> On 15 Dec 2025, at 6:11 PM, Paolo Bonzini <[email protected]> wrote:
>
> On 12/15/25 11:38, Daniel P. Berrangé wrote:
>> On Fri, Dec 12, 2025 at 08:33:28PM +0530, Ani Sinha wrote:
>>> 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 ?
>
> As Ani said, no - the PIDs are attached to QEMU threads, not KVM file
> descriptors.
>
> I can answer this though:
>
>> Can we get this reset functionality into KVM natively instead so QEMU
>> doesn't have todo this dance to re-create everything ?
>
> The answer is no. Unlike normal reset, resetting a confidential VMs entails
> performing all the encryption and measurement from scratch for memory and
> registers, and the data is not available to KVM anymore.
Wearing my FUKI hat, between resets one can also change the state, use a
different starting CPU state, registers, firmware. So saving the old state in
KVM would not do any good in that case either.
>
> QEMU can retrieve it again, just like it did when starting the original VM,
> but KVM does not save and therefore does not know the original contents of
> the memory.
>
> Paolo
>
