From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCB5E606A335 for ; Wed, 11 Nov 2026 10:08:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=VFW7j0bR; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=V2AKnn9t 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-Unsubscribe-Post:List-Owner; bh=H3Ry/FbjG7A2sh6BAhOs+YbZP+AAuJe7onGIRnzyJ68=; b=VFW7j0bR1kjZ4fXqqVqi3nz5yU cXwrUAGv0sy8mUQrhgpBUlwkV3UNHh5dPCMHR0+5OjAF7a7TNPjwYeFyK7sUVO88gkAuWD4dzkFcO qHd8jnnCMZZhOIB0V8RhRot9j3PH1cWD3MEB1JDeWhDiUQgn8LxFDWlx2rZLBTHgmJl2hDdZp/x+n xNqYf01GOzZu+gfN4HBnYG4fD4tGFFj4Bb1OGYCBlEqO4UhiNC9Q/9dmGoUFDe6g+XNS5LjWJa03l lAGZfmJzvFYgOD6m+Vy5vHPlnRfQRTqJNDc9vnvTijMoSDJz4udDlgwwFDgycHDcCSkRZFAA6GwGs ZvKVJzRA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xR5G6-00000006Iit-2bt7; Wed, 11 Nov 2026 10:08:50 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xR5G6-00000006Iin-0GeN for linux-arm-kernel@lists.infradead.org; Wed, 11 Nov 2026 10:08:50 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 6907063C19; Wed, 11 Nov 2026 10:08:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E1DF1F00A0A; Wed, 11 Nov 2026 10:08:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794391729; bh=H3Ry/FbjG7A2sh6BAhOs+YbZP+AAuJe7onGIRnzyJ68=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=V2AKnn9tdnAn6jL8kfwG0cy9iE7vD5xijchVzwwAzjfWIprSbpC5q/oixuEl75VkU gv4mbcMkx5GsmkAw0MnFXj3iYWlOuG3+QcDYWV/XVgIPIK7AKvhcPz14eqUhoIYWGq GMp2pLARv4UVz8ORVuNB99e3DzRZsgP4zg30nFERye8GPA8B4e84ApmUkO6nWoV0+j 7jO2eIL78EpTsQBNT4D9gokF5ekFo1ZKDiYb4BLKtQHyCQ8pN0RuW7NoEiEqMe1Le6 Q5gEWu1c4wchLYe3renNhpnDiGf5ku0AwEKEkF9x5ElZ3r44yxAFEWA2ipnv7gq/tx btV6vc7y+cysQ== 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 1xR5G3-0000000EEJx-0wjw; Wed, 11 Nov 2026 10:08:47 +0000 Date: Wed, 11 Nov 2026 10:08:46 +0000 Message-ID: <86o6bv1xzl.wl-maz@kernel.org> From: Marc Zyngier To: Dan Carpenter Cc: Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, Karthik Bhargavan , =?UTF-8?B?Q2zDqW1lbnQ=?= Blaudeau Subject: Re: [PATCH] KVM: arm64: nv: Invalidate whole L1 blocks on TLBI RIPAS2E1 In-Reply-To: <6817d113e5f0a9cafe0ce5bc0847276b7f14aacc.1794210561.git.dan@cryspen.com> References: <6817d113e5f0a9cafe0ce5bc0847276b7f14aacc.1794210561.git.dan@cryspen.com> 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) X-Archived-By: 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: dan@cryspen.com, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, karthik@pereq.eu, clement@cryspen.com 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-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-15.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 Hi Dan, Thanks for this patch. On Tue, 10 Nov 2026 06:14:20 +0000, Dan Carpenter wrote: > > The shadow stage-2 can map one of the L1's stage-2 blocks with several > smaller leaves. This happens when the host backs the memory with > smaller pages, when the memslot is dirty logging, or when the L1 block > size falls between two host block sizes. > > When the L1 invalidates part of such a block, handle_ripas2e1is() only > unmaps the requested range, so the shadow leaves for the rest of the > block stay valid. A TLBI must remove every TLB entry for a block it > touches, including the parts outside the range. The L1 does not need > to issue another TLBI before reusing the rest of the block, so the L2 > can still reach those pages through the stale shadow entries. > > Use compute_tlb_inval_range() in s2_mmu_unmap_range() to find the L1 > block size, the same as the IPAS2E1 path does, and widen the range to > whole L1 blocks. The other caller, handle_vmalls12e1is(), unmaps the > whole IPA space, so the widening does not change anything there. > > This only affects nested virtualization: the host must be booted with > kvm-arm.mode=nested and the VM must be given a virtual EL2. In such a > VM it breaks the isolation that the L1 hypervisor provides. An L2 can > keep reading and writing pages that the L1 has taken back and reused, > either for itself or for another L2. The host, other VMs and VMs > without nested virtualization are not affected, because the shadow > stage-2 only maps the L1 VM's own memory. > > Fixes: 5d476ca57d7d ("KVM: arm64: nv: Add handling of range-based TLBI operations") > Cc: stable@vger.kernel.org > Signed-off-by: Dan Carpenter > --- > This is part of our formal analysis work at Pereq. I'm not super > familiar with this code. Claude wrote a self test that I used to > test, but it's crap and not worth preserving. Is there any chance you could get Claude to decrapify the self-test? This is the sort of things that would be very valuable to have in our toolbox. > > I also considered widening the range in handle_ripas2e1is(). We would > need to use the largest block size in that scenario and it seemed like > it might hurt performance. It would probably result in over-invalidation, and only benefit guests that play terrible games (multiple S2s tagged with the same VMID). We're better off just computing the correct range for the given MMU context as you are doing here. > > arch/arm64/kvm/sys_regs.c | 13 ++++++++++++++-- > 1 file changed, 12 insertions(+), 1 deletions(-) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 3d3f4eb82fbd..e1a687dfeea7 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -4116,6 +4116,17 @@ union tlbi_info { > static void s2_mmu_unmap_range(struct kvm_s2_mmu *mmu, > const union tlbi_info *info) > { > + u64 start = info->range.start; > + u64 end = start + info->range.size; > + > + /* > + * An L1 stage-2 block may be held in the shadow S2 as several smaller > + * leaves, and R_TVTYQ requires the TLBI to invalidate all of them, so > + * widen each end of the range to the L1 block containing it. > + */ > + start = ALIGN_DOWN(start, compute_tlb_inval_range(mmu, start >> 12)); > + end = ALIGN(end, compute_tlb_inval_range(mmu, (end - 1) >> 12)); > + > /* > * The unmap operation is allowed to drop the MMU lock and block, which > * means that @mmu could be used for a different context than the one > @@ -4139,7 +4150,7 @@ static void s2_mmu_unmap_range(struct kvm_s2_mmu *mmu, > * the L1 needs to put its stage-2 in a consistent state before doing > * the TLBI. > */ > - kvm_stage2_unmap_range(mmu, info->range.start, info->range.size, true); > + kvm_stage2_unmap_range(mmu, start, end - start, true); > } > > static bool handle_vmalls12e1is(struct kvm_vcpu *vcpu, struct sys_reg_params *p, The only snag here is that we end-up with two extra walks for the (pretty common) TLBI VMALLS12E1* case (which by definition covers the whole IPA space). I don't think I'll lose any sleep over it, but it may come back to bite us at a later point. In any case, I'll queue this. Thanks, M. -- Without deviation from the norm, progress is not possible.