spapr: Formalize notion of active interrupt controller
commit81106ddd1aee5c06e390eaffb07f857f925628f4
authorDavid Gibson <david@gibson.dropbear.id.au>
Thu, 26 Sep 2019 05:41:39 +0000 (26 15:41 +1000)
committerDavid Gibson <david@gibson.dropbear.id.au>
Wed, 23 Oct 2019 22:36:55 +0000 (24 09:36 +1100)
tree6623bcc6770d775fecfb05e2840b35233476efc0
parent0b0e52b1317f2a51704cbf32047864869763dea3
spapr: Formalize notion of active interrupt controller

spapr now has the mechanism of constructing both XICS and XIVE instances of
the SpaprInterruptController interface.  However, only one of the interrupt
controllers will actually be active at any given time, depending on feature
negotiation with the guest.  This is handled in the current code via
spapr_irq_current() which checks the OV5 vector from feature negotiation to
determine the current backend.

Determining the active controller at the point we need it like this
can be pretty confusing, because it makes it very non obvious at what
points the active controller can change.  This can make it difficult
to reason about the code and where a change of active controller could
appear in sequence with other events.

Make this mechanism more explicit by adding an 'active_intc' pointer
and an explicit spapr_irq_update_active_intc() function to update it
from the CAS state.  We also add hooks on the intc backend which will
get called when it is activated or deactivated.

For now we just introduce the switch and hooks, later patches will
actually start using them.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
hw/ppc/spapr_irq.c
include/hw/ppc/spapr.h
include/hw/ppc/spapr_irq.h