[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h7e2tsov.wl-maz@kernel.org>
Date: Thu, 30 Sep 2021 08:42:56 +0100
From: Marc Zyngier <maz@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Mark Rutland <mark.rutland@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Shier <pshier@...gle.com>,
Raghavendra Rao Ananta <rananta@...gle.com>,
Ricardo Koller <ricarkol@...gle.com>,
Oliver Upton <oupton@...gle.com>,
Catalin Marinas <catalin.marinas@....com>,
Linus Walleij <linus.walleij@...aro.org>,
kernel-team@...roid.com
Subject: Re: [PATCH v2 14/16] arm64: Add a capability for FEAT_ECV
On Wed, 29 Sep 2021 17:03:30 +0100,
Will Deacon <will@...nel.org> wrote:
>
> On Wed, Sep 22, 2021 at 10:19:39PM +0100, Marc Zyngier wrote:
> > Add a new capability to detect the Enhanced Counter Virtualization
> > feature (FEAT_ECV).
> >
> > Reviewed-by: Oliver Upton <oupton@...gle.com>
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> > ---
> > arch/arm64/kernel/cpufeature.c | 10 ++++++++++
> > arch/arm64/tools/cpucaps | 1 +
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index f8a3067d10c6..26b11ce8fff6 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -1926,6 +1926,16 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> > .sign = FTR_UNSIGNED,
> > .min_field_value = 1,
> > },
> > + {
> > + .desc = "Enhanced Counter Virtualization",
> > + .capability = ARM64_HAS_ECV,
> > + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > + .matches = has_cpuid_feature,
> > + .sys_reg = SYS_ID_AA64MMFR0_EL1,
> > + .field_pos = ID_AA64MMFR0_ECV_SHIFT,
> > + .sign = FTR_UNSIGNED,
> > + .min_field_value = 1,
> > + },
>
> Could we add a HWCAP for this and change the field to FTR_VISIBLE, please? I
> know most users of the counter are indirected via the vDSO, but there are
> some users out there using the counter directly and it would save them
> having to probe via SIGILL if there was a hwcap available.
Fair enough, I'll add that.
The problem of the vdso remains though, and is by far the most common
user of the feature. Any idea on how to handle it? Patching the vdso
is ugly, and I'd rather avoid it.
I briefly looked at using ifunc, but it is likely that the indirection
would add an extra cost. Are we OK with that?
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists