Re: [PATCH v5 2/2] KVM: VMX: Cap VMX preemption timer to work around Intel erratum

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 28, 2026, Jim Mattson wrote:
> On Tue, Jul 28, 2026 at 8:03 AM Sean Christopherson <seanjc@google.com> wrote:
> > > +
> > > +     cpuid(0x15, &eax, &ebx, &ecx, &edx);
> > > +     if (!eax || !ebx)
> > > +             return 1ULL << 32;
> > > +
> > > +     return min_t(u64, 1ULL << 32, ((u64)ebx << 25) / eax);
> >
> > While I appreciate Sashiko's paranoia about "((u64)ebx << 25) / eax)" yielding
> > zero, I think we should treat that as a WARNable offence.  And to avoid a false
> > positive due to running as a VM of a misconfigured hypervisor, I think we should
> > only apply the erratum workaround on bare metal, i.e. use the maximum value if
> > KVM detects X86_FEATURE_HYPERVISOR.
> 
> That's fair. We always emulate the VMCS12 VMX preemption timer with an
> hr_timer,  right?

Yep.  And even if KVM (or any hypervisor) as L0 used the hardware VMX timer to
emulate vmcs12's timer, it would be L0's responsibility to deal with the erratum.

Checking CPUID when running as a VM isn't obviously flawed right now, because
there's nothing that enumerates the erratum or its fix, but I'm guessing we'll
end up with FMS-based detection of the bug, at which point we'll run into the
typical issues with trying to do FMS matching when running as a VM.