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
