All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Justin M. Forbes" <jmforbes@linuxtx.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stefan Bader <stefan.bader@canonical.com>,
	Matt Wilson <msw@amazon.com>,
	xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
Date: Fri, 7 Sep 2012 09:22:51 -0500	[thread overview]
Message-ID: <20120907142251.GA20096@linuxtx.org> (raw)
In-Reply-To: <504A1A950200007800099D4C@nat28.tlf.novell.com>

On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> > On 07.09.2012 14:33, Jan Beulich wrote:
> >>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>> When writing unsupported flags into CR4 (for some time the
> >>> xen_write_cr4 function would refuse to do anything at all)
> >>> older Xen hypervisors (and patch can potentially be improved
> >>> by finding out what older means in version numbers) would
> >>> crash the guest.
> >>>
> >>> Since Amazon EC2 would at least in the past be affected by that,
> >>> Fedora and Ubuntu were carrying a hack that would filter out
> >>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> >>> PV guest, even those running on a newer HV.
> >>>
> >>> And this recently caused trouble because some user-space was
> >>> only partially checking (or maybe only looking at the cpuid
> >>> bits) and then trying to use xsave even though the OS support
> >>> was not set.
> >>>
> >>> So I came up with a patch that would
> >>> - limit the work-around to certain Xen versions
> >>> - prevent the write to CR4 by unsetting xsave and osxsave in
> >>>   the cpuid bits
> >>>
> >>> Doing things that way may actually allow this to be acceptable
> >>> upstream, so I am sending it around, now.
> >>> It probably could be improved when knowing the exact version
> >>> to test for but otherwise should allow to work around the guest
> >>> crash while not preventing xsave on Xen 4.x and newer hosts.
> >> 
> >> Before considering a hack like this, I'd really like to see evidence
> >> of the described behavior with an upstream kernel (i.e. not one
> >> with that known broken hack patched in, which has never been
> >> upstream afaict).
> > 
> > This is the reason I wrote that Fedora and Ubuntu were carrying it. It never 
> > has
> > been send upstream (the other version) because it would filter the CR4 write 
> > for
> > any PV guest regardless of host version.
> 
> 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.

Justin

  reply	other threads:[~2012-09-07 14:23 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-07 11:40 [PATCH/RFC] Fix xsave bug on older Xen hypervisors Stefan Bader
2012-09-07 12:33 ` [Xen-devel] " Jan Beulich
2012-09-07 13:21   ` Stefan Bader
2012-09-07 14:02     ` Jan Beulich
2012-09-07 14:02     ` [Xen-devel] " Jan Beulich
2012-09-07 14:22       ` Justin M. Forbes [this message]
2012-09-07 14:54         ` Konrad Rzeszutek Wilk
2012-09-07 15:43           ` Stefan Bader
2012-09-08 10:18           ` [Xen-devel] " Paolo Bonzini
2012-09-08 10:18           ` Paolo Bonzini
2012-09-10 22:36           ` Matt Wilson
2012-09-10 22:36           ` [Xen-devel] " Matt Wilson
2012-09-07 14:54         ` Konrad Rzeszutek Wilk
2012-09-07 15:44         ` [Xen-devel] " Jan Beulich
2012-09-07 15:47           ` Stefan Bader
2012-09-07 15:52             ` Jan Beulich
2012-09-07 15:48               ` Konrad Rzeszutek Wilk
2012-09-07 15:48               ` [Xen-devel] " Konrad Rzeszutek Wilk
2012-09-07 16:13               ` Stefan Bader
2012-09-07 16:13               ` [Xen-devel] " Stefan Bader
2012-09-08 10:28                 ` Paolo Bonzini
2012-09-08 10:28                 ` [Xen-devel] " Paolo Bonzini
2012-09-07 15:52             ` Jan Beulich
2012-09-07 15:54             ` [Xen-devel] " Ian Campbell
2012-09-07 15:54             ` Ian Campbell
2012-09-08 10:20             ` Paolo Bonzini
2012-09-08 10:20             ` [Xen-devel] " Paolo Bonzini
2012-09-07 15:47           ` Stefan Bader
2012-09-07 16:00           ` Justin M. Forbes
2012-09-07 16:00           ` [Xen-devel] " Justin M. Forbes
2012-09-11  2:40             ` Matt Wilson
2012-09-11  2:40             ` [Xen-devel] " Matt Wilson
2012-09-11 11:37               ` Konrad Rzeszutek Wilk
2012-09-11 13:06                 ` Josh Boyer
2012-09-11 13:06                 ` Josh Boyer
2012-09-11 11:37               ` Konrad Rzeszutek Wilk
2012-09-07 15:44         ` Jan Beulich
2012-09-07 14:22       ` Justin M. Forbes
2012-09-07 13:21   ` Stefan Bader
2012-09-07 12:33 ` Jan Beulich
2012-09-07 13:47 ` Konrad Rzeszutek Wilk
2012-09-07 13:47 ` Konrad Rzeszutek Wilk
2012-09-11  1:17   ` Matt Wilson
2012-09-11  1:17   ` Matt Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120907142251.GA20096@linuxtx.org \
    --to=jmforbes@linuxtx.org \
    --cc=JBeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msw@amazon.com \
    --cc=stefan.bader@canonical.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.