kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: peterx@redhat.com, david@redhat.com, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, mst@redhat.com
Subject: Re: [PATCH v2 4/4] vfio/ccw/pci: Allow devices to opt-in for ballooning
Date: Tue, 7 Aug 2018 16:15:13 +0200	[thread overview]
Message-ID: <20180807161513.300dea9d.cohuck@redhat.com> (raw)
In-Reply-To: <153299247733.14411.6837517320997223920.stgit@gimli.home>

On Mon, 30 Jul 2018 17:14:37 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:

> 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.

I agree, that should be the case.

For the upcoming vfio-ap devices? I'm not sure how much control there
is over the pages that are used.

> 
> 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 <alex.williamson@redhat.com>
> ---
>  hw/vfio/ccw.c                 |    9 +++++++++
>  hw/vfio/common.c              |   23 ++++++++++++++++++++++-
>  hw/vfio/pci.c                 |   26 +++++++++++++++++++++++++-
>  hw/vfio/trace-events          |    1 +
>  include/hw/vfio/vfio-common.h |    2 ++
>  5 files changed, 59 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> index 351b305e1ae7..40e7b5623e69 100644
> --- a/hw/vfio/ccw.c
> +++ b/hw/vfio/ccw.c
> @@ -349,6 +349,15 @@ static void vfio_ccw_get_device(VFIOGroup *group, VFIOCCWDevice *vcdev,
>          }
>      }
>  
> +    /*
> +     * All vfio-ccw devices are believed to operate compatibly with memory

Better "to operate in a way compatible with memory ballooning"?

> +     * ballooning, ie. pages pinned in the host are in the current working
> +     * set of the guest driver and therefore never overlap with pages
> +     * available to the guest balloon driver.  This needs to be set before
> +     * vfio_get_device() for vfio common to handle the balloon inhibitor.
> +     */
> +    vcdev->vdev.balloon_allowed = true;
> +
>      if (vfio_get_device(group, vcdev->cdev.mdevid, &vcdev->vdev, errp)) {
>          goto out_err;
>      }

  reply	other threads:[~2018-08-07 14:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-30 23:13 [PATCH v2 0/4] Balloon inhibit enhancements, vfio restriction Alex Williamson
2018-07-30 23:13 ` [PATCH v2 1/4] balloon: Allow nested inhibits Alex Williamson
2018-07-31  8:25   ` David Hildenbrand
2018-08-07 12:56   ` Peter Xu
2018-08-07 14:20   ` Cornelia Huck
2018-07-30 23:14 ` [PATCH v2 2/4] kvm: Use inhibit to prevent ballooning without synchronous mmu Alex Williamson
2018-07-31  8:24   ` David Hildenbrand
2018-08-07 12:56   ` Peter Xu
2018-08-07 14:24   ` Cornelia Huck
2018-07-30 23:14 ` [PATCH v2 3/4] vfio: Inhibit ballooning based on group attachment to a container Alex Williamson
2018-08-07 13:10   ` Peter Xu
2018-08-07 16:35     ` Alex Williamson
2018-08-08  3:22       ` Peter Xu
2018-07-30 23:14 ` [PATCH v2 4/4] vfio/ccw/pci: Allow devices to opt-in for ballooning Alex Williamson
2018-08-07 14:15   ` Cornelia Huck [this message]
2018-07-31 12:29 ` [PATCH v2 0/4] Balloon inhibit enhancements, vfio restriction Michael S. Tsirkin
2018-07-31 14:44   ` Alex Williamson
2018-07-31 15:07     ` Dr. David Alan Gilbert
2018-07-31 21:50       ` Alex Williamson
2018-08-03 18:42         ` Michael S. Tsirkin
2018-08-03 20:12           ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180807161513.300dea9d.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).