On Tue, Sep 30, 2014 at 8:38 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> 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. 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. 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
