From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BA8C10941 for ; Fri, 20 Oct 2023 08:05:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Et5bY+e3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4D57C433C7; Fri, 20 Oct 2023 08:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697789141; bh=pfd6pPJr8ufDxksvc355rpglL5JyMuBGgmvPPJZB+iA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Et5bY+e3P1P1EU69+JoB1ZarBTmZ2k/5KDvUuPeMDOD1Z0QGja08MBydnjU3hhG6f s7+7sQ8Wqe4ZcUEB5YZY7EWIdgbvNt6U4R5l9lDxsjBXTlqi/tdRlmp902PjiaEkXJ 51tD1p1jtnVB46MiZQbjXUqDw3eFosOtkEYtZygqWVHD6VYepnAZ4XQMUzzDJ7Z39n EhYJxPK9rA7r924pNoLDuvDyA/Eelbp7vk9LktUE6r+ucLVK6Gd2AqIAHOWtU7v8by iTt3jBat0ntfGNQJM0zvpuo8s2eFe5J/E83r2MAp7I5wZSaJEVcif6ftlHLBo51PuP cBJfo5HtyTVoA== 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.95) (envelope-from ) id 1qtkVn-0062KV-1d; Fri, 20 Oct 2023 09:05:39 +0100 Date: Fri, 20 Oct 2023 09:05:38 +0100 Message-ID: <86edhpn2gd.wl-maz@kernel.org> From: Marc Zyngier To: Ryan Roberts Cc: Catalin Marinas , Will Deacon , Oliver Upton , Suzuki K Poulose , James Morse , Zenghui Yu , Ard Biesheuvel , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 01/12] arm64/mm: Update non-range tlb invalidation routines for FEAT_LPA2 In-Reply-To: References: <20231009185008.3803879-1-ryan.roberts@arm.com> <20231009185008.3803879-2-ryan.roberts@arm.com> <87zg0f59ae.wl-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/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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: ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, suzuki.poulose@arm.com, james.morse@arm.com, yuzenghui@huawei.com, ardb@kernel.org, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 19 Oct 2023 10:22:37 +0100, Ryan Roberts wrote: > > On 19/10/2023 09:03, Marc Zyngier wrote: > > On Mon, 09 Oct 2023 19:49:57 +0100, > > Ryan Roberts wrote: > >> > >> FEAT_LPA2 impacts tlb invalidation in 2 ways; Firstly, the TTL field in > >> the non-range tlbi instructions can now validly take a 0 value for the > >> 4KB granule (this is due to the extra level of translation). Secondly, > > > > nit: 0 was always valid. It just didn't indicate any level. > > True. I'll change to "can now validly take a 0 value as a TTL hint". > > > > >> the BADDR field in the range tlbi instructions must be aligned to 64KB > >> when LPA2 is in use (TCR.DS=1). Changes are required for tlbi to > >> continue to operate correctly when LPA2 is in use. > >> > >> KVM only uses the non-range (__tlbi_level()) routines. Therefore we only > >> solve the first problem with this patch. > > > > Is this still true? This patch changes __TLBI_VADDR_RANGE() and co. > > It is no longer true that KVM only uses the non-range routines. v6.6 adds a > series where KVM will now use the range-based routines too. So that text is out > of date and I should have spotted it when doing the rebase - I'll fix. KVM now > using range-based ops is the reason I added patch 2 to this series. > > However, this patch doesn't really change __TLBI_VADDR_RANGE()'s behavior, it > just makes it robust to the presence of TLBI_TTL_UNKNOWN, instead of 0 which was > previously used as the "don't know" value. > > > > >> > >> It is solved by always adding the level hint if the level is between [0, > >> 3] (previously anything other than 0 was hinted, which breaks in the new > >> level -1 case from kvm). When running on non-LPA2 HW, 0 is still safe to > >> hint as the HW will fall back to non-hinted. While we are at it, we > >> replace the notion of 0 being the non-hinted seninel with a macro, > >> TLBI_TTL_UNKNOWN. This means callers won't need updating if/when > >> translation depth increases in future. > >> > >> Signed-off-by: Ryan Roberts > >> Reviewed-by: Catalin Marinas > >> --- > >> arch/arm64/include/asm/tlb.h | 9 ++++--- > >> arch/arm64/include/asm/tlbflush.h | 43 +++++++++++++++++++------------ > >> 2 files changed, 31 insertions(+), 21 deletions(-) > >> > >> diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h > >> index 2c29239d05c3..93c537635dbb 100644 > >> --- a/arch/arm64/include/asm/tlb.h > >> +++ b/arch/arm64/include/asm/tlb.h > >> @@ -22,15 +22,16 @@ static void tlb_flush(struct mmu_gather *tlb); > >> #include > >> > >> /* > >> - * get the tlbi levels in arm64. Default value is 0 if more than one > >> - * of cleared_* is set or neither is set. > >> + * get the tlbi levels in arm64. Default value is TLBI_TTL_UNKNOWN if more than > >> + * one of cleared_* is set or neither is set - this elides the level hinting to > >> + * the hardware. > >> * Arm64 doesn't support p4ds now. > >> */ > >> static inline int tlb_get_level(struct mmu_gather *tlb) > >> { > >> /* The TTL field is only valid for the leaf entry. */ > >> if (tlb->freed_tables) > >> - return 0; > >> + return TLBI_TTL_UNKNOWN; > >> > >> if (tlb->cleared_ptes && !(tlb->cleared_pmds || > >> tlb->cleared_puds || > >> @@ -47,7 +48,7 @@ static inline int tlb_get_level(struct mmu_gather *tlb) > >> tlb->cleared_p4ds)) > >> return 1; > >> > >> - return 0; > >> + return TLBI_TTL_UNKNOWN; > >> } > >> > >> static inline void tlb_flush(struct mmu_gather *tlb) > >> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h > >> index b149cf9f91bc..e688246b3b13 100644 > >> --- a/arch/arm64/include/asm/tlbflush.h > >> +++ b/arch/arm64/include/asm/tlbflush.h > >> @@ -94,19 +94,22 @@ static inline unsigned long get_trans_granule(void) > >> * When ARMv8.4-TTL exists, TLBI operations take an additional hint for > >> * the level at which the invalidation must take place. If the level is > >> * wrong, no invalidation may take place. In the case where the level > >> - * cannot be easily determined, a 0 value for the level parameter will > >> - * perform a non-hinted invalidation. > >> + * cannot be easily determined, the value TLBI_TTL_UNKNOWN will perform > >> + * a non-hinted invalidation. Any provided level outside the hint range > >> + * will also cause fall-back to non-hinted invalidation. > >> * > >> * For Stage-2 invalidation, use the level values provided to that effect > >> * in asm/stage2_pgtable.h. > >> */ > >> #define TLBI_TTL_MASK GENMASK_ULL(47, 44) > >> > >> +#define TLBI_TTL_UNKNOWN (-1) > > > > I find this value somehow confusing, as it represent an actual level > > number. It just happen to be one that cannot be provided as a TTL. So > > having that as a return value from tlb_get_level() isn't great, and > > I'd rather have something that cannot be mistaken for a valid level. > > OK, how about INT_MAX? Works for me. > > > > >> + > >> #define __tlbi_level(op, addr, level) do { \ > >> u64 arg = addr; \ > >> \ > >> if (cpus_have_const_cap(ARM64_HAS_ARMv8_4_TTL) && \ > >> - level) { \ > >> + level >= 0 && level <= 3) { \ > >> u64 ttl = level & 3; \ > >> ttl |= get_trans_granule() << 2; \ > >> arg &= ~TLBI_TTL_MASK; \ > >> @@ -134,16 +137,17 @@ static inline unsigned long get_trans_granule(void) > >> * [BADDR, BADDR + (NUM + 1) * 2^(5*SCALE + 1) * PAGESIZE) > >> * > >> */ > >> -#define __TLBI_VADDR_RANGE(addr, asid, scale, num, ttl) \ > >> - ({ \ > >> - unsigned long __ta = (addr) >> PAGE_SHIFT; \ > >> - __ta &= GENMASK_ULL(36, 0); \ > >> - __ta |= (unsigned long)(ttl) << 37; \ > >> - __ta |= (unsigned long)(num) << 39; \ > >> - __ta |= (unsigned long)(scale) << 44; \ > >> - __ta |= get_trans_granule() << 46; \ > >> - __ta |= (unsigned long)(asid) << 48; \ > >> - __ta; \ > >> +#define __TLBI_VADDR_RANGE(addr, asid, scale, num, ttl) \ > >> + ({ \ > >> + unsigned long __ta = (addr) >> PAGE_SHIFT; \ > >> + unsigned long __ttl = (ttl >= 1 && ttl <= 3) ? ttl : 0; \ > >> + __ta &= GENMASK_ULL(36, 0); \ > >> + __ta |= __ttl << 37; \ > >> + __ta |= (unsigned long)(num) << 39; \ > >> + __ta |= (unsigned long)(scale) << 44; \ > >> + __ta |= get_trans_granule() << 46; \ > >> + __ta |= (unsigned long)(asid) << 48; \ > >> + __ta; \ > >> }) > >> > >> /* These macros are used by the TLBI RANGE feature. */ > >> @@ -216,12 +220,16 @@ static inline unsigned long get_trans_granule(void) > >> * CPUs, ensuring that any walk-cache entries associated with the > >> * translation are also invalidated. > >> * > >> - * __flush_tlb_range(vma, start, end, stride, last_level) > >> + * __flush_tlb_range(vma, start, end, stride, last_level, tlb_level) > >> * Invalidate the virtual-address range '[start, end)' on all > >> * CPUs for the user address space corresponding to 'vma->mm'. > >> * The invalidation operations are issued at a granularity > >> * determined by 'stride' and only affect any walk-cache entries > >> - * if 'last_level' is equal to false. > >> + * if 'last_level' is equal to false. tlb_level is the level at > >> + * which the invalidation must take place. If the level is wrong, > >> + * no invalidation may take place. In the case where the level > >> + * cannot be easily determined, the value TLBI_TTL_UNKNOWN will > >> + * perform a non-hinted invalidation. > >> * > >> * > >> * Finally, take a look at asm/tlb.h to see how tlb_flush() is implemented > >> @@ -442,9 +450,10 @@ static inline void flush_tlb_range(struct vm_area_struct *vma, > >> /* > >> * We cannot use leaf-only invalidation here, since we may be invalidating > >> * table entries as part of collapsing hugepages or moving page tables. > >> - * Set the tlb_level to 0 because we can not get enough information here. > >> + * Set the tlb_level to TLBI_TTL_UNKNOWN because we can not get enough > >> + * information here. > >> */ > >> - __flush_tlb_range(vma, start, end, PAGE_SIZE, false, 0); > >> + __flush_tlb_range(vma, start, end, PAGE_SIZE, false, TLBI_TTL_UNKNOWN); > >> } > >> > >> static inline void flush_tlb_kernel_range(unsigned long start, unsigned long end) > > > > It feels like this range stuff would be better located in the second > > patch. Not a huge deal though. > > As I said, this is the minimal change to the range-based side of things to > robustly deal with the introduction of TLBI_TTL_UNKNOWN. > > But I wonder if I'm actually better of squashing both of the 2 patches into one. > The only reason I split it previously was because KVM was only using the > level-based ops. Maybe. There is something to be said about making the range rework (decreasing scale) an independent patch, as it is a significant change on its own. But maybe the rest of the plumbing can be grouped together. Thanks, M. -- Without deviation from the norm, progress is not possible. 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 4D4F9CDB474 for ; Fri, 20 Oct 2023 08:06:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qoGCFMOt/95jjgI9bnDJ6NEMRloynwhtNMFQOhmKOkA=; b=YpQzQpqnZiPZA2 yC1gQn/UuwQnIni1GE6n44Jfl9Pj2AoOyYkKEjDrdM5YLF2eNDiRtXPhDd3jnIFsw6O3hJQuscJPL x/mdw1WwN4bgelRBMV0tKj9/vWw218GvxAwbmoZXOgxPocs801GW9FQdfAt1R6YQOLJlE4wxD9HFh sgHKo57m3fGodB0/JgEOeqGCC4UeSFQquWwaF/ROMnc44gjercFG795OzBSR2Gip9pXgj8gj85Aba M9pfUE6TfWabg5NjYFVckWHIQ5Sb0q0HwBLzNqSELMHrTEAmix+d4Y5WW9A9XGdnUfxkRqCGWYHlZ A6SnT6TE9x7GXZCPdpVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qtkVv-001W0X-1A; Fri, 20 Oct 2023 08:05:47 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qtkVr-001W0B-1k for linux-arm-kernel@lists.infradead.org; Fri, 20 Oct 2023 08:05:45 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2DD6661E09; Fri, 20 Oct 2023 08:05:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4D57C433C7; Fri, 20 Oct 2023 08:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697789141; bh=pfd6pPJr8ufDxksvc355rpglL5JyMuBGgmvPPJZB+iA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Et5bY+e3P1P1EU69+JoB1ZarBTmZ2k/5KDvUuPeMDOD1Z0QGja08MBydnjU3hhG6f s7+7sQ8Wqe4ZcUEB5YZY7EWIdgbvNt6U4R5l9lDxsjBXTlqi/tdRlmp902PjiaEkXJ 51tD1p1jtnVB46MiZQbjXUqDw3eFosOtkEYtZygqWVHD6VYepnAZ4XQMUzzDJ7Z39n EhYJxPK9rA7r924pNoLDuvDyA/Eelbp7vk9LktUE6r+ucLVK6Gd2AqIAHOWtU7v8by iTt3jBat0ntfGNQJM0zvpuo8s2eFe5J/E83r2MAp7I5wZSaJEVcif6ftlHLBo51PuP cBJfo5HtyTVoA== 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.95) (envelope-from ) id 1qtkVn-0062KV-1d; Fri, 20 Oct 2023 09:05:39 +0100 Date: Fri, 20 Oct 2023 09:05:38 +0100 Message-ID: <86edhpn2gd.wl-maz@kernel.org> From: Marc Zyngier To: Ryan Roberts Cc: Catalin Marinas , Will Deacon , Oliver Upton , Suzuki K Poulose , James Morse , Zenghui Yu , Ard Biesheuvel , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 01/12] arm64/mm: Update non-range tlb invalidation routines for FEAT_LPA2 In-Reply-To: References: <20231009185008.3803879-1-ryan.roberts@arm.com> <20231009185008.3803879-2-ryan.roberts@arm.com> <87zg0f59ae.wl-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/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, suzuki.poulose@arm.com, james.morse@arm.com, yuzenghui@huawei.com, ardb@kernel.org, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231020_010543_665899_DBE2B30C X-CRM114-Status: GOOD ( 59.08 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 19 Oct 2023 10:22:37 +0100, Ryan Roberts wrote: > > On 19/10/2023 09:03, Marc Zyngier wrote: > > On Mon, 09 Oct 2023 19:49:57 +0100, > > Ryan Roberts wrote: > >> > >> FEAT_LPA2 impacts tlb invalidation in 2 ways; Firstly, the TTL field in > >> the non-range tlbi instructions can now validly take a 0 value for the > >> 4KB granule (this is due to the extra level of translation). Secondly, > > > > nit: 0 was always valid. It just didn't indicate any level. > > True. I'll change to "can now validly take a 0 value as a TTL hint". > > > > >> the BADDR field in the range tlbi instructions must be aligned to 64KB > >> when LPA2 is in use (TCR.DS=1). Changes are required for tlbi to > >> continue to operate correctly when LPA2 is in use. > >> > >> KVM only uses the non-range (__tlbi_level()) routines. Therefore we only > >> solve the first problem with this patch. > > > > Is this still true? This patch changes __TLBI_VADDR_RANGE() and co. > > It is no longer true that KVM only uses the non-range routines. v6.6 adds a > series where KVM will now use the range-based routines too. So that text is out > of date and I should have spotted it when doing the rebase - I'll fix. KVM now > using range-based ops is the reason I added patch 2 to this series. > > However, this patch doesn't really change __TLBI_VADDR_RANGE()'s behavior, it > just makes it robust to the presence of TLBI_TTL_UNKNOWN, instead of 0 which was > previously used as the "don't know" value. > > > > >> > >> It is solved by always adding the level hint if the level is between [0, > >> 3] (previously anything other than 0 was hinted, which breaks in the new > >> level -1 case from kvm). When running on non-LPA2 HW, 0 is still safe to > >> hint as the HW will fall back to non-hinted. While we are at it, we > >> replace the notion of 0 being the non-hinted seninel with a macro, > >> TLBI_TTL_UNKNOWN. This means callers won't need updating if/when > >> translation depth increases in future. > >> > >> Signed-off-by: Ryan Roberts > >> Reviewed-by: Catalin Marinas > >> --- > >> arch/arm64/include/asm/tlb.h | 9 ++++--- > >> arch/arm64/include/asm/tlbflush.h | 43 +++++++++++++++++++------------ > >> 2 files changed, 31 insertions(+), 21 deletions(-) > >> > >> diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h > >> index 2c29239d05c3..93c537635dbb 100644 > >> --- a/arch/arm64/include/asm/tlb.h > >> +++ b/arch/arm64/include/asm/tlb.h > >> @@ -22,15 +22,16 @@ static void tlb_flush(struct mmu_gather *tlb); > >> #include > >> > >> /* > >> - * get the tlbi levels in arm64. Default value is 0 if more than one > >> - * of cleared_* is set or neither is set. > >> + * get the tlbi levels in arm64. Default value is TLBI_TTL_UNKNOWN if more than > >> + * one of cleared_* is set or neither is set - this elides the level hinting to > >> + * the hardware. > >> * Arm64 doesn't support p4ds now. > >> */ > >> static inline int tlb_get_level(struct mmu_gather *tlb) > >> { > >> /* The TTL field is only valid for the leaf entry. */ > >> if (tlb->freed_tables) > >> - return 0; > >> + return TLBI_TTL_UNKNOWN; > >> > >> if (tlb->cleared_ptes && !(tlb->cleared_pmds || > >> tlb->cleared_puds || > >> @@ -47,7 +48,7 @@ static inline int tlb_get_level(struct mmu_gather *tlb) > >> tlb->cleared_p4ds)) > >> return 1; > >> > >> - return 0; > >> + return TLBI_TTL_UNKNOWN; > >> } > >> > >> static inline void tlb_flush(struct mmu_gather *tlb) > >> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h > >> index b149cf9f91bc..e688246b3b13 100644 > >> --- a/arch/arm64/include/asm/tlbflush.h > >> +++ b/arch/arm64/include/asm/tlbflush.h > >> @@ -94,19 +94,22 @@ static inline unsigned long get_trans_granule(void) > >> * When ARMv8.4-TTL exists, TLBI operations take an additional hint for > >> * the level at which the invalidation must take place. If the level is > >> * wrong, no invalidation may take place. In the case where the level > >> - * cannot be easily determined, a 0 value for the level parameter will > >> - * perform a non-hinted invalidation. > >> + * cannot be easily determined, the value TLBI_TTL_UNKNOWN will perform > >> + * a non-hinted invalidation. Any provided level outside the hint range > >> + * will also cause fall-back to non-hinted invalidation. > >> * > >> * For Stage-2 invalidation, use the level values provided to that effect > >> * in asm/stage2_pgtable.h. > >> */ > >> #define TLBI_TTL_MASK GENMASK_ULL(47, 44) > >> > >> +#define TLBI_TTL_UNKNOWN (-1) > > > > I find this value somehow confusing, as it represent an actual level > > number. It just happen to be one that cannot be provided as a TTL. So > > having that as a return value from tlb_get_level() isn't great, and > > I'd rather have something that cannot be mistaken for a valid level. > > OK, how about INT_MAX? Works for me. > > > > >> + > >> #define __tlbi_level(op, addr, level) do { \ > >> u64 arg = addr; \ > >> \ > >> if (cpus_have_const_cap(ARM64_HAS_ARMv8_4_TTL) && \ > >> - level) { \ > >> + level >= 0 && level <= 3) { \ > >> u64 ttl = level & 3; \ > >> ttl |= get_trans_granule() << 2; \ > >> arg &= ~TLBI_TTL_MASK; \ > >> @@ -134,16 +137,17 @@ static inline unsigned long get_trans_granule(void) > >> * [BADDR, BADDR + (NUM + 1) * 2^(5*SCALE + 1) * PAGESIZE) > >> * > >> */ > >> -#define __TLBI_VADDR_RANGE(addr, asid, scale, num, ttl) \ > >> - ({ \ > >> - unsigned long __ta = (addr) >> PAGE_SHIFT; \ > >> - __ta &= GENMASK_ULL(36, 0); \ > >> - __ta |= (unsigned long)(ttl) << 37; \ > >> - __ta |= (unsigned long)(num) << 39; \ > >> - __ta |= (unsigned long)(scale) << 44; \ > >> - __ta |= get_trans_granule() << 46; \ > >> - __ta |= (unsigned long)(asid) << 48; \ > >> - __ta; \ > >> +#define __TLBI_VADDR_RANGE(addr, asid, scale, num, ttl) \ > >> + ({ \ > >> + unsigned long __ta = (addr) >> PAGE_SHIFT; \ > >> + unsigned long __ttl = (ttl >= 1 && ttl <= 3) ? ttl : 0; \ > >> + __ta &= GENMASK_ULL(36, 0); \ > >> + __ta |= __ttl << 37; \ > >> + __ta |= (unsigned long)(num) << 39; \ > >> + __ta |= (unsigned long)(scale) << 44; \ > >> + __ta |= get_trans_granule() << 46; \ > >> + __ta |= (unsigned long)(asid) << 48; \ > >> + __ta; \ > >> }) > >> > >> /* These macros are used by the TLBI RANGE feature. */ > >> @@ -216,12 +220,16 @@ static inline unsigned long get_trans_granule(void) > >> * CPUs, ensuring that any walk-cache entries associated with the > >> * translation are also invalidated. > >> * > >> - * __flush_tlb_range(vma, start, end, stride, last_level) > >> + * __flush_tlb_range(vma, start, end, stride, last_level, tlb_level) > >> * Invalidate the virtual-address range '[start, end)' on all > >> * CPUs for the user address space corresponding to 'vma->mm'. > >> * The invalidation operations are issued at a granularity > >> * determined by 'stride' and only affect any walk-cache entries > >> - * if 'last_level' is equal to false. > >> + * if 'last_level' is equal to false. tlb_level is the level at > >> + * which the invalidation must take place. If the level is wrong, > >> + * no invalidation may take place. In the case where the level > >> + * cannot be easily determined, the value TLBI_TTL_UNKNOWN will > >> + * perform a non-hinted invalidation. > >> * > >> * > >> * Finally, take a look at asm/tlb.h to see how tlb_flush() is implemented > >> @@ -442,9 +450,10 @@ static inline void flush_tlb_range(struct vm_area_struct *vma, > >> /* > >> * We cannot use leaf-only invalidation here, since we may be invalidating > >> * table entries as part of collapsing hugepages or moving page tables. > >> - * Set the tlb_level to 0 because we can not get enough information here. > >> + * Set the tlb_level to TLBI_TTL_UNKNOWN because we can not get enough > >> + * information here. > >> */ > >> - __flush_tlb_range(vma, start, end, PAGE_SIZE, false, 0); > >> + __flush_tlb_range(vma, start, end, PAGE_SIZE, false, TLBI_TTL_UNKNOWN); > >> } > >> > >> static inline void flush_tlb_kernel_range(unsigned long start, unsigned long end) > > > > It feels like this range stuff would be better located in the second > > patch. Not a huge deal though. > > As I said, this is the minimal change to the range-based side of things to > robustly deal with the introduction of TLBI_TTL_UNKNOWN. > > But I wonder if I'm actually better of squashing both of the 2 patches into one. > The only reason I split it previously was because KVM was only using the > level-based ops. Maybe. There is something to be said about making the range rework (decreasing scale) an independent patch, as it is a significant change on its own. But maybe the rest of the plumbing can be grouped together. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel