peripherals: 0.945
debug: 0.926
semantic: 0.924
graphic: 0.904
performance: 0.900
device: 0.892
architecture: 0.889
arm: 0.871
assembly: 0.863
PID: 0.837
permissions: 0.832
register: 0.829
risc-v: 0.811
hypervisor: 0.802
socket: 0.799
vnc: 0.799
files: 0.785
network: 0.764
boot: 0.751
user-level: 0.746
ppc: 0.733
mistranslation: 0.690
VMM: 0.657
kernel: 0.649
TCG: 0.629
virtual: 0.579
x86: 0.525
KVM: 0.493
i386: 0.361

[feature request] awareness of instructions that are well emulated

While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64). Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed.

Here is a pull request for the zig language that runs into this problems in qemu https://github.com/ziglang/zig/pull/2945/

I have more code for validation if someone is working on this.

On Sun, 3 Nov 2019 at 04:41, Shawn Landden <email address hidden> wrote:
> While qemu's scalar emulation tends to be excellent, qemu's SIMD
> emulation tends to be incorrect (except for arm64 from x86_64)--i have
> found this both for mipsel and arm32. Until these code paths are
> audited, which is probably a large job, it would be nice if qemu knew
> its emulation of this class of instructions was not very good, and thus
> it would give up on finding these instructions if a "careful" operation
> is passed.

I'm not sure how this could work. If QEMU reports (via ID regs
etc) to the guest that it supports instruction class X when it
does not, that's a bug and we should fix it. If QEMU implements
an instruction but gets it wrong, that's also a bug and we should
fix it. In both cases, we'd need to have specific bug reports,
ideally with reproduce-cases. But we don't really have "known
areas where the emulation is incorrect" that we could somehow
differentiate and disable (except at a very vague level, eg
"probably better not to rely on the x86 emulation").

You might be able by careful selection of the cpu type to avoid
CPUs which implement vector operations. Some architectures
also allow individual CPU features to be disabled with extra
'-foo' qualifiers on the -cpu argument.

For Arm in particular (32 or 64 bit) I believe our implementation
should be correct and am happy to look at bug reports for that.

thanks
-- PMM


ok, here is a double precision exponent implementation that works on arm32 hardware, but fails in qemu with the wrong checksum. https://github.com/shawnl/zig-libmvec/blob/master/exp.zig

You need to build zig with the above patch-set.

I guess I am starting from a pessimistic perspective, where I have only ever seen SIMD work with arm64 emulation (which is quite new), and am sorry for that.

Can you please provide a binary (preferably statically built or with required shared libraries attached)?

Thanks,

Laurent

example binary doing double-precision exponent on 16 megs

expected output:

checksum: f181b401cd42aa7b

actual output:

checksum: 4004022b0ba624fb


Here is the same thing compiled with optimizations on

appears the random number generator produces different results on 32-bit arches, while my code seems to work fine in qemu

I can confirm bench_simple gives the same result on both qemu-arm and my aarch32 hardware.

Can you provide a clearer repro example of what doesn't wirk on mipsel platform?

In last two QEMU releases mips (Wave) developers went to great lenghts making sure both mips SIMD and mips FP instructions (in both scalar and vector variants) are emulated properly. Some of the unit tests were published, but also many were left internal, and there are many integration tests devised and run as well. We in mips (Wave) consider these two areas well tested. Still, we'll consider seriuosly fixing your example, if you prove experimentally that this is a mips-related bug, but just provides us with a reasonably convenient repro procedure.