diff options
author | Sean Christopherson <seanjc@google.com> | 2024-11-28 04:33:48 +0300 |
---|---|---|
committer | Sean Christopherson <seanjc@google.com> | 2024-12-19 01:19:43 +0300 |
commit | 96cbc766baf05daf5dbcfd17c605d821f10170be (patch) | |
tree | 7be9a20cad8cc6a110e4d98a6a093f5707d90030 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | 6416b0fb1660eb8bb73dc35dd5beb844646cb603 (diff) | |
download | linux-96cbc766baf05daf5dbcfd17c605d821f10170be.tar.xz |
KVM: x86: Account for max supported CPUID leaf when getting raw host CPUID
Explicitly zero out the feature word in kvm_cpu_caps if the word's
associated CPUID function is greater than the max leaf supported by the
CPU. For such unsupported functions, Intel CPUs return the output from
the last supported leaf, not all zeros.
Practically speaking, this is likely a benign bug, as KVM uses the raw
host CPUID to mask the kernel's computed capabilities, and the kernel does
perform max leaf checks when populating boot_cpu_data. The only way KVM's
goof could be problematic is if the kernel force-set a feature in a leaf
that is completely unsupported, _and_ the max supported leaf happened to
return a value with '1' the same bit position. Which is theoretically
possible, but extremely unlikely. And even if that did happen, it's
entirely possible that KVM would still provide the correct functionality;
the kernel did set the capability after all.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-22-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions