Re: Questing regarding KVM Guest PMU

[Gleb Natapov <gleb@redhat.com>]

On Sun, Apr 08, 2012 at 06:27:03PM +0300, Gleb Natapov wrote:
> On Fri, Apr 06, 2012 at 09:50:50AM +0300, Gleb Natapov wrote:
> > On Fri, Apr 06, 2012 at 10:43:17AM +0530, shashank rachamalla wrote:
> > > On Thu, Apr 5, 2012 at 8:11 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > > > On Thu, Apr 05, 2012 at 05:38:40PM +0300, Avi Kivity wrote:
> > > >> On 04/05/2012 04:57 PM, Gleb Natapov wrote:
> > > >> > > >
> > > >> > > 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)
> > > >> > >
> > > >> > After upgrading the kernel to latest git from whatever it was there the
> > > >> > same script works and counts CPU_CLK_UNHALT events.
> > > >> >
> > > >>
> > > >> This is even while it violates the Intel guidelines?
> > > >>
> > > > Yes, but who says the result is correct :) It seems that we handle
> > > > global ctrl msr wrong. That is counter can be enabled either in global
> > > > ctrl or in eventsel. Trying to confirm that.
> > > >
> > > if that becomes true then will global ctrl msr have any significance ?
> > When it is in use yes.
> > 
> I was wrong. We do handle global ctrl msr correctly, I just ran my test
> incorrectly. If I disable global ctrl on all cpus (for i in `seq 0 15`;
> do wrmsr -p $i 0x38f 0; done) oprofile stops working.
> 
After searching high and low I finally found the following in
"Performance Monitoring Unit Sharing Guide" white paper:

  Known starting state: Software requires a known starting
  state. After CPU reset, all counters and control registers are
  disabled and clear/reset to 0.  The only exception to this is the
  IA32_PERF_GLOBAL_CTRL control MSR, all programmable counter global
  enable bits are reset to 1.

Patch will follow.

--
			Gleb.