Demi Marie Obenour <demiobenour@xxxxxxxxx> writes: > On 6/13/25 14:13, Jean-Philippe Brucker wrote: >> Hi, >> >> On Fri, Jun 13, 2025 at 01:08:07PM -0400, Demi Marie Obenour wrote: >>> I’m working on virtio-IOMMU interrupt remapping for Spectrum OS [1], >>> and am running into a problem. All of the current interrupt remapping >>> drivers use __init code during initialization, and I’m not sure how to >>> plumb the struct virtio_device * into the IOMMU initialization code. >>> >>> What is the proper way to do this, where “proper” means that it doesn’t >>> do something disgusting like “stuff the virtio device in a global >>> variable”? >> >> I'm not familiar at all with interrupt remapping, but I suspect a major >> hurdle will be device probing order: the PCI subsystem probes the >> virtio-pci transport device relatively late during boot, and the virtio >> driver probes the virtio-iommu device afterwards, at which point we can >> call viommu_probe() and inspect the device features and config. This can >> be quite late in userspace if virtio and virtio-iommu get loaded as >> modules (which distros tend to do).> >> The way we know to hold off initializing dependent devices before the >> IOMMU is ready is by reading the firmware tables. In devicetree the >> "msi-parent" and "msi-map" properties point to the interrupt remapping >> device, so by reading those Linux knows to wait for the probe of the >> remapping device before setting up those endpoints. The ACPI VIOT >> describes this topology as well, although at the moment it does not have >> separate graphs for MMU and interrupts, like devicetree does (could >> probably be added to the spec if needed, but I'm guessing the topologies >> may be the same for a VM). If the interrupt infrastructure supports >> probe deferral, then that's probably the way to go. > > I don't see any examples of probe deferral in the codebase. Would it > instead be possible to require virtio-iommu (and thus virtio) to be > built-in rather than modules? It's certainly possible to have an optional feature in the kernel that depends on a module being built in where it otherwise wouldn't have to be.
Attachment:
signature.asc
Description: PGP signature
