7 files changed, 490 insertions, 0 deletions
diff --git a/results/classifier/108/other/1922 b/results/classifier/108/other/1922
new file mode 100644
index 000000000..c583a6538
--- /dev/null
+++ b/results/classifier/108/other/1922
@@ -0,0 +1,35 @@
+graphic: 0.838
+performance: 0.750
+device: 0.584
+semantic: 0.541
+other: 0.440
+boot: 0.427
+debug: 0.410
+PID: 0.325
+network: 0.284
+vnc: 0.252
+socket: 0.131
+files: 0.101
+permissions: 0.072
+KVM: 0.053
+
+loongson3-virt machine fails to bring up secondary CPUs
+Description of problem:
+When booting Debian netboot on `loongson3-virt` machine with SMP, cores other than number 0 fail to come up.  Boot without SMP is successful.
+
+I provided the details of the first combination I tested, but I have also tested on an x86_64 host, as well as with Debian 11 (kernel `5.10.0-22-loongson-3`) on both hosts, with the same results.
+Steps to reproduce:
+1.  `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/vmlinuz-6.1.0-10-loongson-3`
+2.  `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/initrd.gz`
+3.  `qemu-system-mips64el -M loongson3-virt -kernel vmlinuz-6.1.0-10-loongson-3 -initrd initrd.gz -append "console=ttyS0" -serial stdio -smp 2`
+Additional information:
+Boot is successful when removing `-smp 2` from command line.  With it present, the following error is in `dmesg` (extends to all other CPUs when a larger SMP value is passed):
+```
+[    2.248229] rcu: Hierarchical SRCU implementation.
+[    2.248446] rcu:     Max phase no-delay instances is 1000.
+[    2.647997] smp: Bringing up secondary CPUs ...
+[    2.749706] Booting CPU#1...
+[    7.093229] CPU1: failed to start
+[    7.096508] smp: Brought up 1 node, 1 CPU
+```
+The boot eventually stalls after this.
diff --git a/results/classifier/108/other/1922252 b/results/classifier/108/other/1922252
new file mode 100644
index 000000000..a19ad354f
--- /dev/null
+++ b/results/classifier/108/other/1922252
@@ -0,0 +1,39 @@
+device: 0.881
+graphic: 0.789
+performance: 0.646
+semantic: 0.627
+other: 0.527
+PID: 0.518
+boot: 0.494
+vnc: 0.462
+permissions: 0.462
+network: 0.424
+KVM: 0.272
+debug: 0.257
+socket: 0.247
+files: 0.170
+
+[feature request] webcam support
+
+Please
+
+I am impatient to get something as "-device usb-webcam" to share dynamically the webcam between host and guest.
+
+Thanks
+
+Have you already tried to simply pass the host USB webcam through to the guest? ... that's likely easier and faster than adding software emulation...
+
+I use
+
+-device usb-host,vendorid=0x046d,productid=0x081b
+
+But in this case the webcam belongs to the guest and the host can't use the webcam.
+
+I want a dynamical sharing like the mouse sharing for example.
+
+Thanks
+
+Ticket has been moved to the new issue tracker at GitLab (thanks!):
+https://gitlab.com/qemu-project/qemu/-/issues/316
+... so I'm closing this ticket on Launchpad now.
+
diff --git a/results/classifier/108/other/1922325 b/results/classifier/108/other/1922325
new file mode 100644
index 000000000..22835cad4
--- /dev/null
+++ b/results/classifier/108/other/1922325
@@ -0,0 +1,45 @@
+other: 0.853
+device: 0.741
+semantic: 0.632
+graphic: 0.514
+performance: 0.507
+PID: 0.351
+network: 0.313
+vnc: 0.309
+permissions: 0.256
+files: 0.244
+debug: 0.234
+boot: 0.228
+socket: 0.181
+KVM: 0.131
+
+s390x-virtio-gpu-ccw module unnecessary?
+
+Hi
+
+Test building latest 6.0.0 release candidate on x86_64 host. A new module has appeared:
+
+/usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so
+
+Unless I'm missing something obvious, it would appear to be only useful on s390x platform.
+
+Why would I need this? For me it doesn't seem to do much:
+
+$ nm -D /usr/lib/qemu/hw-s390x-virtio-gpu-ccw.so
+                 w __cxa_finalize
+                 w __gmon_start__
+                 w _ITM_deregisterTMCloneTable
+                 w _ITM_registerTMCloneTable
+00000000000010f0 T qemu_module_dummy
+0000000000001100 T qemu_stamp_0d4aa0592256528f9885a56f182883665e60f8ec
+
+Bug or ... ?
+
+Thanks
+
+How did you run the configure script? The virtio-gpu-ccw device is part of the qemu-system-s390x emulator, so unless you disabled that build, the module will of course be there.
+
+I only enable a few emulators and qemu-system-s390x isn't one of them.
+
+I was thinking it couldn't be useful on an x86_64 host, even if using the qemu-system-s390x emulator! I guess my understanding was wrong. Will close as invalid.
+
diff --git a/results/classifier/108/other/1922611 b/results/classifier/108/other/1922611
new file mode 100644
index 000000000..9a2323b20
--- /dev/null
+++ b/results/classifier/108/other/1922611
@@ -0,0 +1,107 @@
+other: 0.941
+device: 0.932
+graphic: 0.926
+socket: 0.922
+KVM: 0.906
+semantic: 0.902
+debug: 0.901
+PID: 0.892
+network: 0.891
+permissions: 0.888
+vnc: 0.882
+boot: 0.880
+performance: 0.877
+files: 0.813
+
+Acceptance Tests: migration fails on sparc target
+
+QEMU fails migration when using a sparc target.
+
+This cab be verified/reproduced with the `tests/acceptance/migration.py` test.  Running it with:
+
+ $ make check-venv
+ $ ./tests/venv/bin/avocado --show=test run -p qemu_bin=./qemu-system-sparc tests/acceptance/migration.py:Migration.test_migration_with_tcp_localhost
+
+Right after a QMP `query-migrate` is executed, communication with the monitor is lost:
+
+>>> {'execute': 'query-migrate'}
+<<< {'timestamp': {'seconds': 1617667984, 'microseconds': 330282}, 'event': 'STOP'}
+<<< {'return': {'blocked': False, 'status': 'completed', 'setup-time': 0, 'downtime': 1, 'total-time': 15, 'ram': {'total': 135274496, 'postcopy-requests': 0, 'dirty-sync-count': 2, 'multifd-bytes': 0, 'pages-per-second': 0, 'page-size': 4096, 'remaining': 0, 'mbps': 301.2234666666667, 'transferred': 528703, 'duplicate': 33202, 'dirty-pages-rate': 0, 'skipped': 0, 'normal-bytes': 229376, 'normal': 56}}}
+>>> {'execute': 'query-migrate'}
+
+Reproduced traceback from: /var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.7/site-packages/avocado/core/test.py:756
+Traceback (most recent call last):
+  File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 80, in test_migration_with_tcp_localhost
+    self.do_migrate(dest_uri)
+  File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 69, in do_migrate
+    self.assert_migration(source_vm, dest_vm)
+  File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 41, in assert_migration
+    args=(dst_vm,))
+  File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.7/site-packages/avocado/utils/wait.py", line 34, in wait_for
+    output = func(*args, **kwargs)
+  File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line 31, in migration_finished
+    return vm.command('query-migrate')['status'] in ('completed', 'failed')
+  File "/home/cleber/src/qemu/python/qemu/machine.py", line 572, in command
+    return self._qmp.command(cmd, **qmp_args)
+  File "/home/cleber/src/qemu/python/qemu/qmp.py", line 284, in command
+    ret = self.cmd(cmd, kwds)
+  File "/home/cleber/src/qemu/python/qemu/qmp.py", line 278, in cmd
+    return self.cmd_obj(qmp_cmd)
+  File "/home/cleber/src/qemu/python/qemu/qmp.py", line 256, in cmd_obj
+    self.__sock.sendall(json.dumps(qmp_cmd).encode('utf-8'))
+BrokenPipeError: [Errno 32] Broken pipe 
+
+The qemu-system-sparc binary outputs:
+
+ qemu-system-sparc: warning: nic lance.0 has no peer
+ qemu-system-sparc: Missing section footer for sysbusespscsi
+ qemu-system-sparc: load of migration failed: Invalid argument
+
+6cc88d6bf932a905ce36e933dc078eeb6b54ac92 is the first bad commit:
+
+commit 6cc88d6bf932a905ce36e933dc078eeb6b54ac92
+Author: Mark Cave-Ayland <email address hidden>
+Date:   Thu Mar 4 22:10:34 2021 +0000
+
+    esp: remove dma_left from ESPState
+
+This should be fixed by the following patch:
+
+https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00860.html
+
+
+I can confirm this bug has been fixed.  Relevant test output:
+
+VM launch command: './qemu-system-sparc -display none -vga none -chardev socket,id=mon,path=/tmp/avo_qemu_sock_g0w15g26/qemu-1672256-monitor.sock -mon chardev=mon,mode=control -incoming tcp:localhost:53800 -nodefaults'
+>>> {'execute': 'qmp_capabilities'}
+<<< {'return': {}}
+VM launch command: './qemu-system-sparc -display none -vga none -chardev socket,id=mon,path=/tmp/avo_qemu_sock_ajodgya5/qemu-1672256-monitor.sock -mon chardev=mon,mode=control -nodefaults'
+>>> {'execute': 'qmp_capabilities'}
+<<< {'return': {}}
+>>> {'execute': 'migrate', 'arguments': {'uri': 'tcp:localhost:53800'}}
+<<< {'return': {}}
+>>> {'execute': 'query-migrate'}
+<<< {'return': {'blocked': False, 'status': 'setup'}}
+>>> {'execute': 'query-migrate'}
+<<< {'timestamp': {'seconds': 1618444112, 'microseconds': 790928}, 'event': 'STOP'}
+<<< {'return': {'blocked': False, 'status': 'completed', 'setup-time': 1, 'downtime': 1, 'total-time': 17, 'ram': {'total': 135274496, 'postcopy-requests': 0, 'dirty-sync-count': 2, 'multifd-bytes': 0, 'pages-per-second': 0, 'page-size': 4096, 'remaining': 0, 'mbps': 282.253, 'transferred': 528415, 'duplicate': 33170, 'dirty-pages-rate': 0, 'skipped': 0, 'normal-bytes': 229376, 'normal': 56}}}
+>>> {'execute': 'query-migrate'}
+<<< {'timestamp': {'seconds': 1618444112, 'microseconds': 792061}, 'event': 'RESUME'}
+<<< {'return': {'blocked': False, 'status': 'completed'}}
+>>> {'execute': 'query-migrate'}
+<<< {'return': {'blocked': False, 'status': 'completed', 'setup-time': 1, 'downtime': 1, 'total-time': 17, 'ram': {'total': 135274496, 'postcopy-requests': 0, 'dirty-sync-count': 2, 'multifd-bytes': 0, 'pages-per-second': 0, 'page-size': 4096, 'remaining': 0, 'mbps': 282.253, 'transferred': 528415, 'duplicate': 33170, 'dirty-pages-rate': 0, 'skipped': 0, 'normal-bytes': 229376, 'normal': 56}}}
+>>> {'execute': 'query-migrate'}
+<<< {'return': {'blocked': False, 'status': 'completed'}}
+>>> {'execute': 'query-status'}
+<<< {'return': {'status': 'running', 'singlestep': False, 'running': True}}
+>>> {'execute': 'query-status'}
+<<< {'return': {'status': 'postmigrate', 'singlestep': False, 'running': False}}
+>>> {'execute': 'quit'}
+<<< {'return': {}}
+>>> {'execute': 'quit'}
+<<< {'return': {}}
+DATA (filename=output.expected) => NOT FOUND (data sources: variant, test, file)
+DATA (filename=stdout.expected) => NOT FOUND (data sources: variant, test, file)
+DATA (filename=stderr.expected) => NOT FOUND (data sources: variant, test, file)
+PASS 1-tests/acceptance/migration.py:Migration.test_migration_with_tcp_localhost
+
diff --git a/results/classifier/108/other/1922625 b/results/classifier/108/other/1922625
new file mode 100644
index 000000000..1c453a8fd
--- /dev/null
+++ b/results/classifier/108/other/1922625
@@ -0,0 +1,57 @@
+graphic: 0.808
+device: 0.768
+permissions: 0.723
+performance: 0.689
+files: 0.652
+network: 0.643
+socket: 0.635
+other: 0.580
+PID: 0.478
+boot: 0.423
+semantic: 0.381
+vnc: 0.358
+debug: 0.314
+KVM: 0.278
+
+qemu 5.2.0 configure script explodes when in read only directory
+
+I extracted the qemu 5.2.0 source as one user, and then tried to run `./configure --help` in that directory as a different user. Normal autoconf configure scripts have no problem with this but yours goes into an infinite loop printing nonsense:
+
+Using './build' as the directory for build output
+mkdir: build: Permission denied
+touch: build/auto-created-by-configure: No such file or directory
+./configure: line 37: GNUmakefile: Permission denied
+./configure: line 59: cd: build: No such file or directory
+Using './build' as the directory for build output
+mkdir: build: Permission denied
+touch: build/auto-created-by-configure: No such file or directory
+/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied
+/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory
+Using './build' as the directory for build output
+mkdir: build: Permission denied
+touch: build/auto-created-by-configure: No such file or directory
+/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied
+/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory
+Using './build' as the directory for build output
+mkdir: build: Permission denied
+touch: build/auto-created-by-configure: No such file or directory
+/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied
+/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory
+Using './build' as the directory for build output
+mkdir: build: Permission denied
+touch: build/auto-created-by-configure: No such file or directory
+/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied
+/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory
+Using './build' as the directory for build output
+mkdir: build: Permission denied
+
+etc.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/321
+
+
diff --git a/results/classifier/108/other/1922773 b/results/classifier/108/other/1922773
new file mode 100644
index 000000000..906d82998
--- /dev/null
+++ b/results/classifier/108/other/1922773
@@ -0,0 +1,145 @@
+other: 0.676
+KVM: 0.634
+vnc: 0.602
+debug: 0.538
+graphic: 0.535
+device: 0.529
+PID: 0.526
+semantic: 0.525
+permissions: 0.524
+performance: 0.522
+network: 0.520
+socket: 0.510
+files: 0.498
+boot: 0.487
+
+RISCV32 illegal instruction exception
+
+I'm running a machine learning model on qemu riscv32 and I ran into illegal instruction exception for some reason. I wasn't sure if this is a bug and if so whether it is related to zephyr or qemu, however I'll try to provide as much as information to get a better understanding.
+
+Here is the assembly code that I'm running:
+
+0x8000bd74 <+0>:	lw	a4,0(a0)
+   0x8000bd76 <+2>:	lw	a5,8(a0)
+   0x8000bd78 <+4>:	lw	a0,0(a4)
+   0x8000bd7a <+6>:	lw	a1,0(a5)
+   0x8000bd7c <+8>:	li	a3,0
+   0x8000bd7e <+10>:	j	0x8000bda4 <fused_nn_pad_layout_transform+48>
+   0x8000bd80 <+12>:	addi	a5,a3,-2
+   0x8000bd84 <+16>:	li	a2,27
+   0x8000bd86 <+18>:	bgeu	a2,a5,0x8000bdae <fused_nn_pad_layout_transform+58>
+=> 0x8000bd8a <+22>:	fmv.w.x	fa5,zero
+   0x8000bd8e <+26>:	slli	a5,a3,0x5
+   0x8000bd92 <+30>:	add	a5,a5,a4
+   0x8000bd94 <+32>:	slli	a5,a5,0x2
+   0x8000bd96 <+34>:	add	a5,a5,a1
+   0x8000bd98 <+36>:	fsw	fa5,0(a5)
+   0x8000bd9a <+38>:	addi	a4,a4,1
+   0x8000bd9c <+40>:	li	a5,31
+   0x8000bd9e <+42>:	bge	a5,a4,0x8000bd80 <fused_nn_pad_layout_transform+12>
+   0x8000bda2 <+46>:	addi	a3,a3,1
+   0x8000bda4 <+48>:	li	a5,31
+   0x8000bda6 <+50>:	blt	a5,a3,0x8000bde0 <fused_nn_pad_layout_transform+108>
+   0x8000bdaa <+54>:	li	a4,0
+   0x8000bdac <+56>:	j	0x8000bd9c <fused_nn_pad_layout_transform+40>
+   0x8000bdae <+58>:	li	a5,1
+   0x8000bdb0 <+60>:	bge	a5,a4,0x8000bdd4 <fused_nn_pad_layout_transform+96>
+   0x8000bdb4 <+64>:	li	a5,29
+   0x8000bdb6 <+66>:	blt	a5,a4,0x8000bdda <fused_nn_pad_layout_transform+102>
+   0x8000bdba <+70>:	li	a5,28
+   0x8000bdbc <+72>:	mul	a5,a3,a5
+   0x8000bdc0 <+76>:	add	a5,a5,a4
+   0x8000bdc2 <+78>:	lui	a2,0x40000
+   0x8000bdc6 <+82>:	addi	a2,a2,-58 # 0x3fffffc6
+   0x8000bdca <+86>:	add	a5,a5,a2
+   0x8000bdcc <+88>:	slli	a5,a5,0x2
+   0x8000bdce <+90>:	add	a5,a5,a0
+   0x8000bdd0 <+92>:	flw	fa5,0(a5)
+   0x8000bdd2 <+94>:	j	0x8000bd8e <fused_nn_pad_layout_transform+26>
+   0x8000bdd4 <+96>:	fmv.w.x	fa5,zero
+   0x8000bdd8 <+100>:	j	0x8000bd8e <fused_nn_pad_layout_transform+26>
+   0x8000bdda <+102>:	fmv.w.x	fa5,zero
+   0x8000bdde <+106>:	j	0x8000bd8e <fused_nn_pad_layout_transform+26>
+   0x8000bde0 <+108>:	li	a0,0
+   0x8000bde2 <+110>:	ret
+
+My code breaks on line 0x8000bd8a and then the mcause register is loaded with value 0x02 which translates to illegal instruction. Please let me know if you need more information about this.
+
+I also posted this on ZephyrProject in case it is related to the Zephyr: https://github.com/zephyrproject-rtos/zephyr/issues/34026
+
+I have tested on both QEMU 5.1.0 and 5.2.0 versions. I ran the same code on qemu riscv64 and didn't have the same problem. Here is the assembly code that is generated for the same operation:
+
+=> 0x000000008000b446 <+0>:	ld	a4,0(a0)
+   0x000000008000b448 <+2>:	ld	a5,8(a0)
+   0x000000008000b44a <+4>:	ld	a0,0(a4)
+   0x000000008000b44c <+6>:	ld	a1,0(a5)
+   0x000000008000b44e <+8>:	li	a3,0
+   0x000000008000b450 <+10>:	j	0x8000b476 <fused_nn_pad_layout_transform+48>
+   0x000000008000b452 <+12>:	addiw	a5,a3,-2
+   0x000000008000b456 <+16>:	li	a2,27
+   0x000000008000b458 <+18>:	bgeu	a2,a5,0x8000b480 <fused_nn_pad_layout_transform+58>
+   0x000000008000b45c <+22>:	li	a2,0
+   0x000000008000b460 <+26>:	slliw	a5,a3,0x5
+   0x000000008000b464 <+30>:	addw	a5,a5,a4
+   0x000000008000b466 <+32>:	slli	a5,a5,0x2
+   0x000000008000b468 <+34>:	add	a5,a5,a1
+   0x000000008000b46a <+36>:	sw	a2,0(a5)
+   0x000000008000b46c <+38>:	addiw	a4,a4,1
+   0x000000008000b46e <+40>:	li	a5,31
+   0x000000008000b470 <+42>:	bge	a5,a4,0x8000b452 <fused_nn_pad_layout_transform+12>
+   0x000000008000b474 <+46>:	addiw	a3,a3,1
+   0x000000008000b476 <+48>:	li	a5,31
+   0x000000008000b478 <+50>:	blt	a5,a3,0x8000b4ac <fused_nn_pad_layout_transform+102>
+   0x000000008000b47c <+54>:	li	a4,0
+   0x000000008000b47e <+56>:	j	0x8000b46e <fused_nn_pad_layout_transform+40>
+   0x000000008000b480 <+58>:	li	a5,1
+   0x000000008000b482 <+60>:	bge	a5,a4,0x8000b4a0 <fused_nn_pad_layout_transform+90>
+   0x000000008000b486 <+64>:	li	a5,29
+   0x000000008000b488 <+66>:	blt	a5,a4,0x8000b4a6 <fused_nn_pad_layout_transform+96>
+   0x000000008000b48c <+70>:	li	a5,28
+   0x000000008000b48e <+72>:	mulw	a5,a5,a3
+   0x000000008000b492 <+76>:	addw	a5,a5,a4
+   0x000000008000b494 <+78>:	addiw	a5,a5,-58
+   0x000000008000b498 <+82>:	slli	a5,a5,0x2
+   0x000000008000b49a <+84>:	add	a5,a5,a0
+   0x000000008000b49c <+86>:	lw	a2,0(a5)
+   0x000000008000b49e <+88>:	j	0x8000b460 <fused_nn_pad_layout_transform+26>
+   0x000000008000b4a0 <+90>:	li	a2,0
+   0x000000008000b4a4 <+94>:	j	0x8000b460 <fused_nn_pad_layout_transform+26>
+   0x000000008000b4a6 <+96>:	li	a2,0
+   0x000000008000b4aa <+100>:	j	0x8000b460 <fused_nn_pad_layout_transform+26>
+   0x000000008000b4ac <+102>:	li	a0,0
+   0x000000008000b4ae <+104>:	ret
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1922887 b/results/classifier/108/other/1922887
new file mode 100644
index 000000000..b4df7e6bf
--- /dev/null
+++ b/results/classifier/108/other/1922887
@@ -0,0 +1,62 @@
+device: 0.665
+graphic: 0.601
+performance: 0.559
+semantic: 0.474
+other: 0.461
+permissions: 0.413
+network: 0.395
+files: 0.392
+socket: 0.385
+vnc: 0.381
+boot: 0.374
+PID: 0.302
+KVM: 0.265
+debug: 0.242
+
+STR in Thumb 32 decode problem
+
+Hi 
+
+It seems that QEMU does not have a proper check on the STR instruction in Thumb32 mode.
+
+Specifically, the machine code is 0xf84f0ddd, which is 0b1111 1000 0100 1111 0000 1101 1101 1101. 
+This is an STR (immediate, Thumb) instruction with a T4 encoding scheme.
+
+The symbols is 
+
+Rn = 1111
+Rt = 0000
+P = 1
+U = 0
+W = 1
+
+The decode ASL is below:
+
+if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE STRT;
+if Rn == ‘1101’ && P == ‘1’ && U == ‘0’ && W == ‘1’ && imm8 == ‘00000100’ then SEE PUSH;
+if Rn == ‘1111’ || (P == ‘0’ && W == ‘0’) then UNDEFINED;
+t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm8, 32);
+index = (P == ‘1’); add = (U == ‘1’); wback = (W == ‘1’);
+if t == 15 || (wback && n == t) then UNPREDICTABLE;
+
+When Rn == 1111, it should be an undefined instruction, which should raise SEGILL signal. However, it seems that QEMU does not check this constraint, which should be a bug. Many thanks
+
+Regards
+Muhui
+
+NB that for Arm mode the equivalent case is UNPREDICTABLE only in the writeback case (and has defined behaviour for non-writeback), so we need to enforce the UNDEF on rn==15 for Thumb decode only.
+
+
+Patch sent to list: if you could test it against whatever your test case was that would be helpful.
+https://<email address hidden>/
+
+PS: out of interest, why/how were you checking should-UNDEF cases ?
+
+
+We just test the patched version. It looks well. Now QEMU would raise SEGILL signals, which should be the right behavior.
+
+We are not checking should-UNDEF cases in particular. This is a case we observed and checked manually when doing a research project with QEMU. 
+
+Patch has been merged:
+https://gitlab.com/qemu-project/qemu/-/commit/8196fe9d83d6519128b5
+