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

On Mon, 2026-08-17 at 15:04 -0700, Dongli Zhang wrote:
> 
> 
> 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.

There's no "perhaps" about it. You NEVER add clock APIs which just take
one clock value in isolation with nothing to relate it to. Yes, it
*absolutely* has to be a tuple of { steal, kvmclock } at the same
moment, much like the Xen runstates are.

I guess the 'set' API might also want a flag to indicate whether the
delta (the time from the kvmclock in the tuple, to the current
kvmclock) should be accounted as stolen or not. Or would it *always* be
stolen?

>  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.

Yeah, maybe. Although when you said above that it might need to be
rearchitected, I was kind of hoping you were planning for KVM to
remember the actual value and not just increment it in guest memory.