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

On Wed, Jul 29, 2026, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 7d2cc36a04e51..67c8dc1eb2c4f 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> 
> [ ... ]
> 
> > @@ -8305,6 +8306,33 @@ static inline int u64_shl_div_u64(u64 a, unsigned int shift,
> >  	return 0;
> >  }
> >  
> > +/*
> > + * Workaround for a widespread Intel erratum (e.g. EMR158) where the
> > + * VMX-preemption timer may expire earlier than expected when programmed
> > + * with large values. The workaround is to cap the timer value to strictly
> > + * less than 2^25 * CPUID.15H:EBX / CPUID.15H:EAX.
> > + */
> > +static __init u64 calc_preemption_timer_max_value(void)
> > +{
> > +	const u64 ARCHITECTURAL_MAX_VALUE = UINT_MAX;
> > +	u32 eax, ebx, ecx, edx;
> 
> [ ... ]
> 
> > +	if (WARN_ON_ONCE(!(((u64)ebx << 25) / eax)))
> > +		return ARCHITECTURAL_MAX_VALUE;
> > +
> > +	return (((u64)ebx << 25) / eax) - 1;
> 
> [Severity: High]
> If a CPU has a high TSC-to-crystal clock ratio (for example, EBX/EAX >= 128),
> could this calculation exceed UINT_MAX? Because the returned u64 is not clamped
> to ARCHITECTURAL_MAX_VALUE, preemption_timer_max_value could end up storing a
> value larger than 32 bits.

/facepalm

I completely misread this:

	return min_t(u64, 1ULL << 32, ((u64)ebx << 25) / eax);

as max_t.  I'll add it back...