[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 0/3] VPMU fixes



> From: Boris Ostrovsky [mailto:boris.ostrovsky@xxxxxxxxxx]
> Sent: Thursday, December 03, 2015 11:45 PM
> 
> On 12/03/2015 06:02 AM, Jan Beulich wrote:
> >>>> On 03.12.15 at 11:46, <kevin.tian@xxxxxxxxx> wrote:
> >>>   From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >>> Sent: Thursday, December 03, 2015 6:36 PM
> >>>
> >>>>>> On 03.12.15 at 07:16, <kevin.tian@xxxxxxxxx> wrote:
> >>>>>   From: Dietmar Hahn [mailto:dietmar.hahn@xxxxxxxxxxxxxx]
> >>>>> Sent: Wednesday, December 02, 2015 5:21 PM
> >>>>>
> >>>>> Am Mittwoch 02 Dezember 2015, 02:20:49 schrieb Tian, Kevin:
> >>>>>>> From: Boris Ostrovsky [mailto:boris.ostrovsky@xxxxxxxxxx]
> >>>>>>> Sent: Wednesday, December 02, 2015 12:50 AM
> >>>>>>>
> >>>>>>> * Limit VPMU support to PMU versions 2, 3 and 4 (emulated at version 3
> >> level)
> >>>>>>> * Always implement family 6 VPMU quirk.
> >>>>>>>    ==>  Intel folks: is the quirk needed for all family 6 processors 
> >>>>>>> or can
> >> we
> >>>>>>>                      limit it to certain models?
> >>>>>> Let me confirm this information internally. btw could you provide a 
> >>>>>> link
> >>>>>> where you find out the original quirk information?
> >>>>> http://old-list-archives.xenproject.org/xen-devel/2010-11/msg01157.html
> >>>>> Dietmar.
> >>>> Looks there's no formal errata recorded from original thread. Since the
> >>>> patch sustains original behavior, I'm OK with this assumption.
> >>> Except that the Link Dietmar provided makes it even more
> >>> likely that this could be limited to certain models (since in that
> >>> original patch version it covered just two). See also the vague
> >>> statement in 75a92f551a ("Currently only a few Intel models
> >>> have VPMU workaround turned on. It").
> >> Well, I'm not sure about the whole history. If you look at Boris's
> >> patch, the code already assumes quirk for all family 6 before his
> >> change.
> > That's why I was referring you to the older patch (also by him),
> > which converted from a model specific workaround to a universal
> > one.
> >
> 
> These are two threads that are related to 75a92f551a:
> http://lists.xenproject.org/archives/html/xen-devel/2013-05/msg01054.html
> and
> http://lists.xen.org/archives/html/xen-devel/2013-03/msg00998.html
> 
> The latter describes the actual problem that lead us to believe that the
> set of models that the original quirk covered was not enough. There was
> a suggestion that adding 43 (or 45) would be sufficient but then Konrad
> (who originally reported this) started hitting other problems and in the
> end it seems like we ended up with 75a92f551a as being the safest
> approach since Intel could not definitively confirm right set of models.
> 

I can help do another check with our HW guys. But I won't gate this
patch series being that:

- Looks there's no formal errata on this issue and my previous colleague 
(Haitao) didn't get it answered after his trying.

- We've using this safe approach for all family 6 models since 2013.

Thanks
Kevin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.