From mboxrd@z Thu Jan 1 00:00:00 1970 From: Malcolm Crossley Subject: Re: [PATCH] RFC: Linux: disable APERF/MPERF feature in PV kernels Date: Tue, 22 May 2012 18:08:46 +0100 Message-ID: <4FBBC81E.9040502@citrix.com> References: <4FBBB9AF.6020704@amd.com> <4FBBC44B.9020007@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050109050203070105050807" Return-path: In-Reply-To: <4FBBC44B.9020007@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --------------050109050203070105050807 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 --------------050109050203070105050807 Content-Type: text/x-patch; name="mask-thermal-and-power-management-leaf.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mask-thermal-and-power-management-leaf.patch" # 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 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 */ --------------050109050203070105050807 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------050109050203070105050807--