Right, so basically I was working on https://github.com/Atmosphere- NX/Atmosphere/tree/hyp/thermosphere (make PLATFORM=qemu qemudbg). This uses Arm Trusted Firmware.
While gdb now reports $VBAR_EL2 correctly (as opposed to what the title says), I observed the following effects: - at least before I fixed a bug in my exception handlers, I needed to add this JIT workaround I found by accident: https://github.com /Atmosphere-NX/Atmosphere/blob/hyp/thermosphere/src/start.s#L62 to get to main. Otherwise mov sp, x8 (with x8 aligned) crashed for no reason. - VBAR_EL2 is/was loaded before msr VBAR_EL2, x8 despite data and instruction barriers - From 3.1 onwards (or after 2.11): VBAR_EL2 is correctly reported (p $VBAR_EL2 gives $1 = 0x60001000 as exepected, and the read value of PSTATE is 0x3c5) but **QEMU acts as if VBAR_EL2 was 0** depending on crash site (but still reports it correctly when jumping to 0+0x200) (there's a __builtin_trap() call in function main) Attached elf and binary & built Arm TF build. Run flags: -nographic -machine virt,secure=on,virtualization=on,gic-version=2 -cpu cortex-a57 -smp 4 -m 1024 -bios bl1.bin -d unimp -semihosting-config enable,target=native -serial mon:stdio ** Attachment added: "program triggering jit bug" https://bugs.launchpad.net/qemu/+bug/1838277/+attachment/5279996/+files/example.zip ** Summary changed: - qemu-system-aarch64: regression: msr vbar_el2, xN not working in EL2 + qemu-system-aarch64: regression: TCG sometimes using wrong values for VBAR_EL2 despite it being correctly reported to GDB -- 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
