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'.
C.
>> That always has been a problem IMO.
>>
>>
>> C.
>>
>>
>>
>
