Paolo Bonzini <pbonz...@redhat.com> writes: > On 02/01/20 21:39, Vitaly Kuznetsov wrote: >> When enlightened VMCS is enabled, certain VMX controls disappear, e.g. >> posted interrupts for PINBASED_CTLS. With fine-grained VMX feature >> enablement QEMU tries to do KVM_SET_MSRS with default (matching CPU >> model) values and fails as KVM doesn't allow to set now-unsupported >> controls. >> >> The ideal solution for the issue would probably be to re-read VMX >> feature MSRs after enabling KVM_CAP_HYPERV_ENLIGHTENED_VMCS, however, >> this doesn't seem to be possible: currently, KVM returns global >> &vmcs_config.nested values for VMX MSRs when userspace does KVM_GET_MSR. >> >> It is also possible to modify KVM to apply 'evmcs filtering' to VMX >> MSRs when userspace tries to set them and hide the issue but this doesn't >> seem to be entirely correct. >> >> It is unfortunate that we now need to support the list of VMX features >> disabled by enlightened VMCS in QEMU. When (and if) enlightened VMCS v2 >> arrives we'll need to fix QEMU and allow previously disabled features. >> >> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> >> --- >> - I don't quite like this workaround myself, thus RFC. I'm sure someone >> will suggest a better alternative. > > The patch itself is not a big deal, the only thing is that we should > probably check that we get warnings if the "forbidden" features are > explicitly requested by the user. On the other hand, for something like > "-cpu Haswell,vmx,hv_evmcs" there should be no warnings. > > That said, I'm not sure about the whole idea of disabling features, even > in the kernel. I would prefer if the guest knew that it cannot use > these features if using eVMCS. Is this the case for Windows?
Honestly I forgot the story why we filtered out these features upon eVMCS enablement in KVM. As there are no corresponding eVMCS fields, there's no way a guest can actually use them. I'm going to check that nothing breaks if we remove the filter. I'll go and test Hyper-V 2016 and 2019. > If so, we should teach guest-side KVM about this, not QEMU. This is not required when enabling eVMCS on a genuine Hyper-V because it correctly filters out unsupported features, however, to not break KVM-on-KVM-using-eVMCS case we'll have to move the filter from host to guest. Thanks! -- Vitaly
