SEV-ES guest shutdown: linux-next regression with QEMU 10.2.2; smp>1

[Aithal, Srikanth]

Hello,

I am hitting a failure when shutting down a SEV-ES guest (smp>1) on 
recent linux-next, and narrowed it down with bisection on the host 
kernel. The issue appears with more than one vCPU (e.g. -smp 2); with 
-smp 1 shutdown completes normally in my tests. The same guest shutdown 
path works with an older host kernel (<next-20260304) and is also 
avoided with current QEMU master or by cherry-picking a specific QEMU 
commit onto v10.2.2.

Environment:
Host kernel: linux-next, tag next-20260319 [1] (also observed starting 
from next-20260304).
Guest: SEV-ES Linux guest; -smp 2 (or more) reproduces the issue; -smp 1 
does not in my testing.
Hypervisor / QEMU: Initially QEMU v10.2.2 (stable). Later tested QEMU 
master at 8e711856d763 [2].

Details on issue:

After SEV-ES guest shutdown , the serial log shows a register dump 
(example below) .

[   12.613383] reboot: Power down^M
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00a00f11
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000b004 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1
ES =0000 00000000 0000ffff 00009300
CS =f000 00800000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=b0 96 b5 61 ca ef 3f 51 00 c3 65 51 19 77 b1 e0 e5 e2 91 b8 <0c> 5d 
c7 fc 59 bc 2b 6f 90 89 44 23 ec ec 2f 62 fd e0 8f d5 c7 31 24 70 e2 7d 
c6 ee 00 00
-> Hangs here

Host kernel bisect (with QEMU v10.2.2) led to:

Good (no crash on guest shutdown):
32d76cdfa1222c88262da5b12e0b2bba444c96fa
KVM: SVM: Move core EFER.SVME enablement to kernel (local build tagged 
7.0.0-rc232d76cdfa1222 during testing.)

Bad (crash reproduced):
428afac5a8ea9c55bb8408e02dc92b8f85bf5f30
KVM: x86: Move bulk of emergency virtualization logic to virt subsystem

So the first bad commit in my host kernel bisect was 428afac5a8ea. The 
commit prior [32d76cdfa122] did not have this issue.

Later I used QEMU master and with same linux-next next-20260319 as host, 
it did not reproduce the shutdown issue .. that was using QEMU master [2].

QEMU master contains 56d89db2cfd82c53439778fbf39294bf35194dba 
(target/i386: convert SEV-ES termination requests to guest panic events).
Cherry-picking that commit onto QEMU v10.2.2 resolved or at least 
avoided the shutdown crash in my setup.


Questions:

KVM: Is the interaction/issue with older QEMU (e.g. v10.2.2) expected 
here, or is there anything that should be adjusted or documented 
following 428afac5a8ea, like for multi-vCPU SEV-ES guests?
QEMU: Would a stable backport of 56d89db2cfd8 to 10.2.x (or equivalent 
handling of SEV-ES termination) be appropriate for users staying on 
stable QEMU while moving to newer host kernels?

Thank you,

Srikanth Aithal <sraithal@xxxxxxx>

References

[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
— next-20260319
[2] https://gitlab.com/qemu-project/qemu — master 8e711856d763