Re: [PATCH v5 2/2] KVM: VMX: Cleanup VMX misc information defines and usages

[Sean Christopherson]

On Tue, Feb 06, 2024, Xin Li wrote:
> Define VMX misc information fields with BIT_ULL()/GENMASK_ULL(), and move
> VMX misc field macros to vmx.h if used in multiple files or where they are
> used only once.

Yeah, no.  This changelog doesn't even begin to cover what all is going on here,
and as with the first patch, this obviously needs to be split into multiple
patches.

> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 80fea1875948..a9dfda2cbca3 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -917,6 +917,8 @@ static int nested_vmx_store_msr_check(struct kvm_vcpu *vcpu,
>  	return 0;
>  }
>  
> +#define VMX_MISC_MSR_LIST_MULTIPLIER	512
> +
>  static u32 nested_vmx_max_atomic_switch_msrs(struct kvm_vcpu *vcpu)
>  {
>  	struct vcpu_vmx *vmx = to_vmx(vcpu);
> @@ -1315,18 +1317,34 @@ vmx_restore_control_msr(struct vcpu_vmx *vmx, u32 msr_index, u64 data)
>  	return 0;
>  }
>  
> +#define VMX_MISC_SAVE_EFER_LMA		BIT_ULL(5)
> +#define VMX_MISC_ACTIVITY_STATE_BITMAP	GENMASK_ULL(8, 6)
> +#define VMX_MISC_ACTIVITY_HLT		BIT_ULL(6)
> +#define VMX_MISC_ACTIVITY_WAIT_SIPI	BIT_ULL(8)
> +#define VMX_MISC_RDMSR_IN_SMM		BIT_ULL(15)
> +#define VMX_MISC_VMXOFF_BLOCK_SMI	BIT_ULL(28)

Gah, my bad.  I misread a comment in v1, and gave nonsensical feedback.  I thought
the comment was saying that #defines for the *reserved* bits should be in vmx.h
but you were talking about moving existing defines from msr-index.h to vmx.h.
Defining feature bits in nested.c, and thus splitting the VMX_MISC feature bit
definitions across multiple locations, doesn't make any sense.  Sorry for the
confusion.

 : > Probably should also move VMX MSR field defs from msr-index.h to
 : > a vmx header file.
 : 
 : Why bother putting them in a header?  As above, it's extremely unlikely anything
 : besides vmx_restore_vmx_basic() will ever care about exactly which bits are
 : reserved.

> +#define VMX_MISC_FEATURES_MASK			\
> +	(VMX_MISC_SAVE_EFER_LMA |		\
> +	 VMX_MISC_ACTIVITY_STATE_BITMAP |	\
> +	 VMX_MISC_INTEL_PT |			\
> +	 VMX_MISC_RDMSR_IN_SMM |		\
> +	 VMX_MISC_VMXOFF_BLOCK_SMI |		\
> +	 VMX_MISC_VMWRITE_SHADOW_RO_FIELDS |	\
> +	 VMX_MISC_ZERO_LEN_INS)
> +
> +#define VMX_MISC_RESERVED_BITS			\
> +	(BIT_ULL(31) | GENMASK_ULL(13, 9))
> +
>  static inline bool nested_cpu_has_zero_length_injection(struct kvm_vcpu *vcpu)
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index dc163a580f98..96f0d65dea45 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -2570,7 +2570,6 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf,
>  	u32 _vmexit_control = 0;
>  	u32 _vmentry_control = 0;
>  	u64 basic_msr;
> -	u64 misc_msr;
>  	int i;
>  
>  	/*
> @@ -2704,8 +2703,6 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf,
>  	if (vmx_basic_vmcs_mem_type(basic_msr) != MEM_TYPE_WB)
>  		return -EIO;
>  
> -	rdmsrl(MSR_IA32_VMX_MISC, misc_msr);
> -
>  	vmcs_conf->basic = basic_msr;
>  	vmcs_conf->pin_based_exec_ctrl = _pin_based_exec_control;
>  	vmcs_conf->cpu_based_exec_ctrl = _cpu_based_exec_control;
> @@ -2713,7 +2710,8 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf,
>  	vmcs_conf->cpu_based_3rd_exec_ctrl = _cpu_based_3rd_exec_control;
>  	vmcs_conf->vmexit_ctrl         = _vmexit_control;
>  	vmcs_conf->vmentry_ctrl        = _vmentry_control;
> -	vmcs_conf->misc	= misc_msr;
> +
> +	rdmsrl(MSR_IA32_VMX_MISC, vmcs_conf->misc);

No, keep the local variable.  It's unlikely KVM will require a feature that is
enumerated in VMX_MISC, but it's not impossible, at which point we'd have to revert
this change.

And more importantly, if we messed up and forgot to revert this change, it's
slightly more like that the compiler will fail to detect an "uninitialized" access,
e.g. if vmcs_conf->misc were read before it was filled by rdmsrl().

Uninitialized in quotes because the usage from hardware_setup() isn't truly
uninitialized, i.e. it will be zeros.  If we had a bug as above, we'd be relying
on the compiler to see that vmx_check_processor_compat()'s vmx_cap can get used
uninitialized, whereas the current code should be easily flagged if misc_msr is
used before it's written.