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: Tue, 04 Mar 2008 10:13:01 +0000 Message-ID: References: <515922b50802291414q79cd34c9o36eb103811e7f206@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0274818885==" 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. --===============0274818885== Content-type: multipart/alternative; boundary="B_3287470389_23766664" > 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_3287470389_23766664 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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=B9m going to change our emulated opcodes for most FPU instructions to be =B3.byte xx,yy=B2. Personally I think this is as clear as using the mnemonic opcode, o= r 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" 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 fina= lly > working on Intel/VT as well as AMD/SVM. >=20 > 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? >=20 > Signed-off-by: Trolle Selander >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel --B_3287470389_23766664 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) Annoy= ing fact #2 about the FPU instructions is that the GNU assembler reverses th= e 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,yyR= 21;. Personally I think this is as clear as using the mnemonic opcode, or pe= rhaps clearer since it is now obvious that we are executing the exact instru= ction 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, a= nd 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 emula= tion 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 real= mode.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 s= omething, 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?

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

____________________= ___________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/x= en-devel

 --B_3287470389_23766664-- --===============0274818885== 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 --===============0274818885==--