All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Cc: Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH] vpmu intel: Add dumping vpmu infos in 'q' keyhandler
Date: Mon, 25 Mar 2013 10:47:17 -0400	[thread overview]
Message-ID: <20130325144717.GA15129@phenom.dumpdata.com> (raw)
In-Reply-To: <1365941.PJBONSDnbW@amur>

On Wed, Mar 20, 2013 at 07:41:10AM +0100, Dietmar Hahn wrote:
> Am Donnerstag 14 März 2013, 10:36:25 schrieb Dietmar Hahn:
> > 
> > This patch extends the printout of the VPCU infos of the keyhandler 'q'.
> > If vPMU is enabled is on the VCPU and active a line is printed like;
> > (XEN)     vPMU running: fixed=0x2 general=0x1
> > 
> > This means from the fixed counters the counter 3 and the general
> > counter 1 are enabled.
> > As example this picture happens on linux-3.4.6 with watchdog and 'perf top'.
> > This patch supports only Intel as I don't have Amd machines.
> > Thanks.
> > 
> > Dietmar.
> 
> Ping?
>  
> > Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> > 
> > diff -r a6b81234b189 xen/arch/x86/domain.c
> > --- a/xen/arch/x86/domain.c	Mon Mar 11 16:13:42 2013 +0000
> > +++ b/xen/arch/x86/domain.c	Thu Mar 14 10:25:49 2013 +0100
> > @@ -2093,6 +2093,9 @@ void arch_dump_domain_info(struct domain
> >  void arch_dump_vcpu_info(struct vcpu *v)
> >  {
> >      paging_dump_vcpu_info(v);
> > +
> > +    if ( is_hvm_vcpu(v) )
> > +        vpmu_dump(v);
> >  }
> >  
> >  void domain_cpuid(
> > diff -r a6b81234b189 xen/arch/x86/hvm/vmx/vpmu_core2.c
> > --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Mar 11 16:13:42 2013 +0000
> > +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Thu Mar 14 10:25:49 2013 +0100
> > @@ -611,6 +611,41 @@ static void core2_vpmu_do_cpuid(unsigned
> >      }
> >  }
> >  
> > +static void core2_vpmu_dump(struct vcpu *v)
> > +{
> > +    struct vpmu_struct *vpmu = vcpu_vpmu(v);
> > +    int i, num, fixed, general;
> > +    struct core2_vpmu_context *core2_vpmu_cxt = NULL;
> > +
> > +    if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> > +         return;
> > +
> > +    if ( !vpmu_is_set(vpmu, VPMU_RUNNING) )
> > +    {
> > +        if ( vpmu_set(vpmu, VPMU_CONTEXT_LOADED) )
> > +            printk("    vPMU loaded\n");
> > +        else
> > +            printk("    vPMU allocated\n");
> > +        return;
> > +    }
> > +
> > +    core2_vpmu_cxt = vpmu->context;
> > +    num = core2_get_pmc_count();
> > +    general = 0;
> > +    for ( i = 0; i < num; i++ )
> > +    {
> > +        if ( core2_vpmu_cxt->pmu_enable->arch_pmc_enable[i] )
> > +            general |= 1 << i;
> > +    }
> > +    fixed = 0;
> > +    for ( i = 0; i < 3; i++ )

3? What if there are more? Ah, wait. The code can only do 3!
Perhaps another extra patch that makes this a #define in case the
CPU can do more in the future?

> > +    {
> > +        if ( core2_vpmu_cxt->pmu_enable->fixed_ctr_enable[i] )
> > +            fixed |= 1 << i;
> > +    }
> > +    printk("    vPMU running: fixed=0x%x general=0x%x\n", fixed, general);

Would it also make sense to print the contents of the MSR?

And also the global counter enable and the overflow one?
> > +}
> > +
> >  static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
> >  {
> >      struct vcpu *v = current;
> > @@ -724,7 +759,8 @@ struct arch_vpmu_ops core2_vpmu_ops = {
> >      .do_cpuid = core2_vpmu_do_cpuid,
> >      .arch_vpmu_destroy = core2_vpmu_destroy,
> >      .arch_vpmu_save = core2_vpmu_save,
> > -    .arch_vpmu_load = core2_vpmu_load
> > +    .arch_vpmu_load = core2_vpmu_load,
> > +    .arch_vpmu_dump = core2_vpmu_dump
> >  };
> >  
> >  int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
> > diff -r a6b81234b189 xen/arch/x86/hvm/vpmu.c
> > --- a/xen/arch/x86/hvm/vpmu.c	Mon Mar 11 16:13:42 2013 +0000
> > +++ b/xen/arch/x86/hvm/vpmu.c	Thu Mar 14 10:25:49 2013 +0100
> > @@ -157,3 +157,12 @@ void vpmu_destroy(struct vcpu *v)
> >          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
> >  }
> >  
> > +/* Dump some vpmu informations on console. Used in keyhandler dump_domains(). */
> > +void vpmu_dump(struct vcpu *v)
> > +{
> > +    struct vpmu_struct *vpmu = vcpu_vpmu(v);
> > +
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_dump )
> > +        vpmu->arch_vpmu_ops->arch_vpmu_dump(v);
> > +}
> > +
> > diff -r a6b81234b189 xen/include/asm-x86/hvm/vpmu.h
> > --- a/xen/include/asm-x86/hvm/vpmu.h	Mon Mar 11 16:13:42 2013 +0000
> > +++ b/xen/include/asm-x86/hvm/vpmu.h	Thu Mar 14 10:25:49 2013 +0100
> > @@ -54,6 +54,7 @@ struct arch_vpmu_ops {
> >      void (*arch_vpmu_destroy)(struct vcpu *v);
> >      void (*arch_vpmu_save)(struct vcpu *v);
> >      void (*arch_vpmu_load)(struct vcpu *v);
> > +    void (*arch_vpmu_dump)(struct vcpu *v);
> >  };
> >  
> >  int vmx_vpmu_initialise(struct vcpu *, unsigned int flags);
> > @@ -87,6 +88,7 @@ void vpmu_initialise(struct vcpu *v);
> >  void vpmu_destroy(struct vcpu *v);
> >  void vpmu_save(struct vcpu *v);
> >  void vpmu_load(struct vcpu *v);
> > +void vpmu_dump(struct vcpu *v);
> >  
> >  extern int acquire_pmu_ownership(int pmu_ownership);
> >  extern void release_pmu_ownership(int pmu_ownership);
> > 
> > 
> -- 
> Company details: http://ts.fujitsu.com/imprint.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

  reply	other threads:[~2013-03-25 14:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14  9:36 [PATCH] vpmu intel: Add dumping vpmu infos in 'q' keyhandler Dietmar Hahn
2013-03-20  6:41 ` Dietmar Hahn
2013-03-25 14:47   ` Konrad Rzeszutek Wilk [this message]
2013-03-26  8:02     ` Dietmar Hahn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130325144717.GA15129@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=dietmar.hahn@ts.fujitsu.com \
    --cc=eddie.dong@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.