Re: [PATCH v2 for-5.1?] target/arm: Fix Rt/Rt2 in ESR_ELx for copro traps from AArch32 to 64

[Marc Zyngier <maz@kernel.org>]

Hi Peter,

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
> values.
> 
> Fixes: https://bugs.launchpad.net/qemu/+bug/1879587
> Reported-by: Julien Freche <julien@bedrocksystems.com>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> 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.

         M.
-- 
Jazz is not dead. It just smells funny...