xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Malcolm Crossley <malcolm.crossley@citrix.com>
To: xen-devel@lists.xen.org
Subject: Re: [PATCH] RFC: Linux: disable APERF/MPERF feature in PV kernels
Date: Tue, 22 May 2012 18:08:46 +0100	[thread overview]
Message-ID: <4FBBC81E.9040502@citrix.com> (raw)
In-Reply-To: <4FBBC44B.9020007@goop.org>

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On 22/05/12 17:52, Jeremy Fitzhardinge wrote:
> On 05/22/2012 09:07 AM, Andre Przywara wrote:
>> Hi,
>>
>> while testing some APERF/MPERF semantics I discovered that this
>> feature is enabled in Xen Dom0, but is not reliable.
>> The Linux kernel's scheduler uses this feature if it sees the CPUID
>> bit, leading to costly RDMSR traps (a few 100,000s during a kernel
>> compile) and bogus values due to VCPU migration during the measurement.
>> The attached patch explicitly disables this CPU capability inside the
>> Linux kernel, I couldn't measure any APERF/MPERF reads anymore with
>> the patch applied.
>> I am not sure if the PVOPS code is the right place to fix this, we
>> could as well do it in the HV's xen/arch/x86/traps.c:pv_cpuid().
>> Also when the Dom0 VCPUs are pinned, we could allow this, but I am not
>> sure if it's worth to do so.
> Seems reasonable to me.  Do all those RDMSR traps have a measurable
> performance effect?
>
> Also, is there a symbolic constant for that bit?
>
>      J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
Hi,

I've attached a patch which masks the matching CPUID leaves in the Xen pv_cpuid function.
Should the logic in pv_cpuid be changed to only pass through explictly allowed CPUID leaves rather than masking
them using case statements?

Malcolm


[-- Attachment #2: mask-thermal-and-power-management-leaf.patch --]
[-- Type: text/x-patch, Size: 944 bytes --]

# HG changeset patch
# Parent 238900a4ed227d04c164d4cd12dfc66f7a25b946
[PATCH] Xen: Prevent unsupported CPUID leaves from being passed through to dom0 PV guest.

The PV CPUID emulation code is passing through CPUID leaves which do match the unsupported case statement. CPUID features should be passed through when Xen can safely support those features.

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>

diff -r 238900a4ed22 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -900,6 +900,8 @@ static void pv_cpuid(struct cpu_user_reg
         break;
 
     case 0x00000005: /* MONITOR/MWAIT */
+    case 0x00000006: /* Thermal and Power Management leaf */
+    case 0x00000009: /* Direct Cache Access Information Leaf */
     case 0x0000000a: /* Architectural Performance Monitor Features */
     case 0x0000000b: /* Extended Topology Enumeration */
     case 0x8000000a: /* SVM revision and features */

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2012-05-22 17:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-22 16:07 [PATCH] RFC: Linux: disable APERF/MPERF feature in PV kernels Andre Przywara
2012-05-22 16:52 ` Jeremy Fitzhardinge
2012-05-22 17:08   ` Malcolm Crossley [this message]
2012-05-23  8:10     ` Jan Beulich
2012-05-22 20:46   ` Andre Przywara
2012-05-22 17:18 ` Konrad Rzeszutek Wilk
2012-05-22 21:02   ` Andre Przywara
2012-05-22 21:00     ` Konrad Rzeszutek Wilk
2012-05-22 22:44       ` Andre Przywara
2012-05-23 13:26         ` Konrad Rzeszutek Wilk
2012-05-24 13:24           ` Andre Przywara
2012-05-29 10:54             ` Andre Przywara
2012-05-23  7:34 ` Jan Beulich
2012-05-23  9:14   ` Andre Przywara
2012-05-23  9:43     ` Jan Beulich
2012-05-23  9:52       ` Andre Przywara
2012-05-23 10:01         ` Jan Beulich
2012-05-23 11:11   ` Andrew Cooper
2012-05-23 12:18     ` Jan Beulich
2012-05-23 13:21       ` Andrew Cooper
2012-05-23 13:31         ` Andre Przywara

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=4FBBC81E.9040502@citrix.com \
    --to=malcolm.crossley@citrix.com \
    --cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).