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 09:18:19 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1162797404==" Return-path: In-Reply-To: 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. --===============1162797404== Content-type: multipart/alternative; boundary="B_3287207904_32021028" > 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_3287207904_32021028 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Intel SDM Volume 1 Section 8.6 (=B3X87 FPU Exception Synchronization=B2) is ver= y helpful in this regard. It confirms my suspicions, that we will need to wra= p the FPU inline asms in some fixup glue. The only exceptions to this rule ar= e 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" wrote: > Regarding point 1: Don=B9t FPU instructions that raise an exception only lo= g > that in the status word, to be picked up by the next FPU instruction whic= h > checks for exceptions? It strikes me that we can have previously loaded u= p 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 hav= e > added can cause an exception, we will crash Xen because you have not adde= d > fixup handling. Unfortunately I=B9m not really up on exactly how FPU except= ion > handling works: are you? --B_3287207904_32021028 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) 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 c= heck for unmasked exceptions becoming pending after any FPU instruction and = set the faulting CS:IP in the FPU context block appropriately. But life is p= erhaps 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 ra= ise an exception only log that in the status word, to be picked up by the ne= xt FPU instruction which checks for exceptions? It strikes me that we can ha= ve previously loaded up a status word that requires an exception to occur on= FWAIT, in which case semantics are broken. More worryingly, if any o= f the instructions you have added can cause an exception, we will crash Xen = because you have not added fixup handling. Unfortunately I’m not reall= y up on exactly how FPU exception handling works: are you?

 --B_3287207904_32021028-- --===============1162797404== 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 --===============1162797404==--