aboutsummaryrefslogtreecommitdiff
path: root/scripts/switch-timer-api
diff options
context:
space:
mode:
authorGreg Kurz <groug@kaod.org>2019-05-15 19:04:24 +0200
committerDavid Gibson <david@gibson.dropbear.id.au>2019-05-29 11:39:45 +1000
commite7f78db9fbb18900c724fd8ebfc46b6962203b98 (patch)
tree05f22c2836242fff6aee1ca88d2616fc03896763 /scripts/switch-timer-api
parent77bd8937c03dd55e57cc257951ad07c185303c3e (diff)
downloadqemu-e7f78db9fbb18900c724fd8ebfc46b6962203b98.zip
qemu-e7f78db9fbb18900c724fd8ebfc46b6962203b98.tar.gz
qemu-e7f78db9fbb18900c724fd8ebfc46b6962203b98.tar.bz2
spapr/xive: Sanity checks of OV5 during CAS
If a machine is started with ic-mode=xive but the guest only knows about XICS, eg. an RHEL 7.6 guest, the kernel panics. This is expected but a bit unfortunate since the crash doesn't provide much information for the end user to guess what's happening. Detect that during CAS and exit QEMU with a proper error message instead, like it is already done for the MMU. Even if this is less likely to happen, the opposite case of a guest that only knows about XIVE would certainly fail all the same if the machine is started with ic-mode=xics. Also, the only valid values a guest can pass in byte 23 of OV5 during CAS are 0b00 (XIVE legacy mode) and 0b01 (XIVE exploitation mode). Any other value is a bug, at least with the current spec. Again, it does not seem right to let the guest go on without a precise idea of the interrupt mode it asked for. Handle these cases as well. Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155793986451.464434.12887933000007255549.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'scripts/switch-timer-api')
0 files changed, 0 insertions, 0 deletions