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:57:55 +0300 Message-ID: <20120405135754.GL11204@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> <20120405134857.GK11204@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]:29475 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752193Ab2DEN55 convert rfc822-to-8bit (ORCPT ); Thu, 5 Apr 2012 09:57:57 -0400 Content-Disposition: inline In-Reply-To: <20120405134857.GK11204@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Apr 05, 2012 at 04:48:57PM +0300, Gleb Natapov wrote: > 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 = fine inside guest. > > > > > > > >=20 > > > > > > > Good riddance IMO. I managed to run it on a guest (but no= t on my > > > > > > > host!). The thing is buggy. It does not use global ctrl M= SR to enable > > > > > > > counters and kvm has all of them disabled by default. I d= idn't find what > > > > > > > value this MSR should have after reset, so this may be ei= ther kvm bug or > > > > > > > real BIOSes enable all counters in global ctrl MSR for PM= Uv1 > > > > > > > compatibility. Doing "wrmsr 0x38f 0x70000000f" solves thi= s problem. The > > > > > > > second problem is that oprofile reprogram PMU counters wi= thout > > > > > > > disabling them first and this is explicitly prohibited by= Intel SDM. > > > > > > > The patch below solve that, but oprofile is the one who s= hould be fixed. > > > > > >=20 > > > > > > Both should be fixed, there may be other profilers affected= =2E > > > > > >=20 > > > > > Global ctrl msr issue I need to investigate further, but seco= nd one is > > > > > bug that should be fixed in oprofile. Intel spec clearly says= : > > > > > > > > > > EN (Enable Counters) Flag (bit 22) =97 When set, performance= counting > > > > > is enabled in the corresponding performance-monitoring count= er; when > > > > > clear, the corresponding counter is disabled. The event logi= c unit > > > > > 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 simpl= y subtly > > > > > wrong, so it is not as noticeable as with kvm. > > > > > > > > >=20 > > > > First, there is the standard Linus rant to never break userspac= e (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= it 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= =2E > As I said I am almost sure my inability to run it on a host is probab= ly > PEBKAC, although I ran the same script exactly on the host and the > guest (the script is from the first email of this thread) >=20 After upgrading the kernel to latest git from whatever it was there the same script works and counts CPU_CLK_UNHALT events. -- Gleb.