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.fitzhardi...@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.fitzhardi...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
