Re: [PATCH 0/4] KVM: Reset steal time accounting on vCPU pid change (x86 and arm64)

On Mon, Aug 17, 2026 4:51:38AM -0700, David Woodhouse wrote:
> On Sat, 2026-08-15 at 22:33 -0700, Dongli Zhang wrote:
>> 3. Although David also suggested doing the same for Xen-on-KVM vCPUs, this
>> series does not reset last_steal for Xen vCPUs.
> 
> Hm, the more I look at this, the more I like the Xen-on-KVM approach of
> just letting userspace save/restore the values.
> 
> Migration Just Works™, as the runstate times are migrated along with
> the 'current' runstate being set to RUNSTATE_runnable, and the next
> catch-up attributes all the intervening time to steal time, correctly
> tracking the migration downtime.
> 
> For your vCPU hotplug case, a VMM hosting Xen guests can use the same
> API to set all the times to zero and the current runstate to
> RUNSTATE_offline.
> 
> Shouldn't we just add the same save/restore facility for the native KVM
> steal time too? It'd make live migration fully transparent, and a VMM
> could handle your vCPU hotplug case just the same way by setting it to
> zero (the ioctl would recapture last_steal on the current pid just like
> KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_DATA does).

+1

I fully agree with this.

I agree that a save/restore for native KVM stealtime is the best approach so
far. Instead of only getting/setting last_steal, perhaps it should also include
the current vCPU kvm-clock value when the vCPU is preempted. In addition to live
migration and vCPU hotplug, I have recently identified more scenarios where
steal time can be problematic, which I can share in a separate thread.

That said, KVM steal time may need to be rearchitected.

However, I still think the current patchset is useful. It is small and can be
backported to stable kernels, where adding support for a new ioctl would not be
appropriate.

> 
> 
> On the *guest* side, is anything really needed once we fix the host not
> to expose nonsense values? You've given Marc the impression that we
> need guest-side changes to match the host-side changes in this thread,
> and that wasn't my understanding.
> 
> We *should* still fix the guests, of course, but I still prefer my
> approach to that, as discussed in 
> https://lore.kernel.org/all/[email protected]/


Regarding the guest side: yes, your approach avoids accounting an excessive
amount of steal time from bogus host values. But I still wonder whether it also
makes sense for the guest to reset its own baseline whenever it starts using the
feature.

For example, KVM paravirtualization initializes "kvm_sched_clock_offset" when
kvm-clock starts being used, and Xen paravirtualization uses
"xen_sched_clock_offset" for a similar purpose. So perhaps it is not a bad idea
to reset the baseline when enabling a paravirtual feature.

For x86 KVM steal time, that would mean resetting "rq->prev_steal_time" and
"rq->prev_steal_time_rq" before enabling MSR_KVM_STEAL_TIME.


Thank you very much!

Dongli Zhang