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