9 files changed, 218 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/device/182 b/results/classifier/gemma3:12b/device/182
new file mode 100644
index 00000000..a0683388
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/182
@@ -0,0 +1,2 @@
+
+qemu-xhci device should detect if libusb host supports streams
diff --git a/results/classifier/gemma3:12b/device/1820686 b/results/classifier/gemma3:12b/device/1820686
new file mode 100644
index 00000000..30520b37
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1820686
@@ -0,0 +1,6 @@
+
+risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0'
+
+QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded.
+
+I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1821054 b/results/classifier/gemma3:12b/device/1821054
new file mode 100644
index 00000000..cfdd7762
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1821054
@@ -0,0 +1,5 @@
+
+qemu segfault error when using pcie to dual pci adapter
+
+All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor"
+I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1824528 b/results/classifier/gemma3:12b/device/1824528
new file mode 100644
index 00000000..d18408bc
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1824528
@@ -0,0 +1,19 @@
+
+qemu fails to compile on gcc 9 `error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member]`
+
+Qemu compilation fails with below error on ppc64le host with gcc 9(9.0.1 20190328)
+repo: https://github.com/qemu/qemu.git
+branch: master
+commit e1be98540ee672ef93292b65a986055512237c35
+
+
+  CC      net/dump.o
+hw/usb/dev-mtp.c: In function ‘usb_mtp_write_metadata’:
+hw/usb/dev-mtp.c:1708:36: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
+ 1708 |                             dataset->filename);
+      |                             ~~~~~~~^~~~~~~~~~
+cc1: all warnings being treated as errors
+  CC      net/eth.o
+make: *** [/home/kvmci/qemu-main/rules.mak:69: hw/usb/dev-mtp.o] Error 1
+make: *** Waiting for unfinished jobs....
+  CC      net/announce.o
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1824744 b/results/classifier/gemma3:12b/device/1824744
new file mode 100644
index 00000000..5a746ce7
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1824744
@@ -0,0 +1,8 @@
+
+ivshmem PCI device exposes wrong endianness on ppc64le
+
+On a ppc64le host with a ppc64le guest running on QEMU 3.1.0 when an ivshmem device is used, the ivshmem device appears to expose the wrong endianness for the values in BAR 0.
+
+For example, when the guest is assigned an ivshmem device ID of 1, the IVPosition register (u32, offset 8 in BAR 0) returns 0x1000000 instead of 0x1. I tested on an x86_64 machine and the IVPosition reads 0x1 as expected.
+
+It seems possible that there's a ppc64*==bigendian assumption somewhere that is erroneously affecting ppc64le.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1826827 b/results/classifier/gemma3:12b/device/1826827
new file mode 100644
index 00000000..4f49f4b7
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1826827
@@ -0,0 +1,56 @@
+
+dtc crash; pnv_dt_serial cannot find lpc's phandle
+
+pnv_dt_serial has a line which is supposed to set the interrupt-parent of the "isa-serial@i3f8" node to the phandle of "lpc@0". 
+
+To that end, it calls fdt_get_phandle as shown below:
+_FDT((fdt_setprop_cell(fdt, node, "interrupt-parent", fdt_get_phandle(fdt, lpc_off))));
+
+The function fdt_get_phandle fails to find the property "phandle" (or "linux,phandle") for the lpc node. Consequently, pnv_dt_serial sets the interrupt-parent to 0.
+
+
+
+
+
+Now boot the qemu-system-ppc64 powernv machine, and extract the fdt by using the qemu monitor's pmemsave command, taking help of the OPAL firmware's messages to locate the fdt in the physical ram.
+
+qemu-system-ppc64 -m 1g -machine powernv,num-chips=1 \  
+-cpu power9 -smp 2,cores=2,threads=1 -accel tcg,thread=multi \                  
+-kernel ./vmlinux \                                                             
+-append 'disable_radix' \                                                       
+-serial mon:stdio -nographic -nodefaults 
+
+The kernel vmlinux contains nothing but a single instruction which loops infintely, so that we can gather OPAL's messages, especially the one below:
+
+[    0.168845963,5] INIT: Starting kernel at 0x20000000, fdt at 0x304b0b70 14404 bytes
+
+
+
+
+
+Once the fdt is dumped to a file, run the following:
+
+'dtc -O dtb -I dts -o out.dts dtb'
+
+
+After a few warnings, the dtc application crashes because an assertion was fired.
+
+1.dts: Warning (unit_address_vs_reg): /lpcm-opb@6030000000000/lpc@0: node has a unit name, but no reg property
+1.dts: Warning (simple_bus_reg): /lpcm-opb@6030000000000/lpc@0: missing or empty reg/ranges property
+1.dts: Warning (avoid_unnecessary_addr_size): /ibm,opal: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
+1.dts: Warning (unique_unit_address): /interrupt-controller@0: duplicate unit-address (also used in node /memory@0)
+1.dts: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 'stdout-path' instead
+dtc: livetree.c:575: get_node_by_phandle: Assertion `generate_fixups' failed.
+Aborted (core dumped)
+
+
+
+The assertion is fired because get_node_by_phandle receives a phandle value of 0, which is unexpected, unless fixups are needed (They are not, when running the dtc command).
+
+
+
+
+Back inside pnv_dt_serial, if the line that sets "interrupt-parent" for the serial device node is commented out, the dtc crash is prevented. Looking at hw/ppc/e500.c, it takes care of allocating necessary phandle values in the nodes, so a similar method can be adopted for powernv.
+
+
+The dtb is attached.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1828508 b/results/classifier/gemma3:12b/device/1828508
new file mode 100644
index 00000000..309864c6
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1828508
@@ -0,0 +1,25 @@
+
+qemu-img created VMDK files lead to "Unsupported or invalid disk type 7"
+
+Using qemu-img version 3.1.50 (v3.1.0-13607-geb2db0f7ba-dirty) on a Windows 10 machine.
+
+Converting a VHD to VMDK.
+qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic -p "c:\test\AppD-VM01.vmdk"
+
+I have also tried:
+qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic,hwversion=6 -p "c:\test\AppD-VM01.vmdk"
+
+Attaching the VMDK to a VM in VMware produces the following error when powering on.
+
+Power On virtual machine:Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+Target: MyVM1
+vCenter Server: VCENTER
+Error Stack
+An error was received from the ESX host while powering on VM MyVM1.
+Failed to start the virtual machine.
+Module DevicePowerOn power on failed. 
+Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' 
+Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+
+
+If I do not specify the adapter type, it creates an IDE VMDK which works perfectly.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1828608 b/results/classifier/gemma3:12b/device/1828608
new file mode 100644
index 00000000..7ab30bd4
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1828608
@@ -0,0 +1,8 @@
+
+Chardev websocket might not support pasting more than a few chars
+
+When sending more than 4-5 characters on the websocket serial console (with pasting for example), the guest might not receive all of them, or worse interpret the input as Magic SysRq keys.
+
+This might be due to the io loop not checking the backend readiness before calling the read function.
+
+Attached patched fixes the problem on my system. I'm not sure it's the proper approach, this is just to start discussion.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/device/1829 b/results/classifier/gemma3:12b/device/1829
new file mode 100644
index 00000000..c4ad59f2
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1829
@@ -0,0 +1,89 @@
+
+DoS via assert failure by guest user
+Description of problem:
+As root in guest VM user can execute special script, which crashes the whole VM with error
+
+```plaintext
+hw/display/qxl.c:1594 inside of function void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0` failed
+```
+Steps to reproduce:
+1. This bug can be reproduced with:
+
+   ```bash
+   cat << EOF | ./build/qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio
+   outl 0xcf8 0x8000101c
+   outl 0xcfc 0xc000
+   outl 0xcf8 0x80001001
+   outl 0xcfc 0x01000000
+   outl 0xc006 0x00
+   EOF
+   ```
+2. Also, we can execute this python3 script inside guest VM as root (to invoke VM use command: **_qemu-system-x86_64 -vga qxl -hda debian.img -m 2048 -nodefaults_**):
+
+   ```python
+   import os
+   f = os.open("/dev/port", os.O_RDWR|os.O_NDELAY)
+   l = os.lseek(f, 0xcf8, 0)
+   os.write(f, b'\x80\x00\x10\x1c')
+   l = os.lseek(f, 0xcfc, 0)
+   os.write(f, b'\xc0\x00')
+   l = os.lseek(f, 0xcf8, 0)
+   os.write(f, b'\x80\x00\x10\x01')
+   l = os.lseek(f, 0xcfc, 0)
+   os.write(f, b'\x01\x00\x00\x00')
+   l = os.lseek(f, 0xc006, 0)
+   os.write(f, b'\x00')
+   ```
+
+   This script causes VM to crash.
+
+   [PoC_qxl-vga_crash.mkv](/uploads/7ee262c20dca69aa9417812f6a93a532/PoC_qxl-vga_crash.mkv)
+Additional information:
+This issue was found by fuzzing. Here is an auto-generated C source code for a test case that will reproduce the bug.
+
+```plaintext
+/*
+ * Autogenerated Fuzzer Test Case
+ *
+ * Copyright (c) 2023 Artem Nasonov <anasonov@astralinux.ru>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+
+#include "libqtest.h"
+
+/*
+ * cat << EOF | qemu-system-x86_64 -vga qxl -hda \
+ * ~/Downloads/virtualdebian.img -m 2048 -nodefaults -qtest stdio
+ * outl 0xcf8 0x8000101c
+ * outl 0xcfc 0xc000
+ * outl 0xcf8 0x80001001
+ * outl 0xcfc 0x01000000
+ * outl 0xc006 0x00
+ * EOF
+*/
+static void test_qxl_set_mode(void)
+{
+QTestState *s = qtest_init("-vga qxl -m 2048 -nodefaults");
+qtest_outl(s, 0xcf8, 0x8000101c);
+qtest_outl(s, 0xcfc, 0xc000);
+qtest_outl(s, 0xcf8, 0x80001001);
+qtest_outl(s, 0xcfc, 0x01000000);
+qtest_outl(s, 0xc006, 0x00);
+qtest_quit(s);
+}int main(int argc, char **argv)
+{
+    const char *arch = qtest_get_arch();
+
+    g_test_init(&argc, &argv, NULL);
+
+   if (strcmp(arch, "x86_64") == 0) {
+        qtest_add_func("fuzz/test_qxl_set_mode",test_qxl_set_mode);
+   }
+
+   return g_test_run();
+}
+```