On Tue, Jul 28, 2015 at 9:44 AM, Jan Kiszka <jan.kis...@siemens.com> wrote: > The ability to have virtio on systems with IOMMU in place makes testing > much more efficient for us. Ideally, we would have it in non-identity > mapping scenarios as well, e.g. to start secondary Linux instances in > the test VMs, giving them their own virtio devices. And we will > eventually have this need on ARM as well. > > Virtio needs to be backward compatible, so the change to put these > devices under IOMMU control could be advertised during feature > negotiations and controlled on QEMU side via a device property. Newer > guest drivers would have to acknowledge that they support virtio via > IOMMUs. Older ones would refuse to work, and the admin could instead > spawn VMs with this feature disabled. >
The trouble is that this is really a property of the bus and not of the device. If you build a virtio device that physically plugs into a PCIe slot, the device has no concept of an IOMMU in the first place. Similarly, if you take an L0-provided IOMMU-supporting device and pass it through to L2 using current QEMU on L1 (with Q35 emulation and iommu enabled), then, from L2's perspective, the device is 1:1 no matter what the device thinks. IOW, I think the original design was wrong and now we have to deal with it. I think the best solution would be to teach QEMU to fix its ACPI tables so that 1:1 virtio devices are actually exposed as 1:1. --Andy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
