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.
Cheers,
Ben.
>
> C.
