[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH linux-next v2] x86/xen/time: prefer tsc as clocksource when it is invariant
On Mon, Dec 12, 2022 at 01:48:24PM -0500, Boris Ostrovsky wrote: > > On 12/12/22 11:05 AM, Krister Johansen wrote: > > > > diff --git a/arch/x86/include/asm/xen/cpuid.h > > b/arch/x86/include/asm/xen/cpuid.h > > index 6daa9b0c8d11..d9d7432481e9 100644 > > --- a/arch/x86/include/asm/xen/cpuid.h > > +++ b/arch/x86/include/asm/xen/cpuid.h > > @@ -88,6 +88,12 @@ > > * EDX: shift amount for tsc->ns conversion > > * Sub-leaf 2: EAX: host tsc frequency in kHz > > */ > > +#define XEN_CPUID_TSC_EMULATED (1u << 0) > > +#define XEN_CPUID_HOST_TSC_RELIABLE (1u << 1) > > +#define XEN_CPUID_RDTSCP_INSTR_AVAIL (1u << 2) > > +#define XEN_CPUID_TSC_MODE_DEFAULT (0) > > +#define XEN_CPUID_TSC_MODE_EMULATE (1u) > > +#define XEN_CPUID_TSC_MODE_NOEMULATE (2u) > > This file is a copy of Xen public interface so this change should go to Xen > first. Ok, should I split this into a separate patch on the linux side too? > > +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); > > + > > + if (eax & XEN_CPUID_TSC_EMULATED) > > + return 0; > > + > > + if (ebx != XEN_CPUID_TSC_MODE_NOEMULATE) > > + return 0; > > Why is the last test needed? I was under the impression that if the mode was 0 (default) it would be possible for the tsc to become emulated in the future, perhaps after a migration. The presence of the tsc_mode noemulate meant that we could count on the falseneess of the XEN_CPUID_TSC_EMULATED check remaining constant. -K
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |