[Xen-devel] [BUG] x86-64 floating point environment handling

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

Besides the minor problem of the save/restore code needlessly being
conditional for x86-64 (cpu_has_fxsr should always be set for all 64-bit
CPUs) there is a more significant problem: Both FXSAVE and FXRSTOR
require, for a 64-bit environment, 64-bit operand size to be explicitly
used. Simply adding a rex64/ prefix, however, doesn't work because

a) older as well as current binutils complain if the operand uses an
extended register (note that using rex64; rather than rex64/ is
altogether incorrect)

b) 32-bit environments then don't get saved correctly anymore

While fixing this in the Linux kernel is not very difficult, doing the
same in the hypervisor doesn't seem to be as strait forward. This is
because  the Linux kernel makes the guarantee that there can only be (at
most) two 64-bit code selectors (kernel and user mode ones), creation of
new such selectors is impossible. Thus it doesn't suffer from both the
potential of having to know about an unknown number of such selectors as
well as the potential of the descriptor referred to by the code selector
used for the last operation getting re-assigned between the operation
and the raising of an exception.

Thus to properly address this I can only see a more complicated
approach: Whenever a descriptor changes (or the LDT gets reloaded, which
implies all descriptors for selectors with the TI bit set change), the
floating point environment should either be saved completely (along with
an indicator whether it is 32- or 64-bits) and then disabled, or state
machine logic needs to be developed so that only the size of the current
environment is established so that a subsequent save can be done with
the right operand size (for this latter option, I'm not certain provable
to be correct logic can actually be developed).

Before investing time in fixing this, I'd be eager to hear opinions on
the problem, the suggested solution, and ideas towards simpler
solutions.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel