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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 22B4CC52D7C for ; Fri, 23 Aug 2024 12:05:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YD88pZ5wA7R7qrRn3GzbdXUA0yHOl7/+G1jUktE7o0s=; b=dblwu2NSAbJL2jdN2qfnpCqknw PV2uQO5cXCkvnUJJzoxhdWtU1sLak7Xrm3ppDJxgDOH6Dndt9XrjZGA/94SxfKtRz2HGGqLpHpwdh +QvZEn4CBzZvMyZLQOWfuUtYDVr901T5z3hvXRyypqpHroMh+GSUKbdf2e4BPy4h1WYH3gfRYy4V9 8fVpLohhLobJyD/r2g0b3Zhp2+x7WZPwu5U3KeiBJjfehUtUyy4zkZB57Hh0+i8eQvBIUq4om9mEy sa8C63bf7jUdVpefNYvQWDOXHTnREOldv0abZKr8Llm4NUHageXa4kSK3wQu30MDIivvGse1ziqBZ dKi4ioKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1shT2B-0000000GdQK-4A6v; Fri, 23 Aug 2024 12:04:51 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1shT0K-0000000Gczg-3n6W for linux-arm-kernel@lists.infradead.org; Fri, 23 Aug 2024 12:02:59 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3C3416120E; Fri, 23 Aug 2024 12:02:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 847FDC32786; Fri, 23 Aug 2024 12:02:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724414575; bh=A/FgJxDum1qiI66pcETDJ9C+glDvixZYPG/fureO3eQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B05zRse9JXbm3Nul+7T8C2hmmlHBiYh7ZDCrcrXhTMig4moLuGuCU1SoXhY1OjHk7 7oYtxfzsmF9oe5NmVlczQ4+Lmu27JsjqqYbjdHaa8bVaoqptXLe2xFnfjo++5VOejg x8dCrZWDkfJf1FSy8qDdekAM9Z1Se2l8f0XVG/URcb8VkgOJpZiHzQROUM+waRGtFU BhUymzBwVNnQJnp9rwu6Jwr6yCbLuEtnJ6ca5Oya7d2obSQ0WT2gNuQP3K1Nhecbxa MyjX+960VIwonou4rqhiU+RUPXIpJMMsoidWlGei5mB4BNXMcvKQij+lDu1RvoQZAk usnsFwlOfvSjQ== Date: Fri, 23 Aug 2024 13:02:51 +0100 From: Will Deacon To: Peter Collingbourne Cc: Catalin Marinas , Marc Zyngier , linux-arm-kernel@lists.infradead.org, Yichao Yu , Robert O'Callahan , Keno Fischer Subject: Re: [PATCH v2] arm64: Implement prctl(PR_{G,S}ET_TSC) Message-ID: <20240823120247.GC32020@willie-the-truck> References: <20240517212553.3597611-1-pcc@google.com> <20240816102004.GA23304@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240823_050257_076171_38FD40B9 X-CRM114-Status: GOOD ( 29.33 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 16, 2024 at 12:04:14PM -0700, Peter Collingbourne wrote: > On Fri, Aug 16, 2024 at 3:20 AM Will Deacon wrote: > > > > Hi Peter, > > > > On Mon, Jun 10, 2024 at 01:24:51PM -0700, Peter Collingbourne wrote: > > > On Fri, May 17, 2024 at 2:25 PM Peter Collingbourne wrote: > > > > > > > > On arm64, this prctl controls access to CNTVCT_EL0, CNTVCTSS_EL0 and > > > > CNTFRQ_EL0 via CNTKCTL_EL1.EL0VCTEN. Since this bit is also used to > > > > implement various erratum workarounds, check whether the CPU needs > > > > a workaround whenever we potentially need to change it. > > > > > > Ping. > > > > Chatting with Marc and Catalin about this, we're a little uneasy about > > exposing a prctl() for this. Ptrace does seem like a much better fit. > > I still disagree for the consistency and ease of use reasons > previously mentioned. But I suppose that a ptrace() API would be > better than nothing. > > > Can you add a new regset for the counter instead? > > Is your idea that setting the regset to a specific CNTVCT_EL0 value > will cause the kernel to trap and automatically return the previously > set CNTVCT_EL0 without notifying the tracer? I don't think it is > suitable for rr. This would force rr to set CNTVCT_EL0 to a specific > value and keep it constant (or at least it can change it when the > process is stopped for some other reason), whereas what rr wants to do > is handle a CNTVCT_EL0 read at record time by reading CNTVCT_EL0 and > recording the value that was read, and replaying those values at > replay time. To give one example of where a constant CNTVCT_EL0 can > cause problems, imagine that we have a program such as a delay loop > that reads CNTVCT_EL0 repeatedly and compares its value to a > previously read one and only makes progress if the value changes. Such > a program will not make progress if there is no way to make CNTVCT_EL0 > change between reads. So if it has to be a ptrace() API, then I think > it needs to be an opt-in to putting the process into a stopped state > upon reading CNTVCT_EL0. Thanks, makes sense. I replied on the main patch. Will