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

[Dongli Zhang <dongli.zhang@oracle.com>]

On Mon, Aug 17, 2026 1:15:02AM -0700, Marc Zyngier wrote:
> On Sun, 16 Aug 2026 06:33:01 +0100,
> Dongli Zhang <dongli.zhang@oracle.com> 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/20260505003044.78693-2-dongli.zhang@oracle.com

+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/20260505003044.78693-2-dongli.zhang@oracle.com__;!!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