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

[Claudio Fontana <claudio.fontana@huawei.com>]

On 02.06.2014 18:37, Peter Maydell wrote:
> On 2 June 2014 17:16, Claudio Fontana <hw.claudio@gmail.com> 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
> 

Thank you for the clarifications and advice, I think executable permissions might be involved, as removing the NX / PNX check in get_phys_addr_lpae() makes it proceed ahead ([OT: until it dies again trying to read the cpumask from the GIC]),
but I could not find anything really wrong with the PNX setting in OSv (not using NX), but probably more investigation would be needed.

Thanks,

Claudio