Re: [PATCH AUTOSEL 6.18-6.6] KVM: x86/xen: Prevent runstate times from becoming negative

[Sean Christopherson]

On Mon, Oct 19, 2026, Sasha Levin wrote:
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> 
> [ Upstream commit 36a85200643e62d20a91f0bc1a811187b59f7762 ]
> 
> When kvm_xen_update_runstate() is invoked to set a vCPU's runstate, the
> time spent in the previous runstate is accounted. This is based on the
> delta between the current KVM clock time, and the previous value stored
> in vcpu->arch.xen.runstate_entry_time.
> 
> If the KVM clock goes backwards, that delta will be negative. Or, since
> it's an unsigned 64-bit integer, very *large*. Linux guests deal with
> that particularly badly, reporting 100% steal time for ever more (well,
> for *centuries* at least, until the delta has been consumed).
> 
> So when a negative delta is detected, just refrain from updating the
> runstate times until the KVM clock catches up with runstate_entry_time
> again.
> 
> Also clamp steal_ns to delta_ns to prevent steal time from exceeding
> the total elapsed time, and handle negative steal_ns (which can happen
> if run_delay goes backwards across a scheduler update).
> 
> The userspace APIs for setting the runstate times do not allow them to
> be set past the current KVM clock, but userspace can still adjust the
> KVM clock *after* setting the runstate times, which would cause this
> situation to occur.
> 
> Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
> Reviewed-by: Paul Durrant <paul@xxxxxxx>
> Link: https://patch.msgid.link/20260728144954.355376-21-dwmw2@xxxxxxxxxxxxx
> Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> ---

...

> **Step 8.1: DETERMINE WHO IS AFFECTED**
> Xen-ABI KVM guests with runstate/steal enabled (`CONFIG_KVM_XEN` + VMM
> setup). Not all KVM users.
> 
> Record: [config/driver-specific: KVM Xen guests]
> 
> **Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
> 1. `KVM_SET_CLOCK` (live migration/snapshot) after runstate SET_ATTR —
>    documented, exists in this tree
> 2. kvmclock discontinuities from masterclock re-snapshot — still present
>    here; the rest of the series is **not**
> 3. `run_delay < last_steal` unsigned wrap (ioctl uses VMM `current`;
>    vCPU path uses the vCPU task)
> 
> Unprivileged guest cannot call `KVM_SET_CLOCK`; the VMM can. Guest then
> sees broken steal forever.
> 
> Record: [migration/SET_CLOCK and steal wrap] [realistic in production
> Xen-on-KVM] [VMM-triggered, guest-visible]
> 
> **Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
> Not a host oops. Guest scheduler steal accounting becomes permanently
> wrong (100% steal for ~centuries). That breaks guest CPU accounting,
> load, and can stall workloads/watchdogs. **HIGH** for those guests (not
> host CRITICAL).
> 
> Record: [guest steal corruption / apparent 100% steal] [HIGH]
> 
> **Step 8.4: CALCULATE RISK-BENEFIT RATIO**
> Benefit: stops a permanent guest-visible accounting failure on a path
> used in migration. Risk: ~20 lines, no locking/API change, skip-
> accounting is conservative.
> 
> Record: [high benefit for Xen-on-KVM] [very low risk] [favorable]

Two questions: do we care abou this specific flaw, and does anyone run Xen guests
with KVM using an LTS kernel?  I agree with AI's assessment that this is low risk,
but unless this will actually benefit someone, I don't see the point.