From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulanit Subject: Re: [PATCH 3/8] x86/AMD: Read VPMU MSRs from context when it is not loaded into HW Date: Wed, 19 Jun 2013 17:56:19 -0500 Message-ID: <51C23713.6020301@amd.com> References: <1365528379-2516-1-git-send-email-boris.ostrovsky@oracle.com> <1365528379-2516-4-git-send-email-boris.ostrovsky@oracle.com> <5167004B.2000905@amd.com> <51670247.1090409@oracle.com> <20130416154151.GD2799@phenom.dumpdata.com> <20130416171216.GA18385@jshin-Toonie> <20130416183644.GE9417@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4570617640364752409==" Return-path: In-Reply-To: <20130416183644.GE9417@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , Boris Ostrovsky Cc: "haitao.shan@intel.com" , "Shin, Jacob" , "dietmar.hahn@ts.fujitsu.com" , "jun.nakajima@intel.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============4570617640364752409== Content-Type: multipart/alternative; boundary="------------010306050309020502040801" --------------010306050309020502040801 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 4/16/2013 1:36 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 16, 2013 at 12:12:16PM -0500, Jacob Shin wrote: > > On Tue, Apr 16, 2013 at 11:41:51AM -0400, Konrad Rzeszutek Wilk wrote: > > > On Thu, Apr 11, 2013 at 02:34:47PM -0400, Boris Ostrovsky wrote: > > > > On 04/11/2013 02:26 PM, Suravee Suthikulpanit wrote: > > > > >Boris, > > > > > > > > > >I tried booting the guest HVM after the patch, I still see PERF > > > > >only working in Software mode only. I'll look more into this. > > > > > > > > You may need to declare proper CPUID bits in the config file. On > > > > fam15h I have > > > > > > > > cpuid=['0x80000001:ecx=00000001101000011000101111110011'] > > > > > > Would it be possible to write somewhere this magic incantention? > > > > > > Perhaps in the xl.cfg.pod.5 ? > > > > > > (This of course being a different patch). > > > > > > > Well, maybe we should turn it on by default? > > > > http://lists.xen.org/archives/html/xen-devel/2013-04/msg01028.html: > > > > diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c > > index 17efc0f..c269468 100644 > > --- a/tools/libxc/xc_cpuid_x86.c > > +++ b/tools/libxc/xc_cpuid_x86.c > > @@ -112,6 +112,7 @@ static void amd_xc_cpuid_policy( > > bitmaskof(X86_FEATURE_XOP) | > > bitmaskof(X86_FEATURE_FMA4) | > > bitmaskof(X86_FEATURE_TBM) | > > + bitmaskof(X86_FEATURE_PERFCTR_CORE) | > > bitmaskof(X86_FEATURE_LWP)); > > regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */ > > (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) | > > > > Or maybe not since vpmu is not on by default .. ? > > I would say not yet. As the vpmu=1 (at least on Intel) has some issues. > Until that is fixed and vpmu=1 is by default lets leave it as so. > > > > Konrad, Boris: I would like to ask you to reconsider accepting this patch for 4.3. This bit and vpmu=1 are independent of each other. Without vpmu=1 option, PERF in HVM guest will not work regardless of this bit. So, it should be safe to always setting this bit. However, if user set vpmu=1 and not _manually_ setting this bit, the PERF logic will break and users will be getting incorrect result. The bit is currently used in the Linux PERF logic for all family15h to tell that there are 6 counters instead of 4 counters (when bit the is not set). Also, it will be using a different set of event constrain. The current Linux PERF core PMU logic assume that this bit will always be available. Suravee --------------010306050309020502040801 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 4/16/2013 1:36 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Apr 16, 2013 at 12:12:16PM -0500, Jacob Shin wrote:
> On Tue, Apr 16, 2013 at 11:41:51AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Apr 11, 2013 at 02:34:47PM -0400, Boris Ostrovsky wrote:
> > > On 04/11/2013 02:26 PM, Suravee Suthikulpanit wrote:
> > > >Boris,
> > > >
> > > >I tried booting the guest HVM after the patch, I still see PERF
> > > >only working in Software mode only.  I'll look more into this.
> > >
> > > You may need to declare proper CPUID bits in the config file. On
> > > fam15h I have
> > >
> > > cpuid=['0x80000001:ecx=00000001101000011000101111110011']
> >
> > Would it be possible to write somewhere this magic incantention?
> >
> > Perhaps in the xl.cfg.pod.5 ?
> >
> > (This of course being a different patch).
> >
>
> Well, maybe we should turn it on by default?
>
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg01028.html:
>
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index 17efc0f..c269468 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -112,6 +112,7 @@ static void amd_xc_cpuid_policy(
>                       bitmaskof(X86_FEATURE_XOP) |
>                       bitmaskof(X86_FEATURE_FMA4) |
>                       bitmaskof(X86_FEATURE_TBM) |
> +                    bitmaskof(X86_FEATURE_PERFCTR_CORE) |
>                       bitmaskof(X86_FEATURE_LWP));
> regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
>                       (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
>
> Or maybe not since vpmu is not on by default .. ?

I would say not yet. As the vpmu=1 (at least on Intel) has some issues.
Until that is fixed and vpmu=1 is by default lets leave it as so.

> 

Konrad, Boris:
I would like to ask you to reconsider accepting this patch for 4.3. 

This bit and vpmu=1 are independent of each other.  Without vpmu=1 option, PERF in HVM guest
will not work regardless of this bit. So, it should be safe to always setting this bit.
However, if user set vpmu=1 and not _manually_ setting this bit, the PERF logic will 
break and users will be getting incorrect result.

The bit is currently used in the Linux PERF logic for all family15h to
tell that there are 6 counters instead of 4 counters (when bit the is not set).
Also, it will be using a different set of event constrain. The current Linux PERF 
core PMU logic assume that this bit will always be available.

Suravee
 
--------------010306050309020502040801-- --===============4570617640364752409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4570617640364752409==--