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

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


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]/