aboutsummaryrefslogtreecommitdiff
path: root/include/hw
diff options
context:
space:
mode:
authorGreg Kurz <groug@kaod.org>2020-08-07 13:32:14 +0200
committerDavid Gibson <david@gibson.dropbear.id.au>2020-08-13 20:56:01 +1000
commite519cdd9bc02990bddd395656bdaec821c94c8fe (patch)
treeb01083e18635f1e791f0f2dc16b1318b8f5e4b25 /include/hw
parentcf36e5b3760df0a1fdd38970294cf7b0968fcc5c (diff)
downloadqemu-e519cdd9bc02990bddd395656bdaec821c94c8fe.zip
qemu-e519cdd9bc02990bddd395656bdaec821c94c8fe.tar.gz
qemu-e519cdd9bc02990bddd395656bdaec821c94c8fe.tar.bz2
ppc/xive: Introduce dedicated kvm_irqchip_in_kernel() wrappers
Calls to the KVM XIVE device are guarded by kvm_irqchip_in_kernel(). This ensures that QEMU won't try to use the device if KVM is disabled or if an in-kernel irqchip isn't required. When using ic-mode=dual with the pseries machine, we have two possible interrupt controllers: XIVE and XICS. The kvm_irqchip_in_kernel() helper will return true as soon as any of the KVM device is created. It might lure QEMU to think that the other one is also around, while it is not. This is exactly what happens with ic-mode=dual at machine init when claiming IRQ numbers, which must be done on all possible IRQ backends, eg. RTAS event sources or the PHB0 LSI table : only the KVM XICS device is active but we end up calling kvmppc_xive_source_reset_one() anyway, which fails. This doesn't cause any trouble because of another bug : kvmppc_xive_source_reset_one() lacks an error_setg() and callers don't see the failure. Most of the other kvmppc_xive_* functions have similar xive->fd checks to filter out the case when KVM XIVE isn't active. It might look safer to have idempotent functions but it doesn't really help to understand what's going on when debugging. Since we already have all the kvm_irqchip_in_kernel() in place, also have the callers to check xive->fd as well before calling KVM XIVE specific code. This is straight-forward for the spapr specific XIVE code. Some more care is needed for the platform agnostic XIVE code since it cannot access xive->fd directly. Introduce new in_kernel() methods in some base XIVE classes for this purpose and implement them only in spapr. In all cases, we still need to call kvm_irqchip_in_kernel() so that compilers can optimize the kvmppc_xive_* calls away when CONFIG_KVM isn't defined, thus avoiding the need for stubs. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <159679993438.876294.7285654331498605426.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'include/hw')
-rw-r--r--include/hw/ppc/xive.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index 82a61ea..2f3c5af 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -402,6 +402,7 @@ typedef struct XivePresenterClass {
uint8_t nvt_blk, uint32_t nvt_idx,
bool cam_ignore, uint8_t priority,
uint32_t logic_serv, XiveTCTXMatch *match);
+ bool (*in_kernel)(const XivePresenter *xptr);
} XivePresenterClass;
int xive_presenter_tctx_match(XivePresenter *xptr, XiveTCTX *tctx,