[RFC] Avoid dom0/HVM performance penalty from MSR access tightening

[Alex Olson <this.is.a0lson@xxxxxxxxx>]

I'm seeing strange performance issues under Xen on a Supermicro server with a 
Xeon D-1541 CPU caused by an MSR-related commit.

Commit 322ec7c89f6640ee2a99d1040b6f786cf04872cf 'x86/pv: disallow access to 
unknown MSRs'
surprisingly introduces a severe performance penality where dom0 has about 1/8th
the normal CPU performance. Even even when 'xenpm' is used to select the
performance governor and operate the CPU at maximum frequency, actual CPU
performance is still 1/2 of normal (as well as using "cpufreq=xen,performance").

The patch below fixes it but I don't fully understand why.

Basically, when *reads* of MSR_IA32_THERM_CONTROL are blocked, dom0 and
guests (pinned to other CPUs) see the performance issues.

For benchmarking purposes, I built a small C program that runs a "for
loop" 
4Billion iterations and timed its execution. In dom0, the
performance issues
also cause HVM guest startup time to go from 9-10
seconds to almost 80 seconds.

I assumed Xen was managing CPU frequency and thus blocking related MSR
access by dom0 (or any other domain). However,  clearly something else
is happening and I don't understand why.

I initially attempted to copy the same logic as the write MSR case. This
was effective at fixing the dom0 performance issue, but still left other
domains running at 1/2 speed. Hence, the change below has no access control.


If anyone has any insight as to what is really happening, I would be all ears
as I am unsure if the change below is a proper solution.

Thanks

-Alex

---
---
 xen/arch/x86/pv/emul-priv-op.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 7f4279a051..f254479bda 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -970,6 +970,18 @@ static int read_msr(unsigned int reg, uint64_t *val,
         *val = 0;
         return X86EMUL_OKAY;
 
+    /* being unable to read MSR_IA32_THERM_CONTROL seems to significantly 
affect
+     * dom0 and thus HVM guest startup performance, as well as PVH VMs.
+     */
+    case MSR_IA32_THERM_CONTROL:
+    case MSR_IA32_ENERGY_PERF_BIAS:
+        *val = 0;
+        if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
+            break;
+        if ( rdmsr_safe(reg, *val) == 0)
+            return X86EMUL_OKAY;
+        break;
+
     case MSR_P6_PERFCTR(0) ... MSR_P6_PERFCTR(7):
     case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(3):
     case MSR_CORE_PERF_FIXED_CTR0 ... MSR_CORE_PERF_FIXED_CTR2:
-- 
2.30.2