From nobody Mon Aug 24 05:05:30 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=infradead.org ARC-Seal: i=1; a=rsa-sha256; t=1783113763; cv=none; d=zohomail.com; s=zohoarc; b=I5cp4BZWI1Y3fP8H23AgwK3qBPVGJNqIwsFWt7eB1kIsRDji/6kZkbl1PiRyVBs761oNdibnT1FXhsyLokZS6dY8DnfD5zUZfWrDdfixo7pzaYfxcUI5xEuJoWFyQ5YYNgt5BT5KgEetmOeSw2SOQsAH57Z7sHD0nTsG+fVHS3c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1783113763; h=Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=V5hQ2fJb27QK5yOdBL7f7A818+T1JNBNilH2QwnYDyE=; b=iaL/Z/QTBudpAruOrkwhRfGUgKCUMGjyq+7qUkzTJE/cPG70fM02GYRv1lkMjEzebj1RUuPTQogzO7nFQWvjhYP+yoM04vp1rxSVDrPMNQsnfxnxQsf9gv2uPrhojrB2eQs1HSkjmvVfantP5LNzx5OwTVzD+HpvH9kBcWasmKU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1783113763526707.0178202169732; Fri, 3 Jul 2026 14:22:43 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1353750.1609444 (Exim 4.92) (envelope-from ) id 1wflKm-00053h-Qm; Fri, 03 Jul 2026 21:22:04 +0000 Received: by outflank-mailman (output) from mailman id 1353750.1609444; Fri, 03 Jul 2026 21:22:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wflKm-00053F-Js; Fri, 03 Jul 2026 21:22:04 +0000 Received: by outflank-mailman (input) for mailman id 1353750; Fri, 03 Jul 2026 21:22:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wflKl-00051Q-Fi for xen-devel@lists.xenproject.org; Fri, 03 Jul 2026 21:22:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wflKk-001t36-Sc; Fri, 03 Jul 2026 23:22:02 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a4827ca-bab6-0a2a0a5309dd-0a2a4503bf3c-18 for ; Fri, 03 Jul 2026 23:22:02 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a4827fa-ec1a-0a2a45030019-5a9b3222b952-3 for ; Fri, 03 Jul 2026 23:22:02 +0200 Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wflKX-0000000AsYF-1TB1; Fri, 03 Jul 2026 21:21:49 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.2 #2 (Red Hat Linux)) id 1wflKX-00000001RPX-0w0H; Fri, 03 Jul 2026 22:21:49 +0100 X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="Sender:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From:Reply-To: Cc:Content-Type:Content-ID:Content-Description; bh=V5hQ2fJb27QK5yOdBL7f7A818+T1JNBNilH2QwnYDyE=; b=UEnwhLQsS2wkPtr1Pd+i9zzOxH sP8ejEvNPTu+HXmRA1IRK2tldo2/gJzqZvVFkblE3k6NJg2illNeTq4r1tIkNMYNlkdWFonJNHdMK mhSmA+bD14VOI9+r+ngRb7JB7fqCDAalnTCht1e3MXaFddIt8qbgkhuau0zS6oAateAvgrEcabeSd 8ssD8QbBlyyz0HmKWi8dhUlItveVTjZXTUCDUvvZgduEIsDDko+7didrcRF7/U9ZjOHxshnYVg5m8 dzZupkJUGPLn1s+4YQMYQSdzXtYuOWrxtKD6MQ0XG4ZFW1ckoKyrimh4GbzgzAMJIyiUdwJSkSu0l 7JBF15DA==; From: David Woodhouse To: Paolo Bonzini , Jonathan Corbet , Shuah Khan , Sean Christopherson , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Vitaly Kuznetsov , Juergen Gross , Boris Ostrovsky , David Woodhouse , Paul Durrant , Jonathan Cameron , Sascha Bischoff , Marc Zyngier , Joey Gouly , Jack Allister , Dongli Zhang , joe.jin@oracle.com, kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org Subject: [PATCH v6 26/36] KVM: x86/xen: Prevent runstate times from becoming negative Date: Fri, 3 Jul 2026 22:18:05 +0100 Message-ID: <20260703212145.343527-27-dwmw2@infradead.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260703212145.343527-1-dwmw2@infradead.org> References: <20260703212145.343527-1-dwmw2@infradead.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-purgate-ID: tlsNG-33051d/1783113722-B59BA5D1-E40BB414/0/0 X-purgate-type: clean X-purgate-size: 3262 X-ZohoMail-DKIM: pass (identity @infradead.org) X-ZM-MESSAGEID: 1783113764532158500 Content-Type: text/plain; charset="utf-8" From: David Woodhouse 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 Reviewed-by: Paul Durrant --- arch/x86/kvm/xen.c | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index 82e34edbfdbd..b1d67ece5db3 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -586,29 +586,45 @@ void kvm_xen_update_runstate(struct kvm_vcpu *v, int = state) { struct kvm_vcpu_xen *vx =3D &v->arch.xen; u64 now =3D get_kvmclock_ns(v->kvm); - u64 delta_ns =3D now - vx->runstate_entry_time; u64 run_delay =3D current->sched_info.run_delay; + s64 delta_ns =3D now - vx->runstate_entry_time; + s64 steal_ns =3D run_delay - vx->last_steal; =20 + /* + * If the vCPU was never run before, its prior state should + * be considered RUNSTATE_offline. + */ if (unlikely(!vx->runstate_entry_time)) vx->current_runstate =3D RUNSTATE_offline; =20 + /* + * If KVM clock went backwards, just update the current runstate + * but don't account any time. Leave entry_time unchanged so the + * next positive delta covers the full period once the clock + * catches up. Update last_steal every time so stolen time only + * reflects the interval since the most recent call. + */ + if (delta_ns < 0) + goto update_guest; + /* * Time waiting for the scheduler isn't "stolen" if the * vCPU wasn't running anyway. */ - if (vx->current_runstate =3D=3D RUNSTATE_running) { - u64 steal_ns =3D run_delay - vx->last_steal; + if (vx->current_runstate =3D=3D RUNSTATE_running && steal_ns > 0) { + if (steal_ns > delta_ns) + steal_ns =3D delta_ns; =20 delta_ns -=3D steal_ns; - vx->runstate_times[RUNSTATE_runnable] +=3D steal_ns; } - vx->last_steal =3D run_delay; =20 vx->runstate_times[vx->current_runstate] +=3D delta_ns; - vx->current_runstate =3D state; vx->runstate_entry_time =3D now; =20 + update_guest: + vx->current_runstate =3D state; + vx->last_steal =3D run_delay; if (vx->runstate_cache.active) kvm_xen_update_runstate_guest(v, state =3D=3D RUNSTATE_runnable); } --=20 2.54.0