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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DC65C433F5 for ; Thu, 30 Sep 2021 07:43:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3254B6187A for ; Thu, 30 Sep 2021 07:43:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348823AbhI3Hom (ORCPT ); Thu, 30 Sep 2021 03:44:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:53042 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348786AbhI3Hol (ORCPT ); Thu, 30 Sep 2021 03:44:41 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CEFF461527; Thu, 30 Sep 2021 07:42:58 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mVqiW-00Du57-Tz; Thu, 30 Sep 2021 08:42:57 +0100 Date: Thu, 30 Sep 2021 08:42:56 +0100 Message-ID: <87h7e2tsov.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Rutland , Daniel Lezcano , Thomas Gleixner , Peter Shier , Raghavendra Rao Ananta , Ricardo Koller , Oliver Upton , Catalin Marinas , Linus Walleij , kernel-team@android.com Subject: Re: [PATCH v2 14/16] arm64: Add a capability for FEAT_ECV In-Reply-To: <20210929160329.GE22029@willie-the-truck> References: <20210922211941.2756270-1-maz@kernel.org> <20210922211941.2756270-15-maz@kernel.org> <20210929160329.GE22029@willie-the-truck> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) 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: will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, daniel.lezcano@linaro.org, tglx@linutronix.de, pshier@google.com, rananta@google.com, ricarkol@google.com, oupton@google.com, catalin.marinas@arm.com, linus.walleij@linaro.org, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Sep 2021 17:03:30 +0100, Will Deacon 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 > > Signed-off-by: Marc Zyngier > > --- > > 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.