xics: add pre_save/post_load dispatchers

The upcoming support of in-kernel XICS will redefine migration callbacks
for both ICS and ICP so classes and callback pointers are added.

Signed-off-by: Ale

xics: add pre_save/post_load dispatchers

The upcoming support of in-kernel XICS will redefine migration callbacks
for both ICS and ICP so classes and callback pointers are added.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...

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
regis

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 <david@gibson.dropbear.id.au>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Message-id: 1374175984-8930-12-git-send-email-aliguori@us.ibm.com
[aik: added ics_resend() on post_load]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

show more ...

hw: move headers to include/

Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it n

hw: move headers to include/

Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

pseries: Move XICS initialization before cpu initialization

Currently, the pseries machine initializes the cpus, then the XICS
interrupt controller. However, to support the upcoming in-kernel XICS

pseries: Move XICS initialization before cpu initialization

Currently, the pseries machine initializes the cpus, then the XICS
interrupt controller. However, to support the upcoming in-kernel XICS
implementation we will need to initialize the irq controller before the
vcpus. This patch makes the necesssary rearrangement. This means the
xics init code can no longer auto-detect the number of cpus ("interrupt
servers" in XICS terminology) and so we must pass that in explicitly from
the platform code.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Ben Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...

pseries: Use #define for XICS base irq number

Currently the lowest "real" irq number for the XICS irq controller (as
opposed to numbers reserved for IPIs and other special purposes) is
hard coded as

pseries: Use #define for XICS base irq number

Currently the lowest "real" irq number for the XICS irq controller (as
opposed to numbers reserved for IPIs and other special purposes) is
hard coded as 16 in two places - in xics_system_init() and in spapr.c.

As well as being generally bad practice, we're going to need to change this
number soon to fit in with the in-kernel XICS implementation. This patch
adds a #define for this number to avoid future breakage.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Ben Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...

pseries: Remove XICS irq type enum type

Currently the XICS interrupt controller emulation uses a custom enum to
specify whether a given interrupt is level-sensitive or message-triggered.
This enum m

pseries: Remove XICS irq type enum type

Currently the XICS interrupt controller emulation uses a custom enum to
specify whether a given interrupt is level-sensitive or message-triggered.
This enum makes life awkward for saving the state, and isn't particularly
useful since there are only two possibilities. This patch replaces the
enum with a simple bool.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...

pseries: Rework irq assignment to avoid carrying qemu_irqs around

Currently, the interfaces in the pseries machine code for assignment
and setup of interrupts pass around qemu_irq objects. That was

pseries: Rework irq assignment to avoid carrying qemu_irqs around

Currently, the interfaces in the pseries machine code for assignment
and setup of interrupts pass around qemu_irq objects. That was done
in an attempt not to be too closely linked to the specific XICS
interrupt controller. However interactions with the device tree setup
made that attempt rather futile, and XICS is part of the PAPR spec
anyway, so this really just meant we had to carry both the qemu_irq
pointers and the XICS irq numbers around.

This mess will just get worse when we add upcoming PCI MSI support,
since that will require tracking a bunch more interrupt. Therefore,
this patch reworks the spapr code to just use XICS irq numbers
(roughly equivalent to GSIs on x86) and only retrieve the qemu_irq
pointers from the XICS code when we need them (a trivial lookup).

This is a reworked and generalized version of an earlier spapr_pci
specific patch from Alexey Kardashevskiy.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: fix checkpath warning]
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...

pseries: Add support for level interrupts to XICS

The pseries "xics" interrupt controller, like most interrupt
controllers can support both message (i.e. edge sensitive) interrupts
and level sensiti

pseries: Add support for level interrupts to XICS

The pseries "xics" interrupt controller, like most interrupt
controllers can support both message (i.e. edge sensitive) interrupts
and level sensitive interrupts, but it needs to know which are which.

When I implemented the xics emulation for qemu, the only devices we
supported were the PAPR virtual IO devices. These devices only use
message interrupts, so they were the only ones I implemented in xics.

Since then, however, we have added support for PCI devices, which use
level sensitive interrupts. It turns out the message interrupt logic
still actually works most of the time for these, but there are
circumstances where we can lost interrupts due to the incorrect
interrupt logic.

This patch, therefore, implements the correct xics level-sensitive
interrupt logic. The type of the interrupt is set when a device
allocates a new xics interrupt.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...

pseries: Abolish envs array

Currently the pseries machine init code builds up an array, envs, of
CPUState pointers for all the cpus in the system. This is kind of
pointless, given the generic code

pseries: Abolish envs array

Currently the pseries machine init code builds up an array, envs, of
CPUState pointers for all the cpus in the system. This is kind of
pointless, given the generic code already has a perfectly good linked list
of the cpus.

In addition, there are a number of places which assume that the cpu's
cpu_index field is equal to its index in this array. This is true in
practice, because cpu_index values are just assigned sequentially, but
it's conceptually incorrect and may not always be true.

Therefore, this patch abolishes the envs array, and explicitly uses the
generic cpu linked list and cpu_index values throughout.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...

Implement the PAPR (pSeries) virtualized interrupt controller (xics)

PAPR defines an interrupt control architecture which is logically divided
into ICS (Interrupt Control Presentation, each unit is

Implement the PAPR (pSeries) virtualized interrupt controller (xics)

PAPR defines an interrupt control architecture which is logically divided
into ICS (Interrupt Control Presentation, each unit is responsible for
presenting interrupts to a particular "interrupt server", i.e. CPU) and
ICS (Interrupt Control Source, each unit responsible for one or more
hardware interrupts as numbered globally across the system). All PAPR
virtual IO devices expect to deliver interrupts via this mechanism. In
Linux, this interrupt controller system is handled by the "xics" driver.

On pSeries systems, access to the interrupt controller is virtualized via
hypercalls and RTAS methods. However, the virtualized interface is very
similar to the underlying interrupt controller hardware, and similar PICs
exist un-virtualized in some other systems.

This patch implements both the ICP and ICS sides of the PAPR interrupt
controller. For now, only the hypercall virtualized interface is provided,
however it would be relatively straightforward to graft an emulated
register interface onto the underlying interrupt logic if we want to add
a machine with a hardware ICS/ICP system in the future.

There are some limitations in this implementation: it is assumed for now
that only one instance of the ICS exists, although a full xics system can
have several, each responsible for a different group of hardware irqs.
ICP/ICS can handle both level-sensitve (LSI) and message signalled (MSI)
interrupt inputs. For now, this implementation supports only MSI
interrupts, since that is used by PAPR virtual IO devices.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...