qemu-devel
[Top][All Lists]
Advanced

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

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


From: Cédric Le Goater
Subject: Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources
Date: Wed, 29 Nov 2017 17:23:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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 ? 

C.



reply via email to

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