« Previous | Next » 

Revision c04d6cfa

IDc04d6cfa3f17a335942f430a3d40e6041100f0c2

Added by Anthony Liguori almost 11 years ago

xics: rename types to be sane and follow coding style

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.

Yet we call the "XICS" struct icp_state and then the ICPs
'struct icp_server_state'. It's particularly confusing when all of the
functions have xics_prefixes yet take *icp arguments.

Rename:

struct icp_state -> XICSState
  struct icp_server_state -> ICPState
  struct ics_state -> ICSState
  struct ics_irq_state -> ICSIRQState

Signed-off-by: David Gibson <>
Signed-off-by: Anthony Liguori <>
Signed-off-by: Alexey Kardashevskiy <>
Message-id:
[aik: added ics_resend() on post_load]
Signed-off-by: Alexey Kardashevskiy <>
Signed-off-by: Anthony Liguori <>

Files

  • added
  • modified
  • copied
  • renamed
  • deleted

View differences