KVM: x86: Saturate L2's TSC frequency if it exceeds hardware supports

When computing the TSC multiplier for L2, use the minimum/maximum frequency
supported by hardware if the resulting multiplier can't be programmed into
hardware, i.e. saturate L2's frequency on both sides.  This can happen if
userspace is running L1 at a low/high frequency relative to L0, and L1 is
doing the same for L2 (relative to L1), because although each of the L1 and
L2 inputs are constrained and validated, the end result can exceed SVM's
and VMX's architectural limits.

Don't bother trying to log an error or do something more sophisticated,
because in practice only a misbehaving L1 (and/or host userspace) will run
afoul of the flaw.  On SVM, which has the smallest "range" by far (8 bits
for the integer multiplier, versus 16 bits on VMX), KVM can still run L2
with a frequency 255x that of L0.  Even assuming a pessimistic L0 TSC
frequency of 1GHz (modern CPUs run TSC at 2GHz+), L2 would need to be
running at a whopping ~255GHz for the limitation to be a problem.  Not to
mention that if L2 is running at a legitimate frequency, then running that
VM on existing hardware is already doomed irrespective of the nested angle.

Open code the mul_u64_u64_shr() if the compiler natively supports 128-bit
integers, mostly to avoid having to do the multiply twice for what should
be a very rare scenario, but also so that there's a slightly more scrutable
sequence that can be read to understand what all is going on.

Signed-off-by: Amirmohammad Eftekhar <amirmohammad.eftekhar@cispa.de>
[sean: optimize for INT128, rewrite comment+changelog to be less AI]
Link: https://patch.msgid.link/20260930173635.3362655-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>

0 files changed, 0 insertions, 0 deletions