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 <da...@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 <da...@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. C.