On 18 August 2016 at 16:10, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 16 August 2016 at 13:08, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> Bad ram pointer 0x54 >> Aborted (core dumped) > > So the reason this happens is that get_page_addr_code() doesn't > correctly handle the case of the memory region being a > ROM that's not in ROMD mode. That is, the flash memory can > be either in "reads map directly to guest memory" (normal) > mode or "reads are MMIO to a device" (ROMD) mode. QEMU > can't execute from devices, so the best case here would > be that we print the "Sorry, we can't execute from a device" > message and stop execution. >
So is there a spurious write somewhere that causes the ROM to switch into ROMD mode? Because it executes happily from ROM (until it doesn't, of course) > Treating the flash device's "return the current status" > bytes as code probably wasn't what you wanted to do anyway :-) > > In more detail: when we call get_page_addr_code() for this > address, we notice that there is no TLB entry for it, and > so we call cpu_ldub_code() which is supposed to fill the TLB. > This ends up calling tlb_set_page_with_attrs(), which for a > not-RAM-not-ROMD MR will set the addend to 0 and then OR > TLB_MMIO into the address field (rather than setting the > addend to the right offset to get between the guest > address and the host RAM address). get_page_addr_code() > unfortunately then uses a different condition when it > distinguishes "is this an IO address we can't handle" > from "is this RAM", which means it takes the path for > "treat the addend as the offset between guest and host", > resulting in a completely bogus host address. > OK, so that sounds like something that should be fixable. But I still don't understand if the guest code is doing anything wrong.