Re: [PATCH v6 04/16] KVM: x86/pmu: Set MSR_IA32_MISC_ENABLE_EMON bit when vPMU is enabled
From: Xu, Like
Date: Wed May 12 2021 - 22:51:03 EST
On 2021/5/12 23:18, Sean Christopherson wrote:
On Wed, May 12, 2021, Xu, Like wrote:
Hi Venkatesh Srinivas,
On 2021/5/12 9:58, Venkatesh Srinivas wrote:
On 5/10/21, Like Xu <like.xu@xxxxxxxxxxxxxxx> wrote:
On Intel platforms, the software can use the IA32_MISC_ENABLE[7] bit to
detect whether the processor supports performance monitoring facility.
It depends on the PMU is enabled for the guest, and a software write
operation to this available bit will be ignored.
Is the behavior that writes to IA32_MISC_ENABLE[7] are ignored (rather than #GP)
documented someplace?
The bit[7] behavior of the real hardware on the native host is quite
suspicious.
Ugh. Can you file an SDM bug to get the wording and accessibility updated? The
current phrasing is a mess:
Performance Monitoring Available (R)
1 = Performance monitoring enabled.
0 = Performance monitoring disabled.
The (R) is ambiguous because most other entries that are read-only use (RO), and
the "enabled vs. disabled" implies the bit is writable and really does control
the PMU. But on my Haswell system, it's read-only.
On your Haswell system, does it cause #GP or just silent if you change this
bit ?
Assuming the bit is supposed
to be a read-only "PMU supported bit", the SDM should be:
Performance Monitoring Available (RO)
1 = Performance monitoring supported.
0 = Performance monitoring not supported.
And please update the changelog to explain the "why" of whatever the behavior
ends up being. The "what" is obvious from the code.
Thanks for your "why" comment.
To keep the semantics consistent and simple, we propose ignoring write
operation in the virtualized world, since whether or not to expose PMU is
configured by the hypervisor user space and not by the guest side.
Making up our own architectural behavior because it's convient is not a good
idea.
Sometime we do change it.
For example, the scope of some msrs may be "core level share"
but we likely keep it as a "thread level" variable in the KVM out of
convenience.
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 9efc1a6b8693..d9dbebe03cae 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -488,6 +488,7 @@ static void intel_pmu_refresh(struct kvm_vcpu *vcpu)
if (!pmu->version)
return;
+ vcpu->arch.ia32_misc_enable_msr |= MSR_IA32_MISC_ENABLE_EMON;
Hmm, normally I would say overwriting the guest's value is a bad idea, but if
the bit really is a read-only "PMU supported" bit, then this is the correct
behavior, albeit weird if userspace does a late CPUID update (though that's
weird no matter what).
perf_get_x86_pmu_capability(&x86_pmu);
pmu->nr_arch_gp_counters = min_t(int, eax.split.num_counters,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5bd550eaf683..abe3ea69078c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3211,6 +3211,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
}
break;
case MSR_IA32_MISC_ENABLE:
+ data &= ~MSR_IA32_MISC_ENABLE_EMON;
However, this is not. If it's a read-only bit, then toggling the bit should
cause a #GP.
The proposal here is trying to make it as an
unchangeable bit and don't make it #GP if guest changes it.
It may different from the host behavior but
it doesn't cause potential issue if some guest code
changes it during the use of performance monitoring.
Does this make sense to you or do you want to
keep it strictly the same as the host side?
if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT)
&&
((vcpu->arch.ia32_misc_enable_msr ^ data) &
MSR_IA32_MISC_ENABLE_MWAIT)) {
if (!guest_cpuid_has(vcpu, X86_FEATURE_XMM3))
--