>>>> + 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.
I also found a couple of issues on the way.
We do need the "#interrupt-cells" and "interrupt-controller"
properties. They are missing from the XIVE sPAPR specs but there
is no other way to find the parent controller for the LSIs ...
I have re-asked the pHyp team to include them in the specs and
fixed the QEMU model.
Linux thinks the interrupt type is an "edge" and not a "level" one :
(initramfs) cat /proc/interrupts
CPU0
16: 0 XIVE-IPI 0 Edge IPI
17: 14 XIVE-IRQ 4100 Edge enp0s0
18: 0 XIVE-IRQ 4097 Edge RAS_HOTPLUG
19: 0 XIVE-IRQ 4096 Edge RAS_EPOW
20: 20 XIVE-IRQ 4098 Edge hvc_console
and XIVE complains :
[ 8.319970] xive: Interrupt 17 (HW 0x1004) type mismatch, Linux says Edge,
FW says Level
I am digging this one.
Thanks.
C.
