[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restr
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction |
Date: |
Thu, 9 Aug 2018 17:37:58 +0800 |
User-agent: |
Mutt/1.10.0 (2018-05-17) |
On Thu, Aug 09, 2018 at 12:23:43PM +0300, Michael S. Tsirkin wrote:
> 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.
Yes, but AFAICT that's also the best we can have now since the
userspace QEMU (or say, the VT-d emulation code) cannot really modify
a real PMD that the hardware uses - it can only call the VFIO APIs,
and finally it boils down again to the host kernel IOMMU APIs to do
map or unmap only. So it's a impossible task until we provide such an
interface through the whole IOMMU/VFIO/... stack just like what you
have discussed in the other thread.
Thanks,
--
Peter Xu
- [Qemu-devel] [PATCH v3 4/4] vfio/ccw/pci: Allow devices to opt-in for ballooning, (continued)
- [Qemu-devel] [PATCH v3 4/4] vfio/ccw/pci: Allow devices to opt-in for ballooning, Alex Williamson, 2018/08/07
- Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction, Michael S. Tsirkin, 2018/08/07
- Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction, Alex Williamson, 2018/08/07
- Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction, Peter Xu, 2018/08/07
- Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction, Alex Williamson, 2018/08/08
- Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction, Michael S. Tsirkin, 2018/08/09
- Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction, Michael S. Tsirkin, 2018/08/09
- Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction,
Peter Xu <=
- Re: [Qemu-devel] [PATCH v3 0/4] Balloon inhibit enhancements, vfio restriction, Michael S. Tsirkin, 2018/08/09