Doing {,F}X{SAVE,RSTOR} unconditionally with 64-bit operand size leads to the selector values associated with the last instruction/data pointers getting lost. This, besides being inconsistent and not compatible with native hardware behavior especially for 32-bit guests, leads to bug checks in 32-bit Windows when running with "Driver
verifier" (see e.g. http://support.microsoft.com/kb/244617).
In a first try I made the code figure out the current guest mode, but that has the disadvantage of only taking care of the issue when the guest executes in the mode for which the state currently is (i.e. namely not in the case of a 64-bit guest running a 32-bit application, but being in kernle [64-bit] mode).
The solution presented here is to conditionally execute an auxiliary FNSTENV and use the selectors from there.
In either case the determined word size gets stored in the last byte of the FPU/SSE save area, which is available for software use (and I
verified is being cleared to zero by all versions of Xen, i.e. will not present a problem when migrating guests from older to newer hosts), and evaluated for determining the operand size {,F}XRSTOR is to be issued with.
Note that I did check whether using a second FXSAVE or a partial second XSAVE would be faster than FNSTENV - neither on my Westmere (FXSAVE) nor on my Romley (XSAVE) they are.
I was really tempted to use branches into the middle of instructions (i.e. past the REX64 prefixes) here, as that would have allowed to collapse the otherwise identical fault recovery blocks. I stayed away from doing so just because I expect others to dislike such slightly subtle/tricky code.
10f9691 x86: preserve FPU selectors for 32-bit guest code
xen/arch/x86/i387.c | 119 ++++++++++++++++++++++++++++----------
xen/arch/x86/xstate.c | 107 +++++++++++++++++++++++++---------
xen/include/asm-x86/cpufeature.h | 2 +
xen/include/asm-x86/i387.h | 21 +++++++
xen/include/asm-x86/xstate.h | 2 -
5 files changed, 191 insertions(+), 60 deletions(-)
Upstream: xenbits.xen.org