summaryrefslogtreecommitdiff
path: root/xen-hvm-stub.c
diff options
context:
space:
mode:
authorPeter Maydell <peter.maydell@linaro.org>2016-06-20 18:07:05 +0100
committerPeter Maydell <peter.maydell@linaro.org>2016-06-28 18:50:53 +0100
commitd7f30403576f04f1f3a5fb5a1d18cba8dfa7a6d2 (patch)
tree32669ea07c5e5eef4be73601b2fbcac41416a1cd /xen-hvm-stub.c
parent7dd929dfdc5c52ce79b21bf557ff506e89acbf63 (diff)
downloadqemu-d7f30403576f04f1f3a5fb5a1d18cba8dfa7a6d2.tar.gz
cputlb: don't cpu_abort() if guest tries to execute outside RAM or RAM
In get_page_addr_code(), if the guest program counter turns out not to be in ROM or RAM, we can't handle executing from it, and we call cpu_abort(). This results in the message qemu: fatal: Trying to execute code outside RAM or ROM at 0x08000000 followed by a guest register dump, and then QEMU dumps core. This situation happens in one of two cases: (1) a guest kernel bug, where it jumped off into nowhere (2) a user command line mistake, where they tried to run an image for board A on a QEMU model of board B, or where they didn't provide an image at all, and QEMU executed through a ROM or RAM full of NOP instructions and then fell off the end In either case, a core dump of QEMU itself is entirely useless, and only confuses users into thinking that this is a bug in QEMU rather than a bug in the guest or a problem with their command line. (This is a variation on the general idea that we shouldn't assert() on something the user can accidentally provoke.) Replace the cpu_abort() with something that explains the situation a bit better and exits QEMU without dumping core. (See LP:1062220 for several examples of confused users.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Message-id: 1466442425-11885-1-git-send-email-peter.maydell@linaro.org
Diffstat (limited to 'xen-hvm-stub.c')
0 files changed, 0 insertions, 0 deletions