Xen devel - May 2013 - [PATCH] Intel/vpmu: Use Intel VPMU quirk on all family 6 processors

Currently only a few Intel models have VPMU workaround turned on. It
appears, however, that this issue exists on more models than what is
covered by check_pmc_quirk(). Since we don''t know exactly which cpus
are affected we should turn this workaround on for all family 6
processors.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 9f152b4..15b2036 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -65,8 +65,7 @@
 #define PMU_FIXED_WIDTH_MASK     (((1 << PMU_FIXED_WIDTH_BITS) -1)
<< PMU_FIXED_WIDTH_SHIFT)
 
 /*
- * QUIRK to workaround an issue on Nehalem processors currently seen
- * on family 6 cpus E5520 (model 26) and X7542 (model 46).
+ * QUIRK to workaround an issue on various family 6 cpus.
  * The issue leads to endless PMC interrupt loops on the processor.
  * If the interrupt handler is running and a pmc reaches the value 0, this
  * value remains forever and it triggers immediately a new interrupt after
@@ -79,15 +78,10 @@ bool_t __read_mostly is_pmc_quirk;
 
 static void check_pmc_quirk(void)
 {
-    u8 family = current_cpu_data.x86;
-    u8 cpu_model = current_cpu_data.x86_model;
-    is_pmc_quirk = 0;
-    if ( family == 6 )
-    {
-        if ( cpu_model == 47 || cpu_model == 46 || cpu_model == 42 ||
-             cpu_model == 26 )
-            is_pmc_quirk = 1;
-    }
+    if ( current_cpu_data.x86 == 6 )
+        is_pmc_quirk = 1;
+    else
+        is_pmc_quirk = 0;    
 }
 
 static int core2_get_pmc_count(void);
-- 
1.8.1.4

On 05/09/2013 04:34 PM, Boris Ostrovsky wrote:
> Currently only a few Intel models have VPMU workaround turned on. It
> appears, however, that this issue exists on more models than what is
> covered by check_pmc_quirk(). Since we don''t know exactly which
cpus
> are affected we should turn this workaround on for all family 6
> processors.
Haitao,

A few weeks ago we had an email thread about this issue
(http://lists.xen.org/archives/html/xen-devel/2013-03/msg02618.html)
Did you have a chance to clarify with your HW folks what this is?

We kept hitting this on various models which is why I am suggesting this
patch (and I think it should be considered for 4.3).

-boris

>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>   xen/arch/x86/hvm/vmx/vpmu_core2.c | 16 +++++-----------
>   1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> index 9f152b4..15b2036 100644
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
> @@ -65,8 +65,7 @@
>   #define PMU_FIXED_WIDTH_MASK     (((1 << PMU_FIXED_WIDTH_BITS) -1)
<< PMU_FIXED_WIDTH_SHIFT)
>   
>   /*
> - * QUIRK to workaround an issue on Nehalem processors currently seen
> - * on family 6 cpus E5520 (model 26) and X7542 (model 46).
> + * QUIRK to workaround an issue on various family 6 cpus.
>    * The issue leads to endless PMC interrupt loops on the processor.
>    * If the interrupt handler is running and a pmc reaches the value 0,
this
>    * value remains forever and it triggers immediately a new interrupt
after
> @@ -79,15 +78,10 @@ bool_t __read_mostly is_pmc_quirk;
>   
>   static void check_pmc_quirk(void)
>   {
> -    u8 family = current_cpu_data.x86;
> -    u8 cpu_model = current_cpu_data.x86_model;
> -    is_pmc_quirk = 0;
> -    if ( family == 6 )
> -    {
> -        if ( cpu_model == 47 || cpu_model == 46 || cpu_model == 42 ||
> -             cpu_model == 26 )
> -            is_pmc_quirk = 1;
> -    }
> +    if ( current_cpu_data.x86 == 6 )
> +        is_pmc_quirk = 1;
> +    else
> +        is_pmc_quirk = 0;
>   }
>   
>   static int core2_get_pmc_count(void);

On Thu, May 9, 2013 at 9:45 PM, Boris Ostrovsky
<boris.ostrovsky@oracle.com> wrote:
> On 05/09/2013 04:34 PM, Boris Ostrovsky wrote:
>>
>> Currently only a few Intel models have VPMU workaround turned on. It
>> appears, however, that this issue exists on more models than what is
>> covered by check_pmc_quirk(). Since we don''t know exactly
which cpus
>> are affected we should turn this workaround on for all family 6
>> processors.
>
>
> Haitao,
>
> A few weeks ago we had an email thread about this issue
> (http://lists.xen.org/archives/html/xen-devel/2013-03/msg02618.html)
> Did you have a chance to clarify with your HW folks what this is?
>
> We kept hitting this on various models which is why I am suggesting this
> patch (and I think it should be considered for 4.3).
In principle it''s a bug fix, and fine for 4.3.  But it would be good
to get some feedback from someone at Intel.

 -George

>>> On 10.05.13 at 11:46, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Thu, May 9, 2013 at 9:45 PM, Boris Ostrovsky
> <boris.ostrovsky@oracle.com> wrote:
>> On 05/09/2013 04:34 PM, Boris Ostrovsky wrote:
>>>
>>> Currently only a few Intel models have VPMU workaround turned on.
It
>>> appears, however, that this issue exists on more models than what
is
>>> covered by check_pmc_quirk(). Since we don''t know exactly
which cpus
>>> are affected we should turn this workaround on for all family 6
>>> processors.
>>
>>
>> Haitao,
>>
>> A few weeks ago we had an email thread about this issue
>> (http://lists.xen.org/archives/html/xen-devel/2013-03/msg02618.html)
>> Did you have a chance to clarify with your HW folks what this is?
>>
>> We kept hitting this on various models which is why I am suggesting
this
>> patch (and I think it should be considered for 4.3).
> 
> In principle it''s a bug fix, and fine for 4.3.  But it would be
good
> to get some feedback from someone at Intel.
Intel, anyone???

Thanks, Jan

On 05/16/2013 08:30 AM, Jan Beulich wrote:
>>>> On 10.05.13 at 11:46, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
>> On Thu, May 9, 2013 at 9:45 PM, Boris Ostrovsky
>> <boris.ostrovsky@oracle.com> wrote:
>>> On 05/09/2013 04:34 PM, Boris Ostrovsky wrote:
>>>> Currently only a few Intel models have VPMU workaround turned
on. It
>>>> appears, however, that this issue exists on more models than
what is
>>>> covered by check_pmc_quirk(). Since we don''t know
exactly which cpus
>>>> are affected we should turn this workaround on for all family 6
>>>> processors.
>>>
>>> Haitao,
>>>
>>> A few weeks ago we had an email thread about this issue
>>>
(http://lists.xen.org/archives/html/xen-devel/2013-03/msg02618.html)
>>> Did you have a chance to clarify with your HW folks what this is?
>>>
>>> We kept hitting this on various models which is why I am suggesting
this
>>> patch (and I think it should be considered for 4.3).
>> In principle it''s a bug fix, and fine for 4.3.  But it would
be good
>> to get some feedback from someone at Intel.
> Intel, anyone???
>
> Thanks, Jan
>
I haven''t seen any responses from Intel folks about this issue.

Do we wait for post-4.3?

-boris

On 05/30/2013 05:33 PM, Boris Ostrovsky wrote:
> On 05/16/2013 08:30 AM, Jan Beulich wrote:
>>>>> On 10.05.13 at 11:46, George Dunlap
<George.Dunlap@eu.citrix.com>
>>>>> wrote:
>>> On Thu, May 9, 2013 at 9:45 PM, Boris Ostrovsky
>>> <boris.ostrovsky@oracle.com> wrote:
>>>> On 05/09/2013 04:34 PM, Boris Ostrovsky wrote:
>>>>> Currently only a few Intel models have VPMU workaround
turned on. It
>>>>> appears, however, that this issue exists on more models
than what is
>>>>> covered by check_pmc_quirk(). Since we don''t know
exactly which cpus
>>>>> are affected we should turn this workaround on for all
family 6
>>>>> processors.
>>>>
>>>> Haitao,
>>>>
>>>> A few weeks ago we had an email thread about this issue
>>>>
(http://lists.xen.org/archives/html/xen-devel/2013-03/msg02618.html)
>>>> Did you have a chance to clarify with your HW folks what this
is?
>>>>
>>>> We kept hitting this on various models which is why I am
suggesting
>>>> this
>>>> patch (and I think it should be considered for 4.3).
>>> In principle it''s a bug fix, and fine for 4.3.  But it
would be good
>>> to get some feedback from someone at Intel.
>> Intel, anyone???
>>
>> Thanks, Jan
>>
>
> I haven''t seen any responses from Intel folks about this issue.
>
> Do we wait for post-4.3?
Our goals at this point:
- Bug-free release
- Awesome release
- On-time release

I take it that the main risk here is that vcpu for some models which 
would have otherwise worked will not work anymore?

But at his point you *know* many models which don''t work without it; so
on the whole I''m inclined to say that it''s an
"accept" on the
cost/benefits analysis.

  -George

>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 05/30/13 6:32 PM
>>>
>On 05/16/2013 08:30 AM, Jan Beulich wrote:
>> Intel, anyone???
>
>I haven''t seen any responses from Intel folks about this issue.
>
>Do we wait for post-4.3?
I''d commit this whenever we get an ack.

Jan

On 05/30/2013 12:38 PM, George Dunlap wrote:
> On 05/30/2013 05:33 PM, Boris Ostrovsky wrote:
>> On 05/16/2013 08:30 AM, Jan Beulich wrote:
>>>>>> On 10.05.13 at 11:46, George Dunlap
<George.Dunlap@eu.citrix.com>
>>>>>> wrote:
>>>> On Thu, May 9, 2013 at 9:45 PM, Boris Ostrovsky
>>>> <boris.ostrovsky@oracle.com> wrote:
>>>>> On 05/09/2013 04:34 PM, Boris Ostrovsky wrote:
>>>>>> Currently only a few Intel models have VPMU workaround
turned on. It
>>>>>> appears, however, that this issue exists on more models
than what is
>>>>>> covered by check_pmc_quirk(). Since we don''t
know exactly which cpus
>>>>>> are affected we should turn this workaround on for all
family 6
>>>>>> processors.
>>>>>
>>>>> Haitao,
>>>>>
>>>>> A few weeks ago we had an email thread about this issue
>>>>>
(http://lists.xen.org/archives/html/xen-devel/2013-03/msg02618.html)
>>>>> Did you have a chance to clarify with your HW folks what
this is?
>>>>>
>>>>> We kept hitting this on various models which is why I am
suggesting
>>>>> this
>>>>> patch (and I think it should be considered for 4.3).
>>>> In principle it''s a bug fix, and fine for 4.3.  But it
would be good
>>>> to get some feedback from someone at Intel.
>>> Intel, anyone???
>>>
>>> Thanks, Jan
>>>
>>
>> I haven''t seen any responses from Intel folks about this
issue.
>>
>> Do we wait for post-4.3?
>
> Our goals at this point:
> - Bug-free release
> - Awesome release
> - On-time release
>
> I take it that the main risk here is that vcpu for some models which 
> would have otherwise worked will not work anymore?
(I assume you meant vpmu, not vcpu). Yes, that would be the main risk.


-boris
>
> But at his point you *know* many models which don''t work without
it;
> so on the whole I''m inclined to say that it''s an
"accept" on the
> cost/benefits analysis.
>
>  -George

Working on getting people''s attention, I hope to have a response by
tomorrow.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786


-----Original Message-----
From: Jan Beulich [mailto:jbeulich@suse.com] 
Sent: Thursday, May 30, 2013 10:44 AM
To: boris.ostrovsky@oracle.com
Cc: George.Dunlap@eu.citrix.com; maillists.shan@gmail.com; Dugger, Donald D;
Dong, Eddie; Nakajima, Jun; xen-devel@lists.xensource.com;
konrad.wilk@oracle.com; dietmar.hahn@ts.fujitsu.com
Subject: Re: [Xen-devel] [PATCH] Intel/vpmu: Use Intel VPMU quirk on all family
6 processors
>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> 05/30/13 6:32 PM
>>>
>On 05/16/2013 08:30 AM, Jan Beulich wrote:
>> Intel, anyone???
>
>I haven''t seen any responses from Intel folks about this issue.
>
>Do we wait for post-4.3?
I''d commit this whenever we get an ack.

Jan

Jan, George, et. al.,



Regarding the recent discussion on "[Xen-devel] [PATCH] Intel/vpmu: Use
Intel VPMU quirk on all family 6 processors" I believe that
George''s suggestion is the proper approach for Xen 4.3. Extending the
check_pmc_quirk() to return true for all P6 family processors may be overkill
but should cover the issue until we have a better handle on it.



Internally, we are beginning some characterization work but the outcome is
uncertain and is likely to take some time. In addition it is unlikely to
materially change current issues. So regardless of the outcome, if any, we
should move forward with the expanded coverage in check_pmc_quirk().



Thanks,



Will





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

>>> On 31.05.13 at 05:53, "Auld, Will"
<will.auld@intel.com> wrote:
> Regarding the recent discussion on "[Xen-devel] [PATCH] Intel/vpmu:
Use Intel
> VPMU quirk on all family 6 processors" I believe that
George''s suggestion is
> the proper approach for Xen 4.3. Extending the check_pmc_quirk() to return 
> true for all P6 family processors may be overkill but should cover the
issue
> until we have a better handle on it.
> 
> Internally, we are beginning some characterization work but the outcome is 
> uncertain and is likely to take some time. In addition it is unlikely to 
> materially change current issues. So regardless of the outcome, if any, we 
> should move forward with the expanded coverage in check_pmc_quirk().
Thanks Will.

Jun, Eddie - I take it that this was internally to Intel agreed upon,
and hence I''ll go ahead and commit the patch without an explicit
ack from either of you. If this is a problem, we''ll have to revert...

Jan

Jan, 

Jun, Eddie and I are all in the same team. I''m the new comer but
I''ve been in the team for about a year and a half now.

Thanks,

Will
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, May 31, 2013 1:04 AM
> To: Dong, Eddie; Nakajima, Jun; Auld, Will
> Cc: George.Dunlap@eu.citrix.com; Dugger, Donald D; Shan, Haitao; xen-
> devel; boris.ostrovsky@oracle.com
> Subject: RE: [Xen-devel] [PATCH] Intel/vpmu: Use Intel VPMU quirk on
> all family 6 processors
> 
> >>> On 31.05.13 at 05:53, "Auld, Will"
<will.auld@intel.com> wrote:
> > Regarding the recent discussion on "[Xen-devel] [PATCH]
Intel/vpmu:
> > Use Intel VPMU quirk on all family 6 processors" I believe that
> > George''s suggestion is the proper approach for Xen 4.3.
Extending the
> > check_pmc_quirk() to return true for all P6 family processors may be
> > overkill but should cover the issue until we have a better handle on
> it.
> >
> > Internally, we are beginning some characterization work but the
> > outcome is uncertain and is likely to take some time. In addition it
> > is unlikely to materially change current issues. So regardless of the
> > outcome, if any, we should move forward with the expanded coverage in
> check_pmc_quirk().
> 
> Thanks Will.
> 
> Jun, Eddie - I take it that this was internally to Intel agreed upon,
> and hence I''ll go ahead and commit the patch without an explicit
ack
> from either of you. If this is a problem, we''ll have to revert...
> 
> Jan