All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Shier <pshier@google.com>,
	Raghavendra Rao Ananta <rananta@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Oliver Upton <oupton@google.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	kernel-team@android.com
Subject: Re: [PATCH 08/13] clocksource/arm_arch_timer: Work around broken CVAL implementations
Date: Tue, 10 Aug 2021 13:34:07 +0100	[thread overview]
Message-ID: <20210810123407.GB52842@C02TD0UTHF1T.local> (raw)
In-Reply-To: <20210809152651.2297337-9-maz@kernel.org>

On Mon, Aug 09, 2021 at 04:26:46PM +0100, Marc Zyngier wrote:
> The Applied Micro XGene-1 SoC has a busted implementation of the
> CVAL register: it looks like it is based on TVAL instead of the
> other way around. The net effect of this implementation blunder
> is that the maximum deadline you can program in the timer is
> 32bit wide.
> 
> Detect the problematic case and limit the timer to 32bit deltas.
> Note that we don't tie this bug to XGene specifically, as it may
> also catch similar defects on other high-quality implementations.

Do we know of any other implementations that have a similar bug?

> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  drivers/clocksource/arm_arch_timer.c | 38 +++++++++++++++++++++++++++-
>  1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 895844c33351..1c596cd3cc5c 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -778,9 +778,42 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
>  	return 0;
>  }
>  
> +static u64 __arch_timer_check_delta(void)
> +{
> +#ifdef CONFIG_ARM64
> +	u64 tmp;
> +
> +	/*
> +	 * XGene-1 implements CVAL in terms of TVAL, meaning that the
> +	 * maximum timer range is 32bit. Shame on them. Detect the
> +	 * issue by setting a timer to now+(1<<32), which will
> +	 * immediately fire on the duff CPU.
> +	 */
> +	write_sysreg(0, cntv_ctl_el0);
> +	isb();
> +	tmp = read_sysreg(cntvct_el0) | BIT(32);
> +	write_sysreg(tmp, cntv_cval_el0);

This will fire on legitimate implementations fairly often. Consider if
we enter this function at a time where CNTCVT_EL0[32] == 1, where:

* At 100MHz, bit 32 flips every ~42.95
* At 200MHz, bit 32 flips every ~21.47
* At 1GHz, bit 32 flips every ~4.29s

... and ThunderX2 has a 200MHz frequency today, with SBSA recommending
100MHz.

What does XGene-1 return upon a read of CVAL? If it always returns 0 for
the high bits, we could do a timing-insensitive check for truncation of
CVAL, e.g.

| 	/* CVAL must be at least 56 bits wide, as with CNT */
| 	u64 mask = GENMASK(55, 0);
| 	u64 val;
| 
| 	write_sysreg(mask, cntv_cval_el0);
| 	val = read_sysread(cnt_cval_el0);
| 
| 	if (val != mask) {
| 		/* What a great CPU */
| 	}

Thanks,
Mark.

> +	write_sysreg(ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_MASK,
> +		     cntv_ctl_el0);
> +	isb();
> +
> +	tmp = read_sysreg(cntv_ctl_el0);
> +	write_sysreg(0, cntv_ctl_el0);
> +	isb();
> +
> +	if (tmp & ARCH_TIMER_CTRL_IT_STAT) {
> +		pr_warn_once("Detected broken implementation, limiting width to 32bits");
> +		return CLOCKSOURCE_MASK(32);
> +	}
> +#endif
> +	return CLOCKSOURCE_MASK(56);
> +}
> +
>  static void __arch_timer_setup(unsigned type,
>  			       struct clock_event_device *clk)
>  {
> +	u64 max_delta;
> +
>  	clk->features = CLOCK_EVT_FEAT_ONESHOT;
>  
>  	if (type == ARCH_TIMER_TYPE_CP15) {
> @@ -812,6 +845,7 @@ static void __arch_timer_setup(unsigned type,
>  		}
>  
>  		clk->set_next_event = sne;
> +		max_delta = __arch_timer_check_delta();
>  	} else {
>  		clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
>  		clk->name = "arch_mem_timer";
> @@ -828,11 +862,13 @@ static void __arch_timer_setup(unsigned type,
>  			clk->set_next_event =
>  				arch_timer_set_next_event_phys_mem;
>  		}
> +
> +		max_delta = CLOCKSOURCE_MASK(56);
>  	}
>  
>  	clk->set_state_shutdown(clk);
>  
> -	clockevents_config_and_register(clk, arch_timer_rate, 0xf, CLOCKSOURCE_MASK(56));
> +	clockevents_config_and_register(clk, arch_timer_rate, 0xf, max_delta);
>  }
>  
>  static void arch_timer_evtstrm_enable(int divider)
> -- 
> 2.30.2
> 

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Shier <pshier@google.com>,
	Raghavendra Rao Ananta <rananta@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Oliver Upton <oupton@google.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	kernel-team@android.com
Subject: Re: [PATCH 08/13] clocksource/arm_arch_timer: Work around broken CVAL implementations
Date: Tue, 10 Aug 2021 13:34:07 +0100	[thread overview]
Message-ID: <20210810123407.GB52842@C02TD0UTHF1T.local> (raw)
In-Reply-To: <20210809152651.2297337-9-maz@kernel.org>

On Mon, Aug 09, 2021 at 04:26:46PM +0100, Marc Zyngier wrote:
> The Applied Micro XGene-1 SoC has a busted implementation of the
> CVAL register: it looks like it is based on TVAL instead of the
> other way around. The net effect of this implementation blunder
> is that the maximum deadline you can program in the timer is
> 32bit wide.
> 
> Detect the problematic case and limit the timer to 32bit deltas.
> Note that we don't tie this bug to XGene specifically, as it may
> also catch similar defects on other high-quality implementations.

Do we know of any other implementations that have a similar bug?

> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  drivers/clocksource/arm_arch_timer.c | 38 +++++++++++++++++++++++++++-
>  1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 895844c33351..1c596cd3cc5c 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -778,9 +778,42 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
>  	return 0;
>  }
>  
> +static u64 __arch_timer_check_delta(void)
> +{
> +#ifdef CONFIG_ARM64
> +	u64 tmp;
> +
> +	/*
> +	 * XGene-1 implements CVAL in terms of TVAL, meaning that the
> +	 * maximum timer range is 32bit. Shame on them. Detect the
> +	 * issue by setting a timer to now+(1<<32), which will
> +	 * immediately fire on the duff CPU.
> +	 */
> +	write_sysreg(0, cntv_ctl_el0);
> +	isb();
> +	tmp = read_sysreg(cntvct_el0) | BIT(32);
> +	write_sysreg(tmp, cntv_cval_el0);

This will fire on legitimate implementations fairly often. Consider if
we enter this function at a time where CNTCVT_EL0[32] == 1, where:

* At 100MHz, bit 32 flips every ~42.95
* At 200MHz, bit 32 flips every ~21.47
* At 1GHz, bit 32 flips every ~4.29s

... and ThunderX2 has a 200MHz frequency today, with SBSA recommending
100MHz.

What does XGene-1 return upon a read of CVAL? If it always returns 0 for
the high bits, we could do a timing-insensitive check for truncation of
CVAL, e.g.

| 	/* CVAL must be at least 56 bits wide, as with CNT */
| 	u64 mask = GENMASK(55, 0);
| 	u64 val;
| 
| 	write_sysreg(mask, cntv_cval_el0);
| 	val = read_sysread(cnt_cval_el0);
| 
| 	if (val != mask) {
| 		/* What a great CPU */
| 	}

Thanks,
Mark.

> +	write_sysreg(ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_MASK,
> +		     cntv_ctl_el0);
> +	isb();
> +
> +	tmp = read_sysreg(cntv_ctl_el0);
> +	write_sysreg(0, cntv_ctl_el0);
> +	isb();
> +
> +	if (tmp & ARCH_TIMER_CTRL_IT_STAT) {
> +		pr_warn_once("Detected broken implementation, limiting width to 32bits");
> +		return CLOCKSOURCE_MASK(32);
> +	}
> +#endif
> +	return CLOCKSOURCE_MASK(56);
> +}
> +
>  static void __arch_timer_setup(unsigned type,
>  			       struct clock_event_device *clk)
>  {
> +	u64 max_delta;
> +
>  	clk->features = CLOCK_EVT_FEAT_ONESHOT;
>  
>  	if (type == ARCH_TIMER_TYPE_CP15) {
> @@ -812,6 +845,7 @@ static void __arch_timer_setup(unsigned type,
>  		}
>  
>  		clk->set_next_event = sne;
> +		max_delta = __arch_timer_check_delta();
>  	} else {
>  		clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
>  		clk->name = "arch_mem_timer";
> @@ -828,11 +862,13 @@ static void __arch_timer_setup(unsigned type,
>  			clk->set_next_event =
>  				arch_timer_set_next_event_phys_mem;
>  		}
> +
> +		max_delta = CLOCKSOURCE_MASK(56);
>  	}
>  
>  	clk->set_state_shutdown(clk);
>  
> -	clockevents_config_and_register(clk, arch_timer_rate, 0xf, CLOCKSOURCE_MASK(56));
> +	clockevents_config_and_register(clk, arch_timer_rate, 0xf, max_delta);
>  }
>  
>  static void arch_timer_evtstrm_enable(int divider)
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-08-10 12:34 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09 15:26 [PATCH 00/13] clocksource/arm_arch_timer: Add basic ARMv8.6 support Marc Zyngier
2021-08-09 15:26 ` Marc Zyngier
2021-08-09 15:26 ` [PATCH 01/13] clocksource/arm_arch_timer: Drop CNT*_TVAL read accessors Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-11  7:02   ` Oliver Upton
2021-08-11  7:02     ` Oliver Upton
2021-08-24 16:20   ` Mark Rutland
2021-08-24 16:20     ` Mark Rutland
2021-08-09 15:26 ` [PATCH 02/13] clocksource/arm_arch_timer: Extend write side of timer register accessors to u64 Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 16:12   ` Oliver Upton
2021-08-09 16:12     ` Oliver Upton
2021-08-24 16:20   ` Mark Rutland
2021-08-24 16:20     ` Mark Rutland
2021-08-09 15:26 ` [PATCH 03/13] clocksource/arm_arch_timer: Move system register timer programming over to CVAL Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-11  7:15   ` Oliver Upton
2021-08-11  7:15     ` Oliver Upton
2021-08-24 16:21   ` Mark Rutland
2021-08-24 16:21     ` Mark Rutland
2021-08-09 15:26 ` [PATCH 04/13] clocksource/arm_arch_timer: Move drop _tval from erratum function names Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 16:16   ` Oliver Upton
2021-08-09 16:16     ` Oliver Upton
2021-08-24 16:29   ` Mark Rutland
2021-08-24 16:29     ` Mark Rutland
2021-08-09 15:26 ` [PATCH 05/13] clocksource/arm_arch_timer: Fix MMIO base address vs callback ordering issue Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 16:52   ` Oliver Upton
2021-08-09 16:52     ` Oliver Upton
2021-08-10  8:27     ` Marc Zyngier
2021-08-10  8:27       ` Marc Zyngier
2021-08-24 16:44   ` Mark Rutland
2021-08-24 16:44     ` Mark Rutland
2021-08-09 15:26 ` [PATCH 06/13] clocksource/arm_arch_timer: Move MMIO timer programming over to CVAL Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 15:26 ` [PATCH 07/13] clocksource/arm_arch_timer: Advertise 56bit timer to the core code Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 15:26 ` [PATCH 08/13] clocksource/arm_arch_timer: Work around broken CVAL implementations Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-10 12:34   ` Mark Rutland [this message]
2021-08-10 12:34     ` Mark Rutland
2021-08-10 13:15     ` Marc Zyngier
2021-08-10 13:15       ` Marc Zyngier
2021-08-09 15:26 ` [PATCH 09/13] clocksource/arm_arch_timer: Remove any trace of the TVAL programming interface Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 15:26 ` [PATCH 10/13] clocksource/arm_arch_timer: Drop unnecessary ISB on CVAL programming Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 15:26 ` [PATCH 11/13] clocksource/arm_arch_timer: Fix masking for high freq counters Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 16:45   ` Oliver Upton
2021-08-09 16:45     ` Oliver Upton
2021-08-10  8:40     ` Marc Zyngier
2021-08-10  8:40       ` Marc Zyngier
2021-08-10  9:09       ` Oliver Upton
2021-08-10  9:09         ` Oliver Upton
2021-08-09 15:26 ` [PATCH 12/13] arm64: Add a capability for FEAT_EVC Marc Zyngier
2021-08-09 15:26   ` Marc Zyngier
2021-08-09 16:30   ` Oliver Upton
2021-08-09 16:30     ` Oliver Upton
2021-08-09 16:34     ` Oliver Upton
2021-08-09 16:34       ` Oliver Upton
2021-08-09 18:02     ` Marc Zyngier
2021-08-09 18:02       ` Marc Zyngier
2021-08-09 18:21       ` Oliver Upton
2021-08-09 18:21         ` Oliver Upton
2021-08-09 18:23         ` Oliver Upton
2021-08-09 18:23           ` Oliver Upton
2021-08-09 15:26 ` [PATCH 13/13] arm64: Add CNT{P,V}CTSS_EL0 alternatives to cnt{p,v}ct_el0 Marc Zyngier
2021-08-09 15:26   ` [PATCH 13/13] arm64: Add CNT{P, V}CTSS_EL0 alternatives to cnt{p, v}ct_el0 Marc Zyngier
2021-08-09 16:42   ` [PATCH 13/13] arm64: Add CNT{P,V}CTSS_EL0 alternatives to cnt{p,v}ct_el0 Oliver Upton
2021-08-09 16:42     ` [PATCH 13/13] arm64: Add CNT{P, V}CTSS_EL0 alternatives to cnt{p, v}ct_el0 Oliver Upton
2021-08-09 18:11     ` [PATCH 13/13] arm64: Add CNT{P,V}CTSS_EL0 alternatives to cnt{p,v}ct_el0 Marc Zyngier
2021-08-09 18:11       ` [PATCH 13/13] arm64: Add CNT{P, V}CTSS_EL0 alternatives to cnt{p, v}ct_el0 Marc Zyngier
2021-08-09 18:17       ` [PATCH 13/13] arm64: Add CNT{P,V}CTSS_EL0 alternatives to cnt{p,v}ct_el0 Oliver Upton
2021-08-09 18:17         ` [PATCH 13/13] arm64: Add CNT{P, V}CTSS_EL0 alternatives to cnt{p, v}ct_el0 Oliver Upton
2021-08-10  7:59         ` [PATCH 13/13] arm64: Add CNT{P,V}CTSS_EL0 alternatives to cnt{p,v}ct_el0 Marc Zyngier
2021-08-10  7:59           ` [PATCH 13/13] arm64: Add CNT{P, V}CTSS_EL0 alternatives to cnt{p, v}ct_el0 Marc Zyngier

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=20210810123407.GB52842@C02TD0UTHF1T.local \
    --to=mark.rutland@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=kernel-team@android.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@google.com \
    --cc=pshier@google.com \
    --cc=rananta@google.com \
    --cc=ricarkol@google.com \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.