[Qemu-devel] [Bug 1838277] Re: qemu-system-aarch64: regression: TCG sometimes using wrong values for VBAR_EL2 despite it being correctly reported to GDB

[Peter Maydell]

Your example_x20_mov_sp_x8 binary performs an illegal-exception-return
because it does an eret from EL2 to EL1 without having set HCR_EL2.RW to
1. That means that the CPU will continue execution from the exception-
return "link address" in ELR_EL2 (and remain in EL2). That is 0, because
we just loaded it from address +0x1938 in the binary, which is all-
zeroes. Attempting to execute from 0x0 in EL2 triggers a prefetch abort
which is taken to EL2 at entry point 0x60001200 (which is where we
expect to enter given that VBAR_EL2 is 0x60001000 and this is a
synchronous exception to the current EL). The earlier "mov sp, x8" seems
to have executed as expected and the SP at the 'eret' is 0x60002ff0.

This seems to me to be correct execution of a buggy guest binary.

Note that if you are trying to debug this via the gdbstub you may be
being misled by a bug in our handling of "single step" -- if you single
step an instruction and it causes an exception (eg it is a load from a
bad address) then instead of stopping execution at the exception-entry-
point, we will execute one instruction at the exception-entry-point and
then stop after that. So you get back control in gdb one instruction
later than you expect.

-- 
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