1. 06 Oct, 2015 1 commit
    • David Vrabel's avatar
      x86/xen/p2m: hint at the last populated P2M entry · 98dd166e
      David Vrabel authored
      With commit 633d6f17
       (x86/xen: prepare
      p2m list for memory hotplug) the P2M may be sized to accomdate a much
      larger amount of memory than the domain currently has.
      When saving a domain, the toolstack must scan all the P2M looking for
      populated pages.  This results in a performance regression due to the
      unnecessary scanning.
      Instead of reporting (via shared_info) the maximum possible size of
      the P2M, hint at the last PFN which might be populated.  This hint is
      increased as new leaves are added to the P2M (in the expectation that
      they will be used for populated entries).
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Cc: <stable@vger.kernel.org> # 4.0+
  2. 20 Aug, 2015 4 commits
  3. 03 Jun, 2015 1 commit
    • Stephen Rothwell's avatar
      x86/mm: Decouple <linux/vmalloc.h> from <asm/io.h> · d6472302
      Stephen Rothwell authored
      Nothing in <asm/io.h> uses anything from <linux/vmalloc.h>, so
      remove it from there and fix up the resulting build problems
      triggered on x86 {64|32}-bit {def|allmod|allno}configs.
      The breakages were triggering in places where x86 builds relied
      on vmalloc() facilities but did not include <linux/vmalloc.h>
      explicitly and relied on the implicit inclusion via <asm/io.h>.
      Also add:
        - <linux/init.h> to <linux/io.h>
        - <asm/pgtable_types> to <asm/io.h>
      ... which were two other implicit header file dependencies.
      Suggested-by: default avatarDavid Miller <davem@davemloft.net>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      [ Tidied up the changelog. ]
      Acked-by: default avatarDavid Miller <davem@davemloft.net>
      Acked-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarVinod Koul <vinod.koul@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Colin Cross <ccross@android.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: James E.J. Bottomley <JBottomley@odin.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Kristen Carlson Accardi <kristen@linux.intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Suma Ramars <sramars@cisco.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  4. 23 Mar, 2015 1 commit
  5. 27 Feb, 2015 1 commit
  6. 28 Jan, 2015 4 commits
  7. 19 Jan, 2015 1 commit
  8. 12 Jan, 2015 2 commits
  9. 08 Jan, 2015 1 commit
  10. 08 Dec, 2014 1 commit
  11. 04 Dec, 2014 9 commits
  12. 23 Oct, 2014 3 commits
    • Juergen Gross's avatar
      x86/xen: avoid race in p2m handling · 3a0e94f8
      Juergen Gross authored
      When a new p2m leaf is allocated this leaf is linked into the p2m tree
      via cmpxchg. Unfortunately the compare value for checking the success
      of the update is read after checking for the need of a new leaf. It is
      possible that a new leaf has been linked into the tree concurrently
      in between. This could lead to a leaked memory page and to the loss of
      some p2m entries.
      Avoid the race by using the read compare value for checking the need
      of a new p2m leaf and use ACCESS_ONCE() to get it.
      There are other places which seem to need ACCESS_ONCE() to ensure
      proper operation. Change them accordingly.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
    • Juergen Gross's avatar
      x86/xen: delay construction of mfn_list_list · 2c185687
      Juergen Gross authored
      The 3 level p2m tree for the Xen tools is constructed very early at
      boot by calling xen_build_mfn_list_list(). Memory needed for this tree
      is allocated via extend_brk().
      As this tree (other than the kernel internal p2m tree) is only needed
      for domain save/restore, live migration and crash dump analysis it
      doesn't matter whether it is constructed very early or just some
      milliseconds later when memory allocation is possible by other means.
      This patch moves the call of xen_build_mfn_list_list() just after
      calling xen_pagetable_p2m_copy() simplifying this function, too, as it
      doesn't have to bother with two parallel trees now. The same applies
      for some other internal functions.
      While simplifying code, make early_can_reuse_p2m_middle() static and
      drop the unused second parameter. p2m_mid_identity_mfn can be removed
      as well, it isn't used either.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
    • Juergen Gross's avatar
      x86/xen: avoid writing to freed memory after race in p2m handling · 239af7c7
      Juergen Gross authored
      In case a race was detected during allocation of a new p2m tree
      element in alloc_p2m() the new allocated mid_mfn page is freed without
      updating the pointer to the found value in the tree. This will result
      in overwriting the just freed page with the mfn of the p2m leaf.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
  13. 23 Sep, 2014 1 commit
    • Matt Rushton's avatar
      xen/setup: Remap Xen Identity Mapped RAM · 4fbb67e3
      Matt Rushton authored
      Instead of ballooning up and down dom0 memory this remaps the existing mfns
      that were replaced by the identity map. The reason for this is that the
      existing implementation ballooned memory up and and down which caused dom0
      to have discontiguous pages. In some cases this resulted in the use of bounce
      buffers which reduced network I/O performance significantly. This change will
      honor the existing order of the pages with the exception of some boundary
      To do this we need to update both the Linux p2m table and the Xen m2p table.
      Particular care must be taken when updating the p2m table since it's important
      to limit table memory consumption and reuse the existing leaf pages which get
      freed when an entire leaf page is set to the identity map. To implement this,
      mapping updates are grouped into blocks with table entries getting cached
      temporarily and then released.
      On my test system before:
      Total pages: 2105014
      Total contiguous: 1640635
      Total pages: 2105014
      Total contiguous: 2098904
      Signed-off-by: default avatarMatthew Rushton <mrushton@amazon.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
  14. 31 Jul, 2014 1 commit
  15. 15 May, 2014 4 commits
  16. 18 Mar, 2014 1 commit
  17. 03 Feb, 2014 1 commit
  18. 31 Jan, 2014 1 commit
    • 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
      - move the storing of the old mfn in page->index to gnttab_map_refs
      - move the function header update to a separate patch
      - a new approach to retain old behaviour where it needed
      - squash the patches into one
      - 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
      - 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
      - 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>
  19. 06 Jan, 2014 2 commits
    • 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>
    • 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
      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>