From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9FAB239A7EC for ; Mon, 20 Apr 2026 10:44:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776681853; cv=none; b=X5Lb/PI/mtb9VrPysBt1FJgKTSZXdRk29ytwMXTw0V1lVSWSoe79jsu0xuyVlTpZa/EkRGxQSmcAVwMYpoFsoQBFbxFXPeZ6MF6F5vLKNnKyiodOUDqxTRFMs4lIkkr8KPENQFH/FjdtPqBS7OOQEaOFJ4rnSgLn3Oubo80aBpU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776681853; c=relaxed/simple; bh=sCv1hVZNq0VWhETm89fXt9Usc7Qr7cK3/Frw8lB2C0k=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=VW4Z+4+tVWGR4Ysfr6HGwW8AWvJLKGQjTus/oUm5IWDe/wpvpnx3LgQYFmhibfK5RHxX/m3/vooPAGWdRWtLr0p+dpq6NC76gFJ+pIEloifqhCFE8qmlcyx3z1C0YNokUWE7c3lA5lP02mH3huKYK7kJBSLC7yg0Kr9bEqL/WjM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W/qMESO8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="W/qMESO8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45973C19425; Mon, 20 Apr 2026 10:44:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776681853; bh=sCv1hVZNq0VWhETm89fXt9Usc7Qr7cK3/Frw8lB2C0k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=W/qMESO8jYCmDVAfRoKMJ6fJ31opGQK35+c4McQTGMGMLenKGZrudK2fWcAXxaGLn Vl+RrqGJ4Di0ADFlWZ53zmG/0+3MTYCfaxKA2VoQBoGkF8udgBeVjbw4zlcgK5hDLA gHZhsWREJvFrGvbbSO97/FZf8Cum+EI1hPrQzy058Wqa57fJ0J4hVuK6GupAwBkm1k VpX9FoRDNScoJ1kftULBVJSlLECh0MA3bZ84oxRFstFZbeDdjtaP39ztaC0oo75S2s aAutkf7MhKaA3+CkC6KwPQX5GLikp65nzxGdVdo0ojyOWJBcP7bY70JFaOKG3P6hTt sVkE91pUrGwEA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wEm6s-0000000D1qi-3itN; Mon, 20 Apr 2026 10:44:10 +0000 Date: Mon, 20 Apr 2026 11:44:10 +0100 Message-ID: <86pl3t29ol.wl-maz@kernel.org> From: Marc Zyngier To: Puranjay Mohan , Will Deacon Cc: bpf@vger.kernel.org, Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Eduard Zingerman , Kumar Kartikeya Dwivedi , Mykyta Yatsenko , Xu Kuohai , Vadim Fedorenko , Catalin Marinas , kernel-team@meta.com Subject: Re: [PATCH bpf-next v13 6/6] bpf, arm64: Add JIT support for cpu time counter kfuncs In-Reply-To: References: <20260418131614.1501848-1-puranjay@kernel.org> <20260418131614.1501848-7-puranjay@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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: puranjay@kernel.org, will@kernel.org, bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net, martin.lau@kernel.org, eddyz87@gmail.com, memxor@gmail.com, mykyta.yatsenko5@gmail.com, xukuohai@huaweicloud.com, vadim.fedorenko@linux.dev, catalin.marinas@arm.com, kernel-team@meta.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 20 Apr 2026 11:16:34 +0100, Will Deacon wrote: > > [+ Marc] > > On Sat, Apr 18, 2026 at 06:16:04AM -0700, Puranjay Mohan wrote: > > Add ARM64 JIT inlining for bpf_get_cpu_time_counter() and > > bpf_cpu_time_counter_to_ns() kfuncs. > > > > bpf_get_cpu_time_counter() is JIT-inlined as: > > > > ISB // serialize instruction stream > > MRS Xn, CNTVCT_EL0 // read architected timer counter > > > > The ISB before the MRS is required for ordering, matching the kernel's > > arch_timer_read_cntvct_el0() implementation. > > Careful here: this will _not_ order counter accesses against normal > memory barriers (e.g. smp_mb(), acquire/release). If you need that, then > you need something like arch_counter_enforce_ordering(), which we do > have in __arch_counter_get_cntvct(). > > Furthermore, using the virtual counter may expose you to situations > where a guest value for CNTVOFF is installed (e.g. during the VCPU run > loop). Given all the contexts in which BPF can run, this worries me a > little as you might end up seeing a non-monotonic view of time between > BPF programs. Yup, and this will catch you out in subtle ways depending on whether the host runs at EL2 or not. The kernel (mostly) avoids this pitfall by picking the physical counter for sched_clock() when running at EL2, so that it isn't directly affected by CNTVOFF_EL2. I suspect that you'll need something similar if you insist on a globally monotonic view of the counter. > > > On newer CPUs it will be JITed to: > > > > MRS Xn, CNTVCTSS_EL0 // self-synchronized (ISB not needed) > > > > bpf_cpu_time_counter_to_ns() is JIT-inlined using mult/shift constants > > computed at JIT time from the architected timer frequency (CNTFRQ_EL0): And what happens when CNTFRQ_EL0 is not populated, as it is the case on a lot of stupidly integrated HW? The kernel has a fallback, but you don't seem to make use of it here. > > > > MOV Xtmp, #mult // load conversion multiplier > > MUL Xn, Xarg, Xtmp // delta_ticks * mult > > LSR Xn, Xn, #shift // >> shift = nanoseconds > > > > On systems with a 1GHz counter (e.g., Neoverse-V2), mult=1 and shift=0, > > so the conversion collapses to a single MOV (identity). > > Do you have any performance numbers to show that this is worthwhile > compared to calling a helper wrapping __arch_counter_get_cntvct(). > > > Signed-off-by: Puranjay Mohan > > --- > > arch/arm64/include/asm/insn.h | 2 + > > arch/arm64/net/bpf_jit.h | 4 ++ > > arch/arm64/net/bpf_jit_comp.c | 54 +++++++++++++++++++ > > .../selftests/bpf/progs/verifier_cpu_cycles.c | 50 ++++++++++++++++- > > 4 files changed, 109 insertions(+), 1 deletion(-) > > Aren't you conveniently ignoring CPU errata here? I suspect this needs > to be predicated on the absence of those, in a similar way to how the > vDSO deals with the 'vsdo_clockmode'. And I'm afraid this still is the common case... M. -- Without deviation from the norm, progress is not possible.