From: Ben Horgan <ben.horgan@arm.com>
To: Marc Zyngier <maz@kernel.org>, linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [PATCH 2/3] clocksource/drivers/arm_arch_timer: Expose a direct accessor for the virtual counter
Date: Thu, 26 Feb 2026 13:48:38 +0000 [thread overview]
Message-ID: <aa607343-9dd8-4e96-a7e3-5937fa084891@arm.com> (raw)
In-Reply-To: <20260226082234.26707-3-maz@kernel.org>
Hi Marc,
On 2/26/26 08:22, Marc Zyngier wrote:
> We allow access to the architected counter via arch_timer_read_counter().
> However, this accessor can either be the virtual or the physical
> view of the counter, depending on how the kernel has been booted.
>
> At the same time, we have some architectural features (such as WFIT,
> WFET) that rely on the virtual counter, and nothing else.
>
> If implementations were perfect, we'd rely on reading CNTVCT_EL0,
> and be done with it. However, we have a bunch of broken implementations
> in the wild, which rely on preemption being disabled and other
> costly workarounds.
>
> In order to provide decent performance on non-broken HW while still
> supporting the legacy horrors, expose arch_timer_read_vcounter() as
> a new helper that hides this complexity.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 5 +++++
> include/clocksource/arm_arch_timer.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 90aeff44a2764..4e4a62e1c9439 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -137,6 +137,8 @@ static noinstr u64 arch_counter_get_cntvct(void)
> u64 (*arch_timer_read_counter)(void) __ro_after_init = arch_counter_get_cntvct;
> EXPORT_SYMBOL_GPL(arch_timer_read_counter);
>
> +u64 (*arch_timer_read_vcounter)(void) __ro_after_init = arch_counter_get_cntvct;
> +
> static u64 arch_counter_read(struct clocksource *cs)
> {
> return arch_timer_read_counter();
> @@ -931,6 +933,9 @@ static void __init arch_counter_register(void)
> }
>
> arch_timer_read_counter = rd;
> + arch_timer_read_vcounter = (arch_timer_counter_has_wa() ?
This matches what is done for arch_timer_read_counter but it seems a bit
surprising to me that arch_timer_counter_has_wa() is checking that the
workaround is in use and not whether the workaround should be in use. Do
we need to worry about what happens if the workaround fails to be enabled?
> + arch_counter_get_cntvct_stable :
> + arch_counter_get_cntvct);
> clocksource_counter.vdso_clock_mode = vdso_default;
>
> width = arch_counter_get_width();
> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
> index 2eda895f19f54..5bfd6a5db75aa 100644
> --- a/include/clocksource/arm_arch_timer.h
> +++ b/include/clocksource/arm_arch_timer.h
> @@ -88,6 +88,7 @@ struct arch_timer_mem {
>
> extern u32 arch_timer_get_rate(void);
> extern u64 (*arch_timer_read_counter)(void);
> +extern u64 (*arch_timer_read_vcounter)(void);
> extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void);
> extern bool arch_timer_evtstrm_available(void);
>
Thanks,
Ben
next prev parent reply other threads:[~2026-02-26 13:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 8:22 [PATCH 0/3] arm64: WFxT fixes, take #2 Marc Zyngier
2026-02-26 8:22 ` [PATCH 1/3] arm64: Fix sampling the "stable" virtual counter in preemptible section Marc Zyngier
2026-02-26 8:22 ` [PATCH 2/3] clocksource/drivers/arm_arch_timer: Expose a direct accessor for the virtual counter Marc Zyngier
2026-02-26 13:48 ` Ben Horgan [this message]
2026-02-26 14:03 ` Ben Horgan
2026-02-26 16:48 ` Marc Zyngier
2026-02-26 18:09 ` Will Deacon
2026-02-26 8:22 ` [PATCH 3/3] arm64: Convert __delay_cycles() to arch_timer_read_vcounter() Marc Zyngier
2026-02-26 12:53 ` [PATCH 0/3] arm64: WFxT fixes, take #2 André Draszik
2026-02-26 13:36 ` Ben Horgan
2026-02-27 3:16 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa607343-9dd8-4e96-a7e3-5937fa084891@arm.com \
--to=ben.horgan@arm.com \
--cc=catalin.marinas@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox