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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28 Nov 2005, at 15:35, Jan Beulich wrote:
> 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
The only difference between rex64-prefixed fxsave and non-prefixed 
fxsave is the format of the last-instruction/data pointers. Does anyone 
make use of those? I notice that Linux always uses the rex64-prefixed 
version of fxsave, so I guess not (at least, not in 32-bit apps running 
on 64-bit linux).

It''s very unlikely we''d implement expensive and complicated
logic in
Xen to ensure consistency of FP state that noone uses.

  -- Keir


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

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 28.11.05 17:22:22
>>>
>
>On 28 Nov 2005, at 15:35, Jan Beulich wrote:
>
>> 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
>
>The only difference between rex64-prefixed fxsave and non-prefixed 
>fxsave is the format of the last-instruction/data pointers. Does
anyone 
>make use of those? I notice that Linux always uses the rex64-prefixed
>version of fxsave, so I guess not (at least, not in 32-bit apps
running 
>on 64-bit linux).
Just before writing this I had posted a patch to correct this in
Linux.
>It''s very unlikely we''d implement expensive and
complicated logic in
>Xen to ensure consistency of FP state that noone uses.
In any case you should use a 64-bit operand size.

Further, I don''t share your opinion: For one part, no-one says
it''s
only Linux that''s going to run on top of Xen, and you really
can''t make
claims on what apps namely in a non-paravirtualized environment may or
may not use. For the other part, things that today don''t get used
don''t
have to stay that way forever. Why shouldn''t software not yet available
for (or not yet widely used on) Linux use functionality that native
hardware provides and that Xen (and Linux without the just submitted
patch) only partly supports?

Jan

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

On 28 Nov 2005, at 16:40, Jan Beulich wrote:
>> It''s very unlikely we''d implement expensive and
complicated logic in
>> Xen to ensure consistency of FP state that noone uses.
>
> In any case you should use a 64-bit operand size.
If noone uses those fields then it doesn''t matter either way. It seems 
that binutils provides no convenient way to force REX.W on that 
instruction.
> Further, I don''t share your opinion: For one part, no-one says
it''s
> only Linux that''s going to run on top of Xen, and you really
can''t make
> claims on what apps namely in a non-paravirtualized environment may or
> may not use. For the other part, things that today don''t get used
don''t
> have to stay that way forever. Why shouldn''t software not yet
available
> for (or not yet widely used on) Linux use functionality that native
> hardware provides and that Xen (and Linux without the just submitted
> patch) only partly supports?
Well, we''ll support those fields properly if there''s a sane 
not-too-expensive scheme for saving them properly. I didn''t understand 
the scheme that you proposed in your first email.

  -- Keir


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