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
next prev parent 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: linkBe 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.