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.
next prev parent reply other threads:[~2023-10-20 8:16 UTC|newest]
Thread overview: 38+ 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 ` [PATCH v4 01/12] arm64/mm: Update non-range tlb invalidation routines for FEAT_LPA2 Ryan Roberts
2023-10-19 8:03 ` Marc Zyngier
2023-10-19 9:22 ` Ryan Roberts
2023-10-20 8:05 ` Marc Zyngier
2023-10-20 12:39 ` Ryan Roberts
2023-10-20 13:02 ` Marc Zyngier
2023-10-20 13:21 ` Ryan Roberts
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-19 21:06 ` Marc Zyngier
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:50 ` [PATCH v4 04/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability Ryan Roberts
2023-10-20 8:16 ` Marc Zyngier [this message]
2023-10-20 15:03 ` Ryan Roberts
2023-10-23 9:34 ` Marc Zyngier
2023-11-13 11:57 ` Ryan Roberts
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 ` [PATCH v4 06/12] KVM: arm64: Use LPA2 page-tables for stage2 and hyp stage1 Ryan Roberts
2023-10-20 9:16 ` Marc Zyngier
2023-10-20 15:06 ` Ryan Roberts
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-20 9:21 ` Marc Zyngier
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-20 10:42 ` Marc Zyngier
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 ` [PATCH v4 10/12] KVM: arm64: Allow guests with >48-bit IPA size on FEAT_LPA2 systems 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 ` [PATCH v4 12/12] KVM: selftests: arm64: Support P52V48 4K and 16K guest_modes 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 15:22 ` Ryan Roberts
2023-10-23 9:42 ` Marc Zyngier
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox