On Mon, Aug 17, 2026 1:15:02AM -0700, Marc Zyngier wrote:
> On Sun, 16 Aug 2026 06:33:01 +0100,
> Dongli Zhang <[email protected]> wrote:
>
> [...]
>
>> 4. Guest kernel changes are not included. I may send it separately to keep
>> this series limited to the KVM hypervisor.
>
> Hold on. Do you mean you are changing the guest visible behaviour of a
> PV interface? That's an ABI. It *cannot* change unilaterally.
No, this does not change the ABI.
Taking x86 as an example, the Linux guest currently does not reset the stealtime
accounting metadata, i.e. rq->prev_steal_time and rq->prev_steal_time_rq, when a
vCPU is brought online. I meant to reset that metadata before enabling KVM x86
steal time via MSR_KVM_STEAL_TIME, so that the guest is not affected by a stale
steal-time value from before the vCPU was offlined.
For example, in the code below, the guest resets rq->prev_steal_time and
rq->prev_steal_time_rq after enabling KVM steal time via MSR_KVM_STEAL_TIME.
[PATCH 1/5] x86/kvm: Reset prev_steal_time and prev_steal_time_rq when enabling
steal time
https://lore.kernel.org/all/[email protected]
+void sched_steal_time_cpu_init(int cpu, u64 steal)
+{
+ struct rq *rq = cpu_rq(cpu);
+
+ rq->prev_steal_time = steal;
+#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
+ rq->prev_steal_time_rq = steal;
+#endif
+}
+
#ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
static u64 native_steal_clock(int cpu)
{
@@ -337,6 +354,12 @@ static void kvm_register_steal_time(void)
return;
wrmsrq(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
+
+ /*
+ * This CPU is not ready to be scheduled yet.
+ */
+ sched_steal_time_cpu_init(cpu, kvm_steal_clock(cpu));
+
pr_debug("stealtime: cpu %d, msr %llx\n", cpu,
(unsigned long long) slow_virt_to_phys(st));
}
>
>>
>> [PATCH 1/5] x86/kvm: Reset prev_steal_time and prev_steal_time_rq when
>> enabling steal time
>> https://urldefense.com/v3/__https://lore.kernel.org/all/[email protected]__;!!ACWV5N9M2RV99hQ!Kt5J7E63dvSlZsI1Ovt02JMZuh0BwYZZupi0BMQXDxnYkQ6iPNwB7tuWgd7wSVOEVHCF40thrD8Apg$
>>
>>
>> 5. There is one remaining corner case: this series resets last_steal when
>> the vCPU run PID changes, but not when steal time is enabled. If additional
>> host run_delay is accumulated after the PID changes but before the guest
>> enables steal time, that delta could be unexpectedly accounted to guest
>> vCPU steal time. In practice, this should not happen for Linux guests.
>
> Why is Linux immune to this? Also, KVM does not cater for Linux guests
> only.
I should have explained this more clearly.
I did not mean that Linux is immune in the architectural sense, or that KVM
should rely on Linux guest behavior. The corner case I had in mind is:
1. The vCPU is run by a new host PID, so KVM resets last_steal to the new PID's
current run_delay.
2. The guest has not enabled steal time yet.
3. The new host task accumulates additional run_delay before the guest enables
steal time.
4. When steal time is later enabled, that pre-enable run_delay can be included
in the first stealtime update.
For the Linux guest on QEMU/KVM x86 path, this window should normally be very
small. For example, on x86, a Linux guest enables KVM steal time immediately
from the CPU online path. Also, QEMU does not enter KVM_RUN for an offline
vCPU, so the normal QEMU/KVM hotplug path leaves little opportunity to
accumulate run_delay before steal time is enabled.
Thank you very much!
Dongli Zhang
