> For me that test binary seems to work (with a QEMU built from upstream git commit 893dc8300c80e3dc32f3) : at least it boots and prints various messages ending with "Hello from Thermosphere!"
my bad, I wasn't precise enough. Right now, test binary should display a crash dump (=> exceptions.c) following __builtin_trap() but doesn't. Here is what happens: Expected behavior: code steps into $VBAR_EL2+0x200, $VBAR_EL2 being reported to be its expected value Actual behavior: code steps into 0+0x200 (gdb) disas Dump of assembler code for function main: 0x00000000600000e8 <+0>: ldr w1, [x18, #16] 0x00000000600000ec <+4>: str x30, [sp, #-16]! 0x00000000600000f0 <+8>: cbnz w1, 0x60000110 <main+40> 0x00000000600000f4 <+12>: mov w0, #0xc200 // #49664 0x00000000600000f8 <+16>: movk w0, #0x1, lsl #16 0x00000000600000fc <+20>: bl 0x60000d10 <uartInit> 0x0000000060000100 <+24>: adrp x0, 0x60001000 <unknown_exception> 0x0000000060000104 <+28>: add x0, x0, #0x8be 0x0000000060000108 <+32>: bl 0x60000128 <serialLog> => 0x000000006000010c <+36>: brk #0x3e8 0x0000000060000110 <+40>: adrp x0, 0x60001000 <unknown_exception> 0x0000000060000114 <+44>: add x0, x0, #0x8d8 0x0000000060000118 <+48>: bl 0x60000128 <serialLog> 0x000000006000011c <+52>: mov w0, #0x0 // #0 0x0000000060000120 <+56>: ldr x30, [sp], #16 0x0000000060000124 <+60>: ret End of assembler dump. (gdb) stepi ^C Thread 1 received signal SIGINT, Interrupt. 0x0000000000000200 in ?? () (gdb) p $VBAR_EL2 $10 = 0x60001000 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838277 Title: qemu-system-aarch64: regression: TCG sometimes using wrong values for VBAR_EL2 despite it being correctly reported to GDB Status in QEMU: New Bug description: Affects 3.1.0 (latest stable release) and latest commit (893dc8300c80e3dc32f31e968cf7aa0904da50c3) but did *not* affect 2.11 (qemu from bionic ubuntu LTS). With the following code and shell commands: test.s: .text mov x0, #0x60000000 msr vbar_el2, x0 dsb sy isb sy $ aarch64-none-elf-as test.s -o test.o $ aarch64-none-elf-objcopy -S -O binary test.o test.bin $ qemu-system-aarch64 -nographic -machine virt,virtualization=on -cpu cortex-a57 -kernel test.bin -s -S vbar_el2 is still 0 after the code, instead of being the expected 0x60000000. (see screenshot). This regression doesn't seem to happen for vbar_el1 & virtualization=off. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838277/+subscriptions