Add 'enable_pt_guest_exec_control' module parameter to x86 code, with
default value false. This parameter will control enablement for
exposing Intel Mode Based Execution Control (aka MBEC).

Place parameter in x86 common code as, notionally, AMD has a similar
feature called Guest Mode Execute Trap (GMET), which may want to build
off of this parameter in the future, similar to how 'enable_apicv' is
shared across both Intel APICv and AMD AVIC.

Signed-off-by: Jon Kohler <jon@nutanix.com>

---
 arch/x86/include/asm/kvm_host.h | 1 +
 arch/x86/kvm/x86.c              | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7cf2025a64a0..fd37dad38670 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1883,6 +1883,7 @@ struct kvm_arch_async_pf {
 extern u32 __read_mostly kvm_nr_uret_msrs;
 extern bool __read_mostly allow_smaller_maxphyaddr;
 extern bool __read_mostly enable_apicv;
+extern bool __read_mostly enable_pt_guest_exec_control;
 extern struct kvm_x86_ops kvm_x86_ops;
 
 #define kvm_x86_call(func) static_call(kvm_x86_##func)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7bae9e9cc14e..4b2fbb9088ea 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -197,6 +197,10 @@ module_param(eager_page_split, bool, 0644);
 static bool __read_mostly mitigate_smt_rsb;
 module_param(mitigate_smt_rsb, bool, 0444);
 
+bool __read_mostly enable_pt_guest_exec_control;
+EXPORT_SYMBOL_GPL(enable_pt_guest_exec_control);
+module_param(enable_pt_guest_exec_control, bool, 0444);
+
 /*
  * Restoring the host value for MSRs that are only consumed when running in
  * usermode, e.g. SYSCALL MSRs and TSC_AUX, can be deferred until the CPU
-- 
2.43.0

On Thu, Mar 13, 2025, Jon Kohler wrote:
> Add 'enable_pt_guest_exec_control' module parameter to x86 code, with
> default value false.

...

> +bool __read_mostly enable_pt_guest_exec_control;
> +EXPORT_SYMBOL_GPL(enable_pt_guest_exec_control);
> +module_param(enable_pt_guest_exec_control, bool, 0444);

The default value of a parameter doesn't prevent userspace from enabled the param.
I.e. the instant this patch lands, userspace can enable enable_pt_guest_exec_control,
which means MBEC needs to be 100% functional before this can be exposed to userspace.

The right way to do this is to simply omit the module param until KVM is ready to
let userspace enable the feature.

All that said, I don't see any reason to add a module param for this.  *KVM* isn't
using MBEC, the guest is using MBEC.  And unless host userspace is being extremely
careless with VMX MSRs, exposing MBEC to the guest will require additional VMM
enabling and/or user opt-in.

KVM provides module params to control features that KVM is using, generally when
there is no sane alternative to tell KVM not to use a particular feature, i.e.
when there is way for the user to disable a feature for testing/debug purposes.

Furthermore, how this series keys off the module param throughout KVM is completely
wrong.  The *only* input that ultimately matters is the control bit in vmcs12.
Whether or not KVM allows that bit to be set could be controlled by a module param,
but KVM shouldn't be looking at the module param outside of that particular check.

TL;DR: advertising and enabling MBEC should come along when KVM allows the bit to
       be set in vmcs12.

> On May 12, 2025, at 2:08 PM, Sean Christopherson <seanjc@google.com> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> On Thu, Mar 13, 2025, Jon Kohler wrote:
>> Add 'enable_pt_guest_exec_control' module parameter to x86 code, with
>> default value false.
> 
> ...
> 
>> +bool __read_mostly enable_pt_guest_exec_control;
>> +EXPORT_SYMBOL_GPL(enable_pt_guest_exec_control);
>> +module_param(enable_pt_guest_exec_control, bool, 0444);
> 
> The default value of a parameter doesn't prevent userspace from enabled the param.
> I.e. the instant this patch lands, userspace can enable enable_pt_guest_exec_control,
> which means MBEC needs to be 100% functional before this can be exposed to userspace.
> 
> The right way to do this is to simply omit the module param until KVM is ready to
> let userspace enable the feature.
> 
> All that said, I don't see any reason to add a module param for this.  *KVM* isn't
> using MBEC, the guest is using MBEC.  And unless host userspace is being extremely
> careless with VMX MSRs, exposing MBEC to the guest will require additional VMM
> enabling and/or user opt-in.
> 
> KVM provides module params to control features that KVM is using, generally when
> there is no sane alternative to tell KVM not to use a particular feature, i.e.
> when there is way for the user to disable a feature for testing/debug purposes.
> 
> Furthermore, how this series keys off the module param throughout KVM is completely
> wrong.  The *only* input that ultimately matters is the control bit in vmcs12.
> Whether or not KVM allows that bit to be set could be controlled by a module param,
> but KVM shouldn't be looking at the module param outside of that particular check.
> 
> TL;DR: advertising and enabling MBEC should come along when KVM allows the bit to
>       be set in vmcs12.

Gotcha, and I think this fact alone will drive a nice bit of cleanup thru
the entire series. Will mop it up

> On May 12, 2025, at 10:18 PM, Jon Kohler <jon@nutanix.com> wrote:
> 
>> On May 12, 2025, at 2:08 PM, Sean Christopherson <seanjc@google.com> wrote:
>> 
>> On Thu, Mar 13, 2025, Jon Kohler wrote:
>>> Add 'enable_pt_guest_exec_control' module parameter to x86 code, with
>>> default value false.
>> 
>> ...
>> 
>>> +bool __read_mostly enable_pt_guest_exec_control;
>>> +EXPORT_SYMBOL_GPL(enable_pt_guest_exec_control);
>>> +module_param(enable_pt_guest_exec_control, bool, 0444);
>> 
>> The default value of a parameter doesn't prevent userspace from enabled the param.
>> I.e. the instant this patch lands, userspace can enable enable_pt_guest_exec_control,
>> which means MBEC needs to be 100% functional before this can be exposed to userspace.
>> 
>> The right way to do this is to simply omit the module param until KVM is ready to
>> let userspace enable the feature.
>> 
>> All that said, I don't see any reason to add a module param for this.  *KVM* isn't
>> using MBEC, the guest is using MBEC.  And unless host userspace is being extremely
>> careless with VMX MSRs, exposing MBEC to the guest will require additional VMM
>> enabling and/or user opt-in.
>> 
>> KVM provides module params to control features that KVM is using, generally when
>> there is no sane alternative to tell KVM not to use a particular feature, i.e.
>> when there is way for the user to disable a feature for testing/debug purposes.
>> 
>> Furthermore, how this series keys off the module param throughout KVM is completely
>> wrong.  The *only* input that ultimately matters is the control bit in vmcs12.
>> Whether or not KVM allows that bit to be set could be controlled by a module param,
>> but KVM shouldn't be looking at the module param outside of that particular check.
>> 
>> TL;DR: advertising and enabling MBEC should come along when KVM allows the bit to
>>      be set in vmcs12.
> 
> Gotcha, and I think this fact alone will drive a nice bit of cleanup thru
> the entire series. Will mop it up

Ack/done - all of this is cleaned up in favor of the nested.c based enablement

On Tue, 2025-05-13 at 02:18 +0000, Jon Kohler wrote:
> 
> 
> > On May 12, 2025, at 2:08 PM, Sean Christopherson
> > <seanjc@google.com> wrote:
> > 
> > !------------------------------------------------------------------
> > -|
> >  CAUTION: External Email
> > 
> > > -----------------------------------------------------------------
> > > --!
> > 
> > On Thu, Mar 13, 2025, Jon Kohler wrote:
> > > Add 'enable_pt_guest_exec_control' module parameter to x86 code,
> > > with
> > > default value false.
> > 
> > ...
> > 
> > > +bool __read_mostly enable_pt_guest_exec_control;
> > > +EXPORT_SYMBOL_GPL(enable_pt_guest_exec_control);
> > > +module_param(enable_pt_guest_exec_control, bool, 0444);
> > 
> > The default value of a parameter doesn't prevent userspace from
> > enabled the param.
> > I.e. the instant this patch lands, userspace can enable
> > enable_pt_guest_exec_control,
> > which means MBEC needs to be 100% functional before this can be
> > exposed to userspace.
> > 
> > The right way to do this is to simply omit the module param until
> > KVM is ready to
> > let userspace enable the feature.
> > 
> > All that said, I don't see any reason to add a module param for
> > this.  *KVM* isn't
> > using MBEC, the guest is using MBEC.  And unless host userspace is
> > being extremely
> > careless with VMX MSRs, exposing MBEC to the guest will require
> > additional VMM
> > enabling and/or user opt-in.
> > 
> > KVM provides module params to control features that KVM is using,
> > generally when
> > there is no sane alternative to tell KVM not to use a particular
> > feature, i.e.
> > when there is way for the user to disable a feature for
> > testing/debug purposes.
> > 
> > Furthermore, how this series keys off the module param throughout
> > KVM is completely
> > wrong.  The *only* input that ultimately matters is the control bit
> > in vmcs12.
> > Whether or not KVM allows that bit to be set could be controlled by
> > a module param,
> > but KVM shouldn't be looking at the module param outside of that
> > particular check.
> > 
> > TL;DR: advertising and enabling MBEC should come along when KVM
> > allows the bit to
> >       be set in vmcs12.
> 
> Gotcha, and I think this fact alone will drive a nice bit of cleanup
> thru
> the entire series. Will mop it up

Yea - I think (at least for AMD GMET) if the VMM adds the GMET CPUID
bit to the guest CPUID, it should be taken as 'enabled' by KVM.  No
need for a module param there..

		Amit