[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 10:56:55 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
[ ... ]
>>> 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
[ ... ]
>>>> + if (spapr->xics_legacy) {
>>>> + dev->irq = spapr_irq_findone(spapr, &local_err);
>>>> + if (local_err) {
>>>> + error_propagate(errp, local_err);
>>>> + return;
>>>> + }
>>>> + } else {
>>>> + dev->irq = SPAPR_IRQ_VIO + vio_index++;
>>>
>>> This can overlap the next range if we have more than 64 VIO devices...
>>
>> yes. but claim() should fail.
>>
>
> Hmm... I have the impression claim() only fails if:
> - irq < ics->offset (ie, XICS_IRQ_BASE == 4096)
> - or irq >= ics->offset + ics->nr_irqs (ie, XICS_IRQS_SPAPR == 1024)
> - or irq is already in use
>
> I can't find code that would prevent dev->irq to reach SPAPR_IRQ_MSI.
Ah yes. It can overlap.
My previous proposal took care of overlaps but something simpler was
requested. That's how I understand it at least. We can introduce
a maximum for the VIO range or live with it.
C.
- Re: [Qemu-ppc] [PATCH 1/3] spapr: split the IRQ allocation sequence, (continued)
[Qemu-ppc] [PATCH 2/3] spapr: remove unused spapr_irq routines, Cédric Le Goater, 2018/06/15
[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 <=
- 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, David Gibson, 2018/06/18