Naresh Kamboju naresh.kamboju@linaro.org writes:
The QEMU-arm64 boot has failed with the Linux next-20241017 tag. The boot log is incomplete, and no kernel crash was detected. However, the system did not proceed far enough to reach the login prompt.
Please find the incomplete boot log links below for your reference. The Qemu version is 9.0.2. The arm64 devices boot pass.
Can confirm it also fails on the current master of QEMU:
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007ffff4a3ae9f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 0x00007ffff49ebfb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff49d6472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x00007ffff6e47ec8 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007ffff6ea7e1a in g_assertion_message_expr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x0000555555f45732 in regime_is_user (env=0x555557f805f0, mmu_idx=ARMMMUIdx_E10_0) at ../../target/arm/internals.h:978 #7 0x0000555555f5b0f1 in aa64_va_parameters (env=0x555557f805f0, va=18446744073709551615, mmu_idx=ARMMMUIdx_E10_0, data=true, el1_is_aa32=false) at ../../target/arm/helper.c:12048 #8 0x0000555555f4e3e5 in tlbi_aa64_get_range (env=0x555557f805f0, mmuidx=ARMMMUIdx_E10_0, value=107271103184929) at ../../target/arm/helper.c:5214 #9 0x0000555555f4e5a4 in do_rvae_write (env=0x555557f805f0, value=107271103184929, idxmap=21, synced=true) at ../../target/arm/helper.c:5260 #10 0x0000555555f4e6d9 in tlbi_aa64_rvae1is_write (env=0x555557f805f0, ri=0x555557ffda90, value=107271103184929) at ../../target/arm/helper.c:5302 #11 0x00005555560553c8 in helper_set_cp_reg64 (env=0x555557f805f0, rip=0x555557ffda90, value=107271103184929) at ../../target/arm/tcg/op_helper.c:965 #12 0x00007fff60fc3939 in code_gen_buffer ()
while with:
./qemu-system-aarch64 \ -machine type=virt,virtualization=on,gic-version=3,mte=on \ -cpu max,pauth-impdef=on \ -smp 4 \ -accel tcg \ -serial mon:stdio \ -m 8192 \ -kernel /home/alex/lsrc/qemu.git/builds/all/Image -append "root=/dev/sda2 console=ttyAMA0 kvm-arm.mode=protected earlycon" \ -display none
Specifically kvm-arm.mode=protected has to be on.
With more detail I can see:
(gdb) p/x value $1 = 0x619000000021 (gdb) p *ri $2 = {name = 0x555557ffdb28 "TLBI_RVAALE1IS", cp = 19 '\023', crn = 8 '\b', crm = 2 '\002', opc0 = 1 '\001', opc1 = 0 '\000', opc2 = 7 '\a', state = ARM_CP_STATE_AA64, type = 1024, access = PL1_W, secure = ARM_CP_SECSTATE_NS, fgt = FGT_TLBIRVAALE1IS, nv2_redirect_offset = 0, opaque = 0x0, resetvalue = 0, fieldoffset = 0, bank_fieldoffsets = {0, 0}, accessfn = 0x555555f46703 <access_ttlbis>, readfn = 0x0, writefn = 0x555555f4e6a2 <tlbi_aa64_rvae1is_write>, raw_readfn = 0x0, raw_writefn = 0x0, resetfn = 0x0, orig_readfn = 0x0, orig_writefn = 0x0, orig_accessfn = 0x0}
It seems the asset fires because:
case ARMMMUIdx_E10_0: case ARMMMUIdx_E10_1: case ARMMMUIdx_E10_1_PAN: g_assert_not_reached();
But the function:
static int vae1_tlbmask(CPUARMState *env) { uint64_t hcr = arm_hcr_el2_eff(env); uint16_t mask;
if ((hcr & (HCR_E2H | HCR_TGE)) == (HCR_E2H | HCR_TGE)) { mask = ARMMMUIdxBit_E20_2 | ARMMMUIdxBit_E20_2_PAN | ARMMMUIdxBit_E20_0; } else { mask = ARMMMUIdxBit_E10_1 | ARMMMUIdxBit_E10_1_PAN | ARMMMUIdxBit_E10_0; } return mask; }
returns that while handling tlbi_aa64_rvae1is_write(). I don't have an Arm ARM handy with me in the airport. Peter/Richard can you check what the logic should be and if this is a QEMU bug or the kernel doing something it shouldn't?