Re: [PATCH] tests/functional: Convert the kvm_xen_guest avocado test

[David Woodhouse]

On Thu, 2024-12-19 at 10:05 -0800, Richard Henderson wrote:
> On 12/19/24 04:56, David Woodhouse wrote:
> > On Thu, 2024-12-19 at 13:24 +0100, Thomas Huth wrote:
> > 
> > > Anyway, to properly track this, I've now created a ticket with the full 
> > > log:
> > > 
> > >    https://gitlab.com/qemu-project/qemu/-/issues/2731
> > 
> > The patch below should fix it. I don't like it very much; it's very
> > much papering over a much bigger generic problem with QEMU's handling
> > of shared interrupts.
> > 
> > Basically, *nothing* should just directly set the system GSIs to
> > "their" desired level with qemu_set_irq(). Each device should feed into
> > a multiplexer which is essentially an OR gate, and the *output* of that
> > mux goes into the actual GSI.
> 
> We have such a device: include/hw/or-irq.h.
> How simple it is to wire that into this machine model is left
> unexplored.

It's not trivial; I think every source feeding interrupts into
x86ms->gsi[] would need to have its own input into one of these OrIRQ
devices. At which point parts of the PCI bus INTx routing start to look
a bit pointless since it's mostly just implementing that function (and
the SCI IRQ for ICH9 is also manually OR'd in).

I wouldn't be entirely averse to embarking on that journey, but it
*still* wouldn't fix VFIO. For that we really do want the other mode,
of invoking callbacks to reassert the IRQ if the device still wants
attention. That would actually be a lot nicer for the Xen GSI case too,
as we'd just resample when the IRQ is acked at the APIC, rather than
constantly having to check whether we should deassert it.

And doing *that* one is even more yak shaving. And would also lead to
fixing the whole MSI routing mess to get cached translations right...

For now, given that the Xen code already *had* a hook in gsi_handler, I
think I can live with the patch I posted.

smime.p7s
Description: S/MIME cryptographic signature