On Thu, Nov 17, 2022, Maxim Levitsky wrote: > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 03acbe8ff34edb..08a7b2a0a29f3a 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -230,6 +230,8 @@ module_param(dump_invalid_vmcb, bool, 0644); > bool intercept_smi = true; > module_param(intercept_smi, bool, 0444); > > +bool vnmi = true; This can be __ro_after_init, e.g. see https://lore.kernel.org/all/20221110013003.1421895-4-seanjc@xxxxxxxxxx > +module_param(vnmi, bool, 0444); The exposure of "vnmi" to userspace belongs in the last patch. E.g. this patch should only stub in vnmi: bool __ro_after_init vnmi; and then the last patch that actually enables it can default it to true and expose the param to users. It obviously doesn't matter in the end, but it technically makes this series broken, e.g. nested_sync_int_ctl_from_vmcb02() pivots on "vnmi" without the extra V_NMI_ENABLE check, and advertising the vnmi is enabled when it actually isn't is wrong/misleading.
