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

[Peter Maydell]

On 12 April 2017 at 16:02, Harry Wagstaff <address@hidden> 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