Re: [PATCH v2] clocksource/arm_arch_timer: Fix masking for high freq counters

On Sat, 07 Aug 2021 23:30:20 +0100,
Linus Walleij [off-list ref] wrote:

On Sat, Aug 7, 2021 at 9:14 PM Oliver Upton [off-list ref] wrote:

quoted

Unfortunately, the architecture provides no means to determine the bit
width of the system counter. However, we do know the following from the
specification:

 - the system counter is at least 56 bits wide
 - Roll-over time of not less than 40 years

To date, the arch timer driver has depended on the first property,
assuming any system counter to be 56 bits wide and masking off the rest.
However, combining a narrow clocksource mask with a high frequency
counter could result in prematurely wrapping the system counter by a
significant margin. For example, a 56 bit wide, 1GHz system counter
would wrap in a mere 2.28 years!

This is a problem for two reasons: v8.6+ implementations are required to
provide a 64 bit, 1GHz system counter. Furthermore, before v8.6,
implementers may select a counter frequency of their choosing.

Fix the issue by deriving a valid clock mask based on the second
property from above. Set the floor at 56 bits, since we know no system
counter is narrower than that.

Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Oliver Upton <redacted>

This patch looks good to me:
Reviewed-by: Linus Walleij <redacted>

Just a thought that crossed my mind: as this is real hardware we are
talking about mostly, how hard would it be for arch_counter_get_width()
to detect how wide it actually is if nbits > 56?

I would do something like this pseudocode:

nbits = 56;
while (nbits < 64)
    startval = GENMASK(nbits, 0);
    write_counter(startval);

That's where things stop. The counter is not writable, and for good
reasons (it is shared with all the CPUs in the system).

    start_counter;
    nsleep(1);
    stop_counter;
    now = read_counter;
    if (now < startval)
         /* Ooops it wrapped */
         break;
    nbits++

pr_info("counter has %d bits\n", nbits);

Or did you folks already try this approach?

The only way to emulate this behaviour is to use CNTVOFF_EL2 at EL2 to
offset a guest view of the counter, and to run minimal guest that will
do the start/stop/compare work. Given that it involves running a guest
at a point where we are unable to do so, and that it cannot work when
booted at EL1, we're left with guesswork.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

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