aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorJames Hogan <[email protected]>2015-02-06 11:11:56 +0000
committerJames Hogan <[email protected]>2015-03-27 21:25:05 +0000
commit98119ad53376885819d93dfb8737b6a9a61ca0ba (patch)
tree2378ba4c147d05f49ee694082899d220298a6f0f /tools/perf/scripts/python/export-to-postgresql.py
parent8e6c94910320e8ff0f6a4f2fdd809f50289d2852 (diff)
MIPS: KVM: Handle MSA Disabled exceptions from guest
Guest user mode can generate a guest MSA Disabled exception on an MSA capable core by simply trying to execute an MSA instruction. Since this exception is unknown to KVM it will be passed on to the guest kernel. However guest Linux kernels prior to v3.15 do not set up an exception handler for the MSA Disabled exception as they don't support any MSA capable cores. This results in a guest OS panic. Since an older processor ID may be being emulated, and MSA support is not advertised to the guest, the correct behaviour is to generate a Reserved Instruction exception in the guest kernel so it can send the guest process an illegal instruction signal (SIGILL), as would happen with a non-MSA-capable core. Fix this as minimally as reasonably possible by preventing kvm_mips_check_privilege() from relaying MSA Disabled exceptions from guest user mode to the guest kernel, and handling the MSA Disabled exception by emulating a Reserved Instruction exception in the guest, via a new handle_msa_disabled() KVM callback. Signed-off-by: James Hogan <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Paul Burton <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Gleb Natapov <[email protected]> Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v3.15+
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions