With fine grained VMX feature enablement QEMU>=4.2 tries to do KVM_SET_MSRS with default (matching CPU model) values and in case eVMCS is also enabled, fails. While the regression is in QEMU, it may still be preferable to fix this in KVM. It would be great if we could just omit the VMX feature filtering in KVM and make this guest's responsibility: if it switches to using enlightened vmcs it should be aware that not all hardware features are going to be supported. Genuine Hyper-V, however, fails the test. It, for example, enables SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES and without 'apic_access_addr' field in eVMCS there's not much we can do in KVM. Microsoft confirms the bug but it is unclear if it will ever get fixed in the existing Hyper-V versions as genuine Hyper-V never exposes these unsupported controls to L1. Changes since 'RFC': - Go with the bare minimum [Paolo] KVM RFC: https://lore.kernel.org/kvm/20200115171014.56405-1-vkuznets@xxxxxxxxxx/ QEMU RFC@: https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg00123.html Vitaly Kuznetsov (3): x86/kvm/hyper-v: remove stale evmcs_already_enabled check from nested_enable_evmcs() x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs() x86/kvm/hyper-v: don't allow to turn on unsupported VMX controls for nested guests arch/x86/kvm/vmx/evmcs.c | 90 ++++++++++++++++++++++++++++++++++----- arch/x86/kvm/vmx/evmcs.h | 3 ++ arch/x86/kvm/vmx/nested.c | 3 ++ arch/x86/kvm/vmx/vmx.c | 16 ++++++- 4 files changed, 99 insertions(+), 13 deletions(-) -- 2.24.1
