From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B75FC5AD4E for ; Sun, 9 Aug 2026 18:14:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=biTFnHYssGz2lOpfbiM0gbuJjSJ8jehqLOBv/83u8vw=; b=ipezUIBvXFlcCE7YWJlmiXQapK HJux1hRC7lk3CQXxeqqm8TeY76j2Hme1cdKJBHpUSzkOcAxXntNDta63PQSlEhx2U0YmU5QIbBWDE daf/bgCwLFq1/7gRjCB8Lxr3kAfaicn7ZNI2hZjNzfRl6zA2Z2oK8tz9tOG3u4MqhTWhPlF3BpYKd MJedp1am3OIyAJwz0rci/G0P5WduYTg1IehITaM7mlKECA+sBUMLhgNBztWNLmD/a7gXBRAoPcv19 eRGwRWSR1qFyKe58ClwN7fBkY1L73vjSvurpMJvclPEVg8Nla1QOz4GdU/befwzx4rNGfnj6ED9GC Mgs15oHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wt81u-0000000AZdw-3Cjp; Sun, 09 Aug 2026 18:13:50 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wt81u-0000000AZdg-19XF for linux-arm-kernel@lists.infradead.org; Sun, 09 Aug 2026 18:13:50 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id B1A6F600AB; Sun, 9 Aug 2026 18:13:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65E8D1F000E9; Sun, 9 Aug 2026 18:13:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786299228; bh=biTFnHYssGz2lOpfbiM0gbuJjSJ8jehqLOBv/83u8vw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=kjNLuZi2b1RsQVaRFK1bSD6X7nIkB4Dli17pb/LGlSEBvF3T/sDZOGFsretR42kSV wfMKL5jUnxzLGVbNoVkofQHLAFK10I8QOAc1PA+U4i4Jy55JdB1UncbJsnGcAho9jH EloTpMI54D3UMfCNpm41l+YYurA97l04T/UPRICR9fQzCqMeR/8QcAVY+plmjFToVA 4cCb4cTe0X5Of+sSkA7cDQmcCZM/aIgmWAhI4E+K8vDBu3xKxU2ZZe6Y7TOtxrGnA6 HaPhet94swK2y7INulQrC9b+P7Q15l5+x6EkiNNz9vxUi9cADr+JPKxA1rwOWLser1 XV5otCA4iUpOQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wt81p-0000000DsoJ-33u9; Sun, 09 Aug 2026 18:13:45 +0000 Date: Sun, 09 Aug 2026 19:13:45 +0100 Message-ID: <86wltz9n6u.wl-maz@kernel.org> From: Marc Zyngier To: Wei-Lin Chang Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Steffen Eiden , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Fuad Tabba , Hyunwoo Kim , Yao Yuan , ljs@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2 4/8] KVM: arm64: Correctly handle end of VA space TLBI invalidation In-Reply-To: References: <20260806091026.620700-1-maz@kernel.org> <20260806091026.620700-5-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: weilin.chang@arm.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, seiden@linux.ibm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, fuad.tabba@linux.dev, imv4bel@gmail.com, yaoyuan@linux.alibaba.com, ljs@kernel.org, stable@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 08 Aug 2026 22:41:31 +0100, Wei-Lin Chang wrote: > > Hi Marc, > > On Thu, Aug 06, 2026 at 10:10:22AM +0100, Marc Zyngier wrote: > > Our TLB invalidation by VA code is based on comparing two ranges, > > one defined by the TLB, and one defined by the TLBI instruction. > > > > Each range is defined by a start and a size. However, the way the > > comparison is done doesn't account for address rollover, as it > > compares an address with (base + size). This works nicely until > > this expression represent the last page/block in the TTBR1 VA space, > > as the result is a big fat 0. And a failed TLB invalidation. > > > > Rewrite the comparison in a way that is immune to the address > > rollover (making the end address inclusive instead of exclusive), > > and move this into a common helper that is used by both VA and IPA > > invalidations, as suggested by Hyunwoo Kim (although the IPA version > > didn't suffer from this particular problem, obviously). > > > > Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") > > Reviewed-by: Yuan Yao > > Signed-off-by: Marc Zyngier > > Cc: stable@vger.kernel.org > > --- > > arch/arm64/kvm/nested.c | 43 ++++++++++++++++++----------------------- > > 1 file changed, 19 insertions(+), 24 deletions(-) > > > > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c > > index 27bc7ee4b3382..8a602d074dbb4 100644 > > --- a/arch/arm64/kvm/nested.c > > +++ b/arch/arm64/kvm/nested.c > > @@ -999,6 +999,20 @@ static void invalidate_vncr(struct vncr_tlb *vt) > > clear_fixmap(vncr_fixmap(vt->cpu)); > > } > > > > +static bool vncr_tlb_intersects(struct vncr_tlb *vt, u64 addr, > > + u64 scope_start, u64 scope_size) > > +{ > > + u64 tlb_size, tlb_start, tlb_end, scope_end; > > + > > + tlb_size = ttl_to_size(pgshift_level_to_ttl(vt->wi.pgshift, vt->wr.level)); > > + > > + tlb_start = addr & ~(tlb_size - 1); > > + tlb_end = tlb_start + tlb_size - 1; > > + scope_end = scope_start + scope_size - 1; > > I think if scope_end overflows, > > > + > > + return !(tlb_end < scope_start || tlb_start > scope_end); > > tlb_start > scope_end can evaluate to true and we return false even when > there is overlap near the end of the TTBR1 address space. I assume that you are implicitly talking about TLB Range Invalidation, right? Because we otherwise align base on size, making overflows impossible with this patch. > Therefore I think we need to saturate scope_end to ULONG_MAX when overflow > happens. This is also what the architecture does when looking at the > pseudocode J1.2.3.442 TLBIRange (M.c). That's one possible implementation, because the pseudocode is dealing with start/end directly, but that's not how our scope works (it deals with start and size). For that we need to cap the *size*, similarly to what is done in handle_ripas2e1is() (see patch #6). Something like the hack below. M. diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h index 21d0f4cbe07f1..5b8edb2e8a87d 100644 --- a/arch/arm64/include/asm/kvm_nested.h +++ b/arch/arm64/include/asm/kvm_nested.h @@ -305,6 +305,12 @@ static inline u64 decode_range_tlbi(u64 val, u64 *range, u16 *asid) num = FIELD_GET(GENMASK(43, 39), val); *range = __TLBI_RANGE_PAGES(num, scale) << shift; + /* Cap the range to the correct half of the address space */ + if (!(base & BIT(48))) + *range = min(*range, (BIT(48) - base)); + else + *range = min(*range, ~base + 1); + return base; } -- Without deviation from the norm, progress is not possible.