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

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

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

On Tue, Oct 01, 2019 at 01:43:12PM +0200, Cédric Le Goater wrote:
> On 01/10/2019 10:11, David Gibson wrote:
> > On Tue, Oct 01, 2019 at 09:41:27AM +0200, Cédric Le Goater wrote:
> >> On 01/10/2019 08:47, David Gibson wrote:
> >>> 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 <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au>
> >>>>>>>>> [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.
> >>
> >> Define the device model objects under the machine and not pointers :
> >>
> >> 	struct SpaprMachineState {
> >> 		...
> >> 		ICSState ics;
> >> 		SpaprXive  xive;
> >> 		...
> >> 	};
> >>
> >> in spapr_instance_init() :
> >>
> >> 	object_initialize_child(obj, "ics",  &spapr->ics, sizeof(spapr->ics),
> >>                             TYPE_ICS, &error_abort, NULL);
> >> 	object_property_add_const_link(OBJECT(&spapr->ics), "xics", obj,
> >>                                    &error_abort);
> >>
> >> 	object_initialize_child(obj, "xive",  &spapr->xive, sizeof(spapr->xive),
> >>                             TYPE_SPAPR_XIVE, &error_abort, NULL);
> >>
> >>
> >> in spapr_machine_init(), call the realize handler depending on the chosen 
> >> 'ic-mode'.
> > 
> > Hm, yeah, maybe.  I don't love having a whole structure in there
> > that's unused when ic-mode != dual.
> > 
> 
> This is the pattern followed in the ARM SoC models. Enough room is 
> provisioned for the maximum controllers and depending on the SoC
> configuration only some are realized.

Hm, ok, I guess that makes it a pretty promising approach.  Maybe for
another day though.  In the meantime I've come up with an approach
that's not totally elegant, but it does remove the duplication of the
paths for xics vs. xive, keep the individual pointers in the structure
for now, and isn't *too* verbose.

I've stripped your R-b due to the change, so please have a look in the
next spin.

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