[Qemu-devel] [Bug 1682093] [NEW] aarch64-softmmu "bad ram pointer" crash

[Qemu-devel] [Bug 1682093] [NEW] aarch64-softmmu "bad ram pointer" crash

[Harry Wagstaff]

Public bug reported:

I am developing a piece of software called SimBench which is a
benchmarking system for full system simulators. I am currently porting
this to aarch64, using QEMU as a test platform.

I have encountered a 'bad ram pointer' crash. I've attempted to build a
minimum test case, but I haven't managed to replicate the behaviour in
isolation, so I've created a branch of my project which exhibits the
crash: https://bitbucket.org/Awesomeclaw/simbench/get/qemu-bug.tar.gz

The package can be compiled using:

make

and then run using:

qemu-system-aarch64  -M virt -m 512 -cpu cortex-a57 -kernel
out/armv8/virt/simbench -nographic

I have replicated the issue in both qemu 2.8.1 and in 2.9.0-rc3, on
Fedora 23. Please let me know if you need any more information or any
logs/core dumps/etc.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1682093

Title:
  aarch64-softmmu "bad ram pointer" crash

Status in QEMU:
  New

Bug description:
  I am developing a piece of software called SimBench which is a
  benchmarking system for full system simulators. I am currently porting
  this to aarch64, using QEMU as a test platform.

  I have encountered a 'bad ram pointer' crash. I've attempted to build
  a minimum test case, but I haven't managed to replicate the behaviour
  in isolation, so I've created a branch of my project which exhibits
  the crash: https://bitbucket.org/Awesomeclaw/simbench/get/qemu-
  bug.tar.gz

  The package can be compiled using:

  make

  and then run using:

  qemu-system-aarch64  -M virt -m 512 -cpu cortex-a57 -kernel
  out/armv8/virt/simbench -nographic

  I have replicated the issue in both qemu 2.8.1 and in 2.9.0-rc3, on
  Fedora 23. Please let me know if you need any more information or any
  logs/core dumps/etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1682093/+subscriptions

[Qemu-devel] [Bug 1682093] Re: aarch64-softmmu "bad ram pointer" crash

[Harry Wagstaff]

I've done some investigation and it appears that this bug is caused by
the following:

1. The flash memory of the virt platform is initialised as a
cfi.pflash01. It has a memory region with romd_mode = true and
rom_device = true

2. Some code stored in the flash memory is executed. This causes the
memory to be loaded into the TLB.

3. The code is overwritten. This causes the romd_mode of the flash
memory to be reset. It also causes the code to be evicted from the TLB.

4. An attempt is made to execute the code again (cpu_exec(), cpu-exec.c:677)
4a. Eventually, QEMU attempts to refill the TLB (softmmu_template.h:127)
4b. We try to fill in the tlb entry (tlb_set_page_with_attrs, cputlb.c:602)
4b. The flash memory no longer appears to be a ram or romd (cputlb.c:632)
4c. QEMU decides that the flash memory is an IO device (cputlb.c:634)
4d. QEMU aborts while trying to fill in the rest of the TLB entry (qemu_ram_addr_from_host_nofail)

I have built a MWE (which I have attached) which produces this behaviour
in git head. I'm not exactly sure what a fix for this should look like:
AFAIK it's not technically valid to write into flash, but I'm not sure
that QEMU crashing should be considered correct behaviour.

** Attachment added: "mwe.tar.gz"
   https://bugs.launchpad.net/qemu/+bug/1682093/+attachment/4860707/+files/mwe.tar.gz

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1682093

Title:
  aarch64-softmmu "bad ram pointer" crash

Status in QEMU:
  New

Bug description:
  I am developing a piece of software called SimBench which is a
  benchmarking system for full system simulators. I am currently porting
  this to aarch64, using QEMU as a test platform.

  I have encountered a 'bad ram pointer' crash. I've attempted to build
  a minimum test case, but I haven't managed to replicate the behaviour
  in isolation, so I've created a branch of my project which exhibits
  the crash: https://bitbucket.org/Awesomeclaw/simbench/get/qemu-
  bug.tar.gz

  The package can be compiled using:

  make

  and then run using:

  qemu-system-aarch64  -M virt -m 512 -cpu cortex-a57 -kernel
  out/armv8/virt/simbench -nographic

  I have replicated the issue in both qemu 2.8.1 and in 2.9.0-rc3, on
  Fedora 23. Please let me know if you need any more information or any
  logs/core dumps/etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1682093/+subscriptions

Re: [Qemu-devel] [Bug 1682093] Re: aarch64-softmmu "bad ram pointer" crash

[Peter Maydell]

On 12 April 2017 at 16:02, Harry Wagstaff <1682093@bugs.launchpad.net> wrote:
> I've done some investigation and it appears that this bug is caused by
> the following:
>
> 1. The flash memory of the virt platform is initialised as a
> cfi.pflash01. It has a memory region with romd_mode = true and
> rom_device = true
>
> 2. Some code stored in the flash memory is executed. This causes the
> memory to be loaded into the TLB.
>
> 3. The code is overwritten. This causes the romd_mode of the flash
> memory to be reset. It also causes the code to be evicted from the TLB.
>
> 4. An attempt is made to execute the code again (cpu_exec(), cpu-exec.c:677)
> 4a. Eventually, QEMU attempts to refill the TLB (softmmu_template.h:127)
> 4b. We try to fill in the tlb entry (tlb_set_page_with_attrs, cputlb.c:602)
> 4b. The flash memory no longer appears to be a ram or romd (cputlb.c:632)
> 4c. QEMU decides that the flash memory is an IO device (cputlb.c:634)
> 4d. QEMU aborts while trying to fill in the rest of the TLB entry (qemu_ram_addr_from_host_nofail)

Yeah, this is a known bug -- but fixing it would just mean that
we would print the slightly more helpful message about the
guest attempting to execute from something that isn't RAM
or ROM before exiting.

See for instance this thread from January.
https://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg00674.html

> I have built a MWE (which I have attached) which produces this behaviour
> in git head. I'm not exactly sure what a fix for this should look like:
> AFAIK it's not technically valid to write into flash, but I'm not sure
> that QEMU crashing should be considered correct behaviour.

You should fix your guest so that it doesn't try to execute
from flash without putting the flash back into the mode you
can execute from...

Writing to the flash device is permitted -- it's how
you program it (you write command bytes to it, and
read back responses and status and so on).

thanks
-- PMM

[Qemu-devel] [Bug 1682093] Re: aarch64-softmmu "bad ram pointer" crash

[pranith]

** Changed in: qemu
       Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1682093

Title:
  aarch64-softmmu "bad ram pointer" crash

Status in QEMU:
  Invalid

Bug description:
  I am developing a piece of software called SimBench which is a
  benchmarking system for full system simulators. I am currently porting
  this to aarch64, using QEMU as a test platform.

  I have encountered a 'bad ram pointer' crash. I've attempted to build
  a minimum test case, but I haven't managed to replicate the behaviour
  in isolation, so I've created a branch of my project which exhibits
  the crash: https://bitbucket.org/Awesomeclaw/simbench/get/qemu-
  bug.tar.gz

  The package can be compiled using:

  make

  and then run using:

  qemu-system-aarch64  -M virt -m 512 -cpu cortex-a57 -kernel
  out/armv8/virt/simbench -nographic

  I have replicated the issue in both qemu 2.8.1 and in 2.9.0-rc3, on
  Fedora 23. Please let me know if you need any more information or any
  logs/core dumps/etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1682093/+subscriptions