Re: [PATCH RFC] i386/kvm: fix enlightened VMCS with fine-grained VMX feature enablement

[Vitaly Kuznetsov <vkuznets@redhat.com>]

Paolo Bonzini <pbonzini@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 <vkuznets@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