Xen devel - Feb 2008 - [PATCH] [RFC] More fp instructions for realmode emulation (Enables booting OS/2 as a HVM guest on Intel/VT hardware)

This patch adds a number of fp instructions needed for OS/2 to boot as a HVM
guest on Intel/VT hardware. It appears to work fine, and OS/2 is now finally
working on Intel/VT as well as AMD/SVM.

I''m a little concerned about the "correctness" of the FSTSW
emulation and
the use of inline assembly directly using the corresponding ops for
emulation. Wrt FSTSW, it is really two ops FNSTSW immediately preceeded by
an FWAIT. I''ve left FWAIT defined, but a no-op because after looking at
realmode.c it seems in the emulation, exceptions are always processed if a
call to x86_emulate returns an exception, so there should be no way for
there to be "pending" exceptions for FWAIT to wait for. I may have
missed
something, though, hence the RFC.

Secondly, about the inline assembly - i saw that this was how many of the
other FP instructions were done, so I did it that way as well. However, none
of the previous instructions done that way referenced the fp registers. Does
this make a difference, or is it ok the way i''ve done it here?

Signed-off-by: Trolle Selander <trolle.selander@gmail.com>



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

Regarding point 1: Don¹t FPU instructions that raise an exception only log
that in the status word, to be picked up by the next FPU instruction which
checks for exceptions? It strikes me that we can have previously loaded up a
status word that requires an exception to occur on FWAIT, in which case
semantics are broken. More worryingly, if any of the instructions you have
added can cause an exception, we will crash Xen because you have not added
fixup handling. Unfortunately I¹m not really up on exactly how FPU exception
handling works: are you?

Regarding point 2: Yes, direct use of the FPU instructions is fine as we
already loaded guest FPU context.

 -- Keir

On 29/2/08 22:14, "Trolle Selander" <trolle.selander@gmail.com>
wrote:
> I''m a little concerned about the "correctness" of the
FSTSW emulation and the
> use of inline assembly directly using the corresponding ops for emulation.
Wrt
> FSTSW, it is really two ops FNSTSW immediately preceeded by an FWAIT.
I''ve
> left FWAIT defined, but a no-op because after looking at realmode.c it
seems
> in the emulation, exceptions are always processed if a call to x86_emulate
> returns an exception, so there should be no way for there to be
"pending"
> exceptions for FWAIT to wait for. I may have missed something, though,
hence
> the RFC.
> 
> Secondly, about the inline assembly - i saw that this was how many of the
> other FP instructions were done, so I did it that way as well. However,
none
> of the previous instructions done that way referenced the fp registers.
Does
> this make a difference, or is it ok the way i''ve done it here?



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

Intel SDM Volume 1 Section 8.6 (³X87 FPU Exception Synchronization²) is very
helpful in this regard. It confirms my suspicions, that we will need to wrap
the FPU inline asms in some fixup glue. The only exceptions to this rule are
the FN* (no-wait) instructions. Properly speaking we should also check for
unmasked exceptions becoming pending after any FPU instruction and set the
faulting CS:IP in the FPU context block appropriately. But life is perhaps
too short. :-)

 -- Keir

On 1/3/08 08:46, "Keir Fraser" <keir.fraser@eu.citrix.com>
wrote:
> Regarding point 1: Don¹t FPU instructions that raise an exception only log
> that in the status word, to be picked up by the next FPU instruction which
> checks for exceptions? It strikes me that we can have previously loaded up
a
> status word that requires an exception to occur on FWAIT, in which case
> semantics are broken. More worryingly, if any of the instructions you have
> added can cause an exception, we will crash Xen because you have not added
> fixup handling. Unfortunately I¹m not really up on exactly how FPU
exception
> handling works: are you?



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

That''s what I was worried about. I honestly had zilch experience
working
with assembler-level x87 stuff before Friday afternoon when I whipped up
this patch, mainly to see if the fp instructions were all that was missing
to get OS/2 on VT to work. I''ll see if I can find time to make an
exception-safe version of this sometime this week. I''m not worrying
about
life being too short, but rather that March 2008 is too dense... ;)

On Sat, Mar 1, 2008 at 10:18 AM, Keir Fraser <keir.fraser@eu.citrix.com>
wrote:
>  Intel SDM Volume 1 Section 8.6 ("X87 FPU Exception
Synchronization") is
> very helpful in this regard. It confirms my suspicions, that we will need
to
> wrap the FPU inline asms in some fixup glue. The only exceptions to this
> rule are the FN* (no-wait) instructions. Properly speaking we should also
> check for unmasked exceptions becoming pending after any FPU instruction
and
> set the faulting CS:IP in the FPU context block appropriately. But life is
> perhaps too short. :-)
>
>  -- Keir
>
> On 1/3/08 08:46, "Keir Fraser" <keir.fraser@eu.citrix.com>
wrote:
>
> Regarding point 1: Don''t FPU instructions that raise an exception
only log
> that in the status word, to be picked up by the next FPU instruction which
> checks for exceptions? It strikes me that we can have previously loaded up
a
> status word that requires an exception to occur on FWAIT, in which case
> semantics are broken. More worryingly, if *any* of the instructions you
> have added can cause an exception, we will crash Xen because you have not
> added fixup handling. Unfortunately I''m not really up on exactly
how FPU
> exception handling works: are you?
>
>
>

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

I¹ll have some time to do it this afternoon.

 -- Keir

On 3/3/08 12:18, "Trolle Selander" <trolle.selander@gmail.com>
wrote:
> That''s what I was worried about. I honestly had zilch experience
working with
> assembler-level x87 stuff before Friday afternoon when I whipped up this
> patch, mainly to see if the fp instructions were all that was missing to
get
> OS/2 on VT to work. I''ll see if I can find time to make an
exception-safe
> version of this sometime this week. I''m not worrying about life
being too
> short, but rather that March 2008 is too dense... ;)
> 
> On Sat, Mar 1, 2008 at 10:18 AM, Keir Fraser
<keir.fraser@eu.citrix.com>
> wrote:
>> Intel SDM Volume 1 Section 8.6 ("X87 FPU Exception
Synchronization") is very
>> helpful in this regard. It confirms my suspicions, that we will need to
wrap
>> the FPU inline asms in some fixup glue. The only exceptions to this
rule are
>> the FN* (no-wait) instructions. Properly speaking we should also check
for
>> unmasked exceptions becoming pending after any FPU instruction and set
the
>> faulting CS:IP in the FPU context block appropriately. But life is
perhaps
>> too short. :-)
>> 
>>  -- Keir
>> 
>> 
>> On 1/3/08 08:46, "Keir Fraser"
<keir.fraser@eu.citrix.com> wrote:
>> 
>>> Regarding point 1: Don''t FPU instructions that raise an
exception only log
>>> that in the status word, to be picked up by the next FPU
instruction which
>>> checks for exceptions? It strikes me that we can have previously
loaded up a
>>> status word that requires an exception to occur on FWAIT, in which
case
>>> semantics are broken. More worryingly, if any of the instructions
you have
>>> added can cause an exception, we will crash Xen because you have
not added
>>> fixup handling. Unfortunately I''m not really up on exactly
how FPU exception
>>> handling works: are you?
>> 
> 
> 



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

Keir Fraser <keir.fraser@eu.citrix.com> writes:
> Intel SDM Volume 1 Section 8.6 (?X87 FPU Exception Synchronization?) is
very
> helpful in this regard. It confirms my suspicions, that we will need to
wrap
> the FPU inline asms in some fixup glue. The only exceptions to this rule
are
Yes you definitely need to. That was a kernel crash bug on native Linux
some time ago...

Also you need to do the same for any FXSAVEs/FXRSTORs if you haven''t
already.

-Andi


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

On 3/3/08 14:52, "Andi Kleen" <andi@firstfloor.org> wrote:
>> Intel SDM Volume 1 Section 8.6 (?X87 FPU Exception Synchronization?) is
very
>> helpful in this regard. It confirms my suspicions, that we will need to
wrap
>> the FPU inline asms in some fixup glue. The only exceptions to this
rule are
> 
> Yes you definitely need to. That was a kernel crash bug on native Linux
> some time ago...
> 
> Also you need to do the same for any FXSAVEs/FXRSTORs if you
haven''t already.
FXSAVE/FXRSTOR do not flush pending FPU exceptions, right?

 -- Keir



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

On Mon, Mar 03, 2008 at 03:00:52PM +0000, Keir Fraser
wrote:
> On 3/3/08 14:52, "Andi Kleen" <andi@firstfloor.org> wrote:
> 
> >> Intel SDM Volume 1 Section 8.6 (?X87 FPU Exception
Synchronization?) is very
> >> helpful in this regard. It confirms my suspicions, that we will
need to wrap
> >> the FPU inline asms in some fixup glue. The only exceptions to
this rule are
> > 
> > Yes you definitely need to. That was a kernel crash bug on native
Linux
> > some time ago...
> > 
> > Also you need to do the same for any FXSAVEs/FXRSTORs if you
haven''t already.
> 
> FXSAVE/FXRSTOR do not flush pending FPU exceptions, right?
Yes they do not, but there are other ways to make them #GP

-Andi

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

On 3/3/08 16:59, "Andi Kleen" <andi@firstfloor.org> wrote:
>>> Yes you definitely need to. That was a kernel crash bug on native
Linux
>>> some time ago...
>>> 
>>> Also you need to do the same for any FXSAVEs/FXRSTORs if you
haven''t
>>> already.
>> 
>> FXSAVE/FXRSTOR do not flush pending FPU exceptions, right?
> 
> Yes they do not, but there are other ways to make them #GP
We don''t trust FXRSTOR but we do trust FXSAVE. The AMD manual says that
FXRSTOR will #GP if 1s are written to MXCSR reserved bits, but I take this
to be a cut-and-paste typo since FXSAVE does not write to MXCSR.

If there''s real evidence of FXSAVE causing #GP dependent on current FPU
state, I''d be very happy to find out about it!

 -- Keir



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

> We don''t trust FXRSTOR but we do trust FXSAVE. The AMD manual says
that
> FXRSTOR will #GP if 1s are written to MXCSR reserved bits, but I take this
> to be a cut-and-paste typo since FXSAVE does not write to MXCSR.
> 
> If there''s real evidence of FXSAVE causing #GP dependent on
current FPU
> state, I''d be very happy to find out about it!
Sorry, double checked now the Intel docs. First I admit I don''t 
quite remember why it was originally done in Linux, but they
both use exception handlers.

The Intel docs say that #MF can happen for a pending FPU exception
in 64bit mode.

-Andi

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

Annoying fact #2 about the FPU instructions is that the GNU assembler
reverses the operand order of many two-operand FPU instructions. So, for
example, FDIVP becomes DIVRP, and vice versa. Super annoying. So I¹m going
to change our emulated opcodes for most FPU instructions to be ³.byte
xx,yy². Personally I think this is as clear as using the mnemonic opcode, or
perhaps clearer since it is now obvious that we are executing the exact
instruction that we have just decoded.

 -- Keir

On 29/2/08 22:14, "Trolle Selander" <trolle.selander@gmail.com>
wrote:
> This patch adds a number of fp instructions needed for OS/2 to boot as a
HVM
> guest on Intel/VT hardware. It appears to work fine, and OS/2 is now
finally
> working on Intel/VT as well as AMD/SVM.
> 
> I''m a little concerned about the "correctness" of the
FSTSW emulation and the
> use of inline assembly directly using the corresponding ops for emulation.
Wrt
> FSTSW, it is really two ops FNSTSW immediately preceeded by an FWAIT.
I''ve
> left FWAIT defined, but a no-op because after looking at realmode.c it
seems
> in the emulation, exceptions are always processed if a call to x86_emulate
> returns an exception, so there should be no way for there to be
"pending"
> exceptions for FWAIT to wait for. I may have missed something, though,
hence
> the RFC.
> 
> Secondly, about the inline assembly - i saw that this was how many of the
> other FP instructions were done, so I did it that way as well. However,
none
> of the previous instructions done that way referenced the fp registers.
Does
> this make a difference, or is it ok the way i''ve done it here?
> 
> Signed-off-by: Trolle Selander <trolle.selander@gmail.com>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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