Reads of the physical counter and the virtual counter registers "can occur
speculatively and out of order relative to other instructions executed on
the same PE" [1, 2].
There is no theoretical limit to the number of instructions that the CPU
can reorder and we use the counter value to program the timer to fire in
the future. Add an ISB before reading the counter to make sure the read
instruction is not reordered too long in the past with regard to the
instruction that programs the timer alarm, thus causing the timer to fire
unexpectedly. This matches what Linux does (see
arch/arm64/include/asm/arch_timer.h).
Because we use the counter value to program the timer, we create a register
dependency [3] between the value that we read and the value that we write to
CVAL and thus we don't need a barrier after the read. Linux does things
differently because the read needs to be ordered with regard to a memory
load (more information in commit 75a19a0202db ("arm64: arch_timer: Ensure
counter register reads occur with seqlock held")).
This also matches what we already do in get_cntvct from
lib/arm{,64}/asm/processor.h.
[1] ARM DDI 0487E.a, section D11.2.1
[2] ARM DDI 0487E.a, section D11.2.2
[3] ARM DDI 0486E.a, section B2.3.2
Signed-off-by: Alexandru Elisei <alexandru.elisei@xxxxxxx>
---
arm/timer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arm/timer.c b/arm/timer.c
index c6ea108cfa4b..e758e84855c3 100644
--- a/arm/timer.c
+++ b/arm/timer.c
@@ -30,6 +30,7 @@ static void ptimer_unsupported_handler(struct pt_regs *regs, unsigned int esr)
static u64 read_vtimer_counter(void)
{
+ isb();
return read_sysreg(cntvct_el0);
}
@@ -68,6 +69,7 @@ static void write_vtimer_ctl(u64 val)
static u64 read_ptimer_counter(void)
{
+ isb();
return read_sysreg(cntpct_el0);
}
--
2.20.1
