summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/amd/ni65.c
diff options
context:
space:
mode:
authorJim Mattson <jmattson@google.com>2022-02-04 03:13:48 +0300
committerPaolo Bonzini <pbonzini@redhat.com>2022-02-04 11:06:55 +0300
commite3bcfda012edd3564e12551b212afbd2521a1f68 (patch)
tree7d8373e9f4b937c1e89ebc49096f100e62ac803f /drivers/net/ethernet/amd/ni65.c
parentcb4f0843429e38431023c26ca7cdaee447953cbd (diff)
downloadlinux-e3bcfda012edd3564e12551b212afbd2521a1f68.tar.xz
KVM: x86: Report deprecated x87 features in supported CPUID
CPUID.(EAX=7,ECX=0):EBX.FDP_EXCPTN_ONLY[bit 6] and CPUID.(EAX=7,ECX=0):EBX.ZERO_FCS_FDS[bit 13] are "defeature" bits. Unlike most of the other CPUID feature bits, these bits are clear if the features are present and set if the features are not present. These bits should be reported in KVM_GET_SUPPORTED_CPUID, because if these bits are set on hardware, they cannot be cleared in the guest CPUID. Doing so would claim guest support for a feature that the hardware doesn't support and that can't be efficiently emulated. Of course, any software (e.g WIN87EM.DLL) expecting these features to be present likely predates these CPUID feature bits and therefore doesn't know to check for them anyway. Aaron Lewis added the corresponding X86_FEATURE macros in commit cbb99c0f5887 ("x86/cpufeatures: Add FDP_EXCPTN_ONLY and ZERO_FCS_FDS"), with the intention of reporting these bits in KVM_GET_SUPPORTED_CPUID, but I was unable to find a proposed patch on the kvm list. Opportunistically reordered the CPUID_7_0_EBX capability bits from least to most significant. Cc: Aaron Lewis <aaronlewis@google.com> Signed-off-by: Jim Mattson <jmattson@google.com> Message-Id: <20220204001348.2844660-1-jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'drivers/net/ethernet/amd/ni65.c')
0 files changed, 0 insertions, 0 deletions