Description of problem:
When using fc 17 as dom0, you will see it crashed immediately when booting. And this issue only exists with xsave supported platform. After looking into this issue, i found the following patch is totally wrong. For legacy hypervisors, you need to add xsave=1 in kernel cmdline to avoid writing OXSAVE bit of cr4, not using such ugly way to hack it. 
Consider a xsave supported hypervisor, with this patch, dom0 kernel will confuse: it will try to use xsave, but the osxsave bit never be set. Then it crashed.




Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

fix_xen_guest_on_old_EC2.patch

Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
cr4 gracefully. If a guest attempts to write a bit of cr4 that is
unsupported, then the HV is so offended it crashes the domain. While
later guest kernels (such as RHEL6) don't assume the HV supports all
features, they do expect nicer responses. That assumption introduced
code that probes whether or not xsave is supported early in the boot. So
now when attempting to boot a RHEL6 guest on RHEL5.0 or RHEL5.1 an early
crash will occur.

This patch is quite obviously an undesirable hack. The real fix for this
problem should be in the HV, and is, in later HVs. However, to support
running on old HVs, RHEL6 can take this small change. No impact will
occur for running on any RHEL HV (not even RHEL 5.5 supports xsave).
There is only potential for guest performance loss on upstream Xen.

---
 arch/x86/xen/enlighten.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 52f8e19..6db3d67 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -802,6 +802,7 @@ static void xen_write_cr4(unsigned long cr4)
 {
        cr4 &= ~X86_CR4_PGE;
        cr4 &= ~X86_CR4_PSE;
+       cr4 &= ~X86_CR4_OSXSAVE;

        native_write_cr4(cr4);
 }