Naresh Kamboju <naresh.kamb...@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?
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
