> 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
