All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	James Morse <james.morse@arm.com>,
	Zenghui Yu <yuzenghui@huawei.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 v4 04/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability
Date: Fri, 20 Oct 2023 09:16:14 +0100	[thread overview]
Message-ID: <86cyx9n1yp.wl-maz@kernel.org> (raw)
In-Reply-To: <20231009185008.3803879-5-ryan.roberts@arm.com>

On Mon, 09 Oct 2023 19:50:00 +0100,
Ryan Roberts <ryan.roberts@arm.com> wrote:
> 
> Expose FEAT_LPA2 as a capability so that we can take advantage of
> alternatives patching in both the kernel and hypervisor.
> 
> Although FEAT_LPA2 presence is advertised separately for stage1 and
> stage2, the expectation is that in practice both stages will either
> support or not support it. Therefore, for the case where KVM is present,
> we combine both into a single capability, allowing us to simplify the
> implementation. For the case where KVM is not present, we only care
> about stage1.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
>  arch/arm64/include/asm/cpufeature.h |  5 ++++
>  arch/arm64/kernel/cpufeature.c      | 46 +++++++++++++++++++++++++++++
>  arch/arm64/tools/cpucaps            |  1 +
>  3 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 5bba39376055..b1292ec88538 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -831,6 +831,11 @@ static inline bool system_supports_tlb_range(void)
>  		cpus_have_const_cap(ARM64_HAS_TLB_RANGE);
>  }
>  
> +static inline bool system_supports_lpa2(void)
> +{
> +	return cpus_have_const_cap(ARM64_HAS_LPA2);

cpus_have_const_cap() is going away. You may want to look at Mark's
series to see how to replace this one.

> +}
> +
>  int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
>  bool try_emulate_mrs(struct pt_regs *regs, u32 isn);
>  
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 444a73c2e638..1ccb1fe0e310 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1746,6 +1746,46 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>  	return !meltdown_safe;
>  }
>  
> +static inline bool has_lpa2_at_stage1(u64 mmfr0)

Why inline? It isn't like this has any performance implication...

> +{
> +#if defined(CONFIG_ARM64_4K_PAGES) || defined(CONFIG_ARM64_16K_PAGES)
> +	unsigned int tgran;
> +
> +	tgran = cpuid_feature_extract_unsigned_field(mmfr0,
> +						ID_AA64MMFR0_EL1_TGRAN_SHIFT);
> +	return tgran == ID_AA64MMFR0_EL1_TGRAN_LPA2;
> +#else
> +	return false;
> +#endif

Writing this using IS_ENABLED() would be slightly more pleasing to my
tired eyes... ;-)

> +}
> +
> +static inline bool has_lpa2_at_stage2(u64 mmfr0)
> +{
> +#if defined(CONFIG_ARM64_4K_PAGES) || defined(CONFIG_ARM64_16K_PAGES)
> +	unsigned int tgran;
> +
> +	tgran = cpuid_feature_extract_unsigned_field(mmfr0,
> +						ID_AA64MMFR0_EL1_TGRAN_2_SHIFT);
> +	return tgran == ID_AA64MMFR0_EL1_TGRAN_2_SUPPORTED_LPA2;
> +#else
> +	return false;
> +#endif
> +}
> +
> +static bool has_lpa2(const struct arm64_cpu_capabilities *entry, int scope)
> +{
> +	u64 mmfr0;
> +	bool ret;
> +
> +	mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
> +	ret = has_lpa2_at_stage1(mmfr0);
> +
> +	if (kvm_get_mode() != KVM_MODE_NONE)
> +		ret = ret && has_lpa2_at_stage2(mmfr0);

Isn't it too late to go back on the decision to use LPA2 at S1 if you
realise that S2 doesn't support it?

> +
> +	return ret;
> +}
> +
>  #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
>  #define KPTI_NG_TEMP_VA		(-(1UL << PMD_SHIFT))
>  
> @@ -2719,6 +2759,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.matches = has_cpuid_feature,
>  		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
>  	},
> +	{
> +		.desc = "Large Physical Address 2",
> +		.capability = ARM64_HAS_LPA2,
> +		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> +		.matches = has_lpa2,
> +	},
>  	{},
>  };
>  
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index dea3dc89234b..07f3957b8488 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -36,6 +36,7 @@ HAS_GIC_PRIO_MASKING
>  HAS_GIC_PRIO_RELAXED_SYNC
>  HAS_HCX
>  HAS_LDAPR
> +HAS_LPA2
>  HAS_LSE_ATOMICS
>  HAS_MOPS
>  HAS_NESTED_VIRT

Why isn't this patch the first or second in the series? You could use
it to drive the LPA2 decision in the patch #2, avoiding the ugly lpa2
flag...

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	James Morse <james.morse@arm.com>,
	Zenghui Yu <yuzenghui@huawei.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 v4 04/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability
Date: Fri, 20 Oct 2023 09:16:14 +0100	[thread overview]
Message-ID: <86cyx9n1yp.wl-maz@kernel.org> (raw)
In-Reply-To: <20231009185008.3803879-5-ryan.roberts@arm.com>

On Mon, 09 Oct 2023 19:50:00 +0100,
Ryan Roberts <ryan.roberts@arm.com> wrote:
> 
> Expose FEAT_LPA2 as a capability so that we can take advantage of
> alternatives patching in both the kernel and hypervisor.
> 
> Although FEAT_LPA2 presence is advertised separately for stage1 and
> stage2, the expectation is that in practice both stages will either
> support or not support it. Therefore, for the case where KVM is present,
> we combine both into a single capability, allowing us to simplify the
> implementation. For the case where KVM is not present, we only care
> about stage1.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
>  arch/arm64/include/asm/cpufeature.h |  5 ++++
>  arch/arm64/kernel/cpufeature.c      | 46 +++++++++++++++++++++++++++++
>  arch/arm64/tools/cpucaps            |  1 +
>  3 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 5bba39376055..b1292ec88538 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -831,6 +831,11 @@ static inline bool system_supports_tlb_range(void)
>  		cpus_have_const_cap(ARM64_HAS_TLB_RANGE);
>  }
>  
> +static inline bool system_supports_lpa2(void)
> +{
> +	return cpus_have_const_cap(ARM64_HAS_LPA2);

cpus_have_const_cap() is going away. You may want to look at Mark's
series to see how to replace this one.

> +}
> +
>  int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
>  bool try_emulate_mrs(struct pt_regs *regs, u32 isn);
>  
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 444a73c2e638..1ccb1fe0e310 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1746,6 +1746,46 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>  	return !meltdown_safe;
>  }
>  
> +static inline bool has_lpa2_at_stage1(u64 mmfr0)

Why inline? It isn't like this has any performance implication...

> +{
> +#if defined(CONFIG_ARM64_4K_PAGES) || defined(CONFIG_ARM64_16K_PAGES)
> +	unsigned int tgran;
> +
> +	tgran = cpuid_feature_extract_unsigned_field(mmfr0,
> +						ID_AA64MMFR0_EL1_TGRAN_SHIFT);
> +	return tgran == ID_AA64MMFR0_EL1_TGRAN_LPA2;
> +#else
> +	return false;
> +#endif

Writing this using IS_ENABLED() would be slightly more pleasing to my
tired eyes... ;-)

> +}
> +
> +static inline bool has_lpa2_at_stage2(u64 mmfr0)
> +{
> +#if defined(CONFIG_ARM64_4K_PAGES) || defined(CONFIG_ARM64_16K_PAGES)
> +	unsigned int tgran;
> +
> +	tgran = cpuid_feature_extract_unsigned_field(mmfr0,
> +						ID_AA64MMFR0_EL1_TGRAN_2_SHIFT);
> +	return tgran == ID_AA64MMFR0_EL1_TGRAN_2_SUPPORTED_LPA2;
> +#else
> +	return false;
> +#endif
> +}
> +
> +static bool has_lpa2(const struct arm64_cpu_capabilities *entry, int scope)
> +{
> +	u64 mmfr0;
> +	bool ret;
> +
> +	mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
> +	ret = has_lpa2_at_stage1(mmfr0);
> +
> +	if (kvm_get_mode() != KVM_MODE_NONE)
> +		ret = ret && has_lpa2_at_stage2(mmfr0);

Isn't it too late to go back on the decision to use LPA2 at S1 if you
realise that S2 doesn't support it?

> +
> +	return ret;
> +}
> +
>  #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
>  #define KPTI_NG_TEMP_VA		(-(1UL << PMD_SHIFT))
>  
> @@ -2719,6 +2759,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.matches = has_cpuid_feature,
>  		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
>  	},
> +	{
> +		.desc = "Large Physical Address 2",
> +		.capability = ARM64_HAS_LPA2,
> +		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> +		.matches = has_lpa2,
> +	},
>  	{},
>  };
>  
> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index dea3dc89234b..07f3957b8488 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -36,6 +36,7 @@ HAS_GIC_PRIO_MASKING
>  HAS_GIC_PRIO_RELAXED_SYNC
>  HAS_HCX
>  HAS_LDAPR
> +HAS_LPA2
>  HAS_LSE_ATOMICS
>  HAS_MOPS
>  HAS_NESTED_VIRT

Why isn't this patch the first or second in the series? You could use
it to drive the LPA2 decision in the patch #2, avoiding the ugly lpa2
flag...

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

  reply	other threads:[~2023-10-20  8:16 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-09 18:49 [PATCH v4 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2 Ryan Roberts
2023-10-09 18:49 ` Ryan Roberts
2023-10-09 18:49 ` [PATCH v4 01/12] arm64/mm: Update non-range tlb invalidation routines for FEAT_LPA2 Ryan Roberts
2023-10-09 18:49   ` Ryan Roberts
2023-10-19  8:03   ` Marc Zyngier
2023-10-19  8:03     ` Marc Zyngier
2023-10-19  9:22     ` Ryan Roberts
2023-10-19  9:22       ` Ryan Roberts
2023-10-20  8:05       ` Marc Zyngier
2023-10-20  8:05         ` Marc Zyngier
2023-10-20 12:39         ` Ryan Roberts
2023-10-20 12:39           ` Ryan Roberts
2023-10-20 13:02           ` Marc Zyngier
2023-10-20 13:02             ` Marc Zyngier
2023-10-20 13:21             ` Ryan Roberts
2023-10-20 13:21               ` Ryan Roberts
2023-10-20 13:41               ` Marc Zyngier
2023-10-20 13:41                 ` Marc Zyngier
2023-10-09 18:49 ` [PATCH v4 02/12] arm64/mm: Update range-based " Ryan Roberts
2023-10-09 18:49   ` Ryan Roberts
2023-10-19 21:06   ` Marc Zyngier
2023-10-19 21:06     ` Marc Zyngier
2023-10-20 14:55     ` Ryan Roberts
2023-10-20 14:55       ` Ryan Roberts
2023-10-09 18:49 ` [PATCH v4 03/12] arm64/mm: Add FEAT_LPA2 specific ID_AA64MMFR0.TGRAN[2] Ryan Roberts
2023-10-09 18:49   ` Ryan Roberts
2023-10-09 18:50 ` [PATCH v4 04/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-20  8:16   ` Marc Zyngier [this message]
2023-10-20  8:16     ` Marc Zyngier
2023-10-20 15:03     ` Ryan Roberts
2023-10-20 15:03       ` Ryan Roberts
2023-10-23  9:34       ` Marc Zyngier
2023-10-23  9:34         ` Marc Zyngier
2023-11-13 11:57     ` Ryan Roberts
2023-11-13 11:57       ` Ryan Roberts
2023-11-13 12:16       ` Marc Zyngier
2023-11-13 12:16         ` Marc Zyngier
2023-10-09 18:50 ` [PATCH v4 05/12] KVM: arm64: Add new (V)TCR_EL2 field definitions for FEAT_LPA2 Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-09 18:50 ` [PATCH v4 06/12] KVM: arm64: Use LPA2 page-tables for stage2 and hyp stage1 Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-20  9:16   ` Marc Zyngier
2023-10-20  9:16     ` Marc Zyngier
2023-10-20 15:06     ` Ryan Roberts
2023-10-20 15:06       ` Ryan Roberts
2023-10-23  9:36       ` Marc Zyngier
2023-10-23  9:36         ` Marc Zyngier
2023-10-09 18:50 ` [PATCH v4 07/12] KVM: arm64: Prepare TCR_EL2.PS in cpu_prepare_hyp_mode() Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-20  9:21   ` Marc Zyngier
2023-10-20  9:21     ` Marc Zyngier
2023-10-20 15:07     ` Ryan Roberts
2023-10-20 15:07       ` Ryan Roberts
2023-10-09 18:50 ` [PATCH v4 08/12] KVM: arm64: Convert translation level parameter to s8 Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-20 10:42   ` Marc Zyngier
2023-10-20 10:42     ` Marc Zyngier
2023-10-20 15:11     ` Ryan Roberts
2023-10-20 15:11       ` Ryan Roberts
2023-10-09 18:50 ` [PATCH v4 09/12] KVM: arm64: Support up to 5 levels of translation in kvm_pgtable Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-09 18:50 ` [PATCH v4 10/12] KVM: arm64: Allow guests with >48-bit IPA size on FEAT_LPA2 systems Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-09 18:50 ` [PATCH v4 11/12] KVM: selftests: arm64: Determine max ipa size per-page size Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-09 18:50 ` [PATCH v4 12/12] KVM: selftests: arm64: Support P52V48 4K and 16K guest_modes Ryan Roberts
2023-10-09 18:50   ` Ryan Roberts
2023-10-20 10:54 ` [PATCH v4 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2 Marc Zyngier
2023-10-20 10:54   ` Marc Zyngier
2023-10-20 15:22   ` Ryan Roberts
2023-10-20 15:22     ` Ryan Roberts
2023-10-23  9:42     ` Marc Zyngier
2023-10-23  9:42       ` Marc Zyngier
2023-10-23 15:00       ` Ryan Roberts
2023-10-23 15:00         ` 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=86cyx9n1yp.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=ryan.roberts@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /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.