From: mlevitsk@redhat.com
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: d.riley@proxmox.com, jon@nutanix.com,
Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH 20/28] KVM: nVMX: allow MBEC with EVMCS
Date: Tue, 02 Jun 2026 10:28:46 -0400 [thread overview]
Message-ID: <9176c891af8dc496f02c1e8cbef53976576ae7e1.camel@redhat.com> (raw)
In-Reply-To: <20260505195226.563317-21-pbonzini@redhat.com>
On Tue, 2026-05-05 at 21:52 +0200, Paolo Bonzini wrote:
> From: Jon Kohler <jon@nutanix.com>
>
> Extend EVMCS1_SUPPORTED_2NDEXEC to allow MBEC and EVMCS to coexist.
> Presenting both EVMCS and MBEC simultaneously causes KVM to filter out
> MBEC and not present it as a supported control to the guest, preventing
> performance gains from MBEC when Windows HVCI is enabled.
>
> The guest may choose not to use MBEC (e.g., if the admin does not enable
> Windows HVCI / Memory Integrity), but if they use traditional nested
> virt (Hyper-V, WSL2, etc.), having EVMCS exposed is important for
> improving nested guest performance. IOW allowing MBEC and EVMCS to
> coexist provides maximum optionality to Windows users without
> overcomplicating VM administration.
>
> Signed-off-by: Jon Kohler <jon@nutanix.com>
> Message-ID: <20251223054806.1611168-8-jon@nutanix.com>
> Tested-by: David Riley <d.riley@proxmox.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/x86/kvm/vmx/hyperv_evmcs.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kvm/vmx/hyperv_evmcs.h b/arch/x86/kvm/vmx/hyperv_evmcs.h
> index fc7c4e7bd1bf..bc08fe40590e 100644
> --- a/arch/x86/kvm/vmx/hyperv_evmcs.h
> +++ b/arch/x86/kvm/vmx/hyperv_evmcs.h
> @@ -87,6 +87,7 @@
> SECONDARY_EXEC_PT_CONCEAL_VMX | \
> SECONDARY_EXEC_BUS_LOCK_DETECTION | \
> SECONDARY_EXEC_NOTIFY_VM_EXITING | \
> + SECONDARY_EXEC_MODE_BASED_EPT_EXEC | \
> SECONDARY_EXEC_ENCLS_EXITING)
>
> #define EVMCS1_SUPPORTED_3RDEXEC (0ULL)
Unrelated to this patch:
I haven't paid much attention to this particular area of KVM, but 'EVMCSv1_LEGACY' caught my attention now.
According to the Hypervisor Top Level Function Specificaiton v5.0C and v6.0b that I have, there is only one version defined,
version 1.
Is there a reason on why we choose to call it "Legacy"?
Also I see:
Enlightened VMCSv1 doesn't support these:
....
* TSC_MULTIPLIER = 0x00002032,
And yet I see it defined:
EVMCS1_FIELD(TSC_MULTIPLIER, tsc_multiplier,
HV_VMX_ENLIGHTENED_CLEAN_FIELD_CONTROL_GRP2),
Anyway I haven't found any restrictions on the execution controls in the EVMCS in the Microsoft's spec,
so it is unlikely that it is not supported.
So:
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2026-06-02 14:28 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 19:51 [PATCH v6 00/28] KVM: combined patchset for MBEC/GMET support Paolo Bonzini
2026-05-05 19:51 ` [PATCH 01/28] KVM: TDX/VMX: rework EPT_VIOLATION_EXEC_FOR_RING3_LIN into PROT_MASK Paolo Bonzini
2026-06-02 14:19 ` mlevitsk
2026-05-05 19:52 ` [PATCH 02/28] KVM: x86/mmu: remove SPTE_PERM_MASK Paolo Bonzini
2026-06-02 14:20 ` mlevitsk
2026-05-05 19:52 ` [PATCH 03/28] KVM: x86/mmu: free up bit 10 of PTEs in preparation for MBEC Paolo Bonzini
2026-06-02 14:20 ` mlevitsk
2026-05-05 19:52 ` [PATCH 04/28] KVM: x86/mmu: shuffle high bits of SPTEs " Paolo Bonzini
2026-06-02 14:20 ` mlevitsk
2026-05-05 19:52 ` [PATCH 05/28] KVM: x86/mmu: remove SPTE_EPT_* Paolo Bonzini
2026-06-02 14:21 ` mlevitsk
2026-05-05 19:52 ` [PATCH 06/28] KVM: x86/mmu: merge make_spte_{non,}executable Paolo Bonzini
2026-06-02 14:22 ` mlevitsk
2026-05-05 19:52 ` [PATCH 07/28] KVM: x86/mmu: rename and clarify BYTE_MASK Paolo Bonzini
2026-06-02 14:22 ` mlevitsk
2026-05-05 19:52 ` [PATCH 08/28] KVM: x86/mmu: separate more EPT/non-EPT permission_fault() Paolo Bonzini
2026-05-07 14:35 ` Sean Christopherson
2026-06-02 14:22 ` mlevitsk
2026-05-05 19:52 ` [PATCH 09/28] KVM: x86/mmu: introduce ACC_READ_MASK Paolo Bonzini
2026-06-02 14:23 ` mlevitsk
2026-05-05 19:52 ` [PATCH 10/28] KVM: x86/mmu: pass PFERR_GUEST_PAGE/FINAL_MASK to kvm_translate_gpa Paolo Bonzini
2026-06-02 14:23 ` mlevitsk
2026-05-05 19:52 ` [PATCH 11/28] KVM: x86/mmu: pass pte_access for final nGPA->GPA walk Paolo Bonzini
2026-06-02 14:24 ` mlevitsk
2026-05-05 19:52 ` [PATCH 12/28] KVM: x86: make translate_nested_gpa vendor-specific Paolo Bonzini
2026-06-02 14:24 ` mlevitsk
2026-05-05 19:52 ` [PATCH 13/28] KVM: x86/mmu: split XS/XU bits for EPT Paolo Bonzini
2026-06-02 14:24 ` mlevitsk
2026-05-05 19:52 ` [PATCH 14/28] KVM: x86/mmu: move cr4_smep to base role Paolo Bonzini
2026-06-02 14:25 ` mlevitsk
2026-05-05 19:52 ` [PATCH 15/28] KVM: VMX: enable use of MBEC Paolo Bonzini
2026-05-07 14:40 ` Sean Christopherson
2026-06-02 14:26 ` mlevitsk
2026-05-05 19:52 ` [PATCH 16/28] KVM: nVMX: pass advanced EPT violation vmexit info to guest Paolo Bonzini
2026-06-02 14:26 ` mlevitsk
2026-05-05 19:52 ` [PATCH 17/28] KVM: nVMX: pass PFERR_USER_MASK to MMU on EPT violations Paolo Bonzini
2026-06-02 14:27 ` mlevitsk
2026-05-05 19:52 ` [PATCH 18/28] KVM: x86/mmu: add support for MBEC to EPT page table walks Paolo Bonzini
2026-06-02 14:28 ` mlevitsk
2026-05-05 19:52 ` [PATCH 19/28] KVM: nVMX: advertise MBEC to nested guests Paolo Bonzini
2026-06-02 14:28 ` mlevitsk
2026-05-05 19:52 ` [PATCH 20/28] KVM: nVMX: allow MBEC with EVMCS Paolo Bonzini
2026-06-02 14:28 ` mlevitsk [this message]
2026-06-02 15:29 ` Vitaly Kuznetsov
2026-05-05 19:52 ` [PATCH 21/28] KVM: x86/mmu: propagate access mask from root pages down Paolo Bonzini
2026-06-02 14:29 ` mlevitsk
2026-05-05 19:52 ` [PATCH 22/28] KVM: x86/mmu: introduce cpu_role bit for availability of PFEC.I/D Paolo Bonzini
2026-06-02 14:29 ` mlevitsk
2026-05-05 19:52 ` [PATCH 23/28] KVM: SVM: add GMET bit definitions Paolo Bonzini
2026-06-02 14:30 ` mlevitsk
2026-05-05 19:52 ` [PATCH 24/28] KVM: x86/mmu: hard code more bits in kvm_init_shadow_npt_mmu Paolo Bonzini
2026-06-02 14:30 ` mlevitsk
2026-05-05 19:52 ` [PATCH 25/28] KVM: x86/mmu: add support for GMET to NPT page table walks Paolo Bonzini
2026-06-02 14:31 ` mlevitsk
2026-05-05 19:52 ` [PATCH 26/28] KVM: SVM: enable GMET and set it in MMU role Paolo Bonzini
2026-06-02 14:31 ` mlevitsk
2026-05-05 19:52 ` [PATCH 27/28] KVM: SVM: work around errata 1218 Paolo Bonzini
2026-06-02 14:31 ` mlevitsk
2026-05-05 19:52 ` [PATCH 28/28] KVM: nSVM: enable GMET for guests Paolo Bonzini
2026-06-02 14:32 ` mlevitsk
2026-05-07 14:44 ` [PATCH v6 00/28] KVM: combined patchset for MBEC/GMET support Sean Christopherson
2026-05-07 17:49 ` Paolo Bonzini
2026-05-11 10:53 ` David Riley
2026-05-11 10:55 ` Paolo Bonzini
2026-05-11 11:07 ` David Riley
2026-05-14 2:11 ` Chao Gao
2026-05-14 19:13 ` Sean Christopherson
2026-05-12 14:32 ` Paolo Bonzini
2026-05-12 16:34 ` Paolo Bonzini
2026-05-15 14:53 ` David Riley
2026-05-15 18:31 ` Sean Christopherson
2026-05-19 8:02 ` David Riley
2026-08-05 12:35 ` Jonas Theisen
-- strict thread matches above, loose matches on Subject: below --
2026-04-30 15:07 [PATCH v5 " Paolo Bonzini
2026-04-30 15:07 ` [PATCH 20/28] KVM: nVMX: allow MBEC with EVMCS Paolo Bonzini
2026-04-28 11:09 [PATCH v4 00/28] KVM: combined patchset for MBEC/GMET support Paolo Bonzini
2026-04-28 11:09 ` [PATCH 20/28] KVM: nVMX: allow MBEC with EVMCS Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9176c891af8dc496f02c1e8cbef53976576ae7e1.camel@redhat.com \
--to=mlevitsk@redhat.com \
--cc=d.riley@proxmox.com \
--cc=jon@nutanix.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®