>Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> writes: >>Liran Alon <liran.alon@xxxxxxxxxx> writes: >> It seems to me from what you describe that Hyper-V has a bug of using revision_id specified in IA32_VMX_BASIC_MSR >> instead of using one of the eVMCS supported versions reported in CPUID.4000000A. >> >> I’m also not sure I understand what you suggest as “change the other side of KVM to make it’s behaviour match Hyper-V”. >> Do you mean that we will change KVM usage of eVMCS such that >> alloc_vmcs_cpu() will always set vmcs->hdr.revision_id to >> vmcs_config.revision_id? > Yes. My current understanding (correct me if I'm wrong!) is that both > KVM-on-Hyper-V and Hyper-V-on-KVM work well with Enlightened > VMCS. Surprisingly, KVM-on-KVM doesn't - and this is because of the > issue you're trying to address by the patch. Yes you understand correctly. Well, I can change alloc_vmcs_cpu() to always set vmcs->hdr.revison_id to vmcs_config.revision_id even when eVMCS is enabled (which is a deliberate wrong behaviour of KVM eVMCS client code) and also not apply this patch (which remains a deliberate wrong behaviour of KVM eVMCS server code). All of this to overcome Hyper-V wrong behaviour :) Paolo, do you think we should insert this wrong behaviour to KVM to support running on top of buggy Hyper-V? I unfortunately believe we should. If so, should I insert this weird behaviour behind a kvm-intel module parameter? E.g. compact_evmcs_version? -Liran
