Re: [Qemu-devel] [PATCH v7 16/19] spapr: introduce a new sPAPR IRQ backend supporting XIVE and XICS

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

On Wed, Dec 12, 2018 at 10:13:29AM +0100, Cédric Le Goater wrote:
> [ ... ] 
> 
> 
> >>>> +
> >>>> +static qemu_irq spapr_qirq_dual(sPAPRMachineState *spapr, int irq)
> >>>> +{
> >>>> +    return spapr_irq_current(spapr)->qirq(spapr, irq);
> >>>
> >>> Urgh... I don't think this is going to work.  IIRC the various devices
> >>> (PHB, VIO, etc.)  are wired up to their qirqs at realize() time, so if
> >>> you reboot from a XIVE guest to XICS guest (or maybe the other way
> >>> around) the peripherals won't be able to signal irqs in the new
> >>> scheme.
> >>
> >> It does. The IRQ numbers are claimed in both backends.
> > 
> > Yes, I realize that, but the two backends still have their own set of
> > qirqs, which have their own set_irq routines associated with them.
> > 
> >> This is the problem since the very beginning. For reset and migration
> >> to work, we need to keep in sync the IRQ number space of the machine 
> >> and the different interrupt controllers.
> > 
> > Sure, we have the numbers in sync, but that won't help if when the
> > peripherals do a qemu_irq_pulse() it goes to the wrong backend's
> > trigger routine.
> 
> Ah. You mean that the devices could bypass the sPAPR IRQ layer and 
> trigger the IRQ directly from the IRQ controller model ? it's not 
> the case today.

Ah, right, sorry.  We're saved by the fact that basically the only
root level devices for spapr are the PHB and VIO devices, and it so
happens that those look up the relevant qirqs from spapr at interrupt
time, rather than in advance.

I think it's fragile to rely on that - qirqs are supposed to be stable
objects that devices can keep a reference to and use later.

> I agree that having a common set of qirqs and a qemu_irq handler 
> doing the dispatch on the selected interrupt contoller model is 
> good idea. I didn't go in that direction because KVM brings additional 
> head aches.
> 
> Where would put the qirqs ? at the machine level I suppose.

Yes.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]