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.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 0EA25C4338F for ; Mon, 9 Aug 2021 18:13:29 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BF1F061004 for ; Mon, 9 Aug 2021 18:13:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BF1F061004 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FOTJEqlxDFVtTlWgPyh+z7/ReKZ3TnF18Y5hfRaeNeU=; b=RG6zAesI7Lb50v MmwJfaFvitOO90R5d8eq04R9+W9kRvbWX3yKZINrvd6eH/va79kRu3joB4QtxTbUu/wOdZPjZ0nlw bxDZY2fm77+4Eqad7yCopVMqcf9ov0McNM59FQTFxZ6+VNa/2VTOIBXyzJ/bSbyNrEx159W1WIeCN hXm6atLpFHrZ+V41xSv4s3aiXQEAAP9LVhxt8fATZetFa4Zum6T6Y5SoP/7zMI2kA3AXrxeRrHw0w yXAii5meEv3aQPtCiUyb1j7e79hqhUN+2yaf0zce333oEMCyDwOFwln1qMY1sqoOaf3olPZM+1oCm HtHtacjFpYuGYRXWjjeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mD9kB-001f7r-RU; Mon, 09 Aug 2021 18:11:24 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mD9k8-001f6x-0r for linux-arm-kernel@lists.infradead.org; Mon, 09 Aug 2021 18:11:21 +0000 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") 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210809_111120_133284_1FB0AF9C X-CRM114-Status: GOOD ( 26.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel