Re: [PATCH v5 2/3] virtio_pci: Use the DMA API for virtqueues when possible

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Sep 30, 2014 at 08:48:45AM -0700, Andy Lutomirski wrote:
> On Tue, Sep 30, 2014 at 8:38 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > I thought hard about this, I think we are better off waiting till the
> > next release: there's a chance QEMU will have IOMMU support for KVM x86
> > then, and this will make it easier to judge which way does the wind
> > blow.
> >
> > It seems that we lose nothing substantial keeping the status quo a bit longer,
> > but if we make an incompatible change in guests now we might
> > create nasty compatibility headaches going forward.
> >
> 
> I would argue for the opposite approach.  Having a QEMU release that
> supports an IOMMU on x86 and exposes a commonly used PCI device that
> bypasses that IOMMU without any explicit notification to the guest
> (and specification!) that this is happening is IMO insane.  Once that
> happens, we'll have to address the nasty case on both x86 and PPC.
> This will suck.
>
> If we accept the guest change and make sure that there is never a QEMU
> release that has a visible IOMMU cheat on any arch other than PPC,
> then at least the damage will be contained.

Wrt QEMU this sounds reasonable. Wrt guest, deferring guest changes
a bit, until we have a better idea about how the host side behaves
sounds better to me than saying "this is how guests will behave,
let the host adapt to that".

> x86 will be worse than PPC, too: the special case needed to support
> QEMU 2.2 with IOMMU and virtio enabled with a Xen guest will be fairly
> large and disgusting and will only exist to support something that IMO
> should never have existed in the first place.
> 
> PPC at least avoids *that* problem by virtue of not having Xen
> paravirt.  (And please don't add Xen paravirt to PPC -- x86 is trying
> to kill it off, but this is a 5-10 year project.)
> 
> [..., reordered]
> 
> >>
> >> Except that I think that PPC is the only platform on which QEMU's code
> >> actually bypasses any IOMMU.  Unless we've all missed something, there
> >> is no QEMU release that will put a virtio device behind an IOMMU on
> >> any platform other than PPC.
> >
> > I think that is true but it seems that this will be true for x86 for
> > QEMU 2.2 unless we make some changes there.
> > Which we might not have the time for since 2.2 is feature frozen
> > from tomorrow.
> > Maybe we should disable the IOMMU in 2.2, this is worth considering.
> >
> 
> Please do.

Or at least disable it just if there are virtio devices.

> Also, try booting this 2.2 QEMU candidate with nested virtualization
> on.  Then bind vfio to a virtio-pci device and watch the guest get
> corrupted.  QEMU will blame Linux for incorrectly programming the
> hardware, and Linux will blame QEMU for its blatant violation of the
> ACPI spec.  Given that this is presumably most of the point of adding
> IOMMU support, it seems like a terrible idea to let code like that
> into the wild.
> 
> If this happens, Linux may also end up needing a quirk to prevent vfio
> from binding to QEMU 2.2's virtio-pci devices.
> 
> --Andy

This specific item wouldn't worry me too much.

-- 
MST