Re: [PATCH 1/2] arm64: cpufeature: add cpus_have_final_cap()

From: Mark Rutland <mark.rutland@arm.com>
To: Suzuki Kuruppassery Poulose <suzuki.poulose@arm.com>
Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
	maz@kernel.org, will@kernel.org, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 1/2] arm64: cpufeature: add cpus_have_final_cap()
Date: Mon, 10 Feb 2020 17:37:44 +0000	[thread overview]
Message-ID: <20200210173744.GA20840@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <047f1cd2-3537-6671-233c-69f1758684bf@arm.com>

On Mon, Feb 10, 2020 at 04:37:53PM +0000, Suzuki Kuruppassery Poulose wrote:
> On 10/02/2020 12:27, Mark Rutland wrote:
> > When cpus_have_const_cap() was originally introduced it was intended to
> > be safe in hyp context, where it is not safe to access the cpu_hwcaps
> > array as cpus_have_cap() did. For more details see commit:
> > 
> >    a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities")
> > 
> > We then made use of cpus_have_const_cap() throughout the kernel.
> > 
> > Subsequently, we had to defer updating the static_key associated with
> > each capability in order to avoid lockdep complaints. To avoid breaking
> > kernel-wide usage of cpus_have_const_cap(), this was updated to fall
> > back to the cpu_hwcaps array if called before the static_keys were
> > updated. As the kvm hyp code was only called later than this, the
> > fallback is redundant but not functionally harmful. For more details,
> > see commit:
> > 
> >    63a1e1c95e60e798 ("arm64/cpufeature: don't use mutex in bringup path")
> > 
> > Today we have more users of cpus_have_const_cap() which are only called
> > once the relevant static keys are initialized, and it would be
> > beneficial to avoid the redundant code.
> > 
> > To that end, this patch adds a new cpus_have_final_cap(), helper which
> > is intend to be used in code which is only run once capabilities have
> > been finalized, and will never check the cpus_hwcap array. This helps
> > the compiler to generate better code as it no longer needs to generate
> > code to address and test the cpus_hwcap array. To help catch misuse,
> > cpus_have_final_cap() will BUG() if called before capabilities are
> > finalized.
> > 
> > In hyp context, BUG() will result in a hyp panic, but the specific BUG()
> > instance will not be identified in the usual way.
> > 
> > Comments are added to the various cpus_have_*_cap() helpers to describe
> > the constraints on when they can be used. For clarity cpus_have_cap() is
> > moved above the other helpers.
> > 
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: Suzuki Poulose <suzuki.poulose@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> 
> ...
> 
> > +/*
> > + * Test for a capability without a runtime check.
> > + *
> > + * Before capabilities are finalized, this will BUG().
> > + * After capabilities are finalized, this is patched to avoid a runtime check.
> > + *
> > + * @num must be a compile-time constant.
> > + */
> > +static __always_inline bool cpus_have_final_cap(int num)
> > +{
> > +	if (static_branch_likely(&arm64_const_caps_ready))
> 
> We have introduced system_capabilities_finalized() helper and may be
> it is a good idea to use it here, to make it more clear.

Sure thing. There are a few existing uses that could be moved over, so I
can move that up for v2.

> Either ways :
> 
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Thanks!

Mark.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm