[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprI
From: |
Cédric Le Goater |
Subject: |
Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController |
Date: |
Tue, 1 Oct 2019 13:43:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 |
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 <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.
>>>
>>> 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.
- Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController, Cédric Le Goater, 2019/10/01
- Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController, David Gibson, 2019/10/01
- Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController, Cédric Le Goater, 2019/10/01
- Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController, David Gibson, 2019/10/01
- Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController,
Cédric Le Goater <=
- Re: [PATCH v2 21/33] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController, David Gibson, 2019/10/01