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
