Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController

[David Gibson]

On Tue, Oct 01, 2019 at 07:43:51AM +0200, Cédric Le Goater wrote:
> On 01/10/2019 04:31, David Gibson wrote:
> > On Mon, Sep 30, 2019 at 12:13:14PM +0200, Cédric Le Goater wrote:
> >> On 30/09/2019 08:14, David Gibson wrote:
> >>> On Mon, Sep 30, 2019 at 07:28:45AM +0200, Cédric Le Goater wrote:
> >>>> On 30/09/2019 03:49, David Gibson wrote:
> >>>>> On Fri, Sep 27, 2019 at 12:16:49PM +0200, Greg Kurz wrote:
> >>>>>> On Fri, 27 Sep 2019 15:50:16 +1000
> >>>>>> David Gibson <address@hidden> wrote:
> >>>>>>
> >>>>>>> This method essentially represents code which belongs to the interrupt
> >>>>>>> controller, but needs to be called on all possible intcs, rather than
> >>>>>>> just the currently active one.  The "dual" version therefore calls
> >>>>>>> into the xics and xive versions confusingly.
> >>>>>>>
> >>>>>>> Handle this more directly, by making it instead a method on the intc
> >>>>>>> backend, and always calling it on every backend that exists.
> >>>>>>>
> >>>>>>> While we're there, streamline the error reporting a bit.
> >>>>>>>
> >>>>>>> Signed-off-by: David Gibson <address@hidden>
> >>>>> [snip]
> >>>>>>> @@ -525,6 +469,30 @@ static void spapr_irq_check(SpaprMachineState 
> >>>>>>> *spapr, Error **errp)
> >>>>>>>  /*
> >>>>>>>   * sPAPR IRQ frontend routines for devices
> >>>>>>>   */
> >>>>>>> +int spapr_irq_cpu_intc_create(SpaprMachineState *spapr,
> >>>>>>> +                              PowerPCCPU *cpu, Error **errp)
> >>>>>>> +{
> >>>>>>> +    if (spapr->xive) {
> >>>>>>> +        SpaprInterruptController *intc = SPAPR_INTC(spapr->xive);
> >>>>>>> +        SpaprInterruptControllerClass *sicc = 
> >>>>>>> SPAPR_INTC_GET_CLASS(intc);
> >>>>>>> +
> >>>>>>> +        if (sicc->cpu_intc_create(intc, cpu, errp) < 0) {
> >>>>>>> +            return -1;
> >>>>>>> +        }
> >>>>>>> +    }
> >>>>>>> +
> >>>>>>> +    if (spapr->ics) {
> >>>>>>> +        SpaprInterruptController *intc = SPAPR_INTC(spapr->ics);
> >>>>>>> +        SpaprInterruptControllerClass *sicc = 
> >>>>>>> SPAPR_INTC_GET_CLASS(intc);
> >>>>>>> +
> >>>>>>> +        if (sicc->cpu_intc_create(intc, cpu, errp) < 0) {
> >>>>>>> +            return -1;
> >>>>>>> +        }
> >>>>>>> +    }
> >>>>>>> +
> >>>>>>
> >>>>>> Instead of these hooks, what about open-coding 
> >>>>>> spapr_xive_cpu_intc_create()
> >>>>>> and xics_spapr_cpu_intc_create() directly here, like you already did 
> >>>>>> for the
> >>>>>> ICS and the XIVE objects in spapr_irq_init() ?
> >>>>>
> >>>>> I'd prefer not to.  The idea is I want to treat this as basically:
> >>>>>
> >>>>>         foreach_possible_intc(intc)
> >>>>>                 intc::cpu_intc_create(...)
> >>>>>
> >>>>> If I find time I might indeed replace the explicit ics and xive
> >>>>> pointers with just an array of SpaprInterruptController *.
> >>>>
> >>>> Or you could use object_child_foreach() and check for the type. If we had
> >>>> a helper object_child_foreach_type(), we could use it elsewhere.
> >>>
> >>> I thought about that, but I don't think it quite works.  The
> >>> complication is that the xics device is made explicitly a child of the
> >>> machine, but the xive device has mmio, so it's a SusBusDevice sitting
> >>> on the root bus instead.
> >>
> >> PnvXscom works fine with Devices and SysBusDevices.
> > 
> > Uh... what's an example of it working with a SysBusDevice?  All the
> > implementors of PNV_XSCOM_INTERFACE I could find were instantiated
> > with object_initialize_child() making them explicitly children of the
> > chip.  The SPAPR_XIVE is instantiated with qdev_create(NULL,
> > TYPE_SPAPR_XIVE), making it a child of the root bus, not the machine,
> > I believe.
> 
> I see. We should reparent the interrupt controller then.

Well, maybe.  It's not obvious to me that that's the right approach
just because of this.


> Could we rework 
> the code to instantiate and realize the XICS and XIVE model objects ? 
> We have the handlers spapr_instance_init() and spapr_machine_init(). 

I'm not really sure what you're suggesting here.

> That always has been a problem IMO.
> 
> 
> C. 
>  
> 
> 

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

signature.asc
Description: PGP signature