[Qemu-devel] QEMU regression problems

[Qemu-devel] QEMU regression problems

[Gerhard Wiesinger]

Hello,

Checkit reports some problems under DOS:
1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED. 
Seems to be a problem of the instruction set.
2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the
KVM problem, see my previous post). Seems to be that real-time clock is 
not working correct.
3.) There is also a problem with the reported base memory under QEMM386
(HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
Therefore base memory test fails. I guess that reporting memory CMOS 
tables/interrupt functions are not implemented correctly.

Details are listed below.

All issues are NOT present under VMWare Server 2.0 and with real hardware.

QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II 
Quad Core, x86_64-softmmu.

Any comments?

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/

Details:
1.)
     NPU Trigonometric Functions.................................FAILED ***
         Step 1, Expected    0.42926, received    0.42926

Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h).
Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h).
Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h).

2.)
Compare Current Time............................................Passed
     DOS: 16:24:39.89    Real-Time Clock: 16:24:39.00   (.89 apart)

Compare Current Date............................................Passed
     DOS: 04/11/2010     Real-Time Clock: 04/11/2010.

Real-Time Clock Alarm...........................................FAILED ***

Compare Elapsed Time............................................Passed
     DOS: 11.97 Seconds  Real-Time Clock: 12.00 Seconds   (.03 apart)

3.)     Known Memory:
         Base        646K   From      0K to    646K   (0000000h to 00A17FFh)
     Base Memory.................................................FAILED ***
         ERROR at Address   0A0000h, Bits FEDCBA9876543210
         ERROR at Address   0A0004h, Bits FEDCBA9876543210
         ERROR at Address   0A0006h, Bits FEDCBA9876543210
         ERROR at Address   0A0008h, Bits FEDCBA9876543210
         ERROR at Address   0A000Ah, Bits FEDCBA9876543210
         ERROR at Address   0A000Ch, Bits FEDCBA9876543210
         ERROR at Address   0A000Eh, Bits FEDCBA9876543210
         ERROR at Address   0A0010h, Bits FEDCBA9876543210
         ERROR at Address   0A0012h, Bits FEDCBA9876543210
         ERROR at Address   0A0014h, Bits FEDCBA9876543210
         ERROR at Address   0A0016h, Bits FEDCBA9876543210
         ERROR at Address   0A0018h, Bits FEDCBA9876543210
         ERROR at Address   0A001Ah, Bits FEDCBA9876543210
         ERROR at Address   0A001Ch, Bits FEDCBA9876543210
         ERROR at Address   0A001Eh, Bits FEDCBA9876543210
         ERROR at Address   0A0020h, Bits FEDCBA9876543210
         ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE.

Re: [Qemu-devel] QEMU regression problems

[Roy Tam]

2010/4/12 Gerhard Wiesinger <lists@wiesinger.com>:
> Hello,
>
> Checkit reports some problems under DOS:
> 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED.
> Seems to be a problem of the instruction set.
> 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the
> KVM problem, see my previous post). Seems to be that real-time clock is not
> working correct.
> 3.) There is also a problem with the reported base memory under QEMM386
> (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
> Therefore base memory test fails. I guess that reporting memory CMOS
> tables/interrupt functions are not implemented correctly.
>
> Details are listed below.
>
> All issues are NOT present under VMWare Server 2.0 and with real hardware.
>
> QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II
> Quad Core, x86_64-softmmu.
>
> Any comments?
>

Tested with Checkit 3.0 and QEMM 9.0.
- The NPU error is confirmed and it seems to be a floating point
rounding error in QEMU. This should be a 0.12 regression as it works
in 0.11.1 and 0.10.6.
- The RTC Alarm failure is confirmed too. Is it unimplemented in QEMU?
- The Base Memory > 640K error seems to be SeaBIOS related. QEMU Bochs
BIOS(tested with both -old-bios hack in 0.12 series and old 0.11.1)
will just freeze after QEMU counted RAM.(Tested with ScriptPC and
Bochs).

> Thnx.
>
> Ciao,
> Gerhard
>
> --
> http://www.wiesinger.com/
>
> Details:
> 1.)
>    NPU Trigonometric Functions.................................FAILED ***
>        Step 1, Expected    0.42926, received    0.42926
>
> Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h).
> Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h).
> Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h).
>
> 2.)
> Compare Current Time............................................Passed
>    DOS: 16:24:39.89    Real-Time Clock: 16:24:39.00   (.89 apart)
>
> Compare Current Date............................................Passed
>    DOS: 04/11/2010     Real-Time Clock: 04/11/2010.
>
> Real-Time Clock Alarm...........................................FAILED ***
>
> Compare Elapsed Time............................................Passed
>    DOS: 11.97 Seconds  Real-Time Clock: 12.00 Seconds   (.03 apart)
>
> 3.)     Known Memory:
>        Base        646K   From      0K to    646K   (0000000h to 00A17FFh)
>    Base Memory.................................................FAILED ***
>        ERROR at Address   0A0000h, Bits FEDCBA9876543210
>        ERROR at Address   0A0004h, Bits FEDCBA9876543210
>        ERROR at Address   0A0006h, Bits FEDCBA9876543210
>        ERROR at Address   0A0008h, Bits FEDCBA9876543210
>        ERROR at Address   0A000Ah, Bits FEDCBA9876543210
>        ERROR at Address   0A000Ch, Bits FEDCBA9876543210
>        ERROR at Address   0A000Eh, Bits FEDCBA9876543210
>        ERROR at Address   0A0010h, Bits FEDCBA9876543210
>        ERROR at Address   0A0012h, Bits FEDCBA9876543210
>        ERROR at Address   0A0014h, Bits FEDCBA9876543210
>        ERROR at Address   0A0016h, Bits FEDCBA9876543210
>        ERROR at Address   0A0018h, Bits FEDCBA9876543210
>        ERROR at Address   0A001Ah, Bits FEDCBA9876543210
>        ERROR at Address   0A001Ch, Bits FEDCBA9876543210
>        ERROR at Address   0A001Eh, Bits FEDCBA9876543210
>        ERROR at Address   0A0020h, Bits FEDCBA9876543210
>        ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE.
>
>
>

Re: [SeaBIOS] [Qemu-devel] QEMU regression problems

[Kevin O'Connor]

On Tue, Apr 13, 2010 at 02:26:10PM +0800, Roy Tam wrote:
> 2010/4/12 Gerhard Wiesinger <lists@wiesinger.com>:
> > 3.) There is also a problem with the reported base memory under QEMM386
> > (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
> > Therefore base memory test fails. I guess that reporting memory CMOS
> > tables/interrupt functions are not implemented correctly.
> 
> - The Base Memory > 640K error seems to be SeaBIOS related. QEMU Bochs
> BIOS(tested with both -old-bios hack in 0.12 series and old 0.11.1)
> will just freeze after QEMU counted RAM.(Tested with ScriptPC and
> Bochs).

The SeaBIOS log would really help.  This can be done by adding:

-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios

to the qemu command line.

The memory can be obtained in several places (int 12, int 1588, int
15e801, int 15e820, and mem 40:13).  All look fine to me from looking
at the code.

-Kevin

Re: [SeaBIOS] [Qemu-devel] QEMU regression problems

[Gerhard Wiesinger]

[-- Attachment #1.1: Type: text/plain, Size: 4016 bytes --]

Kevin O'Connor wrote:
> On Tue, Apr 13, 2010 at 02:26:10PM +0800, Roy Tam wrote:
>   
>> 2010/4/12 Gerhard Wiesinger <lists@wiesinger.com>:
>>     
>>> 3.) There is also a problem with the reported base memory under QEMM386
>>> (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
>>> Therefore base memory test fails. I guess that reporting memory CMOS
>>> tables/interrupt functions are not implemented correctly.
>>>       
>> - The Base Memory > 640K error seems to be SeaBIOS related. QEMU Bochs
>> BIOS(tested with both -old-bios hack in 0.12 series and old 0.11.1)
>> will just freeze after QEMU counted RAM.(Tested with ScriptPC and
>> Bochs).
>>     
>
> The SeaBIOS log would really help.  This can be done by adding:
>
> -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
>
> to the qemu command line.
>
> The memory can be obtained in several places (int 12, int 1588, int
> 15e801, int 15e820, and mem 40:13).  All look fine to me from looking
> at the code.

OK, I made some research on the topic. Problem is that QEMM pushes the 
Extended BIOS data area to High RAM on some machines (QEMU, P733). 
Therefore 640k low memory is available and checkit reports 640kB + 
6kB=646kB EBIOS DATA AREA. Whats strange that on a physical Pentium 733 
machine this works correctly (details see below and attached files), 
maybe someone can try to find the problem with QEMM+Checkit 3.0 (maybe 
there is still some other BIOS function incorrectly implemented). QEMM 
parameter NOXBDA avoids moving the XBDA up to HI RAM and therefore 
checkit reports 640kB well.

SeaBIOS seems to be correct (see below and attached patch files and 
description below).
Total Memory: 256MB (262144kB), Base RAM: 637kB
Extended BIOS Data Area size: 3 kB, segment=9f40

SCSI option ROM:
After option ROMS, Total Memory: 256MB (262144kB), Base RAM: 634kB
Extended BIOS Data Area size: 6 kB, segment=9e80

*MS-DOS 6.22, QEMM 8.03*

*QEMU*

*Testcase*

	

*BDA*

*40h:13h*

	

*INT*

*12h*

	

*INT 15h,*

*AX=E820h*

	

*EBIOS*

*DATAAREA*

	

*Checkit*

*3.0*

Plain DOS, after Boot

	

634kB

	

634kB

	

634kB

	

9E80h-A000h (6k)

	

640kB

HIMEM.SYS+EMM386.EXE

	

634kB

	

634kB

	

634kB

	

9E80h-A000h (6k)

	

640kB

QEMM

	

640kB

	

640kB

	

634kB

	

CEB5h-D035h (6k)

	

646kB

QEMURAMD + QEMM

	

628kB

	

628kB

	

634kB

	

9E80h-A000h (6k)

	

634k

*VMWare*

*Testcase*

	

*BDA*

*40h:13h*

	

*INT*

*12h*

	

*INT 15h,*

*AX=E820h*

	

*EBIOS*

*DATAAREA*

	

*Checkit 3.0*

Plain DOS, after Boot

	

638kB

	

638kB

	

638kB

	

9F80h-A000h (2k)

	

640kB

HIMEM.SYS+EMM386.EXE

	

638kB

	

638kB

	

638kB

	

9F80h-A000h (2k)

	

640kB

QEMM

	

638kB

	

638kB

	

638kB

	

9F80h-A000h (2k)

	

640kB

QEMURAMD + QEMM

	

632kB

	

632kB

	

632kB

	

9F80h-A000h (2k)

	

634kB

*Pentium 733*

*Testcase*

	

*BDA*

*40h:13h*

	

*INT*

*12h*

	

*INT 15h,*

*AX=E820h*

	

*EBIOS*

*DATAAREA*

	

*Checkit 3.0*

Plain DOS, after Boot

	

639kB

	

639kB

	

639kB

	

9FC0h-A000h (1k)

	

640kB

QEMM

	

640B

	

640kB

	

639kB

	

D1B5h- (1k)

	

640kB

Attached documents:
MEQEMU.TXT QEMU, no CONFIG.SYS/AUTOEXEC.BAT
MEQEMUH.TXT QEMU, HIMEM.SYS, EMM386.EXE
MEQEMUQ1.TXT QEMU, QEMM386.EXE, NOXBDA parameter
MEQEMUQ2.TXT QEMU, QEMM386.EXE
MEVMW.TXT VMWare, no CONFIG.SYS/AUTOEXEC.BAT
MEVMWH.TXT VMWare, HIMEM.SYS, EMM386.EXE
MEVMWQ.TXT QEMU, QEMM386.EXE (XBDA not moved to HMA!?!)
P733.TXT, Pentium 733, no CONFIG.SYS/AUTOEXEC.BAT
P733Q.TXT Pentium 733, QEMM386.EXE

Code and Patches can be found at (released under GPL V2):
http://www.wiesinger.com/opensource/seabios/meminfoa.asm
http://www.wiesinger.com/opensource/seabios/meminfo.c
http://www.wiesinger.com/opensource/seabios/meminfo.exe
http://www.wiesinger.com/opensource/seabios/seabios-0.6.0-gw-V01.patch
QEMURAMD: DOS Device driver, which modifies BDA reported memory by -6kB, 
released later.

Build script will be released under my DOS-Tools soon (some cleanup 
necessary).

Ciao,
Gerhard



[-- Attachment #1.2: Type: text/html, Size: 28935 bytes --]

[-- Attachment #2: MEQEMUQ2.TXT --]
[-- Type: text/plain, Size: 802 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=640, 640kB
INT 12h: AX=640, 640kB

INT 15h, AH=88h
AX=0, number of continuous kB starting at absolute address 100000h: 0kB

INT 15h, AX=E801h
AX=15360, extended memory between 1M and 16M: 15360kB
BX=3840, extended memory above 16M, in 64K blocks: 245760kB
CX=15360, configured memory between 1M and 16M: 15360kB
DX=3840, configured memory above 16M, in 64K blocks: 245760kB

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9E800h (649216), 634kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=B0B5h, memory=6kB
Device driver entry point=D1EEh:023Ch, Device flag 1st byte=00h, 2nd byte=83h



[-- Attachment #3: MEVMW.TXT --]
[-- Type: text/plain, Size: 810 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=638, 638kB
INT 12h: AX=638, 638kB

INT 15h, AH=88h
AX=64512, number of continuous kB starting at absolute address 100000h: 64512kB

INT 15h, AX=E801h
AX=15360, extended memory between 1M and 16M: 15360kB
BX=3823, extended memory above 16M, in 64K blocks: 244672kB
CX=15360, configured memory between 1M and 16M: 15360kB
DX=3823, configured memory above 16M, in 64K blocks: 244672kB

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9F800h (653312), 638kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=9F80h, memory=2kB
Device driver entry point=0000h:0000h, Device flag 1st byte=00h, 2nd byte=02h



[-- Attachment #4: MEVMWH.TXT --]
[-- Type: text/plain, Size: 802 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=638, 638kB
INT 12h: AX=638, 638kB

INT 15h, AH=88h
AX=0, number of continuous kB starting at absolute address 100000h: 0kB

INT 15h, AX=E801h
AX=15360, extended memory between 1M and 16M: 15360kB
BX=3823, extended memory above 16M, in 64K blocks: 244672kB
CX=15360, configured memory between 1M and 16M: 15360kB
DX=3823, configured memory above 16M, in 64K blocks: 244672kB

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9F800h (653312), 638kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=9F80h, memory=2kB
Device driver entry point=CB02h:023Ch, Device flag 1st byte=00h, 2nd byte=C2h



[-- Attachment #5: MEVMWQ.TXT --]
[-- Type: text/plain, Size: 802 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=638, 638kB
INT 12h: AX=638, 638kB

INT 15h, AH=88h
AX=0, number of continuous kB starting at absolute address 100000h: 0kB

INT 15h, AX=E801h
AX=15360, extended memory between 1M and 16M: 15360kB
BX=3823, extended memory above 16M, in 64K blocks: 244672kB
CX=15360, configured memory between 1M and 16M: 15360kB
DX=3823, configured memory above 16M, in 64K blocks: 244672kB

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9F800h (653312), 638kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=9F80h, memory=2kB
Device driver entry point=02FFh:023Ch, Device flag 1st byte=00h, 2nd byte=C2h



[-- Attachment #6: P733.TXT --]
[-- Type: text/plain, Size: 593 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=639, 639kB
INT 12h: AX=639, 639kB

INT 15h, AH=88h
AX=65472, number of continuous kB starting at absolute address 100000h: 65472kB

INT 15h, AX=E801h
Not successful

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9FC00h (654336), 639kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=9FC0h, memory=1kB
Device driver entry point=0000h:0000h, Device flag 1st byte=00h, 2nd byte=00h



[-- Attachment #7: P733Q.TXT --]
[-- Type: text/plain, Size: 585 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=640, 640kB
INT 12h: AX=640, 640kB

INT 15h, AH=88h
AX=0, number of continuous kB starting at absolute address 100000h: 0kB

INT 15h, AX=E801h
Not successful

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9FC00h (654336), 639kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=D1B5h, memory=1kB
Device driver entry point=B11Bh:023Ch, Device flag 1st byte=00h, 2nd byte=82h



[-- Attachment #8: MEQEMU.TXT --]
[-- Type: text/plain, Size: 810 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=634, 634kB
INT 12h: AX=634, 634kB

INT 15h, AH=88h
AX=64512, number of continuous kB starting at absolute address 100000h: 64512kB

INT 15h, AX=E801h
AX=15360, extended memory between 1M and 16M: 15360kB
BX=3840, extended memory above 16M, in 64K blocks: 245760kB
CX=15360, configured memory between 1M and 16M: 15360kB
DX=3840, configured memory above 16M, in 64K blocks: 245760kB

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9E800h (649216), 634kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=9E80h, memory=6kB
Device driver entry point=0000h:0000h, Device flag 1st byte=00h, 2nd byte=00h



[-- Attachment #9: MEQEMUH.TXT --]
[-- Type: text/plain, Size: 802 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=634, 634kB
INT 12h: AX=634, 634kB

INT 15h, AH=88h
AX=0, number of continuous kB starting at absolute address 100000h: 0kB

INT 15h, AX=E801h
AX=15360, extended memory between 1M and 16M: 15360kB
BX=3840, extended memory above 16M, in 64K blocks: 245760kB
CX=15360, configured memory between 1M and 16M: 15360kB
DX=3840, configured memory above 16M, in 64K blocks: 245760kB

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9E800h (649216), 634kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=9E80h, memory=6kB
Device driver entry point=08A9h:023Ch, Device flag 1st byte=00h, 2nd byte=83h



[-- Attachment #10: MEQEMUQ1.TXT --]
[-- Type: text/plain, Size: 802 bytes --]

Memory Information V1.0, (c) 2009-2010 by Gerhard Wiesinger

BIOS area 40h:13h=634, 634kB
INT 12h: AX=634, 634kB

INT 15h, AH=88h
AX=0, number of continuous kB starting at absolute address 100000h: 0kB

INT 15h, AX=E801h
AX=15360, extended memory between 1M and 16M: 15360kB
BX=3840, extended memory above 16M, in 64K blocks: 245760kB
CX=15360, configured memory between 1M and 16M: 15360kB
DX=3840, configured memory above 16M, in 64K blocks: 245760kB

INT 15h, AX=E820h
structure len=20
base address 0h (0)
length in bytes 9E800h (649216), 634kB
type of address range: memory type=1
type of address range: memory type=memory, available to OS

EBDA - Extended BIOS Data Area information, found, segment=9E80h, memory=6kB
Device driver entry point=D1EEh:023Ch, Device flag 1st byte=00h, 2nd byte=83h

Re: [SeaBIOS] [Qemu-devel] QEMU regression problems

[Kevin O'Connor]

On Mon, Apr 19, 2010 at 08:19:55AM +0200, Gerhard Wiesinger wrote:
> Kevin O'Connor wrote:
> >The SeaBIOS log would really help.  This can be done by adding:
> >
> >-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
> >
> >to the qemu command line.
> OK, I made some research on the topic. Problem is that QEMM pushes
> the Extended BIOS data area to High RAM on some machines (QEMU,
> P733). Therefore 640k low memory is available and checkit reports
> 640kB + 6kB=646kB EBIOS DATA AREA. Whats strange that on a physical
> Pentium 733 machine this works correctly (details see below and
> attached files), maybe someone can try to find the problem with
> QEMM+Checkit 3.0 (maybe there is still some other BIOS function
> incorrectly implemented). QEMM parameter NOXBDA avoids moving the
> XBDA up to HI RAM and therefore checkit reports 640kB well.
> 
> SeaBIOS seems to be correct (see below and attached patch files and
> description below).
> Total Memory: 256MB (262144kB), Base RAM: 637kB
> Extended BIOS Data Area size: 3 kB, segment=9f40
> 
> SCSI option ROM:
> After option ROMS, Total Memory: 256MB (262144kB), Base RAM: 634kB
> Extended BIOS Data Area size: 6 kB, segment=9e80

Which scsi option rom?  Can you forward the log using the command line
above?  Another thing that may help is increasing the debug level in
seabios (set CONFIG_DEBUG_LEVEL to 8 in src/config.h and recompile).

SeaBIOS will lock parts of ram from 0xc0000-0xfffff so that the option
roms aren't writable.  I wonder if that is confusing qemm when it
tries to locate the ebda into that area.

-Kevin

Re: [SeaBIOS] [Qemu-devel] QEMU regression problems

[Gerhard Wiesinger]

On Mon, 19 Apr 2010, Kevin O'Connor wrote:

> On Mon, Apr 19, 2010 at 08:19:55AM +0200, Gerhard Wiesinger wrote:
>> Kevin O'Connor wrote:
>>> The SeaBIOS log would really help.  This can be done by adding:
>>>
>>> -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
>>>
>>> to the qemu command line.
>> OK, I made some research on the topic. Problem is that QEMM pushes
>> the Extended BIOS data area to High RAM on some machines (QEMU,
>> P733). Therefore 640k low memory is available and checkit reports
>> 640kB + 6kB=646kB EBIOS DATA AREA. Whats strange that on a physical
>> Pentium 733 machine this works correctly (details see below and
>> attached files), maybe someone can try to find the problem with
>> QEMM+Checkit 3.0 (maybe there is still some other BIOS function
>> incorrectly implemented). QEMM parameter NOXBDA avoids moving the
>> XBDA up to HI RAM and therefore checkit reports 640kB well.
>>
>> SeaBIOS seems to be correct (see below and attached patch files and
>> description below).
>> Total Memory: 256MB (262144kB), Base RAM: 637kB
>> Extended BIOS Data Area size: 3 kB, segment=9f40
>>
>> SCSI option ROM:
>> After option ROMS, Total Memory: 256MB (262144kB), Base RAM: 634kB
>> Extended BIOS Data Area size: 6 kB, segment=9e80
>
> Which scsi option rom?  Can you forward the log using the command line
> above?  Another thing that may help is increasing the debug level in
> seabios (set CONFIG_DEBUG_LEVEL to 8 in src/config.h and recompile).
>
> SeaBIOS will lock parts of ram from 0xc0000-0xfffff so that the option
> roms aren't writable.  I wonder if that is confusing qemm when it
> tries to locate the ebda into that area.

SCSI option ROM, LSI 53C895A (BTW: Is there another SCSI emulation available?):
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip

Log file can be downloaded at: http://www.wiesinger.com/tmp/seabios.log
command line option: -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
CONFIG_DEBUG_LEVEL to 8 in src/config.h

Is the area from 0xc0000-0xfffff only read only when an option ROM is 
installed at some part of the memory area (e.g. option ROM at 0xD0000 to 
0xDFFFF only 0xD0000 to 0xDFFFF is made read only) or the comple area 
is made read only?

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [SeaBIOS] [Qemu-devel] QEMU regression problems

[Kevin O'Connor]

On Wed, Apr 21, 2010 at 09:16:54PM +0200, Gerhard Wiesinger wrote:
> On Mon, 19 Apr 2010, Kevin O'Connor wrote:
> >SeaBIOS will lock parts of ram from 0xc0000-0xfffff so that the option
> >roms aren't writable.  I wonder if that is confusing qemm when it
> >tries to locate the ebda into that area.

>From your initial log, it looks like QEMM tried to relocate the ebda
to CEB5h-D035h.  However, the seabios log shows the last rom
(genroms/vapic.bin) at 0xce800-0xd0a00.  So, SeaBIOS would have locked
that ram.  Can you see if the patch below shows a different result for
you?

> Is the area from 0xc0000-0xfffff only read only when an option ROM
> is installed at some part of the memory area (e.g. option ROM at
> 0xD0000 to 0xDFFFF only 0xD0000 to 0xDFFFF is made read only) or the
> comple area is made read only?

SeaBIOS will lock only those areas it deployed option roms into.
However, the chipset only allows locking of 16K chunks - so SeaBIOS
will round up the option rom storage to the nearest 16K block.  For
example, should the last rom end at 0xd0a00, then SeaBIOS would lock
up to 0xd4000.

-Kevin


--- a/src/shadow.c
+++ b/src/shadow.c
@@ -104,6 +104,8 @@ make_bios_readonly(void)
     // Flush any pending writes before locking memory.
     wbinvd();
 
+    dprintf(1, "RomEnd=%x\n", RomEnd);
+#if 0
     // Write protect roms from 0xc0000-0xf0000
     int i;
     for (i=0; i<6; i++) {
@@ -115,6 +117,7 @@ make_bios_readonly(void)
         }
         pci_config_writeb(bdf, 0x5a + i, 0x11);
     }
+#endif
 
     // Write protect 0xf0000-0x100000
     pci_config_writeb(bdf, 0x59, 0x10);

Re: [SeaBIOS] [Qemu-devel] QEMU regression problems

[Gerhard Wiesinger]

On Wed, 21 Apr 2010, Kevin O'Connor wrote:

> On Wed, Apr 21, 2010 at 09:16:54PM +0200, Gerhard Wiesinger wrote:
>> On Mon, 19 Apr 2010, Kevin O'Connor wrote:
>>> SeaBIOS will lock parts of ram from 0xc0000-0xfffff so that the option
>>> roms aren't writable.  I wonder if that is confusing qemm when it
>>> tries to locate the ebda into that area.
>
> From your initial log, it looks like QEMM tried to relocate the ebda
> to CEB5h-D035h.  However, the seabios log shows the last rom
> (genroms/vapic.bin) at 0xce800-0xd0a00.  So, SeaBIOS would have locked
> that ram.  Can you see if the patch below shows a different result for
> you?

Ok, log file was until boot process only (as we discussed SCSI EBDA area). 
Therefore no QEMM is involved at all. Can send complete log file today 
evening for both cases (QEMM with/wo NOXBDA parameter).

>> Is the area from 0xc0000-0xfffff only read only when an option ROM
>> is installed at some part of the memory area (e.g. option ROM at
>> 0xD0000 to 0xDFFFF only 0xD0000 to 0xDFFFF is made read only) or the
>> comple area is made read only?
>
> SeaBIOS will lock only those areas it deployed option roms into.
> However, the chipset only allows locking of 16K chunks - so SeaBIOS
> will round up the option rom storage to the nearest 16K block.  For
> example, should the last rom end at 0xd0a00, then SeaBIOS would lock
> up to 0xd4000.
>

OK, clear.

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/

[Qemu-devel] Re: QEMU regression problems - Update FPU

[Gerhard Wiesinger]

Hello,

Good news: Seems to be that 2 of 3 issues have been fixed with QEMU: :-)
Summary of previous discussion:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg29465.html

2.) Realtime clock: fixed
3.) Base Memory: fixed

Issue 1.) with FPU still present
I tracked down the problematic code and it is a rounding error from double 
precision to 64bit floats: Any ideas how to fix such an issue in general?

QEMU result in ST0: 0.42925860786976457 (wrong emulated)
KVM result in ST0:  0.42925860786975449 (correct)

Code:
 	fninit			; init FPU
 	fld1			; Pushes 1 on the stack, ST0=1
 	fadd	st(0), st(0)	; ST0=ST0+ST0=2
 	fld1			; Pushes 1 on the stack, ST0=1, ST1=2
 	fadd	st(1), st(0)	; ST1=ST1+ST0=3, ST0=1
 	fdivrp	st(1), st(0)	; ST0=ST0/ST1=1/3
 	f2xm1			; ST0=2^ST0-1 (ST0 must be in range -1 to +1)=2^(1/3)-1=0.25992104989487316476721060727823
 	fldpi			; pushes pi on the stack; ST0=pi, ST1=0.25992104989487316476721060727823
 	fyl2x			; ST0=ST1*log2(ST0)=0.25992104989487316476721060727823*1.651496129472318798043279295108=0.42925860786976448643152122341584
 	fwait			; wait

*.ASM/*.COM file is also present for debugging.

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/


On Mon, 12 Apr 2010, Gerhard Wiesinger wrote:

> Hello,
>
> Checkit reports some problems under DOS:
> 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED. Seems 
> to be a problem of the instruction set.
> 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the
> KVM problem, see my previous post). Seems to be that real-time clock is not 
> working correct.
> 3.) There is also a problem with the reported base memory under QEMM386
> (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
> Therefore base memory test fails. I guess that reporting memory CMOS 
> tables/interrupt functions are not implemented correctly.
>
> Details are listed below.
>
> All issues are NOT present under VMWare Server 2.0 and with real hardware.
>
> QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II 
> Quad Core, x86_64-softmmu.
>
> Any comments?
>
> Thnx.
>
> Ciao,
> Gerhard
>
> --
> http://www.wiesinger.com/
>
> Details:
> 1.)
>    NPU Trigonometric Functions.................................FAILED ***
>        Step 1, Expected    0.42926, received    0.42926
>
> Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h).
> Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h).
> Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h).
>
> 2.)
> Compare Current Time............................................Passed
>    DOS: 16:24:39.89    Real-Time Clock: 16:24:39.00   (.89 apart)
>
> Compare Current Date............................................Passed
>    DOS: 04/11/2010     Real-Time Clock: 04/11/2010.
>
> Real-Time Clock Alarm...........................................FAILED ***
>
> Compare Elapsed Time............................................Passed
>    DOS: 11.97 Seconds  Real-Time Clock: 12.00 Seconds   (.03 apart)
>
> 3.)     Known Memory:
>        Base        646K   From      0K to    646K   (0000000h to 00A17FFh)
>    Base Memory.................................................FAILED ***
>        ERROR at Address   0A0000h, Bits FEDCBA9876543210
>        ERROR at Address   0A0004h, Bits FEDCBA9876543210
>        ERROR at Address   0A0006h, Bits FEDCBA9876543210
>        ERROR at Address   0A0008h, Bits FEDCBA9876543210
>        ERROR at Address   0A000Ah, Bits FEDCBA9876543210
>        ERROR at Address   0A000Ch, Bits FEDCBA9876543210
>        ERROR at Address   0A000Eh, Bits FEDCBA9876543210
>        ERROR at Address   0A0010h, Bits FEDCBA9876543210
>        ERROR at Address   0A0012h, Bits FEDCBA9876543210
>        ERROR at Address   0A0014h, Bits FEDCBA9876543210
>        ERROR at Address   0A0016h, Bits FEDCBA9876543210
>        ERROR at Address   0A0018h, Bits FEDCBA9876543210
>        ERROR at Address   0A001Ah, Bits FEDCBA9876543210
>        ERROR at Address   0A001Ch, Bits FEDCBA9876543210
>        ERROR at Address   0A001Eh, Bits FEDCBA9876543210
>        ERROR at Address   0A0020h, Bits FEDCBA9876543210
>        ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE.
>

Re: [Qemu-devel] Re: QEMU regression problems - Update FPU

[Gerhard Wiesinger]

Any comments on this problem?

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/


On Fri, 18 Feb 2011, Gerhard Wiesinger wrote:

> Hello,
>
> Good news: Seems to be that 2 of 3 issues have been fixed with QEMU: :-)
> Summary of previous discussion:
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg29465.html
>
> 2.) Realtime clock: fixed
> 3.) Base Memory: fixed
>
> Issue 1.) with FPU still present
> I tracked down the problematic code and it is a rounding error from double 
> precision to 64bit floats: Any ideas how to fix such an issue in general?
>
> QEMU result in ST0: 0.42925860786976457 (wrong emulated)
> KVM result in ST0:  0.42925860786975449 (correct)
>
> Code:
> 	fninit			; init FPU
> 	fld1			; Pushes 1 on the stack, ST0=1
> 	fadd	st(0), st(0)	; ST0=ST0+ST0=2
> 	fld1			; Pushes 1 on the stack, ST0=1, ST1=2
> 	fadd	st(1), st(0)	; ST1=ST1+ST0=3, ST0=1
> 	fdivrp	st(1), st(0)	; ST0=ST0/ST1=1/3
> 	f2xm1			; ST0=2^ST0-1 (ST0 must be in range -1 to 
> +1)=2^(1/3)-1=0.25992104989487316476721060727823
> 	fldpi			; pushes pi on the stack; ST0=pi, 
> ST1=0.25992104989487316476721060727823
> 	fyl2x			; 
> ST0=ST1*log2(ST0)=0.25992104989487316476721060727823*1.651496129472318798043279295108=0.42925860786976448643152122341584
> 	fwait			; wait
>
> *.ASM/*.COM file is also present for debugging.
>
> Thnx.
>
> Ciao,
> Gerhard
>
> --
> http://www.wiesinger.com/
>
>
> On Mon, 12 Apr 2010, Gerhard Wiesinger wrote:
>
>> Hello,
>> 
>> Checkit reports some problems under DOS:
>> 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED. 
>> Seems to be a problem of the instruction set.
>> 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the
>> KVM problem, see my previous post). Seems to be that real-time clock is not 
>> working correct.
>> 3.) There is also a problem with the reported base memory under QEMM386
>> (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
>> Therefore base memory test fails. I guess that reporting memory CMOS 
>> tables/interrupt functions are not implemented correctly.
>> 
>> Details are listed below.
>> 
>> All issues are NOT present under VMWare Server 2.0 and with real hardware.
>> 
>> QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II 
>> Quad Core, x86_64-softmmu.
>> 
>> Any comments?
>> 
>> Thnx.
>> 
>> Ciao,
>> Gerhard
>> 
>> --
>> http://www.wiesinger.com/
>> 
>> Details:
>> 1.)
>>    NPU Trigonometric Functions.................................FAILED ***
>>        Step 1, Expected    0.42926, received    0.42926
>> 
>> Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h).
>> Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h).
>> Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h).
>> 
>> 2.)
>> Compare Current Time............................................Passed
>>    DOS: 16:24:39.89    Real-Time Clock: 16:24:39.00   (.89 apart)
>> 
>> Compare Current Date............................................Passed
>>    DOS: 04/11/2010     Real-Time Clock: 04/11/2010.
>> 
>> Real-Time Clock Alarm...........................................FAILED ***
>> 
>> Compare Elapsed Time............................................Passed
>>    DOS: 11.97 Seconds  Real-Time Clock: 12.00 Seconds   (.03 apart)
>> 
>> 3.)     Known Memory:
>>        Base        646K   From      0K to    646K   (0000000h to 00A17FFh)
>>    Base Memory.................................................FAILED ***
>>        ERROR at Address   0A0000h, Bits FEDCBA9876543210
>>        ERROR at Address   0A0004h, Bits FEDCBA9876543210
>>        ERROR at Address   0A0006h, Bits FEDCBA9876543210
>>        ERROR at Address   0A0008h, Bits FEDCBA9876543210
>>        ERROR at Address   0A000Ah, Bits FEDCBA9876543210
>>        ERROR at Address   0A000Ch, Bits FEDCBA9876543210
>>        ERROR at Address   0A000Eh, Bits FEDCBA9876543210
>>        ERROR at Address   0A0010h, Bits FEDCBA9876543210
>>        ERROR at Address   0A0012h, Bits FEDCBA9876543210
>>        ERROR at Address   0A0014h, Bits FEDCBA9876543210
>>        ERROR at Address   0A0016h, Bits FEDCBA9876543210
>>        ERROR at Address   0A0018h, Bits FEDCBA9876543210
>>        ERROR at Address   0A001Ah, Bits FEDCBA9876543210
>>        ERROR at Address   0A001Ch, Bits FEDCBA9876543210
>>        ERROR at Address   0A001Eh, Bits FEDCBA9876543210
>>        ERROR at Address   0A0020h, Bits FEDCBA9876543210
>>        ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE.
>> 
>
>

Re: [Qemu-devel] Re: QEMU regression problems - Update FPU

[Peter Maydell]

On 18 February 2011 07:12, Gerhard Wiesinger <lists@wiesinger.com> wrote:
> Issue 1.) with FPU still present
> I tracked down the problematic code and it is a rounding error from double
> precision to 64bit floats: Any ideas how to fix such an issue in general?
>
> QEMU result in ST0: 0.42925860786976457 (wrong emulated)
> KVM result in ST0:  0.42925860786975449 (correct)

This is an error when running QEMU in TCG mode, right?
At the moment x86 is the odd-one-out in that it doesn't
use CONFIG_SOFTFLOAT for its FPU emulation, so somebody
has made an explicit choice of preferring speed over
accuracy, and I am unsurprised that there are rounding
errors as a result.

-- PMM

Re: [Qemu-devel] Re: QEMU regression problems - Update FPU

[Laurent Desnogues]

On Wed, Feb 23, 2011 at 9:16 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 18 February 2011 07:12, Gerhard Wiesinger <lists@wiesinger.com> wrote:
>> Issue 1.) with FPU still present
>> I tracked down the problematic code and it is a rounding error from double
>> precision to 64bit floats: Any ideas how to fix such an issue in general?
>>
>> QEMU result in ST0: 0.42925860786976457 (wrong emulated)
>> KVM result in ST0:  0.42925860786975449 (correct)
>
> This is an error when running QEMU in TCG mode, right?
> At the moment x86 is the odd-one-out in that it doesn't
> use CONFIG_SOFTFLOAT for its FPU emulation, so somebody
> has made an explicit choice of preferring speed over
> accuracy, and I am unsurprised that there are rounding
> errors as a result.

Even if you were using SoftFloat, you'd probably still get wrong
results given that this test seems to test trigonometric instructions
which aren't implemented in SoftFloat, but are relying on libm.


Laurent

Re: [Qemu-devel] Re: QEMU regression problems - Update FPU

[Aurelien Jarno]

On Wed, Feb 23, 2011 at 10:45:25AM +0100, Laurent Desnogues wrote:
> On Wed, Feb 23, 2011 at 9:16 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 18 February 2011 07:12, Gerhard Wiesinger <lists@wiesinger.com> wrote:
> >> Issue 1.) with FPU still present
> >> I tracked down the problematic code and it is a rounding error from double
> >> precision to 64bit floats: Any ideas how to fix such an issue in general?
> >>
> >> QEMU result in ST0: 0.42925860786976457 (wrong emulated)
> >> KVM result in ST0:  0.42925860786975449 (correct)
> >
> > This is an error when running QEMU in TCG mode, right?
> > At the moment x86 is the odd-one-out in that it doesn't
> > use CONFIG_SOFTFLOAT for its FPU emulation, so somebody
> > has made an explicit choice of preferring speed over
> > accuracy, and I am unsurprised that there are rounding
> > errors as a result.
> 
> Even if you were using SoftFloat, you'd probably still get wrong
> results given that this test seems to test trigonometric instructions
> which aren't implemented in SoftFloat, but are relying on libm.
> 

Actually that's the reason why i386 doesn't use softfloat, as all the
trigonometric use libm, and the bridge between softfloat and libm is not
working correctly (plenty of type abuse).

The solution is probably to implement them in softfloat, but it's not
something trivial. exp2 and log2 are already in softfloat for float32
type, the same way could be use for other trigonometric functions.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

[Qemu-devel] Re: QEMU regression problems - Update FPU

[Paolo Bonzini]

On 02/23/2011 08:04 PM, Aurelien Jarno wrote:
> Actually that's the reason why i386 doesn't use softfloat, as all the
> trigonometric use libm, and the bridge between softfloat and libm is not
> working correctly (plenty of type abuse).

Besides, I doubt softfloat would want bug-compatible trig function 
implementations.  fsincos for example is a far cry from the precision of 
the libm function.

Paolo

[Qemu-devel] Re: QEMU regression problems - Update FPU

[Laurent Desnogues]

On Thu, Feb 24, 2011 at 12:10 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 02/23/2011 08:04 PM, Aurelien Jarno wrote:
>>
>> Actually that's the reason why i386 doesn't use softfloat, as all the
>> trigonometric use libm, and the bridge between softfloat and libm is not
>> working correctly (plenty of type abuse).
>
> Besides, I doubt softfloat would want bug-compatible trig function
> implementations.  fsincos for example is a far cry from the precision of the
> libm function.

I agree, these functions certainly don't belong to SoftFloat.
They should be implemented in target-i386/op_helper.c.  But
bit accuracy might be difficult to achieve, unless Intel/AMD
properly documented how they compute all these functions.


Laurent

Re: [Qemu-devel] Re: QEMU regression problems - Update FPU

[Gerhard Wiesinger]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1379 bytes --]

On Wed, 23 Feb 2011, Peter Maydell wrote:

> On 18 February 2011 07:12, Gerhard Wiesinger <lists@wiesinger.com> wrote:
>> Issue 1.) with FPU still present
>> I tracked down the problematic code and it is a rounding error from double
>> precision to 64bit floats: Any ideas how to fix such an issue in general?
>>
>> QEMU result in ST0: 0.42925860786976457 (wrong emulated)
>> KVM result in ST0:  0.42925860786975449 (correct)
>
> This is an error when running QEMU in TCG mode, right?
> At the moment x86 is the odd-one-out in that it doesn't
> use CONFIG_SOFTFLOAT for its FPU emulation, so somebody
> has made an explicit choice of preferring speed over
> accuracy, and I am unsurprised that there are rounding
> errors as a result.

Yes, QEMU not KVM. Regarding mode: I guess tcg mode because softfloat 
doesn't compile on x64 (AMD) (How to find out which mode is used, what 
other modes exist?).

But can't we use the float64 type and use the normal i386 (or higher) 
instructions and therefore we get:
1.) less accurate but correct emulated results
2.) Have the full speed

Second solution would be to use a more accurate type like now but to use 
rounding to e.g. float64 after each FPU operation.

Maybe we can also use a define or config switch for accuracy vs. speed.

What do you think?

Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [Qemu-devel] Re: QEMU regression problems - Update FPU

[Aurelien Jarno]

On Thu, Feb 24, 2011 at 08:03:02AM +0100, Gerhard Wiesinger wrote:
> On Wed, 23 Feb 2011, Peter Maydell wrote:
> 
> >On 18 February 2011 07:12, Gerhard Wiesinger <lists@wiesinger.com> wrote:
> >>Issue 1.) with FPU still present
> >>I tracked down the problematic code and it is a rounding error from double
> >>precision to 64bit floats: Any ideas how to fix such an issue in general?
> >>
> >>QEMU result in ST0: 0.42925860786976457 (wrong emulated)
> >>KVM result in ST0:  0.42925860786975449 (correct)
> >
> >This is an error when running QEMU in TCG mode, right?
> >At the moment x86 is the odd-one-out in that it doesn't
> >use CONFIG_SOFTFLOAT for its FPU emulation, so somebody
> >has made an explicit choice of preferring speed over
> >accuracy, and I am unsurprised that there are rounding
> >errors as a result.
> 
> Yes, QEMU not KVM. Regarding mode: I guess tcg mode because
> softfloat doesn't compile on x64 (AMD) (How to find out which mode
> is used, what other modes exist?).
> 
> But can't we use the float64 type and use the normal i386 (or
> higher) instructions and therefore we get:
> 1.) less accurate but correct emulated results
> 2.) Have the full speed
> 
> Second solution would be to use a more accurate type like now but to
> use rounding to e.g. float64 after each FPU operation.
> 
> Maybe we can also use a define or config switch for accuracy vs. speed.
> 

This is not something possible, x86 uses a 80-bit FPU, and floats are
rounded to 64-bit when moved to memory. That's actually probably why you
see a difference between TCG or native/KVM.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net