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

[Cédric Le Goater]

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, 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(). 

That always has been a problem IMO.


C.