On 17/10/2018 16:14, Michael S. Tsirkin wrote: >>> Thinking about this comment, I would like to ask: can't the >>> virtio device indicate the ranges in a portable way? >>> This would minimize the dependency on dt bindings and ACPI, >>> enabling support for systems that have neither but do >>> have virtio e.g. through pci. >> >> I thought about adding a PROBE request for this in virtio-iommu, but it >> wouldn't be usable by a Linux guest because of a bootstrapping problem. > > Hmm. At some level it seems wrong to design hardware interfaces > around how Linux happens to probe things. That can change at any time > ...
I suspect that most other OS will also solve this class of problem using a standard such as DT or ACPI, because they also provide dependency for clock, interrupts, power management, etc. We can add a self-contained PROBE method if someone makes a case for it, but it's unlikely to get used at all, and nearly impossible to implement in Linux. The host would still need a method to tell the guest which device to probe first, for example with kernel parameters. >> Early on, Linux needs a description of device dependencies, to determine >> in which order to probe them. If the device dependency was described by >> virtio-iommu itself, the guest could for example initialize a NIC, >> allocate buffers and start DMA on the physical address space (which aborts >> if the IOMMU implementation disallows DMA by default), only to find out >> once the virtio-iommu module is loaded that it needs to cancel all DMA and >> reconfigure the NIC. With a static description such as iommu-map in DT or >> ACPI remapping tables, the guest can defer probing of the NIC until the >> IOMMU is initialized. >> >> Thanks, >> Jean > > Could you point me at the code you refer to here? In drivers/base/dd.c, really_probe() calls dma_configure() before the device driver's probe(). dma_configure() ends up calling either of_dma_configure() or acpi_dma_configure(), which return -EPROBE_DEFER if the device's IOMMU isn't yet available. In that case the device is added to the deferred pending list. After another device is successfully bound to a driver, all devices on the pending list are retried (driver_deferred_probe_trigger()), and if the dependency has been resolved, then dma_configure() succeeds. Another method (used by Intel and AMD IOMMU drivers) is to initialize the IOMMU as early as possible, after discovering it in the ACPI tables and before probing other devices. This can't work for virtio-iommu because the driver might be a module, in which case early init isn't possible. We have to defer probe of all dependent devices until the virtio and virtio-iommu modules are loaded. Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
