Re: [PATCH] target/arm: Don't NOP the SEV insn on v6K CPUs

Richard Henderson <[email protected]> Mon, 27 Jul 2026 10:48:06 -0700
Newsgroups org.nongnu.qemu-arm,org.nongnu.qemu-devel
Message-ID <[email protected]>
On 7/27/26 08:13, Peter Maydell wrote:
> When we implememented SEV to do something on A-profile rather than
> being a nop, we got the condition slightly wrong, and made it only
> effective from v7.  In fact the instruction's Arm encoding has
> non-NOP behaviour from ARMv6K.
> 
> The effect is that a kernel boot may hang on a v6K CPU like the
> ARM11MPCore.
> 
> (This wouldn't have been so noticeable if we feature checked the WFE
> instruction, and had made the same mistake for the condition on both
> instructions.  But we never have done the feature checks that we
> ought on WFE, so the mistake on SEV meant that we showed the 11mpcore
> guest a WFE that did something and a SEV that was a NOP.)
> 
> The v7A Arm ARM is not entirely clear about whether v6K has the Thumb
> SEV encoding or not: it says "ARMv7 (executes as NOP in ARMv6T2)",
> leaving v6K not stated.  The 11MPCore TRM says it has at least WFI in
> both Arm and Thumb, and the v7A Arm ARM uses the same condition text
> for WFI, so I make the assumption that WFI, WFE, and SEV all get
> their functionality for both Thumb and Arm in v6K.  It's possible
> that this differed between v6K CPUs -- the 1176 TRM says it has the
> v6K STREXD/STREXH/STREXB etc, but the WFI is the old-style cp15 one.
> 
> Keeping the condition check the same for both Thumb and Arm encodings
> is the conservative choice: if guests try to execute the Thumb SEV
> insn it will be because they want SEV, not because they want a NOP.
> 
> Resolves:https://gitlab.com/qemu-project/qemu/-/work_items/4044
> Fixes: 60e7ee5bb7cd ("target/arm: implements SEV/SEVL for all modes")
> Signed-off-by: Peter Maydell<[email protected]>

Reviewed-by: Richard Henderson <[email protected]>

> Picking this one up because I think we should fix it for 11.1
> and Alex is on holiday. The "WFI and WFE should have a feature
> check" part we can leave for 11.2.

Really?  I'm tempted to call the mismatch between wait and signal to be the "real" bug.


r~