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

[Stefan Bader]

On 13.09.2012 11:55, Luis Henriques wrote:
> 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?

Right, for now it is basically doing what we were doing before (not allowing
XSAVE on EC2 guests). Just slightly different.

> 
> 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