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

On Mon, 27 Jul 2026 at 18:48, Richard Henderson
<[email protected]> wrote:
>
> 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.

Well, it's not great, but the lack of feature guard on WFI and
WFE has been that way since forever. I suppose we've only
recently made WFE do something and as you say it's the paired
wait/signal where things can go wrong.

I'll have a look at a patch for that part tomorrow I guess.

-- PMM