From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] [RFC] More fp instructions for realmode emulation (Enables booting OS/2 as a HVM guest on Intel/VT hardware) Date: Sat, 01 Mar 2008 08:46:59 +0000 Message-ID: References: <515922b50802291414q79cd34c9o36eb103811e7f206@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0861878691==" Return-path: In-Reply-To: <515922b50802291414q79cd34c9o36eb103811e7f206@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Trolle Selander , xen-devel List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0861878691== Content-type: multipart/alternative; boundary="B_3287206026_31915106" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3287206026_31915106 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Regarding point 1: Don=B9t 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=B9m not really up on exactly how FPU exceptio= n 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" 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'v= e > left FWAIT defined, but a no-op because after looking at realmode.c it se= ems > in the emulation, exceptions are always processed if a call to x86_emulat= e > 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, he= nce > the RFC. >=20 > 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, n= one > of the previous instructions done that way referenced the fp registers. D= oes > this make a difference, or is it ok the way i've done it here? --B_3287206026_31915106 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Xen-devel] [PATCH] [RFC] More fp instructions for realmode emul= ation (Enables booting OS/2 as a HVM guest on Intel/VT hardware) Regar= ding 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 c= hecks 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 sema= ntics are broken. More worryingly, if any of the instructions you hav= e 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 ex= ception handling works: are you?

Regarding point 2: Yes, direct use of the FPU instructions is fine as we al= ready 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 c= orresponding ops for emulation. Wrt FSTSW, it is really two ops FNSTSW immed= iately preceeded by an FWAIT. I've left FWAIT defined, but a no-op because a= fter 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 o= ther 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?

 --B_3287206026_31915106-- --===============0861878691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0861878691==--