Skip to content
  • Peter Maydell's avatar
    d7f30403
    cputlb: don't cpu_abort() if guest tries to execute outside RAM or RAM · d7f30403
    Peter Maydell authored
    
    
    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: default avatarPeter Maydell <peter.maydell@linaro.org>
    Reviewed-by: default avatarRichard Henderson <rth@twiddle.net>
    Message-id: 1466442425-11885-1-git-send-email-peter.maydell@linaro.org
    d7f30403
    cputlb: don't cpu_abort() if guest tries to execute outside RAM or RAM
    Peter Maydell authored
    
    
    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: default avatarPeter Maydell <peter.maydell@linaro.org>
    Reviewed-by: default avatarRichard Henderson <rth@twiddle.net>
    Message-id: 1466442425-11885-1-git-send-email-peter.maydell@linaro.org
Loading