@@ -3440,6 +3440,22 @@ int hvm_msr_read_intercept(unsigned int
*msr_content = v->arch.hvm.msr_tsc_adjust;
break;
+ case MSR_MPERF_RD_ONLY:
+ if ( !d->arch.cpuid->extd.efro )
+ {
+ goto gp_fault;
+
+ case MSR_IA32_MPERF:
+ if ( !(d->arch.cpuid->basic.raw[6].c &
+ CPUID6_ECX_APERFMPERF_CAPABILITY) )
+ goto gp_fault;
+ }
+ if ( rdmsr_safe(msr, *msr_content) )
+ goto gp_fault;
+ if ( d->arch.cpuid->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) )
+ *msr_content = hvm_get_guest_tsc_fixed(v, *msr_content);
+ break;
+
case MSR_APIC_BASE:
*msr_content = vcpu_vlapic(v)->hw.apic_base_msr;
break;
@@ -377,6 +377,9 @@
#define MSR_IA32_MPERF 0x000000e7
#define MSR_IA32_APERF 0x000000e8
+#define MSR_MPERF_RD_ONLY 0xc00000e7
+#define MSR_APERF_RD_ONLY 0xc00000e8
+
#define MSR_IA32_THERM_CONTROL 0x0000019a
#define MSR_IA32_THERM_INTERRUPT 0x0000019b
#define MSR_IA32_THERM_STATUS 0x0000019c
AMD's PM specifies that MPERF (and its r/o counterpart) reads are affected by the TSC ratio. Hence when processing such reads in software we too should scale the values. While we don't currently (yet) expose the underlying feature flags, besides us allowing the MSRs to be read nevertheless, RDPRU is going to expose the values even to user space. Furthermore, due to the not exposed feature flags, this change has the effect of making properly inaccessible (for reads) the two MSRs. Note that writes to MPERF (and APERF) continue to be unsupported. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- v3: New. --- I did consider whether to put the code in guest_rdmsr() instead, but decided that it's better to have it next to TSC handling.