Single-step exceptions incorrectly routed to EL1 when ELD is EL2 (TDE = 1) (qemu version 3.1)

[Elouan Appéré]

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

[Peter Maydell (pmaydell)]

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

[Peter Maydell (pmaydell)]

I've just submitted this patchset:
https://<email address hidden>/

which I think should fix this bug. With those changes, the test image takes a single-step exception to EL2, and then (because there's no code at the exception entry point) takes a series of EL2-to-EL2 undef exceptions, which I think is expected and correct behaviour.

[Elouan Appéré (elouan-appere)]

Thanks for the patch!

I tested it with more complex code, it seems to work fine (and fixes the bug), e.g. with an infinite loop of 2 instructions:

Single-step exeception ELR = 0x0000000060100000, ISV = 1, EX = 0
Single-step exeception ELR = 0x0000000060100004, ISV = 1, EX = 0
(and so on)

(I haven't been able to test load-exclusive instructions yet but I don't see why it would fail for EL2 specifically, anyway)

[Peter Maydell (pmaydell)]

This is fixed in master by commit 8bd587c1066f445 which will be in the 4.2 release.