[PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[Chenyi Qiang]

The three msr number lists(msrs_to_save[], emulated_msrs[] and
msr_based_features[]) are global arrays of kvm.ko, which are
initialized/adjusted (copy supported MSRs forward to override the
unsupported MSRs) when installing kvm-{intel,amd}.ko, but it doesn't
reset these three arrays to their initial value when uninstalling
kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko
will initialize the modified arrays with some MSRs lost and some MSRs
duplicated.

So allocate and initialize these three MSR number lists dynamically when
installing kvm-{intel,amd}.ko and free them when uninstalling.

Cc: stable@vger.kernel.org
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
---
 arch/x86/kvm/x86.c | 86 ++++++++++++++++++++++++++++++----------------
 1 file changed, 57 insertions(+), 29 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ff395f812719..08efcf6351cc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1132,13 +1132,15 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
  * List of msr numbers which we expose to userspace through KVM_GET_MSRS
  * and KVM_SET_MSRS, and KVM_GET_MSR_INDEX_LIST.
  *
- * This list is modified at module load time to reflect the
+ * The three msr number lists(msrs_to_save, emulated_msrs, msr_based_features)
+ * are allocated and initialized at module load time and freed at unload time.
+ * msrs_to_save is selected from the msrs_to_save_all to reflect the
  * capabilities of the host cpu. This capabilities test skips MSRs that are
- * kvm-specific. Those are put in emulated_msrs; filtering of emulated_msrs
+ * kvm-specific. Those are put in emulated_msrs_all; filtering of emulated_msrs
  * may depend on host virtualization features rather than host cpu features.
  */
 
-static u32 msrs_to_save[] = {
+const u32 msrs_to_save_all[] = {
 	MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
 	MSR_STAR,
 #ifdef CONFIG_X86_64
@@ -1179,9 +1181,10 @@ static u32 msrs_to_save[] = {
 	MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17,
 };
 
+static u32 *msrs_to_save;
 static unsigned num_msrs_to_save;
 
-static u32 emulated_msrs[] = {
+const u32 emulated_msrs_all[] = {
 	MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
 	MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
 	HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
@@ -1220,7 +1223,7 @@ static u32 emulated_msrs[] = {
 	 * by arch/x86/kvm/vmx/nested.c based on CPUID or other MSRs.
 	 * We always support the "true" VMX control MSRs, even if the host
 	 * processor does not, so I am putting these registers here rather
-	 * than in msrs_to_save.
+	 * than in msrs_to_save_all.
 	 */
 	MSR_IA32_VMX_BASIC,
 	MSR_IA32_VMX_TRUE_PINBASED_CTLS,
@@ -1239,13 +1242,14 @@ static u32 emulated_msrs[] = {
 	MSR_KVM_POLL_CONTROL,
 };
 
+static u32 *emulated_msrs;
 static unsigned num_emulated_msrs;
 
 /*
  * List of msr numbers which are used to expose MSR-based features that
  * can be used by a hypervisor to validate requested CPU features.
  */
-static u32 msr_based_features[] = {
+const u32 msr_based_features_all[] = {
 	MSR_IA32_VMX_BASIC,
 	MSR_IA32_VMX_TRUE_PINBASED_CTLS,
 	MSR_IA32_VMX_PINBASED_CTLS,
@@ -1270,6 +1274,7 @@ static u32 msr_based_features[] = {
 	MSR_IA32_ARCH_CAPABILITIES,
 };
 
+static u32 *msr_based_features;
 static unsigned int num_msr_based_features;
 
 static u64 kvm_get_arch_capabilities(void)
@@ -3311,11 +3316,11 @@ long kvm_arch_dev_ioctl(struct file *filp,
 		if (n < msr_list.nmsrs)
 			goto out;
 		r = -EFAULT;
-		if (copy_to_user(user_msr_list->indices, &msrs_to_save,
+		if (copy_to_user(user_msr_list->indices, msrs_to_save,
 				 num_msrs_to_save * sizeof(u32)))
 			goto out;
 		if (copy_to_user(user_msr_list->indices + num_msrs_to_save,
-				 &emulated_msrs,
+				 emulated_msrs,
 				 num_emulated_msrs * sizeof(u32)))
 			goto out;
 		r = 0;
@@ -3364,7 +3369,7 @@ long kvm_arch_dev_ioctl(struct file *filp,
 		if (n < msr_list.nmsrs)
 			goto out;
 		r = -EFAULT;
-		if (copy_to_user(user_msr_list->indices, &msr_based_features,
+		if (copy_to_user(user_msr_list->indices, msr_based_features,
 				 num_msr_based_features * sizeof(u32)))
 			goto out;
 		r = 0;
@@ -5086,26 +5091,41 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	return r;
 }
 
-static void kvm_init_msr_list(void)
+static int kvm_init_msr_list(void)
 {
 	struct x86_pmu_capability x86_pmu;
 	u32 dummy[2];
 	unsigned i, j;
 
 	BUILD_BUG_ON_MSG(INTEL_PMC_MAX_FIXED != 4,
-			 "Please update the fixed PMCs in msrs_to_save[]");
+			 "Please update the fixed PMCs in msrs_to_saved_all[]");
 
 	perf_get_x86_pmu_capability(&x86_pmu);
 
-	for (i = j = 0; i < ARRAY_SIZE(msrs_to_save); i++) {
-		if (rdmsr_safe(msrs_to_save[i], &dummy[0], &dummy[1]) < 0)
+	msrs_to_save = kmalloc(sizeof(msrs_to_save_all),
+							GFP_KERNEL_ACCOUNT);
+	if (!msrs_to_save)
+		return -ENOMEM;
+
+	emulated_msrs = kmalloc(sizeof(emulated_msrs_all),
+							GFP_KERNEL_ACCOUNT);
+	if (!emulated_msrs)
+		goto free_msrs_to_save;
+
+	msr_based_features = kmalloc(sizeof(msr_based_features_all),
+							GFP_KERNEL_ACCOUNT);
+	if (!msr_based_features)
+		goto free_emulated_msrs;
+
+	for (i = j = 0; i < ARRAY_SIZE(msrs_to_save_all); i++) {
+		if (rdmsr_safe(msrs_to_save_all[i], &dummy[0], &dummy[1]) < 0)
 			continue;
 
 		/*
 		 * Even MSRs that are valid in the host may not be exposed
 		 * to the guests in some cases.
 		 */
-		switch (msrs_to_save[i]) {
+		switch (msrs_to_save_all[i]) {
 		case MSR_IA32_BNDCFGS:
 			if (!kvm_mpx_supported())
 				continue;
@@ -5133,17 +5153,17 @@ static void kvm_init_msr_list(void)
 			break;
 		case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
 			if (!kvm_x86_ops->pt_supported() ||
-				msrs_to_save[i] - MSR_IA32_RTIT_ADDR0_A >=
+				msrs_to_save_all[i] - MSR_IA32_RTIT_ADDR0_A >=
 				intel_pt_validate_hw_cap(PT_CAP_num_address_ranges) * 2)
 				continue;
 			break;
 		case MSR_ARCH_PERFMON_PERFCTR0 ... MSR_ARCH_PERFMON_PERFCTR0 + 17:
-			if (msrs_to_save[i] - MSR_ARCH_PERFMON_PERFCTR0 >=
+			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_PERFCTR0 >=
 			    min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
 				continue;
 			break;
 		case MSR_ARCH_PERFMON_EVENTSEL0 ... MSR_ARCH_PERFMON_EVENTSEL0 + 17:
-			if (msrs_to_save[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
+			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
 			    min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
 				continue;
 		}
@@ -5151,34 +5171,40 @@ static void kvm_init_msr_list(void)
 			break;
 		}
 
-		if (j < i)
-			msrs_to_save[j] = msrs_to_save[i];
+		if (j <= i)
+			msrs_to_save[j] = msrs_to_save_all[i];
 		j++;
 	}
 	num_msrs_to_save = j;
 
-	for (i = j = 0; i < ARRAY_SIZE(emulated_msrs); i++) {
-		if (!kvm_x86_ops->has_emulated_msr(emulated_msrs[i]))
+	for (i = j = 0; i < ARRAY_SIZE(emulated_msrs_all); i++) {
+		if (!kvm_x86_ops->has_emulated_msr(emulated_msrs_all[i]))
 			continue;
 
-		if (j < i)
-			emulated_msrs[j] = emulated_msrs[i];
+		if (j <= i)
+			emulated_msrs[j] = emulated_msrs_all[i];
 		j++;
 	}
 	num_emulated_msrs = j;
 
-	for (i = j = 0; i < ARRAY_SIZE(msr_based_features); i++) {
+	for (i = j = 0; i < ARRAY_SIZE(msr_based_features_all); i++) {
 		struct kvm_msr_entry msr;
 
-		msr.index = msr_based_features[i];
+		msr.index = msr_based_features_all[i];
 		if (kvm_get_msr_feature(&msr))
 			continue;
 
-		if (j < i)
-			msr_based_features[j] = msr_based_features[i];
+		if (j <= i)
+			msr_based_features[j] = msr_based_features_all[i];
 		j++;
 	}
 	num_msr_based_features = j;
+	return 0;
+free_emulated_msrs:
+	kfree(emulated_msrs);
+free_msrs_to_save:
+	kfree(msrs_to_save);
+	return -ENOMEM;
 }
 
 static int vcpu_mmio_write(struct kvm_vcpu *vcpu, gpa_t addr, int len,
@@ -9294,12 +9320,14 @@ int kvm_arch_hardware_setup(void)
 		kvm_default_tsc_scaling_ratio = 1ULL << kvm_tsc_scaling_ratio_frac_bits;
 	}
 
-	kvm_init_msr_list();
-	return 0;
+	return kvm_init_msr_list();
 }
 
 void kvm_arch_hardware_unsetup(void)
 {
+	kfree(msr_based_features);
+	kfree(emulated_msrs);
+	kfree(msrs_to_save);
 	kvm_x86_ops->hardware_unsetup();
 }
 
-- 
2.17.1

Re: [PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[Paolo Bonzini]

On 05/11/19 10:20, Chenyi Qiang wrote:
> The three msr number lists(msrs_to_save[], emulated_msrs[] and
> msr_based_features[]) are global arrays of kvm.ko, which are
> initialized/adjusted (copy supported MSRs forward to override the
> unsupported MSRs) when installing kvm-{intel,amd}.ko, but it doesn't
> reset these three arrays to their initial value when uninstalling
> kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko
> will initialize the modified arrays with some MSRs lost and some MSRs
> duplicated.
> 
> So allocate and initialize these three MSR number lists dynamically when
> installing kvm-{intel,amd}.ko and free them when uninstalling.

I don't understand.  Do you mean insmod/rmmod when you say
installing/uninstalling? Global data must be reloaded from the ELF file
when insmod is executed.

How is the bug reproducible?

Paolo

Re: [PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[Xiaoyao Li]

On 11/5/2019 6:41 PM, Paolo Bonzini wrote:
> On 05/11/19 10:20, Chenyi Qiang wrote:
>> The three msr number lists(msrs_to_save[], emulated_msrs[] and
>> msr_based_features[]) are global arrays of kvm.ko, which are
>> initialized/adjusted (copy supported MSRs forward to override the
>> unsupported MSRs) when installing kvm-{intel,amd}.ko, but it doesn't
>> reset these three arrays to their initial value when uninstalling
>> kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko
>> will initialize the modified arrays with some MSRs lost and some MSRs
>> duplicated.
>>
>> So allocate and initialize these three MSR number lists dynamically when
>> installing kvm-{intel,amd}.ko and free them when uninstalling.
> 
> I don't understand.  Do you mean insmod/rmmod when you say
> installing/uninstalling? Global data must be reloaded from the ELF file
> when insmod is executed.

Yes, we mean insmod/rmmod.
The problem is that these three MSR arrays belong to kvm.ko but not 
kvm-{intel,amd}.ko. When we rmmod kvm_intel.ko, it does nothing to them.

> How is the bug reproducible?

Suppose there is an intel machine.

1. You can first run
	#rmmod kvm-intel.ko
	#insmod kvm-intel.ko nested=0
2. and then
	#rmmod kvm-intel.ko
	#insmod kvm-intel.ko nested=1

In step 1, all the vmx-related MSRs in msr_based_features[] are not 
supported due to nested=0. And it will move MSR_IA32_UCODE_REV and 
MSR_IA32_ARCH_CAPABILITIES (on my Cascadelake server) forward to 
override array member 0 and 1 (MSR_IA32_VMX_BASIC and 
MSR_IA32_VMX_TRUE_PINBASED_CTLS).

In step 2, we just lose MSR_IA32_VMX_BASIC and 
MSR_IA32_VMX_TRUE_PINBASED_CTLS of VMX and get duplicated 
MSR_IA32_UCODE_REV and MSR_IA32_ARCH_CAPABILITIES.

> Paolo
> 

Re: [PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[Paolo Bonzini]

On 05/11/19 12:11, Xiaoyao Li wrote:
> On 11/5/2019 6:41 PM, Paolo Bonzini wrote:
>> On 05/11/19 10:20, Chenyi Qiang wrote:
>>> The three msr number lists(msrs_to_save[], emulated_msrs[] and
>>> msr_based_features[]) are global arrays of kvm.ko, which are
>>> initialized/adjusted (copy supported MSRs forward to override the
>>> unsupported MSRs) when installing kvm-{intel,amd}.ko, but it doesn't
>>> reset these three arrays to their initial value when uninstalling
>>> kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko
>>> will initialize the modified arrays with some MSRs lost and some MSRs
>>> duplicated.
>>>
>>> So allocate and initialize these three MSR number lists dynamically when
>>> installing kvm-{intel,amd}.ko and free them when uninstalling.
>>
>> I don't understand.  Do you mean insmod/rmmod when you say
>> installing/uninstalling? Global data must be reloaded from the ELF file
>> when insmod is executed.
> 
> Yes, we mean insmod/rmmod.
> The problem is that these three MSR arrays belong to kvm.ko but not
> kvm-{intel,amd}.ko. When we rmmod kvm_intel.ko, it does nothing to them.

Ok, thanks for the explanation.

Paolo

Re: [PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[Paolo Bonzini]

On 05/11/19 10:20, Chenyi Qiang wrote:
> The three msr number lists(msrs_to_save[], emulated_msrs[] and
> msr_based_features[]) are global arrays of kvm.ko, which are
> initialized/adjusted (copy supported MSRs forward to override the
> unsupported MSRs) when installing kvm-{intel,amd}.ko, but it doesn't
> reset these three arrays to their initial value when uninstalling
> kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko
> will initialize the modified arrays with some MSRs lost and some MSRs
> duplicated.
> 
> So allocate and initialize these three MSR number lists dynamically when
> installing kvm-{intel,amd}.ko and free them when uninstalling.
> 
> Cc: stable@vger.kernel.org
> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
> ---
>  arch/x86/kvm/x86.c | 86 ++++++++++++++++++++++++++++++----------------
>  1 file changed, 57 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index ff395f812719..08efcf6351cc 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1132,13 +1132,15 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
>   * List of msr numbers which we expose to userspace through KVM_GET_MSRS
>   * and KVM_SET_MSRS, and KVM_GET_MSR_INDEX_LIST.
>   *
> - * This list is modified at module load time to reflect the
> + * The three msr number lists(msrs_to_save, emulated_msrs, msr_based_features)
> + * are allocated and initialized at module load time and freed at unload time.
> + * msrs_to_save is selected from the msrs_to_save_all to reflect the
>   * capabilities of the host cpu. This capabilities test skips MSRs that are
> - * kvm-specific. Those are put in emulated_msrs; filtering of emulated_msrs
> + * kvm-specific. Those are put in emulated_msrs_all; filtering of emulated_msrs
>   * may depend on host virtualization features rather than host cpu features.
>   */
>  
> -static u32 msrs_to_save[] = {
> +const u32 msrs_to_save_all[] = {

This can remain static.

>  	MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
>  	MSR_STAR,
>  #ifdef CONFIG_X86_64
> @@ -1179,9 +1181,10 @@ static u32 msrs_to_save[] = {
>  	MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17,
>  };
>  
> +static u32 *msrs_to_save;

You can use ARRAY_SIZE to allocate the destination arrays statically.

Paolo

Re: [PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[Xiaoyao Li]

On 11/5/2019 7:30 PM, Paolo Bonzini wrote:
> On 05/11/19 10:20, Chenyi Qiang wrote:
>> The three msr number lists(msrs_to_save[], emulated_msrs[] and
>> msr_based_features[]) are global arrays of kvm.ko, which are
>> initialized/adjusted (copy supported MSRs forward to override the
>> unsupported MSRs) when installing kvm-{intel,amd}.ko, but it doesn't
>> reset these three arrays to their initial value when uninstalling
>> kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko
>> will initialize the modified arrays with some MSRs lost and some MSRs
>> duplicated.
>>
>> So allocate and initialize these three MSR number lists dynamically when
>> installing kvm-{intel,amd}.ko and free them when uninstalling.
>>
>> Cc: stable@vger.kernel.org
>> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
>> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
>> ---
>>   arch/x86/kvm/x86.c | 86 ++++++++++++++++++++++++++++++----------------
>>   1 file changed, 57 insertions(+), 29 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index ff395f812719..08efcf6351cc 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -1132,13 +1132,15 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
>>    * List of msr numbers which we expose to userspace through KVM_GET_MSRS
>>    * and KVM_SET_MSRS, and KVM_GET_MSR_INDEX_LIST.
>>    *
>> - * This list is modified at module load time to reflect the
>> + * The three msr number lists(msrs_to_save, emulated_msrs, msr_based_features)
>> + * are allocated and initialized at module load time and freed at unload time.
>> + * msrs_to_save is selected from the msrs_to_save_all to reflect the
>>    * capabilities of the host cpu. This capabilities test skips MSRs that are
>> - * kvm-specific. Those are put in emulated_msrs; filtering of emulated_msrs
>> + * kvm-specific. Those are put in emulated_msrs_all; filtering of emulated_msrs
>>    * may depend on host virtualization features rather than host cpu features.
>>    */
>>   
>> -static u32 msrs_to_save[] = {
>> +const u32 msrs_to_save_all[] = {
> 
> This can remain static.

How about static const u32 msrs_to_save_all[] ?

Or you think static is enough?

>>   	MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
>>   	MSR_STAR,
>>   #ifdef CONFIG_X86_64
>> @@ -1179,9 +1181,10 @@ static u32 msrs_to_save[] = {
>>   	MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17,
>>   };
>>   
>> +static u32 *msrs_to_save;
> 
> You can use ARRAY_SIZE to allocate the destination arrays statically.

It's much better, then we don't need to allocation and free.

> Paolo
> 

Re: [PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[Paolo Bonzini]

On 05/11/19 13:51, Xiaoyao Li wrote:
> On 11/5/2019 7:30 PM, Paolo Bonzini wrote:
>> On 05/11/19 10:20, Chenyi Qiang wrote:
>>> The three msr number lists(msrs_to_save[], emulated_msrs[] and
>>> msr_based_features[]) are global arrays of kvm.ko, which are
>>> initialized/adjusted (copy supported MSRs forward to override the
>>> unsupported MSRs) when installing kvm-{intel,amd}.ko, but it doesn't
>>> reset these three arrays to their initial value when uninstalling
>>> kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko
>>> will initialize the modified arrays with some MSRs lost and some MSRs
>>> duplicated.
>>>
>>> So allocate and initialize these three MSR number lists dynamically when
>>> installing kvm-{intel,amd}.ko and free them when uninstalling.
>>>
>>> Cc: stable@vger.kernel.org
>>> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
>>> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
>>> ---
>>>   arch/x86/kvm/x86.c | 86 ++++++++++++++++++++++++++++++----------------
>>>   1 file changed, 57 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index ff395f812719..08efcf6351cc 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -1132,13 +1132,15 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
>>>    * List of msr numbers which we expose to userspace through
>>> KVM_GET_MSRS
>>>    * and KVM_SET_MSRS, and KVM_GET_MSR_INDEX_LIST.
>>>    *
>>> - * This list is modified at module load time to reflect the
>>> + * The three msr number lists(msrs_to_save, emulated_msrs,
>>> msr_based_features)
>>> + * are allocated and initialized at module load time and freed at
>>> unload time.
>>> + * msrs_to_save is selected from the msrs_to_save_all to reflect the
>>>    * capabilities of the host cpu. This capabilities test skips MSRs
>>> that are
>>> - * kvm-specific. Those are put in emulated_msrs; filtering of
>>> emulated_msrs
>>> + * kvm-specific. Those are put in emulated_msrs_all; filtering of
>>> emulated_msrs
>>>    * may depend on host virtualization features rather than host cpu
>>> features.
>>>    */
>>>   -static u32 msrs_to_save[] = {
>>> +const u32 msrs_to_save_all[] = {
>>
>> This can remain static.
> 
> How about static const u32 msrs_to_save_all[] ?
> 
> Or you think static is enough?

"static const" is best indeed (that's what I meant, but I wasn't very
clear).

Paolo

>>>       MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP,
>>> MSR_IA32_SYSENTER_EIP,
>>>       MSR_STAR,
>>>   #ifdef CONFIG_X86_64
>>> @@ -1179,9 +1181,10 @@ static u32 msrs_to_save[] = {
>>>       MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17,
>>>   };
>>>   +static u32 *msrs_to_save;
>>
>> You can use ARRAY_SIZE to allocate the destination arrays statically.
> 
> It's much better, then we don't need to allocation and free.
> 
>> Paolo
>>

Re: [PATCH] KVM: X86: Dynamically allocating MSR number lists(msrs_to_save[], emulated_msrs[], msr_based_features[])

[cqiang]

On 11/5/2019 9:03 PM, Paolo Bonzini wrote:
> On 05/11/19 13:51, Xiaoyao Li wrote:
>> On 11/5/2019 7:30 PM, Paolo Bonzini wrote:
>>> On 05/11/19 10:20, Chenyi Qiang wrote:
>>>> The three msr number lists(msrs_to_save[], emulated_msrs[] and
>>>> msr_based_features[]) are global arrays of kvm.ko, which are
>>>> initialized/adjusted (copy supported MSRs forward to override the
>>>> unsupported MSRs) when installing kvm-{intel,amd}.ko, but it doesn't
>>>> reset these three arrays to their initial value when uninstalling
>>>> kvm-{intel,amd}.ko. Thus, at the next installation, kvm-{intel,amd}.ko
>>>> will initialize the modified arrays with some MSRs lost and some MSRs
>>>> duplicated.
>>>>
>>>> So allocate and initialize these three MSR number lists dynamically when
>>>> installing kvm-{intel,amd}.ko and free them when uninstalling.
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
>>>> Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
>>>> ---
>>>>    arch/x86/kvm/x86.c | 86 ++++++++++++++++++++++++++++++----------------
>>>>    1 file changed, 57 insertions(+), 29 deletions(-)
>>>>
>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>>> index ff395f812719..08efcf6351cc 100644
>>>> --- a/arch/x86/kvm/x86.c
>>>> +++ b/arch/x86/kvm/x86.c
>>>> @@ -1132,13 +1132,15 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
>>>>     * List of msr numbers which we expose to userspace through
>>>> KVM_GET_MSRS
>>>>     * and KVM_SET_MSRS, and KVM_GET_MSR_INDEX_LIST.
>>>>     *
>>>> - * This list is modified at module load time to reflect the
>>>> + * The three msr number lists(msrs_to_save, emulated_msrs,
>>>> msr_based_features)
>>>> + * are allocated and initialized at module load time and freed at
>>>> unload time.
>>>> + * msrs_to_save is selected from the msrs_to_save_all to reflect the
>>>>     * capabilities of the host cpu. This capabilities test skips MSRs
>>>> that are
>>>> - * kvm-specific. Those are put in emulated_msrs; filtering of
>>>> emulated_msrs
>>>> + * kvm-specific. Those are put in emulated_msrs_all; filtering of
>>>> emulated_msrs
>>>>     * may depend on host virtualization features rather than host cpu
>>>> features.
>>>>     */
>>>>    -static u32 msrs_to_save[] = {
>>>> +const u32 msrs_to_save_all[] = {
>>>
>>> This can remain static.
>>
>> How about static const u32 msrs_to_save_all[] ?
>>
>> Or you think static is enough?
> 
> "static const" is best indeed (that's what I meant, but I wasn't very
> clear).
> 

Yes, considering the read-only property and scope of these arrays, 
"static const" is more accurate. Thanks.

> Paolo
> 
>>>>        MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP,
>>>> MSR_IA32_SYSENTER_EIP,
>>>>        MSR_STAR,
>>>>    #ifdef CONFIG_X86_64
>>>> @@ -1179,9 +1181,10 @@ static u32 msrs_to_save[] = {
>>>>        MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17,
>>>>    };
>>>>    +static u32 *msrs_to_save;
>>>
>>> You can use ARRAY_SIZE to allocate the destination arrays statically.
>>
>> It's much better, then we don't need to allocation and free.
>>

Got it. Thanks!

>>> Paolo
>>>
>