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
pass-through.
Thanks,
C.
