I haven't tried QEMU 3.1 yet. Adding to to-do list.
I am narrowing down the remaining failures. Within the pveclib test suite,
there are two tests, one is failing, "pveclib_test". It contains numerous
subtests. The failing subtests are:
- test_setb_bcdsq
- test_setb_bcdinv
- test_bcdsr
- test_bcdsrrqi
Investigating the first two so far, it looks like "bcdadd." and
"bcdsub." are not operating correctly. gdb sessions showing the
difference in behavior between QEMU 4.2+patches and hardware (in that
order):
QEMU 4.2+patches:
(gdb) x/i $pc
=> 0x10000698 <vec_setbool_bcdsq+60>: bcdsub. v0,v0,v1,0
(gdb) p $vr0.uint128
$3 = 0x9999999999999999999999999999999d
(gdb) p $vr1.uint128
$4 = 0x1d
(gdb) stepi
(gdb) p $vr1.uint128
$5 = 0x1d
hardware:
1: x/i $pc
=> 0x10000698 <vec_setbool_bcdsq+60>: bcdsub. v0,v0,v1,0
(gdb) p $vr0.uint128
$2 = 0x9999999999999999999999999999999d
(gdb) p $vr1.uint128
$3 = 0x1d
(gdb) nexti
(gdb) p $vr0.uint128
$4 = 0x9999999999999999999999999999998d
--
QEMU 4.2+patches:
=> 0x10000740 <vec_setbool_bcdinv+60>: bcdadd. v0,v0,v1,0
(gdb) p $vr0.uint128
$1 = 0xa999999999999999000000000000000c
(gdb) p $vr1.uint128
$2 = 0xc
(gdb) p $cr
$4 = 0x24000242
(gdb) nexti
(gdb) p $vr0.uint128
$5 = 0xffffffffffffffffffffffffffffffff
(gdb) p $cr
$6 = 0x24000212
hardware:
=> 0x10000740 <vec_setbool_bcdinv+60>: bcdadd. v0,v0,v1,0
(gdb) p $vr0.uint128
$2 = 0xa999999999999999000000000000000c
(gdb) p $vr1.uint128
$3 = 0xc
(gdb) p $cr
$4 = 0x24000442
(gdb) nexti
(gdb) p $vr0.uint128
$5 = 0x999999999999999000000000000000c
(gdb) p $cr
$6 = 0x24000412
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1841990
Title:
instruction 'denbcdq' misbehaving
Status in QEMU:
New
Bug description:
Instruction 'denbcdq' appears to have no effect. Test case attached.
On ppc64le native:
--
gcc -g -O -mcpu=power9 bcdcfsq.c test-denbcdq.c -o test-denbcdq
$ ./test-denbcdq
0x00000000000000000000000000000000
0x0000000000000000000000000000000c
0x22080000000000000000000000000000
$ ./test-denbcdq 1
0x00000000000000000000000000000001
0x0000000000000000000000000000001c
0x22080000000000000000000000000001
$ ./test-denbcdq $(seq 0 99)
0x00000000000000000000000000000064
0x0000000000000000000000000000100c
0x22080000000000000000000000000080
--
With "qemu-ppc64le -cpu power9"
--
$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq
0x00000000000000000000000000000000
0x0000000000000000000000000000000c
0x0000000000000000000000000000000c
$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1
0x00000000000000000000000000000001
0x0000000000000000000000000000001c
0x0000000000000000000000000000001c
$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100)
0x00000000000000000000000000000064
0x0000000000000000000000000000100c
0x0000000000000000000000000000100c
--
I started looking at the code, but I got confused rather quickly.
Could be related to endianness? I think denbcdq arrived on the scene
before little-endian was a big deal. Maybe something to do with
utilizing implicit floating-point register pairs... I don't think the
right data is getting to helper_denbcdq, which would point back to the
gen_fprp_ptr uses in dfp-impl.inc.c (GEN_DFP_T_FPR_I32_Rc). (Maybe?)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1841990/+subscriptions
