> No, it should cause an external abort exception, really.
Ok.
> It's just nobody's needed it (guest OSes should never do anything
> that provokes an external abort unless they're buggy) so nobody's
> bothered doing it yet.
Understood. Thanks.
I'm using QEMU to debug a platform (ARM7TDMI) + OS (eCos) that do not
support a MMU,
so external aborts sometimes occur. The supported ARM946 (which only
has a MPU) is likely
to produce the same type of errors. I guess it is a marginal use of QEMU though.
> Also when it's added various boards need
> testing to see how much they're relying on the current "unassigned
> RAM returns 0" to cover up for missing device models, which
> is a bit tedious given how many boards we have.
Ok. Got it.
There is a piece of code I'm not sure to understand, in
get_page_addr_code(CPUArchState *env1, target_ulong addr)
…
if (unlikely(env1->tlb_table[mmu_idx][page_index].addr_code !=
(addr & TARGET_PAGE_MASK))) {
cpu_ldub_code(env1, addr);
}
pd = env1->iotlb[mmu_idx][page_index] & ~TARGET_PAGE_MASK;
mr = iotlb_to_region(pd);
if (memory_region_is_unassigned(mr))
…
cpu_ldub_code() leads to call io_mem_read() which may trigger a
unassigned_mem_read().
In this case, the invalid mem access is always considered as a data
access, whereas it is an execution access if I'm not mistaken.
In other words, before
get_page_addr_code:memory_region_is_unassigned() is tested and
get_page_addr_code:do_unassigned_access() gets a "chance" to be called
as an "instruction" invalid access, another unsigned access is
triggered with a "data" invalid access.
Did I miss something here?
Would you have any advice on how to stop the execution of the VCPU on
the first invalid memory access (in single step mode)?
Thanks for your help,
Manu.
