[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v5 1/3] spapr: introduce a fixed IRQ number space
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-ppc] [PATCH v5 1/3] spapr: introduce a fixed IRQ number space |
Date: |
Mon, 30 Jul 2018 11:05:58 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
On 07/27/2018 05:56 AM, David Gibson wrote:
> On Thu, Jul 26, 2018 at 03:37:21PM +0200, Cédric Le Goater wrote:
>> This proposal introduces a new IRQ number space layout using static
>> numbers for all devices, depending on a device index, and a bitmap
>> allocator for the MSI IRQ numbers which are negotiated by the guest at
>> runtime.
>>
>> As the VIO device model does not have a device index but a "reg"
>> property, we introduce a formula to compute an IRQ number from a "reg"
>> value. It should minimize most of the collisions.
>>
>> The previous layout is kept in pre-3.1 machines raising the
>> 'legacy_irq_allocation' machine class flag.
>>
>> Signed-off-by: Cédric Le Goater <address@hidden>
>
> One nit left..
>
> [snip]
>> +static inline uint32_t spapr_vio_reg_to_irq(uint32_t reg)
>> +{
>> + uint32_t irq;
>> +
>> + if (reg >= SPAPR_VIO_REG_BASE) {
>> + /*
>> + * VIO device register values when allocated by QEMU. For
>> + * these, we simply mask the high bits to fit the overall
>> + * range: [0x00 - 0xff].
>> + *
>> + * The nvram VIO device (reg=0x71000000) is a static device of
>> + * the pseries machine and so is always allocated by QEMU. Its
>> + * IRQ number is 0x0.
>> + */
>> + irq = reg & 0xff;
>> +
>> + } else if (reg >= 0x30000000) {
>> + /*
>> + * VIO tty devices register values, when allocated by livirt,
>> + * are mapped in range [0xf0 - 0xff], gives us a maximum of 16
>> + * vtys.
>> + */
>> + irq = 0xf0 | ((reg >> 12) & 0xf);
>> +
>> + } else {
>> + /*
>> + * Other VIO devices register values, when allocated by
>> + * livirt, are mapped in range [0x00 - 0xef].
>> + */
>> + irq = (reg >> 12) & 0xef;
>
> This mask doesn't do what you intend - it will map 0x10 to 0, for
> example. You could use % 0xf0, but actually you might as well just
> use & 0xff. Yes, it could collide with the vty devices, but either
> way you can still have collisions if you try hard enough. And, either
> way, they'll get detected later.
>
David,
Shall I resend a v6 with this fix or should I wait for the patch adding
3.1. I could also send a 3.1 pseries machine also if you prefer.
Thanks,
C.
[Qemu-ppc] [PATCH v5 3/3] spapr: increase the size of the IRQ number space, Cédric Le Goater, 2018/07/26