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