> On 18 Feb 2026, at 11:09 PM, Cédric Le Goater <[email protected]> wrote:
>
> On 2/18/26 18:33, Ani Sinha wrote:
>> On Wed, Feb 18, 2026 at 9:00 PM Cédric Le Goater <[email protected]> wrote:
>>>
>>> On 2/18/26 16:07, Ani Sinha wrote:
>>>>
>>>>
>>>>> On 18 Feb 2026, at 7:37 PM, Cédric Le Goater <[email protected]> wrote:
>>>>>
>>>>> On 2/18/26 12:42, Ani Sinha wrote:
>>>>>> Normally the vfio pseudo device file descriptor lives for the life of
>>>>>> the VM.
>>>>>> However, when the kvm VM file descriptor changes, a new file descriptor
>>>>>> for the pseudo device needs to be generated against the new kvm VM
>>>>>> descriptor.
>>>>>> Other existing vfio descriptors needs to be reattached to the new pseudo
>>>>>> device
>>>>>> descriptor. This change performs the above steps.
>>>>>> Tested-by: Cédric Le Goater <[email protected]>
>>>>>
>>>>> There is a regression since last version.
>>>>>
>>>>>
>>>>> 'reboot' from the guest and command 'system_reset' from the QEMU
>>>>> monitor now generate these outputs:
>>>>>
>>>>> qemu-system-x86_64: info: virtual machine state has been rebuilt with
>>>>> new guest file handle.
>>>>> qemu-system-x86_64: info: virtual machine state has been rebuilt with
>>>>> new guest file handle.
>>>>> qemu-system-x86_64: info: virtual machine state has been rebuilt with
>>>>> new guest file handle.
>>>>> ...
>>>>>
>>>>> and QEMU exits after a while.
>>>>
>>>> I have only seen this in SEV-ES with more than one vcpus. Never with TDX
>>>> or SEV-SNP (single or multiple cpus).
>>>> On which host/guest type did you see this?
>>>
>>> SEV-SNP on a RHEL9 host. Same guest I used before and host says :
>>>
>>> [1816531.409591] kvm_amd: SEV-ES guest requested termination: 0x0:0x0
>> Strange! I am not sure why KVM thinks it's SEV-ES. I have done all my
>> SEV-SNP and TDX testing on a fc43 host and for SEV-ES I used a fc42
>> host. I have not seen this kind of guest termination on SEV-SNP or TDX
>> on that host. I am sure there are some differences between the RHEL9
>> host kernel and fc43 kernel.
>
> The same issue occurs with a rhel10 kernel.
OK good news is that I see this issue on the latest rhel9 host but not on a
fc43 host.
The issue happens only when > 1 cpus are created for the guest. With only one
cpu seems its fine.
I tried a minimalistic guest with only a kernel passed as UKI as well as a full
blown fc43 guest. Both manifest the same issue with > 1 vcpu threads.
There is a regression indeed between versions. My v3 which I posted just before
FOSDEM seems good and does not show this behaviour on the same RHEL 9 host.
Both v4 and v5 are affected. This means regression is somewhere in my changes,
not due to host kernel changes.
This shows a little bit more information:
bash-5.1# /usr/sbin/reboot -f
[ 43.920835] ACPI: PM: Preparing to enter system sleep state S5
[ 43.922988] reboot: Restarting system
[ 43.924242] reboot: machine restart
qemu-system-x86_64: info: virtual machine state has been rebuilt with new guest
file handle.
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00800f12
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=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
It is likely that the changes towards fixing non-coco reset case with QMP
“system_reset” introduced this regression. I will have to audit changes between
v3 and v4.
