Re: [PATCH RFC] x86/time: avoid early uses of NOW() to return zero

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, May 06, 2026 at 11:37:41AM +0200, Jan Beulich wrote:
> Waiting loops like the one in flush_command_buffer() will degenerate to
> infinite ones when used early enough for NOW() to still return constant
> zero. Make sure the returned value at least monotonically increases.
> 
> Do this only in get_s_time(), as producing a sane value in
> get_s_time_fixed() for non-zero inputs won't be reasonably possible.
> 
> Reported-by: Roger Pau Monné <roger.pau@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> RFC: This breaks at least the TSM_BOOT case printk_start_of_line(), which
>      checks for NOW() returning 0 (falling back to TSM_RAW in this case).
>      For now I have no idea how to avoid this, except that when CPUID leaf
>      0x15 is available we could leverage that to put in place at least an
>      approximate scale value. Doing so could, however, lead to a
>      discontinuity (returned value moving backwards) once the final scale
>      value was put in place. (Note, however, that such a discontinuity can
>      also result from init_percpu_time() using the BSP's scale value as
>      initial estimate for APs. Then again local_time_calibration() at
>      least makes an attempt at avoiding such.)

For the purposes of printk_start_of_line() we could unconditionally
use get_cycles() when system_state < SYS_STATE_smp_boot IMO.  Using
the frequency value from CPUID seems like a good approach also on
boxes that expose this information.

I wonder, we seem to unconditionally perform the TSC calibration
against a known frequency time source, wouldn't it be more reliable to
use the information from leaf 0x15 when available?

> 
> RFC: While generally the mentioned waiting loops will take longer to time
>      out, on a very fast CPU tight loops may time out too early.

I was wondering about that, increasing just a nano-second for each
call seems like it's going to make progress fairly slow?  Obviously
depends on how tights the calls to NOW() are in the outside loop.

Maybe when lacking frequency information from CPUID we could assume
something like 8GHz and scale the TSC based on that?  AFAICT it's
advisable to use a frequency greater than any CPU, as then we don't
risk NOW() running too fast.

> RFC: In get_s_time_fixed(), should we perhaps assert that the scale was
>      set?

Might be good, but I would like to see what explodes when doing
that...

> I don't think Fixes: tags should be put here. If we did, we'd have to
> enumerate all introductions of early uses of NOW() (or get_s_time()), with
> the exception of those dealing with getting back 0 (which I expect is only
> printk_start_of_line()).

I'm fine with no fixes tag, but we need to remember to backport this
one.

Thanks, Roger.