[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f070686a44225d36bc1086dc1643841b3d43d19.camel@infradead.org>
Date: Fri, 18 Apr 2025 14:01:45 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini
<pbonzini@...hat.com>, Joerg Roedel <joro@...tes.org>, Lu Baolu
<baolu.lu@...ux.intel.com>
Cc: kvm@...r.kernel.org, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, Maxim Levitsky <mlevitsk@...hat.com>, Joao
Martins <joao.m.martins@...cle.com>, David Matlack <dmatlack@...gle.com>
Subject: Re: [PATCH 00/67] KVM: iommu: Overhaul device posted IRQs support
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?
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.
I haven't had a chance to look hard, hopefully your rework doesn't make
that any less feasible...
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)
Powered by blists - more mailing lists