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

Konrad Rzeszutek Wilk
2014-09-30T17:53:54Z

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

<scratches his head> I don't follow.
>
> 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.)

Correction:
- The Xen project is trying to kill some of the paravirts off.
- KVM uses paravirts as well (and then added some)

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

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