[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.
- Re: [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller, (continued)
[Qemu-ppc] [PATCH v2 03/19] spapr: introduce the XIVE interrupt sources, Cédric Le Goater, 2017/12/09
Re: [Qemu-ppc] [PATCH v2 03/19] spapr: introduce the XIVE interrupt sources, David Gibson, 2017/12/20
[Qemu-ppc] [PATCH v2 04/19] spapr: add support for the LSI interrupt sources, Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 05/19] spapr: introduce a XIVE interrupt presenter model, Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 06/19] spapr: introduce the XIVE Event Queues, Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 07/19] spapr: push the XIVE EQ data in OS event queue, Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 08/19] spapr: notify the CPU when the XIVE interrupt priority is more privileged, Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 09/19] spapr: add support for the SET_OS_PENDING command (XIVE), Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 10/19] spapr: introduce a 'xive_exploitation' boolean to enable XIVE, Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 11/19] spapr: add a sPAPRXive object to the machine, Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 12/19] spapr: add hcalls support for the XIVE exploitation interrupt mode, Cédric Le Goater, 2017/12/09
[Qemu-ppc] [PATCH v2 13/19] spapr: add device tree support for the XIVE interrupt mode, Cédric Le Goater, 2017/12/09