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]/
smime.p7s
Description: S/MIME cryptographic signature
