On Fri, Nov 22, 2019 at 08:00:46AM -0500, Michael S. Tsirkin wrote: > > (2) In addition, there are some concerns about having virtio depend on > > ACPI or DT. Some hypervisors (Firecracker, QEMU microvm, kvmtool x86 > > [1]) > > power? In kvmtool it boot with device tree. It also doesn't need virtio-iommu I think, since it has its own paravirtualized interface. > > don't currently implement those methods. > > > > It was suggested to embed the topology description into the device. > > It can work, as demonstrated at the end of this RFC, with the > > following limitations: > > > > - The topology description must be read before any endpoint managed > > by the IOMMU is probed, and even before the virtio module is > > loaded. This RFC uses a PCI quirk to manually parse the virtio > > configuration. It assumes that all endpoints managed by the IOMMU > > are under this same PCI host. > > > > - I don't have a solution for the virtio-mmio transport at the > > moment, because I haven't had time to modify a host to test it. I > > think it could either use a notifier on the platform bus, or > > better, a new 'iommu' command-line argument to the virtio-mmio > > driver. > > A notifier seems easier for users. What are the disadvantages of > that? For each device we have to check if it's virtio-mmio, then map the MMIO resource and check the device type. Having a dedicated command-line argument would be more efficient. Thanks, Jean
