Thread (5 messages) 5 messages, 3 authors, 2025-06-16

Re: Virtio interrupt remapping

From: Alyssa Ross <hidden>
Date: 2025-06-14 08:12:00
Also in: linux-iommu, linux-pci, lkml

Demi Marie Obenour [off-list ref] writes:
On 6/13/25 14:13, Jean-Philippe Brucker wrote:
quoted
Hi,

On Fri, Jun 13, 2025 at 01:08:07PM -0400, Demi Marie Obenour wrote:
quoted
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.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help