On Mon, Sep 10, 2012 at 07:40:47PM -0700, Matt Wilson wrote: > 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@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@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/major > 3 > [ec2-user@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.s...@intel.com> > AuthorDate: Tue Nov 9 11:43:36 2010 -0800 > Commit: Konrad Rzeszutek Wilk <konrad.w...@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
Hey Matt, Thank you for testing. CC-ing some of the Fedora folks so they are aware that they can ditch the: fix_xen_guest_on_old_EC2.patch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
