|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [BUG] x86-64 floating point environment handling
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|