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

["Aithal, Srikanth" <sraithal@amd.com>]

On 4/1/2026 6:23 PM, Tom Lendacky wrote:
> On 4/1/26 06:24, Aithal, Srikanth wrote:
>> Hello Tom,
>>
>>
>> On 3/23/2026 6:40 PM, Tom Lendacky wrote:
>>> On 3/20/26 11:08, Aithal, Srikanth wrote:
>>>> 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
>>>
>>> Any chance you have the enable_virt_at_load module option set to false?
>>
>> No, it is set to Y.
>> # cat /sys/module/kvm/parameters/enable_virt_at_load
>> Y
>>
>>
>>>
>>>>
>>>> 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.
>>>
>>> Well, if it is converting a guest termination request, that is still not
>>> good. It should be a clean shutdown.
>>>
>>>>
>>>>
>>>> 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?
>>>
>>> That wouldn't actually solve the issue, it is just a much more user
>>> friendly error message. Is there a termination event in the host dmesg
>>> log?
>>
>>
>> The guest shutdown proceeds normally until:
>> [ OK ] Reached target poweroff.target - System Power Off.
>> [ 9.918849] reboot: Power down
>>
>> At that point the serial console freezes with the register dump below
>> (EIP=0000b004, HLT=1, EFER=0, etc.).
>>
>> [  OK  ] Finished systemd-poweroff.service - System Power Off.
>> [  OK  ] Reached target poweroff.target - System Power Off.
>> [   10.029330] reboot: Power down
>> 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=98 59 0c db 72 6c 94 71 3d a6 36 32 49 a8 08 22 bd d7 8c bb <4c> 3c
>> d9 bd 90 b5 2e a0 69 26 53 df aa 4c bb fe 5a d9 b6 ee 7b 45 02 2e cf d9
>> 60 48 00 00
>>
>>
>>
>> QEMU does **not** exit on its own — it appears stuck.
>>
>> Only after I press Ctrl+C do I see in host dmesg:
>> kvm_amd: SEV-ES guest requested termination: 0x0:0x0
> 
> So we would have to see what is triggering that termination request.
> 
> We can probably instrument a guest kernel to get some more info.

Sure, I can apply any debug patch and provide the debug logs.

Note: I'm heading out on PTO until next Wednesday (April 8th). I won't 
be able to gather additional debug logs until I return.

> 
>>
>> I also set `kvm_amd.dump_invalid_vmcb=1` before reproducing, but it
>> produced no additional output.
>>
>> This issue is still present on latest linux-next next-20260331 [https://
>> git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tag/?
>> h=next-20260331, tag name    next-20260331
>> (e5da3eef8dadab4e98b228725ca8948edd9d601f)]
> 
> Is it only with linux-next? Which would point to a kernel change vs a
> Qemu change.

Yes, it is specific to linux-next (starting from next-20260304, bisected 
to 428afac5a8ea "KVM: x86: Move bulk of emergency virtualization logic 
to virt subsystem").

- With older host kernels (< next-20260304) + QEMU 10.2.2 → clean 
shutdown (no hang, no termination message, QEMU exits normally).
- With linux-next (next-20260331) + QEMU 10.2.2 → hang at the register 
dump after "reboot: Power down"; only Ctrl+C triggers the "SEV-ES guest 
requested termination: 0x0:0x0" message.
- With linux-next + QEMU master (or 10.2.2 + cherry-pick of 
56d89db2cfd8) → no hang (the termination is converted to a guest panic 
instead).


> 
> Thanks,
> Tom
> 
>>
>>>
>>> Thanks,
>>> Tom
>>>
>>>>
>>>> Thank you,
>>>>
>>>> Srikanth Aithal <sraithal@amd.com>
>>>>
>>>> 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
>>>>
>>>>
>>>
>>
>