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

[Stefan Bader <stefan.bader@canonical.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3360 bytes --]

On 07.09.2012 16:54, Konrad Rzeszutek Wilk wrote:
>>> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
>>> something upstream that isn't upstream)?
>>>
>> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
>> currently carrying is not upstream because:
>>
>> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
>> users because xsave was never supported there.
>>
>> b) The hypervisor was patched to make it unnecessary quite some time ago,
>> and we hoped EC2 would eventually pick up that correct patch and we could
>> drop the crap kernel patch.
>>
>> Unfortunately this has not happened. We are at a point where EC2 really is
>> a quirk that has to be worked around. Distros do not want to maintain
>> a separate EC2 build of the kernel, so the easiest way is to cripple
>> current upstream xen users.  This quirk is unfortunately the best possible
>> solution.  Having it upstream also makes it possible for any user to build
>> an upstream kernel that will run on EC2 without having to dig a random
>> patch out of a vendor kernel.
> 
> Sure. Jan is asking though for actual confirmation that the upstream kernel
> does indeed go belly up without a workaround.
> And whether this patch (which I would did since Canonical is carrying it) does
> fix the issue.

It is really hard to tell. It might even be that all of the hosts on EC2 are now
upgraded. There might be different version around. Even back when the problem
was found it would not always happen.

So it is, still a bit hackish, an attempt to play safe. All that is known is
that there happened to be hosts running Xen 3.something which would do that.
Historical evidence might be:

commit 389a3c02496dd1b399bb0efd005e9fa2be24e9ee
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Tue Sep 18 22:46:33 2007 -0700

    xen: don't bother trying to set cr4

    Xen ignores all updates to cr4, and some versions will kill the domain if
    you try to change its value.  Just ignore all changes.

Of course this is ancient v2.6.23 and it was later relaxed to just filter out
some flags:

commit 2956a3511c8c5dccb1d4739ead17c7c3c23a24b7
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Mon May 26 23:31:04 2008 +0100

    xen: allow some cr4 updates

    The guest can legitimately change things like cr4.OSFXSR and
    OSXMMEXCPT, so let it.

But whether there are still hosts out there running a bad version of the HV is
hard to say. EC2 may or may not be the only case (or not at all anymore). For
upstream Linux it would be a valid decision either way. Not adding a quirk
because the use-case is so small. Or adding it because it avoids special patches
in distros and forcing those bits off on Xen 3 hosts is an acceptable drawback.

At least posting it here would allow those who carry the older more intrusive
hack to replace that. So we do not run again into that mess like when xsave was
half-disabled by guests with that patch and hosts supporting it.

> 
> I am still a newbie on the Amazon EC2 upload your kernel thing (hint, would
> appreciate somebody taking this patch and trying it out).
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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