[Qemu-devel] Emulation differences, qemu-system-x86_64 vs Athlon64

[Qemu-devel] Emulation differences, qemu-system-x86_64 vs Athlon64

[Julian Seward]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]


Recently I've been playing with CVS qemu-system (softmmu) on amd64
and had some stability problems.  I decided to run Valgrind's amd64
instruction-set tests (derived from qemu's) to see if they picked up
anything.  Resulting diffs are attached.

There are a bunch of differences for the C flag for rotates
(rol/ror) by multiples of the word size.  I don't think these
are significant, but who knows.

Perhaps more worryingly are the 20 or so lines at the bottom
of the diff.  These I believe are for double-to-int/short
conversions for a value which is out of range for an int/short;
the hardware produces 0x80000000/0x8000 respectively, which is
the "integer indefinite"; QEMU produces zero.  I can imagine some
obscure routine somewhere checking for integer indefinite after
conversion and being confused as a result.

J

[-- Attachment #2: diffs-qemu-vs-Athlon64.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 8511 bytes --]

Re: [Qemu-devel] Emulation differences, qemu-system-x86_64 vs Athlon64

[Fabrice Bellard]

Julian Seward wrote:
> Recently I've been playing with CVS qemu-system (softmmu) on amd64
> and had some stability problems.  I decided to run Valgrind's amd64
> instruction-set tests (derived from qemu's) to see if they picked up
> anything.  Resulting diffs are attached.
> 
> There are a bunch of differences for the C flag for rotates
> (rol/ror) by multiples of the word size.  I don't think these
> are significant, but who knows.

This is a bug in QEMU. From the manuals, the C flag must be updated even 
if the resulting shift is zero. I just modified the QEMU tests to catch 
this problem (it is not x86_64 specific).

> Perhaps more worryingly are the 20 or so lines at the bottom
> of the diff.  These I believe are for double-to-int/short
> conversions for a value which is out of range for an int/short;
> the hardware produces 0x80000000/0x8000 respectively, which is
> the "integer indefinite"; QEMU produces zero.  I can imagine some
> obscure routine somewhere checking for integer indefinite after
> conversion and being confused as a result.

I guess the problem comes from the usage of lrintl() on x86_64 in 
fpu/softfloat-native.c, but I cannot test it yet.

Fabrice.

Re: [Qemu-devel] Emulation differences, qemu-system-x86_64 vs Athlon64

[Julian Seward]

> I guess the problem comes from the usage of lrintl() on x86_64 in
> fpu/softfloat-native.c, but I cannot test it yet.

It might be that you have to pass in an extra value into those
float -> int conversion routines, which describes what to do if the
conversion is going to overflow.  That's because the behaviour is
different depending on the guest architecture.  x86/amd64 always
give 0x8000...., whereas ppc gives either 0x8000... or 0x7FFF....
depending on the sign of the argument (IIRC).

J