On 2015-07-28 19:10, Andy Lutomirski wrote: > 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. If one would build a real virtio device today, it would be broken because every IOMMU would start to translate its requests. Already from that POV, we really need to introduce a feature flag "I will be IOMMU-translated" so that a potential physical implementation can carry it unconditionally. > 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. Only the current drivers are broken. And we can easily tell them apart from newer ones via feature flags. Sorry, don't get the problem. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
