arch/x86/kvm/vmx/evmcs.c | 4 +-- arch/x86/kvm/vmx/evmcs.h | 48 +++++++++++++++++++++++++------ arch/x86/kvm/vmx/nested.c | 59 +++++++++++++++++++++++++++------------ arch/x86/kvm/vmx/vmcs12.c | 4 +-- arch/x86/kvm/vmx/vmcs12.h | 6 ++-- 5 files changed, 87 insertions(+), 34 deletions(-)
Changes since v2 [Sean]:
- Tweak a comment in PATCH5.
- Add Reviewed-by: tags to PATCHes 3 and 5.
Original description:
Windows 11 with enabled Hyper-V role doesn't boot on KVM when Enlightened
VMCS interface is provided to it. The observed behavior doesn't conform to
Hyper-V TLFS. In particular, I'm observing 'VMREAD' instructions trying to
access field 0x4404 ("VM-exit interruption information"). TLFS, however, is
very clear this should not be happening:
"Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
unsupported and can result in unexpected behavior."
Microsoft confirms this is a bug in Hyper-V which is supposed to get fixed
eventually. For the time being, implement a workaround in KVM allowing
VMREAD instructions to read from the currently loaded Enlightened VMCS.
Patches 1-2 are unrelated fixes to VMX feature MSR filtering when eVMCS is
enabled. Patches 3 and 4 are preparatory changes, patch 5 implements the
workaround.
Vitaly Kuznetsov (5):
KVM: nVMX: Also filter MSR_IA32_VMX_TRUE_PINBASED_CTLS when eVMCS
KVM: nVMX: eVMCS: Filter out VM_EXIT_SAVE_VMX_PREEMPTION_TIMER
KVM: nVMX: Rename vmcs_to_field_offset{,_table}
KVM: nVMX: Implement evmcs_field_offset() suitable for handle_vmread()
KVM: nVMX: Allow VMREAD when Enlightened VMCS is in use
arch/x86/kvm/vmx/evmcs.c | 4 +--
arch/x86/kvm/vmx/evmcs.h | 48 +++++++++++++++++++++++++------
arch/x86/kvm/vmx/nested.c | 59 +++++++++++++++++++++++++++------------
arch/x86/kvm/vmx/vmcs12.c | 4 +--
arch/x86/kvm/vmx/vmcs12.h | 6 ++--
5 files changed, 87 insertions(+), 34 deletions(-)
--
2.34.1
Vitaly Kuznetsov <vkuznets@redhat.com> writes:
> Changes since v2 [Sean]:
> - Tweak a comment in PATCH5.
> - Add Reviewed-by: tags to PATCHes 3 and 5.
>
> Original description:
>
> Windows 11 with enabled Hyper-V role doesn't boot on KVM when Enlightened
> VMCS interface is provided to it. The observed behavior doesn't conform to
> Hyper-V TLFS. In particular, I'm observing 'VMREAD' instructions trying to
> access field 0x4404 ("VM-exit interruption information"). TLFS, however, is
> very clear this should not be happening:
>
> "Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
> unsupported and can result in unexpected behavior."
>
> Microsoft confirms this is a bug in Hyper-V which is supposed to get fixed
> eventually. For the time being, implement a workaround in KVM allowing
> VMREAD instructions to read from the currently loaded Enlightened VMCS.
>
> Patches 1-2 are unrelated fixes to VMX feature MSR filtering when eVMCS is
> enabled. Patches 3 and 4 are preparatory changes, patch 5 implements the
> workaround.
>
Paolo,
would it be possible to pick this up for 5.17? Technically, this is a
"fix", even if the bug itself is not in KVM)
--
Vitaly
Vitaly Kuznetsov <vkuznets@redhat.com> writes:
> Vitaly Kuznetsov <vkuznets@redhat.com> writes:
>
>> Changes since v2 [Sean]:
>> - Tweak a comment in PATCH5.
>> - Add Reviewed-by: tags to PATCHes 3 and 5.
>>
>> Original description:
>>
>> Windows 11 with enabled Hyper-V role doesn't boot on KVM when Enlightened
>> VMCS interface is provided to it. The observed behavior doesn't conform to
>> Hyper-V TLFS. In particular, I'm observing 'VMREAD' instructions trying to
>> access field 0x4404 ("VM-exit interruption information"). TLFS, however, is
>> very clear this should not be happening:
>>
>> "Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
>> unsupported and can result in unexpected behavior."
>>
>> Microsoft confirms this is a bug in Hyper-V which is supposed to get fixed
>> eventually. For the time being, implement a workaround in KVM allowing
>> VMREAD instructions to read from the currently loaded Enlightened VMCS.
>>
>> Patches 1-2 are unrelated fixes to VMX feature MSR filtering when eVMCS is
>> enabled. Patches 3 and 4 are preparatory changes, patch 5 implements the
>> workaround.
>>
>
> Paolo,
>
> would it be possible to pick this up for 5.17? Technically, this is a
> "fix", even if the bug itself is not in KVM)
Ping)
--
Vitaly
On 1/18/22 15:22, Vitaly Kuznetsov wrote:
> Vitaly Kuznetsov <vkuznets@redhat.com> writes:
>
>> Changes since v2 [Sean]:
>> - Tweak a comment in PATCH5.
>> - Add Reviewed-by: tags to PATCHes 3 and 5.
>>
>> Original description:
>>
>> Windows 11 with enabled Hyper-V role doesn't boot on KVM when Enlightened
>> VMCS interface is provided to it. The observed behavior doesn't conform to
>> Hyper-V TLFS. In particular, I'm observing 'VMREAD' instructions trying to
>> access field 0x4404 ("VM-exit interruption information"). TLFS, however, is
>> very clear this should not be happening:
>>
>> "Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
>> unsupported and can result in unexpected behavior."
>>
>> Microsoft confirms this is a bug in Hyper-V which is supposed to get fixed
>> eventually. For the time being, implement a workaround in KVM allowing
>> VMREAD instructions to read from the currently loaded Enlightened VMCS.
>>
>> Patches 1-2 are unrelated fixes to VMX feature MSR filtering when eVMCS is
>> enabled. Patches 3 and 4 are preparatory changes, patch 5 implements the
>> workaround.
>>
>
> Paolo,
>
> would it be possible to pick this up for 5.17? Technically, this is a
> "fix", even if the bug itself is not in KVM)
Yes, it is. I have queued the patch, and feel free to send a 5.16
backport too.
Paolo
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 1/18/22 15:22, Vitaly Kuznetsov wrote:
>> Vitaly Kuznetsov <vkuznets@redhat.com> writes:
>>
>>> Changes since v2 [Sean]:
>>> - Tweak a comment in PATCH5.
>>> - Add Reviewed-by: tags to PATCHes 3 and 5.
>>>
>>> Original description:
>>>
>>> Windows 11 with enabled Hyper-V role doesn't boot on KVM when Enlightened
>>> VMCS interface is provided to it. The observed behavior doesn't conform to
>>> Hyper-V TLFS. In particular, I'm observing 'VMREAD' instructions trying to
>>> access field 0x4404 ("VM-exit interruption information"). TLFS, however, is
>>> very clear this should not be happening:
>>>
>>> "Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is
>>> unsupported and can result in unexpected behavior."
>>>
>>> Microsoft confirms this is a bug in Hyper-V which is supposed to get fixed
>>> eventually. For the time being, implement a workaround in KVM allowing
>>> VMREAD instructions to read from the currently loaded Enlightened VMCS.
>>>
>>> Patches 1-2 are unrelated fixes to VMX feature MSR filtering when eVMCS is
>>> enabled. Patches 3 and 4 are preparatory changes, patch 5 implements the
>>> workaround.
>>>
>>
>> Paolo,
>>
>> would it be possible to pick this up for 5.17? Technically, this is a
>> "fix", even if the bug itself is not in KVM)
>
> Yes, it is. I have queued the patch
Thanks!
> and feel free to send a 5.16 backport too.
I see your pull request to Linus, will send the backport when it lands.
In fact, all 5 patches apply to 5.16 without issues but I guess stable@
tooling won't pick them up automatically.
--
Vitaly
On 1/28/22 15:11, Vitaly Kuznetsov wrote: > I see your pull request to Linus, will send the backport when it lands. > In fact, all 5 patches apply to 5.16 without issues but I guess stable@ > tooling won't pick them up automatically. I noticed, but I wasn't sure what the dependencies were among them and whether you'd prefer to only have patches 3-5; so I didn't just add "Cc: stable" myself. Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > On 1/28/22 15:11, Vitaly Kuznetsov wrote: >> I see your pull request to Linus, will send the backport when it lands. >> In fact, all 5 patches apply to 5.16 without issues but I guess stable@ >> tooling won't pick them up automatically. > > I noticed, but I wasn't sure what the dependencies were among them and > whether you'd prefer to only have patches 3-5; so I didn't just add "Cc: > stable" myself. Actually yes, patches 1/2 don't fix any "real" issue (afair) so we can be a bit more conservative with 5.16. -- Vitaly
© 2016 - 2026 Red Hat, Inc.