Re: [PATCH] hw/i386/pc: Fix level interrupt sharing for Xen event channel GSI

[David Woodhouse]

On Wed, 2025-01-08 at 09:45 +0000, Bernhard Beschow wrote:
> 
> 
> Am 7. Januar 2025 16:20:28 UTC schrieb David Woodhouse
> <dwmw2@infradead.org>:
> > On Tue, 2025-01-07 at 11:07 -0500, Michael S. Tsirkin wrote:
> > > On Thu, Dec 19, 2024 at 05:24:11PM +0100, David Woodhouse wrote:
> > > > From: David Woodhouse <dwmw@amazon.co.uk>
> > > > 
> > > > The system GSIs are not designed for sharing. One device might
> > > > assert a
> > > > shared interrupt with qemu_set_irq() and another might deassert
> > > > it, and
> > > > the level from the first device is lost.
> > > > 
> > > > This could be solved by using a multiplexer which functions as
> > > > an OR
> > > > gate, much like the PCI code already implements for
> > > > pci_set_irq() for
> > > > muxing the INTx lines.
> 
> Just curious: Why not use that aporoach? Could
> <https://lore.kernel.org/qemu-devel/20250108092538.11474-5-shentey@gm
> ail.com/>
>  help?

That looks very similar to hw/core/or-irq.c which rth pointed out to
me. Is there a reason for both of them existing?

It would be theoretically possible to rework the x86 GSI handling to
use such a thing, yes.

It would be a large yak-shaving task which exceeds the time I currently
have available for a bug fix, but I don't *always* let that stop me.

More to the point though, I *still* wouldn't like the outcome. I still
want us to have a 'resample' callback when the interrupt is
acknowledged in the interrupt controller, to see if any of the inputs
still want the line to be asserted.

That's the only way to handle it efficiently for VFIO INTx and for the
Xen GSI callback anyway.

smime.p7s
Description: S/MIME cryptographic signature