Yes, we're directing single-step exceptions to the wrong EL. (I think
this is probably a hangover from the fact that we implemented singlestep
at about the same time or before we properly implemented EL2 support, so
we haven't shaken out all the "assumes debug EL is EL1" assumptions
still.)
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1838913
Title:
Single-step exceptions incorrectly routed to EL1 when ELD is EL2 (TDE
= 1) (qemu version 3.1)
Status in QEMU:
In Progress
Bug description:
Hi,
I've been encountering issues with QEMU 3.1 when trying to single-step
EL1 code, with ELD = EL2 (MDCR_EL2.TDE = 1). I could test with latest
commit in a few hours, if you want.
EL1 is Aarch64.
This happens as soon as MDSCR_EL1.SS is set to 1 and ERET is executed:
- Single-step exceptions are routed to EL1
Exception return from AArch64 EL2 to AArch64 EL1 PC 0x4000005c
Taking exception 1 [Undefined Instruction]
...from EL1 to EL1
...with ESR 0x32/0xca000022
...with ELR 0x4000005c
...to EL1 PC 0x200 PSTATE 0x3c5
EC 0x32 (0b110010) is Exception_SoftwareStepLowerEl.
You can find enclosed minimal code (and resulting .elf) for
reproduction.
qemu-system-aarch64 -nographic -machine virt,virtualization=on -d
unimp,int -cpu cortex-a57 -kernel test_hyp.elf
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1838913/+subscriptions
