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
