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
