diff options
| author | Sean Christopherson <seanjc@google.com> | 2026-09-30 10:36:16 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-09-30 14:23:45 -0700 |
| commit | 967e40fb1b08110e5528d19fc96b4b5410e53109 (patch) | |
| tree | d7a44510fa576dbd832933d04250d80a8fd3f7b8 /tools/perf/scripts/python | |
| parent | b701a8139fd6d51462a5dcac79c92c3ff6524f6c (diff) | |
KVM: SVM: Fallback to the default TSC ratio if KVM tries to use a bad multiplier
Explicitly WARN and fallback to the default TSC ratio, i.e. run the guest
at L0's TSC frequency, if KVM tries to program a bad multiplier value. As
pointed out by Sashiko, leaving the MSR as-is bleeds state from the vCPU
that last ran on the pCPU into the likely-misbehaving current vCPU.
Leaking a vCPU's frequency isn't very interesting, and corrupting KVM's
cache isn't a big deal either since KVM would only refuse to try to write
the same bad value in the future, but falling back to the default value is
trivial, and explicitly WARNing ensures a KVM bug won't slip by silently.
E.g. because ex_handler_msr() only WARNs once for *all* WRMSRs, it's
possible for the potentially-fatal-to-the-guest issue to not exhibit any
visible symptoms in the host.
Reported-by: Sashiko Bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260722091414.E842B1F000E9@smtp.kernel.org
Link: https://patch.msgid.link/20260930173635.3362655-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
