diff options
Diffstat (limited to 'results/classifier/118/network')
115 files changed, 5305 insertions, 0 deletions
diff --git a/results/classifier/118/network/05479587 b/results/classifier/118/network/05479587 new file mode 100644 index 00000000..49122dfe --- /dev/null +++ b/results/classifier/118/network/05479587 @@ -0,0 +1,108 @@ +network: 0.963 +virtual: 0.880 +semantic: 0.866 +device: 0.811 +mistranslation: 0.759 +socket: 0.716 +performance: 0.669 +hypervisor: 0.658 +PID: 0.618 +ppc: 0.616 +register: 0.598 +permissions: 0.584 +graphic: 0.576 +user-level: 0.541 +arm: 0.503 +architecture: 0.501 +peripherals: 0.494 +risc-v: 0.479 +boot: 0.474 +vnc: 0.464 +kernel: 0.460 +files: 0.395 +KVM: 0.374 +i386: 0.360 +assembly: 0.326 +VMM: 0.320 +debug: 0.314 +TCG: 0.226 +x86: 0.197 + +[Qemu-devel] [BUG] network qga : windows os lost ip address of the network card in some cases + +We think this problem coulde be solevd in qga modulesãcan anybody give some +advice ? + + +[BUG] network : windows os lost ip address of the network card in some cases + +we found this problem for a long time ãFor example, if we has three network +card in virtual xml file ï¼such as "network connection 1" / "network connection +2"/"network connection 3" ã + +Echo network card has own ip address ï¼such as 192.168.1.1 / 2.1 /3.1 , when +delete the first card ï¼reboot the windows virtual os, then this problem +happened ! + + + + +we found that the sencond network card will replace the first one , then the +ip address of "network connection 2 " become 192.168.1.1 ã + + +Our third party users began to complain about this bug ãAll the business of the +second ip lost !!! + +I mean both of windows and linux has this bug , we solve this bug in linux +throught bonding netcrad pci and mac address ã + +There is no good solution on windows os . thera are ? we implemented a plan to +resumption of IP by QGA. Is there a better way ? + + + + + + + + +åå§é®ä»¶ + + + +å件人ï¼å°¹ä½ä¸º10144574 +æ¶ä»¶äººï¼ address@hidden +æ¥ æ ï¼2017å¹´04æ14æ¥ 16:46 +主 é¢ ï¼[BUG] network : windows os lost ip address of the network card in some +cases + + + + + + +we found this problem for a long time ãFor example, if we has three network +card in virtual xml file ï¼such as "network connection 1" / "network connection +2"/"network connection 3" ã + +Echo network card has own ip address ï¼such as 192.168.1.1 / 2.1 /3.1 , when +delete the first card ï¼reboot the windows virtual os, then this problem +happened ! + + + + +we found that the sencond network card will replace the first one , then the +ip address of "network connection 2 " become 192.168.1.1 ã + + +Our third party users began to complain about this bug ãAll the business of the +second ip lost !!! + +I mean both of windows and linux has this bug , we solve this bug in linux +throught bonding netcrad pci and mac address ã + +There is no good solution on windows os . thera are ? we implemented a plan to +resumption of IP by QGA. Is there a better way ? + diff --git a/results/classifier/118/network/1054180 b/results/classifier/118/network/1054180 new file mode 100644 index 00000000..af937e7e --- /dev/null +++ b/results/classifier/118/network/1054180 @@ -0,0 +1,53 @@ +network: 0.951 +virtual: 0.899 +performance: 0.869 +graphic: 0.835 +device: 0.778 +files: 0.728 +user-level: 0.721 +vnc: 0.641 +semantic: 0.558 +ppc: 0.522 +socket: 0.476 +hypervisor: 0.418 +architecture: 0.394 +kernel: 0.340 +i386: 0.338 +PID: 0.332 +debug: 0.312 +register: 0.311 +x86: 0.310 +risc-v: 0.294 +peripherals: 0.282 +boot: 0.263 +mistranslation: 0.225 +TCG: 0.198 +permissions: 0.176 +VMM: 0.161 +arm: 0.156 +KVM: 0.155 +assembly: 0.102 + +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. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9 or a release candidate of 2.10)? + +Also could you please provide the exact command line that you use to start QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1071 b/results/classifier/118/network/1071 new file mode 100644 index 00000000..15621983 --- /dev/null +++ b/results/classifier/118/network/1071 @@ -0,0 +1,42 @@ +network: 0.876 +graphic: 0.792 +device: 0.708 +virtual: 0.650 +performance: 0.625 +semantic: 0.582 +mistranslation: 0.422 +debug: 0.402 +PID: 0.364 +hypervisor: 0.309 +risc-v: 0.302 +vnc: 0.285 +permissions: 0.238 +register: 0.215 +VMM: 0.194 +socket: 0.186 +i386: 0.166 +KVM: 0.165 +boot: 0.150 +user-level: 0.142 +assembly: 0.112 +architecture: 0.112 +x86: 0.110 +peripherals: 0.104 +TCG: 0.096 +ppc: 0.091 +files: 0.075 +arm: 0.064 +kernel: 0.057 + +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/118/network/111 b/results/classifier/118/network/111 new file mode 100644 index 00000000..34474aee --- /dev/null +++ b/results/classifier/118/network/111 @@ -0,0 +1,31 @@ +network: 0.845 +mistranslation: 0.835 +performance: 0.748 +device: 0.719 +debug: 0.524 +socket: 0.481 +register: 0.447 +graphic: 0.412 +peripherals: 0.408 +architecture: 0.366 +kernel: 0.345 +ppc: 0.333 +x86: 0.316 +boot: 0.304 +i386: 0.295 +semantic: 0.294 +arm: 0.294 +VMM: 0.283 +permissions: 0.242 +risc-v: 0.236 +vnc: 0.223 +hypervisor: 0.223 +virtual: 0.219 +TCG: 0.201 +assembly: 0.144 +user-level: 0.121 +files: 0.110 +PID: 0.074 +KVM: 0.037 + +[OSS-Fuzz] Assertion Failure: !in6_zero(&ip_addr) diff --git a/results/classifier/118/network/1158 b/results/classifier/118/network/1158 new file mode 100644 index 00000000..9b4d3fc0 --- /dev/null +++ b/results/classifier/118/network/1158 @@ -0,0 +1,31 @@ +network: 0.832 +device: 0.814 +debug: 0.738 +vnc: 0.697 +performance: 0.576 +virtual: 0.511 +arm: 0.431 +graphic: 0.321 +risc-v: 0.305 +semantic: 0.246 +ppc: 0.232 +i386: 0.195 +x86: 0.146 +mistranslation: 0.125 +boot: 0.113 +user-level: 0.104 +permissions: 0.100 +architecture: 0.093 +TCG: 0.082 +assembly: 0.066 +register: 0.055 +PID: 0.054 +socket: 0.032 +hypervisor: 0.014 +peripherals: 0.011 +files: 0.009 +VMM: 0.008 +KVM: 0.005 +kernel: 0.004 + +Error in setting VNC password diff --git a/results/classifier/118/network/1174 b/results/classifier/118/network/1174 new file mode 100644 index 00000000..5e933de1 --- /dev/null +++ b/results/classifier/118/network/1174 @@ -0,0 +1,43 @@ +network: 0.855 +device: 0.851 +kernel: 0.819 +ppc: 0.808 +graphic: 0.805 +performance: 0.771 +architecture: 0.711 +register: 0.676 +mistranslation: 0.670 +PID: 0.594 +files: 0.578 +semantic: 0.564 +vnc: 0.518 +peripherals: 0.508 +socket: 0.494 +permissions: 0.438 +arm: 0.435 +VMM: 0.431 +TCG: 0.414 +i386: 0.403 +x86: 0.393 +user-level: 0.359 +risc-v: 0.324 +boot: 0.306 +debug: 0.291 +KVM: 0.265 +hypervisor: 0.247 +virtual: 0.210 +assembly: 0.156 + +aspeed: Fix first byte in I2C old register mode slave receive +Description of problem: +The first byte of data received through the Aspeed I2C slave controller through the old-register mode (specifically byte-buffered, not pool buffered or DMA buffered) is incorrect. It should be the 8-bit I2C slave address for the transfer, which will be the 7-bit I2C slave address of the I2C controller shifted left 1, and 1 or 0 for the lowest bit (is-slave-to-master-transfer, or is-master-to-slave-transfer). +Steps to reproduce: +You could use the simulated I2C slave EEPROM https://docs.kernel.org/i2c/slave-eeprom-backend.html, but you need another I2C model to send data to it. + +Alternatively, you can take this downstream patch and run the qtest in it. It has a test case for slave-mode rx in old-register mode: + +https://github.com/facebook/openbmc/blob/helium/common/recipes-devtools/qemu/qemu/0008-hw-misc-Add-byte-by-byte-i2c-network-device.patch +Additional information: +I already created the fix, it's pretty simple, I submitted it to the mailing list and Klaus (the author of that section of the Aspeed I2C controller) reviewed it. https://lore.kernel.org/qemu-devel/20220820225712.713209-1-peter@pjd.dev/#t + +This is relatively critical fix, but since slave-mode I2C is not widely used at this point, it's probably fine to ship with this bug. My team uses the master branch for everything anyways. diff --git a/results/classifier/118/network/1176366 b/results/classifier/118/network/1176366 new file mode 100644 index 00000000..7e28142a --- /dev/null +++ b/results/classifier/118/network/1176366 @@ -0,0 +1,59 @@ +network: 0.851 +kernel: 0.753 +debug: 0.708 +peripherals: 0.599 +device: 0.568 +performance: 0.526 +graphic: 0.525 +TCG: 0.502 +semantic: 0.490 +PID: 0.484 +user-level: 0.467 +ppc: 0.463 +mistranslation: 0.458 +register: 0.425 +permissions: 0.400 +hypervisor: 0.389 +architecture: 0.382 +files: 0.378 +vnc: 0.355 +i386: 0.350 +risc-v: 0.329 +socket: 0.312 +boot: 0.296 +x86: 0.289 +virtual: 0.288 +arm: 0.254 +VMM: 0.223 +assembly: 0.211 +KVM: 0.153 + +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. + + + +On Sat, May 04, 2013 at 04:13:19PM -0000, TC1988 wrote: +> 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. + +Please use git-bisect(1) to identify the commit that broke networking. + +http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search +https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html + +Stefan + + +looks like it also happens in 1.5.0-rc1, will check later with git bisect in the latest git release based on rc1. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1279 b/results/classifier/118/network/1279 new file mode 100644 index 00000000..1a78f255 --- /dev/null +++ b/results/classifier/118/network/1279 @@ -0,0 +1,38 @@ +network: 0.990 +device: 0.860 +virtual: 0.737 +graphic: 0.690 +vnc: 0.532 +VMM: 0.421 +semantic: 0.344 +ppc: 0.301 +risc-v: 0.289 +debug: 0.279 +mistranslation: 0.272 +socket: 0.265 +arm: 0.253 +KVM: 0.242 +boot: 0.234 +x86: 0.212 +hypervisor: 0.202 +register: 0.201 +PID: 0.190 +performance: 0.183 +peripherals: 0.177 +user-level: 0.161 +TCG: 0.161 +architecture: 0.146 +permissions: 0.113 +assembly: 0.107 +files: 0.061 +i386: 0.056 +kernel: 0.034 + +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/118/network/1286 b/results/classifier/118/network/1286 new file mode 100644 index 00000000..7f0fb18c --- /dev/null +++ b/results/classifier/118/network/1286 @@ -0,0 +1,31 @@ +mistranslation: 0.979 +network: 0.923 +device: 0.826 +semantic: 0.709 +architecture: 0.654 +arm: 0.567 +PID: 0.558 +permissions: 0.510 +user-level: 0.416 +performance: 0.407 +files: 0.387 +i386: 0.328 +virtual: 0.315 +boot: 0.313 +register: 0.289 +VMM: 0.260 +risc-v: 0.250 +vnc: 0.246 +ppc: 0.221 +TCG: 0.214 +x86: 0.210 +debug: 0.209 +peripherals: 0.205 +graphic: 0.196 +assembly: 0.166 +socket: 0.102 +hypervisor: 0.092 +KVM: 0.074 +kernel: 0.024 + +netdev tftp option docs don't mention that the TFTP server is read-only diff --git a/results/classifier/118/network/1297781 b/results/classifier/118/network/1297781 new file mode 100644 index 00000000..86e26221 --- /dev/null +++ b/results/classifier/118/network/1297781 @@ -0,0 +1,43 @@ +network: 0.940 +device: 0.876 +files: 0.779 +virtual: 0.754 +boot: 0.708 +performance: 0.664 +vnc: 0.637 +mistranslation: 0.608 +user-level: 0.548 +architecture: 0.547 +graphic: 0.544 +PID: 0.540 +VMM: 0.517 +ppc: 0.487 +hypervisor: 0.465 +semantic: 0.440 +register: 0.435 +socket: 0.432 +debug: 0.420 +i386: 0.418 +risc-v: 0.386 +permissions: 0.364 +x86: 0.356 +peripherals: 0.343 +kernel: 0.335 +KVM: 0.334 +assembly: 0.263 +TCG: 0.231 +arm: 0.215 + +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. + +Triaging old bug tickets ... How did you start QEMU here? Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1299 b/results/classifier/118/network/1299 new file mode 100644 index 00000000..456ccc56 --- /dev/null +++ b/results/classifier/118/network/1299 @@ -0,0 +1,54 @@ +network: 0.973 +user-level: 0.937 +virtual: 0.894 +graphic: 0.862 +device: 0.852 +files: 0.817 +semantic: 0.816 +architecture: 0.813 +performance: 0.810 +permissions: 0.742 +register: 0.711 +ppc: 0.673 +vnc: 0.619 +socket: 0.614 +debug: 0.569 +PID: 0.553 +mistranslation: 0.539 +risc-v: 0.491 +boot: 0.489 +arm: 0.461 +peripherals: 0.454 +hypervisor: 0.445 +KVM: 0.356 +kernel: 0.332 +i386: 0.330 +TCG: 0.315 +VMM: 0.297 +assembly: 0.247 +x86: 0.243 + +User networking with an SMB Share while not running as root +Description of problem: +When attempting to write a file to the qemu share, Samba always responds with NT_STATUS_ACCESS_DENIED. + +This only happens on the MacOS version of Samba, on Linux it appears to work without issues for now. +Steps to reproduce: +1. Start a VM with a SMB share attached to it +2. Create a test file to upload `touch test-file.txt` +3. Upload the test file `smbclient //10.0.2.4/qemu -c 'put test-file.txt' +Additional information: +QEMU has been using Samba for it's SMB shares for quite some time now. +But in the 4.17.x release a bug has appeared in the MacOS Build of Samba. + +I've filed a bug with Samba, and suggested a fix for it. +https://bugzilla.samba.org/show_bug.cgi?id=15215 + +The origin of the bug lies in the fact that when running SMBD as a non-root user, a function sets `errno` unexpectedly. +But after discussing this with Samba, they concluded that running smbd as an un-privileged user is not a supported use case. + +Whilst this is not a QEMU bug per se, it is caused by the fact that QEMU is running smbd in an unsupported manner. + +As a side note, on Linux this bug does not appear to exist as of yet. +The Linux version of `unbecome_root` doesn't seem to set `errno`. (tested on a recent ArchLinux install). +But I think this depends on the LibC implementation of setuid/seteuid/setreuid/etc. so I can't say it won't happen in the future, or with a different LibC implementation. diff --git a/results/classifier/118/network/1309 b/results/classifier/118/network/1309 new file mode 100644 index 00000000..76cde1ca --- /dev/null +++ b/results/classifier/118/network/1309 @@ -0,0 +1,31 @@ +network: 0.893 +graphic: 0.813 +device: 0.748 +performance: 0.730 +architecture: 0.580 +arm: 0.382 +hypervisor: 0.297 +debug: 0.249 +ppc: 0.203 +vnc: 0.199 +VMM: 0.131 +TCG: 0.121 +i386: 0.106 +x86: 0.104 +boot: 0.102 +risc-v: 0.095 +mistranslation: 0.085 +PID: 0.060 +peripherals: 0.050 +virtual: 0.040 +KVM: 0.040 +socket: 0.037 +semantic: 0.029 +user-level: 0.028 +register: 0.020 +permissions: 0.011 +assembly: 0.011 +kernel: 0.007 +files: 0.003 + +Heap-overflow in virtio_net_queue_enable diff --git a/results/classifier/118/network/1369347 b/results/classifier/118/network/1369347 new file mode 100644 index 00000000..eb0deb15 --- /dev/null +++ b/results/classifier/118/network/1369347 @@ -0,0 +1,77 @@ +network: 0.850 +device: 0.840 +PID: 0.701 +peripherals: 0.694 +hypervisor: 0.686 +architecture: 0.673 +socket: 0.656 +user-level: 0.655 +arm: 0.651 +ppc: 0.645 +register: 0.612 +vnc: 0.610 +files: 0.588 +risc-v: 0.578 +permissions: 0.572 +boot: 0.570 +performance: 0.568 +semantic: 0.567 +graphic: 0.560 +VMM: 0.558 +kernel: 0.557 +x86: 0.506 +TCG: 0.505 +mistranslation: 0.491 +virtual: 0.460 +KVM: 0.440 +assembly: 0.437 +debug: 0.427 +i386: 0.359 + +Mac OS X cannot passthrough USB device to guest + +I'm using Mac OS 10.9.4 with qemu-system-arm installed from brew (version 1.7.1) and verified with qemu-system-x86_64. I'm trying to pass a Ralink 5370 WiFi USB dongle to my guest system, it appears in my system profiler as: + +802.11 n WLAN: + + Product ID: 0x5370 + Vendor ID: 0x148f + Version: 1.01 + Serial Number: 1.0 + Speed: Up to 480 Mb/sec + Manufacturer: Ralink + Location ID: 0x1d110000 / 6 + Current Available (mA): 500 + Current Required (mA): 450 + +Using the docs, I'm passing "-usb -device usb-host,vendorid=0x148f,productid=0x5370" and getting this error back: +"qemu-system-arm: -device usb-host,vendorid=0x148f,productid=0x5370: Parameter 'driver' expects device type" + +On 14 September 2014 15:23, Aaron <email address hidden> wrote: +> Public bug reported: +> +> I'm using Mac OS 10.9.4 with qemu-system-arm installed from brew +> (version 1.7.1) and verified with qemu-system-x86_64. I'm trying to pass +> a Ralink 5370 WiFi USB dongle to my guest system, it appears in my +> system profiler as: + +I don't imagine anybody's tested trying to get USB passthrough to +work on Macs. If it works it will be by happy side effect of the code +written for and tested on Linux happening to work. + +It may not help, but it would be useful to try against a newer version +of QEMU, ie 2.1. You'll need to make sure you have the libusb +dev libraries installed so our configure can find them. + +thanks +-- PMM + + +I'll give it a shot, thanks :) + +For future googlers, I first ran "brew uninstall qemu" then "brew install libusb". + +After that, download the source, "./configure", "make", "sudo make install" and you're done. + +Comment #3 sounds like this bug has been fixed, right? So I'm closing this bug ticket now. + diff --git a/results/classifier/118/network/1385 b/results/classifier/118/network/1385 new file mode 100644 index 00000000..4edef6b5 --- /dev/null +++ b/results/classifier/118/network/1385 @@ -0,0 +1,31 @@ +network: 0.883 +performance: 0.678 +mistranslation: 0.561 +virtual: 0.470 +semantic: 0.449 +user-level: 0.329 +permissions: 0.315 +architecture: 0.296 +TCG: 0.295 +graphic: 0.288 +KVM: 0.282 +vnc: 0.282 +VMM: 0.240 +risc-v: 0.236 +device: 0.214 +ppc: 0.197 +PID: 0.189 +i386: 0.175 +socket: 0.157 +arm: 0.154 +peripherals: 0.151 +hypervisor: 0.139 +register: 0.120 +debug: 0.105 +x86: 0.100 +files: 0.090 +boot: 0.089 +kernel: 0.080 +assembly: 0.069 + +-net option doesn't work diff --git a/results/classifier/118/network/1402289 b/results/classifier/118/network/1402289 new file mode 100644 index 00000000..e00f9ea2 --- /dev/null +++ b/results/classifier/118/network/1402289 @@ -0,0 +1,69 @@ +network: 0.916 +peripherals: 0.891 +debug: 0.848 +kernel: 0.804 +device: 0.788 +performance: 0.779 +architecture: 0.779 +x86: 0.726 +hypervisor: 0.715 +semantic: 0.696 +mistranslation: 0.693 +socket: 0.658 +register: 0.650 +i386: 0.624 +files: 0.584 +user-level: 0.582 +risc-v: 0.511 +vnc: 0.509 +permissions: 0.500 +boot: 0.500 +PID: 0.495 +ppc: 0.472 +graphic: 0.468 +virtual: 0.429 +assembly: 0.417 +VMM: 0.416 +arm: 0.394 +TCG: 0.326 +KVM: 0.246 + +netware 5.1 and SCSI (LSI Logic 53c895a) = lsi_scsi: error: readb 0x49 + +Subj. + +This error occurs while loading LSIHINW.HAM driver in the netware5.1 SP8 installer. + +Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14). +Linux kernel: 3.17.6 and 3.18.0. + +Debug log for machine in the attachment. + + + +Netware 6.5 SP8: affected. + +On Sat, Dec 13, 2014 at 10:31:20PM -0000, Ainur Shakirov wrote: +> This error occurs while loading LSIHINW.HAM driver in the netware5.1 SP8 +> installer. +> +> Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14). +> Linux kernel: 3.17.6 and 3.18.0. +> +> Debug log for machine in the attachment. + +The LSI SCSI controller has known issues and is not actively maintained. + +Stefan + + +This also affects NW 4.2 with the Novell LSI8XXNW.HAM driver. + +lsi_scsi: error: readb 0x49 + + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1451 b/results/classifier/118/network/1451 new file mode 100644 index 00000000..da3e9f41 --- /dev/null +++ b/results/classifier/118/network/1451 @@ -0,0 +1,31 @@ +network: 0.978 +vnc: 0.949 +device: 0.895 +performance: 0.827 +architecture: 0.788 +VMM: 0.618 +boot: 0.601 +risc-v: 0.598 +debug: 0.583 +graphic: 0.517 +socket: 0.515 +TCG: 0.513 +arm: 0.507 +PID: 0.453 +ppc: 0.378 +hypervisor: 0.363 +KVM: 0.311 +x86: 0.279 +i386: 0.278 +semantic: 0.224 +mistranslation: 0.215 +virtual: 0.192 +kernel: 0.189 +register: 0.186 +peripherals: 0.175 +permissions: 0.106 +assembly: 0.093 +files: 0.089 +user-level: 0.084 + +Assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed. diff --git a/results/classifier/118/network/1482 b/results/classifier/118/network/1482 new file mode 100644 index 00000000..b244ed0f --- /dev/null +++ b/results/classifier/118/network/1482 @@ -0,0 +1,45 @@ +network: 0.986 +virtual: 0.941 +graphic: 0.762 +device: 0.604 +semantic: 0.527 +boot: 0.506 +performance: 0.480 +PID: 0.466 +register: 0.433 +files: 0.421 +permissions: 0.392 +VMM: 0.381 +mistranslation: 0.378 +vnc: 0.320 +assembly: 0.303 +debug: 0.287 +TCG: 0.242 +architecture: 0.238 +socket: 0.216 +risc-v: 0.189 +user-level: 0.183 +i386: 0.183 +peripherals: 0.173 +hypervisor: 0.139 +ppc: 0.134 +x86: 0.113 +kernel: 0.091 +KVM: 0.074 +arm: 0.048 + +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/118/network/151 b/results/classifier/118/network/151 new file mode 100644 index 00000000..595872a0 --- /dev/null +++ b/results/classifier/118/network/151 @@ -0,0 +1,31 @@ +network: 0.809 +virtual: 0.765 +device: 0.759 +performance: 0.543 +semantic: 0.358 +architecture: 0.355 +i386: 0.306 +boot: 0.298 +graphic: 0.291 +vnc: 0.267 +files: 0.249 +arm: 0.220 +debug: 0.213 +x86: 0.197 +peripherals: 0.193 +TCG: 0.186 +PID: 0.183 +socket: 0.175 +mistranslation: 0.170 +register: 0.168 +ppc: 0.159 +user-level: 0.152 +permissions: 0.145 +KVM: 0.131 +hypervisor: 0.112 +VMM: 0.065 +risc-v: 0.046 +assembly: 0.015 +kernel: 0.009 + +virtio-net ignores the absence of the VIRTIO_NET_F_CTRL_VQ feature bit diff --git a/results/classifier/118/network/1560 b/results/classifier/118/network/1560 new file mode 100644 index 00000000..36a06da2 --- /dev/null +++ b/results/classifier/118/network/1560 @@ -0,0 +1,31 @@ +network: 0.858 +architecture: 0.835 +device: 0.822 +performance: 0.620 +boot: 0.459 +semantic: 0.437 +arm: 0.413 +files: 0.367 +ppc: 0.363 +peripherals: 0.329 +virtual: 0.328 +hypervisor: 0.320 +kernel: 0.319 +mistranslation: 0.298 +vnc: 0.282 +debug: 0.259 +VMM: 0.246 +risc-v: 0.245 +graphic: 0.218 +i386: 0.185 +permissions: 0.168 +socket: 0.167 +register: 0.154 +PID: 0.149 +x86: 0.145 +assembly: 0.101 +user-level: 0.094 +TCG: 0.084 +KVM: 0.055 + +SLIRP hostfwd_add ignores bind address and uses `INADDR_ANY` diff --git a/results/classifier/118/network/1569988 b/results/classifier/118/network/1569988 new file mode 100644 index 00000000..0f10bb2a --- /dev/null +++ b/results/classifier/118/network/1569988 @@ -0,0 +1,88 @@ +network: 0.930 +device: 0.926 +user-level: 0.908 +risc-v: 0.898 +PID: 0.887 +vnc: 0.884 +graphic: 0.883 +peripherals: 0.879 +VMM: 0.861 +socket: 0.861 +mistranslation: 0.855 +semantic: 0.852 +debug: 0.842 +architecture: 0.836 +TCG: 0.832 +x86: 0.827 +permissions: 0.827 +ppc: 0.822 +hypervisor: 0.821 +performance: 0.795 +register: 0.787 +files: 0.765 +arm: 0.744 +boot: 0.743 +assembly: 0.707 +virtual: 0.682 +i386: 0.673 +KVM: 0.647 +kernel: 0.597 + +[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 + +Under Linux, it is working fine. + +Another thing: if I disable ipv6, ipv4 runs still in sort of a timeout before writing Network is unreachable (ENETUNREACH), while ipv6 says this without delay (which is ok/good) + + +It looks like this commit caused the regression: + +$ git bisect bad +c619644067f98098dcdbc951e2dda79e97560afa is the first bad commit +commit c619644067f98098dcdbc951e2dda79e97560afa +Author: Daniel P. Berrange <email address hidden> +Date: Mon Mar 7 11:19:18 2016 +0000 + + osdep: fix socket_error() to work with Mingw64 + + +Here is a patch which fixes the problem. + +diff --git a/slirp/tcp_input.c b/slirp/tcp_input.c +index 2027a75..696867f 100644 +--- a/slirp/tcp_input.c ++++ b/slirp/tcp_input.c +@@ -587,7 +587,7 @@ findso: + + if ((tcp_fconnect(so, so->so_ffamily) == -1) && + #if defined(_WIN32) +- socket_error() != WSAEWOULDBLOCK ++ socket_error() != EAGAIN + #else + (errno != EINPROGRESS) && (errno != EWOULDBLOCK) + #endif + + +Latest QEMU needs a slightly different patch: + +diff --git a/slirp/tcp_input.c b/slirp/tcp_input.c +index 5433e7f..3be2d2f 100644 +--- a/slirp/tcp_input.c ++++ b/slirp/tcp_input.c +@@ -659,6 +659,7 @@ findso: + } + + if ((tcp_fconnect(so, so->so_ffamily) == -1) && ++ socket_error() != EAGAIN && + (errno != EINPROGRESS) && (errno != EWOULDBLOCK) + ) { + uint8_t code; + +Fixed since v2.6.0-rc3 release. + diff --git a/results/classifier/118/network/1574327 b/results/classifier/118/network/1574327 new file mode 100644 index 00000000..521e8f4c --- /dev/null +++ b/results/classifier/118/network/1574327 @@ -0,0 +1,50 @@ +x86: 0.995 +network: 0.940 +architecture: 0.884 +device: 0.849 +performance: 0.842 +mistranslation: 0.786 +graphic: 0.732 +ppc: 0.689 +vnc: 0.612 +semantic: 0.571 +files: 0.539 +permissions: 0.514 +kernel: 0.511 +socket: 0.504 +boot: 0.469 +TCG: 0.460 +PID: 0.457 +arm: 0.455 +register: 0.451 +user-level: 0.395 +debug: 0.379 +VMM: 0.357 +peripherals: 0.341 +hypervisor: 0.322 +virtual: 0.316 +risc-v: 0.284 +KVM: 0.139 +assembly: 0.043 +i386: 0.009 + +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 + +Finally fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7b71e03af98fd7b5e1 + diff --git a/results/classifier/118/network/1575561 b/results/classifier/118/network/1575561 new file mode 100644 index 00000000..fa24047d --- /dev/null +++ b/results/classifier/118/network/1575561 @@ -0,0 +1,46 @@ +network: 0.898 +graphic: 0.731 +boot: 0.693 +performance: 0.605 +mistranslation: 0.605 +device: 0.542 +vnc: 0.456 +semantic: 0.331 +virtual: 0.320 +user-level: 0.262 +socket: 0.222 +i386: 0.200 +x86: 0.198 +debug: 0.136 +hypervisor: 0.124 +peripherals: 0.113 +architecture: 0.102 +KVM: 0.079 +arm: 0.078 +VMM: 0.076 +register: 0.075 +assembly: 0.071 +permissions: 0.066 +risc-v: 0.057 +ppc: 0.053 +PID: 0.048 +files: 0.040 +TCG: 0.032 +kernel: 0.028 + +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" + +the vm bios is seabios. see the seabios,it queue size config 256,can not change. + + +but vm by other boot type ,such as dev='hd', can use virtio_queue_size = 1024 + +Which version of QEMU were you using here? Can you still reproduce this issue with the latest version of QEMU? If so, please also provide the full command line parameters that you used to start QEMU. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1585433 b/results/classifier/118/network/1585433 new file mode 100644 index 00000000..91a2bd03 --- /dev/null +++ b/results/classifier/118/network/1585433 @@ -0,0 +1,41 @@ +network: 0.877 +performance: 0.862 +device: 0.846 +vnc: 0.798 +mistranslation: 0.796 +socket: 0.757 +architecture: 0.732 +graphic: 0.672 +PID: 0.595 +semantic: 0.513 +debug: 0.497 +peripherals: 0.489 +files: 0.456 +permissions: 0.438 +risc-v: 0.422 +VMM: 0.417 +register: 0.413 +boot: 0.364 +hypervisor: 0.320 +TCG: 0.287 +kernel: 0.205 +arm: 0.202 +virtual: 0.188 +user-level: 0.170 +ppc: 0.170 +assembly: 0.082 +x86: 0.081 +i386: 0.047 +KVM: 0.043 + +if docker-volume-size of baymodel lessthan 3, bay cann't create + +magnum is running on centos7, + + +magnum baymodel-create --name k8sbaymodel5 --image-id fedora-23-atomic-20160405 --keypair-id testkey --external-network-id public --dns-nameserver 8.8.8.8 --flavor-id m1.small --coe kubernetes --docker-volume-size 5 + +magnum bay-create --name k8sbay5 --baymodel k8sbaymodel5 --node-count 1 + +Execute the above command can get a completed bay,but when docker-volume-size is 1 or 2,the status of bay is FAILED. + diff --git a/results/classifier/118/network/1588591 b/results/classifier/118/network/1588591 new file mode 100644 index 00000000..a6aff09f --- /dev/null +++ b/results/classifier/118/network/1588591 @@ -0,0 +1,43 @@ +network: 0.863 +performance: 0.797 +device: 0.791 +architecture: 0.754 +socket: 0.738 +graphic: 0.725 +semantic: 0.707 +mistranslation: 0.656 +boot: 0.536 +user-level: 0.529 +hypervisor: 0.527 +permissions: 0.508 +debug: 0.504 +PID: 0.489 +peripherals: 0.472 +register: 0.371 +ppc: 0.332 +virtual: 0.312 +x86: 0.289 +vnc: 0.287 +risc-v: 0.274 +arm: 0.248 +assembly: 0.241 +i386: 0.226 +kernel: 0.207 +files: 0.161 +VMM: 0.156 +TCG: 0.128 +KVM: 0.023 + +Qemu 2.6 Solaris 8 Sparc telnet terminate itself + +With Qemu 2.6, Solaris 8 can be installed and run. However, it sometimes terminate itself with I/O thread spun for 1000 iterations. + +qemu-system-sparc -nographic -monitor null -serial mon:telnet:0.0.0.0:3000,server -hda ./Sparc8.disk -m 256 -boot c -net nic,macaddr=52:54:0:12:34:56 -net tap,ifname=tap0,script=no,downscript=noQEMU waiting for connection on: disconnected:telnet:0.0.0.0:3000,server +main-loop: WARNING: I/O thread spun for 1000 iterations + +Although I have occasionally seen this message with later versions of QEMU running Solaris 8/SPARC it has never affected any operations for me or terminated a telnet or QEMU process, so I think if it is still there it's not having any affect. So I think this can be closed. + +Zhen Ning Lim, can you still reproduce the problem where QEMU terminates itself after printing that warning message? + +Nope. Not anymore. I shall close this. Thanks! + diff --git a/results/classifier/118/network/1633508 b/results/classifier/118/network/1633508 new file mode 100644 index 00000000..309a1551 --- /dev/null +++ b/results/classifier/118/network/1633508 @@ -0,0 +1,80 @@ +network: 0.849 +device: 0.837 +peripherals: 0.821 +x86: 0.798 +PID: 0.773 +performance: 0.759 +semantic: 0.752 +permissions: 0.710 +architecture: 0.707 +user-level: 0.704 +socket: 0.658 +mistranslation: 0.645 +graphic: 0.613 +debug: 0.613 +register: 0.585 +kernel: 0.578 +boot: 0.572 +files: 0.506 +hypervisor: 0.484 +vnc: 0.474 +virtual: 0.467 +risc-v: 0.455 +ppc: 0.454 +arm: 0.425 +VMM: 0.421 +TCG: 0.375 +assembly: 0.330 +i386: 0.323 +KVM: 0.127 + +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 + +This looks like a libvirt bug at a first glance. Have you tried to report it to the libvirt project? (See https://libvirt.org/bugs.html ) ... also, can you re-create the bug with the very latest upstream version of libvirt and qemu, or does it only occur with an (older?) version of Ubuntu? + +That seems to be the Libvirt of Ubuntu in Xenial. + +In the past similar issues were uncommon configs or changed behavior on updates that triggered apparmor or SELinux protection. + +=> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1747442 +=> https://bugzilla.redhat.com/show_bug.cgi?id=731243 + +It could as well be some variant of bug 1677398. + +If you are still affected by this, could you check: +1. if it also happens on newer libvirt versions e.g. do a trial run in the most recent Ubuntu +2. if it does could you check dmesg in your setup for related apparmor denials? + + diff --git a/results/classifier/118/network/1656927 b/results/classifier/118/network/1656927 new file mode 100644 index 00000000..79703629 --- /dev/null +++ b/results/classifier/118/network/1656927 @@ -0,0 +1,52 @@ +network: 0.955 +x86: 0.758 +hypervisor: 0.689 +virtual: 0.675 +vnc: 0.654 +device: 0.646 +socket: 0.602 +performance: 0.574 +i386: 0.573 +KVM: 0.556 +architecture: 0.486 +ppc: 0.470 +graphic: 0.435 +files: 0.434 +TCG: 0.389 +PID: 0.385 +register: 0.367 +semantic: 0.349 +permissions: 0.312 +kernel: 0.298 +mistranslation: 0.272 +risc-v: 0.248 +assembly: 0.233 +arm: 0.225 +debug: 0.224 +boot: 0.222 +peripherals: 0.222 +VMM: 0.208 +user-level: 0.093 + +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 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1662 b/results/classifier/118/network/1662 new file mode 100644 index 00000000..11028ae9 --- /dev/null +++ b/results/classifier/118/network/1662 @@ -0,0 +1,65 @@ +network: 0.989 +performance: 0.984 +architecture: 0.975 +vnc: 0.965 +socket: 0.961 +device: 0.945 +PID: 0.945 +debug: 0.943 +graphic: 0.943 +TCG: 0.908 +x86: 0.905 +user-level: 0.903 +VMM: 0.893 +boot: 0.889 +peripherals: 0.880 +kernel: 0.877 +i386: 0.862 +hypervisor: 0.859 +files: 0.850 +ppc: 0.842 +assembly: 0.842 +virtual: 0.772 +register: 0.771 +mistranslation: 0.722 +risc-v: 0.706 +permissions: 0.594 +semantic: 0.554 +arm: 0.545 +KVM: 0.440 + +qemu-system-loongarch64 start Loongnix system coredump +Description of problem: + +Steps to reproduce: +1. build qemu: + ./configure --prefix=/usr --disable-werror --disable-gtk --target-list="loongarch64-softmmu"\ + --enable-debug + make -j32 +2. get bios and qcow2: + wget https://mirrors.wsyu.edu.cn/loongarch/archlinux/images/QEMU_EFI_7.2.fd + wget http://pkg.loongnix.cn/loongnix/isos/Loongnix-20.4/Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 +3. start Loongnix + ./build/qemu-system-loongarch64 \ + -m 8G \ + -cpu la464 \ + -machine virt \ + -smp 16 \ + -bios ./QEMU_EFI_7.2.fd \ + -serial stdio \ + -device virtio-gpu-pci \ + -net nic -net user \ + -device nec-usb-xhci,id=xhci,addr=0x1b \ + -device usb-tablet,id=tablet,bus=xhci.0,port=1 \ + -device usb-kbd,id=keyboard,bus=xhci.0,port=2 \ + -device virtio-blk-pci,drive=test -drive if=none,id=test,file=./Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 + +4. VNC connect +5. use the system + login loongson/Loongson20 +6. qemu coredump + + qemu-system-loongarch64: /root/work/qemu/include/tcg/tcg.h:675: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. +./start-loongnix.sh: line 13: 40242 Aborted (core dumped) ./build/qemu-system-loongarch64 -m 8G -cpu la464 -machine virt -smp 16 -bios ./QEMU_EFI_7.2.fd -serial stdio -device virtio-gpu-pci -net nic -net user -device nec-usb-xhci,id=xhci,addr=0x1b -device usb-tablet,id=tablet,bus=xhci.0,port=1 -device usb-kbd,id=keyboard,bus=xhci.0,port=2 -device virtio-blk-pci,drive=test -drive if=none,id=test,file=./Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 +Additional information: + diff --git a/results/classifier/118/network/1702798 b/results/classifier/118/network/1702798 new file mode 100644 index 00000000..654a0469 --- /dev/null +++ b/results/classifier/118/network/1702798 @@ -0,0 +1,67 @@ +network: 0.834 +ppc: 0.819 +performance: 0.796 +files: 0.774 +graphic: 0.750 +device: 0.695 +arm: 0.674 +kernel: 0.643 +virtual: 0.614 +register: 0.612 +semantic: 0.603 +hypervisor: 0.597 +KVM: 0.573 +PID: 0.571 +assembly: 0.571 +debug: 0.564 +mistranslation: 0.563 +socket: 0.550 +vnc: 0.547 +permissions: 0.546 +user-level: 0.536 +architecture: 0.533 +risc-v: 0.531 +VMM: 0.499 +peripherals: 0.491 +boot: 0.453 +i386: 0.445 +x86: 0.378 +TCG: 0.363 + +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); + ------ +} + +The qemu version is 2.9.0 release. +The secondary vm state make me confused. I tried to add vm_stop and vm_start in colo_process_incoming_thread function, but it crashed. + +In qemu upstream COLO project can not fully running, you can test my internal branch. +https://github.com/zhangckid/qemu/commits/colo-with-virtio-net-internal-jul10 + +Thanks +Zhang Chen + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1719689 b/results/classifier/118/network/1719689 new file mode 100644 index 00000000..4200dc82 --- /dev/null +++ b/results/classifier/118/network/1719689 @@ -0,0 +1,51 @@ +network: 0.975 +peripherals: 0.821 +graphic: 0.723 +kernel: 0.699 +boot: 0.690 +user-level: 0.656 +vnc: 0.593 +device: 0.579 +socket: 0.574 +x86: 0.502 +i386: 0.490 +semantic: 0.423 +debug: 0.417 +PID: 0.401 +mistranslation: 0.390 +ppc: 0.381 +performance: 0.377 +permissions: 0.358 +register: 0.353 +arm: 0.325 +risc-v: 0.317 +VMM: 0.293 +virtual: 0.284 +KVM: 0.274 +TCG: 0.253 +files: 0.202 +architecture: 0.199 +hypervisor: 0.198 +assembly: 0.171 + +[feature request] add flag to treat warnings as errors + +Since booting could potentially take a lot of time and warnings are likely to indicate that something is wrong, it would be useful to have a command line flag which would abort the boot if there are any warnings. + +An example might be network configuration. The following output most likely indicates that there is something the user has to fix before starting and being able to use the guest os. + +Warning: hub port hub0port0 has no peer +Warning: vlan 0 with no nics +Warning: netdev hub0port0 has no peer +Warning: requested NIC (anonymous, model vitrio-net-device) was not created (not supported by this machine?) + +Ideally, there would be an option the user could pass which would cause qemu to print these warnings then exit, rather than boot the kernel. + +Alternatively, or additionally, a dry run option would be helpful for the same purpose: making sure qemu get to the booting the kernel stage with everything in working order so that you do not have to wait for the kernel to boot and then shut down while debugging things like networking (things which can be debugged (at least partially) without booting, or trying to boot, the guest os). + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1732 b/results/classifier/118/network/1732 new file mode 100644 index 00000000..ef040945 --- /dev/null +++ b/results/classifier/118/network/1732 @@ -0,0 +1,33 @@ +network: 0.988 +mistranslation: 0.935 +graphic: 0.925 +semantic: 0.904 +assembly: 0.832 +performance: 0.809 +device: 0.767 +debug: 0.747 +architecture: 0.738 +user-level: 0.668 +risc-v: 0.660 +arm: 0.617 +PID: 0.564 +socket: 0.508 +vnc: 0.480 +i386: 0.435 +ppc: 0.418 +register: 0.414 +x86: 0.414 +hypervisor: 0.394 +VMM: 0.384 +boot: 0.349 +TCG: 0.342 +virtual: 0.338 +permissions: 0.219 +KVM: 0.204 +kernel: 0.146 +peripherals: 0.089 +files: 0.041 + +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/118/network/1751 b/results/classifier/118/network/1751 new file mode 100644 index 00000000..f031a340 --- /dev/null +++ b/results/classifier/118/network/1751 @@ -0,0 +1,31 @@ +network: 0.894 +device: 0.854 +mistranslation: 0.831 +performance: 0.774 +socket: 0.714 +arm: 0.712 +vnc: 0.623 +files: 0.601 +debug: 0.589 +register: 0.567 +risc-v: 0.559 +architecture: 0.556 +kernel: 0.504 +PID: 0.481 +boot: 0.464 +semantic: 0.406 +graphic: 0.383 +assembly: 0.367 +VMM: 0.347 +peripherals: 0.338 +TCG: 0.321 +hypervisor: 0.319 +ppc: 0.298 +permissions: 0.275 +virtual: 0.088 +user-level: 0.018 +KVM: 0.014 +i386: 0.004 +x86: 0.004 + +s390 host: helper_st16_mmu: Assertion `(get_memop(oi) & MO_SIZE) == MO_128' failed diff --git a/results/classifier/118/network/1754372 b/results/classifier/118/network/1754372 new file mode 100644 index 00000000..3b1d25d0 --- /dev/null +++ b/results/classifier/118/network/1754372 @@ -0,0 +1,48 @@ +network: 0.890 +device: 0.881 +architecture: 0.876 +kernel: 0.823 +vnc: 0.763 +socket: 0.754 +ppc: 0.709 +risc-v: 0.649 +semantic: 0.621 +files: 0.608 +VMM: 0.603 +performance: 0.603 +arm: 0.591 +permissions: 0.590 +TCG: 0.562 +graphic: 0.540 +boot: 0.527 +mistranslation: 0.523 +register: 0.510 +PID: 0.494 +peripherals: 0.470 +i386: 0.459 +x86: 0.437 +KVM: 0.375 +hypervisor: 0.370 +user-level: 0.351 +virtual: 0.344 +debug: 0.237 +assembly: 0.153 + +Set MIPS MSA in ELF Auxiliary Vectors + +The MIPS MSA feature is currently not set in the ELF auxiliary vector. + +That is, querying the AT_HWCAP key of the ELF auxiliary vectors for a MIPS CPU that has the MSA feature should return a value that has the second bit [0] set. + +From [0], `HWCAP_MIPS_MSA` is defined to `1 << 1`. + +[0]: https://github.com/torvalds/linux/blob/master/arch/mips/include/uapi/asm/hwcap.h + +Patch: +https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04399.html + +Fix now in master as commit 46a1ee4f397ff and will be in 2.12. + + +Thanks ! + diff --git a/results/classifier/118/network/1783 b/results/classifier/118/network/1783 new file mode 100644 index 00000000..addfc2fe --- /dev/null +++ b/results/classifier/118/network/1783 @@ -0,0 +1,33 @@ +network: 0.989 +virtual: 0.873 +graphic: 0.758 +device: 0.635 +mistranslation: 0.512 +risc-v: 0.482 +boot: 0.442 +VMM: 0.436 +vnc: 0.417 +arm: 0.410 +semantic: 0.405 +register: 0.401 +architecture: 0.303 +TCG: 0.264 +permissions: 0.235 +debug: 0.203 +ppc: 0.178 +PID: 0.177 +x86: 0.106 +i386: 0.105 +kernel: 0.095 +KVM: 0.084 +socket: 0.066 +performance: 0.063 +hypervisor: 0.044 +peripherals: 0.037 +files: 0.028 +assembly: 0.024 +user-level: 0.011 + +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/118/network/1814352 b/results/classifier/118/network/1814352 new file mode 100644 index 00000000..f5f88ef1 --- /dev/null +++ b/results/classifier/118/network/1814352 @@ -0,0 +1,97 @@ +network: 0.882 +graphic: 0.879 +vnc: 0.870 +socket: 0.857 +performance: 0.846 +semantic: 0.844 +architecture: 0.840 +arm: 0.840 +device: 0.834 +PID: 0.825 +files: 0.808 +risc-v: 0.805 +ppc: 0.805 +register: 0.804 +peripherals: 0.801 +mistranslation: 0.801 +hypervisor: 0.797 +debug: 0.793 +kernel: 0.793 +x86: 0.784 +virtual: 0.783 +boot: 0.776 +VMM: 0.771 +permissions: 0.771 +KVM: 0.767 +i386: 0.744 +assembly: 0.725 +TCG: 0.720 +user-level: 0.594 + +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))) +""" + +Your suggested fix looks good -- did you want to send it to qemu-devel with a suitable Signed-off-by: line ? + + +Sure. Looking at HEAD, and even the surrounding the lines, I think I +should have tried STRUCT_short_ifreq instead of STRUCT_int_ifreq, though +I'm not sure what the real difference would be. + +I'll try to test internally with the _short_ version and if that works send +that. + + +On Wed, 10 Apr 2019 at 01:26, Erik Kline <email address hidden> wrote: +> Sure. Looking at HEAD, and even the surrounding the lines, I think I +> should have tried STRUCT_short_ifreq instead of STRUCT_int_ifreq, though +> I'm not sure what the real difference would be. + +The multiple STRUCT_*_ifreq are working around the fact that +our MK_STRUCT infrastructure can't handle unions. The struct +ifreq is a char array followed by a union whose members are +various different types. You should use the STRUCT_*_ifreq +corresponding to whatever type the union field used by this +particular ioctl is. For SIOCGIFNAME the ifr_ifindex is read, +and that's an int, so you want STRUCT_int_ifreq. (If you used +the 'short' version by mistake this would probably break for the +case of big-endian guest and little-endian host or vice-versa +because we'd swap the wrong amount of data.) + +thanks +-- PMM + + +Patch sent to the list. Apologies for the delay. + +Please let me know if further work or another patch submission is required. + +Please let me know if further work or another patch submission is required. + +https://git.qemu.org/?p=qemu.git;a=commit;h=43330b7169ae76222472a4b20c7f4db9d8880527 + +Thank you, all. + +Released as part of v4.1.0. + diff --git a/results/classifier/118/network/1824622 b/results/classifier/118/network/1824622 new file mode 100644 index 00000000..2bfdda24 --- /dev/null +++ b/results/classifier/118/network/1824622 @@ -0,0 +1,49 @@ +network: 0.872 +x86: 0.792 +files: 0.745 +i386: 0.731 +device: 0.685 +debug: 0.666 +semantic: 0.566 +vnc: 0.558 +performance: 0.541 +ppc: 0.474 +socket: 0.453 +register: 0.448 +graphic: 0.439 +risc-v: 0.401 +PID: 0.390 +permissions: 0.344 +boot: 0.343 +TCG: 0.304 +arm: 0.295 +architecture: 0.286 +mistranslation: 0.259 +VMM: 0.225 +peripherals: 0.224 +kernel: 0.217 +user-level: 0.211 +hypervisor: 0.176 +virtual: 0.127 +KVM: 0.117 +assembly: 0.082 + +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 + + + +https://lists.nongnu.org/archive/html/qemu-discuss/2019-04/msg00026.html + +There is a Patch available which fixes this bug: https://lists.nongnu.org/archive/html/qemu-devel/2019-04/msg03497.html + +Fix applied to qemu 4.1 + diff --git a/results/classifier/118/network/1856834 b/results/classifier/118/network/1856834 new file mode 100644 index 00000000..51ab3e10 --- /dev/null +++ b/results/classifier/118/network/1856834 @@ -0,0 +1,230 @@ +network: 0.837 +permissions: 0.808 +virtual: 0.783 +kernel: 0.747 +boot: 0.743 +architecture: 0.743 +VMM: 0.739 +peripherals: 0.735 +debug: 0.708 +register: 0.704 +device: 0.701 +user-level: 0.685 +assembly: 0.682 +ppc: 0.675 +PID: 0.675 +risc-v: 0.672 +vnc: 0.646 +mistranslation: 0.645 +files: 0.639 +semantic: 0.636 +TCG: 0.630 +hypervisor: 0.581 +performance: 0.580 +arm: 0.570 +KVM: 0.552 +graphic: 0.540 +x86: 0.388 +socket: 0.341 +i386: 0.202 + +PCI broken in qemu ppc e500 in v2.12.0 and other versions + +The same qemu -M mpc... command that works on qemu-system-ppc version 2.8.0 freezes guest on bootup and shows error for qemu-system-ppc version 4.2.0release and 4.19dirtygit: + +qemu-system-ppc: virtio-blk failed to set guest notifier (-24), ensure -accel kvm is set. +qemu-system-ppc: virtio_bus_start_ioeventfd: failed. Fallback to userspace (slower). + +ends/freezes at: +nbd: registered device at major 43 + vda: + +I'm using -drive file=/home/me/rawimage.dd,if=virtio and works fine in version 2.8.0 installed with apt-get install (Ubuntu 17.04) and also with 2.8.0 official release from git/github that I compiled/built myself. But both of the newer releases fail on the same exact machine same config. + +I also noticed that qemu-2.8.0 was fine with mtd but the newer ones I tried weren't, ie gave +qemu-system-ppc: -drive if=mtd: machine type does not support if=mtd,bus=0,unit=0 +(but I removed -drive if=mtd since wasn't using it anyway) + +I also tried on windows but I think virtio doesn't work on windows hosts at all? On windows host it fails the same way, even version 2.12 as well as 4.1.10... + +used: +./configure --prefix=/opt/... --enable-fdt --enable-kvm --enable-debug + +(basically all steps the same on same exact system same config, yet 2.8.0 works fine whether apt-get installed or built from source while the others I built, 4.19/4.2.0 or 2.12/4.1.10(win) don't.) + +In case newer qemu versions act weird on various kernels, I did try with both vmlinuz-4.10.0-19-generic and vmlinuz-4.13.12-041312-generic (I didn't compile them but I can provide config-..files) +tx + ecs + +Also tested on another system (Debian GNU/Linux 9 \n \l with kernel SMP Debian 3.16.56-1+deb8u1 (2018-05-08) x86_64) besides the previous Ubuntu 17.04 and confirmed even Qemu 2.8.1 is working but Qemu 3.1.10 and higher not working, virtio fails/freezes guest at vda as on the other system. + +Could you provide the full qemu command line? + +Did you try with just a basic virtio disk and it works for you? + +Because even a basic virtio drive addition fails for me, even this fails on higher than 2.8.1 + +For example: +qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -drive file=/home/me/mmcblk0p2.dd,if=virtio + +The only thing I can think of, is if somehow vda fails due to me running the higher version qemu binaries from their build locations/paths without actually "installing" them in usual paths etc. + +But I ran the 2.8 version from build location I compiled it from and it worked from there, but perhaps the 2.8 version was also the distro installed default one so maybe it found dependencies it needed? + +Anyway I just now reconfigured 4.2.0 with --prefix /opt/qemu4.2.0 and ran it from installed dir: + +root@myserver:/opt/qemu4.2.0/bin# ./qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -drive file=/home/me/mmcblk0p2.dd,if=virtio + +But it still fails even after make install and running it from the /opt/qemu4.2.0/bin directory. +Is it somehow conflicting with the other qemu version 2.8.. installed by usual apt-get install? + +Regardless of how I start them, version 3.1.0 and 4.2.0rc4 and some other 4.19git and 4.2.0final all fail/freeze at: +" +.... +nbd: registered device at major 43 + vda: +" + + +Perhaps you can try to disable the "modern" mode of virtio (The endianness of the API has been changed): + +replace + + -drive file=/home/me/mmcblk0p2.dd,if=virtio + +by + + -device virtio-blk-pci,drive=drive0,disable-modern=true \ + -drive file=mmcblk0p2.dd,if=none,id=drive0,format=raw + +Thanks I tried with: + +/root/QEMU/qemu-git-4.2.0rc4/qemu/build/ppc-softmmu/qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -device virtio-blk-pci,drive=drive0,disable-modern=true -drive file=/home/me/mmcblk0p2.dd,if=none,id=drive0,format=raw + +And again it worked with qemu 2.8.1 but failed with the above 4.2.0rc4 on the same x86_64 host. + +On another x86_64 host I confirmed that the below works with qemu 2.8.0 + +root@myserver:~# qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -device virtio-blk-pci,drive=drive0,disable-modern=true -drive file=/home/me/mmcblk0p2.dd,if=none,id=drive0,format=raw + +But again even on this system 4.2.0 failes with that same command: +root@myserver:~# /root/QEMU/qemu-4.2.0/build/ppc-softmmu/qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -device virtio-blk-pci,drive=drive0,disable-modern=true -drive file=/home/me/mmcblk0p2.dd,if=none,id=drive0,format=raw + +Fails/freezes at the same vda: location. + +Running it from its installed location didn't help, the following still failed at vda: also. + +root@myserver:/opt/qemu4.2.0/bin# ./qemu-system-ppc -M mpc8544ds -nographic -kernel /home/me/boot/uImage-2.6.32 -append "root=/dev/vda rw" -device virtio-blk-pci,drive=drive0,disable-modern=true -drive file=/home/me/mmcblk0p2.dd,if=none,id=drive0,format=raw + +Although I didn't think its required for the softmmu qemu "emulation" only, ie not "kvm", I even enabled kvm as well as DMAR+IOMMU on the kernel and recompiled 4.2.0 but had same vda: failure. + + + + +fyi from what I recall guest kernel was built using mpc85xx_defconfig with some additions like virtio etc. If virtio is working for you just fine using same command as mine, then perhaps its some peculiarity to do with my specific guest kernel or kernel version? (uImage is about 3.4M with equivalent vmlinux about 72M) + +Hope you enjoyed the Holidays, Happy 2020! I would really appreciate if you could confirm for me if virtio works fine for you with ppc -M mpc8544ds with older Linux guest kernels like 2.6.32 +thanks! + +Could you provide your binary uImage-2.6.32? + +With some precautionary measures I think I can provide it. Not sure what of our drivers may already be compiled in etc so I need to send it to you privately so only you have access for testing etc after which you would delete it once issue fixed or discovered etc. Is it possible to send you private message on here with such a link or better email? thanks + +Sorry for the delay, I have sent you a private message/email with the actual kernel image. thx! + +This is broken by: + +commit 67113c03423a23e60915574275aed7d60e9f85e1 +Author: Michael Davidsaver <email address hidden> +Date: Sun Nov 26 15:59:05 2017 -0600 + + e500: fix pci host bridge class/type + + Correct some confusion wrt. the PCI facing + side of the PCI host bridge (not PCIe root complex). + The ref. manual for the mpc8533 (as well as + mpc8540 and mpc8540) give the class code as + PCI_CLASS_PROCESSOR_POWERPC. + While the PCI_HEADER_TYPE field is oddly omitted, + the tables in the "PCI Configuration Header" + section shows a type 0 layout using all 6 BAR + registers (as 2x 32, and 2x 64 bit regions) + + So 997505065dc92e533debf5cb23012ba4e673d387 + seems to be in error. Although there was + perhaps some confusion as the mpc8533 + has a separate PCIe root complex. + With PCIe, a root complex has PCI_HEADER_TYPE=1. + + Neither the PCI host bridge, nor the PCIe + root complex advertise class PCI_CLASS_BRIDGE_PCI. + + This was confusing Linux guests, which try + to interpret the host bridge as a pci-pci + bridge, but get confused and re-enumerate + the bus when the primary/secondary/subordinate + bus registers don't have valid values. + + Signed-off-by: Michael Davidsaver <email address hidden> + Signed-off-by: David Gibson <email address hidden> + + +If I revert 67113c03423a on top of master, vda is correctly detected. + +Thanks for all the help Laurent! I'm new to git so not surre how to 'properly' revert a previous commit on top of master, so I'll google, but if you have some a good link please do send. + +Also, I've heard of the term "bisect" for figuring out at which commit something breaks and if there were some good documentation to spell out the steps to do that for users that aren't, well advanced kernel gurus :D , I'm sure we'd be happy to save you smarter guys time with any mundane testing steps when possible :) thx! + +Not even reverting the patch worked for me, and it's still broken on qemu 5.1. + +For example: + +~/OSS/qemu/ppc-softmmu/qemu-system-ppc -machine mpc8544ds -nographic -cpu e500mc -serial mon:stdio -kernel zImage -initrd rootfs.ird -append 'console=ttyS0,115200' -device e1000,netdev=main -netdev hubport,hubid=0,id=main -net tap,ifname=tap0 -device virtio-balloon-pci -device virtio-rng-pci -device virtio-blk-pci-transitional,drive=drive0 -drive file=disk,if=none,id=drive0,format=raw + +causes the linux kernel to freeze after probing the virtio_blk device: + +virtio_rng: probe of virtio1 failed with error -22 +virtio_blk virtio2: [vda] 131072 512-byte logical blocks (67.1 MB/64.0 MiB) + +Not specifying the virtio-blk-pci device makes the system boot, but still all but the first (e1000) PCI devices seem to not probe. + +It seems I can trace this behavior at least to version 2.4.1, probably even sooner (can't make my linux boot on those, so I'm unsure...). + +After some research, the problem is that mpc8544ds has only 2 PCI slots defined (hw/ppc/mpc8544ds.c -> pmc->pci_nr_slots = 2;). This in turn results in DTB only contain 2 devices in pci@e0008000/interrupt-map. Too bad qemu doesn't complain when more devices are added - the PCI bars seem to be OK, just interrupts are not found by linux, hence the error -22: + +pci 8000:00:13.0: of_irq_parse_pci: failed with rc=-22 + +...and later virtio_rng probe freeze (which freezes linux boot, if a module is not used and probed in different process). + +Changing pci_nr_slots to bigger number (e.g. 4) seems to work just OK, though of course the mpc8544ds simulation is then non-realistic. A cleaner solution is adding PCI-PCI bridge, that seems to work too. + +As a side-note, MSI doesn't seem to work on e500mc neither. Enabling MSI support in kernel seems to cause that virtio-blk-pci device probe freeze in linux, /proc/interrupts shows: + + 19: 0 fsl-msi-224 0 Edge virtio1-config + 20: 0 fsl-msi-224 1 Edge virtio1-req.0 + +Without MSI, legacy IRQ is used and that seems to work OK: + + 17: 743 OpenPIC 3 Level virtio1 + +Alternatively, passing vectors=0 to the virtio device (-device virtio-blk,drive=drive0,vectors=0 -drive ...) does the trick as well. + +That was a fun ride... :-) + +Sorry, above I meant "virtio-blk freeze" (no virtio_rng). But in any case it's obviously not directly related to this bug, so disregard it... Sorry for the noise. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1861875 b/results/classifier/118/network/1861875 new file mode 100644 index 00000000..b6e365a0 --- /dev/null +++ b/results/classifier/118/network/1861875 @@ -0,0 +1,65 @@ +network: 0.926 +x86: 0.900 +device: 0.774 +performance: 0.707 +architecture: 0.691 +graphic: 0.688 +virtual: 0.686 +peripherals: 0.672 +VMM: 0.661 +PID: 0.658 +hypervisor: 0.641 +mistranslation: 0.598 +user-level: 0.582 +kernel: 0.582 +vnc: 0.577 +semantic: 0.574 +socket: 0.563 +i386: 0.526 +files: 0.520 +ppc: 0.507 +register: 0.496 +permissions: 0.477 +debug: 0.448 +risc-v: 0.415 +boot: 0.411 +assembly: 0.408 +TCG: 0.365 +KVM: 0.340 +arm: 0.324 + +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 + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1862979 b/results/classifier/118/network/1862979 new file mode 100644 index 00000000..d2cedce2 --- /dev/null +++ b/results/classifier/118/network/1862979 @@ -0,0 +1,61 @@ +network: 0.850 +device: 0.846 +socket: 0.837 +graphic: 0.785 +virtual: 0.681 +vnc: 0.676 +semantic: 0.638 +performance: 0.575 +PID: 0.539 +VMM: 0.519 +ppc: 0.511 +i386: 0.486 +mistranslation: 0.477 +risc-v: 0.466 +kernel: 0.456 +user-level: 0.444 +register: 0.414 +debug: 0.393 +arm: 0.388 +x86: 0.385 +peripherals: 0.365 +files: 0.358 +boot: 0.343 +architecture: 0.328 +permissions: 0.328 +assembly: 0.319 +hypervisor: 0.297 +TCG: 0.244 +KVM: 0.195 + +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. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/1874539 b/results/classifier/118/network/1874539 new file mode 100644 index 00000000..4f6d8930 --- /dev/null +++ b/results/classifier/118/network/1874539 @@ -0,0 +1,59 @@ +network: 0.869 +files: 0.859 +semantic: 0.824 +performance: 0.800 +PID: 0.702 +user-level: 0.695 +peripherals: 0.654 +ppc: 0.644 +graphic: 0.620 +vnc: 0.611 +virtual: 0.585 +socket: 0.549 +mistranslation: 0.543 +hypervisor: 0.532 +architecture: 0.525 +register: 0.522 +device: 0.512 +TCG: 0.506 +VMM: 0.473 +boot: 0.440 +permissions: 0.417 +debug: 0.409 +arm: 0.386 +risc-v: 0.382 +kernel: 0.366 +i386: 0.316 +x86: 0.311 +KVM: 0.302 +assembly: 0.229 + +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 + +Commit 8ffb7265af does make the code safer, but broke the device model. +Instead of setting the error bits when the frame length is incorrect (too big), it simply discards it. The guest is not notified of the error and keeps waiting. + +Attached trivial patch fixes it. + + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d9b69640391618045 + diff --git a/results/classifier/118/network/1874676 b/results/classifier/118/network/1874676 new file mode 100644 index 00000000..cf8c69e1 --- /dev/null +++ b/results/classifier/118/network/1874676 @@ -0,0 +1,53 @@ +network: 0.818 +device: 0.741 +graphic: 0.639 +register: 0.503 +semantic: 0.500 +socket: 0.490 +vnc: 0.479 +PID: 0.465 +mistranslation: 0.434 +architecture: 0.432 +files: 0.413 +ppc: 0.399 +permissions: 0.377 +risc-v: 0.357 +user-level: 0.342 +peripherals: 0.324 +virtual: 0.323 +kernel: 0.315 +performance: 0.315 +debug: 0.304 +VMM: 0.289 +boot: 0.288 +i386: 0.282 +hypervisor: 0.234 +assembly: 0.227 +TCG: 0.218 +x86: 0.196 +KVM: 0.186 +arm: 0.178 + +[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 + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +OK. Feel free to change the status to Won't Fix. + + +This is an automated cleanup. This bug report has been moved +to QEMU's new bug tracker on gitlab.com and thus gets marked +as 'expired' now. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/49 + + diff --git a/results/classifier/118/network/1876 b/results/classifier/118/network/1876 new file mode 100644 index 00000000..56ab92ce --- /dev/null +++ b/results/classifier/118/network/1876 @@ -0,0 +1,31 @@ +network: 0.813 +performance: 0.710 +device: 0.605 +mistranslation: 0.598 +debug: 0.531 +semantic: 0.301 +graphic: 0.290 +arm: 0.260 +virtual: 0.255 +user-level: 0.155 +architecture: 0.149 +permissions: 0.139 +TCG: 0.108 +ppc: 0.103 +register: 0.090 +VMM: 0.087 +PID: 0.081 +vnc: 0.081 +boot: 0.077 +socket: 0.066 +i386: 0.045 +peripherals: 0.039 +risc-v: 0.037 +files: 0.027 +x86: 0.021 +assembly: 0.020 +hypervisor: 0.015 +KVM: 0.008 +kernel: 0.003 + +Host wayland gtk problem diff --git a/results/classifier/118/network/1881 b/results/classifier/118/network/1881 new file mode 100644 index 00000000..47af2dcd --- /dev/null +++ b/results/classifier/118/network/1881 @@ -0,0 +1,45 @@ +network: 0.981 +socket: 0.980 +graphic: 0.904 +device: 0.894 +PID: 0.888 +TCG: 0.870 +ppc: 0.852 +architecture: 0.827 +performance: 0.822 +permissions: 0.821 +vnc: 0.806 +VMM: 0.755 +register: 0.743 +kernel: 0.738 +files: 0.723 +debug: 0.707 +semantic: 0.657 +risc-v: 0.643 +arm: 0.634 +mistranslation: 0.598 +boot: 0.517 +peripherals: 0.514 +user-level: 0.506 +virtual: 0.311 +x86: 0.274 +i386: 0.237 +KVM: 0.215 +hypervisor: 0.179 +assembly: 0.137 + +netdev-socket test_stream_unix() is unreliable +Description of problem: +test_stream_unix is unreliable and causes random CI job failures such as this one: +https://gitlab.com/qemu-project/qemu/-/jobs/5020899550 + +``` +576/839 ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n") ERROR +576/839 qemu:qtest+qtest-sh4 / qtest-sh4/netdev-socket ERROR 62.85s killed by signal 6 SIGABRT +>>> MALLOC_PERTURB_=249 QTEST_QEMU_BINARY=./qemu-system-sh4 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img /home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/build/tests/qtest/netdev-socket --tap -k +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +** +ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n") +(test program exited with status code -6) +``` diff --git a/results/classifier/118/network/1884169 b/results/classifier/118/network/1884169 new file mode 100644 index 00000000..6fa71f67 --- /dev/null +++ b/results/classifier/118/network/1884169 @@ -0,0 +1,48 @@ +network: 0.838 +device: 0.636 +semantic: 0.506 +mistranslation: 0.501 +user-level: 0.372 +graphic: 0.370 +performance: 0.361 +architecture: 0.300 +permissions: 0.288 +KVM: 0.259 +virtual: 0.225 +peripherals: 0.217 +hypervisor: 0.209 +debug: 0.157 +files: 0.148 +i386: 0.139 +PID: 0.133 +x86: 0.121 +ppc: 0.113 +vnc: 0.096 +register: 0.092 +arm: 0.089 +kernel: 0.076 +boot: 0.063 +socket: 0.061 +VMM: 0.050 +assembly: 0.046 +risc-v: 0.042 +TCG: 0.028 + +There is no option group 'fsdev' for OSX + +When I try to use -fsoption on OSX I receive this error: + +-fsdev local,security_model=mapped,id=fsdev0,path=devel/dmos-example: There is no option group 'fsdev' + +That's the behaviour on macOS that I would expect ATM. So it's not a bug. + +Your macOS version was compiled without virtfs support, that's why qemu does not even offer you these options. + +Even though 9P is a network protocol, you still need support by host OS and guest OS for some kind of communication channel between host and guest. Currently 9pfs in qemu supports either virtio (Linux KVM host <-> Linux guest) or Xen as communication channel. For macOS so far nobody bothered to implement a communication driver for qemu 9pfs yet. + +But actually OS X (macOS) supports 9pfs and it does have its own AppleVirtIO9PVFS which makes things a bit strange, would not that be a good workaround, to use the AppleVirtIO9PVFS? + +All my best, + +Waheed + diff --git a/results/classifier/118/network/190 b/results/classifier/118/network/190 new file mode 100644 index 00000000..fbc5fb8e --- /dev/null +++ b/results/classifier/118/network/190 @@ -0,0 +1,31 @@ +network: 0.942 +device: 0.914 +debug: 0.851 +mistranslation: 0.813 +performance: 0.770 +socket: 0.683 +peripherals: 0.678 +architecture: 0.656 +semantic: 0.637 +arm: 0.538 +graphic: 0.525 +vnc: 0.346 +ppc: 0.312 +user-level: 0.262 +TCG: 0.260 +VMM: 0.237 +files: 0.227 +risc-v: 0.222 +virtual: 0.205 +hypervisor: 0.200 +register: 0.168 +permissions: 0.166 +boot: 0.155 +PID: 0.148 +x86: 0.058 +assembly: 0.053 +kernel: 0.044 +KVM: 0.019 +i386: 0.016 + +'set_link net0 off' not working with e1000e driver diff --git a/results/classifier/118/network/1904954 b/results/classifier/118/network/1904954 new file mode 100644 index 00000000..6b0ba7a5 --- /dev/null +++ b/results/classifier/118/network/1904954 @@ -0,0 +1,70 @@ +network: 0.849 +socket: 0.785 +mistranslation: 0.751 +device: 0.672 +kernel: 0.603 +peripherals: 0.577 +ppc: 0.565 +graphic: 0.561 +files: 0.550 +performance: 0.536 +semantic: 0.531 +user-level: 0.530 +vnc: 0.511 +register: 0.479 +risc-v: 0.436 +hypervisor: 0.431 +arm: 0.423 +architecture: 0.420 +boot: 0.407 +PID: 0.389 +permissions: 0.367 +TCG: 0.356 +VMM: 0.321 +virtual: 0.306 +i386: 0.284 +x86: 0.238 +assembly: 0.233 +debug: 0.210 +KVM: 0.196 + +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 + +Do you have a test case that will reproduce this bug ? + + +(The line of code you point out is pretty clearly wrong; it would just be nice to have a test case to confirm that the obvious fix works.) + +This patchset should fix this bug: +https://<email address hidden>/ + +PS: this isn't a security issue because the lan9118 is used only on board models that can't run under KVM and so it is not on QEMU's security boundary. + + +We do have some code, that is giving different results, between the peeked and the actual: + +https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/9a25860e761036a9eb780799c9db632e3eff60c9/portable/NetworkInterface/MPS2_AN385/NetworkInterface.c#L237 + +We also have a fix to circumvent the problem by just reading the actual size and omit the peeked bytes. + +https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/pull/142 + +changing the code i pointed locally worked fine, but we can't expect all our users to compile qemu from scratch and apply a patch + +Alfred + +Fix now in master: commit e7e29fdbbe07f. + + diff --git a/results/classifier/118/network/2019 b/results/classifier/118/network/2019 new file mode 100644 index 00000000..2dedb2a5 --- /dev/null +++ b/results/classifier/118/network/2019 @@ -0,0 +1,56 @@ +network: 0.953 +socket: 0.884 +boot: 0.784 +graphic: 0.702 +user-level: 0.671 +ppc: 0.635 +PID: 0.603 +device: 0.554 +files: 0.536 +semantic: 0.513 +kernel: 0.479 +performance: 0.454 +architecture: 0.448 +hypervisor: 0.439 +debug: 0.410 +virtual: 0.353 +permissions: 0.343 +assembly: 0.335 +x86: 0.316 +risc-v: 0.295 +register: 0.289 +mistranslation: 0.274 +VMM: 0.268 +vnc: 0.230 +TCG: 0.225 +KVM: 0.209 +peripherals: 0.200 +i386: 0.177 +arm: 0.134 + +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/118/network/2024 b/results/classifier/118/network/2024 new file mode 100644 index 00000000..78664288 --- /dev/null +++ b/results/classifier/118/network/2024 @@ -0,0 +1,60 @@ +network: 0.968 +debug: 0.967 +boot: 0.958 +files: 0.943 +architecture: 0.935 +virtual: 0.930 +hypervisor: 0.918 +device: 0.912 +ppc: 0.910 +PID: 0.899 +peripherals: 0.845 +graphic: 0.832 +vnc: 0.780 +register: 0.773 +performance: 0.764 +socket: 0.746 +kernel: 0.709 +VMM: 0.702 +permissions: 0.701 +semantic: 0.701 +assembly: 0.687 +risc-v: 0.637 +user-level: 0.627 +arm: 0.627 +x86: 0.623 +i386: 0.586 +TCG: 0.556 +KVM: 0.520 +mistranslation: 0.494 + +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/118/network/2088 b/results/classifier/118/network/2088 new file mode 100644 index 00000000..770f598b --- /dev/null +++ b/results/classifier/118/network/2088 @@ -0,0 +1,51 @@ +network: 0.903 +graphic: 0.891 +permissions: 0.887 +files: 0.874 +device: 0.858 +architecture: 0.823 +PID: 0.817 +register: 0.803 +hypervisor: 0.792 +socket: 0.787 +mistranslation: 0.784 +peripherals: 0.769 +kernel: 0.759 +ppc: 0.752 +arm: 0.716 +vnc: 0.714 +semantic: 0.695 +debug: 0.673 +risc-v: 0.612 +boot: 0.601 +performance: 0.598 +VMM: 0.530 +assembly: 0.530 +user-level: 0.521 +TCG: 0.516 +i386: 0.449 +virtual: 0.380 +x86: 0.353 +KVM: 0.146 + +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/118/network/2109 b/results/classifier/118/network/2109 new file mode 100644 index 00000000..bbb62b4d --- /dev/null +++ b/results/classifier/118/network/2109 @@ -0,0 +1,31 @@ +network: 0.968 +virtual: 0.903 +device: 0.865 +architecture: 0.723 +vnc: 0.608 +arm: 0.560 +boot: 0.514 +VMM: 0.419 +graphic: 0.379 +performance: 0.312 +socket: 0.222 +debug: 0.217 +PID: 0.172 +register: 0.172 +hypervisor: 0.170 +i386: 0.146 +TCG: 0.143 +risc-v: 0.134 +ppc: 0.105 +semantic: 0.103 +peripherals: 0.100 +files: 0.094 +x86: 0.071 +mistranslation: 0.062 +user-level: 0.048 +kernel: 0.045 +permissions: 0.020 +assembly: 0.004 +KVM: 0.001 + +NetBSD VM fails to install due to missing py311-expat package diff --git a/results/classifier/118/network/2143 b/results/classifier/118/network/2143 new file mode 100644 index 00000000..c291f3b8 --- /dev/null +++ b/results/classifier/118/network/2143 @@ -0,0 +1,68 @@ +network: 0.920 +performance: 0.891 +peripherals: 0.885 +architecture: 0.875 +boot: 0.856 +graphic: 0.833 +debug: 0.815 +socket: 0.813 +device: 0.809 +ppc: 0.801 +semantic: 0.783 +arm: 0.719 +hypervisor: 0.689 +mistranslation: 0.671 +permissions: 0.669 +PID: 0.661 +user-level: 0.579 +x86: 0.557 +i386: 0.555 +KVM: 0.536 +assembly: 0.535 +vnc: 0.531 +TCG: 0.529 +kernel: 0.526 +risc-v: 0.481 +virtual: 0.441 +files: 0.434 +VMM: 0.423 +register: 0.390 + +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/118/network/2182 b/results/classifier/118/network/2182 new file mode 100644 index 00000000..e196ad92 --- /dev/null +++ b/results/classifier/118/network/2182 @@ -0,0 +1,31 @@ +network: 0.915 +performance: 0.313 +vnc: 0.284 +graphic: 0.259 +VMM: 0.201 +KVM: 0.197 +risc-v: 0.178 +ppc: 0.165 +TCG: 0.161 +i386: 0.110 +virtual: 0.108 +boot: 0.091 +socket: 0.074 +arm: 0.071 +x86: 0.066 +PID: 0.065 +register: 0.063 +semantic: 0.047 +architecture: 0.044 +device: 0.032 +mistranslation: 0.025 +hypervisor: 0.024 +peripherals: 0.013 +user-level: 0.012 +kernel: 0.012 +files: 0.009 +assembly: 0.007 +debug: 0.006 +permissions: 0.003 + +Replication and Network diff --git a/results/classifier/118/network/2209 b/results/classifier/118/network/2209 new file mode 100644 index 00000000..f43e1262 --- /dev/null +++ b/results/classifier/118/network/2209 @@ -0,0 +1,77 @@ +network: 0.832 +files: 0.810 +debug: 0.781 +risc-v: 0.773 +PID: 0.672 +performance: 0.618 +device: 0.608 +ppc: 0.602 +VMM: 0.600 +mistranslation: 0.600 +socket: 0.555 +hypervisor: 0.553 +kernel: 0.546 +semantic: 0.529 +permissions: 0.528 +vnc: 0.526 +peripherals: 0.518 +architecture: 0.496 +user-level: 0.454 +arm: 0.434 +TCG: 0.429 +register: 0.424 +assembly: 0.423 +i386: 0.402 +graphic: 0.395 +KVM: 0.380 +x86: 0.356 +boot: 0.307 +virtual: 0.233 + +no 'system' llibfdt (or too old), subprojects/dtc/ populated, ./configure --disable-download fails +Description of problem: +./configure ... --disable-download, with subprojects/ pre-populated, fails. +Steps to reproduce: +1. ensure libfdt/dtc files/libs/binaries are *not* found in system +2. have subprojects/dtc pre-populated +3. ./configure --target-list=riscv32-softmmu --prefix=/opt/riscv --enable-debug --without-default-features --without-default-devices --disable-download + +configure fails with: +``` +../meson.build:3171:13: ERROR: C shared or static library 'fdt' not found + +A full log can be found at /home/too/vc/ext/qemu/build/meson-logs/meson-log.txt + +ERROR: meson setup failed +``` + +If I outcomment the following lines in meson.build: +``` + #if get_option('wrap_mode') == 'nodownload' + # fdt_opt = 'system' + #endif +``` +Then the above command line works (with --disable-download) +Additional information: +The case is where one wants to ensure that configure does not try to access +network while doing its job. And in a system where dtc/libfdt is not available, +(or is too old, line in Centos/RHEL 7) one has dowloaded the files already in +subprojects/dtc/. + +The meson.build clearly sets (as of 2024-03-05) expectation that dtc/libfdt/ +has to come from 'system' if 'wrap_mode' is set to 'nodownload'. + +Without this check it it works nicely -- and if subprojects/dtc/ was not populated, +the error message is + +``` +Library fdt found: NO + +../meson.build:3187:18: ERROR: Automatic wrap-based subproject downloading is disabled + +A full log can be found at /home/too/vc/ext/qemu/build/meson-logs/meson-log.txt + +ERROR: meson setup failed +``` + +So -- to me -- that looks like it could be a suitable solution to this problem. diff --git a/results/classifier/118/network/2228 b/results/classifier/118/network/2228 new file mode 100644 index 00000000..11f173fb --- /dev/null +++ b/results/classifier/118/network/2228 @@ -0,0 +1,38 @@ +network: 0.838 +device: 0.829 +graphic: 0.827 +peripherals: 0.717 +performance: 0.708 +socket: 0.706 +kernel: 0.694 +PID: 0.664 +register: 0.607 +architecture: 0.561 +x86: 0.523 +debug: 0.516 +files: 0.514 +vnc: 0.496 +boot: 0.427 +i386: 0.415 +hypervisor: 0.405 +ppc: 0.375 +VMM: 0.276 +arm: 0.256 +TCG: 0.249 +semantic: 0.227 +permissions: 0.220 +risc-v: 0.167 +assembly: 0.160 +KVM: 0.147 +user-level: 0.121 +virtual: 0.110 +mistranslation: 0.078 + +hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed +Description of problem: +It's quite easy to trigger the assertion ``hw/core/gpio.c:108: qdev_get_gpio_in_named: Assertion n >= 0 && n < gpio_list->num_in failed`` +Steps to reproduce: +Run one of the following command lines: +1. ``./qemu-system-aarch64 -display none -machine qcom-dc-scm-v1-bmc -device max1111`` +2. ``./qemu-system-aarch64 -display none -machine fby35-bmc -device max1110`` +3. ``./qemu-system-aarch64 -display none -machine yosemitev2-bmc -device corgi-ssp`` diff --git a/results/classifier/118/network/235 b/results/classifier/118/network/235 new file mode 100644 index 00000000..3ee07540 --- /dev/null +++ b/results/classifier/118/network/235 @@ -0,0 +1,31 @@ +network: 0.816 +device: 0.810 +architecture: 0.716 +arm: 0.637 +vnc: 0.578 +VMM: 0.548 +risc-v: 0.524 +kernel: 0.514 +TCG: 0.479 +PID: 0.453 +ppc: 0.408 +boot: 0.392 +debug: 0.368 +graphic: 0.367 +performance: 0.323 +register: 0.322 +socket: 0.244 +files: 0.171 +KVM: 0.161 +mistranslation: 0.107 +peripherals: 0.085 +hypervisor: 0.077 +semantic: 0.068 +user-level: 0.066 +i386: 0.061 +virtual: 0.046 +assembly: 0.032 +permissions: 0.024 +x86: 0.002 + +atomic failure linking with --enable-sanitizers on 32-bit Linux hosts diff --git a/results/classifier/118/network/2364 b/results/classifier/118/network/2364 new file mode 100644 index 00000000..6baa18c0 --- /dev/null +++ b/results/classifier/118/network/2364 @@ -0,0 +1,31 @@ +network: 0.890 +device: 0.538 +permissions: 0.414 +architecture: 0.392 +debug: 0.207 +graphic: 0.200 +hypervisor: 0.186 +peripherals: 0.183 +performance: 0.157 +assembly: 0.120 +arm: 0.109 +mistranslation: 0.088 +register: 0.087 +ppc: 0.086 +virtual: 0.082 +boot: 0.076 +semantic: 0.065 +TCG: 0.059 +VMM: 0.058 +risc-v: 0.051 +PID: 0.042 +socket: 0.038 +user-level: 0.034 +vnc: 0.032 +KVM: 0.004 +kernel: 0.004 +files: 0.003 +i386: 0.002 +x86: 0.001 + +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/118/network/2409 b/results/classifier/118/network/2409 new file mode 100644 index 00000000..668cd64d --- /dev/null +++ b/results/classifier/118/network/2409 @@ -0,0 +1,31 @@ +network: 0.981 +device: 0.968 +performance: 0.945 +graphic: 0.767 +ppc: 0.672 +register: 0.567 +semantic: 0.531 +TCG: 0.501 +vnc: 0.490 +risc-v: 0.464 +arm: 0.397 +PID: 0.369 +VMM: 0.346 +mistranslation: 0.267 +i386: 0.251 +debug: 0.244 +boot: 0.233 +architecture: 0.209 +user-level: 0.187 +permissions: 0.104 +KVM: 0.096 +hypervisor: 0.077 +virtual: 0.066 +kernel: 0.040 +x86: 0.025 +files: 0.022 +assembly: 0.019 +socket: 0.009 +peripherals: 0.004 + +High CPU usage on network traffic on Apple laptops diff --git a/results/classifier/118/network/2459 b/results/classifier/118/network/2459 new file mode 100644 index 00000000..94554403 --- /dev/null +++ b/results/classifier/118/network/2459 @@ -0,0 +1,31 @@ +network: 0.942 +mistranslation: 0.827 +graphic: 0.479 +semantic: 0.289 +device: 0.205 +debug: 0.155 +performance: 0.154 +ppc: 0.146 +socket: 0.110 +risc-v: 0.108 +vnc: 0.098 +virtual: 0.097 +architecture: 0.088 +TCG: 0.059 +hypervisor: 0.054 +register: 0.048 +arm: 0.043 +VMM: 0.040 +peripherals: 0.038 +user-level: 0.036 +PID: 0.029 +permissions: 0.028 +boot: 0.025 +assembly: 0.012 +kernel: 0.009 +i386: 0.008 +files: 0.004 +KVM: 0.003 +x86: 0.002 + +Qemu in termux network bug diff --git a/results/classifier/118/network/2494 b/results/classifier/118/network/2494 new file mode 100644 index 00000000..1d4b597b --- /dev/null +++ b/results/classifier/118/network/2494 @@ -0,0 +1,31 @@ +network: 0.956 +virtual: 0.940 +architecture: 0.872 +peripherals: 0.803 +VMM: 0.792 +device: 0.781 +performance: 0.731 +KVM: 0.685 +risc-v: 0.668 +vnc: 0.658 +hypervisor: 0.640 +TCG: 0.616 +PID: 0.603 +ppc: 0.594 +register: 0.536 +arm: 0.510 +i386: 0.483 +debug: 0.476 +semantic: 0.447 +x86: 0.429 +assembly: 0.425 +kernel: 0.423 +graphic: 0.410 +boot: 0.381 +socket: 0.352 +permissions: 0.287 +mistranslation: 0.128 +user-level: 0.120 +files: 0.107 + +Isolated network between VMs not visible to the host diff --git a/results/classifier/118/network/2514 b/results/classifier/118/network/2514 new file mode 100644 index 00000000..b8985074 --- /dev/null +++ b/results/classifier/118/network/2514 @@ -0,0 +1,31 @@ +network: 0.981 +virtual: 0.925 +performance: 0.726 +VMM: 0.618 +mistranslation: 0.596 +vnc: 0.593 +debug: 0.590 +register: 0.556 +device: 0.556 +architecture: 0.521 +graphic: 0.498 +ppc: 0.497 +arm: 0.490 +risc-v: 0.489 +socket: 0.458 +TCG: 0.449 +hypervisor: 0.419 +semantic: 0.408 +PID: 0.407 +peripherals: 0.377 +boot: 0.364 +KVM: 0.323 +permissions: 0.266 +kernel: 0.231 +files: 0.215 +x86: 0.147 +i386: 0.136 +user-level: 0.085 +assembly: 0.085 + +network unreachable to esxi 8 guest diff --git a/results/classifier/118/network/2528 b/results/classifier/118/network/2528 new file mode 100644 index 00000000..9134e056 --- /dev/null +++ b/results/classifier/118/network/2528 @@ -0,0 +1,39 @@ +network: 0.940 +device: 0.797 +graphic: 0.597 +debug: 0.518 +vnc: 0.402 +performance: 0.355 +socket: 0.327 +files: 0.322 +semantic: 0.311 +boot: 0.309 +risc-v: 0.269 +ppc: 0.227 +i386: 0.199 +register: 0.198 +x86: 0.181 +kernel: 0.149 +hypervisor: 0.139 +arm: 0.130 +PID: 0.122 +VMM: 0.099 +TCG: 0.093 +user-level: 0.076 +KVM: 0.059 +virtual: 0.047 +architecture: 0.046 +assembly: 0.044 +mistranslation: 0.038 +peripherals: 0.034 +permissions: 0.014 + +nbd: CVE-2024-7409 fix is incomplete +Description of problem: +Patch will hit list soon, but opening issue here since if this misses 9.1, we would need to allocate a second CVE for having an incomplete fix (a remaining use-after-free) in the code originally proposed for CVE-2024-7409. +Steps to reproduce: +1. stress test of attempting repeated 'qemu-nbd --list' in parallel with repeated 'nbd-server-start/nbd-server-stop' loops in a qemu process revealed a use-after-free SEGV of nbd_server->listener +2. +3. +Additional information: + diff --git a/results/classifier/118/network/2623 b/results/classifier/118/network/2623 new file mode 100644 index 00000000..82788fdd --- /dev/null +++ b/results/classifier/118/network/2623 @@ -0,0 +1,31 @@ +network: 0.951 +performance: 0.902 +device: 0.869 +arm: 0.670 +architecture: 0.606 +debug: 0.577 +semantic: 0.435 +boot: 0.364 +hypervisor: 0.354 +ppc: 0.338 +register: 0.328 +kernel: 0.303 +mistranslation: 0.301 +risc-v: 0.283 +peripherals: 0.273 +graphic: 0.232 +TCG: 0.230 +socket: 0.209 +vnc: 0.191 +x86: 0.186 +user-level: 0.186 +i386: 0.172 +VMM: 0.161 +virtual: 0.136 +KVM: 0.097 +assembly: 0.093 +permissions: 0.084 +PID: 0.055 +files: 0.022 + +Timeout waiting for ARP/RARP packets diff --git a/results/classifier/118/network/2668 b/results/classifier/118/network/2668 new file mode 100644 index 00000000..4be9d795 --- /dev/null +++ b/results/classifier/118/network/2668 @@ -0,0 +1,33 @@ +network: 0.943 +vnc: 0.915 +device: 0.909 +architecture: 0.908 +arm: 0.829 +virtual: 0.777 +ppc: 0.776 +socket: 0.762 +kernel: 0.743 +files: 0.738 +risc-v: 0.688 +graphic: 0.658 +mistranslation: 0.657 +performance: 0.653 +register: 0.644 +boot: 0.628 +semantic: 0.606 +i386: 0.592 +permissions: 0.561 +PID: 0.544 +debug: 0.504 +VMM: 0.501 +hypervisor: 0.495 +x86: 0.461 +assembly: 0.411 +peripherals: 0.396 +TCG: 0.389 +KVM: 0.237 +user-level: 0.231 + +h.264 encoding/compression support +Additional information: +noVNC now support h.264 decoding. diff --git a/results/classifier/118/network/2685 b/results/classifier/118/network/2685 new file mode 100644 index 00000000..5839f93a --- /dev/null +++ b/results/classifier/118/network/2685 @@ -0,0 +1,31 @@ +architecture: 0.985 +network: 0.926 +TCG: 0.917 +device: 0.769 +performance: 0.745 +arm: 0.692 +debug: 0.403 +graphic: 0.383 +register: 0.309 +semantic: 0.279 +boot: 0.270 +mistranslation: 0.259 +permissions: 0.213 +risc-v: 0.212 +PID: 0.208 +peripherals: 0.190 +vnc: 0.172 +files: 0.119 +hypervisor: 0.115 +VMM: 0.102 +socket: 0.099 +virtual: 0.078 +ppc: 0.061 +assembly: 0.024 +x86: 0.022 +kernel: 0.020 +user-level: 0.016 +KVM: 0.011 +i386: 0.005 + +Netbsd 10.0 AMD64 as host fails in tcg? diff --git a/results/classifier/118/network/2688 b/results/classifier/118/network/2688 new file mode 100644 index 00000000..1893e521 --- /dev/null +++ b/results/classifier/118/network/2688 @@ -0,0 +1,31 @@ +network: 0.956 +user-level: 0.790 +architecture: 0.769 +device: 0.742 +performance: 0.713 +vnc: 0.635 +arm: 0.634 +VMM: 0.610 +TCG: 0.588 +PID: 0.542 +ppc: 0.541 +debug: 0.517 +risc-v: 0.471 +kernel: 0.441 +KVM: 0.413 +semantic: 0.403 +socket: 0.393 +files: 0.374 +i386: 0.372 +graphic: 0.367 +boot: 0.357 +x86: 0.321 +assembly: 0.315 +hypervisor: 0.264 +register: 0.227 +mistranslation: 0.168 +virtual: 0.167 +peripherals: 0.117 +permissions: 0.101 + +Add `disable_host_loopback` for network user backend diff --git a/results/classifier/118/network/2745 b/results/classifier/118/network/2745 new file mode 100644 index 00000000..cb9e52a2 --- /dev/null +++ b/results/classifier/118/network/2745 @@ -0,0 +1,56 @@ +network: 0.922 +virtual: 0.873 +kernel: 0.828 +peripherals: 0.740 +architecture: 0.720 +hypervisor: 0.717 +graphic: 0.715 +performance: 0.708 +device: 0.652 +permissions: 0.622 +PID: 0.611 +semantic: 0.543 +socket: 0.535 +register: 0.429 +ppc: 0.417 +risc-v: 0.387 +user-level: 0.354 +boot: 0.330 +x86: 0.330 +VMM: 0.322 +debug: 0.317 +files: 0.305 +KVM: 0.293 +mistranslation: 0.289 +vnc: 0.281 +assembly: 0.269 +TCG: 0.257 +arm: 0.243 +i386: 0.238 + +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/118/network/2746 b/results/classifier/118/network/2746 new file mode 100644 index 00000000..c7388709 --- /dev/null +++ b/results/classifier/118/network/2746 @@ -0,0 +1,31 @@ +network: 0.847 +semantic: 0.787 +device: 0.780 +performance: 0.751 +hypervisor: 0.617 +mistranslation: 0.572 +graphic: 0.555 +peripherals: 0.453 +kernel: 0.452 +architecture: 0.444 +debug: 0.357 +arm: 0.343 +socket: 0.341 +vnc: 0.271 +register: 0.241 +files: 0.235 +user-level: 0.219 +virtual: 0.214 +TCG: 0.202 +assembly: 0.196 +VMM: 0.189 +boot: 0.178 +risc-v: 0.163 +permissions: 0.154 +ppc: 0.146 +PID: 0.098 +x86: 0.092 +KVM: 0.090 +i386: 0.060 + +NO_CAST.INTEGER_OVERFLOW in /hw/net/e1000.c diff --git a/results/classifier/118/network/2756 b/results/classifier/118/network/2756 new file mode 100644 index 00000000..8823b998 --- /dev/null +++ b/results/classifier/118/network/2756 @@ -0,0 +1,72 @@ +network: 0.991 +device: 0.984 +socket: 0.975 +hypervisor: 0.972 +user-level: 0.958 +graphic: 0.954 +peripherals: 0.948 +kernel: 0.937 +vnc: 0.933 +risc-v: 0.932 +performance: 0.929 +debug: 0.919 +virtual: 0.918 +VMM: 0.913 +KVM: 0.911 +ppc: 0.898 +arm: 0.882 +x86: 0.851 +boot: 0.843 +TCG: 0.838 +PID: 0.819 +permissions: 0.807 +mistranslation: 0.765 +register: 0.760 +semantic: 0.742 +architecture: 0.733 +i386: 0.696 +assembly: 0.533 +files: 0.395 + +Unexpected port id 2909357808 for device virtio-serial0.0 +Description of problem: +when the VM runs for a period of time.qemu log always print the error：“Unexpected port id 2909357808 for device virtio-serial0.0”.And the spice connet display black screen.Restart the vm,it recovery. my channel is 16,Normally it will always output port less than 16,but when error it report a lage port. why it get a lage port "2909357808",Is there a data overflow? +Steps to reproduce: +1.The VM runs for a period of time + +2.report the error: "Unexpected port id 2909357808 for device virtio-serial0.0". + +3.restart to recovery. +Additional information: +qemu log: + +when vm is ok: +``` +virtio serial port 16 send control message event = 1, value = 1 +virtio serial port 0 send control message event = 1, value = 1 +virtio serial port '1' handle control message event = 3, value = 1 +virtio serial port '2' handle control message event = 3, value = 1 +virtio serial port 2 send control message event = 6, value = 1 +virtio serial port '3' handle control message event = 3, value = 1 +virtio serial port 3 send control message event = 6, value = 1 +virtio serial port '4' handle control message event = 3, value = 1 +virtio serial port 4 send control message event = 6, value = 1 +``` + + +when error: + +``` +2024-11-07T07:19:50.969383Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:19:50.969706Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +2024-11-07T07:20:00.944495Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:20:00.950544Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +2024-11-07T07:20:47.923564Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2909357808 for device virtio-serial0.0 +virtio serial port '2400366800' handle control message event = 49671, value = 65535 +2024-11-07T07:20:47.924422Z qemu-system-x86_64: virtio-serial-bus: Unexpected port id 2400366800 for device virtio-serial0.0 +virtio serial port '2909357808' handle control message event = 52747, value = 65535 +``` diff --git a/results/classifier/118/network/2758 b/results/classifier/118/network/2758 new file mode 100644 index 00000000..53a1e23e --- /dev/null +++ b/results/classifier/118/network/2758 @@ -0,0 +1,53 @@ +network: 0.972 +kernel: 0.828 +device: 0.808 +arm: 0.789 +graphic: 0.741 +ppc: 0.632 +vnc: 0.587 +socket: 0.557 +architecture: 0.515 +semantic: 0.419 +i386: 0.408 +x86: 0.364 +performance: 0.341 +boot: 0.341 +debug: 0.330 +hypervisor: 0.304 +KVM: 0.303 +PID: 0.298 +files: 0.294 +peripherals: 0.271 +assembly: 0.271 +TCG: 0.254 +risc-v: 0.220 +register: 0.220 +VMM: 0.169 +virtual: 0.156 +user-level: 0.112 +mistranslation: 0.075 +permissions: 0.044 + +Out-of-bounds access smc91c111_readb() +Description of problem: +An out-of-bounds bug was triggered by my fuzzer. + +It looks like the code doesn't have boundary checks for `data`'s access. + +The error is `hw/net/smc91c111.c:605:24: runtime error: index 2048 out of bounds for type 'uint8_t[2048]' (aka 'unsigned char[2048]')` + +It's likely that the line 457 also needs a check. +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 +writew 0x4e00000c 0x46084a4a +writel 0x4e00000c 0x5c022fcc +clock_step +writel 0x4e000004 0x2fffa1b1 +clock_step +readl 0x4e000008 +EOF +``` +Additional information: + diff --git a/results/classifier/118/network/2767 b/results/classifier/118/network/2767 new file mode 100644 index 00000000..b36ac5d4 --- /dev/null +++ b/results/classifier/118/network/2767 @@ -0,0 +1,67 @@ +network: 0.925 +socket: 0.894 +peripherals: 0.782 +device: 0.723 +PID: 0.701 +graphic: 0.642 +kernel: 0.630 +performance: 0.611 +vnc: 0.532 +TCG: 0.531 +ppc: 0.529 +architecture: 0.511 +x86: 0.438 +risc-v: 0.435 +i386: 0.407 +debug: 0.406 +files: 0.355 +arm: 0.349 +VMM: 0.340 +permissions: 0.333 +boot: 0.323 +user-level: 0.320 +assembly: 0.265 +register: 0.250 +semantic: 0.250 +mistranslation: 0.238 +hypervisor: 0.228 +KVM: 0.213 +virtual: 0.157 + +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/118/network/2780 b/results/classifier/118/network/2780 new file mode 100644 index 00000000..cfb70434 --- /dev/null +++ b/results/classifier/118/network/2780 @@ -0,0 +1,47 @@ +network: 0.981 +device: 0.910 +graphic: 0.906 +arm: 0.871 +performance: 0.770 +architecture: 0.634 +socket: 0.573 +vnc: 0.510 +peripherals: 0.485 +debug: 0.472 +register: 0.472 +kernel: 0.467 +files: 0.458 +ppc: 0.432 +semantic: 0.420 +PID: 0.389 +x86: 0.382 +i386: 0.367 +TCG: 0.304 +hypervisor: 0.283 +assembly: 0.280 +boot: 0.272 +mistranslation: 0.271 +virtual: 0.243 +user-level: 0.225 +risc-v: 0.195 +KVM: 0.190 +VMM: 0.178 +permissions: 0.164 + +Out-of-bounds access in smc91c111_receive() +Description of problem: +An out-of-bounds access happens at hw/net/smc91c111.c:705. + +`hw/net/smc91c111.c:705:5: runtime error: index -1 out of bounds for type 'int[4]'` +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 +writew 0x4e000005 0x227 +writel 0x4e00000b 0x25ab1f2 +writew 0x4e000000 0xaa6c +clock_step +EOF +``` +Additional information: + diff --git a/results/classifier/118/network/282 b/results/classifier/118/network/282 new file mode 100644 index 00000000..1829c51c --- /dev/null +++ b/results/classifier/118/network/282 @@ -0,0 +1,31 @@ +network: 0.829 +device: 0.699 +performance: 0.688 +socket: 0.567 +architecture: 0.481 +hypervisor: 0.421 +vnc: 0.359 +ppc: 0.301 +files: 0.291 +kernel: 0.290 +graphic: 0.290 +i386: 0.288 +register: 0.285 +PID: 0.258 +KVM: 0.255 +x86: 0.252 +boot: 0.250 +risc-v: 0.242 +mistranslation: 0.234 +peripherals: 0.232 +TCG: 0.217 +semantic: 0.212 +VMM: 0.206 +arm: 0.182 +permissions: 0.150 +user-level: 0.121 +debug: 0.118 +virtual: 0.111 +assembly: 0.048 + +[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation) diff --git a/results/classifier/118/network/2827 b/results/classifier/118/network/2827 new file mode 100644 index 00000000..66b4535f --- /dev/null +++ b/results/classifier/118/network/2827 @@ -0,0 +1,31 @@ +network: 0.915 +device: 0.801 +arm: 0.591 +user-level: 0.532 +performance: 0.490 +graphic: 0.265 +boot: 0.217 +semantic: 0.172 +ppc: 0.132 +permissions: 0.107 +i386: 0.107 +mistranslation: 0.105 +register: 0.094 +virtual: 0.082 +x86: 0.079 +socket: 0.076 +debug: 0.072 +risc-v: 0.064 +PID: 0.058 +files: 0.033 +vnc: 0.032 +hypervisor: 0.025 +architecture: 0.021 +TCG: 0.021 +peripherals: 0.015 +assembly: 0.011 +VMM: 0.005 +kernel: 0.004 +KVM: 0.001 + +Document how to use QEMU user mode networking with passt diff --git a/results/classifier/118/network/2829 b/results/classifier/118/network/2829 new file mode 100644 index 00000000..3e2789fa --- /dev/null +++ b/results/classifier/118/network/2829 @@ -0,0 +1,51 @@ +network: 0.939 +architecture: 0.890 +device: 0.833 +PID: 0.822 +socket: 0.798 +graphic: 0.760 +vnc: 0.759 +ppc: 0.753 +permissions: 0.746 +register: 0.728 +kernel: 0.707 +performance: 0.703 +files: 0.697 +semantic: 0.691 +peripherals: 0.594 +risc-v: 0.594 +mistranslation: 0.591 +debug: 0.565 +TCG: 0.475 +arm: 0.474 +boot: 0.454 +hypervisor: 0.437 +VMM: 0.404 +user-level: 0.337 +i386: 0.326 +assembly: 0.281 +x86: 0.265 +virtual: 0.195 +KVM: 0.181 + +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/118/network/2849 b/results/classifier/118/network/2849 new file mode 100644 index 00000000..dcf5a204 --- /dev/null +++ b/results/classifier/118/network/2849 @@ -0,0 +1,48 @@ +network: 0.899 +device: 0.706 +virtual: 0.688 +x86: 0.679 +graphic: 0.640 +vnc: 0.621 +semantic: 0.555 +KVM: 0.433 +VMM: 0.407 +mistranslation: 0.398 +user-level: 0.352 +performance: 0.340 +boot: 0.339 +PID: 0.331 +socket: 0.271 +risc-v: 0.268 +permissions: 0.265 +register: 0.265 +ppc: 0.259 +assembly: 0.237 +i386: 0.220 +debug: 0.219 +architecture: 0.157 +hypervisor: 0.154 +TCG: 0.138 +arm: 0.114 +peripherals: 0.100 +kernel: 0.092 +files: 0.019 + +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/118/network/2872 b/results/classifier/118/network/2872 new file mode 100644 index 00000000..c72015ea --- /dev/null +++ b/results/classifier/118/network/2872 @@ -0,0 +1,31 @@ +network: 0.945 +device: 0.884 +mistranslation: 0.763 +socket: 0.651 +peripherals: 0.601 +architecture: 0.586 +register: 0.523 +vnc: 0.490 +semantic: 0.487 +boot: 0.434 +performance: 0.426 +VMM: 0.408 +risc-v: 0.388 +TCG: 0.378 +graphic: 0.357 +files: 0.357 +debug: 0.352 +ppc: 0.342 +arm: 0.334 +kernel: 0.313 +i386: 0.309 +PID: 0.303 +KVM: 0.261 +hypervisor: 0.253 +x86: 0.233 +virtual: 0.198 +assembly: 0.149 +permissions: 0.117 +user-level: 0.037 + +hw/net: Parameter 'driver' expects a pluggable device type diff --git a/results/classifier/118/network/2884 b/results/classifier/118/network/2884 new file mode 100644 index 00000000..11a97080 --- /dev/null +++ b/results/classifier/118/network/2884 @@ -0,0 +1,65 @@ +network: 0.982 +device: 0.908 +graphic: 0.843 +KVM: 0.809 +socket: 0.772 +ppc: 0.749 +peripherals: 0.731 +kernel: 0.683 +PID: 0.657 +user-level: 0.641 +virtual: 0.639 +vnc: 0.630 +architecture: 0.629 +files: 0.617 +permissions: 0.594 +hypervisor: 0.580 +register: 0.578 +performance: 0.559 +i386: 0.543 +semantic: 0.528 +x86: 0.527 +risc-v: 0.519 +debug: 0.491 +arm: 0.484 +mistranslation: 0.451 +boot: 0.408 +VMM: 0.406 +assembly: 0.384 +TCG: 0.258 + +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/118/network/2951 b/results/classifier/118/network/2951 new file mode 100644 index 00000000..f75c6993 --- /dev/null +++ b/results/classifier/118/network/2951 @@ -0,0 +1,51 @@ +network: 0.935 +graphic: 0.840 +device: 0.838 +vnc: 0.799 +peripherals: 0.796 +kernel: 0.768 +performance: 0.755 +socket: 0.693 +files: 0.689 +ppc: 0.666 +architecture: 0.629 +register: 0.614 +hypervisor: 0.583 +boot: 0.561 +risc-v: 0.536 +semantic: 0.529 +permissions: 0.501 +PID: 0.493 +arm: 0.454 +i386: 0.414 +debug: 0.413 +x86: 0.399 +TCG: 0.395 +VMM: 0.379 +user-level: 0.296 +KVM: 0.277 +assembly: 0.249 +mistranslation: 0.142 +virtual: 0.049 + +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/118/network/299 b/results/classifier/118/network/299 new file mode 100644 index 00000000..f6fe9506 --- /dev/null +++ b/results/classifier/118/network/299 @@ -0,0 +1,31 @@ +network: 0.957 +device: 0.790 +architecture: 0.757 +graphic: 0.599 +ppc: 0.436 +semantic: 0.409 +performance: 0.374 +debug: 0.367 +peripherals: 0.356 +hypervisor: 0.306 +register: 0.272 +arm: 0.254 +mistranslation: 0.193 +boot: 0.185 +virtual: 0.174 +PID: 0.160 +risc-v: 0.155 +vnc: 0.141 +user-level: 0.132 +kernel: 0.107 +permissions: 0.105 +files: 0.062 +TCG: 0.062 +VMM: 0.047 +assembly: 0.036 +socket: 0.026 +i386: 0.010 +x86: 0.008 +KVM: 0.007 + +Tulip NIC not working on OpenBSD/hppa (and more) diff --git a/results/classifier/118/network/308 b/results/classifier/118/network/308 new file mode 100644 index 00000000..c1f4bc86 --- /dev/null +++ b/results/classifier/118/network/308 @@ -0,0 +1,31 @@ +network: 0.947 +architecture: 0.853 +virtual: 0.853 +device: 0.785 +performance: 0.738 +hypervisor: 0.683 +VMM: 0.643 +arm: 0.418 +graphic: 0.394 +mistranslation: 0.377 +debug: 0.331 +boot: 0.300 +risc-v: 0.259 +i386: 0.255 +PID: 0.213 +permissions: 0.185 +x86: 0.170 +semantic: 0.162 +ppc: 0.141 +peripherals: 0.114 +TCG: 0.077 +files: 0.056 +user-level: 0.046 +register: 0.034 +assembly: 0.033 +socket: 0.027 +vnc: 0.018 +kernel: 0.009 +KVM: 0.005 + +QEMU: net: vmxnet: integer overflow may crash guest diff --git a/results/classifier/118/network/309 b/results/classifier/118/network/309 new file mode 100644 index 00000000..79dc8ed9 --- /dev/null +++ b/results/classifier/118/network/309 @@ -0,0 +1,31 @@ +network: 0.919 +device: 0.714 +socket: 0.606 +VMM: 0.585 +performance: 0.506 +vnc: 0.466 +virtual: 0.464 +files: 0.464 +hypervisor: 0.455 +peripherals: 0.427 +architecture: 0.419 +graphic: 0.406 +register: 0.352 +semantic: 0.337 +PID: 0.328 +debug: 0.306 +arm: 0.299 +boot: 0.260 +i386: 0.258 +x86: 0.221 +permissions: 0.218 +TCG: 0.174 +ppc: 0.171 +KVM: 0.146 +mistranslation: 0.136 +assembly: 0.101 +risc-v: 0.101 +kernel: 0.099 +user-level: 0.071 + +assert issue locates in hw/net/vmxnet3.c:1793:vmxnet3_io_bar1_write: code should not be reach diff --git a/results/classifier/118/network/335 b/results/classifier/118/network/335 new file mode 100644 index 00000000..536ca308 --- /dev/null +++ b/results/classifier/118/network/335 @@ -0,0 +1,31 @@ +network: 0.975 +device: 0.858 +graphic: 0.663 +performance: 0.558 +risc-v: 0.466 +debug: 0.441 +PID: 0.336 +arm: 0.278 +VMM: 0.250 +mistranslation: 0.239 +vnc: 0.234 +TCG: 0.224 +register: 0.164 +ppc: 0.164 +peripherals: 0.137 +socket: 0.134 +boot: 0.124 +user-level: 0.114 +semantic: 0.090 +KVM: 0.085 +virtual: 0.065 +files: 0.055 +hypervisor: 0.029 +permissions: 0.023 +i386: 0.015 +assembly: 0.014 +kernel: 0.010 +architecture: 0.009 +x86: 0.002 + +Broken tap networking on macOS host diff --git a/results/classifier/118/network/336 b/results/classifier/118/network/336 new file mode 100644 index 00000000..6b3942bf --- /dev/null +++ b/results/classifier/118/network/336 @@ -0,0 +1,31 @@ +network: 0.859 +device: 0.803 +architecture: 0.714 +arm: 0.493 +mistranslation: 0.354 +graphic: 0.330 +i386: 0.220 +ppc: 0.197 +performance: 0.157 +x86: 0.155 +semantic: 0.155 +risc-v: 0.131 +boot: 0.118 +permissions: 0.066 +TCG: 0.053 +vnc: 0.050 +assembly: 0.044 +PID: 0.039 +VMM: 0.026 +register: 0.016 +virtual: 0.011 +debug: 0.009 +KVM: 0.007 +hypervisor: 0.004 +peripherals: 0.003 +kernel: 0.003 +user-level: 0.003 +socket: 0.003 +files: 0.002 + +Built-in DHCP server: SiAddr diff --git a/results/classifier/118/network/360 b/results/classifier/118/network/360 new file mode 100644 index 00000000..e10383f2 --- /dev/null +++ b/results/classifier/118/network/360 @@ -0,0 +1,31 @@ +network: 0.804 +device: 0.793 +permissions: 0.785 +mistranslation: 0.761 +socket: 0.695 +performance: 0.687 +arm: 0.614 +kernel: 0.531 +debug: 0.506 +architecture: 0.477 +vnc: 0.414 +peripherals: 0.408 +files: 0.397 +risc-v: 0.329 +ppc: 0.308 +hypervisor: 0.295 +graphic: 0.270 +i386: 0.255 +semantic: 0.252 +boot: 0.249 +PID: 0.229 +x86: 0.170 +assembly: 0.137 +register: 0.123 +TCG: 0.107 +VMM: 0.104 +virtual: 0.102 +user-level: 0.089 +KVM: 0.010 + +load_helper() do_unaligned_access path doesn't return correct result with MMIO diff --git a/results/classifier/118/network/377 b/results/classifier/118/network/377 new file mode 100644 index 00000000..49c36003 --- /dev/null +++ b/results/classifier/118/network/377 @@ -0,0 +1,31 @@ +network: 0.947 +mistranslation: 0.753 +device: 0.563 +architecture: 0.502 +socket: 0.497 +graphic: 0.469 +ppc: 0.353 +PID: 0.353 +vnc: 0.340 +TCG: 0.336 +performance: 0.328 +semantic: 0.324 +risc-v: 0.314 +register: 0.310 +VMM: 0.305 +boot: 0.284 +i386: 0.273 +KVM: 0.266 +x86: 0.232 +permissions: 0.207 +arm: 0.207 +debug: 0.203 +virtual: 0.190 +files: 0.179 +peripherals: 0.118 +assembly: 0.094 +hypervisor: 0.025 +kernel: 0.021 +user-level: 0.007 + +Indentation should be done with spaces, not with TABs, in the net subsystem diff --git a/results/classifier/118/network/428 b/results/classifier/118/network/428 new file mode 100644 index 00000000..0c2a0223 --- /dev/null +++ b/results/classifier/118/network/428 @@ -0,0 +1,31 @@ +network: 0.962 +performance: 0.933 +device: 0.852 +peripherals: 0.722 +architecture: 0.566 +graphic: 0.468 +semantic: 0.301 +mistranslation: 0.227 +boot: 0.215 +vnc: 0.212 +user-level: 0.183 +PID: 0.160 +risc-v: 0.136 +VMM: 0.121 +socket: 0.108 +ppc: 0.092 +permissions: 0.084 +TCG: 0.076 +debug: 0.066 +register: 0.059 +arm: 0.042 +virtual: 0.019 +files: 0.009 +hypervisor: 0.007 +assembly: 0.005 +kernel: 0.002 +KVM: 0.001 +i386: 0.001 +x86: 0.000 + +Windows: Very low network throughput with tap-netdev & virtio-serial diff --git a/results/classifier/118/network/460 b/results/classifier/118/network/460 new file mode 100644 index 00000000..f573254e --- /dev/null +++ b/results/classifier/118/network/460 @@ -0,0 +1,31 @@ +network: 0.952 +device: 0.940 +virtual: 0.867 +performance: 0.729 +arm: 0.712 +architecture: 0.624 +VMM: 0.581 +debug: 0.552 +hypervisor: 0.530 +peripherals: 0.455 +graphic: 0.389 +socket: 0.372 +register: 0.310 +boot: 0.260 +PID: 0.214 +mistranslation: 0.172 +semantic: 0.170 +kernel: 0.160 +assembly: 0.160 +files: 0.071 +user-level: 0.062 +ppc: 0.057 +risc-v: 0.049 +permissions: 0.046 +vnc: 0.044 +TCG: 0.031 +i386: 0.021 +KVM: 0.019 +x86: 0.005 + +vmxnet3: Assertion failure in eth_setup_ip4_fragmentation diff --git a/results/classifier/118/network/485250 b/results/classifier/118/network/485250 new file mode 100644 index 00000000..5c757578 --- /dev/null +++ b/results/classifier/118/network/485250 @@ -0,0 +1,63 @@ +network: 0.966 +mistranslation: 0.966 +peripherals: 0.964 +architecture: 0.952 +semantic: 0.944 +x86: 0.938 +device: 0.935 +performance: 0.929 +user-level: 0.914 +boot: 0.907 +graphic: 0.904 +hypervisor: 0.889 +files: 0.870 +vnc: 0.865 +permissions: 0.864 +socket: 0.825 +debug: 0.799 +kernel: 0.787 +PID: 0.779 +ppc: 0.732 +register: 0.703 +virtual: 0.667 +KVM: 0.655 +assembly: 0.634 +VMM: 0.559 +TCG: 0.545 +risc-v: 0.529 +arm: 0.516 +i386: 0.370 + +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 + +Maybe you can try the e1000 drivers from Intel's site. You could also try using the stadard Qemu mac prefix of 52:54 (the first bit of the mac has a special meaning). + +I can reproduce this in qemu-kvm 0.12.50. + +Most likely a problem with the e1000 driver in QEMU. Funny thing is the guest seems to be able to obtain it's IP address via DHCP, then stops communicating. + + +Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/517 b/results/classifier/118/network/517 new file mode 100644 index 00000000..28f2621b --- /dev/null +++ b/results/classifier/118/network/517 @@ -0,0 +1,31 @@ +network: 0.887 +device: 0.844 +performance: 0.663 +architecture: 0.546 +socket: 0.468 +arm: 0.453 +debug: 0.360 +mistranslation: 0.349 +graphic: 0.337 +VMM: 0.310 +virtual: 0.306 +semantic: 0.304 +PID: 0.279 +ppc: 0.242 +hypervisor: 0.230 +permissions: 0.221 +peripherals: 0.184 +TCG: 0.129 +boot: 0.123 +i386: 0.102 +user-level: 0.093 +x86: 0.083 +register: 0.082 +files: 0.068 +assembly: 0.065 +risc-v: 0.059 +vnc: 0.056 +KVM: 0.012 +kernel: 0.011 + +Abort in vmxnet3_setup_tx_offloads diff --git a/results/classifier/118/network/533 b/results/classifier/118/network/533 new file mode 100644 index 00000000..ff3441ef --- /dev/null +++ b/results/classifier/118/network/533 @@ -0,0 +1,31 @@ +network: 0.830 +debug: 0.792 +performance: 0.661 +hypervisor: 0.604 +device: 0.604 +mistranslation: 0.450 +graphic: 0.384 +architecture: 0.299 +VMM: 0.296 +semantic: 0.283 +risc-v: 0.277 +virtual: 0.255 +boot: 0.215 +arm: 0.211 +TCG: 0.172 +register: 0.171 +i386: 0.160 +vnc: 0.157 +x86: 0.147 +ppc: 0.106 +assembly: 0.059 +peripherals: 0.047 +PID: 0.044 +user-level: 0.038 +socket: 0.037 +kernel: 0.025 +permissions: 0.024 +files: 0.022 +KVM: 0.016 + +Assertion failure in vmxnet3_get_next_body_rx_descr: d->btype == VMXNET3_RXD_BTYPE_BODY diff --git a/results/classifier/118/network/539 b/results/classifier/118/network/539 new file mode 100644 index 00000000..d0241866 --- /dev/null +++ b/results/classifier/118/network/539 @@ -0,0 +1,31 @@ +network: 0.872 +device: 0.836 +performance: 0.703 +arm: 0.397 +architecture: 0.328 +graphic: 0.317 +peripherals: 0.309 +semantic: 0.293 +hypervisor: 0.292 +mistranslation: 0.250 +virtual: 0.200 +VMM: 0.179 +ppc: 0.119 +socket: 0.105 +user-level: 0.064 +i386: 0.063 +debug: 0.062 +boot: 0.052 +PID: 0.049 +x86: 0.038 +TCG: 0.036 +vnc: 0.035 +register: 0.018 +risc-v: 0.017 +permissions: 0.016 +files: 0.012 +assembly: 0.008 +kernel: 0.007 +KVM: 0.006 + +Abort in vmxnet3_validate_interrupt_idx diff --git a/results/classifier/118/network/544 b/results/classifier/118/network/544 new file mode 100644 index 00000000..64b73d2b --- /dev/null +++ b/results/classifier/118/network/544 @@ -0,0 +1,31 @@ +network: 0.820 +device: 0.796 +performance: 0.654 +peripherals: 0.613 +semantic: 0.610 +mistranslation: 0.588 +debug: 0.483 +graphic: 0.401 +assembly: 0.342 +files: 0.304 +architecture: 0.280 +arm: 0.251 +TCG: 0.164 +VMM: 0.156 +vnc: 0.156 +boot: 0.149 +risc-v: 0.142 +hypervisor: 0.118 +ppc: 0.116 +permissions: 0.106 +socket: 0.105 +user-level: 0.083 +virtual: 0.074 +KVM: 0.043 +PID: 0.031 +i386: 0.031 +register: 0.030 +x86: 0.019 +kernel: 0.017 + +Assert xfer->packet.status != USB_RET_NAK in xhci diff --git a/results/classifier/118/network/557 b/results/classifier/118/network/557 new file mode 100644 index 00000000..3fd23f40 --- /dev/null +++ b/results/classifier/118/network/557 @@ -0,0 +1,31 @@ +network: 0.800 +performance: 0.694 +device: 0.661 +graphic: 0.546 +architecture: 0.204 +debug: 0.128 +boot: 0.099 +arm: 0.055 +register: 0.050 +semantic: 0.047 +peripherals: 0.047 +mistranslation: 0.046 +virtual: 0.042 +hypervisor: 0.041 +assembly: 0.040 +PID: 0.036 +TCG: 0.036 +ppc: 0.035 +socket: 0.020 +VMM: 0.016 +permissions: 0.016 +vnc: 0.011 +i386: 0.010 +risc-v: 0.008 +user-level: 0.008 +x86: 0.007 +files: 0.004 +kernel: 0.003 +KVM: 0.002 + +Stack-overflow through pcnet_tmd_load diff --git a/results/classifier/118/network/580 b/results/classifier/118/network/580 new file mode 100644 index 00000000..8038e3ec --- /dev/null +++ b/results/classifier/118/network/580 @@ -0,0 +1,47 @@ +network: 0.995 +graphic: 0.991 +risc-v: 0.988 +performance: 0.945 +device: 0.926 +PID: 0.898 +socket: 0.893 +debug: 0.883 +architecture: 0.867 +files: 0.853 +mistranslation: 0.850 +register: 0.838 +semantic: 0.814 +user-level: 0.788 +vnc: 0.765 +permissions: 0.764 +TCG: 0.733 +VMM: 0.714 +ppc: 0.709 +hypervisor: 0.705 +peripherals: 0.696 +boot: 0.694 +arm: 0.682 +virtual: 0.621 +kernel: 0.609 +i386: 0.598 +assembly: 0.596 +x86: 0.560 +KVM: 0.509 + +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/118/network/590552 b/results/classifier/118/network/590552 new file mode 100644 index 00000000..5987e9be --- /dev/null +++ b/results/classifier/118/network/590552 @@ -0,0 +1,53 @@ +network: 0.851 +performance: 0.772 +user-level: 0.770 +mistranslation: 0.719 +graphic: 0.716 +semantic: 0.701 +ppc: 0.694 +device: 0.685 +peripherals: 0.650 +socket: 0.502 +architecture: 0.489 +i386: 0.417 +vnc: 0.403 +virtual: 0.398 +PID: 0.397 +x86: 0.381 +debug: 0.373 +register: 0.359 +files: 0.329 +hypervisor: 0.305 +permissions: 0.301 +boot: 0.292 +risc-v: 0.281 +kernel: 0.259 +arm: 0.253 +VMM: 0.224 +TCG: 0.214 +assembly: 0.192 +KVM: 0.129 + +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. + +Seems like you were using the QEMU from your Linux distribution (Debian). If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! + +Thank you for your interest but after more than 6 years I can't even remember what this bug was about. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/593 b/results/classifier/118/network/593 new file mode 100644 index 00000000..8e4ed292 --- /dev/null +++ b/results/classifier/118/network/593 @@ -0,0 +1,37 @@ +network: 0.973 +device: 0.920 +graphic: 0.760 +vnc: 0.551 +performance: 0.498 +register: 0.487 +socket: 0.477 +risc-v: 0.471 +mistranslation: 0.464 +files: 0.452 +semantic: 0.450 +peripherals: 0.429 +boot: 0.405 +ppc: 0.391 +PID: 0.389 +TCG: 0.377 +arm: 0.358 +VMM: 0.354 +debug: 0.302 +permissions: 0.292 +kernel: 0.262 +architecture: 0.260 +i386: 0.185 +KVM: 0.175 +hypervisor: 0.134 +virtual: 0.108 +user-level: 0.090 +assembly: 0.060 +x86: 0.050 + +USB ECM network device does not work under XHCI +Description of problem: +No data is ever received by the USB ECM network device when it is attached to an XHCI controller. (USB 1.0 controllers work OK.) +Additional information: +There are some patches it appears were submitted to the GitHub mirror that resolve the problem (I tested them applied to git master, and confirmed they work): https://github.com/qemu/qemu/pull/100 + +I guess they never were submitted to the mailing list, or somehow got missed? diff --git a/results/classifier/118/network/605 b/results/classifier/118/network/605 new file mode 100644 index 00000000..51fa9ed6 --- /dev/null +++ b/results/classifier/118/network/605 @@ -0,0 +1,45 @@ +network: 0.992 +graphic: 0.986 +boot: 0.973 +device: 0.949 +debug: 0.895 +vnc: 0.889 +performance: 0.873 +virtual: 0.863 +files: 0.816 +PID: 0.781 +ppc: 0.781 +arm: 0.723 +risc-v: 0.695 +semantic: 0.638 +register: 0.624 +socket: 0.616 +architecture: 0.608 +VMM: 0.535 +permissions: 0.474 +mistranslation: 0.442 +peripherals: 0.410 +TCG: 0.327 +user-level: 0.236 +KVM: 0.235 +kernel: 0.109 +hypervisor: 0.082 +assembly: 0.057 +i386: 0.025 +x86: 0.003 + +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/118/network/62179944 b/results/classifier/118/network/62179944 new file mode 100644 index 00000000..09bc45df --- /dev/null +++ b/results/classifier/118/network/62179944 @@ -0,0 +1,56 @@ +network: 0.966 +graphic: 0.907 +device: 0.818 +virtual: 0.784 +performance: 0.636 +socket: 0.608 +register: 0.601 +boot: 0.567 +files: 0.565 +ppc: 0.562 +user-level: 0.542 +mistranslation: 0.533 +PID: 0.504 +vnc: 0.498 +hypervisor: 0.492 +peripherals: 0.470 +architecture: 0.459 +semantic: 0.454 +permissions: 0.403 +debug: 0.400 +arm: 0.379 +risc-v: 0.345 +assembly: 0.275 +VMM: 0.258 +TCG: 0.217 +i386: 0.187 +x86: 0.164 +KVM: 0.153 +kernel: 0.063 + +[Qemu-devel] [BUG] network : windows os lost ip address of the network card in some cases + +we found this problem for a long time ãFor example, if we has three network +card in virtual xml file ï¼such as "network connection 1" / "network connection +2"/"network connection 3" ã + +Echo network card has own ip address ï¼such as 192.168.1.1 / 2.1 /3.1 , when +delete the first card ï¼reboot the windows virtual os, then this problem +happened ! + + + + +we found that the sencond network card will replace the first one , then the +ip address of "network connection 2 " become 192.168.1.1 ã + + +Our third party users began to complain about this bug ãAll the business of the +second ip lost !!! + +I mean both of windows and linux has this bug , we solve this bug in linux +throught bonding netcrad pci and mac address ã + +There is no good solution on windows os . thera are ? we implemented a plan to +resumption of IP by QGA. Is there a better way ? + diff --git a/results/classifier/118/network/641118 b/results/classifier/118/network/641118 new file mode 100644 index 00000000..4e7e999c --- /dev/null +++ b/results/classifier/118/network/641118 @@ -0,0 +1,47 @@ +i386: 0.991 +network: 0.989 +device: 0.805 +boot: 0.802 +architecture: 0.764 +mistranslation: 0.763 +vnc: 0.734 +graphic: 0.724 +socket: 0.679 +semantic: 0.670 +peripherals: 0.619 +performance: 0.600 +PID: 0.548 +permissions: 0.533 +register: 0.509 +x86: 0.475 +arm: 0.460 +risc-v: 0.425 +ppc: 0.410 +debug: 0.402 +user-level: 0.393 +files: 0.386 +virtual: 0.364 +VMM: 0.353 +TCG: 0.331 +KVM: 0.324 +kernel: 0.323 +hypervisor: 0.287 +assembly: 0.227 + +NetBSD guest only supports network without ACPI + +Git commit: abdfd9500e07fab7d6ffd4385fa30a065c329a39 +Host: Linux 64bit Debian +Guest: NetBSD5.0.2/i386 + +Networking works only when ACPI is disabled in the guest. Without it the network card (wm0) is not detected. + +Boot: qemu -hda netbsd5.0.2-i386 -boot c -enable-kvm +Configure: --enable-linux-aio --enable-io-thread --enable-kvm + +Can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays? + +I've just tried, and it is OK using NetBSD7 as the guest. I no longer have NetBSD5 so I am unable to check if the problem still exists on that. + +OK, thanks for checking! ... so let's close this bug. + diff --git a/results/classifier/118/network/676934 b/results/classifier/118/network/676934 new file mode 100644 index 00000000..b32c0ab6 --- /dev/null +++ b/results/classifier/118/network/676934 @@ -0,0 +1,48 @@ +network: 0.812 +socket: 0.755 +device: 0.684 +mistranslation: 0.673 +virtual: 0.535 +graphic: 0.502 +semantic: 0.455 +ppc: 0.356 +peripherals: 0.353 +performance: 0.319 +arm: 0.313 +PID: 0.308 +boot: 0.300 +i386: 0.293 +permissions: 0.293 +kernel: 0.281 +risc-v: 0.258 +vnc: 0.242 +x86: 0.209 +TCG: 0.205 +debug: 0.198 +register: 0.166 +architecture: 0.138 +hypervisor: 0.108 +VMM: 0.094 +files: 0.085 +KVM: 0.056 +assembly: 0.044 +user-level: 0.041 + +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. + +Aren't these at different levels of the stack? Network devices deal in packets not connections. It sounds like you want to use something like vsock which provides a virtual socket device to the guest. + +This is just about connecting the NIC backends for 2 QEMUs together using a UNIX socket, instead of the current TCP/UDP socket. It should be fairly trivial to support i would expect. Though ideally we'd port the netdev socket backend to use QIOChannel too + + +This is an automated cleanup. This bug report got closed because it +is a duplicate. + + diff --git a/results/classifier/118/network/741 b/results/classifier/118/network/741 new file mode 100644 index 00000000..2bcf9814 --- /dev/null +++ b/results/classifier/118/network/741 @@ -0,0 +1,31 @@ +network: 0.925 +architecture: 0.525 +semantic: 0.403 +performance: 0.373 +mistranslation: 0.277 +permissions: 0.221 +user-level: 0.205 +graphic: 0.145 +register: 0.119 +socket: 0.103 +TCG: 0.091 +virtual: 0.089 +i386: 0.083 +ppc: 0.083 +x86: 0.074 +vnc: 0.067 +VMM: 0.058 +device: 0.057 +assembly: 0.050 +KVM: 0.048 +files: 0.046 +hypervisor: 0.042 +PID: 0.034 +peripherals: 0.030 +debug: 0.024 +arm: 0.018 +risc-v: 0.017 +kernel: 0.014 +boot: 0.012 + +Document "net/net.h" API diff --git a/results/classifier/118/network/762 b/results/classifier/118/network/762 new file mode 100644 index 00000000..ff37739f --- /dev/null +++ b/results/classifier/118/network/762 @@ -0,0 +1,31 @@ +network: 0.855 +performance: 0.799 +device: 0.780 +debug: 0.444 +graphic: 0.426 +arm: 0.350 +architecture: 0.341 +vnc: 0.274 +semantic: 0.173 +TCG: 0.169 +ppc: 0.161 +i386: 0.161 +x86: 0.155 +kernel: 0.148 +boot: 0.147 +hypervisor: 0.140 +PID: 0.084 +virtual: 0.075 +VMM: 0.071 +KVM: 0.067 +assembly: 0.057 +mistranslation: 0.056 +peripherals: 0.056 +risc-v: 0.054 +user-level: 0.026 +register: 0.024 +socket: 0.022 +permissions: 0.007 +files: 0.004 + +Assertion failure in iov_from_buf_full `offset == 0' failed through virtio-net diff --git a/results/classifier/118/network/774 b/results/classifier/118/network/774 new file mode 100644 index 00000000..cb5a74ad --- /dev/null +++ b/results/classifier/118/network/774 @@ -0,0 +1,45 @@ +network: 0.976 +device: 0.971 +peripherals: 0.968 +graphic: 0.958 +ppc: 0.937 +boot: 0.932 +vnc: 0.807 +semantic: 0.757 +performance: 0.741 +architecture: 0.714 +socket: 0.705 +mistranslation: 0.675 +PID: 0.578 +register: 0.559 +i386: 0.480 +x86: 0.477 +files: 0.471 +debug: 0.458 +virtual: 0.405 +permissions: 0.355 +assembly: 0.328 +user-level: 0.323 +risc-v: 0.307 +kernel: 0.294 +VMM: 0.292 +arm: 0.290 +hypervisor: 0.232 +TCG: 0.154 +KVM: 0.050 + +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/118/network/806656 b/results/classifier/118/network/806656 new file mode 100644 index 00000000..925bfd97 --- /dev/null +++ b/results/classifier/118/network/806656 @@ -0,0 +1,52 @@ +network: 0.889 +vnc: 0.865 +graphic: 0.853 +mistranslation: 0.816 +semantic: 0.799 +socket: 0.760 +device: 0.751 +files: 0.733 +performance: 0.715 +ppc: 0.654 +register: 0.654 +user-level: 0.651 +PID: 0.638 +architecture: 0.629 +kernel: 0.627 +virtual: 0.578 +permissions: 0.568 +x86: 0.557 +risc-v: 0.526 +KVM: 0.515 +i386: 0.513 +arm: 0.493 +boot: 0.474 +peripherals: 0.452 +debug: 0.452 +assembly: 0.444 +VMM: 0.436 +TCG: 0.422 +hypervisor: 0.366 + +Tight PNG VNC encoding is sent even when --disable-vnc-png is set + +This bug exists in 0.14.1 and also in 9312805d33e8b (Jun 17, 2011) in the master git repo. + +The "Tight PNG" encoding is a derivative of the "Tight" encoding that replaces zlib encoded rects with PNG encoded data instead. However, when the "Tight PNG" encoding is disabled (--disable-vnc-png), the server will send frame buffer updates that are marked as "Tight PNG" but in fact contain zlib encoded regions (i.e. it's really "tight" protocol). + +The "Tight PNG" encoding should only be used when --enable-vnc-png is set. + + + +The patch looks right, maybe you should send it directly to the qemu mailing list. + +Using noVNC and kvm in SLES 11 we have hit this bug as well. + +Joel, would you like to send your patch to the qemu mailing list? + +I sent the patch on May 16 (http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02373.html). I haven't seen any response. + +Patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=fe3e7f2dc05225cdd2ba +... so I'm closing this ticket now. + diff --git a/results/classifier/118/network/807 b/results/classifier/118/network/807 new file mode 100644 index 00000000..95e5398d --- /dev/null +++ b/results/classifier/118/network/807 @@ -0,0 +1,48 @@ +network: 0.941 +graphic: 0.934 +performance: 0.866 +device: 0.823 +socket: 0.805 +semantic: 0.796 +architecture: 0.738 +virtual: 0.730 +x86: 0.728 +vnc: 0.723 +ppc: 0.613 +permissions: 0.546 +assembly: 0.525 +peripherals: 0.519 +i386: 0.491 +register: 0.481 +mistranslation: 0.448 +arm: 0.414 +VMM: 0.393 +debug: 0.389 +hypervisor: 0.378 +PID: 0.332 +KVM: 0.322 +user-level: 0.297 +risc-v: 0.292 +TCG: 0.279 +kernel: 0.253 +boot: 0.251 +files: 0.153 + +TigerVNC client to built-in VNC server causes VM to crash/freeze +Description of problem: +Connecting to the built-in VNC server via TigerVNC upon disconnect the whole VM process freezes/crashes. The process continues to exist but does not respond to any network connection and the monitor socket is dead too. Killing it with TERM doesn't work. + +Using tigervnc-viewer 1.10.1+dfsg-3 (Ubuntu 20.04) with default options like `vncviwer localhost:0` +Steps to reproduce: +* `qemu-system-x86_64 -vnc 127.0.0.1:0` + * Connect to built-in VNC server via TigerVNC + * Keep the VNC connection open and wait some period of time (usually 5-10 minutes is enough though sometimes hours) then disconnect/reconnect VNC. If the reconnect succeeds then wait again for a period of time then disconnect and try again until failure. Often just connecting and disconnecting to the VNC once is enough to make the VM eventually crash/freeze even if running only in the background but this is less reproducible. + * Observe VM is no longer responsive to anything + +If TigerVNC is never connected/disconnected from the VM then this doesn't happen. +Additional information: +Note due to the nature of this issue it might be hard to reproduce for unknown reasons. The VM always eventually freezes though. The qemu process has no output when it freezes. + +As far as I can tell connecting to the built-in VNC server via `gvncviwer` seems to be OK and doesn't cause an issue (?). I'm not sure about other VNC clients (eg. TurboVNC). + +I am connecting to the VNC server from a completely different machine than the host via SSH port redirection (the host is headless). Not sure if that matters. diff --git a/results/classifier/118/network/829455 b/results/classifier/118/network/829455 new file mode 100644 index 00000000..aa852f23 --- /dev/null +++ b/results/classifier/118/network/829455 @@ -0,0 +1,73 @@ +network: 0.843 +mistranslation: 0.799 +user-level: 0.767 +socket: 0.696 +KVM: 0.677 +ppc: 0.605 +device: 0.566 +PID: 0.489 +architecture: 0.471 +virtual: 0.441 +vnc: 0.432 +semantic: 0.422 +register: 0.411 +debug: 0.389 +x86: 0.384 +hypervisor: 0.384 +arm: 0.382 +performance: 0.361 +permissions: 0.330 +risc-v: 0.318 +VMM: 0.307 +boot: 0.292 +i386: 0.289 +TCG: 0.289 +kernel: 0.276 +assembly: 0.265 +peripherals: 0.245 +graphic: 0.242 +files: 0.232 + +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) + +Did you guys merge back the fix in: + +http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01519.html +? + +On Fri, Jun 14, 2013 at 10:59:10AM -0000, Axel Hübl wrote: +> Did you guys merge back the fix in: +> +> http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01519.html +> ? + +This patch has not been applied. CCing Jan Kiszka, slirp maintainer. + +Stefan + + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=b5a87d26e848945eb8 + +It seems that's problem persist with this patch ( qemu 2.7rc2) +Regards + +Sorry for this spam, +it's just a routing problem . +Regards + diff --git a/results/classifier/118/network/838974 b/results/classifier/118/network/838974 new file mode 100644 index 00000000..93e2ad6b --- /dev/null +++ b/results/classifier/118/network/838974 @@ -0,0 +1,44 @@ +network: 0.905 +semantic: 0.872 +device: 0.802 +socket: 0.709 +risc-v: 0.680 +kernel: 0.672 +hypervisor: 0.669 +virtual: 0.664 +files: 0.660 +architecture: 0.648 +vnc: 0.646 +mistranslation: 0.645 +graphic: 0.645 +i386: 0.643 +register: 0.638 +ppc: 0.595 +KVM: 0.586 +peripherals: 0.576 +PID: 0.569 +arm: 0.557 +VMM: 0.554 +performance: 0.551 +x86: 0.530 +boot: 0.526 +TCG: 0.517 +debug: 0.493 +permissions: 0.470 +user-level: 0.384 +assembly: 0.359 + +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. + +Thanks for reporting this bug. + +That certainly could be confusing. However, practically speaking, since qemu was compiled without that support, it becomes more difficult for qemu to tell the difference between a unsupported but otherwise-valid type, and an invalid type. + +Perhaps upstream would accept a (trivial) patch changing the message to always say "expects a valid network client type". Even more helpful would be for that message to be followed by a list of valid, supported network types. + +I think this has been fixed by this commit here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d139e9a6cf01b8c31f59 +... so closing this ticket now. + diff --git a/results/classifier/118/network/898 b/results/classifier/118/network/898 new file mode 100644 index 00000000..16417a77 --- /dev/null +++ b/results/classifier/118/network/898 @@ -0,0 +1,31 @@ +network: 0.890 +architecture: 0.846 +performance: 0.836 +TCG: 0.836 +device: 0.834 +peripherals: 0.616 +arm: 0.481 +hypervisor: 0.469 +semantic: 0.392 +graphic: 0.386 +VMM: 0.338 +boot: 0.330 +virtual: 0.300 +debug: 0.268 +PID: 0.220 +permissions: 0.209 +kernel: 0.199 +vnc: 0.179 +mistranslation: 0.172 +files: 0.169 +assembly: 0.165 +socket: 0.155 +register: 0.136 +ppc: 0.133 +user-level: 0.133 +KVM: 0.094 +risc-v: 0.052 +x86: 0.018 +i386: 0.010 + +check-tcg sha512-mvx test is failing on s390x hosts diff --git a/results/classifier/118/network/903365 b/results/classifier/118/network/903365 new file mode 100644 index 00000000..85bac876 --- /dev/null +++ b/results/classifier/118/network/903365 @@ -0,0 +1,40 @@ +network: 0.813 +user-level: 0.609 +graphic: 0.585 +mistranslation: 0.531 +device: 0.509 +semantic: 0.500 +performance: 0.482 +socket: 0.475 +peripherals: 0.416 +architecture: 0.377 +register: 0.354 +i386: 0.344 +vnc: 0.337 +permissions: 0.336 +risc-v: 0.315 +files: 0.269 +VMM: 0.260 +ppc: 0.257 +debug: 0.252 +TCG: 0.237 +x86: 0.236 +kernel: 0.220 +hypervisor: 0.215 +boot: 0.208 +PID: 0.186 +assembly: 0.186 +arm: 0.176 +virtual: 0.172 +KVM: 0.157 + +[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. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/network/912 b/results/classifier/118/network/912 new file mode 100644 index 00000000..868b1c2a --- /dev/null +++ b/results/classifier/118/network/912 @@ -0,0 +1,31 @@ +network: 0.940 +device: 0.909 +architecture: 0.840 +performance: 0.644 +permissions: 0.642 +hypervisor: 0.522 +mistranslation: 0.492 +debug: 0.481 +semantic: 0.464 +graphic: 0.358 +register: 0.341 +files: 0.307 +PID: 0.289 +assembly: 0.275 +vnc: 0.243 +boot: 0.232 +peripherals: 0.225 +kernel: 0.216 +virtual: 0.208 +user-level: 0.202 +socket: 0.178 +x86: 0.128 +risc-v: 0.124 +ppc: 0.073 +arm: 0.073 +VMM: 0.039 +TCG: 0.038 +i386: 0.015 +KVM: 0.003 + +Cannot access RHEL8_s390x installed OS using SSH from host OS network diff --git a/results/classifier/118/network/960 b/results/classifier/118/network/960 new file mode 100644 index 00000000..23db21b9 --- /dev/null +++ b/results/classifier/118/network/960 @@ -0,0 +1,31 @@ +network: 0.873 +mistranslation: 0.762 +device: 0.664 +arm: 0.617 +user-level: 0.452 +semantic: 0.449 +graphic: 0.341 +performance: 0.269 +boot: 0.250 +debug: 0.239 +permissions: 0.230 +register: 0.210 +PID: 0.201 +virtual: 0.175 +socket: 0.165 +architecture: 0.160 +risc-v: 0.158 +ppc: 0.149 +VMM: 0.120 +peripherals: 0.116 +vnc: 0.106 +TCG: 0.086 +files: 0.082 +assembly: 0.034 +hypervisor: 0.014 +kernel: 0.006 +KVM: 0.005 +i386: 0.004 +x86: 0.002 + +Windows host / win98 guest, i don't understand how to use network diff --git a/results/classifier/118/network/97 b/results/classifier/118/network/97 new file mode 100644 index 00000000..88b68024 --- /dev/null +++ b/results/classifier/118/network/97 @@ -0,0 +1,31 @@ +network: 0.880 +device: 0.766 +performance: 0.755 +semantic: 0.466 +architecture: 0.427 +mistranslation: 0.392 +graphic: 0.248 +debug: 0.243 +TCG: 0.219 +risc-v: 0.155 +VMM: 0.136 +user-level: 0.106 +peripherals: 0.099 +hypervisor: 0.080 +KVM: 0.078 +permissions: 0.071 +boot: 0.068 +arm: 0.062 +i386: 0.059 +PID: 0.059 +virtual: 0.054 +ppc: 0.031 +assembly: 0.023 +x86: 0.019 +register: 0.014 +files: 0.014 +socket: 0.007 +kernel: 0.007 +vnc: 0.003 + +-serial tcp should hang up when DTR goes low diff --git a/results/classifier/118/network/974 b/results/classifier/118/network/974 new file mode 100644 index 00000000..de5a24bc --- /dev/null +++ b/results/classifier/118/network/974 @@ -0,0 +1,33 @@ +network: 0.837 +device: 0.736 +arm: 0.733 +performance: 0.699 +mistranslation: 0.607 +semantic: 0.417 +register: 0.370 +graphic: 0.339 +architecture: 0.323 +permissions: 0.323 +boot: 0.304 +VMM: 0.238 +vnc: 0.220 +ppc: 0.204 +files: 0.153 +PID: 0.135 +TCG: 0.125 +hypervisor: 0.104 +virtual: 0.090 +socket: 0.085 +debug: 0.084 +peripherals: 0.081 +user-level: 0.033 +assembly: 0.033 +risc-v: 0.023 +i386: 0.013 +KVM: 0.011 +kernel: 0.010 +x86: 0.003 + +Enable virtio-9pfs on windows hosts +Additional information: +attn: @schoenebeck diff --git a/results/classifier/118/network/976 b/results/classifier/118/network/976 new file mode 100644 index 00000000..3059b79d --- /dev/null +++ b/results/classifier/118/network/976 @@ -0,0 +1,31 @@ +network: 0.935 +performance: 0.808 +device: 0.734 +graphic: 0.612 +debug: 0.483 +mistranslation: 0.304 +architecture: 0.299 +semantic: 0.224 +files: 0.221 +virtual: 0.212 +permissions: 0.178 +register: 0.173 +user-level: 0.171 +hypervisor: 0.141 +vnc: 0.118 +i386: 0.094 +arm: 0.087 +boot: 0.080 +x86: 0.070 +ppc: 0.037 +socket: 0.034 +risc-v: 0.031 +assembly: 0.029 +peripherals: 0.023 +VMM: 0.022 +PID: 0.017 +TCG: 0.016 +kernel: 0.006 +KVM: 0.003 + +Qemu - Bridge direct network connection not working diff --git a/results/classifier/118/network/984476 b/results/classifier/118/network/984476 new file mode 100644 index 00000000..f47bb3a8 --- /dev/null +++ b/results/classifier/118/network/984476 @@ -0,0 +1,44 @@ +network: 0.890 +ppc: 0.839 +vnc: 0.828 +mistranslation: 0.814 +virtual: 0.800 +device: 0.780 +semantic: 0.770 +register: 0.767 +socket: 0.758 +graphic: 0.641 +architecture: 0.600 +performance: 0.584 +peripherals: 0.574 +VMM: 0.572 +TCG: 0.540 +boot: 0.533 +risc-v: 0.509 +arm: 0.501 +debug: 0.479 +user-level: 0.477 +files: 0.457 +PID: 0.444 +permissions: 0.404 +kernel: 0.365 +x86: 0.364 +i386: 0.360 +hypervisor: 0.343 +KVM: 0.238 +assembly: 0.102 + +"segmentaion" error when DMAing + +When working with QEMU's PCI network card E1000 emulator, I accidentally put virtual addresses into the memory mapped registers when I should have put physical addresses. Short story is, the address was too large for the physical address space so when the network card tried to DMA the location it tossed a "segmentaion" error out to the console. That's right--not a "segmentation" error, but a "segmentaion" error. I just thought I'd let ya'll know about that little typo. + +My "qemu -version" gives "QEMU emulator version 0.15.0, Copyright (c) 2003-2008 Fabrice Bellard" on linux version 2.6.32. I guess it might be an older version, dunno if the typo's still there. + +Was it "TCP segmentaion Error"? Then it is still there. + +Thanks for reporting. It will be fixed in latest QEMU. + +Yeah it was. Sorry, should have specified. Thanks! + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=362f5fb5643a9cfcf4b5127f + diff --git a/results/classifier/118/network/999 b/results/classifier/118/network/999 new file mode 100644 index 00000000..2e07b8f2 --- /dev/null +++ b/results/classifier/118/network/999 @@ -0,0 +1,36 @@ +network: 0.841 +device: 0.838 +graphic: 0.796 +socket: 0.695 +kernel: 0.659 +arm: 0.642 +debug: 0.640 +boot: 0.584 +performance: 0.536 +PID: 0.526 +register: 0.491 +semantic: 0.483 +hypervisor: 0.455 +mistranslation: 0.436 +architecture: 0.420 +vnc: 0.414 +risc-v: 0.410 +peripherals: 0.377 +ppc: 0.326 +user-level: 0.263 +TCG: 0.241 +files: 0.226 +i386: 0.219 +VMM: 0.209 +x86: 0.200 +virtual: 0.164 +assembly: 0.092 +permissions: 0.085 +KVM: 0.005 + +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 |