From: Alex Williamson <alex.williamson@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PULL 4/4] vfio/ccw/pci: Allow devices to opt-in for ballooning
Date: Mon, 20 Aug 2018 08:55:03 -0600 [thread overview]
Message-ID: <20180820085503.296a8a62@t450s.home> (raw)
In-Reply-To: <CAFEAcA-jyx-=BeHWM4PVner4oZBYttY0piXBq2VMv7RseMpHZA@mail.gmail.com>
On Mon, 20 Aug 2018 15:23:35 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:
> On 17 August 2018 at 18:08, 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.
> >
> > 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>
>
> > @@ -2869,6 +2870,27 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
> > }
> > }
> >
> > + /*
> > + * Mediated devices *might* operate compatibly with memory ballooning, but
> > + * we cannot know for certain, it depends on whether the mdev vendor driver
> > + * stays in sync with the active working set of the guest driver. Prevent
> > + * the x-balloon-allowed option unless this is minimally an mdev device.
> > + */
> > + tmp = g_strdup_printf("%s/subsystem", vdev->vbasedev.sysfsdev);
> > + subsys = realpath(tmp, NULL);
> > + g_free(tmp);
> > + is_mdev = (strcmp(subsys, "/sys/bus/mdev") == 0);
> > + free(subsys);
>
> Hi -- Coverity points out that we aren't checking the return
> value from realpath() here. It returns NULL on failure, in
> which case we'll pass NULL into strcmp() and segfault.
> (CID 1395101).
Thanks, patch posted. The fix is trivial, you're welcome to pull it in
directly, otherwise I'll send a pull request if qemu-trivial doesn't
get to it first. Thanks,
Alex
next prev parent reply other threads:[~2018-08-20 14:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 17:08 [Qemu-devel] [PULL 0/4] VFIO update 2018-08-17 Alex Williamson
2018-08-17 17:08 ` [Qemu-devel] [PULL 1/4] balloon: Allow multiple inhibit users Alex Williamson
2018-08-22 15:56 ` Christian Borntraeger
2018-08-22 17:47 ` Alex Williamson
2018-08-22 19:01 ` Alex Williamson
2018-08-23 8:10 ` Cornelia Huck
2018-08-17 17:08 ` [Qemu-devel] [PULL 2/4] kvm: Use inhibit to prevent ballooning without synchronous mmu Alex Williamson
2018-08-17 17:08 ` [Qemu-devel] [PULL 3/4] vfio: Inhibit ballooning based on group attachment to a container Alex Williamson
2018-08-17 17:08 ` [Qemu-devel] [PULL 4/4] vfio/ccw/pci: Allow devices to opt-in for ballooning Alex Williamson
2018-08-20 14:23 ` Peter Maydell
2018-08-20 14:55 ` Alex Williamson [this message]
2018-08-20 8:47 ` [Qemu-devel] [PULL 0/4] VFIO update 2018-08-17 Peter Maydell
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=20180820085503.296a8a62@t450s.home \
--to=alex.williamson@redhat.com \
--cc=peter.maydell@linaro.org \
--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).