1. 23 5月, 2018 2 次提交
  2. 27 10月, 2017 1 次提交
  3. 08 7月, 2017 1 次提交
  4. 26 4月, 2017 1 次提交
  5. 23 3月, 2017 1 次提交
  6. 23 11月, 2016 2 次提交
  7. 29 10月, 2016 5 次提交
  8. 03 8月, 2016 1 次提交
  9. 12 7月, 2016 1 次提交
  10. 23 5月, 2016 3 次提交
  11. 10 2月, 2016 1 次提交
  12. 27 1月, 2016 3 次提交
    • I
      xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory API. · e0cb42ae
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxenforeignmemory which provides access to
      privileged foreign mappings and which will provide an interface
      equivalent to xc_map_foreign_{pages,bulk}.
      
      The new xenforeignmemory_map() function behaves like
      xc_map_foreign_pages() when the err argument is NULL and like
      xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
      here onto checking err == NULL and calling the appropriate old
      function.
      
      Note that xenforeignmemory_map() takes the number of pages before the
      arrays themselves, in order to support potentially future use of
      variable-length-arrays in the prototype (in the future, when Xen's
      baseline toolchain requirements are new enough to ensure VLAs are
      supported).
      
      In preparation for adding support for libxenforeignmemory add support
      to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
      switch to using the new API. These shims will disappear for versions
      of Xen which include libxenforeignmemory.
      
      Since libxenforeignmemory will have its own handle type but for <= 4.6
      the functionality is provided by using a libxenctrl handle we
      introduce a new global xen_fmem alongside the existing xen_xc. In fact
      we make xen_fmem a pointer to the existing xen_xc, which then works
      correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
      is a pointer). In the latter case xen_fmem is actually a double
      indirect pointer, but it all falls out in the wash.
      
      Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
      rather than just specifying that munmap should be used, so the unmap
      paths are updated to use xenforeignmemory_unmap, which is a shim for
      munmap on these versions of xen. The mappings in xen-hvm.c do not
      appear to be unmapped (which makes sense for a qemu-dm process)
      
      In fb_disconnect this results in a change from simply mmap over the
      existing mapping (with an implicit munmap) to expliclty unmapping with
      xenforeignmemory_unmap and then mapping the required anonymous memory
      in the same hole. I don't think this is a problem since any other
      thread which was racily touching this region would already be running
      the risk of hitting the mapping halfway through the call. If this is
      thought to be a problem then we could consider adding an extra API to
      the libxenforeignmemory interface to replace a foreign mapping with
      anonymous shared memory, but I'd prefer not to.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      e0cb42ae
    • I
      xen: Switch to libxengnttab interface for compat shims. · c1345a88
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxengnttab which provides access to grant
      tables.
      
      In preparation for this switch the compatibility layer in xen_common.h
      (which support building with older versions of Xen) to use what will
      be the new library API. This means that the gnttab shim will disappear
      for versions of Xen which include libxengnttab.
      
      To simplify things for the <= 4.0.0 support we wrap the int fd in a
      malloc(sizeof int) such that the handle is always a pointer. This
      leads to less typedef headaches and the need for
      XC_HANDLER_INITIAL_VALUE etc for these interfaces.
      
      Note that this patch does not add any support for actually using
      libxengnttab, it just adjusts the existing shims.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      c1345a88
    • I
      xen: Switch to libxenevtchn interface for compat shims. · a2db2a1e
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxenevtchn which provides access to event
      channels.
      
      In preparation for this switch the compatibility layer in xen_common.h
      (which support building with older versions of Xen) to use what will
      be the new library API. This means that the evtchn shim will disappear
      for versions of Xen which include libxenevtchn.
      
      To simplify things for the <= 4.0.0 support we wrap the int fd in a
      malloc(sizeof int) such that the handle is always a pointer. This
      leads to less typedef headaches and the need for
      XC_HANDLER_INITIAL_VALUE etc for these interfaces.
      
      Note that this patch does not add any support for actually using
      libxenevtchn, it just adjusts the existing shims.
      
      Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
      since that functionality is not exposed by /dev/xen/evtchn.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      a2db2a1e
  13. 07 7月, 2014 1 次提交
  14. 09 4月, 2013 1 次提交
    • P
      hw: move headers to include/ · 0d09e41a
      Paolo Bonzini 提交于
      Many of these should be cleaned up with proper qdev-/QOM-ification.
      Right now there are many catch-all headers in include/hw/ARCH depending
      on cpu.h, and this makes it necessary to compile these files per-target.
      However, fixing this does not belong in these patches.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0d09e41a
  15. 05 4月, 2013 1 次提交
  16. 01 3月, 2013 1 次提交
    • P
      hw: include hw header files with full paths · 83c9f4ca
      Paolo Bonzini 提交于
      Done with this script:
      
      cd hw
      for i in `find . -name '*.h' | sed 's/^..//'`; do
        echo '\,^#.*include.*["<]'$i'[">], s,'$i',hw/&,'
      done | sed -i -f - `find . -type f`
      
      This is so that paths remain valid as files are moved.
      
      Instead, files in hw/dataplane are referenced with the relative path.
      We know they are not going to move to include/, and they are the only
      include files that are in subdirectories _and_ move.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      83c9f4ca
  17. 19 12月, 2012 3 次提交
  18. 04 8月, 2012 1 次提交
  19. 09 9月, 2011 1 次提交
  20. 08 5月, 2011 1 次提交
  21. 03 10月, 2010 1 次提交
  22. 24 8月, 2010 1 次提交
    • B
      Rearrange block headers · 2446333c
      Blue Swirl 提交于
      Changing block.h or blockdev.h resulted in recompiling most objects.
      
      Move DriveInfo typedef and BlockInterfaceType enum definitions
      to qemu-common.h and rearrange blockdev.h use to decrease churn.
      Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      2446333c
  23. 15 6月, 2010 1 次提交
  24. 22 3月, 2010 1 次提交
  25. 20 3月, 2010 1 次提交
  26. 12 9月, 2009 1 次提交
    • B
      Fix sys-queue.h conflict for good · 72cf2d4f
      Blue Swirl 提交于
      Problem: Our file sys-queue.h is a copy of the BSD file, but there are
      some additions and it's not entirely compatible. Because of that, there have
      been conflicts with system headers on BSD systems. Some hacks have been
      introduced in the commits 15cc9235,
      f40d7537,
      96555a96 and
      3990d09a but the fixes were fragile.
      
      Solution: Avoid the conflict entirely by renaming the functions and the
      file. Revert the previous hacks.
      Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      72cf2d4f
  27. 22 4月, 2009 2 次提交