[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] d7f304: cputlb: don't cpu_abort() if guest tr

From: GitHub
Subject: [Qemu-commits] [qemu/qemu] d7f304: cputlb: don't cpu_abort() if guest tries to execut...
Date: Tue, 28 Jun 2016 11:30:06 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: d7f30403576f04f1f3a5fb5a1d18cba8dfa7a6d2
  Author: Peter Maydell <address@hidden>
  Date:   2016-06-28 (Tue, 28 Jun 2016)

  Changed paths:
    M cputlb.c

  Log Message:
  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 <address@hidden>
Reviewed-by: Richard Henderson  <address@hidden>
Message-id: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]