Fwd: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors

[Luis Henriques]

Hi Stefan,

On Thu, Sep 13, 2012 at 10:33:43AM +0200, Stefan Bader wrote:
> I will not get to this is week. But this basically means that we can drop any
> xen work-around patches (even the ones I currently submitted for SRU) for
> kernels after 2.6.38 (which was the time Xen kernel code changed in a way that
> it would not test XSAVE capabilities by flipping the bit on in CR4 but looked at
> the CPU feature bits and apparently this will work better).
> 
> The work-around is not harmful, so it will be ok to leave things in for this
> stable cycle and then proceed in the next one. If there is a re-build required
> for any other reason then the new work-around might be dropped, too (keeping the
> revert of the old one). But I probably would not rush a re-build just for that.

According to this information and to your last comment in bug
#1044550:

* You've tested this workaround on EC2 instances without any issue
* Even if we'll be reverting this workaround in the future, it is
  (allegedly) harmless

Also, so far, we have no reasons to re-spin this kernel for this cycle.

Thus, it should be ok for us to tag bug #1044550 as verified.  Or are
there any concerns about this?  Brad?

Cheers,
--
Luis

> 
> -Stefan
> 
> 
> -------- Original Message --------
> Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
> Date: Mon, 10 Sep 2012 19:40:47 -0700
> From: Matt Wilson <msw at amazon.com>
> To: Justin M. Forbes <jmforbes at linuxtx.org>
> CC: Linux Kernel Mailing List <linux-kernel at vger.kernel.org>,        Konrad
> Rzeszutek Wilk <konrad.wilk at oracle.com>,        Stefan Bader
> <stefan.bader at canonical.com>,        Jan Beulich <JBeulich at suse.com>,
> xen-devel at lists.xen.org
> 
> On Fri, Sep 07, 2012 at 11:00:22AM -0500, Justin M. Forbes wrote:
> > On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> > > 
> > > All of this still doesn't provide evidence that a plain upstream
> > > kernel is actually having any problems in the first place. Further,
> > > if you say EC2 has a crippled hypervisor patch - is that patch
> > > available for looking at somewhere?
> > 
> > Yes, I can verify that a plain upstream kernel has problems in the first
> > place, which is why we are carrying a patch to simply disable xsave all
> > together in the pv guest.
> > EC2 is not carrying a patch to cripple the hypervisor, there was an old
> > xen bug that makes all this fail.  The correct fix for that bug is to
> > patch the hypervisor, but they have not done so. Upstream xen has had
> > the fix for quite some time, but that doesn't change the fact that a lot
> > of xen guest usage these days is on EC2.  This is no different than
> > putting in a quirk to work around a firmware bug in common use.
> 
> I've done some testing and have results that indicate otherwise. The
> out-of-tree xen_write_cr4() patch is not needed as of 2.6.39. I tested
> 3.2.21 on a machine that has XSAVE capabilities:
> 
> [ec2-user at ip-10-160-18-80 ~]$ cpuid -1 -i | grep -i xsave/xstor
>       XSAVE/XSTOR states                      = true
>       OS-enabled XSAVE/XSTOR                  = false
> 
> on an older hypervisor build:
> 
> [ec2-user at ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/major
> 3
> [ec2-user at ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/minor
> 0
> 
> and it boots without a problem. This patch correctly detects that the
> hypervisor supports XSAVE by testing for OSXSAVE:
> 
> commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
> Author:     Shan Haitao <haitao.shan at intel.com>
> AuthorDate: Tue Nov 9 11:43:36 2010 -0800
> Commit:     Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
> CommitDate: Wed Apr 6 08:31:13 2011 -0400
> 
>     xen: Allow PV-OPS kernel to detect whether XSAVE is supported
> 
>     Xen fails to mask XSAVE from the cpuid feature, despite not historically
>     supporting guest use of XSAVE.  However, now that XSAVE support has been
>     added to Xen, we need to reliably detect its presence.
> 
>     The most reliable way to do this is to look at the OSXSAVE feature in
>     cpuid which is set iff the OS (Xen, in this case), has set
>     CR4.OSXSAVE.
> 
> Matt
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> http://lists.xen.org/xen-devel
> 
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team