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 45887C433EF for ; Sun, 22 May 2022 15:37:10 +0000 (UTC) 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=VbEXb/hrbfPIIDW1tbt07jTwKDEli0A9WyUqthRWOX4=; b=Szx2sI+KXPc5qZ Ib00pm9fWFs98409y2HJlonsOO2WfDqhjgzH/5B4dNc87njZF98w6pK5AkFqUyHFNu5hsAZn2udBh fpTm7QQZ5IBSzUyMXtZtJSbnwyvQjQp6S606mWBLmP0AXaAZD/jgxuEzgyda0ZybnB5jOIAyajbCv PnMgES9Qk3X3/mbhU87OtJGbZBwK/gOLzknsMqC8ebLRrvqu8eJv7REv0t8kVR6zNBaq0/VCwLjM4 Z9iAvbKF9luaB/ku7RR5SKrhk9JYYnVVqKxq9Z5p784kcthQmhQb28jeW1LdWwBaiPL9g16IxVjuA D38Uo4SG+rm9sKpITR3A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nsncY-001anS-9l; Sun, 22 May 2022 15:35:54 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nsncS-001amP-Mg for linux-arm-kernel@lists.infradead.org; Sun, 22 May 2022 15:35:52 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B146EB80CA1; Sun, 22 May 2022 15:35:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 712FDC385AA; Sun, 22 May 2022 15:35:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653233745; bh=Ni6fjoGMdQzbQmZpLoAHQFcIXLw4p5hqcCJJSrIedEw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pdjkKNJpUux7FDHj3pAlVI8Su/CRzMtqOihjp6TXsFhRzMS1+TsROlMXw5Ibh/w2J fg4V2aoORBmfWJumujotUYxbAovyL9q/+r3vHk0oEXoLbD0rX866pSTc59ufmIegkO gZiIFLgvD/Jm/FzEToUSe1Z5guBbx4S0upkXpOAL7DsLHM///1vCwxUMyIDidlityq s0DBG4rXrXcvCayRLwNlCB5M9d0rf7Xzdu33YBi8Y8o7tUG9WUrZAVwmbClQsoDGos 9I0ANxrZHrkSf6yhTOxXVzfmFh+NC5qblIIdTaRVAxFnrs8wnYxa4y9JvdR/u82R7Q diJEurUswCyRQ== Received: from ppp-94-66-34-157.home.otenet.gr ([94.66.34.157] helo=wait-a-minute.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 1nsncM-00D06N-UA; Sun, 22 May 2022 16:35:43 +0100 Date: Sun, 22 May 2022 16:35:40 +0100 Message-ID: <87ilpxmvg3.wl-maz@kernel.org> From: Marc Zyngier To: Kyle Huey Cc: open list , "moderated list:ARM PORT" , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , yyc1992@gmail.com, Keno Fischer , "Robert O'Callahan" , Thomas Gleixner , Borislav Petkov , Suzuki K Poulose , Will Deacon Subject: Re: arm64 equivalents of PR_SET_TSC/ARCH_SET_CPUID In-Reply-To: References: 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: 94.66.34.157 X-SA-Exim-Rcpt-To: me@kylehuey.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, yyc1992@gmail.com, keno@juliacomputing.com, robert@ocallahan.org, tglx@linutronix.de, bp@alien8.de, suzuki.poulose@arm.com, will.deacon@arm.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-20220522_083549_080787_5BD36537 X-CRM114-Status: GOOD ( 34.14 ) 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 Sat, 21 May 2022 21:07:14 +0100, Kyle Huey wrote: > > There is ongoing work by Yichao Yu to make rr, a userspace record and > replay debugger[0], production quality on arm64[1]. One of the bigger > remaining issues is the kernel's emulation of accesses to certain > system registers[2] that reflect timing and CPU capabilities and are > either non-deterministic or can vary from processor to processor. Just to make things clear: the kernel usually doesn't provide any emulation for registers such as CNTVCT_EL0. On sane HW, userspace is free to access it directly without any mediation (we only use the trap for the sake of dealing with HW bugs). > We > would like to add the ability to tell the kernel to decline to emulate > these instructions for a given task and pass that responsibility onto > the supervising rr ptracer. There are analogous processor features and > disabling mechanisms on x86. The RDTSC instruction is controlled by > prctl(PR_SET_TSC) and the CPUID instruction is controlled (when the > hardware allows) by arch_prctl(ARCH_SET_CPUID). > > The questions I'd like to raise are: > > 1. Is it appropriate to reuse PR_SET_TSC for roughly equivalent > functionality on AArch64? (even if the AArch64 feature is not actually > named Time Stamp Counter). My gut feeling is that you really don't want to hijack an existing API, because this is fundamentally different. The Linux arm64 ABI mandates that the counter (and the frequency register associated with it) are accessible, and you can't make them disappear. >From what I understand, you are relying on the TSC being disabled in the tracee and intercepting the signal that gets delivered when it accesses the counter. Is that correct? Assuming I'm right, I think it'd make a lot more sense if there was a first class ptrace option, if only because this would mandate the kernel to start trapping things that are not trapped today. It also begs the question of the fate of CNTFRQ_EL0, since you want to be able to replay traces from one system to another (and the counter is meaningless without the frequency). Finally, what of the VDSO, which is by far the most common user of the counter? I can totally imagine the VDSO getting stuck if emulation is used and the sequence counter moves synchronously with the traps (which is why we disable the VDSO when trapping CNTVCT_EL0). > 2. Likewise for ARCH_SET_CPUID We don't just emulate a single register, but a whole class of them. If you are to present a different view for any of those, you'll need to handle the lot (I really can't see why one would be more important than the others). So SET_CPUID really is the wrong tool. I'd rather there was (again) an API that described exactly that. > 3. Since arch_prctl is x86-only, does it make more sense to add > arch_prctl to arm64 or to duplicate ARCH_SET_CPUID into the prctl > world? (e.g. a PR_SET_CPUID that works on both x86/arm64) I don't think any applies here. Different architectures have different ABI requirements, and you can't really merge the two. Because the next thing you know, you'll ask for the same thing for PMU registers, and try to map them onto something else. Overall, this would be better served by a framework for userspace delegation of sysreg access by a ptrace'd process. Let's try to look at it in those terms rather than casting arm64 into a seemingly unrelated API. Thanks, M. > > - Kyle > > [0] https://rr-project.org/ > [1] https://github.com/rr-debugger/rr/issues/3234 > [2] e.g. CNTVCT_EL0 and MIDR_EL1, among others > -- 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