[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS

From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS
Date: Tue, 09 Jul 2013 14:48:48 +1000

On Tue, 2013-07-09 at 13:40 +1000, Alexey Kardashevskiy wrote:
> No, why? It is a per CPU state of XICS controller, never exists apart
> from XICS.

ICP is. ICS is  ... different but can mostly be considered to be the
XICS itself.

Anthony, we could be completely anal about it and create a gigantic
cathedral of devices or just be a bit realistic and do something simpler
that has the exact same functionality :)

Basically, in HW the layout of the interrupt network is:

 - One ICP per processor thread (the "presenter"). This contains the
registers to fetch a pending interrupt (ack), EOI, and control the
processor priority.

 - One ICS per logical source of interrupts (ie, one per PCI host
bridge, and a few others here or there). This contains the per-interrupt
source configuration (target processor(s), priority, mask) and the
per-interrupt internal state.

Under PAPR, there is a single "virtual" ICS ... somewhat (it's a bit
oddball what pHyp does here, arguably there are two but we can ignore
that distinction). There is no register level access. A pair of firmware
(RTAS) calls is used to configure each virtual interrupt.

So our model here is somewhat the same. We have one ICS in the emulated
XICS which arguably *is* the emulated XICS, there's no point making it a
separate "device", that would just be gross, and each VCPU has an
associated ICP.


reply via email to

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