[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <75DA0FC8-A77C-47EE-BADB-309E90CC58AA@nutanix.com>
Date: Tue, 23 Dec 2025 04:16:02 +0000
From: Jon Kohler <jon@...anix.com>
To: Jon Kohler <jon@...anix.com>
CC: Sean Christopherson <seanjc@...gle.com>,
"pbonzini@...hat.com"
<pbonzini@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org"
<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"kvm@...r.kernel.org"
<kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [RFC PATCH 17/18] KVM: VMX: Allow MBEC with EVMCS
> On May 12, 2025, at 10:01 PM, Jon Kohler <jon@...anix.com> wrote:
>
>> On May 12, 2025, at 5:35 PM, Sean Christopherson <seanjc@...gle.com> wrote:
>>
>> On Thu, Mar 13, 2025, Jon Kohler wrote:
>>> Extend EVMCS1_SUPPORTED_2NDEXEC to understand MBEC enablement,
>>> otherwise presenting both EVMCS and MBEC at the same time will disable
>>> MBEC presentation into the guest.
>>
>> A brief rundown on any relevant history of eVMCS support for MBEC would be
>> appreciated, if there is any.
>
> There isn’t any, but the broader theme of “make the commit/short log better” will
> tidy this up, as I spent quite a lot of time on this eVMCS area trying to wrap my
> head around that, I’ll codify that knowledge in the commit log
I’ve simplified this patch in the V1 series and expanded the commit log a pinch,
and focused the log on the real use case here, which is making VM administration
easy, so that admins (and/or VMMs) can expose both MBEC and EVMCS, and Windows
will just “do the right thing” for performance, which is consuming MBEC when
HVCI is enabled, and EVMCS when HVCI is not enabled.
>
>>
>>> Signed-off-by: Jon Kohler <jon@...anix.com>
>>>
>>> ---
>>> arch/x86/kvm/vmx/hyperv.c | 5 ++++-
>>> arch/x86/kvm/vmx/hyperv_evmcs.h | 1 +
>>> 2 files changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/kvm/vmx/hyperv.c b/arch/x86/kvm/vmx/hyperv.c
>>> index fab6a1ad98dc..941a29c9e667 100644
>>> --- a/arch/x86/kvm/vmx/hyperv.c
>>> +++ b/arch/x86/kvm/vmx/hyperv.c
>>> @@ -138,7 +138,10 @@ void nested_evmcs_filter_control_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *
>>> ctl_high &= evmcs_get_supported_ctls(EVMCS_EXEC_CTRL);
>>> break;
>>> case MSR_IA32_VMX_PROCBASED_CTLS2:
>>> - ctl_high &= evmcs_get_supported_ctls(EVMCS_2NDEXEC);
>>> + supported_ctrls = evmcs_get_supported_ctls(EVMCS_2NDEXEC);
>>> + if (!vcpu->arch.pt_guest_exec_control)
>>> + supported_ctrls &= ~SECONDARY_EXEC_MODE_BASED_EPT_EXEC;
>>
>> No idea what you're trying to do, but I don't see how this is necessary in any
>> capacity.
>
> The eVMCS code has this logic to be able to “peel back” changes based
> on runtime level enablement. I think with the broader changes to the series
> suggested (moving control out of vcpu structure here), then this goes away.
>
> I’ll seek to simplify this.
Yea I got rid of this shenanigans.
>
>>
>>> + ctl_high &= supported_ctrls;
>>> break;
>>> case MSR_IA32_VMX_TRUE_PINBASED_CTLS:
>>> case MSR_IA32_VMX_PINBASED_CTLS:
>>> diff --git a/arch/x86/kvm/vmx/hyperv_evmcs.h b/arch/x86/kvm/vmx/hyperv_evmcs.h
>>> index a543fccfc574..930429f376f9 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)
>>> --
>>> 2.43.0
>>>
>
Powered by blists - more mailing lists