From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: Questing regarding KVM Guest PMU Date: Thu, 5 Apr 2012 16:48:57 +0300 Message-ID: <20120405134857.GK11204@redhat.com> References: <20120404070435.GA10069@redhat.com> <20120404102932.GA11918@redhat.com> <4F7D8FA6.3030402@redhat.com> <20120405123739.GI11204@redhat.com> <4F7D94B3.8090300@redhat.com> <20120405132653.GJ11204@redhat.com> <4F7D9E10.6070703@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=cp1255 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: shashank rachamalla , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:42364 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752193Ab2DENs7 convert rfc822-to-8bit (ORCPT ); Thu, 5 Apr 2012 09:48:59 -0400 Content-Disposition: inline In-Reply-To: <4F7D9E10.6070703@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Apr 05, 2012 at 04:28:48PM +0300, Avi Kivity wrote: > On 04/05/2012 04:26 PM, Gleb Natapov wrote: > > On Thu, Apr 05, 2012 at 03:48:51PM +0300, Avi Kivity wrote: > > > On 04/05/2012 03:37 PM, Gleb Natapov wrote: > > > > On Thu, Apr 05, 2012 at 03:27:18PM +0300, Avi Kivity wrote: > > > > > On 04/04/2012 01:29 PM, Gleb Natapov wrote: > > > > > > > > > > > > > > > ok. seems to be. will move over to perf as its working fi= ne inside guest. > > > > > > >=20 > > > > > > Good riddance IMO. I managed to run it on a guest (but not = on my > > > > > > host!). The thing is buggy. It does not use global ctrl MSR= to enable > > > > > > counters and kvm has all of them disabled by default. I did= n't find what > > > > > > value this MSR should have after reset, so this may be eith= er kvm bug or > > > > > > real BIOSes enable all counters in global ctrl MSR for PMUv= 1 > > > > > > compatibility. Doing "wrmsr 0x38f 0x70000000f" solves this = problem. The > > > > > > second problem is that oprofile reprogram PMU counters with= out > > > > > > disabling them first and this is explicitly prohibited by I= ntel SDM. > > > > > > The patch below solve that, but oprofile is the one who sho= uld be fixed. > > > > >=20 > > > > > Both should be fixed, there may be other profilers affected. > > > > >=20 > > > > Global ctrl msr issue I need to investigate further, but second= one is > > > > bug that should be fixed in oprofile. Intel spec clearly says: > > > > > > > > EN (Enable Counters) Flag (bit 22) =97 When set, performance c= ounting > > > > is enabled in the corresponding performance-monitoring counter= ; when > > > > clear, the corresponding counter is disabled. The event logic = unit > > > > for a UMASK must be disabled by setting IA32_PERFEVTSELx[bit 2= 2] =3D 0, > > > > before writing to IA32_PMCx. > > > > > > > > I suspect that on real HW they got wrong result too. It simply = subtly > > > > wrong, so it is not as noticeable as with kvm. > > > > > > >=20 > > > First, there is the standard Linus rant to never break userspace = (and > > We broke nothing. Oprofile is broken and never could have worked > > according to Intel spec. (It didn't manage to get any result from i= t on > > real CPU, but may be this is unrelated). >=20 > But it did work sometime in the past, I've used it. >=20 May be it used NMI based profiling. We should ask oprofile developers. As I said I am almost sure my inability to run it on a host is probably PEBKAC, although I ran the same script exactly on the host and the guest (the script is from the first email of this thread) > > > for us a guest kernel is userspace). Second, the Intel rule may = have > > > been added later (as preparation for a change in behaviour), so i= t may > > > actually work correctly on older hardware. > > >=20 > > May be (the rule is specified for MPUv1 BTW), but we emulate newer = HW, > > the one that spec describes and we report this in cpuid leaf 10. I > > highly doubt Intel would change CPU in a way that may make old soft= ware > > to work incorrectly on newer cpus. >=20 > The non-architectural PMU is version specific, so they could have mad= e > this change before arch PMU was introduced. >=20 So Table 18-11 section 18.4.4.3 Writing a PEBS Interrupt Service Routin= e has: For Processors based on Intel Core microarchitecture "Counters MUST be stopped before writing". "Must" is written in all caps in the spec. For NetBurst this is optiona= l. Really, I fail to see how this is not oprofile bug. -- Gleb.