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: David Gibson
Subject: Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources
Date: Thu, 30 Nov 2017 15:28:57 +1100
User-agent: Mutt/1.9.1 (2017-09-22)

On Wed, Nov 29, 2017 at 05:23:25PM +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 ?

Hrm.  These IVE bits are architected, aren't they?  In which case I'd
be wary of stealing a reserved bit in case of future extensions.

I'm wondering if we want another word / structure for storing
non-architected, implementation specific flags or info.

How does this work at the hardware level?  Presumbly the actual
hardware components don't communicate with the XIVE to request edge or
level.  So how does it know?  Specific ranges for LSIs?  If that we
should probably do the same.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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