qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 01ccbe: balloon: Allow multiple inhibit users


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 01ccbe: balloon: Allow multiple inhibit users
Date: Mon, 20 Aug 2018 01:47:46 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 01ccbec7bdf6f89f1b7d46dda05e4c1fd2dd5ade
      
https://github.com/qemu/qemu/commit/01ccbec7bdf6f89f1b7d46dda05e4c1fd2dd5ade
  Author: Alex Williamson <address@hidden>
  Date:   2018-08-17 (Fri, 17 Aug 2018)

  Changed paths:
    M balloon.c

  Log Message:
  -----------
  balloon: Allow multiple inhibit users

A simple true/false internal state does not allow multiple users.  Fix
this within the existing interface by converting to a counter, so long
as the counter is elevated, ballooning is inhibited.

Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: f59489423ab79852e98d9b3025b7d99ba8da584f
      
https://github.com/qemu/qemu/commit/f59489423ab79852e98d9b3025b7d99ba8da584f
  Author: Alex Williamson <address@hidden>
  Date:   2018-08-17 (Fri, 17 Aug 2018)

  Changed paths:
    M accel/kvm/kvm-all.c
    M hw/virtio/virtio-balloon.c

  Log Message:
  -----------
  kvm: Use inhibit to prevent ballooning without synchronous mmu

Remove KVM specific tests in balloon_page(), instead marking
ballooning as inhibited without KVM_CAP_SYNC_MMU support.

Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: c65ee433153b5925e183a00ebf568e160077c694
      
https://github.com/qemu/qemu/commit/c65ee433153b5925e183a00ebf568e160077c694
  Author: Alex Williamson <address@hidden>
  Date:   2018-08-17 (Fri, 17 Aug 2018)

  Changed paths:
    M hw/vfio/common.c

  Log Message:
  -----------
  vfio: Inhibit ballooning based on group attachment to a container

We use a VFIOContainer to associate an AddressSpace to one or more
VFIOGroups.  The VFIOContainer represents the DMA context for that
AdressSpace for those VFIOGroups and is synchronized to changes in
that AddressSpace via a MemoryListener.  For IOMMU backed devices,
maintaining the DMA context for a VFIOGroup generally involves
pinning a host virtual address in order to create a stable host
physical address and then mapping a translation from the associated
guest physical address to that host physical address into the IOMMU.

While the above maintains the VFIOContainer synchronized to the QEMU
memory API of the VM, memory ballooning occurs outside of that API.
Inflating the memory balloon (ie. cooperatively capturing pages from
the guest for use by the host) simply uses MADV_DONTNEED to "zap"
pages from QEMU's host virtual address space.  The page pinning and
IOMMU mapping above remains in place, negating the host's ability to
reuse the page, but the host virtual to host physical mapping of the
page is invalidated outside of QEMU's memory API.

When the balloon is later deflated, attempting to cooperatively
return pages to the guest, the page is simply freed by the guest
balloon driver, allowing it to be used in the guest and incurring a
page fault when that occurs.  The page fault maps a new host physical
page backing the existing host virtual address, meanwhile the
VFIOContainer still maintains the translation to the original host
physical address.  At this point the guest vCPU and any assigned
devices will map different host physical addresses to the same guest
physical address.  Badness.

The IOMMU typically does not have page level granularity with which
it can track this mapping without also incurring inefficiencies in
using page size mappings throughout.  MMU notifiers in the host
kernel also provide indicators for invalidating the mapping on
balloon inflation, not for updating the mapping when the balloon is
deflated.  For these reasons we assume a default behavior that the
mapping of each VFIOGroup into the VFIOContainer is incompatible
with memory ballooning and increment the balloon inhibitor to match
the attached VFIOGroups.

Reviewed-by: Peter Xu <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: 238e91728503d400e1c4e644e3a9b80f9e621682
      
https://github.com/qemu/qemu/commit/238e91728503d400e1c4e644e3a9b80f9e621682
  Author: Alex Williamson <address@hidden>
  Date:   2018-08-17 (Fri, 17 Aug 2018)

  Changed paths:
    M hw/vfio/ccw.c
    M hw/vfio/common.c
    M hw/vfio/pci.c
    M hw/vfio/trace-events
    M include/hw/vfio/vfio-common.h

  Log Message:
  -----------
  vfio/ccw/pci: Allow devices to opt-in for ballooning

If a vfio assigned device makes use of a physical IOMMU, then memory
ballooning is necessarily inhibited due to the page pinning, lack of
page level granularity at the IOMMU, and sufficient notifiers to both
remove the page on balloon inflation and add it back on deflation.
However, not all devices are backed by a physical IOMMU.  In the case
of mediated devices, if a vendor driver is well synchronized with the
guest driver, such that only pages actively used by the guest driver
are pinned by the host mdev vendor driver, then there should be no
overlap between pages available for the balloon driver and pages
actively in use by the device.  Under these conditions, ballooning
should be safe.

vfio-ccw devices are always mediated devices and always operate under
the constraints above.  Therefore we can consider all vfio-ccw devices
as balloon compatible.

The situation is far from straightforward with vfio-pci.  These
devices can be physical devices with physical IOMMU backing or
mediated devices where it is unknown whether a physical IOMMU is in
use or whether the vendor driver is well synchronized to the working
set of the guest driver.  The safest approach is therefore to assume
all vfio-pci devices are incompatible with ballooning, but allow user
opt-in should they have further insight into mediated devices.

Signed-off-by: Alex Williamson <address@hidden>


  Commit: a544c9110d3971cc764c2dcd86a55b28534e4a63
      
https://github.com/qemu/qemu/commit/a544c9110d3971cc764c2dcd86a55b28534e4a63
  Author: Peter Maydell <address@hidden>
  Date:   2018-08-17 (Fri, 17 Aug 2018)

  Changed paths:
    M accel/kvm/kvm-all.c
    M balloon.c
    M hw/vfio/ccw.c
    M hw/vfio/common.c
    M hw/vfio/pci.c
    M hw/vfio/trace-events
    M hw/virtio/virtio-balloon.c
    M include/hw/vfio/vfio-common.h

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20180817.0' 
into staging

VFIO update 2018-08-17

 - Enhance balloon inhibitor for multiple users and use around vfio
   device assignment (Alex Williamson)

# gpg: Signature made Fri 17 Aug 2018 17:43:37 BST
# gpg:                using RSA key 239B9B6E3BB08B22
# gpg: Good signature from "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"
# Primary key fingerprint: 42F6 C04E 540B D1A9 9E7B  8A90 239B 9B6E 3BB0 8B22

* remotes/awilliam/tags/vfio-update-20180817.0:
  vfio/ccw/pci: Allow devices to opt-in for ballooning
  vfio: Inhibit ballooning based on group attachment to a container
  kvm: Use inhibit to prevent ballooning without synchronous mmu
  balloon: Allow multiple inhibit users

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/0abaa41d936b...a544c9110d39
      **NOTE:** This service has been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]