From: Peter Maydell <peter.maydell@linaro.org>
To: QEMU Developers <qemu-devel@nongnu.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>,
Patch Tracking <patches@linaro.org>
Subject: Re: [Qemu-devel] [PATCH] cputlb: don't cpu_abort() if guest tries to execute outside RAM or RAM
Date: Tue, 28 Jun 2016 16:42:26 +0100 [thread overview]
Message-ID: <CAFEAcA-psB-zGajHBifYde99DFASMTRa3x5qUy1QFBNxBh5tSw@mail.gmail.com> (raw)
In-Reply-To: <1466442425-11885-1-git-send-email-peter.maydell@linaro.org>
Ping for review?
thanks
-- PMM
On 20 June 2016 at 18:07, Peter Maydell <peter.maydell@linaro.org> wrote:
> 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>
> ---
> I've been meaning to do this for a while now...hopefully the
> expanded error message should reduce user confusion.
>
> cputlb.c | 39 +++++++++++++++++++++++++++++++++++++--
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/cputlb.c b/cputlb.c
> index 23c9b91..079e497 100644
> --- a/cputlb.c
> +++ b/cputlb.c
> @@ -30,6 +30,8 @@
> #include "exec/ram_addr.h"
> #include "exec/exec-all.h"
> #include "tcg/tcg.h"
> +#include "qemu/error-report.h"
> +#include "exec/log.h"
>
> /* DEBUG defines, enable DEBUG_TLB_LOG to log to the CPU_LOG_MMU target */
> /* #define DEBUG_TLB */
> @@ -427,6 +429,39 @@ void tlb_set_page(CPUState *cpu, target_ulong vaddr,
> prot, mmu_idx, size);
> }
>
> +static void report_bad_exec(CPUState *cpu, target_ulong addr)
> +{
> + /* Accidentally executing outside RAM or ROM is quite common for
> + * several user-error situations, so report it in a way that
> + * makes it clear that this isn't a QEMU bug and provide suggestions
> + * about what a user could do to fix things.
> + */
> + error_report("Trying to execute code outside RAM or ROM at 0x"
> + TARGET_FMT_lx, addr);
> + error_printf("This usually means one of the following happened:\n\n"
> + "(1) You told QEMU to execute a kernel for the wrong machine "
> + "type, and it crashed on startup (eg trying to run a "
> + "raspberry pi kernel on a versatilepb QEMU machine)\n"
> + "(2) You didn't give QEMU a kernel or BIOS filename at all, "
> + "and QEMU executed a ROM full of no-op instructions until "
> + "it fell off the end\n"
> + "(3) Your guest kernel has a bug and crashed by jumping "
> + "off into nowhere\n\n"
> + "This is almost always one of the first two, so check your "
> + "command line and that you are using the right type of kernel "
> + "for this machine.\n"
> + "If you think option (3) is likely then you can try debugging "
> + "your guest with the -d debug options; in particular "
> + "-d guest_errors will cause the log to include a dump of the "
> + "guest register state at this point.\n\n"
> + "Execution cannot continue; stopping here.\n\n");
> +
> + /* Report also to the logs, with more detail including register dump */
> + qemu_log_mask(LOG_GUEST_ERROR, "qemu: fatal: Trying to execute code "
> + "outside RAM or ROM at 0x" TARGET_FMT_lx "\n", addr);
> + log_cpu_state_mask(LOG_GUEST_ERROR, cpu, CPU_DUMP_FPU | CPU_DUMP_CCOP);
> +}
> +
> /* NOTE: this function can trigger an exception */
> /* NOTE2: the returned address is not exactly the physical address: it
> * is actually a ram_addr_t (in system mode; the user mode emulation
> @@ -455,8 +490,8 @@ tb_page_addr_t get_page_addr_code(CPUArchState *env1, target_ulong addr)
> if (cc->do_unassigned_access) {
> cc->do_unassigned_access(cpu, addr, false, true, 0, 4);
> } else {
> - cpu_abort(cpu, "Trying to execute code outside RAM or ROM at 0x"
> - TARGET_FMT_lx "\n", addr);
> + report_bad_exec(cpu, addr);
> + exit(1);
> }
> }
> p = (void *)((uintptr_t)addr + env1->tlb_table[mmu_idx][page_index].addend);
> --
> 1.9.1
next prev parent reply other threads:[~2016-06-28 15:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 17:07 [Qemu-devel] [PATCH] cputlb: don't cpu_abort() if guest tries to execute outside RAM or RAM Peter Maydell
2016-06-20 19:16 ` Mark Cave-Ayland
2016-06-20 20:11 ` Peter Maydell
2016-06-28 15:42 ` Peter Maydell [this message]
2016-06-28 17:49 ` Paolo Bonzini
2016-06-28 17:53 ` Peter Maydell
2016-06-28 15:44 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA-psB-zGajHBifYde99DFASMTRa3x5qUy1QFBNxBh5tSw@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=patches@linaro.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).