All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy
Date: Tue, 5 Dec 2023 11:03:16 +0000	[thread overview]
Message-ID: <ZW8DXGQCSWO1wB2m@FVFF77S0Q05N> (raw)
In-Reply-To: <86h6kxbz8u.wl-maz@kernel.org>

On Mon, Dec 04, 2023 at 06:26:25PM +0000, Marc Zyngier wrote:
> On Mon, 04 Dec 2023 14:44:56 +0000,
> Mark Rutland <mark.rutland@arm.com> wrote:
> > 
> > On Mon, Dec 04, 2023 at 02:36:03PM +0000, Marc Zyngier wrote:
> > > ARMv8.2 introduced support for VPIPT i-caches, the V standing for
> > > VMID-tagged. Although this looked like a reasonable idea, no
> > > implementation has ever made it into the wild.
> > > 
> > > Linux has supported this for over 6 years (amusingly, just as the
> > > architecture was dropping support for AIVIVT i-caches), but we had no
> > > way to even test it, and it is likely that this code was just
> > > bit-rotting.
> > > 
> > > However, in a recent breakthrough (XML drop 2023-09, tagged as
> > > d55f5af8e09052abe92a02adf820deea2eaed717), the architecture has
> > > finally been purged of this option, making VIPT and PIPT the only two
> > > valid options.
> > > 
> > > This really means this code is just dead code. Nobody will ever come
> > > up with such an implementation, and we can just get rid of it.
> > > 
> > > Most of the impact is on KVM, where we drop a few large comment blocks
> > > (and a bit of code), while the core arch code loses the detection code
> > > itself.
> > > 
> > > * From v2:
> > >   - Fix reserved naming for RESERVED_AIVIVT
> > >   - Collected RBs from Anshuman an Zenghui
> > > 
> > > Marc Zyngier (3):
> > >   KVM: arm64: Remove VPIPT I-cache handling
> > >   arm64: Kill detection of VPIPT i-cache policy
> > >   arm64: Rename reserved values for CTR_EL0.L1Ip
> > 
> > For the series:
> > 
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> 
> Thanks.
> 
> > Looking forward, we can/should probably replace __icache_flags with a single
> > ICACHE_NOALIASING or ICACHE_PIPT cpucap, which'd get rid of a bunch of
> > duplicated logic and make that more sound in the case of races around cpu
> > onlining.
> 
> As long as we refuse VIPT CPUs coming up late (i.e. after we have
> patched the kernel to set ICACHE_PIPT), it should be doable. I guess
> we already have this restriction as userspace is able to probe the
> I-cache policy anyway.
> 
> How about the patch below (tested in a guest with a bunch of hacks to
> expose different L1Ip values)?

That's roughly what I was thinking; the diff looks good, minor comments below.

> 
> Thanks,
> 
> 	M.
> 
> From 8f88afb0b317213dcbf18ea460a508bfccc18568 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz@kernel.org>
> Date: Mon, 4 Dec 2023 18:09:40 +0000
> Subject: [PATCH] arm64: Make icache detection a cpu capability
> 
> Now that we only have two icache policies, we are in a good position
> to make the whole detection business more robust.
> 
> Let's replace __icache_flags by a single capability (ICACHE_PIPT),
> and use this if all CPUs are indeed PIPT. It means we can rely on
> existing logic to mandate that a VIPT CPU coming up late will be
> denied booting, which is the safe thing to do.
> 
> This also leads to some nice cleanups in pKVM, and KVM as a whole
> can use ARM64_ICACHE_PIPT as a final cap.
> 
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  arch/arm64/include/asm/cache.h   |  9 ++-------
>  arch/arm64/include/asm/kvm_hyp.h |  1 -
>  arch/arm64/include/asm/kvm_mmu.h |  2 +-
>  arch/arm64/kernel/cpufeature.c   |  7 +++++++
>  arch/arm64/kernel/cpuinfo.c      | 34 --------------------------------
>  arch/arm64/kvm/arm.c             |  1 -
>  arch/arm64/kvm/hyp/nvhe/pkvm.c   |  3 ---
>  arch/arm64/tools/cpucaps         |  1 +
>  arch/arm64/tools/sysreg          |  2 +-
>  9 files changed, 12 insertions(+), 48 deletions(-)

Nice diffstat!

[...]

>  /*
>   * Whilst the D-side always behaves as PIPT on AArch64, aliasing is
>   * permitted in the I-cache.
>   */
>  static inline int icache_is_aliasing(void)
>  {
> -	return test_bit(ICACHEF_ALIASING, &__icache_flags);
> +	return !cpus_have_cap(ARM64_ICACHE_PIPT);
>  }

It might be nicer to use alternative_has_cap_{likely,unlikely}(...) for
consistency with other cap checks, though that won't matter for hyp code and I
don't think the likely/unlikely part particularly matters either.

[...]

> -static void cpuinfo_detect_icache_policy(struct cpuinfo_arm64 *info)
> -{
> -	unsigned int cpu = smp_processor_id();
> -	u32 l1ip = CTR_L1IP(info->reg_ctr);
> -
> -	switch (l1ip) {
> -	case CTR_EL0_L1Ip_PIPT:
> -		break;
> -	case CTR_EL0_L1Ip_VIPT:
> -	default:
> -		/* Assume aliasing */
> -		set_bit(ICACHEF_ALIASING, &__icache_flags);
> -		break;
> -	}
> -
> -	pr_info("Detected %s I-cache on CPU%d\n", icache_policy_str(l1ip), cpu);
> -}

Not printing this for each CPU is a nice bonus!

[...]

> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index c5af75b23187..db8c96841138 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -2003,7 +2003,7 @@ Field	28	IDC
>  Field	27:24	CWG
>  Field	23:20	ERG
>  Field	19:16	DminLine
> -Enum	15:14	L1Ip
> +UnsignedEnum	15:14	L1Ip
>  	# This was named as VPIPT in the ARM but now documented as reserved
>  	0b00	RESERVED_VPIPT
>  	# This is named as AIVIVT in the ARM but documented as reserved

I was initially surprised by the use of UnsignedEnum, but given PIPT is 0b11, I
can see that works. Otherwise, we can keep this as an enum and use a helper
that checks for an exact match.

Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy
Date: Tue, 5 Dec 2023 11:03:16 +0000	[thread overview]
Message-ID: <ZW8DXGQCSWO1wB2m@FVFF77S0Q05N> (raw)
In-Reply-To: <86h6kxbz8u.wl-maz@kernel.org>

On Mon, Dec 04, 2023 at 06:26:25PM +0000, Marc Zyngier wrote:
> On Mon, 04 Dec 2023 14:44:56 +0000,
> Mark Rutland <mark.rutland@arm.com> wrote:
> > 
> > On Mon, Dec 04, 2023 at 02:36:03PM +0000, Marc Zyngier wrote:
> > > ARMv8.2 introduced support for VPIPT i-caches, the V standing for
> > > VMID-tagged. Although this looked like a reasonable idea, no
> > > implementation has ever made it into the wild.
> > > 
> > > Linux has supported this for over 6 years (amusingly, just as the
> > > architecture was dropping support for AIVIVT i-caches), but we had no
> > > way to even test it, and it is likely that this code was just
> > > bit-rotting.
> > > 
> > > However, in a recent breakthrough (XML drop 2023-09, tagged as
> > > d55f5af8e09052abe92a02adf820deea2eaed717), the architecture has
> > > finally been purged of this option, making VIPT and PIPT the only two
> > > valid options.
> > > 
> > > This really means this code is just dead code. Nobody will ever come
> > > up with such an implementation, and we can just get rid of it.
> > > 
> > > Most of the impact is on KVM, where we drop a few large comment blocks
> > > (and a bit of code), while the core arch code loses the detection code
> > > itself.
> > > 
> > > * From v2:
> > >   - Fix reserved naming for RESERVED_AIVIVT
> > >   - Collected RBs from Anshuman an Zenghui
> > > 
> > > Marc Zyngier (3):
> > >   KVM: arm64: Remove VPIPT I-cache handling
> > >   arm64: Kill detection of VPIPT i-cache policy
> > >   arm64: Rename reserved values for CTR_EL0.L1Ip
> > 
> > For the series:
> > 
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> 
> Thanks.
> 
> > Looking forward, we can/should probably replace __icache_flags with a single
> > ICACHE_NOALIASING or ICACHE_PIPT cpucap, which'd get rid of a bunch of
> > duplicated logic and make that more sound in the case of races around cpu
> > onlining.
> 
> As long as we refuse VIPT CPUs coming up late (i.e. after we have
> patched the kernel to set ICACHE_PIPT), it should be doable. I guess
> we already have this restriction as userspace is able to probe the
> I-cache policy anyway.
> 
> How about the patch below (tested in a guest with a bunch of hacks to
> expose different L1Ip values)?

That's roughly what I was thinking; the diff looks good, minor comments below.

> 
> Thanks,
> 
> 	M.
> 
> From 8f88afb0b317213dcbf18ea460a508bfccc18568 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz@kernel.org>
> Date: Mon, 4 Dec 2023 18:09:40 +0000
> Subject: [PATCH] arm64: Make icache detection a cpu capability
> 
> Now that we only have two icache policies, we are in a good position
> to make the whole detection business more robust.
> 
> Let's replace __icache_flags by a single capability (ICACHE_PIPT),
> and use this if all CPUs are indeed PIPT. It means we can rely on
> existing logic to mandate that a VIPT CPU coming up late will be
> denied booting, which is the safe thing to do.
> 
> This also leads to some nice cleanups in pKVM, and KVM as a whole
> can use ARM64_ICACHE_PIPT as a final cap.
> 
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  arch/arm64/include/asm/cache.h   |  9 ++-------
>  arch/arm64/include/asm/kvm_hyp.h |  1 -
>  arch/arm64/include/asm/kvm_mmu.h |  2 +-
>  arch/arm64/kernel/cpufeature.c   |  7 +++++++
>  arch/arm64/kernel/cpuinfo.c      | 34 --------------------------------
>  arch/arm64/kvm/arm.c             |  1 -
>  arch/arm64/kvm/hyp/nvhe/pkvm.c   |  3 ---
>  arch/arm64/tools/cpucaps         |  1 +
>  arch/arm64/tools/sysreg          |  2 +-
>  9 files changed, 12 insertions(+), 48 deletions(-)

Nice diffstat!

[...]

>  /*
>   * Whilst the D-side always behaves as PIPT on AArch64, aliasing is
>   * permitted in the I-cache.
>   */
>  static inline int icache_is_aliasing(void)
>  {
> -	return test_bit(ICACHEF_ALIASING, &__icache_flags);
> +	return !cpus_have_cap(ARM64_ICACHE_PIPT);
>  }

It might be nicer to use alternative_has_cap_{likely,unlikely}(...) for
consistency with other cap checks, though that won't matter for hyp code and I
don't think the likely/unlikely part particularly matters either.

[...]

> -static void cpuinfo_detect_icache_policy(struct cpuinfo_arm64 *info)
> -{
> -	unsigned int cpu = smp_processor_id();
> -	u32 l1ip = CTR_L1IP(info->reg_ctr);
> -
> -	switch (l1ip) {
> -	case CTR_EL0_L1Ip_PIPT:
> -		break;
> -	case CTR_EL0_L1Ip_VIPT:
> -	default:
> -		/* Assume aliasing */
> -		set_bit(ICACHEF_ALIASING, &__icache_flags);
> -		break;
> -	}
> -
> -	pr_info("Detected %s I-cache on CPU%d\n", icache_policy_str(l1ip), cpu);
> -}

Not printing this for each CPU is a nice bonus!

[...]

> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index c5af75b23187..db8c96841138 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -2003,7 +2003,7 @@ Field	28	IDC
>  Field	27:24	CWG
>  Field	23:20	ERG
>  Field	19:16	DminLine
> -Enum	15:14	L1Ip
> +UnsignedEnum	15:14	L1Ip
>  	# This was named as VPIPT in the ARM but now documented as reserved
>  	0b00	RESERVED_VPIPT
>  	# This is named as AIVIVT in the ARM but documented as reserved

I was initially surprised by the use of UnsignedEnum, but given PIPT is 0b11, I
can see that works. Otherwise, we can keep this as an enum and use a helper
that checks for an exact match.

Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-12-05 11:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04 14:36 [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy Marc Zyngier
2023-12-04 14:36 ` Marc Zyngier
2023-12-04 14:36 ` [PATCH v3 1/3] KVM: arm64: Remove VPIPT I-cache handling Marc Zyngier
2023-12-04 14:36   ` Marc Zyngier
2023-12-04 14:36 ` [PATCH v3 2/3] arm64: Kill detection of VPIPT i-cache policy Marc Zyngier
2023-12-04 14:36   ` Marc Zyngier
2023-12-04 14:36 ` [PATCH v3 3/3] arm64: Rename reserved values for CTR_EL0.L1Ip Marc Zyngier
2023-12-04 14:36   ` Marc Zyngier
2023-12-05  2:04   ` Anshuman Khandual
2023-12-05  2:04     ` Anshuman Khandual
2023-12-04 14:44 ` [PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy Mark Rutland
2023-12-04 14:44   ` Mark Rutland
2023-12-04 18:26   ` Marc Zyngier
2023-12-04 18:26     ` Marc Zyngier
2023-12-05 11:03     ` Mark Rutland [this message]
2023-12-05 11:03       ` Mark Rutland
2023-12-05 11:53       ` Marc Zyngier
2023-12-05 11:53         ` Marc Zyngier
2023-12-05 15:16 ` Will Deacon
2023-12-05 15:16   ` Will Deacon

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=ZW8DXGQCSWO1wB2m@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --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.