1. 20 8月, 2015 2 次提交
  2. 28 5月, 2015 3 次提交
  3. 18 5月, 2015 1 次提交
  4. 16 3月, 2015 2 次提交
    • D
      xen/privcmd: improve performance of MMAPBATCH_V2 · 4e8c0c8c
      David Vrabel 提交于
      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: NDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      4e8c0c8c
    • D
      xen: unify foreign GFN map/unmap for auto-xlated physmap guests · 628c28ee
      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: NDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      628c28ee
  5. 21 1月, 2015 1 次提交
  6. 04 12月, 2014 1 次提交
  7. 12 9月, 2014 1 次提交
  8. 26 7月, 2014 1 次提交
  9. 13 5月, 2014 1 次提交
  10. 10 5月, 2014 1 次提交
  11. 30 1月, 2014 2 次提交
  12. 06 1月, 2014 1 次提交
    • K
      xen/grant: Implement an grant frame array struct (v3). · efaf30a3
      Konrad Rzeszutek Wilk 提交于
      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: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [v3: Based on top of 'asm/xen/page.h: remove redundant semicolon']
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      efaf30a3
  13. 12 12月, 2013 1 次提交
    • I
      arm: xen: foreign mapping PTEs are special. · a7892f32
      Ian Campbell 提交于
      These mappings are in fact special and require special handling in privcmd,
      which already exists. Failure to mark the PTE as special on arm64 causes all
      sorts of bad PTE fun. e.g.
      
      e.g.:
      
      BUG: Bad page map in process xl  pte:e0004077b33f53 pmd:4079575003
      page:ffffffbce1a2f328 count:1 mapcount:-1 mapping:          (null) index:0x0
      page flags: 0x4000000000000014(referenced|dirty)
      addr:0000007fb5259000 vm_flags:040644fa anon_vma:          (null) mapping:ffffffc03a6fda58 index:0
      vma->vm_ops->fault: privcmd_fault+0x0/0x38
      vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x2c
      CPU: 0 PID: 2657 Comm: xl Not tainted 3.12.0+ #102
      Call trace:
      [<ffffffc0000880f8>] dump_backtrace+0x0/0x12c
      [<ffffffc000088238>] show_stack+0x14/0x1c
      [<ffffffc0004b67e0>] dump_stack+0x70/0x90
      [<ffffffc000125690>] print_bad_pte+0x12c/0x1bc
      [<ffffffc0001268f4>] unmap_single_vma+0x4cc/0x700
      [<ffffffc0001273b4>] unmap_vmas+0x68/0xb4
      [<ffffffc00012c050>] unmap_region+0xcc/0x1d4
      [<ffffffc00012df20>] do_munmap+0x218/0x314
      [<ffffffc00012e060>] vm_munmap+0x44/0x64
      [<ffffffc00012ed78>] SyS_munmap+0x24/0x34
      
      Where unmap_single_vma contains inlined -> unmap_page_range -> zap_pud_range
      -> zap_pmd_range -> zap_pte_range -> print_bad_pte.
      
      Or:
      
      BUG: Bad page state in process xl  pfn:4077b4d
      page:ffffffbce1a2f8d8 count:0 mapcount:-1 mapping:          (null) index:0x0
      page flags: 0x4000000000000014(referenced|dirty)
      Modules linked in:
      CPU: 0 PID: 2657 Comm: xl Tainted: G    B        3.12.0+ #102
      Call trace:
      [<ffffffc0000880f8>] dump_backtrace+0x0/0x12c
      [<ffffffc000088238>] show_stack+0x14/0x1c
      [<ffffffc0004b67e0>] dump_stack+0x70/0x90
      [<ffffffc00010f798>] bad_page+0xc4/0x110
      [<ffffffc00010f8b4>] free_pages_prepare+0xd0/0xd8
      [<ffffffc000110e94>] free_hot_cold_page+0x28/0x178
      [<ffffffc000111460>] free_hot_cold_page_list+0x38/0x60
      [<ffffffc000114cf0>] release_pages+0x190/0x1dc
      [<ffffffc00012c0e0>] unmap_region+0x15c/0x1d4
      [<ffffffc00012df20>] do_munmap+0x218/0x314
      [<ffffffc00012e060>] vm_munmap+0x44/0x64
      [<ffffffc00012ed78>] SyS_munmap+0x24/0x34
      
      x86 already gets this correct. 32-bit arm gets away with this because there is
      not PTE_SPECIAL bit in the PTE there and the vm_normal_page fallback path does
      the right thing.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      a7892f32
  14. 04 12月, 2013 1 次提交
  15. 09 9月, 2013 2 次提交
  16. 05 8月, 2013 1 次提交
  17. 23 7月, 2013 1 次提交
  18. 04 7月, 2013 1 次提交
  19. 14 5月, 2013 3 次提交
  20. 27 4月, 2013 1 次提交
  21. 26 4月, 2013 4 次提交
  22. 20 2月, 2013 1 次提交
  23. 29 11月, 2012 2 次提交
  24. 09 11月, 2012 1 次提交
  25. 07 11月, 2012 1 次提交
  26. 09 8月, 2012 1 次提交
  27. 14 9月, 2012 1 次提交
  28. 13 9月, 2012 1 次提交