aboutsummaryrefslogtreecommitdiff
path: root/hw/core
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2019-09-24 10:53:50 +1000
committerDavid Gibson <david@gibson.dropbear.id.au>2019-10-04 19:08:22 +1000
commitad8de98636e7cadeb1be4efa997cfe2a60bd5c30 (patch)
tree5feb8ddb4ad6b38a4d0e3bec00882e782207d1e5 /hw/core
parent7678b74a94a70186da3b3971d7ae92ca1a81c969 (diff)
downloadqemu-ad8de98636e7cadeb1be4efa997cfe2a60bd5c30.zip
qemu-ad8de98636e7cadeb1be4efa997cfe2a60bd5c30.tar.gz
qemu-ad8de98636e7cadeb1be4efa997cfe2a60bd5c30.tar.bz2
spapr: Clarify and fix handling of nr_irqs
Both the XICS and XIVE interrupt backends have a "nr-irqs" property, but it means slightly different things. For XICS (or, strictly, the ICS) it indicates the number of "real" external IRQs. Those start at XICS_IRQ_BASE (0x1000) and don't include the special IPI vector. For XIVE, however, it includes the whole IRQ space, including XIVE's many IPI vectors. The spapr code currently doesn't handle this sensibly, with the nr_irqs value in SpaprIrq having different meanings depending on the backend. We fix this by renaming nr_irqs to nr_xirqs and making it always indicate just the number of external irqs, adjusting the value we pass to XIVE accordingly. We also move to using common constants in most of the irq configurations, to make it clearer that the IRQ space looks the same to the guest (and emulated devices), even if the backend is different. 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>
Diffstat (limited to 'hw/core')
0 files changed, 0 insertions, 0 deletions