The kernel would set OSXSAVE in CR4 when the cpuid bits for XSAVE and OSXSAVE are set. Xen is supposed to mask those off (cannot say since which version but it is claimed to be done for quite a while now). The issues with upstream kernels happened after kernel code for Xen did try to probe for the feature on its own by writing CR4:
commit 191216b9289ed02256086e6bab4f668112109399
xen: mask XSAVE from cpuid
This was added in 2.6.30 but then replaced by the following two patches in 2.6.39:
commit 61f4237d5b005767a76f4f3694e68e6f78f392d9
xen: just completely disable XSAVE
commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
xen: Allow PV-OPS kernel to detect whether XSAVE is supported
So kernels newer than 2.6.39 (Oneiric, Precise, Quantal) should be ok even without the work-around. For Lucid we either should update the work-around, or (probably the preferred way) backport at least "xen: just completely disable XSAVE".
Annotations/info from the upstream discussion:
The kernel would set OSXSAVE in CR4 when the cpuid bits for XSAVE and OSXSAVE are set. Xen is supposed to mask those off (cannot say since which version but it is claimed to be done for quite a while now). The issues with upstream kernels happened after kernel code for Xen did try to probe for the feature on its own by writing CR4:
commit 191216b9289ed02 256086e6bab4f66 8112109399
xen: mask XSAVE from cpuid
This was added in 2.6.30 but then replaced by the following two patches in 2.6.39:
commit 61f4237d5b00576 7a76f4f3694e68e 6f78f392d9 b774af3666ee74f cd9f47f646
xen: just completely disable XSAVE
commit 947ccf9c3c30307
xen: Allow PV-OPS kernel to detect whether XSAVE is supported
So kernels newer than 2.6.39 (Oneiric, Precise, Quantal) should be ok even without the work-around. For Lucid we either should update the work-around, or (probably the preferred way) backport at least "xen: just completely disable XSAVE".