Re: [PATCH linux-next v2] x86/xen/time: prefer tsc as clocksource when it is invariant

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.12.2022 17:05, Krister Johansen wrote:
> Kvm elects to use tsc instead of kvm-clock when it can detect that the
> TSC is invariant.
> 
> (As of commit 7539b174aef4 ("x86: kvmguest: use TSC clocksource if
> invariant TSC is exposed")).
> 
> Notable cloud vendors[1] and performance engineers[2] recommend that Xen
> users preferentially select tsc over xen-clocksource due the performance
> penalty incurred by the latter.  These articles are persuasive and
> tailored to specific use cases.  In order to understand the tradeoffs
> around this choice more fully, this author had to reference the
> documented[3] complexities around the Xen configuration, as well as the
> kernel's clocksource selection algorithm.  Many users may not attempt
> this to correctly configure the right clock source in their guest.
> 
> The approach taken in the kvm-clock module spares users this confusion,
> where possible.
> 
> Both the Intel SDM[4] and the Xen tsc documentation explain that marking
> a tsc as invariant means that it should be considered stable by the OS
> and is elibile to be used as a wall clock source.  The Xen documentation
> further clarifies that this is only reliable on HVM and PVH because PV
> cannot intercept a cpuid instruction.

Without meaning to express a view on the argumentation as a whole, this
PV aspect is suspicious. Unless you open-code a use of the CPUID insn
in the kernel, all uses of CPUID are going to be processed by Xen by
virtue of the respective pvops hook. Documentation says what it says
for environments where this might not be the case.

> @@ -474,15 +475,55 @@ static void xen_setup_vsyscall_time_info(void)
>       xen_clocksource.vdso_clock_mode = VDSO_CLOCKMODE_PVCLOCK;
>  }
>  
> +/*
> + * Check if it is possible to safely use the tsc as a clocksource.  This is 
> only
> + * true if the domain is HVM or PVH, the hypervisor notifies the guest that 
> its
> + * tsc is invariant, and the tsc instruction is not going to be emulated.
> + */
> +static int __init xen_tsc_safe_clocksource(void)
> +{
> +     u32 eax, ebx, ecx, edx;
> +
> +     if (!(xen_hvm_domain() || xen_pvh_domain()))
> +             return 0;
> +
> +     if (!(boot_cpu_has(X86_FEATURE_CONSTANT_TSC)))
> +             return 0;
> +
> +     if (!(boot_cpu_has(X86_FEATURE_NONSTOP_TSC)))
> +             return 0;
> +
> +     if (check_tsc_unstable())
> +             return 0;
> +
> +     cpuid(xen_cpuid_base() + 3, &eax, &ebx, &ecx, &edx);

Xen leaf 3 has sub-leaves, so I think you need to set ecx to zero before
this call.

Jan