[PATCH v3 0/3] arm64: Drop support for VPIPT i-cache policy

Marc Zyngier maz at kernel.org
Tue Dec 5 03:53:20 PST 2023


On Tue, 05 Dec 2023 11:03:16 +0000,
Mark Rutland <mark.rutland at arm.com> wrote:
> 
> On Mon, Dec 04, 2023 at 06:26:25PM +0000, Marc Zyngier wrote:
> > 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.
> 
> [...]
> 
> >  /*
> >   * 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.

Right, this should be marginally better. I was initially worried of
the cap not being configured yet, but since we start by assuming VIPT
and only flip to PIPT once we have seen all CPUs, this stays correct
by construction.

> [...]
> 
> > 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.

Yeah, I hesitated either way, but maybe the helper approach is
cleaner.  I'll give it a go and repost this patch.

Thanks,

	M.

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



More information about the linux-arm-kernel mailing list