semantic: 0.135
other: 0.109
debug: 0.101
graphic: 0.097
device: 0.081
PID: 0.067
permissions: 0.064
socket: 0.061
vnc: 0.059
performance: 0.057
files: 0.052
network: 0.045
boot: 0.044
KVM: 0.027
semantic: 0.344
other: 0.108
debug: 0.086
files: 0.076
PID: 0.060
socket: 0.051
device: 0.045
boot: 0.044
vnc: 0.043
network: 0.037
performance: 0.037
KVM: 0.036
permissions: 0.020
graphic: 0.014

[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.