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.
