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 2529FC55174 for ; Sat, 8 Aug 2026 09:05:19 +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=BcQpUXzQNF+2Q+6o8/0P7HWncW1idJum/qJtU1Voeqo=; b=4NvVV4dZYQw809mLFu5rAIPLoM g1pzbr5mPi4ih6Z3tCZ9p9e8lYj2CjJbBRohgnPaXJn9T8ZbW283O5tOk4hy7zELO0WPmzq//znVx ZWMJ9IbAaziMhP4u6Dgqu0m5ezT70LIDlNCSBQOaXB9KTV0R0D3eg4n7MnEzsW3rcJIYkZOTDTDDs 0yUfTru+59HjF7z91mVX6wbzjXz4wW4ajwY3AyATTZS5wGkt5X49hmKBZefc395HUtE7JLl7OvbbG tVziyN+J+omfm8L0C8/PbWqPC1luQKoNY85s5u/C8ysS3HbpV9sHud5XCUWC/K94WArU2A8pJyamJ PjYEecSg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wsczQ-00000009CNA-3GUP; Sat, 08 Aug 2026 09:05:12 +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 1wsczP-00000009CMv-2DmO for linux-arm-kernel@lists.infradead.org; Sat, 08 Aug 2026 09:05:11 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 3AF636001A; Sat, 8 Aug 2026 09:05:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E52511F000E9; Sat, 8 Aug 2026 09:05:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786179909; bh=BcQpUXzQNF+2Q+6o8/0P7HWncW1idJum/qJtU1Voeqo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=lkTGYsW1dZasSDUaE9oKcDoNEJuYeo3oNBSycdPzNb9GtBwb9fh8lUX1B+hnDKyBN LDjvFM/0hlJaHuObNzAnGsZnYgQ6Kz5WYQLet5RwUGQ4llz7MS5l7gnsLdv9g8dzaU yLEh2e704eiOD488zCQUHBvIQG7J5ZnS2VD8qU/P9Jo9yNeCqtWj4xbJKeTE2L5JbP kMqaNt6gAkTOJ1M8o+gXFvUDS5a3VNavTNH0OSydcHIwS/Uy7/qUkirAk4fmc2oD/H ky4rJojkbfGyDVqbNNFpY0Zy4KKvn6X3ldnkXiJP6ixcVZG0lBS8544tnLqsLIVnv7 VUrSTq3sj8Jsw== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-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 1wsczL-0000000Dd90-3XoN; Sat, 08 Aug 2026 09:05:07 +0000 Date: Sat, 08 Aug 2026 10:06:31 +0100 Message-ID: <87bjbdouaw.wl-maz@kernel.org> From: Marc Zyngier To: "Lorenzo Stoakes (ARM)" 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 , stable@vger.kernel.org Subject: Re: [PATCH v2 2/8] KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation In-Reply-To: References: <20260806091026.620700-1-maz@kernel.org> <20260806091026.620700-3-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: ljs@kernel.org, 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, 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 Fri, 07 Aug 2026 18:12:18 +0100, "Lorenzo Stoakes (ARM)" wrote: [...] > So actually if granularity is TLBI_TTL_TG_4K this will return SZ_1G and 0 in the > other cases unless I'm getting something wrong here? > > This is really more a 'maybe worth mentioning in the commit log to be pedantic' > kind of thing :) > > IOW you could luck out before with SZ_1G for TLBI_TTL_TG_4K. Yes, and that's what happens in most cases. But as Huynwoo Kim's reports, 16k and 64k lead to something really bad. And even 4k works by pure luck, so this is all fsck'd in my book. > > > > > Tidy-up pgshift_level_to_ttl() to handle these negative levels, and > > ttl_to_size() to always return SZ_1G when no valid TTL is present. > > This allows the removal of open-coded checks for similar situations. > > I guess SZ_1G is a reasonable default here? It is more than a reasonable default. It is the maximum block size that can architecturally be mapped in the absence of FEAT_LPA*. In this situation, 16k pages imply a 32M max block mapping, and 64k implies 512M. 4K pages, by virtue of allowing a level-1 block mapping result in a 1G size. > > > > > Note that the check for a negative value not explicitely checking for > > NIT: explicitely -> explicitly > > > S1_MMU_DISABLED is deliberate, so that actual negative levels introduced > > with LVA2 and D128 can take the same path if we ever support them. > > > > Fixes: 7270cc9157f47 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers") > > Reported-by: Hyunwoo Kim > > Link: https://lore.kernel.org/r/ameGoxbn2wzBq2kL@v4bel > > Signed-off-by: Marc Zyngier > > Cc: stable@vger.kernel.org > > --- > > arch/arm64/kvm/nested.c | 26 +++++++++++++++++++------- > > 1 file changed, 19 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c > > index f3c75954cf36c..035cda256e2a5 100644 > > --- a/arch/arm64/kvm/nested.c > > +++ b/arch/arm64/kvm/nested.c > > @@ -505,7 +505,7 @@ int kvm_walk_nested_s2(struct kvm_vcpu *vcpu, phys_addr_t gipa, > > return ret; > > } > > > > -static unsigned int ttl_to_size(u8 ttl) > > +static unsigned int __ttl_to_size(u8 ttl) > > { > > int level = ttl & 3; > > int gran = (ttl >> 2) & 3; > > @@ -561,10 +561,22 @@ static unsigned int ttl_to_size(u8 ttl) > > return max_size; > > } > > > > -static u8 pgshift_level_to_ttl(u16 shift, u8 level) > > +static unsigned int ttl_to_size(u8 ttl) > > +{ > > + return __ttl_to_size(ttl) ?: SZ_1G; > > +} > > Might be worth a comment about the default? It's the architecture. I'm trying hard not to make KVM a running commentary of the ARM ARM ;-). > > > + > > +static u8 pgshift_level_to_ttl(u16 shift, s8 level) > > { > > u8 ttl; > > > > + /* > > + * If we don't have a proper level, fallback to the maximum > > + * size. > > + */ > > + if (level < 0) > > + return 0; > > + > > switch(shift) { > > case 12: > > ttl = TLBI_TTL_TG_4K; > > @@ -675,7 +687,11 @@ unsigned long compute_tlb_inval_range(struct kvm_s2_mmu *mmu, u64 val) > > ttl = get_guest_mapping_ttl(mmu, addr); > > } > > > > - max_size = ttl_to_size(ttl); > > + /* > > + * Don't use the default 1GB fallback, as we can adapt to the > > + * max mapping size we allow at S2. > > + */ > > Being a bit pedantic here but I wonder if simply just to say 'Adapt to the max > mapping size allowed at S2' as the fallback is inferred? Sure. Thanks, M. -- Jazz isn't dead. It just smells funny.