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
