From: Catalin Marinas <catalin.marinas@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Ard Biesheuvel <ardb@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH v2 01/12] arm64/mm: Update non-range tlb invalidation routines for FEAT_LPA2
Date: Wed, 12 Apr 2023 16:47:35 +0100 [thread overview]
Message-ID: <ZDbSl8vccLiMCrDz@arm.com> (raw)
In-Reply-To: <20230306195438.1557851-2-ryan.roberts@arm.com>
On Mon, Mar 06, 2023 at 07:54:27PM +0000, 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,
> 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.
There are some patches on the list to add support for range invalidation
in KVM:
https://lore.kernel.org/r/20230206172340.2639971-1-rananta@google.com
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 412a3b9a3c25..67dd47df42d5 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -93,19 +93,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)
> +
> #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) { \
I'd just use level != TLBI_TTL_UNKNOWN here.
> u64 ttl = level & 3; \
> ttl |= get_trans_granule() << 2; \
> arg &= ~TLBI_TTL_MASK; \
> @@ -133,16 +136,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; \
And here, set __ttl to 0 if TLBI_TTL_UNKNOWN.
Otherwise it looks fine:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Ard Biesheuvel <ardb@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH v2 01/12] arm64/mm: Update non-range tlb invalidation routines for FEAT_LPA2
Date: Wed, 12 Apr 2023 16:47:35 +0100 [thread overview]
Message-ID: <ZDbSl8vccLiMCrDz@arm.com> (raw)
In-Reply-To: <20230306195438.1557851-2-ryan.roberts@arm.com>
On Mon, Mar 06, 2023 at 07:54:27PM +0000, 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,
> 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.
There are some patches on the list to add support for range invalidation
in KVM:
https://lore.kernel.org/r/20230206172340.2639971-1-rananta@google.com
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index 412a3b9a3c25..67dd47df42d5 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -93,19 +93,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)
> +
> #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) { \
I'd just use level != TLBI_TTL_UNKNOWN here.
> u64 ttl = level & 3; \
> ttl |= get_trans_granule() << 2; \
> arg &= ~TLBI_TTL_MASK; \
> @@ -133,16 +136,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; \
And here, set __ttl to 0 if TLBI_TTL_UNKNOWN.
Otherwise it looks fine:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-12 15:47 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 19:54 [PATCH v2 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2 Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 01/12] arm64/mm: Update non-range tlb invalidation routines for FEAT_LPA2 Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-04-12 15:47 ` Catalin Marinas [this message]
2023-04-12 15:47 ` Catalin Marinas
2023-04-13 8:04 ` Ryan Roberts
2023-04-13 8:04 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 02/12] arm64/mm: Add FEAT_LPA2 specific ID_AA64MMFR0.TGRAN[2] Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-04-12 16:27 ` Catalin Marinas
2023-04-12 16:27 ` Catalin Marinas
2023-04-13 8:16 ` Ryan Roberts
2023-04-13 8:16 ` Ryan Roberts
2023-04-13 16:54 ` Catalin Marinas
2023-04-13 16:54 ` Catalin Marinas
2023-03-06 19:54 ` [PATCH v2 03/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 04/12] KVM: arm64: Add new (V)TCR_EL2 field definitions for FEAT_LPA2 Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-04-12 16:36 ` Catalin Marinas
2023-04-12 16:36 ` Catalin Marinas
2023-03-06 19:54 ` [PATCH v2 05/12] KVM: arm64: Use LPA2 page-tables for stage2 if HW supports it Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 06/12] KVM: arm64: Use LPA2 page-tables for hyp stage1 " Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-04-12 17:06 ` Catalin Marinas
2023-04-12 17:06 ` Catalin Marinas
2023-04-13 8:27 ` Ryan Roberts
2023-04-13 8:27 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 07/12] KVM: arm64: Insert PS field at TCR_EL2 assembly time Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 08/12] KVM: arm64: Convert translation level parameter to s8 Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 09/12] KVM: arm64: Support up to 5 levels of translation in kvm_pgtable Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 20:02 ` Ryan Roberts
2023-03-06 20:02 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 10/12] KVM: arm64: Allow guests with >48-bit IPA size on FEAT_LPA2 systems Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 11/12] KVM: selftests: arm64: Determine max ipa size per-page size Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 19:54 ` [PATCH v2 12/12] KVM: selftests: arm64: Support P52V48 4K and 16K guest_modes Ryan Roberts
2023-03-06 19:54 ` Ryan Roberts
2023-03-06 20:04 ` Ryan Roberts
2023-03-06 20:04 ` Ryan Roberts
2023-04-17 10:43 ` [PATCH v2 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2 Ryan Roberts
2023-04-17 10:43 ` Ryan Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZDbSl8vccLiMCrDz@arm.com \
--to=catalin.marinas@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.