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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F576C4320A for ; Mon, 9 Aug 2021 18:11:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 75B1060F02 for ; Mon, 9 Aug 2021 18:11:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234597AbhHISLm (ORCPT ); Mon, 9 Aug 2021 14:11:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:52616 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231357AbhHISLk (ORCPT ); Mon, 9 Aug 2021 14:11:40 -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 C336060F6F; Mon, 9 Aug 2021 18:11:19 +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 1mD9k5-003sfH-Tt; Mon, 09 Aug 2021 19:11:18 +0100 Date: Mon, 09 Aug 2021 19:11:17 +0100 Message-ID: <87im0ebi9m.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton 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 , Will Deacon , Catalin Marinas , Linus Walleij , kernel-team@android.com Subject: Re: [PATCH 13/13] arm64: Add CNT{P,V}CTSS_EL0 alternatives to cnt{p,v}ct_el0 In-Reply-To: References: <20210809152651.2297337-1-maz@kernel.org> <20210809152651.2297337-14-maz@kernel.org> 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: oupton@google.com, 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, will@kernel.org, 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 Mon, 09 Aug 2021 17:42:00 +0100, Oliver Upton wrote: > > On Mon, Aug 9, 2021 at 8:48 AM Marc Zyngier wrote: > > > > CNTPCTSS_EL0 and CNTVCTSS_EL0 are alternatives to the usual > > CNTPCT_EL0 and CNTVCT_EL0 that do not require a previous ISB > > to be synchronised (SS stands for Self-Synchronising). > > > > Use the ARM64_HAS_ECV capability to control alternative sequences > > that switch to these low(er)-cost primitives. Note that the > > counter access in the VDSO is for now left alone until we decide > > whether we want to allow this. > > What remains to be figured out before we add this to the vDSO (and > presumably advertise to userspace through some standard convention)? We need to understand what breaks if we runtime-patch the VDSO just like we do with the rest of the kernel. To start with, the debug version of the shared object is not the same as the object presented to the process. Maybe that's not a problem, but I would tend to err on the side of caution. An alternative suggested by Ard was to have a separate function altogether for the counter access and an ifunc mapping to pick the right one. > It would be nice to skip the trap handler altogether, unless there's a > can of worms lurking that I'm not aware of. The trap handlers are only there to work around errata. If you look at the arch timer code, you will notice that there is a bunch of SoCs and CPUs that do not have a reliable counter, and for which we have to trap the virtual counter accesses from userspace (as well as the VDSO). On sane platforms, userspace is free to use the virtual counter without any trap. Thanks, M. -- Without deviation from the norm, progress is not possible.