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