31 Jul, 2019

1 commit

  • Building the privcmd code as a loadable module on ARM, we get
    a link error due to the private cache management functions:

    ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!

    Move the code into a new that is always built in when Xen is enabled,
    as suggested by Juergen Gross and Boris Ostrovsky.

    Signed-off-by: Arnd Bergmann
    Reviewed-by: Stefano Stabellini
    Signed-off-by: Juergen Gross

    Arnd Bergmann
     

13 Jul, 2019

1 commit

  • Drop the pgtable_t variable from all implementation for pte_fn_t as none
    of them use it. apply_to_pte_range() should stop computing it as well.
    Should help us save some cycles.

    Link: http://lkml.kernel.org/r/1556803126-26596-1-git-send-email-anshuman.khandual@arm.com
    Signed-off-by: Anshuman Khandual
    Acked-by: Matthew Wilcox
    Cc: Ard Biesheuvel
    Cc: Russell King
    Cc: Catalin Marinas
    Cc: Will Deacon
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Michal Hocko
    Cc: Logan Gunthorpe
    Cc: "Kirill A. Shutemov"
    Cc: Dan Williams
    Cc:
    Cc: Mike Rapoport
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anshuman Khandual
     

30 Nov, 2018

1 commit

  • Add a missing header otherwise compiler warns about missed prototype:

    drivers/xen/xlate_mmu.c:183:5: warning: no previous prototype for 'xen_xlate_unmap_gfn_range?' [-Wmissing-prototypes]
    int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
    ^~~~~~~~~~~~~~~~~~~~~~~~~

    Signed-off-by: Srikanth Boddepalli
    Reviewed-by: Boris Ostrovsky
    Reviewed-by: Joey Pabalinas
    Signed-off-by: Juergen Gross

    Srikanth Boddepalli
     

06 Jul, 2016

2 commits


23 Oct, 2015

1 commit

  • The hypercall interface (as well as the toolstack) is always using 4KB
    page granularity. When the toolstack is asking for mapping a series of
    guest PFN in a batch, it expects to have the page map contiguously in
    its virtual memory.

    When Linux is using 64KB page granularity, the privcmd driver will have
    to map multiple Xen PFN in a single Linux page.

    Note that this solution works on page granularity which is a multiple of
    4KB.

    Signed-off-by: Julien Grall
    Reviewed-by: David Vrabel
    Signed-off-by: David Vrabel

    Julien Grall
     

09 Sep, 2015

1 commit

  • The privcmd code is mixing the usage of GFN and MFN within the same
    functions which make the code difficult to understand when you only work
    with auto-translated guests.

    The privcmd driver is only dealing with GFN so replace all the mention
    of MFN into GFN.

    The ioctl structure used to map foreign change has been left unchanged
    given that the userspace is using it. Nonetheless, add a comment to
    explain the expected value within the "mfn" field.

    Signed-off-by: Julien Grall
    Reviewed-by: David Vrabel
    Signed-off-by: David Vrabel

    Julien Grall
     

16 Mar, 2015

2 commits

  • Make the IOCTL_PRIVCMD_MMAPBATCH_V2 (and older V1 version) map
    multiple frames at a time rather than one at a time, despite the pages
    being non-consecutive GFNs.

    xen_remap_foreign_mfn_array() is added which maps an array of GFNs
    (instead of a consecutive range of GFNs).

    Since per-frame errors are returned in an array, privcmd must set the
    MMAPBATCH_V1 error bits as part of the "report errors" phase, after
    all the frames are mapped.

    Migrate times are significantly improved (when using a PV toolstack
    domain). For example, for an idle 12 GiB PV guest:

    Before After
    real 0m38.179s 0m26.868s
    user 0m15.096s 0m13.652s
    sys 0m28.988s 0m18.732s

    Signed-off-by: David Vrabel
    Reviewed-by: Stefano Stabellini

    David Vrabel
     
  • Auto-translated physmap guests (arm, arm64 and x86 PVHVM/PVH) map and
    unmap foreign GFNs using the same method (updating the physmap).
    Unify the two arm and x86 implementations into one commont one.

    Note that on arm and arm64, the correct error code will be returned
    (instead of always -EFAULT) and map/unmap failure warnings are no
    longer printed. These changes are required if the foreign domain is
    paging (-ENOENT failures are expected and must be propagated up to the
    caller).

    Signed-off-by: David Vrabel
    Reviewed-by: Stefano Stabellini

    David Vrabel