qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH v2 03/19] spapr: introduce the XIVE interrupt sour


From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [PATCH v2 03/19] spapr: introduce the XIVE interrupt sources
Date: Wed, 20 Dec 2017 19:08:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 12/20/2017 08:54 AM, Cédric Le Goater wrote:
> On 12/20/2017 06:22 AM, David Gibson wrote:
>> On Sat, Dec 09, 2017 at 09:43:22AM +0100, Cédric Le Goater wrote:
>>> Each XIVE interrupt source is associated with a two bit state machine
>>> called an Event State Buffer (ESB) : the first bit "P" means that an
>>> interrupt is "pending" and waiting for an EOI and the bit "Q" (queued)
>>> means a new interrupt was triggered while another was still pending.
>>>
>>> When an event is triggered, the associated interrupt state bits are
>>> fetched and modified and forwarded to the virtualization engine of the
>>> controller doing the routing. These can also be controlled by MMIO, to
>>> trigger events or turn off the sources for instance. See code for more
>>> details on the states and transitions.
>>>
>>> The MMIO space for the ESBs is 512GB large on the bare-metal system
>>> (PowerNV) and the BAR depends on the chip id. In our model for the
>>> sPAPR machine, we choose to only map the sub-region for the
>>> provisioned IRQ numbers and to use the mapping address of chip 0 of a
>>> real system.
>>
>> I think we probably want a device property to make the virtualized
>> base address arbitrary.  It's fine for it to default to the chip 0
>> base, but that'll make it easier to adapt if we need to later on.
> 
> yes. We can add a "bar" property for this purpose like for some of 
> the pnv models
> 
>> As noted in the followup messages, I think you're going to want to
>> move this stuff from the current xive object into a "block of sources"
>> object.

I have (re)introduced a XiveSource object. Only a single instance, and 
under the sPAPRXive object (because it is easier to create). Adding a 
source list should not be too problematic if needed. 

So the XiveSource is generic and I hope to be able to do the same for 
the presenter. 

Just like for XICS, I am also adding a :

        typedef struct XiveFabricClass {
            InterfaceClass parent;
            void (*notify)(XiveFabric *xive, int lisn);
        } XiveFabricClass;

which we can use for both the pnv and pseries machines, but the fabric 
is not the machine itself, it is the Xive routing engine, an object 
below.

C.



reply via email to

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