From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
qemu-devel@nongnu.org, Cornelia Huck <cohuck@redhat.com>,
kvm@vger.kernel.org, david@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction
Date: Thu, 9 Aug 2018 12:23:43 +0300 [thread overview]
Message-ID: <20180809122030-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180808034543.GC24415@xz-mi>
On Wed, Aug 08, 2018 at 11:45:43AM +0800, Peter Xu wrote:
> On Wed, Aug 08, 2018 at 12:58:32AM +0300, Michael S. Tsirkin wrote:
> > At least with VTD, it seems entirely possible to change e.g. a PMD
> > atomically to point to a different set of PTEs, then flush.
> > That will allow removing memory at high granularity for
> > an arbitrary device without mdev or PASID dependency.
>
> My understanding is that the guest driver should prohibit this kind of
> operation (say, modifying PMD).
Interesting. Which part of the VTD spec prohibits this?
> Actually I don't see how it can
> happen in Linux if the kernel drivers always call the IOMMU API since
> there are only map/unmap APIs rather than this atomic-modify API.
It could happen with a non-Linux guest which might have a different API.
> The thing is that IMHO it's the guest driver's responsibility to make
> sure the pages will never be used by the device before it removes the
> entry (including modifying the PMD since that actually removes all the
> entries on the old PMD).
If you switch PMDs atomically from one set of valid PTEs to another,
then flush, then as far as I could see it just works in the hardware
VTD, but not in the emulated VTD. So that's a difference in
behaviour. Maybe we are lucky and no one does that.
> If not, I would see it a guest kernel bug
> instead of the bug in the emulation code.
>
> Thanks,
>
> --
> Peter Xu
next prev parent reply other threads:[~2018-08-09 9:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 19:31 [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction Alex Williamson
2018-08-07 19:31 ` [Qemu-devel] [PATCH v3 1/4] balloon: Allow multiple inhibit users Alex Williamson
2018-08-07 19:44 ` Michael S. Tsirkin
2018-08-07 20:08 ` Alex Williamson
2018-08-08 0:07 ` Michael S. Tsirkin
2018-08-07 19:31 ` [Qemu-devel] [PATCH v3 2/4] kvm: Use inhibit to prevent ballooning without synchronous mmu Alex Williamson
2018-08-16 18:15 ` Alex Williamson
2018-08-17 7:46 ` Paolo Bonzini
2018-08-07 19:31 ` [Qemu-devel] [PATCH v3 3/4] vfio: Inhibit ballooning based on group attachment to a container Alex Williamson
2018-08-08 3:38 ` Peter Xu
2018-08-07 19:31 ` [Qemu-devel] [PATCH v3 4/4] vfio/ccw/pci: Allow devices to opt-in for ballooning Alex Williamson
2018-08-07 19:44 ` [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction Michael S. Tsirkin
2018-08-07 19:53 ` Alex Williamson
2018-08-07 21:58 ` Michael S. Tsirkin
2018-08-07 22:40 ` Alex Williamson
2018-08-08 0:02 ` Michael S. Tsirkin
2018-08-08 3:45 ` Peter Xu
2018-08-08 22:23 ` Alex Williamson
2018-08-09 9:20 ` Michael S. Tsirkin
2018-08-09 9:23 ` Michael S. Tsirkin [this message]
2018-08-09 9:37 ` Peter Xu
2018-08-09 10:13 ` Michael S. Tsirkin
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=20180809122030-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--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).