On Wed, 11 Jan 2023 16:58:37 +0000 David Woodhouse <[email protected]> wrote:
> On Wed, 2023-01-11 at 11:25 -0500, Michael S. Tsirkin wrote: > > On Wed, Jan 11, 2023 at 02:41:58PM +0000, David Woodhouse wrote: > > > This allows drivers to register a callback on a qemu_irq, which is > > > invoked when a level-triggered IRQ is acked on the irqchip. > > > > > > This allows us to simulate level-triggered interrupts more efficiently, > > > by resampling the state of the interrupt only when it actually matters. > > > > I think we tried this with vfio and had to give up on this. > > I don't remember the details though. Alex probably does? > > Hm, not sure why there would be any insurmountable problems. > > I've seen this working at scale in a different VMM with split-irqchip > and PCI INTX + Xen event channel support. > > And it's what the kernel does internally, and exposes through its dual- > eventfd APIs in both KVM IRQ routing and VFIO interrupts. > > That said, I don't care *that* much. I can live with the way I've done > it for the Xen support, by polling the status on a vCPU0 vmexit. > Looking at the VFIO code made me throw up in my mouth a little bit, but > I just won't do that again... :) Nice. IIRC, we ended up with the hack solution we have today in vfio because there was too much resistance to callbacks that were only necessary for vfio in the past. Once we had KVM resampling support, it simply wasn't worth the effort for a higher latency solution to fight that battle, so we implemented what could best be described as a universal workaround embedded in vfio. Clearly a callback is preferable, and yes, that's how we operate with KVM resampling and unmasking INTx, so in theory plumbing this to our existing eoi callback and removing the region toggling ought to do the right thing. Thanks, Alex
