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

[Bernhard Beschow]

Am 8. Januar 2025 11:26:57 UTC schrieb David Woodhouse <dwmw2@infradead.org>:
>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?

Thanks for pointing out its existence! I totally expected it to exist under 
hw/core/, next to split-irq. But it resides under hw/, next to irq.c...

>
>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.

Good to know. Thanks!

Best regards,
Bernhard