> On May 12, 2025, at 2:08 PM, Sean Christopherson <seanjc@xxxxxxxxxx> 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
