qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 1/3] spapr: introduce a fixed IRQ number spac


From: Cédric Le Goater
Subject: Re: [Qemu-devel] [PATCH v4 1/3] spapr: introduce a fixed IRQ number space
Date: Fri, 6 Jul 2018 18:43:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 07/06/2018 04:16 PM, Greg Kurz wrote:
> On Fri, 6 Jul 2018 15:27:17 +0200
> Cédric Le Goater <address@hidden> wrote:
> 
>>   > +/*
>>> + * The register property of a VIO device is defined in livirt using a
>>> + * base number + 0x1000 increment and in QEMU by incrementing the base
>>> + * register number 0x71000000.
>>> + *
>>> + * The formula below tries to compute a unique index number from the
>>> + * register value that will be used to define the IRQ number of the
>>> + * VIO device. A maximum of 256 (0x100) VIO devices is covered.
>>> + *
>>> + * To minimize collisions, we define two distinct ranges depending on
>>> + * the "reg" value definition:
>>> + *
>>> + *     [0x00 - 0x7f]    user/libvirt
>>> + *     [0x80 - 0xff]    QEMU VIO model
>>> + *
>>> + * Collisions will be detected when the IRQ is claimed.
>>> + */
>>> +static inline uint32_t spapr_vio_reg_to_irq(uint32_t reg)
>>> +{
>>> +    if (reg >= SPAPR_VIO_REG_BASE) {
>>> +        return SPAPR_IRQ_VIO | (reg & 0x7f) | 0x80;
>>> +    } else {
>>> +        return SPAPR_IRQ_VIO | ((reg & 0x7f) ^ ((reg >> 12) & 0x7f));  
>>
>> This is not good enough for the VIO devices with a user defined "reg".
>>
>> I propose to extract bits [29-28] and [16-12] to compose a 7bit index :
>>
>>      (((reg >> 28) & 0x3) << 5) | ((reg >> 12) & 0x1f)
>>
> 
> Looks good.

Thanks for the investigation you made in libvirt and the tests. 

C. 

> 
>> That would give us a mapping :
>>
>>      0x00000000  -> 0
>>      0x00001000  -> 1
>>              ...
>>      0x0001F000  -> 31
>>      0x10000000  -> 32
>>      0x10001000  -> 33
>>              ...
>>      0x1001F000  -> 63
>>      0x20000000  -> 64
>>      0x20001000  -> 65
>>              ...
>>      0x2001F000  -> 95
>>      0x30000000  -> 96
>>      0x30001000  -> 97
>>              ...
>>      0x3001F000  -> 127
>>
>> C.
>>
>>
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]