[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 for-5.1?] target/arm: Fix Rt/Rt2 in ESR_ELx for copro trap
Re: [PATCH v2 for-5.1?] target/arm: Fix Rt/Rt2 in ESR_ELx for copro traps from AArch32 to 64
Wed, 05 Aug 2020 09:00:19 +0100
On 2020-08-04 20:39, Peter Maydell wrote:
When a coprocessor instruction in an AArch32 guest traps to AArch32
Hyp mode, the syndrome register (HSR) includes Rt and Rt2 fields
which are simply copies of the Rt and Rt2 fields from the trapped
instruction. However, if the instruction is trapped from AArch32 to
an AArch64 higher exception level, the Rt and Rt2 fields in the
syndrome register (ESR_ELx) must be the AArch64 view of the register.
This makes a difference if the AArch32 guest was in a mode other than
User or System and it was using r13 or r14, or if it was in FIQ mode
and using r8-r14.
We don't know at translate time which AArch32 CPU mode we are in, so
we leave the values we generate in our prototype syndrome register
value at translate time as the raw Rt/Rt2 from the instruction, and
instead correct them to the AArch64 view when we find we need to take
an exception from AArch32 to AArch64 with one of these syndrome
Reported-by: Julien Freche <firstname.lastname@example.org>
Signed-off-by: Peter Maydell <email@example.com>
Changes v1->v2: fixed the register mapping for LR (thanks to
Julien for testing v1, diagnosing the bug in it, and suggesting
the fix to LR handling)
Marc: Cc'd you just in case you're interested, given that I'd
expect running Linux aarch64 KVM in QEMU emulation with a 32-bit
guest to hit this bug...
Thanks for the heads up.
Funnily enough, KVM had the exact opposite bug until c0f0963464c2
("arm64: KVM: Fix AArch32 to AArch64 register mapping"), which was
fixed 5 years ago. We used to actively translate the register numbers
obtained from ESR_EL2, leading to all kind of bizarre bugs if trapping
from non USR/SYS modes.
Jazz is not dead. It just smells funny...