[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [RFC PATCH v2 01/21] ppc/xive: introduce a skeleton for t
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-ppc] [RFC PATCH v2 01/21] ppc/xive: introduce a skeleton for the sPAPR XIVE interrupt controller |
Date: |
Fri, 22 Sep 2017 14:42:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 09/22/2017 01:00 PM, David Gibson wrote:
> On Tue, Sep 19, 2017 at 03:15:44PM +0200, Cédric Le Goater wrote:
>> On 09/19/2017 04:27 AM, David Gibson wrote:
>>> On Mon, Sep 11, 2017 at 07:12:15PM +0200, Cédric Le Goater wrote:
>>>> Start with a couple of attributes for the XIVE sPAPR controller
>>>> model. The number of provisionned IRQ is necessary to size the
>>>> different internal XIVE tables, the number of CPUs is also.
>>>>
>>>> Signed-off-by: Cédric Le Goater <address@hidden>
>>>
>>> [snip]
>>>
>>>> +static void spapr_xive_realize(DeviceState *dev, Error **errp)
>>>> +{
>>>> + sPAPRXive *xive = SPAPR_XIVE(dev);
>>>> +
>>>> + if (!xive->nr_targets) {
>>>> + error_setg(errp, "Number of interrupt targets needs to be greater
>>>> 0");
>>>> + return;
>>>> + }
>>>> + /* We need to be able to allocate at least the IPIs */
>>>> + if (!xive->nr_irqs || xive->nr_irqs < xive->nr_targets) {
>>>> + error_setg(errp, "Number of interrupts too small");
>>>> + return;
>>>> + }
>>>> +}
>>>> +
>>>> +static Property spapr_xive_properties[] = {
>>>> + DEFINE_PROP_UINT32("nr-irqs", sPAPRXive, nr_irqs, 0),
>>>> + DEFINE_PROP_UINT32("nr-targets", sPAPRXive, nr_targets, 0),
>>>
>>> I'm a bit uneasy about the number of targets having to be set in
>>> advance: this can make life awkward when CPUs are hotplugged. I know
>>> there's something similar in xics, but it has caused some hassles, and
>>> we're starting to move away from it.
>>>
>>> Do you really need this?
>>>
>>
>> Some of the internal table size depend on the number of cpus
>> defined for the machine.
>
> Which ones? My impression was that there needed to be at least #cpus
> * #priority-levels EQs, but there could be more than that,
euh no, not in spapr mode at least. There are 8 queues per cpu.
> so it was no longer as tightly bound to the number if "interrupt servers"> as
> xics.
ah. I think I see what you mean, that we could allocate them on the
fly when needed by some hcalls ?
The other place where I use the nr_targets is to provision the
IRQ numbers for the IPIs but that could probably be done in some
other way, specially it there is a IRQ allocator at the machine level.
C.
>> When the sPAPRXive object is instantiated,
>> we use xics_max_server_number() to get the max number of cpus
>> provisioned.
>>
>> C.
>>
>
[Qemu-ppc] [RFC PATCH v2 02/21] migration: add VMSTATE_STRUCT_VARRAY_UINT32_ALLOC, Cédric Le Goater, 2017/09/11
[Qemu-ppc] [RFC PATCH v2 03/21] ppc/xive: define the XIVE internal tables, Cédric Le Goater, 2017/09/11
[Qemu-ppc] [RFC PATCH v2 04/21] ppc/xive: provide a link to the sPAPR ICS object under XIVE, Cédric Le Goater, 2017/09/11