From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Questing regarding KVM Guest PMU Date: Thu, 05 Apr 2012 16:28:48 +0300 Message-ID: <4F7D9E10.6070703@redhat.com> References: <20120403165850.GA20155@redhat.com> <20120404070435.GA10069@redhat.com> <20120404102932.GA11918@redhat.com> <4F7D8FA6.3030402@redhat.com> <20120405123739.GI11204@redhat.com> <4F7D94B3.8090300@redhat.com> <20120405132653.GJ11204@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: shashank rachamalla , kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27099 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716Ab2DEN2v (ORCPT ); Thu, 5 Apr 2012 09:28:51 -0400 In-Reply-To: <20120405132653.GJ11204@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 fine= 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 t= o enable > > > > > counters and kvm has all of them disabled by default. I didn'= t find what > > > > > value this MSR should have after reset, so this may be either= kvm bug or > > > > > real BIOSes enable all counters in global ctrl MSR for PMUv1 > > > > > compatibility. Doing "wrmsr 0x38f 0x70000000f" solves this pr= oblem. The > > > > > second problem is that oprofile reprogram PMU counters withou= t > > > > > disabling them first and this is explicitly prohibited by Int= el SDM. > > > > > The patch below solve that, but oprofile is the one who shoul= d 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 o= ne is > > > bug that should be fixed in oprofile. Intel spec clearly says: > > > > > > EN (Enable Counters) Flag (bit 22) =97 When set, performance cou= nting > > > is enabled in the corresponding performance-monitoring counter; = when > > > clear, the corresponding counter is disabled. The event logic un= it > > > for a UMASK must be disabled by setting IA32_PERFEVTSELx[bit 22]= =3D 0, > > > before writing to IA32_PMCx. > > > > > > I suspect that on real HW they got wrong result too. It simply su= btly > > > wrong, so it is not as noticeable as with kvm. > > > > >=20 > > First, there is the standard Linus rant to never break userspace (a= nd > We broke nothing. Oprofile is broken and never could have worked > according to Intel spec. (It didn't manage to get any result from it = on > real CPU, but may be this is unrelated). But it did work sometime in the past, I've used it. > > for us a guest kernel is userspace). Second, the Intel rule may ha= ve > > been added later (as preparation for a change in behaviour), so it = 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 softwa= re > to work incorrectly on newer cpus. The non-architectural PMU is version specific, so they could have made this change before arch PMU was introduced. --=20 error compiling committee.c: too many arguments to function