From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v3 5/8] x86/HVM: scale MPERF values reported to guests (on AMD)
Date: Mon, 6 Jan 2020 17:37:03 +0100 [thread overview]
Message-ID: <6fe561a6-9fe0-49e7-f1f7-fe36f277052b@suse.com> (raw)
In-Reply-To: <6f167053-38dc-19b5-a873-321d978e9a59@suse.com>
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.
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -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;
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-01-06 16:36 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-06 16:31 [Xen-devel] [PATCH v3 0/8] x86emul: further work Jan Beulich
2020-01-06 16:34 ` [Xen-devel] [PATCH v3 1/8] x86: determine HAVE_AS_* just once Jan Beulich
2020-01-06 16:41 ` Andrew Cooper
2020-01-06 16:56 ` Jan Beulich
2020-01-20 12:04 ` Roger Pau Monné
2020-01-20 12:36 ` Jan Beulich
2020-01-06 16:35 ` [Xen-devel] [PATCH v3 2/8] x86: move back clang no integrated assembler tests Jan Beulich
2020-01-20 11:37 ` Roger Pau Monné
2020-01-06 16:35 ` [Xen-devel] [PATCH v3 3/8] x86emul: support MOVDIRI insn Jan Beulich
2020-01-06 16:56 ` Andrew Cooper
2020-01-06 17:01 ` Jan Beulich
2020-01-06 16:36 ` [Xen-devel] [PATCH RFC v3 4/8] x86emul: support MOVDIR64B insn Jan Beulich
2020-01-06 19:38 ` Andrew Cooper
2020-01-07 9:01 ` Jan Beulich
2020-01-06 16:37 ` Jan Beulich [this message]
2020-01-06 16:37 ` [Xen-devel] [PATCH RFC v3 6/8] x86emul: support RDPRU Jan Beulich
2020-01-06 19:50 ` Andrew Cooper
2020-01-06 16:39 ` [Xen-devel] [PATCH v3 7/8] x86/HVM: don't needlessly intercept APERF/MPERF/TSC MSR reads Jan Beulich
2020-01-19 2:44 ` Tian, Kevin
2020-01-20 8:32 ` Jan Beulich
2020-01-21 2:45 ` Tian, Kevin
2020-01-06 16:39 ` [Xen-devel] [PATCH RFC v3 8/8] x86emul: support MCOMMIT Jan Beulich
2020-01-06 19:45 ` Andrew Cooper
2020-01-07 9:04 ` Jan Beulich
2020-01-06 16:41 ` [Xen-devel] [PATCH v3 0/8] x86emul: further work Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6fe561a6-9fe0-49e7-f1f7-fe36f277052b@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.