From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1DD6175A79 for ; Wed, 1 Apr 2026 21:16:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775078182; cv=none; b=UmGuzZX2FDaZVbFHyntgd1sD8aU14/cToJCqi1Sz6MWxW+vmnIooD02fr7uYZbSky3dh+fSOk1DT+Q+wT9rKy2mnf8cqblZARTiE8pN+0r54uQpXRiM/+6ImNWaaeZRGvXvA6AD8qz9s0jYcnNG9XYfdewujseuw9bZCavP+1pI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775078182; c=relaxed/simple; bh=l6iX1nTTLN/2uZkvSFq8geykaFQBjso9ZjDDB1VMUM8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ae4T3oC+p63w6iDRV0BT5mhlKHKQjP6oQs5rVi8Ou+SYWU2nKrDidvXURa+lR7bmiyPb62Mf/g1+mdVdYqM/luho8F59VPMoErv6CTxLHiQGwG0bUopSLO+hQaLPT2khFxkO4UWThZH9XavtKkx9+gcCFY+7CzsDWiGEe32ZJak= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=QvsIVPub; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QvsIVPub" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-82ce1c395ccso441934b3a.2 for ; Wed, 01 Apr 2026 14:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775078181; x=1775682981; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ebhOtBJLLq955jMRQ0doD/9JGBRayn9HmmZNW0XQhFg=; b=QvsIVPublX4qQPIgSGS1MDedO5t2sI5YArEUv7IyNTNF0PxhUFSFdBicnH7j5RWAHu 9mBrW1wvCxJ68CFHF8gy8WSFf8FZjkas3YXJ7D27jzfTlJshdkkSKwr/iDZLKvyfu+Qy q81ISHQFWIyjUj3QithW670sR4PtNqYaJHWKtQbnrudr+lgiuYYMx8Z+4UpNzl66k9Q3 02LNaH2mVEX7Tdhc4lcyephislGwaYHj4ibptbpTwXSM9wCfUTBSQ77jg5GhsproJ/aI ycieIL7iEgorfS5juVtutoFRddQ4s2t5zZzNJkZFC/H7f/w2eZ3jdYzB6l9NdeFdV4/Z NrlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775078181; x=1775682981; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ebhOtBJLLq955jMRQ0doD/9JGBRayn9HmmZNW0XQhFg=; b=hEBzWV85VXPkl4xRLHEFcW3HlS7hGnHQhpprtJe6toIPPEiJfhPump9fZ+Y8pETpKQ c3KfDCu8KcMhtHrTaPSO8ZIfSiu1NTg2pIYINdiurUnJJzMAAMRzExUfICrgrIoa+VQ3 Cihm70PFycP7cLvz7pdF48+dfAHpAVnBk6lUqo+f2PgT2TstiNSuMlIXiFOUuLT/KbzG sJgXLEK/FI3nbSE9rskKWNhkesvHHaNApagXcol2lhStE2/upwdLwWz2EEScxIOSjyi4 dHgaMS9NV4rwg+F75B5sComN9Fbun0D0pdljYjl3vExetug72lfCnrRuWbAdsDs6e3P3 /89Q== X-Forwarded-Encrypted: i=1; AJvYcCXCcmWTl1Iitw+afo51MRPmfsKjjsUnM1Rn9CydJFv4DGIj7njyY3trQwiGl7enIyeV4vWitKKCeKTtO9w=@vger.kernel.org X-Gm-Message-State: AOJu0YzFrbBn7j+TfPI+Evf6W04tWRrtlv+f/BqWsTlAsfk4crhX4N+f a29cW+S0DafByA1lXETpjHxF/klVNgGGB3V6zvT5D/hqUIRgxJE22/wsFLGQwb5fw0vXQ5l5Nr8 lsqdwog== X-Received: from pfwy21.prod.google.com ([2002:a05:6a00:1c95:b0:82c:e41e:8959]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:8b84:b0:82c:ec1b:9e15 with SMTP id d2e1a72fcca58-82cec1ba300mr3372988b3a.1.1775078180972; Wed, 01 Apr 2026 14:16:20 -0700 (PDT) Date: Wed, 1 Apr 2026 14:16:19 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: Message-ID: Subject: Re: [REGRESSION 6.19, BISECTED] KVM: x86: kvmclock rate-limit removal causes IPI storm and high guest steal time From: Sean Christopherson To: Lei Chen Cc: Jaroslav Pulchart , kvm@vger.kernel.org, LKML , pbonzini@redhat.com, Igor Raits , Jan Cipa Content-Type: text/plain; charset="us-ascii" On Wed, Apr 01, 2026, Lei Chen wrote: > Hi Jaroslav, > > I apologize for the late reply. > > I have reviewed the code and identified two scenarios that currently > trigger the KVM_REQ_GLOBAL_CLOCK_UPDATE request: > > Scenario 1: kvm_write_system_time > This code path occurs when the hypervisor (such as QEMU) adjusts the > time, or when the guest writes to the TSC. > > Scenario 2: vcpu schedule in kvm_arch_vcpu_load > If this function triggers KVM_REQ_GLOBAL_CLOCK_UPDATE, it indicates > that the virtual machine is not using the master_clock. > > Those two cases are uncommon. Could you please provide your dmesg and > help check which code path triggers KVM_REQ_GLOBAL_CLOCK_UPDATE? I'm also mildly curious as to why KVM_REQ_GLOBAL_CLOCK_UPDATE is being triggered, but I don't know that it matters. E.g. fixing the underlying flaw (if one even exists) could fix Jaroslav's setup, but it won't fix setups where the "uncommon" cases are unavoidable, e.g. on setups that _can't_ use a master clock for whatever reason. At a glance, explicitly ratelimiting kvm_gen_kvmclock_update() seems like the simplest option to address the regression.