On 08/11/2010 01:53 AM, Ian Campbell wrote:
On Wed, 2010-08-11 at 03:31 +0100, Ben Hutchings wrote:On Mon, 2010-08-09 at 19:29 -0400, Kyle Moffett wrote:Package: linux-2.6 Severity: normal Tags: patch Would it be possible to apply the attached Fedora/Ubuntu kernel patch to Debian as well? The Fedora link is: http://cvs.fedoraproject.org/viewvc/F-13/kernel/fix_xen_guest_on_old_EC2.patch And the Ubuntu link: http://kernel.ubuntu.com/git?p=rtg/ubuntu-maverick.git;a=commit;h=1a30f99 As far as I can tell, no released version of Xen currently supports XSAVE, so this change is effectively a NOP on all newer hypervisors, but it allows functionality on older hypervisors (such as RHEL5, or when running on Amazon's EC2 service).[...] The comment says that 'There is only potential for guest performance loss on upstream Xen' which implies that XSAVE is supported now. Ian, what's your take on this? Is it worth trying to use XSAVE, and if so is there a way to detect the broken HV versions before doing so?The following commit seems to be in v2.6.31-rc1, is it not sufficient to allow correct operation on these older hypervisors? If not it would be nice to know why.
The patch referred to by those two links says that old versions of Xen will simply kill the domain if they try to set CR4 bits the hypervisor doesn't understand, so this patch will not work.
commit e826fe1ba1563a9272345da8e3279a930ac160a7
Author: Jeremy Fitzhardinge<jeremy.fitzhardinge@citrix.com>
Date: Sat Mar 7 17:09:27 2009 -0800
xen: mask XSAVE from cpuid
Xen leaves XSAVE set in cpuid, but doesn't allow cr4.OSXSAVE
to be set. This confuses the kernel and it ends up crashing on
an xsetbv instruction.
At boot time, try to set cr4.OSXSAVE, and mask XSAVE out of
cpuid it we can't. This will produce a spurious error from Xen,
but allows us to support XSAVE if/when Xen does.
This also factors out the cpuid mask decisions to boot time.
Signed-off-by: Jeremy Fitzhardinge<jeremy.fitzhardinge@citrix.com>
The kernel can take a "noxsave" on the command line which I imagine
would also workaround the issue.
If the hypervisor is old-but-not-too-old you may also have the option of
masking the xsave bit in cpuid via the domain config file.
On the other hand as far as I can tell even xen-unstable.hg does not
support XSAVE for PV guests so any potential guest performance loss is
only theoretical in the future.
It's not clear that xsave could ever be usable by PV guests, even in principle, so its probably all completely over-engineered. If setting X86_CR4_OSXSAVE is problematic, then simply adding it to the list of things we mask out of cpuid is probably the best fix.
J