| Message ID | 20230822080312.63514-1-likexu@tencent.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86: Allow exposure of VMware backdoor Pseudo-PMCs when !enable_pmu | expand |
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 >
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 >>
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;