diff options
author | Vitaly Kuznetsov <vkuznets@redhat.com> | 2021-09-07 19:35:30 +0300 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-09-22 17:33:15 +0300 |
commit | 8d68bad6d869fae8f4d50ab6423538dec7da72d1 (patch) | |
tree | cbb4a83c8f6c028192481b4f86d1ef9365280867 /net/unix/unix_bpf.c | |
parent | 0bbc2ca8515f9cdf11df84ccb63dc7c44bc3d8f4 (diff) | |
download | linux-8d68bad6d869fae8f4d50ab6423538dec7da72d1.tar.xz |
KVM: nVMX: Filter out all unsupported controls when eVMCS was activated
Windows Server 2022 with Hyper-V role enabled failed to boot on KVM when
enlightened VMCS is advertised. Debugging revealed there are two exposed
secondary controls it is not happy with: SECONDARY_EXEC_ENABLE_VMFUNC and
SECONDARY_EXEC_SHADOW_VMCS. These controls are known to be unsupported,
as there are no corresponding fields in eVMCSv1 (see the comment above
EVMCS1_UNSUPPORTED_2NDEXEC definition).
Previously, commit 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls
sanitization out of nested_enable_evmcs()") introduced the required
filtering mechanism for VMX MSRs but for some reason put only known
to be problematic (and not full EVMCS1_UNSUPPORTED_* lists) controls
there.
Note, Windows Server 2022 seems to have gained some sanity check for VMX
MSRs: it doesn't even try to launch a guest when there's something it
doesn't like, nested_evmcs_check_controls() mechanism can't catch the
problem.
Let's be bold this time and instead of playing whack-a-mole just filter out
all unsupported controls from VMX MSRs.
Fixes: 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs()")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210907163530.110066-1-vkuznets@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'net/unix/unix_bpf.c')
0 files changed, 0 insertions, 0 deletions