On Sat, May 30, 2026, [email protected] wrote: > > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > > index 487ad838c4418..36d66abf53796 100644 > > --- a/arch/x86/xen/time.c > > +++ b/arch/x86/xen/time.c > > @@ -42,6 +42,17 @@ static unsigned int __init xen_tsc_khz(void) > > { > > struct pvclock_vcpu_time_info *info = > > &HYPERVISOR_shared_info->vcpu_info[0].time; > > + u32 base = xen_cpuid_base(); > > + u32 eax, ebx, ecx, edx; > > + > > + /* > > + * If Xen provides the guest TSC frequency directly in CPUID > > + * (leaf 3, sub-leaf 0, ECX), use that instead of reverse- > > + * calculating from the pvclock mul/shift. > > + */ > > + cpuid_count(base + 3, 0, &eax, &ebx, &ecx, &edx); > > + if (ecx) > > + return ecx; > > [Severity: High] > Is it possible for the hypervisor to support a maximum leaf of base + 2, > resulting in an out-of-bounds CPUID query here? > > Looking at xen_cpuid_base(), it calls cpuid_base_hypervisor(XEN_SIGNATURE, 2) > which only guarantees that the hypervisor supports up to leaf base + 2. > > If the hypervisor does not support base + 3, this CPUID query could be out > of bounds. Processors handling out-of-bounds CPUID requests typically return > data from the maximum basic leaf.
Heh, depends on the hypervisor. This quirk is specific to Intel CPUs, and so KVM emulates this behavior only when the advertised vCPU vendor is Intel. Anyways, AFAICT, Sashiko is right to be skeptical, I don't see anything obvious that guarantees +3 will be supported. David, can you send this as a standalone patch, and either address Sashiko's concern or add a blurb/comment explaining why it's safe? Unlike the KVM changes, this won't conflict with any of the other changes in this series. So while it's themetatically very related to this series, in practice it can go in separately, and I'd strongly prefer to let the Xen folks handle this one.
