1. 15 7月, 2017 2 次提交
  2. 14 7月, 2017 2 次提交
  3. 27 6月, 2017 1 次提交
  4. 15 6月, 2017 2 次提交
  5. 04 6月, 2017 1 次提交
  6. 26 5月, 2017 2 次提交
  7. 24 4月, 2017 1 次提交
    • G
      memory: add support getting and using a dirty bitmap copy. · 8deaf12c
      Gerd Hoffmann 提交于
      This patch adds support for getting and using a local copy of the dirty
      bitmap.
      
      memory_region_snapshot_and_clear_dirty() will create a snapshot of the
      dirty bitmap for the specified range, clear the dirty bitmap and return
      the copy.  The returned bitmap can be a bit larger than requested, the
      range is expanded so the code can copy unsigned longs from the bitmap
      and avoid atomic bit update operations.
      
      memory_region_snapshot_get_dirty() will return the dirty status of
      pages, pretty much like memory_region_get_dirty(), but using the copy
      returned by memory_region_copy_and_clear_dirty().
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Message-id: 20170421091632.30900-3-kraxel@redhat.com
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      8deaf12c
  8. 21 4月, 2017 6 次提交
  9. 03 4月, 2017 1 次提交
    • P
      exec: revert MemoryRegionCache · 90c4fe5f
      Paolo Bonzini 提交于
      MemoryRegionCache did not know about virtio support for IOMMUs (because the
      two features were developed at the same time).  Revert MemoryRegionCache
      to "normal" address_space_* operations for 2.9, as it is simpler than
      undoing the virtio patches.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      90c4fe5f
  10. 14 3月, 2017 1 次提交
  11. 18 2月, 2017 1 次提交
  12. 28 1月, 2017 1 次提交
  13. 17 1月, 2017 1 次提交
  14. 10 1月, 2017 2 次提交
  15. 22 12月, 2016 2 次提交
  16. 31 10月, 2016 2 次提交
    • A
      memory: Don't use memcpy for ram_device regions · 4a2e242b
      Alex Williamson 提交于
      With a vfio assigned device we lay down a base MemoryRegion registered
      as an IO region, giving us read & write accessors.  If the region
      supports mmap, we lay down a higher priority sub-region MemoryRegion
      on top of the base layer initialized as a RAM device pointer to the
      mmap.  Finally, if we have any quirks for the device (ie. address
      ranges that need additional virtualization support), we put another IO
      sub-region on top of the mmap MemoryRegion.  When this is flattened,
      we now potentially have sub-page mmap MemoryRegions exposed which
      cannot be directly mapped through KVM.
      
      This is as expected, but a subtle detail of this is that we end up
      with two different access mechanisms through QEMU.  If we disable the
      mmap MemoryRegion, we make use of the IO MemoryRegion and service
      accesses using pread and pwrite to the vfio device file descriptor.
      If the mmap MemoryRegion is enabled and results in one of these
      sub-page gaps, QEMU handles the access as RAM, using memcpy to the
      mmap.  Using either pread/pwrite or the mmap directly should be
      correct, but using memcpy causes us problems.  I expect that not only
      does memcpy not necessarily honor the original width and alignment in
      performing a copy, but it potentially also uses processor instructions
      not intended for MMIO spaces.  It turns out that this has been a
      problem for Realtek NIC assignment, which has such a quirk that
      creates a sub-page mmap MemoryRegion access.
      
      To resolve this, we disable memory_access_is_direct() for ram_device
      regions since QEMU assumes that it can use memcpy for those regions.
      Instead we access through MemoryRegionOps, which replaces the memcpy
      with simple de-references of standard sizes to the host memory.
      
      With this patch we attempt to provide unrestricted access to the RAM
      device, allowing byte through qword access as well as unaligned
      access.  The assumption here is that accesses initiated by the VM are
      driven by a device specific driver, which knows the device
      capabilities.  If unaligned accesses are not supported by the device,
      we don't want them to work in a VM by performing multiple aligned
      accesses to compose the unaligned access.  A down-side of this
      philosophy is that the xp command from the monitor attempts to use
      the largest available access weidth, unaware of the underlying
      device.  Using memcpy had this same restriction, but at least now an
      operator can dump individual registers, even if blocks of device
      memory may result in access widths beyond the capabilities of a
      given device (RTL NICs only support up to dword).
      Reported-by: NThorsten Kohfeldt <thorsten.kohfeldt@gmx.de>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      4a2e242b
    • A
      memory: Replace skip_dump flag with "ram_device" · 21e00fa5
      Alex Williamson 提交于
      Setting skip_dump on a MemoryRegion allows us to modify one specific
      code path, but the restriction we're trying to address encompasses
      more than that.  If we have a RAM MemoryRegion backed by a physical
      device, it not only restricts our ability to dump that region, but
      also affects how we should manipulate it.  Here we recognize that
      MemoryRegions do not change to sometimes allow dumps and other times
      not, so we replace setting the skip_dump flag with a new initializer
      so that we know exactly the type of region to which we're applying
      this behavior.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      21e00fa5
  17. 24 10月, 2016 2 次提交
  18. 27 9月, 2016 3 次提交
    • P
      migration: sync all address spaces · 9c1f8f44
      Paolo Bonzini 提交于
      Migrating a VM during reboot sometimes results in differences
      between the source and destination in the SMRAM area.
      
      This is because migration_bitmap_sync() only fetches from KVM
      the dirty log of address_space_memory.  SMRAM memory slots
      are ignored and the modifications to SMRAM are not sent to the
      destination.
      Reported-by: NHe Rongguang <herongguang.he@huawei.com>
      Reviewed-by: NHe Rongguang <herongguang.he@huawei.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      9c1f8f44
    • P
      memory: introduce IOMMUOps.notify_flag_changed · 5bf3d319
      Peter Xu 提交于
      The new interface can be used to replace the old notify_started() and
      notify_stopped(). Meanwhile it provides explicit flags so that IOMMUs
      can know what kind of notifications it is requested for.
      Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Message-Id: <1474606948-14391-3-git-send-email-peterx@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5bf3d319
    • P
      memory: introduce IOMMUNotifier and its caps · cdb30812
      Peter Xu 提交于
      IOMMU Notifier list is used for notifying IO address mapping changes.
      Currently VFIO is the only user.
      
      However it is possible that future consumer like vhost would like to
      only listen to part of its notifications (e.g., cache invalidations).
      
      This patch introduced IOMMUNotifier and IOMMUNotfierFlag bits for a
      finer grained control of it.
      
      IOMMUNotifier contains a bitfield for the notify consumer describing
      what kind of notification it is interested in. Currently two kinds of
      notifications are defined:
      
      - IOMMU_NOTIFIER_MAP:    for newly mapped entries (additions)
      - IOMMU_NOTIFIER_UNMAP:  for entries to be removed (cache invalidates)
      
      When registering the IOMMU notifier, we need to specify one or multiple
      types of messages to listen to.
      
      When notifications are triggered, its type will be checked against the
      notifier's type bits, and only notifiers with registered bits will be
      notified.
      
      (For any IOMMU implementation, an in-place mapping change should be
       notified with an UNMAP followed by a MAP.)
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Message-Id: <1474606948-14391-2-git-send-email-peterx@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      cdb30812
  19. 04 7月, 2016 2 次提交
    • P
      memory: Assert that memory_region_init_rom_device() ops aren't NULL · 39e0b03d
      Peter Maydell 提交于
      It doesn't make sense to pass a NULL ops argument to
      memory_region_init_rom_device(), because the effect will
      be that if the guest tries to write to the memory region
      then QEMU will segfault. Catch the bug earlier by sanity
      checking the arguments to this function, and remove the
      misleading documentation that suggests that passing NULL
      might be sensible.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Message-id: 1467122287-24974-4-git-send-email-peter.maydell@linaro.org
      39e0b03d
    • P
      memory: Provide memory_region_init_rom() · a1777f7f
      Peter Maydell 提交于
      Provide a new helper function memory_region_init_rom() for memory
      regions which are read-only (and unlike those created by
      memory_region_init_rom_device() don't have special behaviour
      for writes). This has the same behaviour as calling
      memory_region_init_ram() and then memory_region_set_readonly()
      (which is what we do today in boards with pure ROMs) but is a
      more easily discoverable API for the purpose.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Message-id: 1467122287-24974-2-git-send-email-peter.maydell@linaro.org
      a1777f7f
  20. 01 7月, 2016 1 次提交
  21. 22 6月, 2016 1 次提交
  22. 29 5月, 2016 3 次提交