Re: [Qemu-devel] AArch64 QEMU System emulation: issue with TTBR0

[Peter Maydell]

On 2 June 2014 17:16, Claudio Fontana <address@hidden> wrote:
> In particular I get a sync exception when I try to msr to TTBR0_EL1.
>
> The ESR as read in env->cp15.esr_el[1] is 0x8400000e, which looking up
> in the ESR table means
>
> Instruction fault, with IFSC (instruction fault status code) = 0xe,
> which should match
>
> 0b0011LL = permission fault (LL indicates level at which fault occurred).
>
> with LL = 0b10 meaning EL2.

No, "permission fault, second level" doesn't mean EL2, it means
"at the second level of the page table".

In other words, QEMU thinks the page tables you've just pointed
us at are wrong. I suggest sticking a breakpoint in get_phys_addr_lpae()
and walking through it to see what address it's trying to load
and why it thinks the page table walk indicates a permission
fault.

> The code is in particular:
>
> 00000000401db2d0 <mmu::switch_to_runtime_page_tables()>:
>     401db2d0:   d00037a0        adrp    x0, 408d1000 <unique_mtx+0x10>
>     401db2d4:   9130e000        add     x0, x0, #0xc38
>     401db2d8:   f9400000        ldr     x0, [x0]
>     401db2dc:   92748c00        and     x0, x0, #0xfffffffff000
>     401db2e0:   d5182000        msr     ttbr0_el1, x0
>     401db2e4:   d5033fdf        isb
>     401db2e8:   d00037a0        adrp    x0, 408d1000 <unique_mtx+0x10>
>     401db2ec:   9130e000        add     x0, x0, #0xc38
>     401db2f0:   f9400400        ldr     x0, [x0,#8]
>     401db2f4:   92748c00        and     x0, x0, #0xfffffffff000
>     401db2f8:   d5182020        msr     ttbr1_el1, x0
>     401db2fc:   d5033fdf        isb
>     401db300:   d5033f9f        dsb     sy
>     401db304:   d508831f        tlbi    vmalle1is
>     401db308:   d5033f9f        dsb     sy
>     401db30c:   d5033fdf        isb
>     401db310:   d65f03c0        ret
>
> ELR_EL1 in env->elr_el[1] reads as 0x401da200, which is strangely
> enough the address of the first instruction of the exception vector
> entry for sync:

This suggests that we faulted once, and then faulted again
because we couldn't read the insn at the vector entrypoint
either, and you didn't catch the first one in whatever debugger
you're using, only the second. (Were you single-stepping in
gdb? IIRC that has the effect of stopping after trying to
execute the first insn at the exception vector, rather than
before it.)

thanks
-- PMM