[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space |
Date: |
Mon, 18 Jun 2018 19:40:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
On 06/18/2018 02:46 PM, Greg Kurz wrote:
> On Mon, 18 Jun 2018 13:31:26 +0200
> Cédric Le Goater <address@hidden> wrote:
>
>> On 06/18/2018 11:54 AM, Greg Kurz wrote:
>>> On Mon, 18 Jun 2018 10:56:55 +0200
>>> Cédric Le Goater <address@hidden> wrote:
>>>
>>>> [ ... ]
>>>>
>>>>>>> This is 4 irqs per PHB, hence up to 32 PHBs. Cool, we're currently
>>>>>>> limited to 31 PHBs.
>>>>>>>
>>>>>>>> +#define SPAPR_IRQ_MSI 0x1100 /* Offset of the dynamic range
>>>>>>>> covered
>>>>>>>
>>>>>>> We only support dynamic MSIs with PCI, maybe rename to
>>>>>>> SPAPR_IRQ_PCI_MSI ?
>>>>>>
>>>>>> hmm, no. We could have CAPI devices there. remember ? ;)
>>>>>>
>>>>>
>>>>> Well... OpenCAPI devices are exposed to the OS as PCI devices, so I'm not
>>>>> sure we need a CAPI specific range.
>>>>
>>>> yes. so this range is common to all devices doing dynamic allocation
>>>> of IRQs. How should we call it ?
>>>>
>>>>>>>> + * by the bitmap allocator */
>>>>>>>>
>>>>>>>
>>>>>>> The range size is hence 1k (XICS_IRQS_SPAPR) for the time being.
>>>>>>
>>>>>> in fact we could this bogus limit and use spapr->irq_map_nr now.
>>>>>>
>>>>>
>>>>> "we could *missing verb* this bogus limit"... so I'm not sure to
>>>>> understand...
>>>>
>>>> oups. We could use spapr->irq_map_nr instead of XICS_IRQS_SPAPR when
>>>> defining :
>>>>
>>>> _FDT(fdt_setprop_cell(fdt, bus_off, "ibm,pe-total-#msi",
>>>> XICS_IRQS_SPAPR));
>>>>
>>>> in spapr_pci.c
>>>>
>>>
>>> Ah... yeah, I've always found weird that all PHBs advertise the same number
>>> of available MSIs as the total number of irqs for the whole machine. And
>>> putting spapr->irq_map_nr looks weird all the same if all PHBs rely on the
>>> same bitmap actually.
>>>
>>> I'm thinking of doing the other way around: keep XICS_IRQS_SPAPR in
>>> "ibm,pe-total-#msi" and have one XICS_IRQS_SPAPR sized bitmap per PHB.
>>
>> That could be the place where to put the msi allocator.
>>
>
> Are you suggesting to move @irq_map and @irq_map_nr to sPAPRPHBState and
> to have these setup during PHB realize ? I guess we could do that.
Hmm, I think it's better to keep it under the machine. We only need
to define an IRQ number "quantity" per phb and not a specific IRQ
number range. The claimed numbers can be machine wide numbers.
C.
- Re: [Qemu-ppc] [PATCH 2/3] spapr: remove unused spapr_irq routines, (continued)
- [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, Cédric Le Goater, 2018/06/15
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, Greg Kurz, 2018/06/15
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, Cédric Le Goater, 2018/06/15
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, Greg Kurz, 2018/06/18
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, Cédric Le Goater, 2018/06/18
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, Greg Kurz, 2018/06/18
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, Cédric Le Goater, 2018/06/18
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, Greg Kurz, 2018/06/18
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space,
Cédric Le Goater <=
- Re: [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space, David Gibson, 2018/06/18