On Tue, Jul 28, 2015 at 9:44 AM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
