diff options
| author | Sean Christopherson <seanjc@google.com> | 2021-09-29 15:24:26 -0700 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-09-30 04:27:08 -0400 |
| commit | 25b9784586a41f1fccc4d2cf7f210252b9df149c (patch) | |
| tree | 3d84be6282e401d3c028bdc88080dcc2ba949904 /tools/testing/selftests/kvm/lib/sparsebit.c | |
| parent | 62dd57dd67d74ff5bfdfc28260a35cc4a31babb3 (diff) | |
KVM: x86: Manually retrieve CPUID.0x1 when getting FMS for RESET/INIT
Manually look for a CPUID.0x1 entry instead of bouncing through
kvm_cpuid() when retrieving the Family-Model-Stepping information for
vCPU RESET/INIT. This fixes a potential undefined behavior bug due to
kvm_cpuid() using the uninitialized "dummy" param as the ECX _input_,
a.k.a. the index.
A more minimal fix would be to simply zero "dummy", but the extra work in
kvm_cpuid() is wasteful, and KVM should be treating the FMS retrieval as
an out-of-band access, e.g. same as how KVM computes guest.MAXPHYADDR.
Both Intel's SDM and AMD's APM describe the RDX value at RESET/INIT as
holding the CPU's FMS information, not as holding CPUID.0x1.EAX. KVM's
usage of CPUID entries to get FMS is simply a pragmatic approach to avoid
having yet another way for userspace to provide inconsistent data.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Message-Id: <20210929222426.1855730-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/testing/selftests/kvm/lib/sparsebit.c')
0 files changed, 0 insertions, 0 deletions