> On 15 Dec 2025, at 4:08 PM, Daniel P. Berrangé <[email protected]> wrote:
>
> On Fri, Dec 12, 2025 at 08:33:28PM +0530, Ani Sinha wrote:
>> This change introduces support for confidential guests
>> (SEV-ES, SEV-SNP and TDX) to reset/reboot just like other non-confidential
>> guests. Currently, a reboot intiated from the confidential guest results
>> in termination of the QEMU hypervisor as the CPUs are not resettable. As the
>> initial state of the guest including private memory is locked and encrypted,
>> the contents of that memory will not be accessible post reset. Hence a new
>> KVM file descriptor must be opened to create a new confidential VM context
>> closing the old one. All KVM VM specific ioctls must be called again. New
>> VCPU file descriptors must be created against the new KVM fd and most VCPU
>> ioctls must be called again as well.
>>
>> This change perfoms closing of the old KVM fd and creating a new one. After
>> the new KVM fd is opened, all generic and architecture specific ioctl calls
>> are issued again. Notifiers are added to notify subsystems that:
>> - The KVM file fd is about to be changed to state sync-ing from KVM to QEMU
>> should be done if required.
>> - The KVM file fd has changed, so ioctl calls to the new KVM fd has to be
>> performed again.
>> - That new VCPU fds are created so that VCPU ioctl calls must be called again
>> where required.
>
> Presumably this re-opening of VCPU FDs means that all the KVM vCPU PIDs
> are going to change ?
Only vcpu file descriptor numbers are going to change, not the PID for the
corresponding threads. The same thread is going to be used.
>
> If so, this is a significant semantic change that will break management
> applications. vCPU PIDs are exposed in QMP and applications like libvirt
> query them upon QEMU startup *BEFORE* vCPUs are started, and then do
> things like setting CPU pinning or NUMA policies against them.
>
> They cannot re-query the vCPU PIDs at time of reset, as by that point QEMU
> has been running guest code, and so mgmt applications must assume that the
> QEMU process (and thus QMP replies) are hostile. They cannot trust the vCPU
> PIDs that would be reported as QEMU might have been compromised and now be
> reporting vCPU PIDs of a completely different process as a form of DoS
> against the mgmt app.
>
> Can we get this reset functionality into KVM natively instead so QEMU
> doesn't have todo this dance to re-create everything ?
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o- https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
