diff options
author | Greg Kurz <groug@kaod.org> | 2019-05-15 19:04:24 +0200 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2019-05-29 11:39:45 +1000 |
commit | e7f78db9fbb18900c724fd8ebfc46b6962203b98 (patch) | |
tree | 05f22c2836242fff6aee1ca88d2616fc03896763 /scripts/switch-timer-api | |
parent | 77bd8937c03dd55e57cc257951ad07c185303c3e (diff) | |
download | qemu-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