On Tue, Sep 30, 2014 at 10:53 AM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: >> 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. If you boot a Xen PV dom0 on QEMU master with -machine q35,iommu=on and you add a virtio device, dom0 will end up with a PCI device that does DMA to "machine" addresses. These addresses are not compatible with the DMA API (which works with bus addresses), nor are they the same as physical addresses. So virtio in current kernels won't work for the same reason they never work on Xen. But virtio-pci with my patches won't work either, because they (or the Xen hypervisor) will try to program the IOMMU with a non-identity mapping, causing everything to explode. Hacking up the virtio-pci driver to explicitly ask Xen for machine addresses might work, but, at the very least, it will be a giant security hole if anyone binds a virtio device to a domain other than dom0 (which, again, is kind of the point of having an IOMMU). >> >> 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) By "paravirt" I meant PV, where there's the weird physical/machine address discrepancy that's visible to the guest. This is not to say that Xen PVH wouldn't also be screwed running on QEMU master. --Andy _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
