[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH 10/25] spapr: add MMIO handlers for the XIVE inter

From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources
Date: Sat, 2 Dec 2017 15:47:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 12/02/2017 03:28 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2017-11-29 at 17:23 +0100, Cédric Le Goater wrote:
>> On 11/29/2017 02:56 PM, Cédric Le Goater wrote:
>>>>>>> +    switch (offset) {
>>>>>>> +    case 0:
>>>>>>> +        spapr_xive_source_eoi(xive, lisn);
>>>>>> Hrm.  I don't love that you're dealing with clearing that LSI bit
>>>>>> here, but setting it at a different level.
>>>>>> The state machines are doing my head in a bit, is there any way
>>>>>> you could derive the STATUS_SENT bit from the PQ bits?
>>>>> Yes. I should. 
>>>>> I am also lacking a guest driver to exercise these LSIs so I didn't
>>>>> pay a lot of attention to level interrupts. Any idea ?
>>>> How about an old-school emulated PCI device?  Maybe rtl8139?
>>> Perfect. The current model is working but I will see how I can 
>>> improve it to use the PQ bits instead.
>> Using the PQ bits is simplifying the model but we still have to 
>> maintain an array to store the IRQ type. 
>> There are 3 unused bits in the IVE descriptor, bits[1-3]:  
>>   #define IVE_VALID       PPC_BIT(0)
>>   #define IVE_EQ_BLOCK    PPC_BITMASK(4, 7)        /* Destination EQ block# 
>> */
>>   #define IVE_EQ_INDEX    PPC_BITMASK(8, 31)       /* Destination EQ index */
>>   #define IVE_MASKED      PPC_BIT(32)              /* Masked */
>>   #define IVE_EQ_DATA     PPC_BITMASK(33, 63)      /* Data written to the EQ 
>> */
>> We could hijack one of them to store the LSI type and get rid of 
>> the type array. Would you object to that ? 
> This won't work well if/when you implement a real HW XIVE.
> Another option is to have different source objects for LSIs and MSIs.

yes. Like for the PHB3 in PowerNV or in OPAL.

I will need to complexify the model a bit more with multiple source 
support like we did for PowerNV but that might be interesting for 



reply via email to

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