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 C1ECB1094A for ; Fri, 20 Oct 2023 08:16:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I/2UpPnW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30131C433C7; Fri, 20 Oct 2023 08:16:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697789778; bh=kYbBC1uCW/IrsU7Ie/AtvN1XKRDqHmtud5Ozeobgrms=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=I/2UpPnWrrzwbNclSrpunmBM7CvNuMrCzu0N3WGlmvCUlI9AS4n6QDwmDJD+81dGG BeXqNoD/JMMkyce9MqBuQsDE9gpnJSQsfuCDzZ4obl/hx4g9VpPyzINgUCtXk4Z3HN yJceJGoOvQku43DKWSQ+kxdXNL0MbYmCmFGF8+6mzvZcdXVJQGkUKb1YmWq48BxSM4 M7gkkzt1c/h+08/K8hpF62xLvkI6dyPgHQ75/NIpaTDnV/apNCMKfFVCdcKBuKCUt9 p+UgEcCnEbQtnUuJAhYv0DUQ3rqzEIhp/ulTJIZ29AUjHoYzNCkjMmrPo6+4ir0teG Lto3mKSVF6S1A== 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 1qtkg3-0062Vb-K9; Fri, 20 Oct 2023 09:16:15 +0100 Date: Fri, 20 Oct 2023 09:16:14 +0100 Message-ID: <86cyx9n1yp.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 04/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability In-Reply-To: <20231009185008.3803879-5-ryan.roberts@arm.com> References: <20231009185008.3803879-1-ryan.roberts@arm.com> <20231009185008.3803879-5-ryan.roberts@arm.com> 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 Mon, 09 Oct 2023 19:50:00 +0100, Ryan Roberts 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 > --- > 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. 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 138F1CDB47E for ; Fri, 20 Oct 2023 08:16:51 +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=9VXL8yxCyE+DhLCkIQeuki7/m8cMTmBMrL1/waW1AlU=; b=N8SL/ndinI2QV+ iLj5w9b8dNolWyW2zayVQOfNjl/sHgZiOxDktgvEB2ZVCijzHMuPn/0rrAbCAmSJZMKCSWj/rISje 0G81fwPsJxd7MbNVIdHTv/FcW9/F1necJBwYzBqHxIWDAktKVxUe2MMhfU27M38ntzl7zD6vocOZF i8vhHnzt/xgruuDgsBwkzf2gc7zcAxvKfu9+HbX3ZkuoD8yXo0hIWcEuoMciwG29bmLcUj9MYwuKZ Tybknh6d8Ae8nKuO6et2MKJkyWl5p3oobsgUVQjFwXo+3zJnMlkpotQzWBUbQyS2MMz/O3hXeBWNX qIErWzr/1411+91NOuwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qtkgC-001X2c-0Q; Fri, 20 Oct 2023 08:16:24 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qtkg8-001X27-34 for linux-arm-kernel@lists.infradead.org; Fri, 20 Oct 2023 08:16:22 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id F30B5CE35BF; Fri, 20 Oct 2023 08:16:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30131C433C7; Fri, 20 Oct 2023 08:16:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697789778; bh=kYbBC1uCW/IrsU7Ie/AtvN1XKRDqHmtud5Ozeobgrms=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=I/2UpPnWrrzwbNclSrpunmBM7CvNuMrCzu0N3WGlmvCUlI9AS4n6QDwmDJD+81dGG BeXqNoD/JMMkyce9MqBuQsDE9gpnJSQsfuCDzZ4obl/hx4g9VpPyzINgUCtXk4Z3HN yJceJGoOvQku43DKWSQ+kxdXNL0MbYmCmFGF8+6mzvZcdXVJQGkUKb1YmWq48BxSM4 M7gkkzt1c/h+08/K8hpF62xLvkI6dyPgHQ75/NIpaTDnV/apNCMKfFVCdcKBuKCUt9 p+UgEcCnEbQtnUuJAhYv0DUQ3rqzEIhp/ulTJIZ29AUjHoYzNCkjMmrPo6+4ir0teG Lto3mKSVF6S1A== 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 1qtkg3-0062Vb-K9; Fri, 20 Oct 2023 09:16:15 +0100 Date: Fri, 20 Oct 2023 09:16:14 +0100 Message-ID: <86cyx9n1yp.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 04/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability In-Reply-To: <20231009185008.3803879-5-ryan.roberts@arm.com> References: <20231009185008.3803879-1-ryan.roberts@arm.com> <20231009185008.3803879-5-ryan.roberts@arm.com> 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_011621_331476_D72C6591 X-CRM114-Status: GOOD ( 30.28 ) 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 Mon, 09 Oct 2023 19:50:00 +0100, Ryan Roberts 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 > --- > 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