1. 11 Feb, 2014 3 commits
  2. 03 Feb, 2014 2 commits
  3. 31 Jan, 2014 3 commits
    • Dave Jones's avatar
      xen/pvh: Fix misplaced kfree from xlated_setup_gnttab_pages · f93576e1
      Dave Jones authored
      Passing a freed 'pages' to free_xenballooned_pages will end badly
      on kernels with slub debug enabled.
      
      This looks out of place between the rc assign and the check, but
      we do want to kfree pages regardless of which path we take.
      Signed-off-by: default avatarDave Jones <davej@fedoraproject.org>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      f93576e1
    • Bob Liu's avatar
      drivers: xen: deaggressive selfballoon driver · bc1b0df5
      Bob Liu authored
      Current xen-selfballoon driver is too aggressive which may cause OOM be
      triggered more often. Eg. this bug reported by James:
      https://lkml.org/lkml/2013/11/21/158
      
      There are two mainly reasons:
      1) The original goal_page didn't consider some pages used by kernel space, like
      slab pages and pages used by device drivers.
      
      2) The balloon driver may not give back memory to guest OS fast enough when the
      workload suddenly aquries a lot of physical memory.
      
      In both cases, the guest OS will suffer from memory pressure and OOM may
      be triggered.
      
      The fix is make xen-selfballoon driver not that aggressive by adding extra 10%
      of total ram pages to goal_page.
      It's more valuable to keep the guest system reliable and response faster than
      balloon out these 10% pages to XEN.
      Signed-off-by: default avatarBob Liu <bob.liu@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      bc1b0df5
    • Zoltan Kiss's avatar
      xen/grant-table: Avoid m2p_override during mapping · 08ece5bb
      Zoltan Kiss authored
      The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
      for blkback and future netback patches it just cause a lock contention, as
      those pages never go to userspace. Therefore this series does the following:
      - the original functions were renamed to __gnttab_[un]map_refs, with a new
        parameter m2p_override
      - based on m2p_override either they follow the original behaviour, or just set
        the private flag and call set_phys_to_machine
      - gnttab_[un]map_refs are now a wrapper to call __gnttab_[un]map_refs with
        m2p_override false
      - a new function gnttab_[un]map_refs_userspace provides the old behaviour
      
      It also removes a stray space from page.h and change ret to 0 if
      XENFEAT_auto_translated_physmap, as that is the only possible return value
      there.
      
      v2:
      - move the storing of the old mfn in page->index to gnttab_map_refs
      - move the function header update to a separate patch
      
      v3:
      - a new approach to retain old behaviour where it needed
      - squash the patches into one
      
      v4:
      - move out the common bits from m2p* functions, and pass pfn/mfn as parameter
      - clear page->private before doing anything with the page, so m2p_find_override
        won't race with this
      
      v5:
      - change return value handling in __gnttab_[un]map_refs
      - remove a stray space in page.h
      - add detail why ret = 0 now at some places
      
      v6:
      - don't pass pfn to m2p* functions, just get it locally
      Signed-off-by: default avatarZoltan Kiss <zoltan.kiss@citrix.com>
      Suggested-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      08ece5bb
  4. 30 Jan, 2014 3 commits
  5. 21 Jan, 2014 1 commit
    • Roger Pau Monne's avatar
      xen/pvh: Set X86_CR0_WP and others in CR0 (v2) · c9f6e997
      Roger Pau Monne authored
      otherwise we will get for some user-space applications
      that use 'clone' with CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID
      end up hitting an assert in glibc manifested by:
      
      general protection ip:7f80720d364c sp:7fff98fd8a80 error:0 in
      libc-2.13.so[7f807209e000+180000]
      
      This is due to the nature of said operations which sets and clears
      the PID.  "In the successful one I can see that the page table of
      the parent process has been updated successfully to use a
      different physical page, so the write of the tid on
      that page only affects the child...
      
      On the other hand, in the failed case, the write seems to happen before
      the copy of the original page is done, so both the parent and the child
      end up with the same value (because the parent copies the page after
      the write of the child tid has already happened)."
      (Roger's analysis). The nature of this is due to the Xen's commit
      of 51e2cac257ec8b4080d89f0855c498cbbd76a5e5
      "x86/pvh: set only minimal cr0 and cr4 flags in order to use paging"
      the CR0_WP was removed so COW features of the Linux kernel were not
      operating properly.
      
      While doing that also update the rest of the CR0 flags to be inline
      with what a baremetal Linux kernel would set them to.
      
      In 'secondary_startup_64' (baremetal Linux) sets:
      
      X86_CR0_PE | X86_CR0_MP | X86_CR0_ET | X86_CR0_NE | X86_CR0_WP |
      X86_CR0_AM | X86_CR0_PG
      
      The hypervisor for HVM type guests (which PVH is a bit) sets:
      X86_CR0_PE | X86_CR0_ET | X86_CR0_TS
      For PVH it specifically sets:
      X86_CR0_PG
      
      Which means we need to set the rest: X86_CR0_MP | X86_CR0_NE  |
      X86_CR0_WP | X86_CR0_AM to have full parity.
      Signed-off-by: default avatarRoger Pau Monne <roger.pau@citrix.com>
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [v1: Took out the cr4 writes to be a seperate patch]
      [v2: 0-DAY kernel found xen_setup_gdt to be missing a static]
      c9f6e997
  6. 20 Jan, 2014 1 commit
  7. 10 Jan, 2014 2 commits
  8. 07 Jan, 2014 6 commits
  9. 06 Jan, 2014 19 commits
    • Konrad Rzeszutek Wilk's avatar
      xen/grant-table: Force to use v1 of grants. · 11c7ff17
      Konrad Rzeszutek Wilk authored
      We have the framework to use v2, but there are no backends that
      actually use it. The end result is that on PV we use v2 grants
      and on PVHVM v1. The v1 has a capacity of 512 grants per page while
      the v2 has 256 grants per page. This means we lose about 50%
      capacity - and if we want more than 16 VIFs (each VIF takes
      512 grants), then we are hitting the max per guest of 32.
      
      Oracle-bug: 16039922
      CC: annie.li@oracle.com
      CC: msw@amazon.com
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      11c7ff17
    • Mukesh Rathor's avatar
      xen/pvh: Support ParaVirtualized Hardware extensions (v3). · 4e903a20
      Mukesh Rathor authored
      PVH allows PV linux guest to utilize hardware extended capabilities,
      such as running MMU updates in a HVM container.
      
      The Xen side defines PVH as (from docs/misc/pvh-readme.txt,
      with modifications):
      
      "* the guest uses auto translate:
       - p2m is managed by Xen
       - pagetables are owned by the guest
       - mmu_update hypercall not available
      * it uses event callback and not vlapic emulation,
      * IDT is native, so set_trap_table hcall is also N/A for a PVH guest.
      
      For a full list of hcalls supported for PVH, see pvh_hypercall64_table
      in arch/x86/hvm/hvm.c in xen.  From the ABI prespective, it's mostly a
      PV guest with auto translate, although it does use hvm_op for setting
      callback vector."
      
      Use .ascii and .asciz to define xen feature string. Note, the PVH
      string must be in a single line (not multiple lines with \) to keep the
      assembler from putting null char after each string before \.
      This patch allows it to be configured and enabled.
      
      We also use introduce the 'XEN_ELFNOTE_SUPPORTED_FEATURES' ELF note to
      tell the hypervisor that 'hvm_callback_vector' is what the kernel
      needs. We can not put it in 'XEN_ELFNOTE_FEATURES' as older hypervisor
      parse fields they don't understand as errors and refuse to load
      the kernel. This work-around fixes the problem.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      4e903a20
    • Mukesh Rathor's avatar
      xen/pvh: Piggyback on PVHVM XenBus. · be3e9cf3
      Mukesh Rathor authored
      PVH is a PV guest with a twist - there are certain things
      that work in it like HVM and some like PV. For the XenBus
      mechanism we want to use the PVHVM mechanism.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      be3e9cf3
    • Konrad Rzeszutek Wilk's avatar
      xen/pvh: Piggyback on PVHVM for grant driver (v4) · 6926f6d6
      Konrad Rzeszutek Wilk authored
      In PVH the shared grant frame is the PFN and not MFN,
      hence its mapped via the same code path as HVM.
      
      The allocation of the grant frame is done differently - we
      do not use the early platform-pci driver and have an
      ioremap area - instead we use balloon memory and stitch
      all of the non-contingous pages in a virtualized area.
      
      That means when we call the hypervisor to replace the GMFN
      with a XENMAPSPACE_grant_table type, we need to lookup the
      old PFN for every iteration instead of assuming a flat
      contingous PFN allocation.
      
      Lastly, we only use v1 for grants. This is because PVHVM
      is not able to use v2 due to no XENMEM_add_to_physmap
      calls on the error status page (see commit
      69e8f430
       xen/granttable: Disable grant v2 for HVM domains.)
      
      Until that is implemented this workaround has to
      be in place.
      
      Also per suggestions by Stefano utilize the PVHVM paths
      as they share common functionality.
      
      v2 of this patch moves most of the PVH code out in the
      arch/x86/xen/grant-table driver and touches only minimally
      the generic driver.
      
      v3, v4: fixes us some of the code due to earlier patches.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      6926f6d6
    • Konrad Rzeszutek Wilk's avatar
      xen/grant: Implement an grant frame array struct (v3). · efaf30a3
      Konrad Rzeszutek Wilk authored
      The 'xen_hvm_resume_frames' used to be an 'unsigned long'
      and contain the virtual address of the grants. That was OK
      for most architectures (PVHVM, ARM) were the grants are contiguous
      in memory. That however is not the case for PVH - in which case
      we will have to do a lookup for each virtual address for the PFN.
      
      Instead of doing that, lets make it a structure which will contain
      the array of PFNs, the virtual address and the count of said PFNs.
      
      Also provide a generic functions: gnttab_setup_auto_xlat_frames and
      gnttab_free_auto_xlat_frames to populate said structure with
      appropriate values for PVHVM and ARM.
      
      To round it off, change the name from 'xen_hvm_resume_frames' to
      a more descriptive one - 'xen_auto_xlat_grant_frames'.
      
      For PVH, in patch "xen/pvh: Piggyback on PVHVM for grant driver"
      we will populate the 'xen_auto_xlat_grant_frames' by ourselves.
      
      v2 moves the xen_remap in the gnttab_setup_auto_xlat_frames
      and also introduces xen_unmap for gnttab_free_auto_xlat_frames.
      Suggested-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [v3: Based on top of 'asm/xen/page.h: remove redundant semicolon']
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      efaf30a3
    • Konrad Rzeszutek Wilk's avatar
      xen/grant-table: Refactor gnttab_init · 45684753
      Konrad Rzeszutek Wilk authored
      We have this odd scenario of where for PV paths we take a shortcut
      but for the HVM paths we first ioremap xen_hvm_resume_frames, then
      assign it to gnttab_shared.addr. This is needed because gnttab_map
      uses gnttab_shared.addr.
      
      Instead of having:
      	if (pv)
      		return gnttab_map
      	if (hvm)
      		...
      
      	gnttab_map
      
      Lets move the HVM part before the gnttab_map and remove the
      first call to gnttab_map.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      45684753
    • Konrad Rzeszutek Wilk's avatar
      xen/grants: Remove gnttab_max_grant_frames dependency on gnttab_init. · 7f256020
      Konrad Rzeszutek Wilk authored
      The function gnttab_max_grant_frames() returns the maximum amount
      of frames (pages) of grants we can have. Unfortunatly it was
      dependent on gnttab_init() having been run before to initialize
      the boot max value (boot_max_nr_grant_frames).
      
      This meant that users of gnttab_max_grant_frames would always
      get a zero value if they called before gnttab_init() - such as
      'platform_pci_init' (drivers/xen/platform-pci.c).
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      7f256020
    • Mukesh Rathor's avatar
      xen/pvh: Piggyback on PVHVM for event channels (v2) · 2771374d
      Mukesh Rathor authored
      PVH is a PV guest with a twist - there are certain things
      that work in it like HVM and some like PV. There is
      a similar mode - PVHVM where we run in HVM mode with
      PV code enabled - and this patch explores that.
      
      The most notable PV interfaces are the XenBus and event channels.
      
      We will piggyback on how the event channel mechanism is
      used in PVHVM - that is we want the normal native IRQ mechanism
      and we will install a vector (hvm callback) for which we
      will call the event channel mechanism.
      
      This means that from a pvops perspective, we can use
      native_irq_ops instead of the Xen PV specific. Albeit in the
      future we could support pirq_eoi_map. But that is
      a feature request that can be shared with PVHVM.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      2771374d
    • Mukesh Rathor's avatar
      xen/pvh: Update E820 to work with PVH (v2) · 9103bb0f
      Mukesh Rathor authored
      In xen_add_extra_mem() we can skip updating P2M as it's managed
      by Xen. PVH maps the entire IO space, but only RAM pages need
      to be repopulated.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      9103bb0f
    • Mukesh Rathor's avatar
      xen/pvh: Secondary VCPU bringup (non-bootup CPUs) · 5840c84b
      Mukesh Rathor authored
      The VCPU bringup protocol follows the PV with certain twists.
      From xen/include/public/arch-x86/xen.h:
      
      Also note that when calling DOMCTL_setvcpucontext and VCPU_initialise
      for HVM and PVH guests, not all information in this structure is updated:
      
       - For HVM guests, the structures read include: fpu_ctxt (if
       VGCT_I387_VALID is set), flags, user_regs, debugreg[*]
      
       - PVH guests are the same as HVM guests, but additionally use ctrlreg[3] to
       set cr3. All other fields not used should be set to 0.
      
      This is what we do. We piggyback on the 'xen_setup_gdt' - but modify
      a bit - we need to call 'load_percpu_segment' so that 'switch_to_new_gdt'
      can load per-cpu data-structures. It has no effect on the VCPU0.
      
      We also piggyback on the %rdi register to pass in the CPU number - so
      that when we bootup a new CPU, the cpu_bringup_and_idle will have
      passed as the first parameter the CPU number (via %rdi for 64-bit).
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      5840c84b
    • Mukesh Rathor's avatar
      xen/pvh: Load GDT/GS in early PV bootup code for BSP. · 8d656bbe
      Mukesh Rathor authored
      During early bootup we start life using the Xen provided
      GDT, which means that we are running with %cs segment set
      to FLAT_KERNEL_CS (FLAT_RING3_CS64 0xe033, GDT index 261).
      
      But for PVH we want to be use HVM type mechanism for
      segment operations. As such we need to switch to the HVM
      one and also reload ourselves with the __KERNEL_CS:eip
      to run in the proper GDT and segment.
      
      For HVM this is usually done in 'secondary_startup_64' in
      (head_64.S) but since we are not taking that bootup
      path (we start in PV - xen_start_kernel) we need to do
      that in the early PV bootup paths.
      
      For good measure we also zero out the %fs, %ds, and %es
      (not strictly needed as Xen has already cleared them
      for us). The %gs is loaded by 'switch_to_new_gdt'.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      8d656bbe
    • Mukesh Rathor's avatar
      xen/pvh: Setup up shared_info. · 4dd322bc
      Mukesh Rathor authored
      For PVHVM the shared_info structure is provided via the same way
      as for normal PV guests (see include/xen/interface/xen.h).
      
      That is during bootup we get 'xen_start_info' via the %esi register
      in startup_xen. Then later we extract the 'shared_info' from said
      structure (in xen_setup_shared_info) and start using it.
      
      The 'xen_setup_shared_info' is all setup to work with auto-xlat
      guests, but there are two functions which it calls that are not:
      xen_setup_mfn_list_list and xen_setup_vcpu_info_placement.
      This patch modifies the P2M code (xen_setup_mfn_list_list)
      while the "Piggyback on PVHVM for event channels" modifies
      the xen_setup_vcpu_info_placement.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      4dd322bc
    • Mukesh Rathor's avatar
      xen/pvh/mmu: Use PV TLB instead of native. · 76bcceff
      Mukesh Rathor authored
      We also optimize one - the TLB flush. The native operation would
      needlessly IPI offline VCPUs causing extra wakeups. Using the
      Xen one avoids that and lets the hypervisor determine which
      VCPU needs the TLB flush.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      76bcceff
    • Mukesh Rathor's avatar
      xen/pvh: MMU changes for PVH (v2) · 4e44e44b
      Mukesh Rathor authored
      .. which are surprisingly small compared to the amount for PV code.
      
      PVH uses mostly native mmu ops, we leave the generic (native_*) for
      the majority and just overwrite the baremetal with the ones we need.
      
      At startup, we are running with pre-allocated page-tables
      courtesy of the tool-stack. But we still need to graft them
      in the Linux initial pagetables. However there is no need to
      unpin/pin and change them to R/O or R/W.
      
      Note that the xen_pagetable_init due to 7836fec9d0994cc9c9150c5a33f0eb0eb08a335a
      "xen/mmu/p2m: Refactor the xen_pagetable_init code." does not
      need any changes - we just need to make sure that xen_post_allocator_init
      does not alter the pvops from the default native one.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      4e44e44b
    • Konrad Rzeszutek Wilk's avatar
      xen/mmu: Cleanup xen_pagetable_p2m_copy a bit. · b621e157
      Konrad Rzeszutek Wilk authored
      Stefano noticed that the code runs only under 64-bit so
      the comments about 32-bit are pointless.
      
      Also we change the condition for xen_revector_p2m_tree
      returning the same value (because it could not allocate
      a swath of space to put the new P2M in) or it had been
      called once already. In such we return early from the
      function.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      b621e157
    • Konrad Rzeszutek Wilk's avatar
      xen/mmu/p2m: Refactor the xen_pagetable_init code (v2). · 32df75cd
      Konrad Rzeszutek Wilk authored
      The revectoring and copying of the P2M only happens when
      !auto-xlat and on 64-bit builds. It is not obvious from
      the code, so lets have seperate 32 and 64-bit functions.
      
      We also invert the check for auto-xlat to make the code
      flow simpler.
      Suggested-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      32df75cd
    • Konrad Rzeszutek Wilk's avatar
      xen/pvh: Don't setup P2M tree. · 696fd7c5
      Konrad Rzeszutek Wilk authored
      P2M is not available for PVH. Fortunatly for us the
      P2M code already has mostly the support for auto-xlat guest thanks to
      commit 3d24bbd7
      "grant-table: call set_phys_to_machine after mapping grant refs"
      which: "
      introduces set_phys_to_machine calls for auto_translated guests
      (even on x86) in gnttab_map_refs and gnttab_unmap_refs.
      translated by swiotlb-xen... " so we don't need to muck much.
      
      with above mentioned "commit you'll get set_phys_to_machine calls
      from gnttab_map_refs and gnttab_unmap_refs but PVH guests won't do
      anything with them " (Stefano Stabellini) which is OK - we want
      them to be NOPs.
      
      This is because we assume that an "IOMMU is always present on the
      plaform and Xen is going to make the appropriate IOMMU pagetable
      changes in the hypercall implementation of GNTTABOP_map_grant_ref
      and GNTTABOP_unmap_grant_ref, then eveything should be transparent
      from PVH priviligied point of view and DMA transfers involving
      foreign pages keep working with no issues[sp]
      
      Otherwise we would need a P2M (and an M2P) for PVH priviligied to
      track these foreign pages .. (see arch/arm/xen/p2m.c)."
      (Stefano Stabellini).
      
      We still have to inhibit the building of the P2M tree.
      That had been done in the past by not calling
      xen_build_dynamic_phys_to_machine (which setups the P2M tree
      and gives us virtual address to access them). But we are missing
      a check for xen_build_mfn_list_list - which was continuing to setup
      the P2M tree and would blow up at trying to get the virtual
      address of p2m_missing (which would have been setup by
      xen_build_dynamic_phys_to_machine).
      
      Hence a check is needed to not call xen_build_mfn_list_list when
      running in auto-xlat mode.
      
      Instead of replicating the check for auto-xlat in enlighten.c
      do it in the p2m.c code. The reason is that the xen_build_mfn_list_list
      is called also in xen_arch_post_suspend without any checks for
      auto-xlat. So for PVH or PV with auto-xlat - we would needlessly
      allocate space for an P2M tree.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      696fd7c5
    • Mukesh Rathor's avatar
      xen/pvh: Early bootup changes in PV code (v4). · d285d683
      Mukesh Rathor authored
      We don't use the filtering that 'xen_cpuid' is doing
      because the hypervisor treats 'XEN_EMULATE_PREFIX' as
      an invalid instruction. This means that all of the filtering
      will have to be done in the hypervisor/toolstack.
      
      Without the filtering we expose to the guest the:
      
       - cpu topology (sockets, cores, etc);
       - the APERF (which the generic scheduler likes to
          use), see  5e626254
          "xen/setup: filter APERFMPERF cpuid feature out"
       - and the inability to figure out whether MWAIT_LEAF
         should be exposed or not. See
         df88b2d9
         "xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded."
       - x2apic, see  4ea9b9ac
         "xen: mask x2APIC feature in PV"
      
      We also check for vector callback early on, as it is a required
      feature. PVH also runs at default kernel IOPL.
      
      Finally, pure PV settings are moved to a separate function that are
      only called for pure PV, ie, pv with pvmmu. They are also #ifdef
      with CONFIG_XEN_PVMMU.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      d285d683
    • Mukesh Rathor's avatar
      xen/pvh/x86: Define what an PVH guest is (v3). · ddc416cb
      Mukesh Rathor authored
      Which is a PV guest with auto page translation enabled
      and with vector callback. It is a cross between PVHVM and PV.
      
      The Xen side defines PVH as (from docs/misc/pvh-readme.txt,
      with modifications):
      
      "* the guest uses auto translate:
       - p2m is managed by Xen
       - pagetables are owned by the guest
       - mmu_update hypercall not available
      * it uses event callback and not vlapic emulation,
      * IDT is native, so set_trap_table hcall is also N/A for a PVH guest.
      
      For a full list of hcalls supported for PVH, see pvh_hypercall64_table
      in arch/x86/hvm/hvm.c in xen.  From the ABI prespective, it's mostly a
      PV guest with auto translate, although it does use hvm_op for setting
      callback vector."
      
      Also we use the PV cpuid, albeit we can use the HVM (native) cpuid.
      However, we do have a fair bit of filtering in the xen_cpuid and
      we can piggyback on that until the hypervisor/toolstack filters
      the appropiate cpuids. Once that is done we can swap over to
      use the native one.
      
      We setup a Kconfig entry that is disabled by default and
      cannot be enabled.
      
      Note that on ARM the concept of PVH is non-existent. As Ian
      put it: "an ARM guest is neither PV nor HVM nor PVHVM.
      It's a bit like PVH but is different also (it's further towards
      the H end of the spectrum than even PVH).". As such these
      options (PVHVM, PVH) are never enabled nor seen on ARM
      compilations.
      Signed-off-by: default avatarMukesh Rathor <mukesh.rathor@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ddc416cb