From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 668173B52E4 for ; Thu, 26 Feb 2026 18:24:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772130300; cv=none; b=UHS2Jd88xkCPYzsTp+MJ5fSu+mLOr9iodUrC52jpQah/sgjypKIcB3x01VGTtrErKdP+HUePBsm1NrRIdtdzVqCHcejQE1OZeuCv0JEni7vOFFuI4zx2oinD9HSminGfluXN29BRexteXUdaUL1VDQ/ce6kezEmmSqMeOHgICCc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772130300; c=relaxed/simple; bh=k3soXQkk7YLuqSivAHD1V0eG6RUMSXYigk1r/BeTy8Q=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=qbkZI0aJDDMYq+yBeK1I826SKZMPqf7UwSarvD64zKEvLsojCbdUgNvlRumFEWpTCEfgWVx9BwCZFEQEAcztQd/N/TiO3c5eBOefOaYButjKWiber8buZdq7u0WzmEexC6oTVYbxm8YNnLpePaFRiEWbfEW/FNXUklG4gC6yx+g= 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=NGri9AOn; arc=none smtp.client-ip=209.85.214.201 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="NGri9AOn" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2adae76a9d0so13200725ad.2 for ; Thu, 26 Feb 2026 10:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772130298; x=1772735098; 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=X3CnbC2LzEBnADf0H4jNpgSa/BKh2OZoa8tvpC3rGZ8=; b=NGri9AOnE3kuWDz43IjdMITNlyT/meOGX8wlNGKGPqTtFR+MxFkanXJoTwzBnpBsvC A9rHG1yPa8ZOn3oGZbLw0oL7zAhn+OBYXzM+ccRHNTVVTI2R0NXT+xmRpWUMlneyCEGA X+a5fevVuuTAdQtSZy+k+HWIqr1pZ/eoGyOStjThIbzgmFtOuHBnwUVkh3wfoNI8EWpJ bMy2GcRsF/qUN6ZOwyh1Rd3V+S+7uOJqRudqvT+J3/Rnz97XYsgyBqAF3UXF+yYCiQ5D Rxe3mVlMpUXFqfQxR/7GFTTGu5+nqerA0LbSLBwaclNyrpgTv5fYfVDGfrpU/6i03Bxf P+RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772130298; x=1772735098; 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=X3CnbC2LzEBnADf0H4jNpgSa/BKh2OZoa8tvpC3rGZ8=; b=wXlx87RkJQTLUt/2s4bBkAqijbxTrJaZ/BBWBdMQy7I9uSdIlpcKdkCWe002Iu8J5n DYs1skQUx6Qz+oFC4pzqHCwmDGXioK8Ip0poxp/BbPViLu7t5/iEgofDMZQZQZSchtA8 F+Y00TLtE5KyEP8GRjkNwrrLKXTX0FhzcHpLNoQgaSL+C+8OM9Ka4syJkVKgyAkFImBC w5KWuS+T8KFHljKBz3oxns2rqZX6WD+yeONgq9kvK1kYUihtwmtOL21gddOIpHlv7rnO djFK3prVWaXZaUoOtY6lE6oa9kr9YSWyhEIaRnlFi8yqCrvqw5KgMIyzKAEiOWpRpHlp YX4A== X-Forwarded-Encrypted: i=1; AJvYcCV1vv0v/k3KnVGWve+Rf4MDwKq8nAgPNFcXQ+geKJUzH0rHVeHvV0HzDy3cauZQmZSEUanetGEnwlKK0JM=@vger.kernel.org X-Gm-Message-State: AOJu0YyG7YEsYR4GSn2pSdrBMx3xR9St/8/UZYZY6oWPN7VsRjAZ81p2 QAw6wI8Jh4FWhvnpAVZyIrOsu5UG25idZPU7Bo17E1BOrEwRHIKhHkXAugujWJRf9rrdsxnpnOr MbIqKtg== X-Received: from plau11.prod.google.com ([2002:a17:903:304b:b0:2aa:e682:e951]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e849:b0:2a7:d5c0:c659 with SMTP id d9443c01a7336-2ae0305efc8mr36873085ad.5.1772130297522; Thu, 26 Feb 2026 10:24:57 -0800 (PST) Date: Thu, 26 Feb 2026 10:24:55 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260202074557.16544-1-lance.yang@linux.dev> <20260202074557.16544-4-lance.yang@linux.dev> Message-ID: Subject: Re: [PATCH v4 3/3] x86/tlb: add architecture-specific TLB IPI optimization support From: Sean Christopherson To: Lance Yang Cc: akpm@linux-foundation.org, david@kernel.org, dave.hansen@intel.com, dave.hansen@linux.intel.com, ypodemsk@redhat.com, hughd@google.com, will@kernel.org, aneesh.kumar@kernel.org, npiggin@gmail.com, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, arnd@arndb.de, lorenzo.stoakes@oracle.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, shy828301@gmail.com, riel@surriel.com, jannh@google.com, jgross@suse.com, pbonzini@redhat.com, boris.ostrovsky@oracle.com, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ioworker0@gmail.com Content-Type: text/plain; charset="us-ascii" On Thu, Feb 26, 2026, Lance Yang wrote: > On 2026/2/26 04:11, Sean Christopherson wrote: > > On Mon, Feb 02, 2026, Lance Yang wrote: > > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c > > > index 37dc8465e0f5..6a5e47ee4eb6 100644 > > > --- a/arch/x86/kernel/kvm.c > > > +++ b/arch/x86/kernel/kvm.c > > > @@ -856,6 +856,12 @@ static void __init kvm_guest_init(void) > > > #ifdef CONFIG_SMP > > > if (pv_tlb_flush_supported()) { > > > pv_ops.mmu.flush_tlb_multi = kvm_flush_tlb_multi; > > > + /* > > > + * KVM's flush implementation calls native_flush_tlb_multi(), > > > + * which sends real IPIs when INVLPGB is not available. > > > > Not on all (virtual) CPUs. The entire point of KVM's PV TLB flush is to elide > > the IPIs. If a vCPU was scheduled out by the host, the guest sets a flag and > > relies on the host to flush the TLB on behalf of the guest prior to the next > > VM-Enter. > > Ah, I see. Thanks for the correction! > > KVM only sends IPIs to running vCPUs; preempted ones are left out of the mask > and flushed on VM-Enter. So the old comment was wrong ... > > IIUC, we still set the flag to true because only running vCPUs can be in a > software/lockless walk, and they all get the IPI, so the flush is enough. > > Does that match what you had in mind? No, because from the guest kernel's perspective, the vCPU is running. The kernel can't make any assumptions about what code the vCPU was executing when the vCPU was preempted by the host scheduler, i.e. it's entirely possible the vCPU is in a software/lockless walk.