[PATCH] KVM: x86: Allow exposure of VMware backdoor Pseudo-PMCs when !enable_pmu

[PATCH] KVM: x86: Allow exposure of VMware backdoor Pseudo-PMCs when !enable_pmu

[Like Xu]

From: Like Xu <likexu@tencent.com>

Fix kvm_pmu_rdpmc() logic to allow exposure of VMware backdoor Pseudo-PMCs
if pmu is globally disabled.

In this usage scenario, once vmware_backdoor is enabled, the VMs can fully
utilize all of the vmware_backdoor-related resources, not just part of it,
i.e., vcpu should always be able to access the VMware backdoor Pseudo-PMCs
via RDPMC. Since the enable_pmu is more concerned with the visibility of
hardware pmu resources on the host, fix it to decouple the two knobs.

The test case vmware_backdoors from KUT is used for validation.

Cc: Arbel Moshe <arbel.moshe@oracle.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Like Xu <likexu@tencent.com>
---
 arch/x86/kvm/pmu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index edb89b51b383..c896328b2b5a 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -526,12 +526,12 @@ int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned idx, u64 *data)
 	struct kvm_pmc *pmc;
 	u64 mask = fast_mode ? ~0u : ~0ull;
 
-	if (!pmu->version)
-		return 1;
-
 	if (is_vmware_backdoor_pmc(idx))
 		return kvm_pmu_rdpmc_vmware(vcpu, idx, data);
 
+	if (!pmu->version)
+		return 1;
+
 	pmc = static_call(kvm_x86_pmu_rdpmc_ecx_to_pmc)(vcpu, idx, &mask);
 	if (!pmc)
 		return 1;

base-commit: fff2e47e6c3b8050ca26656693caa857e3a8b740
-- 
2.41.0

Re: [PATCH] KVM: x86: Allow exposure of VMware backdoor Pseudo-PMCs when !enable_pmu

[Sean Christopherson]

On Tue, Aug 22, 2023, Like Xu wrote:
> From: Like Xu <likexu@tencent.com>
> 
> Fix kvm_pmu_rdpmc() logic to allow exposure of VMware backdoor Pseudo-PMCs
> if pmu is globally disabled.
> 
> In this usage scenario, once vmware_backdoor is enabled, the VMs can fully
> utilize all of the vmware_backdoor-related resources, not just part of it,
> i.e., vcpu should always be able to access the VMware backdoor Pseudo-PMCs
> via RDPMC. Since the enable_pmu is more concerned with the visibility of
> hardware pmu resources on the host, fix it to decouple the two knobs.
>
> The test case vmware_backdoors from KUT is used for validation.

Is there a real world need for this?  Per commit 672ff6cff80c ("KVM: x86: Raise
#GP when guest vCPU do not support PMU"), KVM's behavior is intentional.  If there
is a real world need, then (a) that justification needs to be provided, (b) this
needs a Fixes:, and (c) this probably needs to be tagged for stable.

> Cc: Arbel Moshe <arbel.moshe@oracle.com>
> Cc: Liran Alon <liran.alon@oracle.com>
> Cc: Nikita Leshenko <nikita.leshchenko@oracle.com>

The expectation is that a Cc: in the changelog means the patch email is Cc'd to
that person, i.e. one of the purposes of Cc: here is to record that people who
might care about the patch have been made aware of its existence.  stable@ is
pretty much the only exception to that rule, as "Cc: stable@vger.kernel.org" is
really just a metadata tag for scripts.

FWIW, I believe Liran no longer works for Oracle, no idea about the others.

> Signed-off-by: Like Xu <likexu@tencent.com>
> ---
>  arch/x86/kvm/pmu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> index edb89b51b383..c896328b2b5a 100644
> --- a/arch/x86/kvm/pmu.c
> +++ b/arch/x86/kvm/pmu.c
> @@ -526,12 +526,12 @@ int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned idx, u64 *data)
>  	struct kvm_pmc *pmc;
>  	u64 mask = fast_mode ? ~0u : ~0ull;
>  
> -	if (!pmu->version)
> -		return 1;
> -
>  	if (is_vmware_backdoor_pmc(idx))
>  		return kvm_pmu_rdpmc_vmware(vcpu, idx, data);
>  
> +	if (!pmu->version)
> +		return 1;
> +
>  	pmc = static_call(kvm_x86_pmu_rdpmc_ecx_to_pmc)(vcpu, idx, &mask);
>  	if (!pmc)
>  		return 1;
> 
> base-commit: fff2e47e6c3b8050ca26656693caa857e3a8b740
> -- 
> 2.41.0
> 

Re: [PATCH] KVM: x86: Allow exposure of VMware backdoor Pseudo-PMCs when !enable_pmu

[Like Xu]

Hi folks,

Please help confirm if VMware backdoor Pseudo-PMCs [*] are still available
when the KVM module parameter eneble_pmu=0.

	- VMWARE_BACKDOOR_PMC_HOST_TSC;
	- VMWARE_BACKDOOR_PMC_REAL_TIME;
	- VMWARE_BACKDOOR_PMC_APPARENT_TIME;

I'd like to say yes, but safely you have the official right to define it. Thanks.

[*] https://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf

On 24/8/2023 4:35 am, Sean Christopherson wrote:
> On Tue, Aug 22, 2023, Like Xu wrote:
>> From: Like Xu <likexu@tencent.com>
>>
>> Fix kvm_pmu_rdpmc() logic to allow exposure of VMware backdoor Pseudo-PMCs
>> if pmu is globally disabled.
>>
>> In this usage scenario, once vmware_backdoor is enabled, the VMs can fully
>> utilize all of the vmware_backdoor-related resources, not just part of it,
>> i.e., vcpu should always be able to access the VMware backdoor Pseudo-PMCs
>> via RDPMC. Since the enable_pmu is more concerned with the visibility of
>> hardware pmu resources on the host, fix it to decouple the two knobs.
>>
>> The test case vmware_backdoors from KUT is used for validation.
> 
> Is there a real world need for this?  Per commit 672ff6cff80c ("KVM: x86: Raise
> #GP when guest vCPU do not support PMU"), KVM's behavior is intentional.  If there
> is a real world need, then (a) that justification needs to be provided, (b) this
> needs a Fixes:, and (c) this probably needs to be tagged for stable.
> 
>> Cc: Arbel Moshe <arbel.moshe@oracle.com>
>> Cc: Liran Alon <liran.alon@oracle.com>
>> Cc: Nikita Leshenko <nikita.leshchenko@oracle.com>
> 
> The expectation is that a Cc: in the changelog means the patch email is Cc'd to
> that person, i.e. one of the purposes of Cc: here is to record that people who
> might care about the patch have been made aware of its existence.  stable@ is
> pretty much the only exception to that rule, as "Cc: stable@vger.kernel.org" is
> really just a metadata tag for scripts.
> 
> FWIW, I believe Liran no longer works for Oracle, no idea about the others.
> 
>> Signed-off-by: Like Xu <likexu@tencent.com>
>> ---
>>   arch/x86/kvm/pmu.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>> index edb89b51b383..c896328b2b5a 100644
>> --- a/arch/x86/kvm/pmu.c
>> +++ b/arch/x86/kvm/pmu.c
>> @@ -526,12 +526,12 @@ int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned idx, u64 *data)
>>   	struct kvm_pmc *pmc;
>>   	u64 mask = fast_mode ? ~0u : ~0ull;
>>   
>> -	if (!pmu->version)
>> -		return 1;
>> -
>>   	if (is_vmware_backdoor_pmc(idx))
>>   		return kvm_pmu_rdpmc_vmware(vcpu, idx, data);
>>   
>> +	if (!pmu->version)
>> +		return 1;
>> +
>>   	pmc = static_call(kvm_x86_pmu_rdpmc_ecx_to_pmc)(vcpu, idx, &mask);
>>   	if (!pmc)
>>   		return 1;
>>
>> base-commit: fff2e47e6c3b8050ca26656693caa857e3a8b740
>> -- 
>> 2.41.0
>>