> On 12 Feb 2026, at 1:44 PM, Ani Sinha <[email protected]> wrote:
>
>
>
>> On 12 Feb 2026, at 1:40 PM, Daniel P. Berrangé <[email protected]> wrote:
>>
>> On Thu, Feb 12, 2026 at 11:54:44AM +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.
>>>
>>> Specific subsystems use these notifiers to re-issue ioctl calls where
>>> required.
>>>
>>> Changes are made to SEV and TDX modules to reinitialize the confidential
>>> guest
>>> state and seal it again. Along the way, some bug fixes are made so that some
>>> initialization functions can be called again. Some refactoring of existing
>>> code is done so that both init and reset paths can use them.
>>>
>>> Tested on TDX, SEV-ES and SEV-SNP. Tested on non-coco hardware. Tested with
>>> Xen
>>> emulation enabled.
>>
>> I see no QOM changes here, so is there any way for a mgmt app to
>> detect that QEMU is now capable of guest reset with TDX/SEV/SNP,
>> compared to the current behaviour ?
>
> The thought did not occur to me. So other than the availability of
> 'x-change-vmfd-on-reset’ machine property there is nothing else.
Looking at the code, actually ‘can_rebuild_guest_state’ is the one we want to
use. It’s a property of ConfidentialGuestSupportClass . Maybe we can expose
this somehow.
