diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-06 09:15:28 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-06 09:15:28 +0000 |
| commit | d0af66c2d76056b173294fc81cdfc47305e4e2a7 (patch) | |
| tree | 04414c325574a99bc3cd3f1f354786f1b24f06de /results/classifier/111/semantic | |
| parent | 140a79ffee69434ba0fbfde4cefb9fe5e82d93b4 (diff) | |
| download | emulator-bug-study-d0af66c2d76056b173294fc81cdfc47305e4e2a7.tar.gz emulator-bug-study-d0af66c2d76056b173294fc81cdfc47305e4e2a7.zip | |
add new results
Diffstat (limited to 'results/classifier/111/semantic')
| -rw-r--r-- | results/classifier/111/semantic/1497711 | 66 | ||||
| -rw-r--r-- | results/classifier/111/semantic/1675333 | 45 | ||||
| -rw-r--r-- | results/classifier/111/semantic/1798659 | 69 | ||||
| -rw-r--r-- | results/classifier/111/semantic/1851095 | 101 |
4 files changed, 281 insertions, 0 deletions
diff --git a/results/classifier/111/semantic/1497711 b/results/classifier/111/semantic/1497711 new file mode 100644 index 00000000..38ebef6e --- /dev/null +++ b/results/classifier/111/semantic/1497711 @@ -0,0 +1,66 @@ +semantic: 0.336 +other: 0.141 +graphic: 0.067 +vnc: 0.058 +device: 0.056 +PID: 0.056 +network: 0.048 +files: 0.046 +debug: 0.045 +socket: 0.040 +permissions: 0.034 +performance: 0.031 +boot: 0.023 +KVM: 0.018 +semantic: 0.167 +files: 0.154 +debug: 0.107 +performance: 0.102 +other: 0.088 +device: 0.077 +PID: 0.071 +boot: 0.055 +network: 0.046 +vnc: 0.035 +socket: 0.033 +KVM: 0.029 +permissions: 0.019 +graphic: 0.016 + +tests/libqos/ahci.c:745: redundant condition ? + +[qemu/tests/libqos/ahci.c:745]: (style) Redundant condition: props.ncq. '!props.ncq || (props.ncq && props.lba48)' is equivalent to '!props.ncq || props.lba48' + + g_assert(!props->ncq || (props->ncq && props->lba48)); + +On Sun, Sep 20, 2015 at 10:08:49AM -0000, dcb wrote: +> Public bug reported: +> +> [qemu/tests/libqos/ahci.c:745]: (style) Redundant condition: props.ncq. +> '!props.ncq || (props.ncq && props.lba48)' is equivalent to '!props.ncq +> || props.lba48' +> +> g_assert(!props->ncq || (props->ncq && props->lba48)); + +CCing John Snow, AHCI maintainer + + +Fixed in: + +commit 3d937150dce20cb95cbaae99b6fd48dca4261f32 +Author: John Snow <email address hidden> +Date: Mon Oct 5 12:00:55 2015 -0400 + + qtest/ahci: fix redundant assertion + + Fixes https://bugs.launchpad.net/qemu/+bug/1497711 + + (!ncq || (ncq && lba48)) is the same as + (!ncq || lba48). + + The intention is simply: "If a command is NCQ, + it must also be LBA48." + + Signed-off-by: John Snow <email address hidden> + Message-id: <email address hidden> + diff --git a/results/classifier/111/semantic/1675333 b/results/classifier/111/semantic/1675333 new file mode 100644 index 00000000..58936c87 --- /dev/null +++ b/results/classifier/111/semantic/1675333 @@ -0,0 +1,45 @@ +semantic: 0.185 +other: 0.109 +files: 0.107 +device: 0.107 +graphic: 0.076 +socket: 0.062 +network: 0.060 +debug: 0.057 +vnc: 0.055 +PID: 0.052 +boot: 0.045 +permissions: 0.037 +performance: 0.028 +KVM: 0.021 +semantic: 0.181 +debug: 0.159 +other: 0.140 +files: 0.136 +device: 0.075 +performance: 0.066 +network: 0.061 +PID: 0.058 +boot: 0.032 +socket: 0.023 +graphic: 0.023 +permissions: 0.022 +KVM: 0.013 +vnc: 0.012 + +qemu-system crashes when use sheepdog driver + +Already solved. + + + +why this bug is Invalid? +U can view my upload file and qemu/block/sheepdog.c differences. + +Sorry, but if I read a bug description that says "already solved", without any proper description how you ran qemu, which version you were using, etc., then the bug ticket does not make much sense. +So please provide a proper description, and if you've already got a fix, send a patch (diff!) to the qemu-devel mailing list instead of attaching a .c file to the bug tracker. See http://wiki.qemu-project.org/Contribute/SubmitAPatch for details. Thanks. + +Have you ever sent a patch to the qemu-devel mailing list? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/111/semantic/1798659 b/results/classifier/111/semantic/1798659 new file mode 100644 index 00000000..6cd5bbae --- /dev/null +++ b/results/classifier/111/semantic/1798659 @@ -0,0 +1,69 @@ +semantic: 0.330 +other: 0.193 +graphic: 0.093 +PID: 0.061 +vnc: 0.051 +device: 0.051 +socket: 0.036 +files: 0.036 +debug: 0.032 +network: 0.028 +performance: 0.027 +boot: 0.026 +permissions: 0.025 +KVM: 0.010 +semantic: 0.310 +KVM: 0.179 +files: 0.158 +debug: 0.130 +performance: 0.046 +other: 0.044 +PID: 0.022 +device: 0.020 +network: 0.020 +permissions: 0.017 +vnc: 0.015 +boot: 0.015 +socket: 0.012 +graphic: 0.012 + +Replace comma with semicolon in trace/simple.c + +In the master branch in trace/simple.c in writeout_thread (https://github.com/qemu/qemu/blob/master/trace/simple.c#L174) we currently have: + dropped.rec.length = sizeof(TraceRecord) + sizeof(uint64_t), + dropped.rec.pid = trace_pid; + +It seems to me like a typo that the first line ends with a comma. +Currently this causes no harm, but I think this should be fixed. + +It's perfect valid C to terminate a statement with "," instead of ";" - it just has a different meaning. Consider this: + +#include <stdio.h> + +int main() +{ + if (0) + printf("Hello!\n"), + + printf("Good bye!\n"); + + return 0; +} + +At a first glance, you'd expect this program to print "Good bye!" - but it does not. Actually, the "," is used here to put the two printf statements into the same block, so this program is the same as: + + if (0) { + printf("Hello!\n"); + printf("Good bye!\n"); + } + +Thus, there is no real bug in simple.c here, but of course it would be better style to clean this up and use ";" instead. + +By the way, two lines earlier there is another line ending in ",": + + dropped.rec.event = DROPPED_EVENT_ID, + +Fixed in commit 7ff5920717d413d8b7c3ba13d9, which will be in the upcoming 4.0 release. + + + diff --git a/results/classifier/111/semantic/1851095 b/results/classifier/111/semantic/1851095 new file mode 100644 index 00000000..eb5ab82b --- /dev/null +++ b/results/classifier/111/semantic/1851095 @@ -0,0 +1,101 @@ +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. + |
