diff options
author | Peter Maydell <peter.maydell@linaro.org> | 2016-06-20 18:07:05 +0100 |
---|---|---|
committer | Peter Maydell <peter.maydell@linaro.org> | 2016-06-28 18:50:53 +0100 |
commit | d7f30403576f04f1f3a5fb5a1d18cba8dfa7a6d2 (patch) | |
tree | 32669ea07c5e5eef4be73601b2fbcac41416a1cd /hw/s390x | |
parent | 7dd929dfdc5c52ce79b21bf557ff506e89acbf63 (diff) | |
download | qemu-d7f30403576f04f1f3a5fb5a1d18cba8dfa7a6d2.zip qemu-d7f30403576f04f1f3a5fb5a1d18cba8dfa7a6d2.tar.gz qemu-d7f30403576f04f1f3a5fb5a1d18cba8dfa7a6d2.tar.bz2 |
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 'hw/s390x')
0 files changed, 0 insertions, 0 deletions