Re: [PATCH 00/67] KVM: iommu: Overhaul device posted IRQs support

[Sean Christopherson]

On Fri, Apr 18, 2025, David Woodhouse wrote:
> On Fri, 2025-04-04 at 12:38 -0700, Sean Christopherson wrote:
> > 
> > This series is well tested except for one notable gap: I was not able to
> > fully test the AMD IOMMU changes.  Long story short, getting upstream
> > kernels into our full test environments is practically infeasible.  And
> > exposing a device or VF on systems that are available to developers is a
> > bit of a mess.
> 
> If I can make AMD bare-metal "instances" available to you, would that help?

Probably not, my main limitation is time, not lack of hardware.

I'm confident I can get a functional AMD test setup internally, it'll just take
a bit more time/effort (there are other people working on the testing front; I'm
hoping if I wait a bit, someone will solve the hiccups for me).

I'd been holding this series since ~October of last year, precisely due to lack
of bandwidth to configure a working test environment.  I felt that I got far
enough in testing that the odds of something being _really_ broken are small,
and didn't want to delay posting for potentially multiple more months as I assume
other folks in the community already have readily available test setups.

And no matter what, I want to get more thorough testing on a broader range of
hardware, e.g. from Intel and AMD in particular, before this gets merged, so in
the end I don't think me getting access to different hardware would move the
needle much.

Though I appreciate the offer :-)

> Separately, I'd quite like to see the eventfd→MSI delivery linkage not
> use the IRQ routing table at all, and not need a GSI# assigned. Doing
> it that way is just a scaling and performance issue.
> 
> I recently looked through the irqfd code and came to the conclusion
> that it wouldn't be hard to add a new user API which allows us to
> simply configure the kvm_irq_routing_entry to be delivered when a given
> eventfd fires, without using the table.

Yeah, especially if we gated the functionality on a per-VM capability.  That way
kvm_irq_routing_update() could completely skip processing irqfds.  At that point,
other than the new uAPI, I think it's just irqfd_inject() and the resample code
that needs to be modified.

> I haven't had a chance to look hard, hopefully your rework doesn't make
> that any less feasible...

Quite the opposite, it should make it much, much easier.  Currently, both
vmx_pi_update_irte() and avic_pi_update_irte() pull the GSI's routing entry from
kvm->irq_routing.

After this rework, irqfd->irq_entry is explicitly passed into 
kvm_arch_update_irqfd_routing(), i.e. it removes two of the gnarliest paths that
expect irqfd to go through the standard routing table.