When a confidential virtual machine is reset, a new guest context in the
accelerator must be generated post reset. Therefore, the old accelerator guest
file handle must be closed and a new one created. To this end, a per-accelerator
callback, "reset_vmfd" is introduced that would get called when a confidential
guest is reset. Subsequent patches will introduce specific implementation of
this callback for KVM accelerator.

Signed-off-by: Ani Sinha <anisinha@redhat.com>
---
 include/accel/accel-ops.h |  1 +
 system/runstate.c         | 37 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/include/accel/accel-ops.h b/include/accel/accel-ops.h
index 23a8c246e1..998a95ca69 100644
--- a/include/accel/accel-ops.h
+++ b/include/accel/accel-ops.h
@@ -23,6 +23,7 @@ struct AccelClass {
     AccelOpsClass *ops;
 
     int (*init_machine)(AccelState *as, MachineState *ms);
+    int (*reset_vmfd)(MachineState *ms);
     bool (*cpu_common_realize)(CPUState *cpu, Error **errp);
     void (*cpu_common_unrealize)(CPUState *cpu);
     /* get_stats: Append statistics to @buf */
diff --git a/system/runstate.c b/system/runstate.c
index 5d58260ed5..0a74e3ade5 100644
--- a/system/runstate.c
+++ b/system/runstate.c
@@ -42,6 +42,7 @@
 #include "qapi/qapi-commands-run-state.h"
 #include "qapi/qapi-events-run-state.h"
 #include "qemu/accel.h"
+#include "accel/accel-ops.h"
 #include "qemu/error-report.h"
 #include "qemu/job.h"
 #include "qemu/log.h"
@@ -509,6 +510,9 @@ void qemu_system_reset(ShutdownCause reason)
 {
     MachineClass *mc;
     ResetType type;
+    AccelClass *ac = ACCEL_GET_CLASS(current_accel());
+    bool vmfd_reset = false;
+    int ret;
 
     mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
 
@@ -521,6 +525,29 @@ void qemu_system_reset(ShutdownCause reason)
     default:
         type = RESET_TYPE_COLD;
     }
+
+    /*
+     * different accelerators implement how to close the old file handle of
+     * the accelerator descriptor and create a new one here. Resetting
+     * file handle is necessary to create a new confidential VM context post
+     * VM reset.
+     */
+    if (!cpus_are_resettable() &&
+        (reason == SHUTDOWN_CAUSE_GUEST_RESET ||
+         reason == SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET)) {
+        if (ac->reset_vmfd) {
+            ret = ac->reset_vmfd(current_machine);
+            if (ret < 0) {
+                error_report("unable to reset vmfd: %s(%d)",
+                             strerror(-ret), ret);
+                vm_stop(RUN_STATE_INTERNAL_ERROR);
+            }
+            vmfd_reset = true;
+        } else {
+            error_report("accelerator does not support reset");
+        }
+    }
+
     if (mc && mc->reset) {
         mc->reset(current_machine, type);
     } else {
@@ -543,7 +570,15 @@ void qemu_system_reset(ShutdownCause reason)
      * it does _more_  than cpu_synchronize_all_post_reset().
      */
     if (cpus_are_resettable()) {
-        cpu_synchronize_all_post_reset();
+        if (vmfd_reset) {
+            /*
+             * If vmfd has changed, then vcpufds have also changed.
+             * Need to sync full cpu state for non confidential guests.
+             */
+            cpu_synchronize_all_post_init();
+        } else {
+            cpu_synchronize_all_post_reset();
+        }
     }
 
     vm_set_suspended(false);
-- 
2.42.0

Hi Ani,

On 12/2/26 07:24, Ani Sinha wrote:
> When a confidential virtual machine is reset, a new guest context in the
> accelerator must be generated post reset. Therefore, the old accelerator guest
> file handle must be closed and a new one created. To this end, a per-accelerator
> callback, "reset_vmfd" is introduced that would get called when a confidential
> guest is reset. Subsequent patches will introduce specific implementation of
> this callback for KVM accelerator.
> 
> Signed-off-by: Ani Sinha <anisinha@redhat.com>
> ---
>   include/accel/accel-ops.h |  1 +
>   system/runstate.c         | 37 ++++++++++++++++++++++++++++++++++++-
>   2 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/include/accel/accel-ops.h b/include/accel/accel-ops.h
> index 23a8c246e1..998a95ca69 100644
> --- a/include/accel/accel-ops.h
> +++ b/include/accel/accel-ops.h
> @@ -23,6 +23,7 @@ struct AccelClass {
>       AccelOpsClass *ops;
>   
>       int (*init_machine)(AccelState *as, MachineState *ms);
> +    int (*reset_vmfd)(MachineState *ms);

So far 'vmfd' is a KVM concept. Can we use a more generic name?

Please add a @docstring description for this handler.

>       bool (*cpu_common_realize)(CPUState *cpu, Error **errp);
>       void (*cpu_common_unrealize)(CPUState *cpu);
>       /* get_stats: Append statistics to @buf */
> diff --git a/system/runstate.c b/system/runstate.c
> index 5d58260ed5..0a74e3ade5 100644
> --- a/system/runstate.c
> +++ b/system/runstate.c
> @@ -42,6 +42,7 @@
>   #include "qapi/qapi-commands-run-state.h"
>   #include "qapi/qapi-events-run-state.h"
>   #include "qemu/accel.h"
> +#include "accel/accel-ops.h"
>   #include "qemu/error-report.h"
>   #include "qemu/job.h"
>   #include "qemu/log.h"
> @@ -509,6 +510,9 @@ void qemu_system_reset(ShutdownCause reason)
>   {
>       MachineClass *mc;
>       ResetType type;
> +    AccelClass *ac = ACCEL_GET_CLASS(current_accel());
> +    bool vmfd_reset = false;
> +    int ret;
>   
>       mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
>   
> @@ -521,6 +525,29 @@ void qemu_system_reset(ShutdownCause reason)
>       default:
>           type = RESET_TYPE_COLD;
>       }
> +
> +    /*
> +     * different accelerators implement how to close the old file handle of
> +     * the accelerator descriptor and create a new one here. Resetting
> +     * file handle is necessary to create a new confidential VM context post
> +     * VM reset.
> +     */
> +    if (!cpus_are_resettable() &&
> +        (reason == SHUTDOWN_CAUSE_GUEST_RESET ||
> +         reason == SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET)) {
> +        if (ac->reset_vmfd) {
> +            ret = ac->reset_vmfd(current_machine);
> +            if (ret < 0) {
> +                error_report("unable to reset vmfd: %s(%d)",
> +                             strerror(-ret), ret);
> +                vm_stop(RUN_STATE_INTERNAL_ERROR);
> +            }
> +            vmfd_reset = true;

If we need a such flag, please rename it generically.

> +        } else {
> +            error_report("accelerator does not support reset");
> +        }
> +    }
> +
>       if (mc && mc->reset) {
>           mc->reset(current_machine, type);
>       } else {
> @@ -543,7 +570,15 @@ void qemu_system_reset(ShutdownCause reason)
>        * it does _more_  than cpu_synchronize_all_post_reset().
>        */
>       if (cpus_are_resettable()) {
> -        cpu_synchronize_all_post_reset();
> +        if (vmfd_reset) {
> +            /*
> +             * If vmfd has changed, then vcpufds have also changed.
> +             * Need to sync full cpu state for non confidential guests.
> +             */
> +            cpu_synchronize_all_post_init();

Calling post_init() in reset() is dubious. It might work with KVM by
chance (because only KVM implements .reset_vmfd), but by design I
don't expect it to work on other accelerators. If you really think
this is the only solution, then you'll need to document cpu_sync*
methods very carefully.

> +        } else {
> +            cpu_synchronize_all_post_reset();
> +        }
>       }
>   
>       vm_set_suspended(false);

Isn't the confidential_guest_kvm_reset() API more appropriate here?

On Thu, Feb 12, 2026 at 10:23 PM Philippe Mathieu-Daudé
<philmd@linaro.org> wrote:
>
> Hi Ani,
>
> On 12/2/26 07:24, Ani Sinha wrote:
> > When a confidential virtual machine is reset, a new guest context in the
> > accelerator must be generated post reset. Therefore, the old accelerator guest
> > file handle must be closed and a new one created. To this end, a per-accelerator
> > callback, "reset_vmfd" is introduced that would get called when a confidential
> > guest is reset. Subsequent patches will introduce specific implementation of
> > this callback for KVM accelerator.
> >
> > Signed-off-by: Ani Sinha <anisinha@redhat.com>
> > ---
> >   include/accel/accel-ops.h |  1 +
> >   system/runstate.c         | 37 ++++++++++++++++++++++++++++++++++++-
> >   2 files changed, 37 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/accel/accel-ops.h b/include/accel/accel-ops.h
> > index 23a8c246e1..998a95ca69 100644
> > --- a/include/accel/accel-ops.h
> > +++ b/include/accel/accel-ops.h
> > @@ -23,6 +23,7 @@ struct AccelClass {
> >       AccelOpsClass *ops;
> >
> >       int (*init_machine)(AccelState *as, MachineState *ms);
> > +    int (*reset_vmfd)(MachineState *ms);
>
> So far 'vmfd' is a KVM concept. Can we use a more generic name?
>
> Please add a @docstring description for this handler.
>
> >       bool (*cpu_common_realize)(CPUState *cpu, Error **errp);
> >       void (*cpu_common_unrealize)(CPUState *cpu);
> >       /* get_stats: Append statistics to @buf */
> > diff --git a/system/runstate.c b/system/runstate.c
> > index 5d58260ed5..0a74e3ade5 100644
> > --- a/system/runstate.c
> > +++ b/system/runstate.c
> > @@ -42,6 +42,7 @@
> >   #include "qapi/qapi-commands-run-state.h"
> >   #include "qapi/qapi-events-run-state.h"
> >   #include "qemu/accel.h"
> > +#include "accel/accel-ops.h"
> >   #include "qemu/error-report.h"
> >   #include "qemu/job.h"
> >   #include "qemu/log.h"
> > @@ -509,6 +510,9 @@ void qemu_system_reset(ShutdownCause reason)
> >   {
> >       MachineClass *mc;
> >       ResetType type;
> > +    AccelClass *ac = ACCEL_GET_CLASS(current_accel());
> > +    bool vmfd_reset = false;
> > +    int ret;
> >
> >       mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
> >
> > @@ -521,6 +525,29 @@ void qemu_system_reset(ShutdownCause reason)
> >       default:
> >           type = RESET_TYPE_COLD;
> >       }
> > +
> > +    /*
> > +     * different accelerators implement how to close the old file handle of
> > +     * the accelerator descriptor and create a new one here. Resetting
> > +     * file handle is necessary to create a new confidential VM context post
> > +     * VM reset.
> > +     */
> > +    if (!cpus_are_resettable() &&
> > +        (reason == SHUTDOWN_CAUSE_GUEST_RESET ||
> > +         reason == SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET)) {
> > +        if (ac->reset_vmfd) {
> > +            ret = ac->reset_vmfd(current_machine);
> > +            if (ret < 0) {
> > +                error_report("unable to reset vmfd: %s(%d)",
> > +                             strerror(-ret), ret);
> > +                vm_stop(RUN_STATE_INTERNAL_ERROR);
> > +            }
> > +            vmfd_reset = true;
>
> If we need a such flag, please rename it generically.
>
> > +        } else {
> > +            error_report("accelerator does not support reset");
> > +        }
> > +    }
> > +
> >       if (mc && mc->reset) {
> >           mc->reset(current_machine, type);
> >       } else {
> > @@ -543,7 +570,15 @@ void qemu_system_reset(ShutdownCause reason)
> >        * it does _more_  than cpu_synchronize_all_post_reset().
> >        */
> >       if (cpus_are_resettable()) {
> > -        cpu_synchronize_all_post_reset();
> > +        if (vmfd_reset) {
> > +            /*
> > +             * If vmfd has changed, then vcpufds have also changed.
> > +             * Need to sync full cpu state for non confidential guests.
> > +             */
> > +            cpu_synchronize_all_post_init();
>
> Calling post_init() in reset() is dubious. It might work with KVM by
> chance (because only KVM implements .reset_vmfd), but by design I
> don't expect it to work on other accelerators. If you really think
> this is the only solution, then you'll need to document cpu_sync*
> methods very carefully.
>
> > +        } else {
> > +            cpu_synchronize_all_post_reset();
> > +        }
> >       }
> >
> >       vm_set_suspended(false);
>
> Isn't the confidential_guest_kvm_reset() API more appropriate here?

This above hunk I did, calling post_init() to do a full
put_registers() etc is required only for non-coco case in KVM after
CPU reset when we are enabling vm file descriptor change. In the coco
case, the call is a noop as the guest state is protected.
This part I am not very familiar with and used my best judgement. To
address your concern that other accelerators might implement
reset_vmfd() but does not like to call
cpu_synchronize_all_post_init(), we can wrap it inside another
accelerator callback like ac->cpu_synchronize_all_post_vmfd_change()
or some such.

Paolo has some context as I was debugging this area with his help. I
am curious also for his inputs on this.

On 2/13/26 07:40, Ani Sinha wrote:
>>> +        if (vmfd_reset) {
>>> +            /*
>>> +             * If vmfd has changed, then vcpufds have also changed.
>>> +             * Need to sync full cpu state for non confidential guests.
>>> +             */
>>> +            cpu_synchronize_all_post_init();
>>
>> Calling post_init() in reset() is dubious. It might work with KVM by
>> chance (because only KVM implements .reset_vmfd), but by design I
>> don't expect it to work on other accelerators. If you really think
>> this is the only solution, then you'll need to document cpu_sync*
>> methods very carefully.

post_init is called to do a first-time initialization of the VM file 
descriptor.  This is exactly why you need to call it here, the VM file 
descriptor is new and has never been fully synchronized before. 
Otherwise, kvm_arch_set_tsc_khz() is never called (doing it in the 
reset_vmfd callback would be a hack).

Other accelerators don't implement separate post-init and post-reset 
callbacks at all:

mshv => same except for abort vs. RUN_STATE_INTERNAL_ERROR
whpx => WHPX_SET_RESET_STATE vs. WHPX_SET_FULL_STATE, actually no change
nvmm => same implementation
hvf => same implementation
tcg => does not implement either

so they're unaffected.

>>> +        } else {
>>> +            cpu_synchronize_all_post_reset();
>>> +        }
>>>        }
>>>
>>>        vm_set_suspended(false);
>>
>> Isn't the confidential_guest_kvm_reset() API more appropriate here?
> 
> This above hunk I did, calling post_init() to do a full
> put_registers() etc is required only for non-coco case in KVM after
> CPU reset when we are enabling vm file descriptor change. In the coco
> case, the call is a noop as the guest state is protected.
> This part I am not very familiar with and used my best judgement. To
> address your concern that other accelerators might implement
> reset_vmfd() but does not like to call
> cpu_synchronize_all_post_init(), we can wrap it inside another
> accelerator callback like ac->cpu_synchronize_all_post_vmfd_change()
> or some such.

No, calling the post_init callback is the right thing to do.

I must say I am not 100% sure of the initialization flow in general; I 
think kvm_arch_set_tsc_khz() must be called for confidential guests too 
and, in order to do so, at initialization time QEMU could call a 
post_init call that only does kvm_arch_set_tsc_khz(), and then call 
post_reset normally. But this is independent of this series, which 
doesn't make the fix any easier or harder.

Paolo

> On 12 Feb 2026, at 10:23 PM, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> 
> Hi Ani,
> 
> On 12/2/26 07:24, Ani Sinha wrote:
>> When a confidential virtual machine is reset, a new guest context in the
>> accelerator must be generated post reset. Therefore, the old accelerator guest
>> file handle must be closed and a new one created. To this end, a per-accelerator
>> callback, "reset_vmfd" is introduced that would get called when a confidential
>> guest is reset. Subsequent patches will introduce specific implementation of
>> this callback for KVM accelerator.
>> Signed-off-by: Ani Sinha <anisinha@redhat.com>
>> ---
>>  include/accel/accel-ops.h |  1 +
>>  system/runstate.c         | 37 ++++++++++++++++++++++++++++++++++++-
>>  2 files changed, 37 insertions(+), 1 deletion(-)
>> diff --git a/include/accel/accel-ops.h b/include/accel/accel-ops.h
>> index 23a8c246e1..998a95ca69 100644
>> --- a/include/accel/accel-ops.h
>> +++ b/include/accel/accel-ops.h
>> @@ -23,6 +23,7 @@ struct AccelClass {
>>      AccelOpsClass *ops;
>>        int (*init_machine)(AccelState *as, MachineState *ms);
>> +    int (*reset_vmfd)(MachineState *ms);
> 
> So far 'vmfd' is a KVM concept. Can we use a more generic name?

This is more like a hypervisor interface to manage the VM. For example, for Xen it would be what xc_interface_open() would return.
So I can rename it to something like “reset_hypervisor_interface”.

> 
> Please add a @docstring description for this handler.
> 
>>      bool (*cpu_common_realize)(CPUState *cpu, Error **errp);
>>      void (*cpu_common_unrealize)(CPUState *cpu);
>>      /* get_stats: Append statistics to @buf */
>> diff --git a/system/runstate.c b/system/runstate.c
>> index 5d58260ed5..0a74e3ade5 100644
>> --- a/system/runstate.c
>> +++ b/system/runstate.c
>> @@ -42,6 +42,7 @@
>>  #include "qapi/qapi-commands-run-state.h"
>>  #include "qapi/qapi-events-run-state.h"
>>  #include "qemu/accel.h"
>> +#include "accel/accel-ops.h"
>>  #include "qemu/error-report.h"
>>  #include "qemu/job.h"
>>  #include "qemu/log.h"
>> @@ -509,6 +510,9 @@ void qemu_system_reset(ShutdownCause reason)
>>  {
>>      MachineClass *mc;
>>      ResetType type;
>> +    AccelClass *ac = ACCEL_GET_CLASS(current_accel());
>> +    bool vmfd_reset = false;
>> +    int ret;
>>        mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
>>  @@ -521,6 +525,29 @@ void qemu_system_reset(ShutdownCause reason)
>>      default:
>>          type = RESET_TYPE_COLD;
>>      }
>> +
>> +    /*
>> +     * different accelerators implement how to close the old file handle of
>> +     * the accelerator descriptor and create a new one here. Resetting
>> +     * file handle is necessary to create a new confidential VM context post
>> +     * VM reset.
>> +     */
>> +    if (!cpus_are_resettable() &&
>> +        (reason == SHUTDOWN_CAUSE_GUEST_RESET ||
>> +         reason == SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET)) {
>> +        if (ac->reset_vmfd) {
>> +            ret = ac->reset_vmfd(current_machine);
>> +            if (ret < 0) {
>> +                error_report("unable to reset vmfd: %s(%d)",
>> +                             strerror(-ret), ret);
>> +                vm_stop(RUN_STATE_INTERNAL_ERROR);
>> +            }
>> +            vmfd_reset = true;
> 
> If we need a such flag, please rename it generically.
> 
>> +        } else {
>> +            error_report("accelerator does not support reset");
>> +        }
>> +    }
>> +
>>      if (mc && mc->reset) {
>>          mc->reset(current_machine, type);
>>      } else {
>> @@ -543,7 +570,15 @@ void qemu_system_reset(ShutdownCause reason)
>>       * it does _more_  than cpu_synchronize_all_post_reset().
>>       */
>>      if (cpus_are_resettable()) {
>> -        cpu_synchronize_all_post_reset();
>> +        if (vmfd_reset) {
>> +            /*
>> +             * If vmfd has changed, then vcpufds have also changed.
>> +             * Need to sync full cpu state for non confidential guests.
>> +             */
>> +            cpu_synchronize_all_post_init();
> 
> Calling post_init() in reset() is dubious. It might work with KVM by
> chance (because only KVM implements .reset_vmfd), but by design I
> don't expect it to work on other accelerators. If you really think
> this is the only solution, then you'll need to document cpu_sync*
> methods very carefully.
> 
>> +        } else {
>> +            cpu_synchronize_all_post_reset();
>> +        }
>>      }
>>        vm_set_suspended(false);
> 
> Isn't the confidential_guest_kvm_reset() API more appropriate here?

On 2/13/26 06:24, Ani Sinha wrote:
> 
> 
>> On 12 Feb 2026, at 10:23 PM, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>
>> Hi Ani,
>>
>> On 12/2/26 07:24, Ani Sinha wrote:
>>> When a confidential virtual machine is reset, a new guest context in the
>>> accelerator must be generated post reset. Therefore, the old accelerator guest
>>> file handle must be closed and a new one created. To this end, a per-accelerator
>>> callback, "reset_vmfd" is introduced that would get called when a confidential
>>> guest is reset. Subsequent patches will introduce specific implementation of
>>> this callback for KVM accelerator.
>>> Signed-off-by: Ani Sinha <anisinha@redhat.com>
>>> ---
>>>   include/accel/accel-ops.h |  1 +
>>>   system/runstate.c         | 37 ++++++++++++++++++++++++++++++++++++-
>>>   2 files changed, 37 insertions(+), 1 deletion(-)
>>> diff --git a/include/accel/accel-ops.h b/include/accel/accel-ops.h
>>> index 23a8c246e1..998a95ca69 100644
>>> --- a/include/accel/accel-ops.h
>>> +++ b/include/accel/accel-ops.h
>>> @@ -23,6 +23,7 @@ struct AccelClass {
>>>       AccelOpsClass *ops;
>>>         int (*init_machine)(AccelState *as, MachineState *ms);
>>> +    int (*reset_vmfd)(MachineState *ms);
>>
>> So far 'vmfd' is a KVM concept. Can we use a more generic name?

For what it's worth, mshv and nvmm also have it (whpx has a handle 
because it's Windows, hvf probably has a file descriptor internally but 
only exposes a single VM per process).

> This is more like a hypervisor interface to manage the VM. For example, for Xen it would be what xc_interface_open() would return.
> So I can rename it to something like “reset_hypervisor_interface”.
Or rebuild_vm perhaps?  It can also be done on applying, since it's an 
easy mass change on the .patch files themselves.

Paolo