8 files changed, 350 insertions, 0 deletions
diff --git a/results/classifier/108/other/144 b/results/classifier/108/other/144
new file mode 100644
index 000000000..5df7c0567
--- /dev/null
+++ b/results/classifier/108/other/144
@@ -0,0 +1,16 @@
+device: 0.823
+performance: 0.572
+other: 0.486
+boot: 0.463
+network: 0.416
+socket: 0.383
+graphic: 0.373
+semantic: 0.345
+debug: 0.172
+vnc: 0.163
+PID: 0.132
+permissions: 0.124
+files: 0.015
+KVM: 0.007
+
+Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up
diff --git a/results/classifier/108/other/1440843 b/results/classifier/108/other/1440843
new file mode 100644
index 000000000..388168bf4
--- /dev/null
+++ b/results/classifier/108/other/1440843
@@ -0,0 +1,53 @@
+PID: 0.642
+graphic: 0.632
+device: 0.620
+socket: 0.524
+other: 0.478
+performance: 0.460
+network: 0.399
+vnc: 0.390
+KVM: 0.339
+debug: 0.327
+boot: 0.301
+files: 0.300
+semantic: 0.266
+permissions: 0.249
+
+Guest WinXP crashes when trying to use a USB spectrometer
+
+I'm using Amadeus spectrometer (OceanOptics USB250) via Windows-based software "Quantum". I've tried six ways of attaching it to QEMU:
+
+1. command line parameter "-device usb-host,hostbus=3,hostaddr=25"
+2. command line parameter "-device usb-host,vendorid=0x2457,productid=0x1030"
+3. command line parameter "-usbdevice host:2457:1030
+4. command line parameter "-usbdevice host:3.25"
+5. qemu console command "usb_add host:2457:1030"
+5. qemu console command "usb_add host:3.25"
+
+From these, only "-device ..." options work, i.e. numbers 1 and 2 in the list above, and all others lead to IRQL_NOT_LESS_OR_EQUAL BSOD in usbuhci.sys when I launch Quantum, which tries to start acquiring spectra.
+
+I've also tried to reproduce the crash with a flash drive, but couldn't — it seems to work reliably in this case.
+
+Which version is used? Try the latest QEMU or at least QEMU 2.0.
+The behavior sounds like a pretty old QEMU version.
+Additionally, enable the EHCI controller (see example in the docs subdirectory).
+It it working on a native Windows XP?
+
+I was using QEMU from git, v2.3.0-rc2, when reporting this bug. And this is the same since much earlier (about a year older) version. And of course I do enable EHCI controller via `-device usb-ehci`. And checked it with native Windows XP, where the device works with no problem. Actually, as I said in OP, `-device hsb-host,...` options work in QEMU too, but the others like `-usbdevice host...` and `usb_add host...` don't.
+
+Please check that the devices get added to the EHCI bus and not to the UHCI.
+As far as I know the -usb* commands are deprecated. The functions behind the -device usb* and -usb* should behave the same.
+
+Indeed, the device appears added to the UHCI in both crashing cases and to EHCI in the working case. Also, sometimes instead of BSOD of guest OS I get abort of QEMU:
+
+qemu-system-i386: hw/usb/core.c:735: usb_ep_get: Assertion `pid == 0x69 || pid == 0xe1' failed.
+/usr/bin/qemuxp: line 4: 13514 Aborted                 (core dumped) qemu-system-i386 /home/ruslan/iso/Windoze/qemuxp.img -m 512 -display sdl -vga vmware -enable-kvm -usb -device usb-ehci $*
+
+here $* stands for
+
+-snapshot -hdb ~/iso/ntfs-data.img
+
+and the crash was triggered by using usb_add command in QEMU terminal and then attempting to access the device from WinXP.
+
+"-usbdevice host" and "usb_add host" have been removed with QEMU 2.12, so marking this bug as Wont-Fix.
+
diff --git a/results/classifier/108/other/1441 b/results/classifier/108/other/1441
new file mode 100644
index 000000000..e2003c512
--- /dev/null
+++ b/results/classifier/108/other/1441
@@ -0,0 +1,49 @@
+vnc: 0.812
+graphic: 0.732
+device: 0.715
+network: 0.594
+PID: 0.548
+files: 0.540
+socket: 0.471
+debug: 0.436
+permissions: 0.428
+semantic: 0.412
+performance: 0.403
+boot: 0.340
+other: 0.142
+KVM: 0.074
+
+Assertion failure when executing RISC-V vfncvt.rtz.x.f.w instruction
+Description of problem:
+When emulating the `vfncvt.rtz.x.f.w` instruction, QEMU crashes with an assertion failure at `target/riscv/translate.c:211`, complaining that ```decode_save_opc: Assertion `ctx->insn_start != NULL' failed.```
+
+It appears this problem first emerged with https://gitlab.com/qemu-project/qemu/-/commit/a9814e3e08d2aacbd9018c36c77c2fb652537848
+Steps to reproduce:
+The following C program triggers the assertion failure when built a sufficiently recent version of the Clang cross compiler (in my case 15.0.6):
+```
+/* test.c */
+#include <riscv_vector.h>
+
+#define LEN 4
+
+int main(int argc, char *argv[]) {
+  double in[LEN];
+  int out[LEN];
+
+  vfloat64m1_t vf = vle64_v_f64m1(in, LEN);
+  vint32mf2_t vi = vfncvt_rtz_x_f_w_i32mf2(vf, LEN);
+  vse32_v_i32mf2(out, vi, LEN);
+
+  return 0;
+}
+```
+
+The above `test.c` can be compiled and run as follows:
+```
+clang -O3 -march=rv64gcv -static test.c
+qemu-riscv64 -cpu "rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0" a.out
+qemu-riscv64: ../target/riscv/translate.c:211: decode_save_opc: Assertion `ctx->insn_start != NULL' failed.
+Segmentation fault (core dumped)
+```
+Additional information:
+
diff --git a/results/classifier/108/other/1443 b/results/classifier/108/other/1443
new file mode 100644
index 000000000..2e996f617
--- /dev/null
+++ b/results/classifier/108/other/1443
@@ -0,0 +1,16 @@
+device: 0.770
+performance: 0.595
+other: 0.528
+network: 0.463
+files: 0.428
+permissions: 0.392
+vnc: 0.379
+semantic: 0.375
+debug: 0.358
+graphic: 0.355
+socket: 0.245
+boot: 0.241
+PID: 0.237
+KVM: 0.044
+
+site download.qemu.org | non-adequate function applied for sorting by date-time
diff --git a/results/classifier/108/other/1444 b/results/classifier/108/other/1444
new file mode 100644
index 000000000..b68ccb9fa
--- /dev/null
+++ b/results/classifier/108/other/1444
@@ -0,0 +1,57 @@
+other: 0.860
+permissions: 0.812
+performance: 0.779
+debug: 0.758
+graphic: 0.749
+device: 0.730
+semantic: 0.714
+vnc: 0.711
+KVM: 0.687
+boot: 0.672
+PID: 0.671
+files: 0.649
+socket: 0.645
+network: 0.601
+
+ld.so on aarch64 crashes (SIGSEGV) qemu-aarch64-static to verify attached executable
+Description of problem:
+I'm currently managing an automation to build a linux distribution from nothing.
+The issues is when I try to cross compile gobject-introspection for aarch64 (it is currently working on arm) because the g-ir-compile phase requires a binary verification using ld-linux-aarch64-so-1 --verify GLib-2.0 process used by ldd, that crashes qemu-aarch64-static.
+Original command is: ${SYSROOT}/lib/ld-linux-aarch64-so-1 --verify ${HOME}/builds/gobject-introspection_1.75.4/tmp-introspectnpyrhpje/GLib-2.0.
+I simplified the problem bringing out the ld.so and GLib-2.0 binary to obtain the same result.
+
+This happens with glibc 2.35 and glibc 2.36 on aarch64 built with a gcc-12.2 cross compiler (x86 -> aarch64).
+
+[GLib-2.0](/uploads/47932b18278835fb13ef0de4c34872fa/GLib-2.0)
+
+[ld-linux-aarch64.so.1](/uploads/0ee01949285bea8ccfcebdc88a1d5b33/ld-linux-aarch64.so.1)
+
+I tried to debug the SIGSEGV but it's out completely out of my capacity.
+Steps to reproduce:
+1. Copy the 2 attached files in a directory:
+2. Run: qemu-aarch64-static ./ld-linux-aarch64.so.1 --verify ./GLib-2.0
+3. Result: Segmentation fault.
+Additional information:
+I attach the output of gdb after install qemu debug symbols:
+
+```
+Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault.
+0x0000000000401088 in ?? ()
+(gdb) bt
+#0  0x0000000000401088 in ?? ()
+#1  0x00000000006aa439 in g_malloc0 ()
+#2  0x000000000061bb4b in page_find_alloc (index=index@entry=1024, alloc=alloc@entry=1)
+    at ../accel/tcg/translate-all.c:494
+#3  0x000000000061db12 in page_set_flags (start=start@entry=4194304, end=end@entry=4206592, flags=9, flags@entry=73)
+    at ../accel/tcg/translate-all.c:2288
+#4  0x0000000000629f10 in target_mmap (start=<optimized out>, start@entry=4194304, len=<optimized out>,
+    len@entry=12288, target_prot=target_prot@entry=1, flags=2066, fd=fd@entry=3, offset=offset@entry=0)
+    at ../linux-user/mmap.c:629
+#5  0x0000000000641e1d in do_syscall1 (cpu_env=0x9e8c10, num=222, arg1=4194304, arg2=12288, arg3=1,
+    arg4=<optimized out>, arg5=3, arg6=0, arg8=<optimized out>, arg7=<optimized out>) at ../linux-user/syscall.c:9961
+#6  0x0000000000644c8c in do_syscall (cpu_env=cpu_env@entry=0x9e8c10, num=222, arg1=4194304, arg2=12288, arg3=1,
+    arg4=2066, arg5=3, arg6=0, arg7=0, arg8=0) at ../linux-user/syscall.c:13203
+#7  0x000000000040fca8 in cpu_loop (env=env@entry=0x9e8c10) at ../linux-user/aarch64/cpu_loop.c:93
+#8  0x000000000040267f in main (argc=<optimized out>, argv=0x7fffffffdfc8, envp=<optimized out>)
+    at ../linux-user/main.c:897
+```
diff --git a/results/classifier/108/other/1447 b/results/classifier/108/other/1447
new file mode 100644
index 000000000..dd5229572
--- /dev/null
+++ b/results/classifier/108/other/1447
@@ -0,0 +1,22 @@
+device: 0.764
+debug: 0.702
+graphic: 0.576
+network: 0.394
+performance: 0.347
+boot: 0.324
+semantic: 0.256
+files: 0.222
+vnc: 0.222
+socket: 0.207
+permissions: 0.165
+PID: 0.145
+KVM: 0.113
+other: 0.090
+
+riscv: reset_vec uses CSR even when disabled causing inability to boot
+Steps to reproduce:
+1. Run any rv32 binary with `./qemu-system-riscv32 -cpu rv32,d=off,f=off,Zicsr=off`
+
+To view using GDB use `./qemu-system-riscv32 -cpu rv32,d=off,f=off,Zicsr=off -S -s`
+`gdb-multiarch --ex="target remote localhost:1234" -ex "layout asm"`
+then type `si` till $pc jumps to zero on `csrr   a0, mhartid`
diff --git a/results/classifier/108/other/1449 b/results/classifier/108/other/1449
new file mode 100644
index 000000000..69a3e8cdf
--- /dev/null
+++ b/results/classifier/108/other/1449
@@ -0,0 +1,20 @@
+device: 0.715
+other: 0.583
+graphic: 0.491
+socket: 0.454
+network: 0.426
+files: 0.373
+semantic: 0.348
+boot: 0.310
+vnc: 0.290
+debug: 0.173
+PID: 0.165
+performance: 0.150
+KVM: 0.094
+permissions: 0.042
+
+RISCV: wrong check for vector extension ELEN value.
+Description of problem:
+When checking if the vector extension ELEN value is in the range [8, 64], the lower bound check uses the `vlen` field instead of the `elen` one: https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/cpu.c#L885.
+Additional information:
+This is basically just a typo I found while reading the code, I do not have a real case scenario which resulted in this check to fail.
diff --git a/results/classifier/108/other/1449687 b/results/classifier/108/other/1449687
new file mode 100644
index 000000000..fb8bc7928
--- /dev/null
+++ b/results/classifier/108/other/1449687
@@ -0,0 +1,117 @@
+permissions: 0.726
+semantic: 0.686
+other: 0.661
+debug: 0.644
+KVM: 0.599
+performance: 0.576
+boot: 0.569
+network: 0.565
+PID: 0.559
+vnc: 0.558
+graphic: 0.537
+device: 0.510
+files: 0.410
+socket: 0.390
+
+block migration of qcow2 VMs copies all empty space
+
+I'm running openstack 2012.1 'icehouse' which, ultimately, calls down into qemu-system-x86 2.0.0+dfsg-2ubuntu1.10.
+
+I primed the process by copying all necessary base images onto the destination host.  Nonetheless, post-migration instances are much larger than the original image; the copy duplicated all the empty space that ought to have remained copy-on-write.
+
+It looks like there was some attempt to address this issue in the past (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1058173 ) but perhaps I'm conflating two different issues.
+
+Did you paste the wrong Red Hat bugzilla link?
+https://bugzilla.redhat.com/show_bug.cgi?id=1058173
+
+I don't see how this BZ is related to expanded disk image files after migration.
+
+You're right, clearly that was a c/p fail.  I can't for the life of me find the bug that I was trying to refer to :(
+
+I found a relevant Fedora bug here:
+https://bugzilla.redhat.com/show_bug.cgi?id=817700
+
+There is a patch available: https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg03742.html (and those which are mentioned in the responses)
+
+This patch does not help us. When migrating, the same drives become thick ...
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+On the source :
+
+# qemu-img info VM.img 
+image: VM.img
+file format: raw
+virtual size: 20G (21474836480 bytes)
+disk size: 3.4G
+
+On the target:
+
+# qemu-img info VM.img 
+image: VM.img
+file format: raw
+virtual size: 20G (21474836480 bytes)
+disk size: 20G
+
+
+I also tried with qcow2 format but it's the same bug.
+
+All kvm migration drop sparse disk image !
+
+How can we resolve this ? 
+Does a workaround exist ?
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1219541
+https://bugzilla.redhat.com/show_bug.cgi?id=1248996
+https://bugzilla.redhat.com/show_bug.cgi?id=1090093
+https://bugzilla.redhat.com/show_bug.cgi?id=817700
+
+I forgot to inform my test envrionement : 
+
+Ubuntu Xenial
+qemu-kvm version 2.5
+libvirt-bin version 1.3.1
+
+Can you please reproduce bugs with the latest version of QEMU, i.e. currently v2.11 ? Old versions like 2.5 are not supported by the upstream QEMU project anymore, and bugs from such old versions might have been fixed already. (Otherwise, if you're only interested in the Ubuntu binary, please open a bug against the Ubuntu QEMU package instead)
+
+Well, if you had a closer look at the BZs that you've quoted, especially BZ 1219541, you should have seen that this problem apparently has been solved in upstream QEMU version 2.9 or 2.10. So it's really just about the backlevel version 2.5 that you're using. I'm re-assigning this ticket to the Ubuntu package, maybe they can fix it for you.
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+I tried with qemu 2.10 and libvirt 3.6.0: not bug, it works.
+
+I tried with raw and qcow2 format, both works.
+
+I used this repository: https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/pike-staging
+
+But it's a staging version, i didn't find a stable qemu/libvirt repository for Ubuntu Xenial with those versions
+
+Maybe i can use this repository : 
+
+http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/xenial-updates
+
+Just want to throw a comment on here too. We are also effected by this. We are in the process of switching to KVM and lose thin/sparse disks on live migration. Unfortunately we need this to work.
+
+We are using:
+* Ubuntu Xenial
+* qemu-kvm version 2.5
+* libvirt-bin version 1.3.1
+* Using local storage
+
+I've tried qcow2 and raw formats with files and even a thin LVM pool. We have had the same outcome every time.
+
+virsh migrate --live --persistent --undefinesource --copy-storage-all (and --copy-storage-inc) fails to keep the sparse file.
+
+I've had no luck using rsync or tar to pre-copy the disks either.
+
+Building libvirt (v3.10.0) and qemu (v12.11) from source solved the issue but is not practical for us to do this in our environment. Using the repository above that Anthony mentioned is a temporary fix in my opinion, it's using libvirt v3.6.0 and qemu v12.10.1 and also solves the migration bug. Ubuntu should release a patch for Xenial. It appears Bionic will include the working versions.
+
+Please backport qemu 2.10+ and libvirt 3.6+.  Having issues with migration of thin provisioned disks without shared storage.  Tried qcow/raw/lvm thin all with the same results.  Can confirm that the versions from https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/pike-staging do fix the issues at least with qcow disks.
+
+The new versions are made available via the cloud-archive already on a regular base.
+We backport isolated fixed that have a low regression risk for other users, but not sull versions per the SRU Policy (https://wiki.ubuntu.com/StableReleaseUpdates).
+
+Since it seems it was identified that the version in Bionic is good, but the new feature is huge and unlikely to be backported I'll set the tasks up that way.
+
+I consider it unlikely, but if there is a minor set of commits assocuated that might be backportable please speak up and set the Xenial task back to new when providing the commits needed.
+