diff options
Diffstat (limited to 'results/classifier/105/network')
184 files changed, 8418 insertions, 0 deletions
diff --git a/results/classifier/105/network/05479587 b/results/classifier/105/network/05479587 new file mode 100644 index 00000000..742a5a97 --- /dev/null +++ b/results/classifier/105/network/05479587 @@ -0,0 +1,91 @@ +network: 0.963 +semantic: 0.866 +device: 0.811 +mistranslation: 0.759 +socket: 0.716 +instruction: 0.597 +graphic: 0.576 +boot: 0.474 +vnc: 0.464 +KVM: 0.374 +assembly: 0.326 +other: 0.200 + +[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/105/network/1010484 b/results/classifier/105/network/1010484 new file mode 100644 index 00000000..9a268f4e --- /dev/null +++ b/results/classifier/105/network/1010484 @@ -0,0 +1,38 @@ +network: 0.774 +device: 0.707 +socket: 0.645 +graphic: 0.612 +semantic: 0.568 +vnc: 0.552 +mistranslation: 0.462 +other: 0.430 +instruction: 0.333 +boot: 0.332 +assembly: 0.234 +KVM: 0.174 + +slirp to accept non-local dns server + +current version of slirp doesn't allow feeded dns address to be outside of given network. +in many scenarios you need to provide dns server that isn't local. + +this simple patch removes checking for if dns server isn't in local subnet. + + + +The feature makes sense and would be acceptable. But please +- post a patch on qemu-devel, following http://wiki.qemu.org/Contribute/SubmitAPatch +- reject non-local DNS servers if restrict=on is selected + +Thanks! + +ping + +[Expired for QEMU because there has been no activity for 60 days.] + +A patch has been sent to the list now: +https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg00180.html + +Fixed here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=120b721f5b590393971673 +... and released with QEMU v4.2 + diff --git a/results/classifier/105/network/1014099 b/results/classifier/105/network/1014099 new file mode 100644 index 00000000..ac326a88 --- /dev/null +++ b/results/classifier/105/network/1014099 @@ -0,0 +1,41 @@ +network: 0.730 +instruction: 0.531 +other: 0.483 +device: 0.479 +socket: 0.476 +mistranslation: 0.459 +graphic: 0.457 +semantic: 0.389 +vnc: 0.359 +boot: 0.341 +assembly: 0.142 +KVM: 0.130 + +hw/esp.c does not properly deal with TEST_UNIT_READY in NetBSD/sparc + +The NetBSD ncr53c9x.c driver does a TEST_UNIT_READY command with SELATN but dma disabled sometimes (early during bus enumeration). This is fine, as the command will not produce nor consume any data, and works on real hardware. + +However, the qemu emulation does not allow this (for reasons I don't understand). + +The change below fixes the problem. + + + +Guess I understand the code now - so here is a working version - though it may be considered slightly hackish + +On Sat, Jun 16, 2012 at 5:50 PM, Martin Husemann <email address hidden> wrote: +> ** Patch added: "esp.c.patch" +> https://bugs.launchpad.net/bugs/1014099/+attachment/3192643/+files/esp.c.patch + +Please see this on how to contribute patches to QEMU: +http://wiki.qemu.org/Contribute/SubmitAPatch + +Stefan + + +Patch removed, as it was bogus and your workflow is weird, so I'll post a better patch to the devel list + +Has this problem been fixed in 2012, so that we could close this ticket now? Or is there still something left to do? + +Yes. Just to make sure I tested qemu 2.8 against an old disk image from 2012 and it boots fine w/o any complaints during the device probes. + diff --git a/results/classifier/105/network/1054180 b/results/classifier/105/network/1054180 new file mode 100644 index 00000000..dde51a47 --- /dev/null +++ b/results/classifier/105/network/1054180 @@ -0,0 +1,36 @@ +network: 0.951 +graphic: 0.835 +instruction: 0.809 +device: 0.778 +vnc: 0.641 +semantic: 0.558 +socket: 0.476 +other: 0.370 +boot: 0.263 +mistranslation: 0.225 +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/105/network/1067 b/results/classifier/105/network/1067 new file mode 100644 index 00000000..c838503e --- /dev/null +++ b/results/classifier/105/network/1067 @@ -0,0 +1,97 @@ +network: 0.882 +graphic: 0.865 +device: 0.848 +instruction: 0.760 +socket: 0.713 +vnc: 0.679 +boot: 0.573 +semantic: 0.550 +assembly: 0.366 +mistranslation: 0.317 +other: 0.179 +KVM: 0.015 + +SSH QEMU ISSUE by using with MacOs +Description of problem: +ssh connection between Qemu Image and Guest Host (MacOS) broken down after few minutes +Steps to reproduce: +1. Take the Qemu window and external ssh connection to backround, \ + wait until few minutes and the connection are frozen. \ + If we clicking to qemu window again, the ssh connection are available +Additional information: +The ssh connection settings by Macos: \ +Host * \ +AddKeysToAgent yes \ +IdentityFile ~/.ssh/id_rsa \ +IdentitiesOnly yes \ +ServerAliveInterval 3600 \ +TCPKeepAlive yes \ +ServerAliveCountMax 2 \ +\ +\ +SSH connection settings by Ubuntu Server: + +Include /etc/ssh/sshd_config.d/*.conf \ +\ +#Port 22 \ +#AddressFamily any \ +#ListenAddress 0.0.0.0 \ +#ListenAddress :: \ +#HostKey /etc/ssh/ssh_host_rsa_key \ +#HostKey /etc/ssh/ssh_host_ecdsa_key \ +#HostKey /etc/ssh/ssh_host_ed25519_key \ +#RekeyLimit default none \ +#SyslogFacility AUTH \ +#LogLevel INFO \ +#LoginGraceTime 2m \ +#PermitRootLogin prohibit-password \ +#StrictModes yes \ +#MaxAuthTries 6 \ +#MaxSessions 10 \ +#PubkeyAuthentication yes \ +#Expect .ssh/authorized_keys2 to be disregarded by default in future. \ +#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 \ +#AuthorizedPrincipalsFile none \ +#AuthorizedKeysCommand none \ +#AuthorizedKeysCommandUser nobody \ +#HostbasedAuthentication no \ +#IgnoreUserKnownHosts no \ +#IgnoreRhosts yes \ +#PasswordAuthentication yes \ +#PermitEmptyPasswords no \ +ChallengeResponseAuthentication no \ +#KerberosAuthentication no \ +#KerberosOrLocalPasswd yes \ +#KerberosTicketCleanup yes \ +#KerberosGetAFSToken no \ +#GSSAPIAuthentication no \ +#GSSAPICleanupCredentials yes \ +#GSSAPIStrictAcceptorCheck yes \ +#GSSAPIKeyExchange no \ +UsePAM yes \ +#AllowAgentForwarding yes \ +#AllowTcpForwarding yes \ +#GatewayPorts no \ +X11Forwarding yes \ +#X11DisplayOffset 10 \ +#X11UseLocalhost yes \ +#PermitTTY yes \ +PrintMotd no \ +#PrintLastLog yes \ +#TCPKeepAlive yes \ +#PermitUserEnvironment no \ +#Compression delayed \ +#ClientAliveInterval 0 \ +#ClientAliveCountMax 3 \ +#UseDNS no \ +#PidFile /var/run/sshd.pid \ +#MaxStartups 10:30:100 \ +#PermitTunnel no \ +#ChrootDirectory none \ +#VersionAddendum none \ +#Banner none \ +AcceptEnv LANG LC_* \ +PasswordAuthentication yes \ +ClientAliveInterval 600 \ +TCPKeepAlive yes \ +ClientAliveCountMax 10 \ diff --git a/results/classifier/105/network/1071 b/results/classifier/105/network/1071 new file mode 100644 index 00000000..e79a12cd --- /dev/null +++ b/results/classifier/105/network/1071 @@ -0,0 +1,25 @@ +network: 0.876 +graphic: 0.792 +device: 0.708 +semantic: 0.582 +instruction: 0.522 +mistranslation: 0.422 +vnc: 0.285 +socket: 0.186 +KVM: 0.165 +boot: 0.150 +other: 0.149 +assembly: 0.112 + +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/105/network/1139 b/results/classifier/105/network/1139 new file mode 100644 index 00000000..daa9cac4 --- /dev/null +++ b/results/classifier/105/network/1139 @@ -0,0 +1,91 @@ +network: 0.927 +instruction: 0.926 +device: 0.909 +other: 0.857 +graphic: 0.852 +socket: 0.845 +mistranslation: 0.842 +vnc: 0.777 +boot: 0.774 +assembly: 0.770 +semantic: 0.765 +KVM: 0.630 + +block/nbd.c and drive backup to a remote nbd server +Description of problem: +Good afternoon! + +I trying to copy attached drive content to remote NBD server via drive-backup QMP method. I'he tested two very similar ways but with very different performance. First is a backuping to exported NBD at another server. Second way is a backuping to same server but with connecting to /dev/nbd*. + +Exporting qcow2 via nbd: +``` +(nbd) ~ # qemu-nbd -p 12345 -x backup --cache=none --aio=native --persistent -f qcow2 backup.qcow2 + +(qemu) ~ # qemu-img info nbd://10.0.0.1:12345/backup +image: nbd://10.0.0.1:12345/backup +file format: raw +virtual size: 10 GiB (10737418240 bytes) +disk size: unavailable +``` + +Starting drive backuping via QMP: + +``` +{ + "execute": "drive-backup", + "arguments": { + "device": "disk", + "sync": "full", + "target": "nbd://10.0.0.1:12345/backup", + "mode": "existing" + } +} +``` + +With process starting qemu notifying about warning: + +> warning: The target block device doesn't provide information about the block size and it doesn't have a backing file. The default block size of 65536 bytes is used. If the actual block size of the target exceeds this default, the backup may be unusable + +And backup process is limited by speed around 30MBps, watched by iotop + + +Second way to creating backup + +Exporting qcow2 via nbd: +``` +(nbd) ~ # qemu-nbd -p 12345 -x backup --cache=none --aio=native --persistent -f qcow2 backup.qcow2 +``` + +``` +(qemu) ~ # qemu-img info nbd://10.0.0.1:12345/backup +image: nbd://10.0.0.1:12345/backup +file format: raw +virtual size: 10 GiB (10737418240 bytes) +disk size: unavailable +(qemu) ~ # qemu-nbd -c /dev/nbd0 nbd://10.0.0.1:12345/backup +(qemu) ~ # qemu-img info /dev/nbd0 +image: /dev/nbd0 +file format: raw +virtual size: 10 GiB (10737418240 bytes) +disk size: 0 B +``` + +Starting drive backuping via QMP to local nbd device: + +``` +{ + "execute": "drive-backup", + "arguments": { + "device": "disk", + "sync": "full", + "target": "/dev/nbd0", + "mode": "existing" + } +} +``` + +Backup process started without previous warning, and speed limited around 100MBps (network limit) + +So I have question: how I can get same performance without connection network device to local block nbd device at the qemu host? + +Kind regards diff --git a/results/classifier/105/network/1158 b/results/classifier/105/network/1158 new file mode 100644 index 00000000..405777be --- /dev/null +++ b/results/classifier/105/network/1158 @@ -0,0 +1,14 @@ +network: 0.832 +device: 0.814 +vnc: 0.697 +graphic: 0.321 +semantic: 0.246 +other: 0.167 +mistranslation: 0.125 +boot: 0.113 +assembly: 0.066 +instruction: 0.038 +socket: 0.032 +KVM: 0.005 + +Error in setting VNC password diff --git a/results/classifier/105/network/1174 b/results/classifier/105/network/1174 new file mode 100644 index 00000000..47dbe46c --- /dev/null +++ b/results/classifier/105/network/1174 @@ -0,0 +1,26 @@ +network: 0.855 +device: 0.851 +graphic: 0.805 +mistranslation: 0.670 +instruction: 0.647 +other: 0.586 +semantic: 0.564 +vnc: 0.518 +socket: 0.494 +boot: 0.306 +KVM: 0.265 +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/105/network/1176366 b/results/classifier/105/network/1176366 new file mode 100644 index 00000000..e72164b9 --- /dev/null +++ b/results/classifier/105/network/1176366 @@ -0,0 +1,42 @@ +network: 0.851 +device: 0.568 +graphic: 0.525 +semantic: 0.490 +mistranslation: 0.458 +instruction: 0.356 +vnc: 0.355 +other: 0.330 +socket: 0.312 +boot: 0.296 +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/105/network/1189 b/results/classifier/105/network/1189 new file mode 100644 index 00000000..d34e525c --- /dev/null +++ b/results/classifier/105/network/1189 @@ -0,0 +1,14 @@ +network: 0.603 +device: 0.427 +other: 0.269 +socket: 0.268 +vnc: 0.225 +graphic: 0.193 +boot: 0.175 +semantic: 0.159 +instruction: 0.147 +mistranslation: 0.069 +assembly: 0.037 +KVM: 0.034 + +Cannot Resolve Names When Host Is Running Systemd-Resolved diff --git a/results/classifier/105/network/1192464 b/results/classifier/105/network/1192464 new file mode 100644 index 00000000..e48a06a4 --- /dev/null +++ b/results/classifier/105/network/1192464 @@ -0,0 +1,56 @@ +network: 0.810 +graphic: 0.767 +device: 0.713 +other: 0.691 +semantic: 0.655 +socket: 0.638 +instruction: 0.607 +vnc: 0.550 +mistranslation: 0.356 +boot: 0.314 +KVM: 0.231 +assembly: 0.111 + +udp checksum computed as 0 not converted to 0xffff, from guest os that share a common linux bridge among multiple guest os + +UDP checksum computed as '0' during transmission of packets that uses e1000 NIC in the Guest as well as emulated h/w in the qemu layer, That needs to be converted to 0xffff, This occurs only when Hardware checksum offload is been set in the guest OS NIC and made it as a transmitter. The guest O.S use the N/W interface that is been shared to the linux brige created in the host (used source=<bridge>) in the xml tags of libvirt. + +As per RFC768(http://tools.ietf.org/html/rfc768 [^]), If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care). + +Triaging old buck tickets ... can you still reproduce this issue with the latest version of QEMU? Is it only happening with e1000 or also with other NICs? What kind of network backend are you using (--netdev user ? tap ? ....). Could you please provide the full command line that you use to run QEMU? Thanks! + +Sorry, I meant "bug tickets", of course, not "buck tickets" ... need more coffee... + +Question is where is this zero checksum observed which is not clear from the report. + +If in the guest it is certainly correct. + +If in the host it is correct so long as the bridge appears to have checksum offloading as well. If whatever interface the guest packets appear to come from is not set up with checksum offloading this is a bug which should be fixed by setting the offload flags to match the guest. + +If outside the host this is a problem. + +Fixed: + +commit 0dacea92d26c31d453c58de2e99c178fee554166 +Author: Ed Swierk <email address hidden> +Date: Thu Nov 16 06:06:06 2017 -0800 + + net: Transmit zero UDP checksum as 0xFFFF + + The checksum algorithm used by IPv4, TCP and UDP allows a zero value + to be represented by either 0x0000 and 0xFFFF. But per RFC 768, a zero + UDP checksum must be transmitted as 0xFFFF because 0x0000 is a special + value meaning no checksum. + + Substitute 0xFFFF whenever a checksum is computed as zero when + modifying a UDP datagram header. Doing this on IPv4 and TCP checksums + is unnecessary but legal. Add a wrapper for net_checksum_finish() that + makes the substitution. + + (We can't just change net_checksum_finish(), as that function is also + used by receivers to verify checksums, and in that case the expected + value is always 0x0000.) + + Signed-off-by: Ed Swierk <email address hidden> + Signed-off-by: Jason Wang <email address hidden> + diff --git a/results/classifier/105/network/1196727 b/results/classifier/105/network/1196727 new file mode 100644 index 00000000..3a1a6131 --- /dev/null +++ b/results/classifier/105/network/1196727 @@ -0,0 +1,160 @@ +network: 0.961 +socket: 0.953 +other: 0.938 +device: 0.937 +semantic: 0.931 +instruction: 0.929 +graphic: 0.925 +boot: 0.915 +mistranslation: 0.911 +assembly: 0.910 +vnc: 0.904 +KVM: 0.796 + +SLIRP on Windows 7 64-bit host or is it me? + + Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit + Host: Windows 7 64-bit + Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 ppc64, Fedora 18 ppc64 + libiconv: 1.14 + glib: 2.28.8 +gettext: 0.18.1.1 + pixman: 0.30.0 + libSDL: 1.2.14 + Driver: virtio-net-pci + Emu: full (non-KVM) + +I'm new to Windows 7 64-bit as a host for QEMU (previously I was running QEMU on Windows XP with no issues) so it could be me, now on Windows 7 SLIRP only works for me connecting internally from the host to the guest via SLIRP redirect, but any outbound requests from the guest to the Internet are failing with the following: + +if_start... +m_get... + m = 61f7bd40 +ip_input... + m = 61f7bd40 + m_len = 48 +tcp_input... + m = 61f7bd40 iphlen = 20 inso = 0 +tcp_fconnect... + so = 33e140 + connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45 + tcp fconnect errno = 10035-Unknown error +icmp_error... + msrc = 61f7bd40 + msrc_len = 48 + 10.0.2.5 to 206.190.36.45 +m_get... + m = 61f7b6c0 +ip_output... + so = 0 + m0 = 61f7b6c0 +if_output... + so = 0 + ifm = 61f7b6c0 +if_start... +arp_table_search... + ip = 0x502000a + found hw addr = 52:54:00:12:34:56 +m_free... + m = 61f7b6c0 +tcp_close... + tp = 377840 +m_free... + m = 0 +m_free... + m = 61f7bd40 + +Am I doing something wrong with my Windows host configuration or is this a bug in SLIRP only on W64 and not W32? + +I confirmed it wasn't my host, I successfully ran a test on the same host with a 32-bit QEMU build and SLIRP works fine, for 1.6.0-rc3 as well. + +It could be my x86_64-w64-mingw32-gcc compiler version, I tested 4.8 and 4.7, maybe they're too new? Is there a specific gcc version known to work? I can build a new cross-compiler if need be. + +The reason I want the 64-bit build to work is to raise the guest memory. + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +Hi, you can close this ticket. I can't remember what I did to get it working. + +Sent from Yahoo Mail on Android + + On Thu, Jul 20, 2017 at 8:16 AM, Thomas Huth<email address hidden> wrote: Triaging old bug tickets ... can you still reproduce this problem with +the latest version of QEMU (currently v2.9.0)? + +** Changed in: qemu + Status: New => Incomplete + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1196727 + +Title: + SLIRP on Windows 7 64-bit host or is it me? + +Status in QEMU: + Incomplete + +Bug description: + Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit + Host: Windows 7 64-bit + Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 ppc64, Fedora 18 ppc64 + libiconv: 1.14 + glib: 2.28.8 + gettext: 0.18.1.1 + pixman: 0.30.0 + libSDL: 1.2.14 + Driver: virtio-net-pci + Emu: full (non-KVM) + + I'm new to Windows 7 64-bit as a host for QEMU (previously I was + running QEMU on Windows XP with no issues) so it could be me, now on + Windows 7 SLIRP only works for me connecting internally from the host + to the guest via SLIRP redirect, but any outbound requests from the + guest to the Internet are failing with the following: + + if_start... + m_get... + m = 61f7bd40 + ip_input... + m = 61f7bd40 + m_len = 48 + tcp_input... + m = 61f7bd40 iphlen = 20 inso = 0 + tcp_fconnect... + so = 33e140 + connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45 + tcp fconnect errno = 10035-Unknown error + icmp_error... + msrc = 61f7bd40 + msrc_len = 48 + 10.0.2.5 to 206.190.36.45 + m_get... + m = 61f7b6c0 + ip_output... + so = 0 + m0 = 61f7b6c0 + if_output... + so = 0 + ifm = 61f7b6c0 + if_start... + arp_table_search... + ip = 0x502000a + found hw addr = 52:54:00:12:34:56 + m_free... + m = 61f7b6c0 + tcp_close... + tp = 377840 + m_free... + m = 0 + m_free... + m = 61f7bd40 + + Am I doing something wrong with my Windows host configuration or is + this a bug in SLIRP only on W64 and not W32? + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1196727/+subscriptions + + +OK, thanks for your answer - so I'm closing the ticket now + diff --git a/results/classifier/105/network/1222034 b/results/classifier/105/network/1222034 new file mode 100644 index 00000000..900070ae --- /dev/null +++ b/results/classifier/105/network/1222034 @@ -0,0 +1,242 @@ +instruction: 0.982 +network: 0.979 +assembly: 0.978 +device: 0.976 +socket: 0.970 +other: 0.965 +mistranslation: 0.945 +boot: 0.943 +graphic: 0.942 +semantic: 0.934 +vnc: 0.912 +KVM: 0.891 + +QEMU + SPICE + AUDIO = FAILURE + +Hello it's my first time doing this, since the major round of timer/block changes in August I have not been able to have audio working in any guest with the spice protocol. + +64 bit linux , AMD SVM, IOMMUv1 M5A99X EVO R2.0 + + +Example command line: + +qemu-system-x86_64 -m 1024 -cdrom /common/stor8/torrents/Sabayon_Linux_DAILY_x86_Xfce.iso -soundhw hda -vga qxl -spice port=5999,addr=0.0.0.0,disable-ticketing -enable-kvm + + + +Any time the guest tries to access the emulated hardware it will hang for a very long period of time and play no audio through spice. + +This issue does not happen with the 1.6.0 release. + + +If you are unable to replicate this I will go to the trouble of getting the race message that happens in the guest but I am assuming at this point that my configuration is not exotic and it should be very easy to see the issue. + +Here is the dmesg that occurs inside the guest using any recent qemu upstream build for me: + +[ 248.943541] input: spice vdagent tablet as /devices/virtual/input/input6 +[ 677.164385] input: spice vdagent tablet as /devices/virtual/input/input7 +[183308.532032] INFO: rcu_sched self-detected stall on CPU { 1} (t=22338 jiffies g=1183551 c=1183550 q=30) +[183308.532032] sending NMI to all CPUs: +[183308.532032] NMI backtrace for cpu 1 +[183308.532032] CPU: 1 PID: 2765 Comm: alsa-sink-ID 22 Tainted: G W 3.10-2-amd64 #1 Debian 3.10.7-1 +[183308.532032] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +[183308.532032] task: ffff88007b1a3840 ti: ffff88007b1b2000 task.ti: ffff88007b1b2000 +[183308.532032] RIP: 0010:[<ffffffff8102e321>] [<ffffffff8102e321>] native_write_msr_safe+0x6/0x9 +[183308.532032] RSP: 0018:ffff88007fd03e18 EFLAGS: 00000046 +[183308.532032] RAX: 0000000000000400 RBX: 0000000000000001 RCX: 0000000000000830 +[183308.532032] RDX: 0000000000000001 RSI: 0000000000000400 RDI: 0000000000000830 +[183308.532032] RBP: 000000000000b0ca R08: ffffffff81693c40 R09: ffffffff814f1e2a +[183308.532032] R10: 0000000000000000 R11: ffff880000000000 R12: 0000000000000002 +[183308.532032] R13: ffffffff81693c40 R14: 0000000000000001 R15: 0000000000080000 +[183308.532032] FS: 00007f0cb7b1f700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 +[183308.532032] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[183308.532032] CR2: 00007f0cbd234000 CR3: 000000007b3e0000 CR4: 00000000000406e0 +[183308.532032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[183308.532032] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[183308.532032] Stack: +[183308.532032] ffffffff8102a739 ffffffff8102a85c 0000000000000086 0000000000002710 +[183308.532032] ffff88007fd0e8e0 ffffffff8163cd00 ffff88007fd0e2b0 ffff88007b1b2000 +[183308.532032] 0000000000000001 ffffffff8102829b ffffffff8163cd00 ffffffff810a0a53 +[183308.532032] Call Trace: +[183308.532032] <IRQ> +[183308.532032] [<ffffffff8102a739>] ? paravirt_write_msr+0xb/0xe +[183308.532032] [<ffffffff8102a85c>] ? __x2apic_send_IPI_mask+0x70/0xa5 +[183308.532032] [<ffffffff8102829b>] ? arch_trigger_all_cpu_backtrace+0x4d/0x7e +[183308.532032] [<ffffffff810a0a53>] ? rcu_check_callbacks+0x1a4/0x4bb +[183308.532032] [<ffffffff81079937>] ? tick_sched_do_timer+0x25/0x25 +[183308.532032] [<ffffffff810484b7>] ? update_process_times+0x31/0x5c +[183308.532032] [<ffffffff8107969b>] ? tick_sched_handle+0x3e/0x4a +[183308.532032] [<ffffffff81079967>] ? tick_sched_timer+0x30/0x4c +[183308.532032] [<ffffffff81059923>] ? __run_hrtimer+0xac/0x151 +[183308.532032] [<ffffffff8105a196>] ? hrtimer_interrupt+0xbd/0x19e +[183308.532032] [<ffffffff81027840>] ? smp_apic_timer_interrupt+0x6d/0x7e +[183308.532032] [<ffffffff8138b9dd>] ? apic_timer_interrupt+0x6d/0x80 +[183308.532032] <EOI> +[183308.532032] [<ffffffffa01b1648>] ? snd_timer_user_append_to_tqueue+0x3f/0x3f [snd_timer] +[183308.532032] [<ffffffffa0200905>] ? arch_local_irq_enable+0x4/0x8 [snd_pcm] +[183308.532032] [<ffffffffa0202299>] ? snd_pcm_action_lock_irq+0x91/0x9d [snd_pcm] +[183308.532032] [<ffffffffa0204070>] ? snd_pcm_common_ioctl1+0x3f2/0xaed [snd_pcm] +[183308.532032] [<ffffffffa01d2a95>] ? snd_ctl_ioctl+0x2eb/0x65f [snd] +[183308.532032] [<ffffffff810f901d>] ? kfree+0x50/0x6f +[183308.532032] [<ffffffffa0204c11>] ? snd_pcm_playback_ioctl1+0x230/0x24d [snd_pcm] +[183308.532032] [<ffffffff81114e49>] ? do_filp_open+0x2a/0x6e +[183308.532032] [<ffffffffa0204c54>] ? snd_pcm_playback_ioctl+0x26/0x29 [snd_pcm] +[183308.532032] [<ffffffff81115f74>] ? vfs_ioctl+0x1b/0x25 +[183308.532032] [<ffffffff81116795>] ? do_vfs_ioctl+0x3e8/0x42a +[183308.532032] [<ffffffff8107d0b7>] ? SyS_futex+0x133/0x165 +[183308.532032] [<ffffffff8110a6b5>] ? fput+0xe/0xb6 +[183308.532032] [<ffffffff81116825>] ? SyS_ioctl+0x4e/0x79 +[183308.532032] [<ffffffff8138ade9>] ? system_call_fastpath+0x16/0x1b +[183308.532032] Code: 0f 01 f9 48 c1 e2 20 89 0f 48 09 c2 48 89 d0 c3 89 f9 0f 32 31 ff 48 c1 e2 20 89 c0 89 3e 48 09 c2 48 89 d0 c3 89 f0 89 f9 0f 30 <31> c0 c3 89 f9 0f 33 48 c1 e2 20 89 c0 48 09 c2 48 89 d0 c3 66 +[183308.535258] NMI backtrace for cpu 0 +[183308.535258] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.10-2-amd64 #1 Debian 3.10.7-1 +[183308.535258] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +[183308.535258] task: ffffffff81613400 ti: ffffffff81600000 task.ti: ffffffff81600000 +[183308.535258] RIP: 0010:[<ffffffffa01f1a67>] [<ffffffffa01f1a67>] azx_get_position+0x4d/0x259 [snd_hda_intel] +[183308.535258] RSP: 0018:ffff88007fc03dd8 EFLAGS: 00000046 +[183308.535258] RAX: ffffc900003b8160 RBX: ffff88007bfd9de8 RCX: 0000000000000000 +[183308.535258] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880037287000 +[183308.535258] RBP: 0000000000001200 R08: ffff88007cc00050 R09: 0000000000000034 +[183308.535258] R10: 0000000000000001 R11: 0000000000000000 R12: ffff880037287000 +[183308.535258] R13: ffff88007b7e4780 R14: 0000000000000074 R15: ffff88007cad4400 +[183308.535258] FS: 00007f6045ffd700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 +[183308.535258] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +[183308.535258] CR2: 00007f1f10013000 CR3: 0000000059a83000 CR4: 00000000000406f0 +[183308.535258] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[183308.535258] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[183308.535258] Stack: +[183308.535258] ffffffff811bcb21 ffff880037384478 ffff88007cad4400 ffff88007fc03ea8 +[183308.535258] 0000000000000086 0000000000000007 0000000000000000 ffff88007bd41400 +[183308.535258] ffffffffa01f1d3c ffff88007cad4400 ffffffffa0207c07 ffff88007fd13f40 +[183308.535258] Call Trace: +[183308.535258] <IRQ> +[183308.535258] [<ffffffff811bcb21>] ? __cfq_slice_expired+0x20c/0x23f +[183308.535258] [<ffffffffa01f1d3c>] ? azx_pcm_pointer+0x20/0x3a [snd_hda_intel] +[183308.535258] [<ffffffffa0207c07>] ? snd_pcm_update_hw_ptr0+0x38/0x316 [snd_pcm] +[183308.535258] [<ffffffff8102e18f>] ? kvm_clock_read+0x1b/0x1c +[183308.535258] [<ffffffff8107338b>] ? timekeeping_get_ns.constprop.10+0xd/0x31 +[183308.535258] [<ffffffff81073615>] ? ktime_get+0x5f/0x6b +[183308.535258] [<ffffffff8102a739>] ? paravirt_write_msr+0xb/0xe +[183308.535258] [<ffffffffa0207fca>] ? snd_pcm_period_elapsed+0xe5/0xf4 [snd_pcm] +[183308.535258] [<ffffffffa01f39b4>] ? azx_interrupt+0xc0/0x15a [snd_hda_intel] +[183308.535258] [<ffffffff81099734>] ? handle_irq_event_percpu+0x49/0x1a4 +[183308.535258] [<ffffffff810998c1>] ? handle_irq_event+0x32/0x4b +[183308.535258] [<ffffffff8109bc61>] ? handle_edge_irq+0xa2/0xcc +[183308.535258] [<ffffffff8100e93e>] ? handle_irq+0x18/0x20 +[183308.535258] [<ffffffff8100e657>] ? do_IRQ+0x40/0x95 +[183308.535258] [<ffffffff81385d2d>] ? common_interrupt+0x6d/0x6d +[183308.535258] <EOI> +[183308.535258] [<ffffffff8102e385>] ? native_safe_halt+0x2/0x3 +[183308.535258] [<ffffffff810133f6>] ? default_idle+0x17/0x3f +[183308.535258] [<ffffffff81072590>] ? cpu_startup_entry+0x10d/0x187 +[183308.535258] [<ffffffff816b3d3d>] ? start_kernel+0x3e8/0x3f3 +[183308.535258] [<ffffffff816b3777>] ? repair_env_string+0x54/0x54 +[183308.535258] [<ffffffff816b3598>] ? x86_64_start_kernel+0xf2/0xfd +[183308.535258] Code: ce 49 8b 44 cd 18 4c 8d 71 74 48 89 44 24 08 42 8b 44 b7 08 83 f8 01 74 0b 83 f8 03 0f 85 a6 00 00 00 eb 0c 48 8b 43 58 8b 68 04 <e9> dd 00 00 00 48 8b 43 58 8b 48 04 48 8b 43 68 89 cd 83 78 3c +[183398.171091] [sched_delayed] sched: RT throttling activated +[183460.564042] INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 1, t=38280 jiffies, g=1183551, c=1183550, q=569) +[183460.564042] sending NMI to all CPUs: +[183460.564042] NMI backtrace for cpu 1 +[183460.564042] CPU: 1 PID: 2765 Comm: alsa-sink-ID 22 Tainted: G W 3.10-2-amd64 #1 Debian 3.10.7-1 +[183460.564042] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +[183460.564042] task: ffff88007b1a3840 ti: ffff88007b1b2000 task.ti: ffff88007b1b2000 +[183460.564042] RIP: 0010:[<ffffffff8102e321>] [<ffffffff8102e321>] native_write_msr_safe+0x6/0x9 +[183460.564042] RSP: 0018:ffff88007fd03e18 EFLAGS: 00000046 +[183460.564042] RAX: 0000000000000400 RBX: 0000000000000001 RCX: 0000000000000830 +[183460.564042] RDX: 0000000000000001 RSI: 0000000000000400 RDI: 0000000000000830 +[183460.564042] RBP: 000000000000b0ca R08: ffffffff81693c40 R09: ffffffff814f1e2a +[183460.564042] R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000002 +[183460.564042] R13: ffffffff81693c40 R14: 0000000000000001 R15: 0000000000080000 +[183460.564042] FS: 00007f0cb7b1f700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 +[183460.564042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[183460.564042] CR2: 00007f4ccff00000 CR3: 000000007b3e0000 CR4: 00000000000406e0 +[183460.564042] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[183460.564042] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[183460.564042] Stack: +[183460.564042] ffffffff8102a739 ffffffff8102a85c 0000000000000086 0000000000002710 +[183460.564042] ffff88007fd0e8e0 ffffffff8163cd00 0000000000000001 ffff88007b1b2000 +[183460.564042] ffffffff8163cdc0 ffffffff8102829b ffffffff8163cd00 ffffffff810a0c8b +[183460.564042] Call Trace: +[183460.564042] <IRQ> +[183460.564042] [<ffffffff8102a739>] ? paravirt_write_msr+0xb/0xe +[183460.564042] [<ffffffff8102a85c>] ? __x2apic_send_IPI_mask+0x70/0xa5 +[183460.564042] [<ffffffff8102829b>] ? arch_trigger_all_cpu_backtrace+0x4d/0x7e +[183460.564042] [<ffffffff810a0c8b>] ? rcu_check_callbacks+0x3dc/0x4bb +[183460.564042] [<ffffffff81079937>] ? tick_sched_do_timer+0x25/0x25 +[183460.564042] [<ffffffff810484b7>] ? update_process_times+0x31/0x5c +[183460.564042] [<ffffffff8107969b>] ? tick_sched_handle+0x3e/0x4a +[183460.564042] [<ffffffff81079967>] ? tick_sched_timer+0x30/0x4c +[183460.564042] [<ffffffff81059923>] ? __run_hrtimer+0xac/0x151 +[183460.564042] [<ffffffff8105a196>] ? hrtimer_interrupt+0xbd/0x19e +[183460.564042] [<ffffffff81027840>] ? smp_apic_timer_interrupt+0x6d/0x7e +[183460.564042] [<ffffffff8138b9dd>] ? apic_timer_interrupt+0x6d/0x80 +[183460.564042] <EOI> +[183460.564042] [<ffffffffa0200905>] ? arch_local_irq_enable+0x4/0x8 [snd_pcm] +[183460.564042] [<ffffffffa02023d8>] ? snd_pcm_stream_unlock_irq+0x18/0x19 [snd_pcm] +[183460.564042] [<ffffffffa02025e9>] ? snd_pcm_hwsync+0x58/0x5d [snd_pcm] +[183460.564042] [<ffffffffa020432e>] ? snd_pcm_common_ioctl1+0x6b0/0xaed [snd_pcm] +[183460.564042] [<ffffffffa01d2a95>] ? snd_ctl_ioctl+0x2eb/0x65f [snd] +[183460.564042] [<ffffffff810f901d>] ? kfree+0x50/0x6f +[183460.564042] [<ffffffffa0204c11>] ? snd_pcm_playback_ioctl1+0x230/0x24d [snd_pcm] +[183460.564042] [<ffffffff811181b6>] ? spin_unlock+0x5/0x6 +[183460.564042] [<ffffffff81119658>] ? dput+0x27/0xf3 +[183460.564042] [<ffffffffa0204c54>] ? snd_pcm_playback_ioctl+0x26/0x29 [snd_pcm] +[183460.564042] [<ffffffff81115f74>] ? vfs_ioctl+0x1b/0x25 +[183460.564042] [<ffffffff81116795>] ? do_vfs_ioctl+0x3e8/0x42a +[183460.564042] [<ffffffff8105eae9>] ? mmdrop+0xd/0x1c +[183460.564042] [<ffffffff8105f734>] ? finish_task_switch+0x81/0xaa +[183460.564042] [<ffffffff81384e35>] ? __schedule+0x4dc/0x532 +[183460.564042] [<ffffffff81116825>] ? SyS_ioctl+0x4e/0x79 +[183460.564042] [<ffffffff8138ade9>] ? system_call_fastpath+0x16/0x1b +[183460.564042] Code: 0f 01 f9 48 c1 e2 20 89 0f 48 09 c2 48 89 d0 c3 89 f9 0f 32 31 ff 48 c1 e2 20 89 c0 89 3e 48 09 c2 48 89 d0 c3 89 f0 89 f9 0f 30 <31> c0 c3 89 f9 0f 33 48 c1 e2 20 89 c0 48 09 c2 48 89 d0 c3 66 +[183459.216873] NMI backtrace for cpu 0 +[183459.216873] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.10-2-amd64 #1 Debian 3.10.7-1 +[183459.216873] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +[183459.216873] task: ffffffff81613400 ti: ffffffff81600000 task.ti: ffffffff81600000 +[183459.216873] RIP: 0010:[<ffffffffa01f1c84>] [<ffffffffa01f1c84>] azx_position_ok+0x11/0xa9 [snd_hda_intel] +[183459.216873] RSP: 0018:ffff88007fc03da0 EFLAGS: 00000002 +[183459.216873] RAX: ffffc900003b8000 RBX: ffff88007bfd9de8 RCX: ffffc900003b8160 +[183459.216873] RDX: 000000000000541c RSI: ffff88007bfd9de8 RDI: ffff880037287000 +[183459.216873] RBP: 000000000164e960 R08: ffff88007cc00050 R09: 0000000000000034 +[183459.216873] R10: 0000000000000103 R11: 000000000000b8a3 R12: ffff880037287000 +[183459.216873] R13: 0000000000000007 R14: 0000000080000080 R15: ffff880037287208 +[183459.216873] FS: 00007f6045ffd700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 +[183459.216873] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +[183459.216873] CR2: 00007f1f10013000 CR3: 0000000059a83000 CR4: 00000000000406f0 +[183459.216873] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[183459.216873] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[183459.216873] Stack: +[183459.216873] ffff880037287000 ffff88007bfd9de8 ffff880037287044 ffffffffa01f399a +[183459.216873] ffff88007befe3c0 0000000000000032 ffff88007a4a9800 0000000000000000 +[183459.216873] ffffffff81601fd8 0000000000000000 ffffffff81099734 000000000000080b +[183459.216873] Call Trace: +[183459.216873] <IRQ> +[183459.216873] [<ffffffffa01f399a>] ? azx_interrupt+0xa6/0x15a [snd_hda_intel] +[183459.216873] [<ffffffff81099734>] ? handle_irq_event_percpu+0x49/0x1a4 +[183459.216873] [<ffffffff810998c1>] ? handle_irq_event+0x32/0x4b +[183459.216873] [<ffffffff8109bc61>] ? handle_edge_irq+0xa2/0xcc +[183459.216873] [<ffffffff8100e93e>] ? handle_irq+0x18/0x20 +[183459.216873] [<ffffffff8100e657>] ? do_IRQ+0x40/0x95 +[183459.216873] [<ffffffff81385d2d>] ? common_interrupt+0x6d/0x6d +[183459.216873] [<ffffffff81060626>] ? ttwu_do_wakeup+0xf/0xc1 +[183459.216873] [<ffffffff8104196f>] ? arch_local_irq_enable+0x4/0x8 +[183459.216873] [<ffffffff8104215e>] ? __do_softirq+0x8e/0x205 +[183459.216873] [<ffffffff8104239f>] ? irq_exit+0x3e/0x81 +[183459.216873] [<ffffffff81027845>] ? smp_apic_timer_interrupt+0x72/0x7e +[183459.216873] [<ffffffff8138b9dd>] ? apic_timer_interrupt+0x6d/0x80 +[183459.216873] <EOI> +[183459.216873] [<ffffffff8102e385>] ? native_safe_halt+0x2/0x3 +[183459.216873] [<ffffffff810133f6>] ? default_idle+0x17/0x3f +[183459.216873] [<ffffffff81072590>] ? cpu_startup_entry+0x10d/0x187 +[183459.216873] [<ffffffff816b3d3d>] ? start_kernel+0x3e8/0x3f3 +[183459.216873] [<ffffffff816b3777>] ? repair_env_string+0x54/0x54 +[183459.216873] [<ffffffff816b3598>] ? x86_64_start_kernel+0xf2/0xfd +[183459.216873] Code: 00 00 4d 85 ed 75 d4 eb f0 48 83 c4 10 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 54 49 89 fc 55 53 48 89 f3 48 8b 47 38 8b 68 30 <48> 8b 46 50 31 d2 b9 03 00 00 00 2b 6e 48 48 01 c0 48 f7 f1 48 + + +That above example is from a debian x64 guest. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and a recent guest kernel? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/network/127 b/results/classifier/105/network/127 new file mode 100644 index 00000000..a33626f2 --- /dev/null +++ b/results/classifier/105/network/127 @@ -0,0 +1,14 @@ +network: 0.642 +device: 0.595 +mistranslation: 0.491 +boot: 0.469 +instruction: 0.454 +semantic: 0.357 +graphic: 0.299 +socket: 0.047 +other: 0.033 +vnc: 0.023 +KVM: 0.014 +assembly: 0.013 + +linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8") diff --git a/results/classifier/105/network/1279 b/results/classifier/105/network/1279 new file mode 100644 index 00000000..7ca4418e --- /dev/null +++ b/results/classifier/105/network/1279 @@ -0,0 +1,21 @@ +network: 0.990 +device: 0.860 +graphic: 0.690 +vnc: 0.532 +instruction: 0.503 +semantic: 0.344 +mistranslation: 0.272 +socket: 0.265 +KVM: 0.242 +boot: 0.234 +other: 0.144 +assembly: 0.107 + +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/105/network/1286 b/results/classifier/105/network/1286 new file mode 100644 index 00000000..ea657a77 --- /dev/null +++ b/results/classifier/105/network/1286 @@ -0,0 +1,14 @@ +mistranslation: 0.979 +network: 0.923 +device: 0.826 +semantic: 0.709 +other: 0.554 +instruction: 0.368 +boot: 0.313 +vnc: 0.246 +graphic: 0.196 +assembly: 0.166 +socket: 0.102 +KVM: 0.074 + +netdev tftp option docs don't mention that the TFTP server is read-only diff --git a/results/classifier/105/network/1297781 b/results/classifier/105/network/1297781 new file mode 100644 index 00000000..cc366273 --- /dev/null +++ b/results/classifier/105/network/1297781 @@ -0,0 +1,26 @@ +network: 0.940 +device: 0.876 +boot: 0.708 +vnc: 0.637 +mistranslation: 0.608 +graphic: 0.544 +other: 0.539 +instruction: 0.509 +semantic: 0.440 +socket: 0.432 +KVM: 0.334 +assembly: 0.263 + +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/105/network/1299 b/results/classifier/105/network/1299 new file mode 100644 index 00000000..f82f9b87 --- /dev/null +++ b/results/classifier/105/network/1299 @@ -0,0 +1,37 @@ +network: 0.973 +other: 0.891 +graphic: 0.862 +device: 0.852 +instruction: 0.845 +semantic: 0.816 +vnc: 0.619 +socket: 0.614 +mistranslation: 0.539 +boot: 0.489 +KVM: 0.356 +assembly: 0.247 + +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/105/network/1309 b/results/classifier/105/network/1309 new file mode 100644 index 00000000..7c45ab30 --- /dev/null +++ b/results/classifier/105/network/1309 @@ -0,0 +1,14 @@ +network: 0.893 +graphic: 0.813 +device: 0.748 +vnc: 0.199 +instruction: 0.125 +boot: 0.102 +mistranslation: 0.085 +KVM: 0.040 +socket: 0.037 +semantic: 0.029 +other: 0.021 +assembly: 0.011 + +Heap-overflow in virtio_net_queue_enable diff --git a/results/classifier/105/network/1364 b/results/classifier/105/network/1364 new file mode 100644 index 00000000..661e7706 --- /dev/null +++ b/results/classifier/105/network/1364 @@ -0,0 +1,28 @@ +network: 0.981 +instruction: 0.956 +device: 0.939 +graphic: 0.935 +other: 0.901 +vnc: 0.763 +mistranslation: 0.739 +semantic: 0.694 +boot: 0.401 +socket: 0.382 +KVM: 0.331 +assembly: 0.292 + +Support vmnet networking without elevated permissions +Additional information: +Here is a command, that doesn't work when running as normal user: +```bash +$ qemu-system-aarch64 \ + -device virtio-net-pci,netdev=net0 \ + -netdev vmnet-bridged,id=net0,ifname=en0 \ + -machine virt +``` +It fails with: +``` +qemu-system-aarch64: -netdev vmnet-bridged,id=net0,ifname=en0: cannot create vmnet interface: general failure (possibly not enough privileges) +``` + +When running the same command using elevated permissions (i.e. via `sudo`), it works without any issue. diff --git a/results/classifier/105/network/1369347 b/results/classifier/105/network/1369347 new file mode 100644 index 00000000..a527569f --- /dev/null +++ b/results/classifier/105/network/1369347 @@ -0,0 +1,60 @@ +network: 0.850 +device: 0.840 +other: 0.745 +socket: 0.656 +instruction: 0.624 +vnc: 0.610 +boot: 0.570 +semantic: 0.567 +graphic: 0.560 +mistranslation: 0.491 +KVM: 0.440 +assembly: 0.437 + +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/105/network/1381 b/results/classifier/105/network/1381 new file mode 100644 index 00000000..52057a3d --- /dev/null +++ b/results/classifier/105/network/1381 @@ -0,0 +1,16 @@ +network: 0.881 +device: 0.876 +graphic: 0.850 +instruction: 0.689 +semantic: 0.663 +other: 0.632 +vnc: 0.547 +socket: 0.530 +boot: 0.494 +mistranslation: 0.278 +assembly: 0.193 +KVM: 0.116 + +plugins: plugin_mem_cbs is not consistently NULL'ed when returning from execution +Description of problem: +This is an invariant that we should have been checking for; when returning from execution, cpu->plugin_mem_cbs should be NULL. Otherwise we open a door for a use-after-free; admittedly this door isn't that large (it requires a tb_flush to occur while we have the dangling plugin_mem_cbs), but at least one plugin user has encountered this problem: https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg02703.html diff --git a/results/classifier/105/network/1385 b/results/classifier/105/network/1385 new file mode 100644 index 00000000..188fb547 --- /dev/null +++ b/results/classifier/105/network/1385 @@ -0,0 +1,14 @@ +network: 0.883 +mistranslation: 0.561 +semantic: 0.449 +graphic: 0.288 +KVM: 0.282 +vnc: 0.282 +device: 0.214 +socket: 0.157 +instruction: 0.149 +other: 0.107 +boot: 0.089 +assembly: 0.069 + +-net option doesn't work diff --git a/results/classifier/105/network/1400 b/results/classifier/105/network/1400 new file mode 100644 index 00000000..45fa3a76 --- /dev/null +++ b/results/classifier/105/network/1400 @@ -0,0 +1,14 @@ +network: 0.861 +device: 0.852 +instruction: 0.768 +vnc: 0.665 +socket: 0.564 +KVM: 0.360 +graphic: 0.263 +boot: 0.239 +semantic: 0.230 +assembly: 0.197 +other: 0.155 +mistranslation: 0.054 + +helper_access_check_cp_reg() raising Undefined Instruction on big-endian host diff --git a/results/classifier/105/network/1402289 b/results/classifier/105/network/1402289 new file mode 100644 index 00000000..0990bdd4 --- /dev/null +++ b/results/classifier/105/network/1402289 @@ -0,0 +1,52 @@ +network: 0.916 +device: 0.788 +semantic: 0.696 +mistranslation: 0.693 +socket: 0.658 +other: 0.570 +instruction: 0.533 +vnc: 0.509 +boot: 0.500 +graphic: 0.468 +assembly: 0.417 +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/105/network/1422 b/results/classifier/105/network/1422 new file mode 100644 index 00000000..720d762c --- /dev/null +++ b/results/classifier/105/network/1422 @@ -0,0 +1,28 @@ +network: 0.649 +device: 0.638 +graphic: 0.627 +socket: 0.597 +other: 0.592 +instruction: 0.571 +vnc: 0.554 +semantic: 0.542 +KVM: 0.535 +assembly: 0.451 +boot: 0.417 +mistranslation: 0.400 + +/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q' +Description of problem: +Qemu 7.2.0 doesn't build on powerpc64le. +Steps to reproduce: +Build qemu. +Additional information: +``` +FAILED: libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o +cc -m64 -mlittle-endian -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/include/pixman-1 -I/usr/local/include -I/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -iquote . -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/include -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong -O2 -pipe -fstack-protector-strong -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -MF libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o.d -o libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -c ../tcg/tcg.c +In file included from ../tcg/tcg.c:432: +/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q' + asm("mr %%r6, %1\n\t" + ^ +1 error generated. +``` diff --git a/results/classifier/105/network/1440 b/results/classifier/105/network/1440 new file mode 100644 index 00000000..aa6be7d3 --- /dev/null +++ b/results/classifier/105/network/1440 @@ -0,0 +1,14 @@ +network: 0.500 +device: 0.416 +socket: 0.407 +semantic: 0.363 +mistranslation: 0.287 +vnc: 0.255 +graphic: 0.215 +instruction: 0.188 +boot: 0.121 +KVM: 0.070 +other: 0.066 +assembly: 0.004 + +block/curl.c uses curl features deprecated in curl 7.55.0 and 7.85.0 diff --git a/results/classifier/105/network/1451 b/results/classifier/105/network/1451 new file mode 100644 index 00000000..76b855cd --- /dev/null +++ b/results/classifier/105/network/1451 @@ -0,0 +1,14 @@ +network: 0.978 +vnc: 0.949 +device: 0.895 +boot: 0.601 +graphic: 0.517 +socket: 0.515 +instruction: 0.497 +KVM: 0.311 +semantic: 0.224 +mistranslation: 0.215 +other: 0.135 +assembly: 0.093 + +Assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed. diff --git a/results/classifier/105/network/1462 b/results/classifier/105/network/1462 new file mode 100644 index 00000000..41d997c6 --- /dev/null +++ b/results/classifier/105/network/1462 @@ -0,0 +1,27 @@ +network: 0.913 +graphic: 0.909 +device: 0.896 +boot: 0.892 +instruction: 0.868 +vnc: 0.833 +socket: 0.770 +semantic: 0.547 +mistranslation: 0.327 +other: 0.143 +KVM: 0.079 +assembly: 0.063 + +qemu-system-m68k segfaults on opcode 0x4848 +Description of problem: +Running an m68k executable with opcode 0x4848 will segfault qemu-system-m68k +Steps to reproduce: +1. Boot m68k debian +2. Compile program (see above for the oops.c source) that executes opcode 0x4848 +3. Run program +4. QEMU segfaults: + +``` +./debian-m68k.sh: line 10: 4420 Segmentation fault (core dumped) qemu-system-m68k -boot c -M q800 -serial none -serial mon:stdio -m 1000M -net nic,model=dp83932,addr=08:00:07:12:34:89 -net user -append "root=/dev/sda2 rw console=ttyS0 console=tty" -kernel virt/vmlinux-4.16.0-1-m68k -initrd virt/initrd.img-4.16.0-1-m68k -drive file=virt/debian-m68k-deb10.qcow2,format=qcow2 -nographic +``` +Additional information: + diff --git a/results/classifier/105/network/1482 b/results/classifier/105/network/1482 new file mode 100644 index 00000000..7a4d15af --- /dev/null +++ b/results/classifier/105/network/1482 @@ -0,0 +1,28 @@ +network: 0.986 +graphic: 0.762 +device: 0.604 +semantic: 0.527 +boot: 0.506 +instruction: 0.479 +mistranslation: 0.378 +vnc: 0.320 +assembly: 0.303 +other: 0.291 +socket: 0.216 +KVM: 0.074 + +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/105/network/1502095 b/results/classifier/105/network/1502095 new file mode 100644 index 00000000..229d1e23 --- /dev/null +++ b/results/classifier/105/network/1502095 @@ -0,0 +1,57 @@ +network: 0.866 +instruction: 0.864 +other: 0.820 +device: 0.747 +graphic: 0.736 +mistranslation: 0.713 +KVM: 0.650 +semantic: 0.589 +socket: 0.429 +assembly: 0.320 +vnc: 0.318 +boot: 0.237 + +Sporadic input / output error — x86-64 linux guest + +** Setup: ** + +→ Host + Qemu version 2.4.0.1 + Linux: 4.1.1 (Debian 8.2, GCC 4.9.2, x86_64) + filesystem ext3 and ext4 + +→ Guests (3 VMs) + architecture x86_64, Linux 3.16.0-4-amd64 (Debian 7.6) + virtual disk qcow2, uncompressed + guests filesystem ext3 + virtual disks size: VM1: 3GB, VM2: 5GB, VM3: 250GB + +→ Network + bridge (br0) and tap interfaces. + + +** Command line ** + +For all 3 VMs, the command line is similar to the following. Only RAM size and ID ("109") are changed. + + /usr/local/bin/qemu-system-x86_64 -hda /media/raid1/qemu-109 -m 8G -smp 4 -enable-kvm \ + -netdev bridge,id=br109 -device virtio-net-pci,netdev=br109,id=nic0,mac=00:00:00:00:01:09 \ + -k it -daemonize + + +** Problem ** + +Sporadic, unexplained input output error. +When I try to SSH to one of the instances, most of the times everything just works fine. Some other times, the SSH connection can be established, but as I interact with the guests via SSH (ls, cd, top) the guest reports "input / output error" on the SSH console. Sometimes, the SSH daemon on the guest answers "/bin/bash input output error". Sometimes the SSH client answers that the connection has been dropped by the host. + +When this happens, the web services I run on the VMs get unreachable, the VMs themselves are unreachable/unusable via SSH as described, and after killing the relative qemu processes and restarting the VMs, no recent logs are registered on /var/logs, arguably since the time of the crash. + +This only happens to one VM at a time, independently. The other VMs appear to run fine when one VM encounters the problem. + +I which instructions to further debug this. + +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/105/network/1505 b/results/classifier/105/network/1505 new file mode 100644 index 00000000..2882426f --- /dev/null +++ b/results/classifier/105/network/1505 @@ -0,0 +1,14 @@ +network: 0.714 +device: 0.697 +instruction: 0.616 +other: 0.415 +boot: 0.362 +semantic: 0.361 +mistranslation: 0.286 +socket: 0.283 +KVM: 0.252 +vnc: 0.212 +graphic: 0.193 +assembly: 0.071 + +guest agent: add --allow-rpcs / whitelist mode diff --git a/results/classifier/105/network/151 b/results/classifier/105/network/151 new file mode 100644 index 00000000..00dc3598 --- /dev/null +++ b/results/classifier/105/network/151 @@ -0,0 +1,14 @@ +network: 0.809 +device: 0.759 +instruction: 0.434 +semantic: 0.358 +boot: 0.298 +graphic: 0.291 +vnc: 0.267 +socket: 0.175 +mistranslation: 0.170 +other: 0.149 +KVM: 0.131 +assembly: 0.015 + +virtio-net ignores the absence of the VIRTIO_NET_F_CTRL_VQ feature bit diff --git a/results/classifier/105/network/1543163 b/results/classifier/105/network/1543163 new file mode 100644 index 00000000..cc92a811 --- /dev/null +++ b/results/classifier/105/network/1543163 @@ -0,0 +1,79 @@ +network: 0.967 +device: 0.964 +instruction: 0.963 +socket: 0.953 +boot: 0.953 +assembly: 0.946 +graphic: 0.944 +KVM: 0.940 +vnc: 0.938 +other: 0.919 +semantic: 0.892 +mistranslation: 0.873 + +VMs unable to boot from network with e1000 since 2.2 + +With KVM/QEMU version 1.4, using e1000 NIC, virtual machines boot from network alright; they get an IP from DHCP server (machine A), then connect to Microsoft System Center (machine B) and proceed to boot into Windows PE, install images etc. + +However, with versions at least 2.2 and 2.5, using same NIC, virtual machines fail to boot from network; they still get an IP from A, but then fail "contacting B using gateway (0.0.0.0). Different NICs do not help except for i82551, which however causes problems further down the road (presumably because there is no driver for that card in PE (based on Windows 7/8/10)). + +Note that actual physical machines work. + +Wireshark reveals this: + +QEMU 1.4 + Intel e1000 +********************** +1) client sends DHCP discover +2) machine A answers, offers an IP, gateway and itself as next server +3) machine B answers, offers no IP, but gateway and itself as next server +4) client requests the IP +5) machine A ACKs +6) client sends unicast request for ??? to B +7) B offers (unicast) a boot file (some .com) +8) client sends another unicast request for ??? to B +9) B again offers the boot file +(then they chat a bit, B offers another file, client downloads some stuff via TFTP etc.) + + +QEMU 2.2/2.5 + Intel e1000 +************************** +1) client sends DHCP discover +2) machine A answers, offers an IP, gateway and itself as next server +3) machine B answers, offers no IP, but gateway and itself as next server +4) client requests the IP +5) machine A ACKs +6) client sends _broadcast_ request for ??? to B +7) B offers (likewise broadcast) a boot file +8) client sends another request, this time unicast and claims "Client IP address = 0.0.0.0" +(and it basically hangs) + + +So, since some time after 1.4, QEMUlated machines with otherwise trusty e1000 can no longer boot from network and it might be due to different behaviour. + +Probably the same issue in different scenario: DHCP server is running on the host machine (VMs use virtual NICs connected to a bridge) and is also configured to do PXE, which works, but only when VMs are launched in BIOS mode. When launched in UEFI mode using Tianocore, they fail. Now the interesting bit is again provided by Wireshark: + + +BIOS mode +********* +1) VM sends DHCP discover, flag 0x0000 (Unicast) +2) DHCP replies with an offer, also 0x0000 (Unicast) +3) normal process continues + + +UEFI MODE +******** +1) VM sends DHCP discover, flag 0x8000 (Broadcast) +2) DHCP replies with an offer, also 0x8000 (Broadcast) +3) VM ignores the offer +4) goto 1) + +The UEFI PXE issue was caused by a typo in DHCP server config file; the server then did not send DHCP option, if I remember correctly, 67. +Nevertheless, that inspired me and I will further investigate the original issue with SCCM and focus on DHCP options. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I have 3.10 and I managed to boot with e1000 at least in BIOS mode. I am not sure about UEFI mode, because I get no output on "screen" for whatever, perhaps unrelated reason. +Anyway, I think we may close it for now. + +Ok, thanks for checking. Closing now. + diff --git a/results/classifier/105/network/1569988 b/results/classifier/105/network/1569988 new file mode 100644 index 00000000..e7baaf62 --- /dev/null +++ b/results/classifier/105/network/1569988 @@ -0,0 +1,71 @@ +network: 0.930 +device: 0.926 +other: 0.884 +vnc: 0.884 +graphic: 0.883 +instruction: 0.869 +socket: 0.861 +mistranslation: 0.855 +semantic: 0.852 +boot: 0.743 +assembly: 0.707 +KVM: 0.647 + +[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/105/network/1574327 b/results/classifier/105/network/1574327 new file mode 100644 index 00000000..65c20b7f --- /dev/null +++ b/results/classifier/105/network/1574327 @@ -0,0 +1,33 @@ +network: 0.940 +device: 0.849 +mistranslation: 0.786 +instruction: 0.744 +graphic: 0.732 +vnc: 0.612 +semantic: 0.571 +socket: 0.504 +boot: 0.469 +other: 0.244 +KVM: 0.139 +assembly: 0.043 + +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/105/network/1575561 b/results/classifier/105/network/1575561 new file mode 100644 index 00000000..2d0bc7f5 --- /dev/null +++ b/results/classifier/105/network/1575561 @@ -0,0 +1,29 @@ +network: 0.898 +graphic: 0.731 +boot: 0.693 +mistranslation: 0.605 +device: 0.542 +instruction: 0.504 +other: 0.482 +vnc: 0.456 +semantic: 0.331 +socket: 0.222 +KVM: 0.079 +assembly: 0.071 + +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/105/network/1585433 b/results/classifier/105/network/1585433 new file mode 100644 index 00000000..168f0400 --- /dev/null +++ b/results/classifier/105/network/1585433 @@ -0,0 +1,24 @@ +network: 0.877 +device: 0.846 +instruction: 0.843 +vnc: 0.798 +mistranslation: 0.796 +socket: 0.757 +graphic: 0.672 +semantic: 0.513 +other: 0.448 +boot: 0.364 +assembly: 0.082 +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/105/network/1588591 b/results/classifier/105/network/1588591 new file mode 100644 index 00000000..eaae4f42 --- /dev/null +++ b/results/classifier/105/network/1588591 @@ -0,0 +1,26 @@ +network: 0.863 +instruction: 0.822 +device: 0.791 +socket: 0.738 +graphic: 0.725 +other: 0.719 +semantic: 0.707 +mistranslation: 0.656 +boot: 0.536 +vnc: 0.287 +assembly: 0.241 +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/105/network/1604303 b/results/classifier/105/network/1604303 new file mode 100644 index 00000000..093b3dc5 --- /dev/null +++ b/results/classifier/105/network/1604303 @@ -0,0 +1,33 @@ +network: 0.963 +KVM: 0.959 +device: 0.898 +graphic: 0.843 +instruction: 0.766 +boot: 0.657 +socket: 0.650 +mistranslation: 0.633 +vnc: 0.603 +semantic: 0.553 +other: 0.536 +assembly: 0.185 + +Solaris on KVM/QEMU: WARNING rtls0: Failure resetting PHY + +When running Solaris (both version 10 and 11) on a QEMU/KVM virtual host, the Solaris guest displays this warning just after starting the system: +WARNING rtls0: Failure resetting PHY. + +Although the networking seems to work fine. + +I have this network device model selected for the Solaris guest: rtl8139 + +See also: +http://www.linux-kvm.org/page/Guest_Support_Status#UNIX_Family:_Solaris.2FOpenSolaris + +version: qemu-system-x86.x86_64 2:2.6.0-5.fc24 + +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/105/network/1633508 b/results/classifier/105/network/1633508 new file mode 100644 index 00000000..0178a8db --- /dev/null +++ b/results/classifier/105/network/1633508 @@ -0,0 +1,63 @@ +network: 0.849 +device: 0.837 +instruction: 0.831 +semantic: 0.752 +socket: 0.658 +other: 0.653 +mistranslation: 0.645 +graphic: 0.613 +boot: 0.572 +vnc: 0.474 +assembly: 0.330 +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/105/network/1634726 b/results/classifier/105/network/1634726 new file mode 100644 index 00000000..95fc3671 --- /dev/null +++ b/results/classifier/105/network/1634726 @@ -0,0 +1,61 @@ +network: 0.781 +vnc: 0.725 +device: 0.696 +graphic: 0.590 +semantic: 0.587 +socket: 0.543 +instruction: 0.496 +mistranslation: 0.490 +boot: 0.339 +KVM: 0.318 +other: 0.280 +assembly: 0.242 + +qemu "make test" fails in iov.c with "undefined reference" on aarch64 on Ubuntu 16.04 + +I'm building the master tree on a multicore ARMv8 machine running Ubuntu 16.04. The build worked just fine, using the simple directions in the README file and "make -j 64" to do the build. + +Next, I did "make test", and got this: + +emv@armv8hello:~/src/qemu/qemu/build$ make test +make -C tests/tcg test +make[1]: Entering directory '/mnt/src/qemu/qemu/build/tests/tcg' + CC test_path.o + LINK test_path +test_path.o: In function `qemu_iovec_is_zero': +/home/emv/src/qemu/qemu/util/iov.c:365: undefined reference to `buffer_is_zero' +collect2: error: ld returned 1 exit status +/home/emv/src/qemu/qemu/rules.mak:105: recipe for target 'test_path' failed +make[1]: *** [test_path] Error 1 +make[1]: Leaving directory '/mnt/src/qemu/qemu/build/tests/tcg' +Makefile:498: recipe for target 'test' failed +make: *** [test] Error 2 + +I expected "make test" to complete with no errors. + +uname -a: +Linux armv8hello.local.lan 4.4.0-38-generic #57-Ubuntu SMP Wed Sep 7 10:19:14 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux + +emv@armv8hello:~/src/qemu/qemu$ more VERSION +2.7.50 + +You want 'make check' to run the self-tests. 'make test' is a bunch of broken old stuff :-( + + +Ah, perhaps this bug should be renamed, "remove make test target". + +While I'm noting things, "make check" builds OK on this system, complaining only about kvm. My next goal is "make docker-test". + +"make docker-test" fails repeatedly with + +Pulling repository docker.io/library/qemu +docker: Error: image library/qemu:debian-bootstrap not found. +See 'docker run --help'. +Pulling repository docker.io/library/qemu +docker: Error: image library/qemu:fedora not found. +See 'docker run --help'. + +etc. + +"make test" has been removed, so I'll mark this as fixed now. + diff --git a/results/classifier/105/network/1656 b/results/classifier/105/network/1656 new file mode 100644 index 00000000..9681c37d --- /dev/null +++ b/results/classifier/105/network/1656 @@ -0,0 +1,20 @@ +network: 0.783 +device: 0.762 +graphic: 0.596 +socket: 0.533 +instruction: 0.489 +vnc: 0.488 +mistranslation: 0.443 +KVM: 0.395 +boot: 0.338 +other: 0.243 +semantic: 0.225 +assembly: 0.068 + +https://wiki.qemu.org/: TLS certificate has expired (`May 14 21:15:57 2023 GMT`) +Description of problem: +The ceritficate for https://wiki.qemu.org/ has expired on May 14 21:15:57 2023 GMT. +Steps to reproduce: +1. Browse https://wiki.qemu.org/ +Additional information: + diff --git a/results/classifier/105/network/1656927 b/results/classifier/105/network/1656927 new file mode 100644 index 00000000..97e5b3f5 --- /dev/null +++ b/results/classifier/105/network/1656927 @@ -0,0 +1,35 @@ +network: 0.955 +vnc: 0.654 +device: 0.646 +socket: 0.602 +KVM: 0.556 +instruction: 0.490 +graphic: 0.435 +semantic: 0.349 +mistranslation: 0.272 +other: 0.272 +assembly: 0.233 +boot: 0.222 + +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/105/network/1662 b/results/classifier/105/network/1662 new file mode 100644 index 00000000..a6576c3e --- /dev/null +++ b/results/classifier/105/network/1662 @@ -0,0 +1,48 @@ +network: 0.989 +instruction: 0.967 +vnc: 0.965 +socket: 0.961 +device: 0.945 +graphic: 0.943 +boot: 0.889 +assembly: 0.842 +mistranslation: 0.722 +semantic: 0.554 +KVM: 0.440 +other: 0.199 + +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/105/network/1702798 b/results/classifier/105/network/1702798 new file mode 100644 index 00000000..469c1309 --- /dev/null +++ b/results/classifier/105/network/1702798 @@ -0,0 +1,50 @@ +network: 0.834 +instruction: 0.769 +graphic: 0.750 +device: 0.695 +semantic: 0.603 +KVM: 0.573 +assembly: 0.571 +mistranslation: 0.563 +other: 0.561 +socket: 0.550 +vnc: 0.547 +boot: 0.453 + +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/105/network/1719689 b/results/classifier/105/network/1719689 new file mode 100644 index 00000000..9b926856 --- /dev/null +++ b/results/classifier/105/network/1719689 @@ -0,0 +1,34 @@ +network: 0.975 +other: 0.764 +graphic: 0.723 +boot: 0.690 +vnc: 0.593 +device: 0.579 +socket: 0.574 +semantic: 0.423 +mistranslation: 0.390 +KVM: 0.274 +instruction: 0.207 +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/105/network/1721788 b/results/classifier/105/network/1721788 new file mode 100644 index 00000000..5d8d2f41 --- /dev/null +++ b/results/classifier/105/network/1721788 @@ -0,0 +1,103 @@ +network: 0.717 +semantic: 0.668 +graphic: 0.629 +assembly: 0.614 +device: 0.606 +instruction: 0.603 +other: 0.600 +KVM: 0.528 +socket: 0.503 +vnc: 0.496 +boot: 0.492 +mistranslation: 0.488 + +Failed to get shared "write" lock with 'qemu-img info' + +When running 'qemu-img info test.qcow2' while test.qcow2 is currently used by a Qemu process, I get the error + +qemu-img: Could not open 'test.qcow2': Failed to get shared "write" lock. + + +Why does displaying information about a disk image need a write lock for the file? + +Steps to reproduce: + +qemu-img create -f qcow2 test.qcow2 10M +qemu-system-x86_64 -nographic -drive file=test.qcow2 +qemu-img info test.qcow2 + +The above was tested with Qemu version 2.10.0 + +The QEMU process that has the disk image open may be doing I/O that causes qcow2 metadata to be changed. Such changes could confuse the 'qemu-img' process it is was reading the metadata at the same time it was being changed, causing bad data to be printed or worse. So requiring a write lock is the 'safe' thing to do for reliability in the worst case. You can override this by passing '--force-share' arg though. + +I've just noticed, however, that '--force-share' appears totally undocumented in both CLI help output and the man page. So that's certainly something that should be fixed + +On 10/06/2017 09:09 AM, Jan Heidbrink wrote: +> Public bug reported: +> +> When running 'qemu-img info test.qcow2' while test.qcow2 is currently +> used by a Qemu process, I get the error +> +> qemu-img: Could not open 'test.qcow2': Failed to get shared "write" +> lock. +> +> +> Why does displaying information about a disk image need a write lock for the file? + +Because there is a risk (albeit rather slight) that what you read from +the disk is inconsistent due to being an intermediate state in-between +separate non-atomic write actions by the other process that has it open +for write. + +If you are willing to ignore the risk, then use: + +qemu-img info -U test.qcow2 + +which says that you are okay reading the image while it is shared with a +concurrent writer, even if the read fails spectacularly in the unlikely +case that it sees inconsistent information. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +This does not only affect qemu-img only, it could not make libvirt +"<shareable>" work either when two vms were running with share disk +image. Is there a workaround for this situation? + +Best, +Liang + +On 10/6/17 10:30 AM, Daniel Berrange wrote: +> I've just noticed, however, that '--force-share' appears totally +> undocumented in both CLI help output and the man page. So that's +> certainly something that should be fixed +> + + + +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. + +Hi, + +What exactly is the problem now? As Eric explained in comment 3, "qemu-img info -U" is what needs to be used here. Daniel raised the problem of --force-share/-U being undocumented, but that’s no longer the case as of commit a7e326df1c116e99e, which was first included in the 2.12.0 release. + +Max + +Ah ok, I think this bug can be closed then. + +I have the same problem + diff --git a/results/classifier/105/network/1724477 b/results/classifier/105/network/1724477 new file mode 100644 index 00000000..2a44bd52 --- /dev/null +++ b/results/classifier/105/network/1724477 @@ -0,0 +1,57 @@ +network: 0.855 +vnc: 0.852 +device: 0.822 +other: 0.804 +socket: 0.798 +KVM: 0.774 +semantic: 0.506 +instruction: 0.506 +boot: 0.454 +mistranslation: 0.385 +graphic: 0.306 +assembly: 0.304 + +Build-in websocket broken since v2.9.0-rc0 + +Since upgrading to 2.9.0, the qemu's build-in websocket was no longer available. + +Host: Ubuntu 16.04 LTS +Command-line: /bin/qemu-system-x86_64 -enable-kvm -vnc 0.0.0.0:8,websocket + +I have tested the following qemu versions: + +master Fail +2.10.1 Fail +2.9.1 Fail +2.9.0 Fail +2.9.0-rc3 Fail +2.9.0-rc0 Fail + +2.8.1.1 Pass +2.7.1 Pass +2.6.2 Pass + + + + + +Note that we tightened up the websocket server impl to validate HTTP requests more strictly. One key change is that the websockets path is required to be empty, while noVNC will default to appending a path - so make sure you change noVNC to have an empty path. Also until GIT master yesterday, there was a bug that prevented it working if the client requested keep-alive, which I see noVNC now does. So if you try git master today, it ought to work. + +Awesome! I cleared the path and tried the latest version, now it works! +BTW, is there any other VNC Web Client that I can choose? or noVNC is the one and only? + +Key fixes for client interoperability coming in 2.11 include + + +6d5d23b00709510d55711661c7ca41408fd9934e io: cope with websock 'Connection' header having multiple values +530ca60c16c83435d4becc9916d74fa43e003815 io: Attempt to send websocket close messages to client +268a53f50de795481dd73ffd0e0c1339ad3dc44b io: Reply to ping frames +01af17fc002414ee1ac0800babfb0edc2bef1a7d io: Ignore websocket PING and PONG frames +3a29640e2cbae9d47b89ffaf98ed358920eb6797 io: Allow empty websocket payload +ff1300e626949fa9850b0f91dc5e8c2cb45b6a88 io: Add support for fragmented websocket binary frames +eefa3d8ef649f9055611361e2201cca49f8c3433 io: Small updates in preparation for websocket changes +33badfd1e3735b877e41939100511c65572be6b9 io: use case insensitive check for Connection & Upgrade websock headers +3a3f8705962c8c8a47a9b981ffd5aab7274ad508 io: include full error message in websocket handshake trace +f69a8bde29354493ff8aea64cc9cb3b531d16337 io: send proper HTTP response for websocket errors + + diff --git a/results/classifier/105/network/1732 b/results/classifier/105/network/1732 new file mode 100644 index 00000000..4d6cad18 --- /dev/null +++ b/results/classifier/105/network/1732 @@ -0,0 +1,16 @@ +network: 0.988 +mistranslation: 0.935 +graphic: 0.925 +semantic: 0.904 +assembly: 0.832 +other: 0.827 +device: 0.767 +instruction: 0.656 +socket: 0.508 +vnc: 0.480 +boot: 0.349 +KVM: 0.204 + +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/105/network/1751 b/results/classifier/105/network/1751 new file mode 100644 index 00000000..932230bb --- /dev/null +++ b/results/classifier/105/network/1751 @@ -0,0 +1,14 @@ +network: 0.894 +device: 0.854 +mistranslation: 0.831 +instruction: 0.787 +socket: 0.714 +vnc: 0.623 +boot: 0.464 +semantic: 0.406 +graphic: 0.383 +assembly: 0.367 +other: 0.222 +KVM: 0.014 + +s390 host: helper_st16_mmu: Assertion `(get_memop(oi) & MO_SIZE) == MO_128' failed diff --git a/results/classifier/105/network/1754372 b/results/classifier/105/network/1754372 new file mode 100644 index 00000000..03594800 --- /dev/null +++ b/results/classifier/105/network/1754372 @@ -0,0 +1,31 @@ +network: 0.890 +device: 0.881 +instruction: 0.784 +vnc: 0.763 +socket: 0.754 +semantic: 0.621 +graphic: 0.540 +boot: 0.527 +mistranslation: 0.523 +other: 0.404 +KVM: 0.375 +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/105/network/1757 b/results/classifier/105/network/1757 new file mode 100644 index 00000000..a6d59db9 --- /dev/null +++ b/results/classifier/105/network/1757 @@ -0,0 +1,14 @@ +network: 0.762 +device: 0.697 +semantic: 0.413 +boot: 0.324 +vnc: 0.245 +other: 0.235 +mistranslation: 0.224 +instruction: 0.222 +graphic: 0.212 +KVM: 0.197 +socket: 0.140 +assembly: 0.042 + +guest-agent: improve help for --allow-rpcs and --block-rpcs diff --git a/results/classifier/105/network/1773753 b/results/classifier/105/network/1773753 new file mode 100644 index 00000000..37ce858b --- /dev/null +++ b/results/classifier/105/network/1773753 @@ -0,0 +1,291 @@ +network: 0.943 +other: 0.928 +assembly: 0.928 +device: 0.927 +KVM: 0.909 +socket: 0.905 +instruction: 0.890 +semantic: 0.885 +vnc: 0.879 +graphic: 0.866 +mistranslation: 0.845 +boot: 0.788 + +virsh start, after virsh managed save hangs and vm goes to paused state with qemu version v2.12.0-813-g5a5c383b13-dirty on powerpc + +Host Env: +IBM Power8 with Fedora28 base with compiled upstream kernel, qemu, libvirt. + +Host Kernel: 4.17.0-rc5-00069-g3acf4e395260 + +qemu-kvm(5a5c383b1373aeb6c87a0d6060f6c3dc7c53082b): v2.12.0-813-g5a5c383b13-dirty + +libvirt(4804a4db33a37f828d033733bc47f6eff5d262c3): + +Guest Kernel: 4.17.0-rc7 + +Steps to recreate: +Define a guest attached with above setup and start. +# virsh start avocado-vt-vm1 + +guest console;... +# uname -r +4.17.0-rc7 +[root@atest-guest ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 3 +On-line CPU(s) list: 0-2 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 3 +NUMA node(s): 1 +Model: 2.1 (pvr 004b 0201) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 64K +L1i cache: 32K +NUMA node0 CPU(s): 0-2 + + +# virsh managedsave avocado-vt-vm1 + +Domain avocado-vt-vm1 state saved by libvirt + +# virsh list + Id Name State +---------------------------------------------------- + +# virsh start avocado-vt-vm1 ----Hangs forever and vm state goes to paused. + + +# virsh list + Id Name State +---------------------------------------------------- + 87 avocado-vt-vm1 paused + + +P:S:- with same above setup, just changing the qemu-kvm comes bydefault with F28 works fine. + +/usr/bin/qemu-kvm --version +QEMU emulator version 2.11.1(qemu-2.11.1-2.fc28) + +Summary: with above other setup. +machine type pseries-2.12 and qemu-2.11.1-2.fc28 -Works fine. + +machine type pseries-2.12/pseries-2.13 and qemu 5a5c383b1373aeb6c87a0d6060f6c3dc7c53082b - Does not work. + + + +To recover from the failed state it requires below steps to be run. + +# virsh destroy avocado-vt-vm1 +Domain avocado-vt-vm1 destroyed + +# virsh undefine --managed-save avocado-vt-vm1 +Domain avocado-vt-vm1 has been undefined + + + + +On Mon, May 28, 2018 at 09:12:21AM -0000, Satheesh Rajendran wrote: +> Public bug reported: +> +> Host Env: +> IBM Power8 with Fedora28 base with compiled upstream kernel, qemu, libvirt. +> +> Host Kernel: 4.17.0-rc5-00069-g3acf4e395260 +> +> qemu-kvm(5a5c383b1373aeb6c87a0d6060f6c3dc7c53082b): +> v2.12.0-813-g5a5c383b13-dirty +> +> libvirt(4804a4db33a37f828d033733bc47f6eff5d262c3): +> +> Guest Kernel: 4.17.0-rc7 +> +> Steps to recreate: +> Define a guest attached with above setup and start. +> # virsh start avocado-vt-vm1 +> +> guest console;... +> # uname -r +> 4.17.0-rc7 +> [root@atest-guest ~]# lscpu +> Architecture: ppc64le +> Byte Order: Little Endian +> CPU(s): 3 +> On-line CPU(s) list: 0-2 +> Thread(s) per core: 1 +> Core(s) per socket: 1 +> Socket(s): 3 +> NUMA node(s): 1 +> Model: 2.1 (pvr 004b 0201) +> Model name: POWER8 (architected), altivec supported +> Hypervisor vendor: KVM +> Virtualization type: para +> L1d cache: 64K +> L1i cache: 32K +> NUMA node0 CPU(s): 0-2 +> +> +> # virsh managedsave avocado-vt-vm1 +> +> Domain avocado-vt-vm1 state saved by libvirt +> +> # virsh list +> Id Name State +> ---------------------------------------------------- +> +> # virsh start avocado-vt-vm1 ----Hangs forever and vm state goes to +> paused. + +Libvirt is using fd migration, right? If so, I suspect this is the +same problem with the iotest failure, and the fix should be in a pull +request: + + Message-Id: <email address hidden> + Subject: [Qemu-devel] [PULL 1/2] migration: fix exec/fd migrations + +Regards, + +-- +Peter Xu + + +with above patch compiled on top of latest upstream fails with below error: + +# virsh managedsave avocado-vt-vm1 +error: Failed to save domain avocado-vt-vm1 state +error: internal error: guest unexpectedly quit + + +rest of the behaviour same.. +# virsh start avocado-vt-vm1 ----gets hung +---crtl+c --> to comeback to prompt +# + +# virsh destroy avocado-vt-vm1 +Domain avocado-vt-vm1 destroyed + +# virsh undefine --managed-save avocado-vt-vm1 +Domain avocado-vt-vm1 has been undefined + + + + +followed by further attempts saves the domains as reported but issue still same. + +#virsh managedsave avocado-vt-vm1 + +Domain avocado-vt-vm1 state saved by libvirt +# virsh start avocado-vt-vm1 ----hung + + +# virsh list --all + Id Name State +---------------------------------------------------- + 98 avocado-vt-vm1 paused + +I tried restarting libvirt, after which guest goes to shutoff state, with reason as crash in the qemu log + + +# service libvirtd restart +Redirecting to /bin/systemctl restart libvirtd.service + +# virsh list --all + Id Name State +---------------------------------------------------- + - avocado-vt-vm1 shut off + + + +2018-05-28 12:59:46.748+0000: starting up libvirt version: 4.4.0, package: 1.fc28 (Unknown, 2018-05-28-03:15:39, 9.40.192.86), qemu version: 2.12.50v2.12.0-813-g5a5c383b13-dirty, kernel: 4.17.0-rc5-00069-g3acf4e395260, hostname: 9.40.192.86 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/share/avocado-plugins-vt/bin/qemu -name guest=avocado-vt-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-97-avocado-vt-vm1/master-key.aes -machine pseries-2.13,accel=kvm,usb=off,dump-guest-core=off -m 1024 -realtime mlock=off -smp 2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid ba3012d5-3244-47d9-bedc-0b60821f7cd1 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-97-avocado-vt-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /home/kvmci/linux/vmlinux -append 'root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug' -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/avocado/data/avocado-vt/images/jeos-27-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3d:3e:3f,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/avocado-vt-vm1-guest.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -sandbox off -msg timestamp=on +2018-05-28T12:59:46.826738Z qemu: -chardev pty,id=charserial0: char device redirected to /dev/pts/3 (label charserial0) +2018-05-28 13:00:52.948+0000: shutting down, reason=saved + +2018-05-28T13:00:52.950802Z qemu: terminating on signal 15 from pid 41456 (/usr/sbin/libvirtd) +2018-05-28 13:01:00.467+0000: starting up libvirt version: 4.4.0, package: 1.fc28 (Unknown, 2018-05-28-03:15:39, 9.40.192.86), qemu version: 2.12.50v2.12.0-813-g5a5c383b13-dirty, kernel: 4.17.0-rc5-00069-g3acf4e395260, hostname: 9.40.192.86 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/share/avocado-plugins-vt/bin/qemu -name guest=avocado-vt-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-98-avocado-vt-vm1/master-key.aes -machine pseries-2.13,accel=kvm,usb=off,dump-guest-core=off -m 1024 -realtime mlock=off -smp 2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid ba3012d5-3244-47d9-bedc-0b60821f7cd1 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-98-avocado-vt-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /home/kvmci/linux/vmlinux -append 'root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug' -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/avocado/data/avocado-vt/images/jeos-27-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3d:3e:3f,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/avocado-vt-vm1-guest.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -sandbox off -msg timestamp=on +2018-05-28T13:01:00.546872Z qemu: -chardev pty,id=charserial0: char device redirected to /dev/pts/3 (label charserial0) +2018-05-28 13:02:56.434+0000: shutting down, reason=crashed <============ + + +I was able to reproduce this with: + +qemu - v2.12.0-813-g5a5c383 +host/guest kernel - 4.11 +libvirt - 3.9.0 + +It bisects to: + + 36c2f8b migration: Delay start of migration main routines + + +However, the issue did *not* reproduce with: + +qemu - v2.12.0-865-ge609fa7 +host/guest kernel - 4.11 +libvirt - 3.9.0 + +As Peter suggested, it is fixed by: + + 0efc914 migration: fix exec/fd migrations + + +So perhaps there is still something on libvirt side? I'll try again with a more +recent one. + + + + + +Could not reproduce with: + +qemu - v2.12.0-865-ge609fa7 +host/guest kernel - 4.11 +libvirt - 4.4.0 + +and + +qemu - v2.12.0-865-ge609fa7 +host kernel - v4.17-rc7-22-g3d661e2 +guest kernel - 4.11 +libvirt - 4.4.0 + +So I'd say that this is fixed by: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0efc914 + + + +Yes, tested again with below levels and not issue is not reproducible. + +Issue is fixed! + +qemu: 2.12.50 (v2.12.0-949-g392fba9f58-dirty) +host/guest kernel: 4.17.0-rc7-00045-g0512e0134582 + +libvirt: +Compiled against library: libvirt 4.4.0 +Using library: libvirt 4.4.0 +Using API: QEMU 4.4.0 +Running hypervisor: QEMU 2.12.50 + +#virsh managedsave avocado-vt-vm1 + +Domain avocado-vt-vm1 state saved by libvirt + +# virsh start avocado-vt-vm1 +Domain avocado-vt-vm1 started + +Guest console. +# uname -r +4.17.0-rc7-00045-g0512e0134582 + + +This bug can be closed. + +libvirt compiled against 105bcdde76bc8c64f2d9aca9db684186a5e96e63 + diff --git a/results/classifier/105/network/1779447 b/results/classifier/105/network/1779447 new file mode 100644 index 00000000..edf9eb22 --- /dev/null +++ b/results/classifier/105/network/1779447 @@ -0,0 +1,37 @@ +network: 0.709 +device: 0.640 +socket: 0.615 +semantic: 0.544 +vnc: 0.531 +other: 0.501 +instruction: 0.446 +graphic: 0.387 +boot: 0.353 +mistranslation: 0.340 +assembly: 0.179 +KVM: 0.142 + +SLIRP SMB silently fails with MacOS smbd + +When using the -net user,id=net0,ipv6=off,smb=/path/to/share/option,hostfwd=tcp::19500-:22 I can successfully mount_smbfs the shared directory on the guest when QEMU is running on a Linux or FreeBSD host. However, on a MacOS host the mount_smbfs command just fails with +`mount_smbfs: unable to open connection: syserr = Connection reset by peer`. +After some debugging it turns out this is because the smbd shipped by macos is incompatible and doesn't use the same config file/command line arguments. + +I have since got it working by compiling the sources form samba.org and using the --smbd= configure option pointing to that binary. + +Would it be possible to print a warning message or even better abort the launch saying smbd is incompatible with QEMU if the -smb= flag is passed? It appears that smbd should die with an error code on invalid arguments so QEMU should be able to report that. + + +This was happening with QEMU built from git sources at c1c2a435905ae76b159c573b0c0d6f095b45ebc6. + +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. + + +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/153 + + diff --git a/results/classifier/105/network/1783 b/results/classifier/105/network/1783 new file mode 100644 index 00000000..7830e1d8 --- /dev/null +++ b/results/classifier/105/network/1783 @@ -0,0 +1,16 @@ +network: 0.989 +graphic: 0.758 +other: 0.679 +device: 0.635 +mistranslation: 0.512 +boot: 0.442 +vnc: 0.417 +semantic: 0.405 +instruction: 0.384 +KVM: 0.084 +socket: 0.066 +assembly: 0.024 + +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/105/network/1809453 b/results/classifier/105/network/1809453 new file mode 100644 index 00000000..37a575b9 --- /dev/null +++ b/results/classifier/105/network/1809453 @@ -0,0 +1,30 @@ +network: 0.762 +mistranslation: 0.662 +graphic: 0.594 +device: 0.543 +semantic: 0.528 +socket: 0.318 +instruction: 0.249 +other: 0.163 +boot: 0.123 +vnc: 0.123 +assembly: 0.005 +KVM: 0.004 + +Windows qemu download Big file bug in net user mode + +hi + +Windows qemu with -net user downloading big files has a bug, -net tap is good! + +I suspect that the Slirp protocol has a bug on the Windows pc, which is normal on ubuntu. + +What is your version of qemu? I understand you are running qemu on ubuntu. + +The VM is windows? which version? Which URL are you downloading? What is the program being used? + +thanks + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/network/1814352 b/results/classifier/105/network/1814352 new file mode 100644 index 00000000..8c47bb32 --- /dev/null +++ b/results/classifier/105/network/1814352 @@ -0,0 +1,80 @@ +network: 0.882 +graphic: 0.879 +vnc: 0.870 +other: 0.865 +socket: 0.857 +semantic: 0.844 +device: 0.834 +instruction: 0.833 +mistranslation: 0.801 +boot: 0.776 +KVM: 0.767 +assembly: 0.725 + +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/105/network/1824622 b/results/classifier/105/network/1824622 new file mode 100644 index 00000000..72009734 --- /dev/null +++ b/results/classifier/105/network/1824622 @@ -0,0 +1,32 @@ +network: 0.872 +device: 0.685 +instruction: 0.671 +semantic: 0.566 +vnc: 0.558 +socket: 0.453 +graphic: 0.439 +boot: 0.343 +other: 0.285 +mistranslation: 0.259 +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/105/network/1832281 b/results/classifier/105/network/1832281 new file mode 100644 index 00000000..f90690a9 --- /dev/null +++ b/results/classifier/105/network/1832281 @@ -0,0 +1,97 @@ +instruction: 0.994 +network: 0.989 +socket: 0.987 +vnc: 0.985 +device: 0.979 +other: 0.950 +graphic: 0.931 +semantic: 0.879 +mistranslation: 0.869 +boot: 0.868 +KVM: 0.714 +assembly: 0.409 + +tcg bug master / 4.0.0 v8 operation >>> and |= + +vm guest is linux, executed with tcg +running this Node.js snippet leads to + +$ node +> a = undefined +undefined +> a >>> 0 +4294967295 + +host node +$ node +> a = undefined +undefined +> a >>> 0 +0 + +same with |= + +node +Welcome to Node.js v12.4.0. +Type ".help" for more information. +> let buffer +undefined +> buffer |= 0 +0 + +vm with tcg: + +$ ./out/Release/node --version +v12.4.0 +./out/Release/node -e "let buffer; buffer |= 0; console.log(buffer);" +-1 + + +vm guest is debian x86_64 latest release +vm guest is started with ./x86_64-softmmu/qemu-system-x86_64 -vnc :0 -cdrom debian-9.9.0-amd64-netinst.iso -m 4G -smp cores=6,threads=1,sockets=1 -nic user,hostfwd=tcp:ipv4addr:2233-:22 -cpu qemu64 debian.img + +git tag v4.0.0 and master, commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf, for building qemu-system-x86_64 was used. + +Node.js as compiled on the vm guest (v12.4.0 / master) + + +see also +https://github.com/nodejs/node/issues/19348#issuecomment-500465502 + +I need further assistance to track down the cause of the bug. + +Kind regards +Manuel + +This might be the same underlying problem as LP:1815423 which also mentions some issues with Javascript calculations involving arithmetic operations on a js "undefined" value. That bug has a C-only reproduce case so is probably a good place to start for anybody interesting in investigating and fixing it. + + +https://<email address hidden>/ is a patch which I think probably fixes this bug -- could you test it? (I don't have an x86 vm with node.js in it to test with.) + +Hi Peter, + +I will try the tag and report back. + +result: + +node +Welcome to Node.js v12.4.0. +Type ".help" for more information. +> a = undefined +undefined +> a >>> 0 +0 +> let buffer +undefined +> buffer |= 0 +0 + + +Thanks for the patch :-) + +Thanks a lot for testing it! + + +Patch had been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1e8a98b53867f61da9c + diff --git a/results/classifier/105/network/1832877 b/results/classifier/105/network/1832877 new file mode 100644 index 00000000..40443732 --- /dev/null +++ b/results/classifier/105/network/1832877 @@ -0,0 +1,67 @@ +network: 0.473 +device: 0.375 +graphic: 0.334 +mistranslation: 0.259 +semantic: 0.243 +socket: 0.183 +boot: 0.145 +vnc: 0.086 +other: 0.085 +instruction: 0.068 +assembly: 0.053 +KVM: 0.045 + +qemu-bridge-helper undocumented and broken + +qemu output: + +access denied by acl file +qemu-system-ppc64: bridge helper failed + +Option description: + + -netdev bridge,id=id[,br=bridge][,helper=helper] + Connect a host TAP network interface to a host bridge device. + + Use the network helper helper to configure the TAP interface and attach it to the bridge. The default network + helper executable is /path/to/qemu-bridge-helper and the default bridge device is br0. + + Examples: + + #launch a QEMU instance with the default network helper to + #connect a TAP device to bridge br0 + qemu-system-i386 linux.img -netdev bridge,id=n1 -device virtio-net,netdev=n1 + + + + #launch a QEMU instance with the default network helper to + #connect a TAP device to bridge qemubr0 + qemu-system-i386 linux.img -netdev bridge,br=qemubr0,id=n1 -device virtio-net,netdev=n1 + + +What is the acl file? What is the interface to qemu-bridge-helper? + +Also this is what bridge.conf contains: + +# Access control file for qemu bridge helper +# Syntax consists of: +# # comment (ignored) +# allow all +# allow <bridge_name> +# deny all +# deny <bridge_name> +# include /path/to/additional/ACL/file +# Users are blacklisted by default and 'deny' takes precedence over 'allow'. +# Including additional ACL files allows file access permissions to be used as +# a component of the policy to allow access or deny access to specific bridges. + +How are users specified? Or is the mention of users bogus? + + +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/177 + + diff --git a/results/classifier/105/network/1849644 b/results/classifier/105/network/1849644 new file mode 100644 index 00000000..17048deb --- /dev/null +++ b/results/classifier/105/network/1849644 @@ -0,0 +1,185 @@ +network: 0.916 +instruction: 0.916 +assembly: 0.916 +graphic: 0.915 +device: 0.914 +semantic: 0.911 +socket: 0.906 +vnc: 0.902 +other: 0.888 +boot: 0.839 +KVM: 0.836 +mistranslation: 0.728 + +QEMU VNC websocket proxy requires non-standard 'binary' subprotocol + +When running a machine using "-vnc" and the "websocket" option QEMU seems to require the subprotocol called 'binary'. This subprotocol does not exist in the WebSocket specification. In fact it has never existed in the spec, in one of the very early drafts of WebSockets it was briefly mentioned but it never made it to a final version. + +When the WebSocket server requires a non-standard subprotocol any WebSocket client that works correctly won't be able to connect. + +One example of such a client is noVNC, it tells the server that it doesn't want to use any subprotocol. QEMU's WebSocket proxy doesn't let noVNC connect. If noVNC is modified to ask for 'binary' it will work, this is, however, incorrect behavior. + +Looking at the code in "io/channel-websock.c" it seems it's quite hard-coded to binary: + +Look at line 58 and 433 here: https://git.qemu.org/?p=qemu.git;a=blob;f=io/channel-websock.c + +This code has to be made more dynamic, and shouldn't require binary. + +It isn't mandatory to use a standardized subprotocol, all that's required is that the client & server agree + + https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism + + "The subprotocols may be selected from the IANA WebSocket Subprotocol Name Registry or may be a custom name jointly understood by the client and the server." + +QEMU used/required 'binary' because that is what noVNC used when the QEMU websockets code was first implemented. + +It appears that noVNC was changed though to not send a "binary" subprotocol in + + commit f8318361b1b62c4d76b091132d4a8ccfdd2957e4 + Author: Pierre Ossman <email address hidden> + Date: Sat Oct 14 12:45:56 2017 +0200 + + Remove wsProtocols setting + + It isn't in use anymore since we deprecated support for Base64 mode. + +From QEMU's POV looks like we'll need to tweak code to treat 'binary' and no sub-protocol as being equivalent. + + +Thank you for your response, Daniel! + +Do you think this is something you will have the opportunity to look at soon? + +I have sent a patch about this problem. + +Please see https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg03924.html + + + +Did anyone at QEMU get a chance to look at that patch? + +Hi, Samuel + +This patch has been viewed by Daniel. +Please see https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg00264.html + +However, Daniel has not sent a PR which includes this patch. + +Thanks. + +Ok, thanks! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c64e1e75381d + + +This is in v5.0.0 so fixed in Groovy. +The related noVNC change is in upstream version >=v1.0.0 which correlates with Ubuntu >=20.04, threfore fixing this in Focals Qemu seems good. + +Repro steps: +$ sudo apt install qemu-system-x86 novnc +/usr/share/novnc +python3 -m http.server + +Connect browser to http://<IP>:8000/vnc.html + Click "Settings" + Open "advanced" + Open "websocket" + Set port 5700 + Clear path + Click "Connect" + +And it works ... + +Turns out my former check on the offending noVNC commit was wrong. +There are +https://github.com/novnc/noVNC/commit/f8318361b1b62c4d76b091132d4a8ccfdd2957e4 (referenced on this bug before) +$ git tag --contains f8318361b1b62c4d76b091132d4a8ccfdd2957e4 +v1.0.0 +But only really gone later with: +https://github.com/novnc/noVNC/commit/c912230309806aacbae4295faf7ad6406da97617 +$ git tag --contains c912230309806aacbae4295faf7ad6406da97617 +v1.2.0 + +So the novnc of Focal isn't affected but anyone who uses a newer noVNC >=1.2 would be. +=> lower SRU priority +=> Modify above repro steps to not use noVNC from Focal via apt but use 1.2 from snaps + + +Repro steps: +$ snap install novnc +$ novnc --vnc localhost:5700 +Connect browser to http://<IP>:6080/vnc.html +Click "Connect" + +TODO: repro steps to be verified with a qemu that has the fix applied + +I can confirm the test steps mentioned above. In an unchanged scenario a formerly failing-to-connect case got working when replacing the qemu (on Focal) in use with a patched one. + +Adding an SRU Template for Focal to the bug description ... + +SRU Template for qemu added and MP linked to fix this in Ubuntu 20.04 + +Hello Samuel, or anyone else affected, + +Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.7 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.7) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +casper/1.445.1 (amd64) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +Trying to connect using +novnc latest/stable: 1.2.0 2020-07-31 (6) 18MB - + +as-is failing to connect +Keeping VNC up and refreshing qemu. + + +Updating to the new qemu from focal proposed (by now resolved the archive publishing issues we had before this morning). +Get:67 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-utils amd64 1:4.2-3ubuntu6.7 [975 kB] +Get:68 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-common amd64 1:4.2-3ubuntu6.7 [1056 kB] +Get:69 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-block-extra amd64 1:4.2-3ubuntu6.7 [53.8 kB] +Get:70 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-data all 1:4.2-3ubuntu6.7 [563 kB] +Get:71 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-kvm amd64 1:4.2-3ubuntu6.7 [13.1 kB] +Get:72 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-x86 amd64 1:4.2-3ubuntu6.7 [6720 kB] +Get:73 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-gui amd64 1:4.2-3ubuntu6.7 [40.8 kB] +Get:74 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 qemu-system-mips amd64 1:4.2-3ubuntu6.7 [12.9 MB] + + +Now the same novnc1.2 can connect to it \o/ +Setting verified + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.7 + +--------------- +qemu (1:4.2-3ubuntu6.7) focal; urgency=medium + + * d/p/ubuntu/lp-1882774-*: add newer EPYC processor types (LP: #1887490) + * d/p/u/lp-1896751-exec-rom_reset-Free-rom-data-during-inmigrate-skip.patch: + fix reboot after migration (LP: #1896751) + * d/p/u/lp-1849644-io-channel-websock-treat-binary-and-no-sub-protocol-.patch: + fix websocket compatibility with newer versions of noVNC (LP: #1849644) + + -- Christian Ehrhardt <email address hidden> Mon, 27 Jul 2020 11:45:26 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + diff --git a/results/classifier/105/network/1856834 b/results/classifier/105/network/1856834 new file mode 100644 index 00000000..7195c084 --- /dev/null +++ b/results/classifier/105/network/1856834 @@ -0,0 +1,213 @@ +network: 0.837 +boot: 0.743 +other: 0.730 +instruction: 0.705 +device: 0.701 +assembly: 0.682 +vnc: 0.646 +mistranslation: 0.645 +semantic: 0.636 +KVM: 0.552 +graphic: 0.540 +socket: 0.341 + +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/105/network/1857226 b/results/classifier/105/network/1857226 new file mode 100644 index 00000000..16843856 --- /dev/null +++ b/results/classifier/105/network/1857226 @@ -0,0 +1,48 @@ +network: 0.784 +device: 0.615 +semantic: 0.426 +graphic: 0.385 +other: 0.315 +socket: 0.314 +vnc: 0.260 +mistranslation: 0.207 +boot: 0.137 +instruction: 0.136 +assembly: 0.075 +KVM: 0.036 + +'set_link net0 off' not working with e1000e driver + +I'm encountering a bug with the e1000e network driver, that appears to got previously reported at rhbz. Steps to reproduce are provided in detail there: + +https://bugzilla.redhat.com/show_bug.cgi?id=1707646 + +It is about switching off network link state (set_link net0 off) having no effect when using the e1000e driver. + +Version details: +QEMU emulator version 4.1.1 (qemu-4.1.1-1.fc31) +Fedora 31 + +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. + + +Still reproducible on Fedora 34 with QEMU 5.2.0. + + +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/190 + + diff --git a/results/classifier/105/network/1861875 b/results/classifier/105/network/1861875 new file mode 100644 index 00000000..34c29fcc --- /dev/null +++ b/results/classifier/105/network/1861875 @@ -0,0 +1,48 @@ +network: 0.926 +device: 0.774 +graphic: 0.688 +other: 0.676 +mistranslation: 0.598 +vnc: 0.577 +semantic: 0.574 +instruction: 0.567 +socket: 0.563 +boot: 0.411 +assembly: 0.408 +KVM: 0.340 + +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/105/network/1862979 b/results/classifier/105/network/1862979 new file mode 100644 index 00000000..72762f91 --- /dev/null +++ b/results/classifier/105/network/1862979 @@ -0,0 +1,44 @@ +network: 0.850 +device: 0.846 +socket: 0.837 +graphic: 0.785 +vnc: 0.676 +other: 0.651 +semantic: 0.638 +instruction: 0.635 +mistranslation: 0.477 +boot: 0.343 +assembly: 0.319 +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/105/network/1874539 b/results/classifier/105/network/1874539 new file mode 100644 index 00000000..ab4a0ef7 --- /dev/null +++ b/results/classifier/105/network/1874539 @@ -0,0 +1,42 @@ +network: 0.869 +semantic: 0.824 +graphic: 0.620 +vnc: 0.611 +other: 0.588 +socket: 0.549 +mistranslation: 0.543 +device: 0.512 +instruction: 0.462 +boot: 0.440 +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/105/network/1874676 b/results/classifier/105/network/1874676 new file mode 100644 index 00000000..3c5fd7be --- /dev/null +++ b/results/classifier/105/network/1874676 @@ -0,0 +1,36 @@ +network: 0.818 +device: 0.741 +graphic: 0.639 +semantic: 0.500 +socket: 0.490 +vnc: 0.479 +other: 0.467 +mistranslation: 0.434 +instruction: 0.409 +boot: 0.288 +assembly: 0.227 +KVM: 0.186 + +[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/105/network/1876 b/results/classifier/105/network/1876 new file mode 100644 index 00000000..83140de7 --- /dev/null +++ b/results/classifier/105/network/1876 @@ -0,0 +1,14 @@ +network: 0.813 +device: 0.605 +mistranslation: 0.598 +semantic: 0.301 +graphic: 0.290 +other: 0.270 +instruction: 0.105 +vnc: 0.081 +boot: 0.077 +socket: 0.066 +assembly: 0.020 +KVM: 0.008 + +Host wayland gtk problem diff --git a/results/classifier/105/network/1876187 b/results/classifier/105/network/1876187 new file mode 100644 index 00000000..e8dc3d6b --- /dev/null +++ b/results/classifier/105/network/1876187 @@ -0,0 +1,27 @@ +network: 0.748 +device: 0.719 +mistranslation: 0.680 +vnc: 0.622 +instruction: 0.598 +socket: 0.582 +graphic: 0.568 +semantic: 0.451 +other: 0.357 +boot: 0.336 +assembly: 0.104 +KVM: 0.047 + +qemu-system-arm freezes when using SystickTimer on netduinoplus2 + +git commit 27c94566379069fb8930bb1433dcffbf7df3203d + +The global variable system_clock_scale used in hw/timer/armv7m_systick.c is never set on the netduinoplus2 platform, it stays initialized as zero. Using the timer with the clock source as cpu clock leads to an infinit loop because systick_timer->tick always stays the same. + +To reproduce use to CMSIS function SysTick_Config(uint32_t ticks) to setup the timer. + +Patch sent to list: https://<email address hidden>/ + + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e7e5a9595ab1136845c + diff --git a/results/classifier/105/network/1881 b/results/classifier/105/network/1881 new file mode 100644 index 00000000..744b5391 --- /dev/null +++ b/results/classifier/105/network/1881 @@ -0,0 +1,28 @@ +network: 0.981 +socket: 0.980 +graphic: 0.904 +device: 0.894 +instruction: 0.824 +vnc: 0.806 +semantic: 0.657 +mistranslation: 0.598 +boot: 0.517 +other: 0.401 +KVM: 0.215 +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/105/network/1883984 b/results/classifier/105/network/1883984 new file mode 100644 index 00000000..538cf691 --- /dev/null +++ b/results/classifier/105/network/1883984 @@ -0,0 +1,154 @@ +semantic: 0.931 +network: 0.925 +other: 0.924 +device: 0.915 +instruction: 0.906 +boot: 0.902 +graphic: 0.902 +vnc: 0.900 +assembly: 0.881 +KVM: 0.877 +mistranslation: 0.867 +socket: 0.826 + +QEMU S/390x sqxbr (128-bit IEEE 754 square root) crashes qemu-system-s390x + +In porting software to guest Ubuntu 18.04 and 20.04 VMs for S/390x, I discovered +that some of my own numerical programs, and also a GNU configure script for at +least one package with CC=clang, would cause an instant crash of the VM, sometimes +also destroying recently opened files, and producing long strings of NUL characters +in /var/log/syslog in the S/390 guest O/S. + +Further detective work narrowed the cause of the crash down to a single IBM S/390 +instruction: sqxbr (128-bit IEEE 754 square root). Here is a one-line program +that when compiled and run on a VM hosted on QEMUcc emulator version 4.2.0 +(Debian 1:4.2-3ubuntu6.1) [hosted on Ubuntu 20.04 on a Dell Precision 7920 +workstation with an Intel Xeon Platinum 8253 CPU], and also on QEMU emulator +version 5.0.0, reproducibly produces a VM crash under qemu-system-s390x. + +% cat bug-sqrtl-one-line.c +int main(void) { volatile long double x, r; x = 4.0L; __asm__ __volatile__("sqxbr %0, %1" : "=f" (r) : "f" (x)); return (0);} + +% cc bug-sqrtl-one-line.c && ./a.out +Segmentation fault (core dumped) + +The problem code may be the function float128_sqrt() defined in qemu-5.0.0/fpu/softfloat.c +starting at line 7619. I have NOT attempted to run the qemu-system-s390x executable +under a debugger. However, I observe that S/390 is the only CPU family that I know of, +except possibly for a Fujitsu SPARC-64, that has a 128-bit square root in hardware. +Thus, this instruction bug may not have been seen before. + +Another way to reproduce this bug is with qemu-s390x and a cross-compiled binary: + +$ s390x-linux-gnu-gcc-5 -static -o bug-sqrtl-one-line.s390x bug-sqrtl-one-line.c +$ qemu-s390x bug-sqrtl-one-line.s390x +Segmentation fault (core dumped) + +Find attached the binary. + +With --enable-debug, + +qemu-s390x: /home/rth/qemu/qemu/include/tcg/tcg.h:687: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. + +which turns out to be related to a null-pointer temporary. + +I confirm that the patch https://lists.gnu.org/archive/html/qemu-s390x/2020-06/msg00213.html fixes the issue, both for qemu-s390x and qemu-system-s390x. + +Thanks Richard! + +This bug was fixed in the package qemu - 1:5.0-5ubuntu4 + +--------------- +qemu (1:5.0-5ubuntu4) groovy; urgency=medium + + * xen: provide compat links to what libxen-dev reports where to find + the binaries (LP: #1890005) + * d/p/ubuntu/lp-1883984-target-s390x-Fix-SQXBR.patch: avoid crash on + SQXBR (LP: #1883984) + * d/p/lp-1890154-*: fix -no-reboot on s390x secure boot (LP: #1890154) + + -- Christian Ehrhardt <email address hidden> Mon, 03 Aug 2020 07:15:28 +0200 + +Note: final upstream commit link https://git.qemu.org/?p=qemu.git;a=commit;h=9bf728a09bf7509b27543664f9cca6f4f337f608 + +Hello Nelson, or anyone else affected, + +Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.5 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.5) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +ubuntu-image/1.9+20.04ubuntu1 (amd64) +systemd/245.4-4ubuntu3.2 (amd64, armhf, s390x, ppc64el) +livecd-rootfs/2.664.4 (amd64, arm64, s390x, ppc64el) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +old version +sudo apt install qemu-system-s390x=1:4.2-3ubuntu6.4 +...test as listed in the test instructions ... + +ubuntu@focal-sqxbr:~$ ./a.out +Segmentation fault +(qemu is dead at this point) + +$ sudo apt install qemu-system-s390x=1:4.2-3ubuntu6.5 +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following packages will be upgraded: + qemu-system-s390x +1 upgraded, 0 newly installed, 0 to remove and 315 not upgraded. +Need to get 2334 kB of archives. +After this operation, 4096 B of additional disk space will be used. +Get:1 http://ports.ubuntu.com focal-proposed/main s390x qemu-system-s390x s390x 1:4.2-3ubuntu6.5 [2334 kB] +Fetched 2334 kB in 1s (3927 kB/s) +(Reading database ... 203254 files and directories currently installed.) +Preparing to unpack .../qemu-system-s390x_1%3a4.2-3ubuntu6.5_s390x.deb ... +Unpacking qemu-system-s390x (1:4.2-3ubuntu6.5) over (1:4.2-3ubuntu6.4) ... +Setting up qemu-system-s390x (1:4.2-3ubuntu6.5) ... +Processing triggers for man-db (2.9.3-2) ... +ubuntu@s1lp05:~$ + +ubuntu@focal-sqxbr:~$ ./a.out +(no crash) + + +Setting verified + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.5 + +--------------- +qemu (1:4.2-3ubuntu6.5) focal; urgency=medium + + * further stabilize qemu by importing patches of qemu v4.2.1 + Fixes (LP: #1891203) and (LP: #1891877) + - d/p/stable/lp-1891877-* + - as part of the stabilization this also fixes an + riscv emulation issue due to the CVE-2020-13754 fixes via + d/p/ubuntu/hw-riscv-Allow-64-bit-access-to-SiFive-CLINT.patch + * fix s390x SQXBR emulation (LP: #1883984) + - d/p/ubuntu/lp-1883984-target-s390x-Fix-SQXBR.patch + * fix -no-reboot for s390x protvirt guests (LP: #1890154) + - d/p/ubuntu/lp-1890154-s390x-protvirt-allow-to-IPL-secure-guests-with-* + + -- Christian Ehrhardt <email address hidden> Wed, 19 Aug 2020 13:40:49 +0200 + diff --git a/results/classifier/105/network/1884169 b/results/classifier/105/network/1884169 new file mode 100644 index 00000000..ec605ac6 --- /dev/null +++ b/results/classifier/105/network/1884169 @@ -0,0 +1,31 @@ +network: 0.838 +device: 0.636 +semantic: 0.506 +mistranslation: 0.501 +graphic: 0.370 +other: 0.356 +instruction: 0.345 +KVM: 0.259 +vnc: 0.096 +boot: 0.063 +socket: 0.061 +assembly: 0.046 + +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/105/network/1884425 b/results/classifier/105/network/1884425 new file mode 100644 index 00000000..e290800f --- /dev/null +++ b/results/classifier/105/network/1884425 @@ -0,0 +1,55 @@ +network: 0.898 +graphic: 0.897 +vnc: 0.885 +other: 0.871 +instruction: 0.856 +device: 0.850 +boot: 0.832 +semantic: 0.747 +KVM: 0.739 +mistranslation: 0.736 +socket: 0.709 +assembly: 0.665 + +MIPS64EL emu hangs at reboot + +QEMU Release version: 5.0.50 (v5.0.0-1411-g26bf4a2921-dirty) + +Full command line: qemu-system-mips64el -hda nt4svr.qcow2 -M magnum -L . -global ds1225y.filename=nvram -global ds1225y.size=8200 -net nic -net user -cdrom en_winnt_4.0_svr.iso + +Host machine: Windows 10 1909 64-bit, QEMU running under WSL with the latest Kali distro and the latest Xming. + +Guest machine: MIPS64EL Magnum machine, no OS needs to be installed to reproduce - just change some stuff in the Setup program and try to exit + +Note: Custom ROM with Windows NT support used, NTPROM.RAW used from http://hpoussineau.free.fr/qemu/firmware/magnum-4000/setup.zip + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/network/1886793 b/results/classifier/105/network/1886793 new file mode 100644 index 00000000..7962d2cb --- /dev/null +++ b/results/classifier/105/network/1886793 @@ -0,0 +1,396 @@ +network: 0.294 +graphic: 0.290 +other: 0.242 +instruction: 0.220 +device: 0.217 +KVM: 0.217 +semantic: 0.190 +vnc: 0.188 +assembly: 0.172 +mistranslation: 0.165 +boot: 0.165 +socket: 0.147 + +"go install" command fails while running inside s390x docker container on x86_64 host using qemu + +Steps to reproduce the issue: + +Register x86_64 host with the latest qemu-user-static. +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + +Build the following Docker Image using following Dockerfile.s390x using command docker build -t test/crossbuild:latest-s390x -f Dockerfile.s390x . + +Dockerfile.s390x + +FROM alpine:3.11 as qemu + +ARG QEMU_VERSION=5.0.0-2 +ARG QEMU_ARCHS="s390x" + +RUN apk --update add curl + +#Enable non-native runs on amd64 architecture hosts +RUN for i in ${QEMU_ARCHS}; do curl -L https://github.com/multiarch/qemu-user-static/releases/download/v${QEMU_VERSION}/qemu-${i}-static.tar.gz | tar zxvf - -C /usr/bin; done +RUN chmod +x /usr/bin/qemu-* + +FROM s390x/golang:1.14.2-alpine3.11 +MAINTAINER LoZ Open Source Ecosystem (https://www.ibm.com/developerworks/community/groups/community/lozopensource) + +ARG MANIFEST_TOOL_VERSION=v1.0.2 + +#Enable non-native builds of this image on an amd64 hosts. +#This must be the first RUN command in this file! +COPY --from=qemu /usr/bin/qemu-*-static /usr/bin/ + +#Install su-exec for use in the entrypoint.sh (so processes run as the right user) +#Install bash for the entry script (and because it's generally useful) +#Install curl to download glide +#Install git for fetching Go dependencies +#Install ssh for fetching Go dependencies +#Install mercurial for fetching go dependencies +#Install wget since it's useful for fetching +#Install make for building things +#Install util-linux for column command (used for output formatting). +#Install grep and sed for use in some Makefiles (e.g. pulling versions out of glide.yaml) +#Install shadow for useradd (it allows to use big UID) +RUN apk update && apk add --no-cache su-exec curl bash git openssh mercurial make wget util-linux tini file grep sed shadow +RUN apk upgrade --no-cache + +#Disable ssh host key checking +RUN echo 'Host *' >> /etc/ssh/ssh_config \ + && echo ' StrictHostKeyChecking no' >> /etc/ssh/ssh_config + +#Disable cgo so that binaries we build will be fully static. +ENV CGO_ENABLED=0 + +#Recompile the standard library with cgo disabled. This prevents the standard library from being +#marked stale, causing full rebuilds every time. +RUN go install -v std + +#Install glide +RUN go get github.com/Masterminds/glide +ENV GLIDE_HOME /home/user/.glide + +#Install dep +RUN go get github.com/golang/dep/cmd/dep + +#Install ginkgo CLI tool for running tests +RUN go get github.com/onsi/ginkgo/ginkgo + +#Install linting tools. +RUN wget -O - -q https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | sh -s v1.20.0 +RUN golangci-lint --version + +#Install license checking tool. +RUN go get github.com/pmezard/licenses + +#Install tool to merge coverage reports. +RUN go get github.com/wadey/gocovmerge + +#Install CLI tool for working with yaml files +RUN go get github.com/mikefarah/yaml + +#Delete all the Go sources that were downloaded, we only rely on the binaries +RUN rm -rf /go/src/* + +#Install vgo (should be removed once we take Go 1.11) +RUN go get -u golang.org/x/vgo + +#Ensure that everything under the GOPATH is writable by everyone +RUN chmod -R 777 $GOPATH + +RUN curl -sSL https://github.com/estesp/manifest-tool/releases/download/${MANIFEST_TOOL_VERSION}/manifest-tool-linux-s390x > manifest-tool && \ + chmod +x manifest-tool && \ + mv manifest-tool /usr/bin/ + +COPY entrypoint.sh /usr/local/bin/entrypoint.sh +ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/entrypoint.sh"] + + + + +The build just hangs at RUN go install -v std + + + +Also, while running the same command inside s390x container on x86_64 host, error Illegal instruction (core dumped) is thrown. +Register x86_64 host with the latest qemu-user-static. +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + +docker run -it -v /home/test/qemu-s390x-static:/usr/bin/qemu-s390x-static s390x/golang:1.14.2-alpine3.11 + +Inside s390x container: + +apk update && apk add --no-cache su-exec curl bash git openssh mercurial make wget util-linux tini file grep sed shadow +apk upgrade --no-cache + +#Disable ssh host key checking +echo 'Host *' >> /etc/ssh/ssh_config +echo ' StrictHostKeyChecking no' >> /etc/ssh/ssh_config + +#Disable cgo so that binaries we build will be fully static. +export CGO_ENABLED=0 + +#Recompile the standard library with cgo disabled. This prevents the standard library from being +#marked stale, causing full rebuilds every time. +go install -v std +Describe the results you re +This gives the following error: +Illegal instruction (core dumped) + + + +Environment: +x86_64 Ub18.04 4.15.0-101-generic Ubuntu SMP x86_64 GNU/Linux + +QEMU user static version: 5.0.0-2 + +Container application: Docker + +Client: Docker Engine - Community + Version: 19.03.11 + API version: 1.40 + Go version: go1.13.10 + Git commit: 42e35e61f3 + Built: Mon Jun 1 09:12:22 2020 + OS/Arch: linux/amd64 + Experimental: false + +Server: Docker Engine - Community + Engine: + Version: 19.03.11 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.10 + Git commit: 42e35e61f3 + Built: Mon Jun 1 09:10:54 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.2.13 + GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 + runc: + Version: 1.0.0-rc10 + GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd + docker-init: + Version: 0.18.0 + GitCommit: fec3683 + +Additional information optionally: +When I build the same Dockerfile.s390x on an s390x machine, it is built successfully. + +One more thing which I tried: +I installed qemu on x86 Ubuntu host with apt-get install. +Extracted s390x go 1.14.2 binaries on the same. Ran the following commands: + +root:~ wget -q https://storage.googleapis.com/golang/go1.14.2.linux-s390x.tar.gz +root@:~# chmod ugo+r go1.14.2.linux-s390x.tar.gz +root@:~# rm -rf /usr/local/go /usr/bin/go +root@:~# tar -C /usr/local -xzf go1.14.2.linux-s390x.tar.gz +root@:~# ln -sf /usr/local/go/bin/go /usr/bin/ +root@:~# ln -sf /usr/local/go/bin/gofmt /usr/bin/ +root@:~# ln -sf /usr/bin/gcc /usr/bin/s390x-linux-gnu-gcc +root@:~# go version +/lib/ld64.so.1: No such file or directory +root@:~# qemu-s390x /usr/bin/go version +/lib/ld64.so.1: No such file or directory + +Could you try to reproduce the problem with the latest version of QEMU from git repo? + +Cloned qemu source code, checked out latest tag v5.0.0, built and installed the same on x86 Ubuntu host using "make" and "make install". + +root:~# qemu-s390x --version +qemu-s390x version 5.0.0 (v5.0.0-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + +root:~# wget -q https://storage.googleapis.com/golang/go1.14.2.linux-s390x.tar.gz +root:~# chmod ugo+r go1.14.2.linux-s390x.tar.gz +root:~# rm -rf /usr/local/go /usr/bin/go +root:~# tar -C /usr/local -xzf go1.14.2.linux-s390x.tar.gz +root:~# ln -sf /usr/local/go/bin/go /usr/bin/ +root:~# ln -sf /usr/local/go/bin/gofmt /usr/bin/ +root:~# ln -sf /usr/bin/gcc /usr/bin/s390x-linux-gnu-gcc +root:~# go version +-bash: /usr/bin/go: cannot execute binary file: Exec format error +root:~# qemu-s390x /usr/bin/go version +/lib/ld64.so.1: No such file or directory + + +If you install go directly in your host system you must also install the libraries of s390x somewhere (except if it statically linked). + +The easiest way to test this is to install debian chroot, with something like: + +Check binftm_misc is configured: + +# cat /proc/sys/fs/binfmt_misc/qemu-s390x +enabled +interpreter //qemu-s390x +flags: OC +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff + +Then you can install a debian sid system into a directory: + +# debootstrap --arch=s390x --foreign sid chroot-s390x/ +# cp .../qemu-s390x chroot-s390x/ +# sudo chroot chroot-s390x/ /debootstrap/debootstrap --second-stage + +And then you can use it with: + +# sudo chroot s390x-chroot/ +# uname -m +s390x +# apt install golang-go +... + +I will try the same and will report here soon. + +What about the issue with getting a go s390x environment inside and s390x container running on x86 host using qemu-user-static? (This problem is also mentioned in the main issue above. This is the ultimate target which needs to be achieved, I want to be able to build an s390x docker image with go installations inside on an x86 host, rest of the stuff I did for debugging purposes only) + +I ran the following commands: + +#apt install debootstrap +#debootstrap_dir=debootstrap +#debootstrap --arch=s390x --foreign sid "$debootstrap_dir" +#sudo mkdir -p "${debootstrap_dir}/usr/bin" +#sudo cp "$(which qemu-s390x-static)" "${debootstrap_dir}/usr/bin" +#sudo cp "$(which qemu-s390x)" "${debootstrap_dir}/usr/bin" + +All commands above were successful except below one: + +#sudo chroot "$debootstrap_dir" /debootstrap/debootstrap --second-stage +Gave following error: +W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.47_s390x.deb +W: See //debootstrap/debootstrap.log for details (possibly the package libgcc1 is at fault) + +Anyway, I proceeded: +# uname -m +s390x + +# apt install golang-go +Reading package lists... Done +Building dependency tree... Done +You might want to run 'apt --fix-broken install' to correct these. +The following packages have unmet dependencies: + dpkg : Conflicts: dpkg:none + dpkg:none : Conflicts: dpkg but 1.20.5 is to be installed + golang-go : Depends: golang-1.14-go but it is not going to be installed + Depends: golang-src (>= 2:1.14~2) but it is not going to be installed + libgcc1 : Depends: gcc-10-base (= 10.1.0-1) but 10.1.0-6+b1 is to be installed +E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). + +# apt --fix-broken install +Reading package lists... Done +Building dependency tree... Done +Correcting dependencies... Done +The following packages will be REMOVED: + dpkg:none libgcc1 +0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. +1 not fully installed or removed. +After this operation, 85.0 kB disk space will be freed. +Do you want to continue? [Y/n] y +perl: warning: Setting locale failed. +perl: warning: Please check that your locale settings: + LANGUAGE = (unset), + LC_ALL = (unset), + LANG = "en_US.UTF-8" + are supported and installed on your system. +perl: warning: Falling back to the standard locale ("C"). +/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory +/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory +/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory +dpkg: error: parsing file '/var/lib/dpkg/status' near line 3918 package 'dpkg': + duplicate value for 'Package' field +E: Sub-process dpkg --set-selections returned an error code (2) +E: Couldn't record the approved state changes as dpkg selection states + + + +Any update on this? +I tried the latest version of qemu-user-static, it still fails with the same error. + +Le 23/11/2020 à 12:03, Nirman Narang a écrit : +> Any update on this? +> I tried the latest version of qemu-user-static, it still fails with the same error. +> + +It works fine for me. Perhaps your chroot has been corrupted by your +previous attempts + + +Let me try again using the following commands on a fresh x86 host. + +#apt install debootstrap +#debootstrap_dir=debootstrap +#debootstrap --arch=s390x --foreign sid "$debootstrap_dir" +#sudo mkdir -p "${debootstrap_dir}/usr/bin" +#sudo cp "$(which qemu-s390x-static)" "${debootstrap_dir}/usr/bin" +#sudo cp "$(which qemu-s390x)" "${debootstrap_dir}/usr/bin"#sudo chroot "$debootstrap_dir" /debootstrap/debootstrap --second-stage + +Here is the output of the steps I tried: + +root@11:~# cat /proc/sys/fs/binfmt_misc/qemu-s390x +enabled +interpreter /usr/bin/qemu-s390x-static +flags: F +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff + + +debootstrap --arch=s390x --foreign sid chroot-s390x_dir + +cp -f /usr/bin/qemu-s390x-static /root/chroot-s390x_dir/usr/bin/ + +chmod +x /root/chroot-s390x_dir/usr/bin/qemu-s390x-static + +chroot chroot-s390x_dir /debootstrap/debootstrap --second-stage --verbose + +chroot chroot-s390x_dir/ + + +root@11:/# uname -a +Linux 4.15.0-123-generic #126-Ubuntu SMP Wed Oct 21 09:40:11 UTC 2020 s390x GNU/Linux + +Then tried to install the golang version mentioned below: +golang | 2:1.15~1 | http://deb.debian.org/debian sid/main s390x Packages + + +root@11:/# go version +Illegal instruction (core dumped) + +root@11:/# go version -v +Segmentation fault (core dumped) + +The error is the same as the one faced while implementing the s390x container using qemu-user-static on x86 machine with go install commands as mentioned in the main issue above. + +Any update on this? +Tried on fresh env, Illegal instruction (core dumped), and Segmentation fault (core dumped) errors are still thrown with go commands. + +Which qemu version do you end up using? "/usr/bin/qemu-s390x-static" *usually* refers to the one provided by your distro, not your custom build. + +FWIW, I just installed go under Fedora 32 (which uses a slightly older version of go): + +[root@atomic-00 ~]# uname -a +Linux atomic-00 5.8.11-200.fc32.s390x #1 SMP Wed Sep 23 13:36:15 UTC 2020 s390x s390x s390x GNU/Linux + +[root@atomic-00 ~]# go version +go version go1.14.13 linux/s390x +[root@atomic-00 ~]# go version -v +go version go1.14.13 linux/s390x + + +As Laurent also cannot reproduce, maybe double check the QEMU you end up using is the right one? + +Using latest greatest go from https://golang.org/dl/ + +[root@atomic-00 hello]# /usr/local/go/bin/go version +go version go1.15.7 linux/s390x + + +I used the command "docker run --rm --privileged multiarch/qemu-user-static --reset -p yes". +This pulls the latest one automatically. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/network/1894781 b/results/classifier/105/network/1894781 new file mode 100644 index 00000000..ff686d44 --- /dev/null +++ b/results/classifier/105/network/1894781 @@ -0,0 +1,142 @@ +semantic: 0.953 +assembly: 0.947 +instruction: 0.946 +network: 0.938 +other: 0.938 +graphic: 0.927 +device: 0.922 +boot: 0.907 +socket: 0.819 +KVM: 0.766 +vnc: 0.705 +mistranslation: 0.673 + +[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation) + +(following from https://gitlab.com/libvirt/libvirt/-/issues/68#note_400960567) + +As is very well explained in https://www.berrange.com/posts/2016/04/05/improving-qemu-security-part-5-tls-support-for-nbd-server-client/, and easily confirmed with captures, NBD stream starts in cleartext and upgrades to TLS inline (similar to STARTTLS mechanism). As a rationale, it is stated that this provides better error messages for the user of NBD. + +However, this approach has downsides: + +1) Clear indication to a network observer that NBD (and therefore likely qemu/libvirt) is used. In contrast, TLS1.3 hides even the SNI of the servers (ESNI, https://blog.cloudflare.com/encrypted-sni/). +2) Potential for bugs in NBD protocol negotiation code. That code just statistically, likely less looked at code than gnutls. This is not a reflection on NBD code quality, just the fact that TLS code does receive a bit more scrutiny. +3) Inability to inspect TLS listener interface for compliance, e.g. with a security scanner. Making sure TLS listeners only select certain ciphersuits is a requirement of some compliance regimes. + +I think it's fully possible to satisfy the original requirement of good error messages as well, detecting that the other end is initiating TLS connection. + +It's very unlikely that it's currently sae to recommend to run QEMU migration stream over a hostile network, but it should be possible to do with TLS only option. + +Solution to this, just like in the case of SMTP, is to provide TLS only option (no initial cleartext at all) for QEMU migration, which hopefully it not a large addition. + +Thank you for your consideration! + +On 9/7/20 11:00 PM, Vjaceslavs Klimovs wrote: +> Public bug reported: +> +> (following from +> https://gitlab.com/libvirt/libvirt/-/issues/68#note_400960567) +> +> As is very well explained in https://www.berrange.com/posts/2016/04/05 +> /improving-qemu-security-part-5-tls-support-for-nbd-server-client/, and +> easily confirmed with captures, NBD stream starts in cleartext and +> upgrades to TLS inline (similar to STARTTLS mechanism). As a rationale, +> it is stated that this provides better error messages for the user of +> NBD. +> +> However, this approach has downsides: +> +> 1) Clear indication to a network observer that NBD (and therefore likely qemu/libvirt) is used. + +qemu/libvirt is not the only client of NBD. In fact, the nbdkit and +libnbd projects exist to make it easier to utilize NBD from more places. + +> In contrast, TLS1.3 hides even the SNI of the servers (ESNI, https://blog.cloudflare.com/encrypted-sni/). +> 2) Potential for bugs in NBD protocol negotiation code. That code just statistically, likely less looked at code than gnutls. This is not a reflection on NBD code quality, just the fact that TLS code does receive a bit more scrutiny. + +This is a non-argument. When configured correctly at the NBD server, +the NBD_OPT_STARTTLS option is the _only_ option accepted by a client, +at which point you are right back into TLS code (from gnutls or +elsewhere) and using the existing TLS libraries to establish the +connection - but that is the SAME thing you would have to do even if +there were a way to connect to an NBD server that doesn't even start +with plaintext handshaking. + +> 3) Inability to inspect TLS listener interface for compliance, e.g. with a security scanner. Making sure TLS listeners only select certain ciphersuits is a requirement of some compliance regimes. +> +> I think it's fully possible to satisfy the original requirement of good +> error messages as well, detecting that the other end is initiating TLS +> connection. + +If you are going to make a change in this area, it will need to be +agreed on in the upstream NBD list, where _all_ implementations of NBD +(both client and server) can weigh in; qemu will not change in a vacuum +without upstream protocol concurrence. + +https://lists.debian.org/nbd/ + +> +> It's very unlikely that it's currently sae to recommend to run QEMU +> migration stream over a hostile network, but it should be possible to do +> with TLS only option. + +It is very easy to write both servers and clients that require a +transition from plaintext into TLS before any serious traffic is sent. + +> +> Solution to this, just like in the case of SMTP, is to provide TLS only +> option (no initial cleartext at all) for QEMU migration, which hopefully +> it not a large addition. +> +> Thank you for your consideration! +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +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/282 + + diff --git a/results/classifier/105/network/190 b/results/classifier/105/network/190 new file mode 100644 index 00000000..367adfd1 --- /dev/null +++ b/results/classifier/105/network/190 @@ -0,0 +1,14 @@ +network: 0.942 +device: 0.914 +mistranslation: 0.813 +socket: 0.683 +semantic: 0.637 +graphic: 0.525 +instruction: 0.507 +other: 0.483 +vnc: 0.346 +boot: 0.155 +assembly: 0.053 +KVM: 0.019 + +'set_link net0 off' not working with e1000e driver diff --git a/results/classifier/105/network/1903470 b/results/classifier/105/network/1903470 new file mode 100644 index 00000000..df87b799 --- /dev/null +++ b/results/classifier/105/network/1903470 @@ -0,0 +1,65 @@ +network: 0.632 +socket: 0.506 +device: 0.429 +semantic: 0.333 +instruction: 0.300 +graphic: 0.296 +boot: 0.293 +vnc: 0.243 +mistranslation: 0.212 +other: 0.204 +assembly: 0.150 +KVM: 0.131 + +qemu 5.1.0: Add UNIX socket support for netdev socket + +qemu has a way to connect instances using a socket: + +-netdev socket,id=str[,fd=h][,listen=[host]:port][,connect=host:port] + +This can also be used to connect a qemu instance to something else using a socket connection, however there is no authentication or security to the connection, so rather than using a port which can be accessed by any user on the machine, having the ability to use or connect to UNIX sockets would be helpful, and adding this option should be fairly trivial. + +UNIX sockets can be found in various parts of qemu (monitor, etc) so I believe having this on network would make sense. + +With the fd= argument/property, you can setup a private socketpair connection already. Is this enough? + +Thanks for the response. I'm not sure, how would I run qemu with a fd= socketpair on the command line? + +The wiki (https://wiki.qemu.org/index.php/Documentation/Networking) suggests for example to use: + +-netdev socket,id=mynet0,listen=:1234 +-netdev socket,id=mynet0,connect=:1234 + +This would allow however anyone on the same network (or in the world if run on a server) to connect to this network and possibly do bad things. Using localhost binding helps but is still risky if there is more than one user on a given machine. Using something like: + +-netdev socket,id=mynet0,listen=~/.qemu-netsocket +-netdev socket,id=mynet0,connect=~/.qemu-netsocket + +How would one do that with fd= ? + +[Expired for QEMU because there has been no activity for 60 days.] + +JFYI I miss the ability to use Unix socket right now.. I'm trying to use vagrant + vagrant-qemu + socket_vmnet on Macbook m1. It'd be MUCH easier to connect QEMU to the socket_vmnet' Unix socket directly w/o any wrappers.. + +This will be available in the next QEMU release (7.2) under a sligthly different form: + +"-netdev stream" for TCP socket and "-netdev dgram" for UDP socket. + +Both support inet and unix sockets. See qemu(1). + +This was added to support passt: + +https://passt.top + +Despite what is said in an earlier comment, qemu(1) has no information on -netdev stream or -netdev dgram. + +The best help I could find comes from the patch description: + +https://<email address hidden>/ + +Example use: + +-netdev stream,id=socket0,server=off,addr.type=unix,addr.path=/tmp/qemu0 + +Also useful to note that the reconnect argument is only going to be available in qemu 8.0.0 (not released yet) + diff --git a/results/classifier/105/network/1904954 b/results/classifier/105/network/1904954 new file mode 100644 index 00000000..a537ceab --- /dev/null +++ b/results/classifier/105/network/1904954 @@ -0,0 +1,53 @@ +network: 0.849 +socket: 0.785 +mistranslation: 0.751 +device: 0.672 +instruction: 0.666 +other: 0.604 +graphic: 0.561 +semantic: 0.531 +vnc: 0.511 +boot: 0.407 +assembly: 0.233 +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/105/network/1912059 b/results/classifier/105/network/1912059 new file mode 100644 index 00000000..195d7c32 --- /dev/null +++ b/results/classifier/105/network/1912059 @@ -0,0 +1,65 @@ +network: 0.611 +mistranslation: 0.542 +vnc: 0.539 +other: 0.509 +semantic: 0.490 +assembly: 0.456 +device: 0.445 +socket: 0.436 +instruction: 0.427 +graphic: 0.407 +boot: 0.367 +KVM: 0.290 + +capstone link failure building linux-user static + +$ ../configure --disable-system --static + +qemu 5.2.50 + + static build: YES + capstone: system +[...] + +$ make qemu-i386 +[...] +[478/478] Linking target qemu-i386 +FAILED: qemu-i386 +cc -o qemu-i386 libcommon.fa.p/hw_core_cpu.c.o libcommon.fa.p/disas_capstone.c.o libcommon.fa.p/disas_i386.c.o ... -Wl,--as-needed -Wl,--no-undefined -Wl,--whole-archive libhwcore.fa libqom.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -static -m64 -fstack-protector-strong -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libhwcore.fa libqom.fa -lcapstone -lrt -pthread -lutil -lm -lgthread-2.0 -lglib-2.0 -lpcre -lgthread-2.0 -lglib-2.0 -lpcre -Wl,--end-group +/usr/bin/ld: cannot find -lcapstone +collect2: error: ld returned 1 exit status +ninja: build stopped: subcommand failed. +make: *** [Makefile:172: run-ninja] Error 1 + +$ rpm -ql capstone-devel +/usr/include/capstone +/usr/include/capstone/arm.h +/usr/include/capstone/arm64.h +/usr/include/capstone/capstone.h +/usr/include/capstone/evm.h +/usr/include/capstone/m680x.h +/usr/include/capstone/m68k.h +/usr/include/capstone/mips.h +/usr/include/capstone/platform.h +/usr/include/capstone/ppc.h +/usr/include/capstone/sparc.h +/usr/include/capstone/systemz.h +/usr/include/capstone/tms320c64x.h +/usr/include/capstone/x86.h +/usr/include/capstone/xcore.h +/usr/lib64/libcapstone.so +/usr/lib64/pkgconfig/capstone.pc + +libcapstone.a seems detected by Meson but is not installed on the system (Fedora 32). + +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. + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/238 + + diff --git a/results/classifier/105/network/1913012 b/results/classifier/105/network/1913012 new file mode 100644 index 00000000..dcc59f6c --- /dev/null +++ b/results/classifier/105/network/1913012 @@ -0,0 +1,175 @@ +network: 0.963 +device: 0.955 +boot: 0.953 +instruction: 0.951 +other: 0.950 +assembly: 0.940 +KVM: 0.938 +semantic: 0.938 +graphic: 0.930 +socket: 0.927 +vnc: 0.906 +mistranslation: 0.740 + +Installed firmware descriptor files contain (invalid) relative paths + +Unless the Qemu build is configured using `./configure --datadir=<path> where <path> is some absolute path which is a subdirectory of <prefix>, the resulting installed firmware descriptor files contain relative paths for their `mapping.filename` properties. These relative paths will not be accepted as valid by tools like `virt-install`, resulting in the inability to configure new VMs using these firmware descriptors. + +# QEMU version +$ qemu-system-x86_64 -version +QEMU emulator version 5.2.0 + +(I've also reproduced the issue with QEMU built from Git master @ v5.2.0-1300-g0e32462630, see next comment.) + +# OS version +Void Linux x86_64 (glibc) + +Steps to reproduce (with results on my system): + +# Verify the symptom + +$ virt-install --boot firmware=efi --disk none --memory 2048 +Using default --name vm4 +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +Starting install... +ERROR Failed to open file 'share/qemu/edk2-i386-vars.fd': No such file or directory +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///session start vm4 +otherwise, please restart your installation. + +# Verify most likely cause + +$ grep filename /usr/share/qemu/firmware/*i386*.json +/usr/share/qemu/firmware/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-secure-code.fd", +/usr/share/qemu/firmware/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-vars.fd", +/usr/share/qemu/firmware/60-edk2-i386.json: "filename": "share/qemu/edk2-i386-code.fd", +/usr/share/qemu/firmware/60-edk2-i386.json: "filename": "share/qemu/edk2-i386-vars.fd", + +There is an issue on Void Linux packages issue tracker about this bug[1] + +# Steps to verify the issue on a fresh Git clone of QEMU source + +$ git clone https://github.com/qemu/qemu +$ cd qemu +$ make DEBUG=1 docker-test-misc@alpine +[...] + COPY RUNNER + RUN test-misc in qemu/alpine +* Prepared to run command: + ./test-misc +* Hit Ctrl-D to continue, or type 'exit 1' to abort + +bash-5.1$ . common-rc +[...] +bash-5.1$ configure_qemu --disable-system --disable-user +Configure options: +--enable-werror --prefix=/tmp/qemu-test/install --disable-system --disable-user +cross containers no +The Meson build system +Version: 0.56.2 +Source dir: /tmp/qemu-test/src +Build dir: /tmp/qemu-test/src/tests/docker +Build type: native build +Project name: qemu +Project version: 5.2.50 +[...] +bash-5.1$ grep filename pc-bios/descriptors/* +pc-bios/descriptors/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-secure-code.fd", +pc-bios/descriptors/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-vars.fd", +[...all other matches have relative paths...] +bash-5.1$ exit 1 +[...] + +# Research + +The filename path substitution appears to be done in the file `pc-bios/descriptors/meson.build`. +In particular, occurrences of `@DATADIR@` in the template files get substituted using the value of `qemu_datadir`: + + configure_file(input: files(f), + output: f, + configuration: {'DATADIR': qemu_datadir}, + install: get_option('install_blobs'), + install_dir: qemu_datadir / 'firmware') + +The variable `qemu_datadir` gets initialized from toplevel `meson.build` file using: + + qemu_datadir = get_option('datadir') / get_option('qemu_suffix') + +From the Meson documentation on built-in (build) options[2], `datadir` option gets initialized to `"share"` (note: a relative path!) by default, unless `datadir` build option is configured explicitly, so the value of `qemu_datadir`, as well as the substitution made ends up being a relative path as well. + +I found a commit which I think is relevant to why this choice was made[3]. + +# Test a workaround, try #1: specify `datadir` manually + +$ make DEBUG=1 docker-test-misc@alpine +[...] +bash-5.1$ configure_qemu --datadir=/usr/share --disable-system --disable-user +Configure options: +--enable-werror --prefix=/tmp/qemu-test/install --datadir=/usr/share --disable-system --disable-user +cross containers no +The Meson build system +Version: 0.56.2 +Source dir: /tmp/qemu-test/src +Build dir: /tmp/qemu-test/src/tests/docker +Build type: native build + +../../meson.build:1:0: ERROR: The value of the 'datadir' option is '/usr/share' which must be a subdir of the prefix '/tmp/qemu-test/install'. +Note that if you pass a relative path, it is assumed to be a subdir of prefix. + +A full log can be found at /tmp/qemu-test/src/tests/docker/meson-logs/meson-log.txt + +ERROR: meson setup failed + +Ah! So perhaps `datadir` can be an absolute path, but then it must be a subdir of the (already specified) `prefix`. +Let's try again. + +# Test a workaround, try #2: specify `datadir` as subdir of <prefix> manually + +$ make DEBUG=1 docker-test-misc@alpine +[...] +bash-5.1$ configure_qemu --datadir=/tmp/qemu-test/install/share --disable-system --disable-user +Configure options: +--enable-werror --prefix=/tmp/qemu-test/install --datadir=/tmp/qemu-test/install/share --disable-system --disable-user +[...] +bash-5.1$ grep filename pc-bios/descriptors/* +pc-bios/descriptors/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-secure-code.fd", +pc-bios/descriptors/50-edk2-i386-secure.json: "filename": "share/qemu/edk2-i386-vars.fd", +bash-5.1$ exit 1 + +Getting there, but the paths are still relative, missing the initial `/`. + +[1]: https://github.com/void-linux/void-packages/issues/27965 +[2]: https://mesonbuild.com/Builtin-options.html +[3]: https://github.com/qemu/qemu/commit/ab4c0996f80d43d1fc28c6e76f4ecb27423a7e29 + + + +I think this needs to be fixed in QEMU source. The `configure_file()` action needs both an absolute path for `configuration` (to substitute into the descriptor files) _and_ a relative path for use with the `install_dir` keyword argument. + +Please disregard the `# Test a coworkaround` stuff in comment #1, bad copypasta, too late at night ;-) + +Gentoo also noticed the bug: https://bugs.gentoo.org/766743 + +Jannik Glückert proposed a fix: + +``` +--- a/pc-bios/descriptors/meson.build ++++ b/pc-bios/descriptors/meson.build +@@ -8,7 +8,7 @@ foreach f: [ + ] + configure_file(input: files(f), + output: f, +- configuration: {'DATADIR': qemu_datadir}, ++ configuration: {'DATADIR': get_option('prefix') / qemu_datadir}, + install: get_option('install_blobs'), + install_dir: qemu_datadir / 'firmware') + endforeach +``` + + + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/4b956a399969c0c497a + diff --git a/results/classifier/105/network/1957 b/results/classifier/105/network/1957 new file mode 100644 index 00000000..ff409564 --- /dev/null +++ b/results/classifier/105/network/1957 @@ -0,0 +1,33 @@ +network: 0.804 +graphic: 0.797 +device: 0.712 +boot: 0.689 +instruction: 0.610 +semantic: 0.582 +other: 0.539 +vnc: 0.530 +socket: 0.510 +mistranslation: 0.350 +assembly: 0.305 +KVM: 0.245 + +Reading files failed from QEMU TFTP server +Description of problem: +QEMU TFTP server on Linux is sensitive to the filename delimiters: + +After building QEMU UEFI firmware with the entire NetworkPkg stack and booting to UEFI shell, one can use `tftp` command to read files from the QEMU TFTP server specified during QEMU launching. i.e. `tftp 10.0.2.2 Boot\BCD`. However, when setting up the TFTP folder to be exactly the same (Linux and Windows), the result for running this command is different. On Windows host, this tftp command from emulated UEFI shell will proceed properly. But on Linux host, this will fail with "File Not Found". + +The issue seems to be around the slirp engine used by QEMU: the received packet will hand off to slirp as is, which leads to a host specific libc implementation of "open" function call: https://git.launchpad.net/ubuntu/+source/libslirp/tree/src/tftp.c#n113. Thus the server result would be different when the host is different. + +This will cause the PXE boot to fail when setting up the PXE folder on through QEMU on Linux because Windows will attempt to read BCD file at the same directory of the initial boot file, with a `\` in between. + +As TFTP protocol seems to be folder agnostic (just file names), in this case, should the TFTP server (QEMU here) handle the path normalization to make sure the file lookup to go through? Otherwise, Windows PXE boot on QEMU Linux host will always fail. + +Any suggestion here? Thanks in advance! +Steps to reproduce: +1. Build OVMF UEFI with full network stack +2. Launch QEMU with the built UEFI with nic enabled, boot to UEFI shell. +3. Invoke `tftp 10.0.2.2 Boot\BCD` from UEFI shell. +4. When performing step 1-3 on Windows, this will succeed. But on Linux, this will fail with "File Not Found" +Additional information: +Attached is a wireshark dump from QEMU on Linux host. The same command sequence will all be successful on Windows host. diff --git a/results/classifier/105/network/198 b/results/classifier/105/network/198 new file mode 100644 index 00000000..57a55fbb --- /dev/null +++ b/results/classifier/105/network/198 @@ -0,0 +1,14 @@ +network: 0.930 +device: 0.906 +graphic: 0.448 +other: 0.423 +semantic: 0.366 +mistranslation: 0.365 +instruction: 0.296 +boot: 0.208 +KVM: 0.096 +vnc: 0.051 +assembly: 0.027 +socket: 0.023 + +USB Ethernet device (RNDIS) does not work on several tested operating systems diff --git a/results/classifier/105/network/199 b/results/classifier/105/network/199 new file mode 100644 index 00000000..373b36fa --- /dev/null +++ b/results/classifier/105/network/199 @@ -0,0 +1,14 @@ +network: 0.574 +device: 0.523 +instruction: 0.485 +socket: 0.419 +boot: 0.399 +semantic: 0.326 +graphic: 0.180 +vnc: 0.172 +mistranslation: 0.115 +other: 0.075 +assembly: 0.020 +KVM: 0.019 + +Convert QAPI to static types diff --git a/results/classifier/105/network/2009 b/results/classifier/105/network/2009 new file mode 100644 index 00000000..a1b96ebd --- /dev/null +++ b/results/classifier/105/network/2009 @@ -0,0 +1,14 @@ +network: 0.758 +device: 0.757 +other: 0.663 +socket: 0.592 +instruction: 0.578 +mistranslation: 0.525 +boot: 0.461 +vnc: 0.400 +assembly: 0.365 +semantic: 0.307 +graphic: 0.305 +KVM: 0.264 + +ld: warning: -undefined error is deprecated diff --git a/results/classifier/105/network/2017 b/results/classifier/105/network/2017 new file mode 100644 index 00000000..b000cff4 --- /dev/null +++ b/results/classifier/105/network/2017 @@ -0,0 +1,30 @@ +network: 0.766 +device: 0.757 +boot: 0.718 +graphic: 0.717 +socket: 0.485 +semantic: 0.427 +instruction: 0.420 +vnc: 0.263 +other: 0.188 +mistranslation: 0.183 +assembly: 0.074 +KVM: 0.031 + +Qemu 8.1-8.2 Sparc Now Timeout Boot Failing with Sun Bios +Description of problem: +Boot with original Sun bios never reaches the ok prompt. You get a series of ongoing network boot attempts with the message "Timeout waiting for ARP/RARP package." + +On earlier versions of Qemu up to and including 8.0, you could use the original firmware in the combinations below on Sparc model SS-5 and SS-20 machines. + +Note: Model SS-5 needs the cpu set to "TI MicroSparc II" or "TI MicroSparc IIep." Model SS-20 needs the cpu set to "TI SuperSparc 50" or "TI SuperSparc 60." +Steps to reproduce: +1. Use Qemu 8.1, 8.2, or current +2. Run above command line using original sun bios +3. See result below + + +Additional information: +Glad to test further and give checksums in bios files if needed. Have real hardware for the Sparcstation 5. Default lance card on qemu is active with usermode networking. + +Sun bios helps for booting some older versions of Solaris and is generally nice to have for testing. diff --git a/results/classifier/105/network/2019 b/results/classifier/105/network/2019 new file mode 100644 index 00000000..1b40bc8d --- /dev/null +++ b/results/classifier/105/network/2019 @@ -0,0 +1,39 @@ +network: 0.953 +socket: 0.884 +boot: 0.784 +instruction: 0.767 +graphic: 0.702 +other: 0.563 +device: 0.554 +semantic: 0.513 +assembly: 0.335 +mistranslation: 0.274 +vnc: 0.230 +KVM: 0.209 + +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/105/network/2023 b/results/classifier/105/network/2023 new file mode 100644 index 00000000..5d85bbfd --- /dev/null +++ b/results/classifier/105/network/2023 @@ -0,0 +1,14 @@ +network: 0.815 +device: 0.721 +instruction: 0.561 +graphic: 0.323 +mistranslation: 0.276 +socket: 0.217 +semantic: 0.208 +vnc: 0.208 +boot: 0.151 +other: 0.084 +assembly: 0.057 +KVM: 0.016 + +[block jobs]qemu hang when creating snapshot target node(iothread enable) diff --git a/results/classifier/105/network/2024 b/results/classifier/105/network/2024 new file mode 100644 index 00000000..a422b5e2 --- /dev/null +++ b/results/classifier/105/network/2024 @@ -0,0 +1,43 @@ +network: 0.968 +boot: 0.958 +instruction: 0.953 +device: 0.912 +graphic: 0.832 +vnc: 0.780 +socket: 0.746 +semantic: 0.701 +assembly: 0.687 +other: 0.680 +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/105/network/2109 b/results/classifier/105/network/2109 new file mode 100644 index 00000000..b682b00f --- /dev/null +++ b/results/classifier/105/network/2109 @@ -0,0 +1,14 @@ +network: 0.968 +device: 0.865 +vnc: 0.608 +boot: 0.514 +graphic: 0.379 +instruction: 0.273 +socket: 0.222 +semantic: 0.103 +mistranslation: 0.062 +other: 0.058 +assembly: 0.004 +KVM: 0.001 + +NetBSD VM fails to install due to missing py311-expat package diff --git a/results/classifier/105/network/2113 b/results/classifier/105/network/2113 new file mode 100644 index 00000000..50b63222 --- /dev/null +++ b/results/classifier/105/network/2113 @@ -0,0 +1,14 @@ +network: 0.790 +device: 0.774 +instruction: 0.738 +vnc: 0.549 +boot: 0.481 +socket: 0.467 +graphic: 0.317 +semantic: 0.310 +mistranslation: 0.274 +other: 0.223 +KVM: 0.036 +assembly: 0.027 + +x64-freebsd-13-build CI job fails with "/usr/local/lib/libtasn1.so: undefined reference to strverscmp@FBSD_1.7" diff --git a/results/classifier/105/network/2143 b/results/classifier/105/network/2143 new file mode 100644 index 00000000..eee93ad6 --- /dev/null +++ b/results/classifier/105/network/2143 @@ -0,0 +1,51 @@ +network: 0.920 +instruction: 0.895 +boot: 0.856 +graphic: 0.833 +socket: 0.813 +device: 0.809 +semantic: 0.783 +other: 0.687 +mistranslation: 0.671 +KVM: 0.536 +assembly: 0.535 +vnc: 0.531 + +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/105/network/2178 b/results/classifier/105/network/2178 new file mode 100644 index 00000000..59d7f610 --- /dev/null +++ b/results/classifier/105/network/2178 @@ -0,0 +1,30 @@ +network: 0.989 +device: 0.933 +other: 0.916 +graphic: 0.900 +instruction: 0.841 +semantic: 0.725 +mistranslation: 0.715 +boot: 0.660 +assembly: 0.616 +socket: 0.489 +vnc: 0.365 +KVM: 0.041 + +USB passthrough on Apple Silicon is unusable +Description of problem: +I can't get USB passthrough to work sufficiently well with wifi modems such as the RTL8187L or Atheros AR 9271. + +I only use the VM as a router since the host OS doesn't have drivers for any external wifi modems. This is a setup I've used flawlessly many times in the past with other VMs on x86 platforms for many years, but with ARM it's been one fail after another. Parallels does work with the exact same host and guest, but fails in the networking area (plus it's expensive and overkill for something this simple). I mention this because I know the guest drivers work 100% with a different VM. +Steps to reproduce: +1. Run any Linux on QEMU on any Apple Silicon mac +2. Attempt to use a Atheros AR 9271 USB device +3. Various fails including + a) USB device not showing up (lsusb) + b) device shows up and Linux attempts to attach driver, but fails (lsmod shows driver loaded but no interface listed on iwconfig) + c) interface shows up (never got the Atheros this far, but RealTek does) but the interface is slow, corrupts data, etc. + d) after re-attaching several times it will eventually stop attaching at all requiring a MacOS system reboot, which is really annoying for my workflow. + +It's basically non-functional for me. Atheros is 100% non-functional and RealTek 10% works (well enough to *sometimes* connect to the AP, but usually craps the bed if you try to do anything as simple as run a dhcp client to fetch the IP). + +If anyone knows of any other Linux ARM on Mac ARM vm solutions that allow USB passthrough please let me know. Unfortunately, VirtualBox os currently not one of them. diff --git a/results/classifier/105/network/218 b/results/classifier/105/network/218 new file mode 100644 index 00000000..f765cb11 --- /dev/null +++ b/results/classifier/105/network/218 @@ -0,0 +1,14 @@ +network: 0.695 +device: 0.665 +instruction: 0.466 +graphic: 0.369 +socket: 0.344 +semantic: 0.305 +mistranslation: 0.157 +other: 0.079 +boot: 0.034 +vnc: 0.031 +assembly: 0.015 +KVM: 0.004 + +qemu-storage-daemon --nbd-server fails with "too many connections" error diff --git a/results/classifier/105/network/2182 b/results/classifier/105/network/2182 new file mode 100644 index 00000000..9dab5f3b --- /dev/null +++ b/results/classifier/105/network/2182 @@ -0,0 +1,14 @@ +network: 0.915 +vnc: 0.284 +graphic: 0.259 +KVM: 0.197 +boot: 0.091 +socket: 0.074 +other: 0.064 +semantic: 0.047 +device: 0.032 +mistranslation: 0.025 +assembly: 0.007 +instruction: 0.006 + +Replication and Network diff --git a/results/classifier/105/network/2189 b/results/classifier/105/network/2189 new file mode 100644 index 00000000..0f7d63d8 --- /dev/null +++ b/results/classifier/105/network/2189 @@ -0,0 +1,27 @@ +network: 0.903 +graphic: 0.869 +device: 0.841 +vnc: 0.807 +mistranslation: 0.791 +instruction: 0.692 +socket: 0.648 +semantic: 0.607 +other: 0.576 +boot: 0.527 +KVM: 0.430 +assembly: 0.272 + +vhost_user:When configure queues of vhost-user NIC exceeds max_queues, the virtual machine is always paused +Description of problem: +When the virtual machine uses the vhost-user network card and sets the queue number of the network card to exceed the maximum number of supported queues, the virtual machine fails to start and stays in the paused state. +And the virtual machine log file kept print "qemu - system - x86_64: -netdev host-user,chardev=charnet0,queues=5,id=hostnet0:you are asking more queues than supported:4” +Steps to reproduce: +1.Configure vhost-user network cards for VMS and use multiple queues. +2.The number of NIC queues configured in the VM xml file is greater than the maximum number of queues supported by the VM, that is, the number of Vcpus on the VM. +3.Execute "virsh create VM_xml_file" cmd to start VM. +Additional information: +According to normal logic, if the number of configured vhost-user NIC queues exceeds max-queues, the qemu process should be stopped, rather than paused the virtual machine. +I am confused about this patch:https://github.com/qemu/qemu/commit/c89804d674e4e3804bd3ac1fe79650896044b4e8 +The process will remain in the do...while loop, when vhost_user_start is called in net_vhost_user_event, if queues > max_queues in vhost_user_start. +/label ~"kind::Bug" +``` diff --git a/results/classifier/105/network/2209 b/results/classifier/105/network/2209 new file mode 100644 index 00000000..dca9f55e --- /dev/null +++ b/results/classifier/105/network/2209 @@ -0,0 +1,60 @@ +network: 0.832 +device: 0.608 +mistranslation: 0.600 +socket: 0.555 +semantic: 0.529 +vnc: 0.526 +instruction: 0.429 +assembly: 0.423 +graphic: 0.395 +other: 0.384 +KVM: 0.380 +boot: 0.307 + +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/105/network/2210 b/results/classifier/105/network/2210 new file mode 100644 index 00000000..e2405146 --- /dev/null +++ b/results/classifier/105/network/2210 @@ -0,0 +1,68 @@ +network: 0.731 +graphic: 0.705 +other: 0.698 +instruction: 0.693 +mistranslation: 0.630 +assembly: 0.629 +semantic: 0.595 +vnc: 0.591 +device: 0.584 +KVM: 0.533 +boot: 0.507 +socket: 0.489 + +contrib/plugins/execlog.c: warning: passing argument 2 of ‘g_ptr_array_add’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] +Description of problem: +Hit some warning messages when compiling upstream qemu +Steps to reproduce: +1. Clone repo and compile it + + 1.1 git clone https://gitlab.com/qemu-project/qemu.git + + 1.2 mkdir build + + 1.3 cd build/ + + 1.4 ../configure --target-list=x86_64-softmmu --enable-debug-info + + 1.5 make + +2. It will print the following warning messages: +``` +[2767/2767] Linking target tests/qtest/netdev-socket +/root/qemu/contrib/plugins/execlog.c: In function ‘registers_init’: +/root/qemu/contrib/plugins/execlog.c:339:63: warning: passing argument 2 of ‘g_ptr_array_add’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] + 339 | g_ptr_array_add(all_reg_names, reg->name); + | ~~~^~~~~~ +In file included from /usr/include/glib-2.0/glib.h:31, + from /root/qemu/contrib/plugins/execlog.c:9: +/usr/include/glib-2.0/glib/garray.h:192:62: note: expected ‘gpointer’ {aka ‘void *’} but argument is of type ‘const char *’ + 192 | gpointer data); + | ~~~~~~~~~~~~~~~~~~^~~~ +``` +Additional information: +1. After Eugenio Perez Martin (eperezma@redhat.com) debug, we found this problem introduced by this commit: +``` +commit af6e4e0a22c18a7cc97650caec56ed99c9899dd7 +Author: Alex Bennée <alex.bennee@linaro.org> +Date: Tue Feb 27 14:43:32 2024 +0000 + + contrib/plugins: extend execlog to track register changes +``` +2. The latest commit in my env: +``` +commit db596ae19040574e41d086e78469014191d7d7fc (origin/staging, origin/master, origin/HEAD) +Merge: 7d4e29ef80 7558300c53 +Author: Peter Maydell <peter.maydell@linaro.org> +Date: Tue Mar 5 13:54:54 2024 +0000 + + Merge tag 'pull-target-arm-20240305' of https://git.linaro.org/people/pmaydell/qemu-arm into staging + + target-arm queue: + * raspi: Implement Broadcom Serial Controller (BSC) for BCM2835 boards + * hw/char/pl011: Add support for loopback + * STM32L4x5: Implement RCC clock control device + * target/arm: Do memory type alignment checks + * atomic.h: Reword confusing comment for qatomic_cmpxchg + * qemu-options.hx: Don't claim "-serial" has limit of 4 serial ports +``` diff --git a/results/classifier/105/network/2228 b/results/classifier/105/network/2228 new file mode 100644 index 00000000..76d3b7f0 --- /dev/null +++ b/results/classifier/105/network/2228 @@ -0,0 +1,21 @@ +network: 0.838 +device: 0.829 +graphic: 0.827 +instruction: 0.769 +socket: 0.706 +vnc: 0.496 +boot: 0.427 +semantic: 0.227 +assembly: 0.160 +KVM: 0.147 +mistranslation: 0.078 +other: 0.050 + +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/105/network/235 b/results/classifier/105/network/235 new file mode 100644 index 00000000..fa66a043 --- /dev/null +++ b/results/classifier/105/network/235 @@ -0,0 +1,14 @@ +network: 0.816 +device: 0.810 +instruction: 0.651 +vnc: 0.578 +boot: 0.392 +graphic: 0.367 +socket: 0.244 +KVM: 0.161 +other: 0.123 +mistranslation: 0.107 +semantic: 0.068 +assembly: 0.032 + +atomic failure linking with --enable-sanitizers on 32-bit Linux hosts diff --git a/results/classifier/105/network/2364 b/results/classifier/105/network/2364 new file mode 100644 index 00000000..417d2999 --- /dev/null +++ b/results/classifier/105/network/2364 @@ -0,0 +1,14 @@ +network: 0.890 +device: 0.538 +other: 0.457 +instruction: 0.266 +graphic: 0.200 +assembly: 0.120 +mistranslation: 0.088 +boot: 0.076 +semantic: 0.065 +socket: 0.038 +vnc: 0.032 +KVM: 0.004 + +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/105/network/238 b/results/classifier/105/network/238 new file mode 100644 index 00000000..7a670885 --- /dev/null +++ b/results/classifier/105/network/238 @@ -0,0 +1,14 @@ +network: 0.708 +device: 0.537 +graphic: 0.486 +instruction: 0.444 +vnc: 0.214 +semantic: 0.208 +mistranslation: 0.194 +boot: 0.192 +assembly: 0.113 +other: 0.049 +KVM: 0.044 +socket: 0.031 + +capstone link failure building linux-user static diff --git a/results/classifier/105/network/2409 b/results/classifier/105/network/2409 new file mode 100644 index 00000000..a8bcf8ed --- /dev/null +++ b/results/classifier/105/network/2409 @@ -0,0 +1,14 @@ +network: 0.981 +device: 0.968 +graphic: 0.767 +semantic: 0.531 +vnc: 0.490 +mistranslation: 0.267 +boot: 0.233 +instruction: 0.203 +other: 0.107 +KVM: 0.096 +assembly: 0.019 +socket: 0.009 + +High CPU usage on network traffic on Apple laptops diff --git a/results/classifier/105/network/2439 b/results/classifier/105/network/2439 new file mode 100644 index 00000000..a8222f78 --- /dev/null +++ b/results/classifier/105/network/2439 @@ -0,0 +1,22 @@ +network: 0.728 +socket: 0.672 +graphic: 0.652 +device: 0.635 +vnc: 0.625 +instruction: 0.485 +semantic: 0.402 +KVM: 0.282 +mistranslation: 0.165 +boot: 0.147 +other: 0.044 +assembly: 0.034 + +qemu.org ssl certificate is expired +Description of problem: + +Steps to reproduce: +1. go to qemu.org +2. look at it +3. maybe screenshot +Additional information: + diff --git a/results/classifier/105/network/2459 b/results/classifier/105/network/2459 new file mode 100644 index 00000000..282581ca --- /dev/null +++ b/results/classifier/105/network/2459 @@ -0,0 +1,14 @@ +network: 0.942 +mistranslation: 0.827 +graphic: 0.479 +semantic: 0.289 +device: 0.205 +socket: 0.110 +other: 0.109 +vnc: 0.098 +boot: 0.025 +instruction: 0.017 +assembly: 0.012 +KVM: 0.003 + +Qemu in termux network bug diff --git a/results/classifier/105/network/2461 b/results/classifier/105/network/2461 new file mode 100644 index 00000000..1e36a59b --- /dev/null +++ b/results/classifier/105/network/2461 @@ -0,0 +1,69 @@ +network: 0.849 +other: 0.846 +semantic: 0.841 +assembly: 0.838 +instruction: 0.837 +graphic: 0.837 +device: 0.799 +KVM: 0.788 +boot: 0.784 +vnc: 0.776 +socket: 0.750 +mistranslation: 0.620 + +Qemu with -accel whpx doesn't set WRMSR permissions, which blocks nested virtualization +Description of problem: +This bug blocks https://gitlab.com/qemu-project/qemu/-/issues/628 + +Qemu doesn't set the host's Hyper-V permissions for WRMSR command to allow using SVM or VMX. Unset permissions lead to `unchecked MSR access error: WRMSR to 0xc0000080` inside Linux VM when trying to launch nested VM on real AMD cpu. Intel users do not see guest VMX feature at all. Please see **Additional info** section to understand how Hyper-V permissions for nested virtualization work in Windows. +Steps to reproduce: +1. Turn on VT-x (for Intel) or AMD-V virtualization in your real hardware BIOS/EFI. This was tested only on AMD cpu and Qemu 9, Intel \*may\* behave differently. + 2. Install any distro in qemu disk c:\\linux_disk.qcow2 with MSR enabled in kernel, for example, Ubuntu 22.04 LTS. + 3. Run qemu using `qemu-system-x86_64.exe -m 2048 -machine q35 -accel whpx -cpu Opteron_G5,check,+svm -hda c:\linux_disk.qcow2` + + To check if your distro has MSR mod enabled, run `grep -i msr /boot/config-$(uname -r)` and it should return `CONFIG_X86_MSR=m` or `CONFIG_X86_MSR=y`. If not, recompile and reinstall your kernel. + 4. Run `sudo modprobe msr` and then `sudo rdmsr 0xc0000080 #EFER`. You should see `d01` on modern AMD models. \[Untested\] For intel, run `sudo modprobe msr`, then `sudo rdmsr 0x3A`. You should see `5` or `0x5` or `0x100005`. d01 for AMD and 5 for Intel in output are necessary to enable nested VM. If RDMSR returns non-zero value, it means that qemu developers implemented this part of functionality and your Hyper-V on Windows is not broken. + 5. Run `cat /proc/cpuinfo | grep -c svm` on AMD cpu, which should output a positive digit. + 6. Run `sudo dmesg | grep kvm` and note: + + `[1.924036] kvm_amd: Nested Virtualization enabled` + + `[1.924038] kvm_amd: Nested Paging disabled`\ + `[1.924040] kvm_amd: PMU virtualization is disabled` + 7. This, in theory, is sufficient for KVM-acclelerated qemu to start a nested VM. + 8. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error + 9. Run `sudo qemu-system-x86_64 -accel kvm`. A black window with "Guest has not initialized the display (yet)." appears. +10. Run `sudo dmesg` and note qemu crash starting with `unchecked MSR access error: WRMSR` + + \* Steps 1-4 are only required for diagnostics, and KVM works (in native Windows Hyper-V manager) without the necessarity to enter these commands in usual usage scenarios. If you run <span dir="">`cat /proc/cpuinfo | grep -c vmx` on Intel cpu</span> on Step 5, you may get zero. See Step 5 of Additional Info to understand why. + + \ + Microsoft released useful info about how to look into Hyper-V MSR access problems:\ + WRMSR research in Hyper-V - https://msrc.microsoft.com/blog/2018/12/first-steps-in-hyper-v-research/ +Additional information: +By default, Hyper-V manager in Windows does not allow nested virtualization.\ +To see what happens, do the following: + + 1. Open Hyper-V manager built in the host Windows and create default Ubuntu 22.04 LTS suggested. Upon installation, shut down the VM. Note the name of the VM ("Ubuntu 22.04 LTS" by default). + 2. Open Powershell console in the host and run `Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $false` + 3. Launch guest Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. No output. + 4. Run `sudo rdmsr 0xc0000080 #EFER` that outputs d01, which means that Hyper-V manager allows this **ring 0 level** operation. + 5. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `0`. + 6. Shut the VM down. + 7. Now, Open Powershell console and `run Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $true` + 8. Launch Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. Output: + + `[2.369144] kvm: Nested Virtualization enabled` + + `[2.369146] SVM: kvm: Nested Paging enabled` + + `[2.369148] SVM: kvm: Hyper-V enlightened NPT TLB flush enabled` + + `[2.369149] SVM: kvm: Hyper-V Direct TLB flush enabled` + + `[2.369153] SVM: Virtual VMLOAD VMSAVE supported` + 9. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `1` or other positive digit, depending on the number of cpus you've assigned to the VM. +10. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error +11. Run `sudo qemu-system-x86_64 -accel kvm` and it successfully boots into qemu BIOS. +12. Running `sudo qemu-system-x86_64 -accel kvm` calls WRMSR in background, so if you see\ + booted qemu BIOS in KVM, wrmsr was successfully called. diff --git a/results/classifier/105/network/2494 b/results/classifier/105/network/2494 new file mode 100644 index 00000000..b19823d9 --- /dev/null +++ b/results/classifier/105/network/2494 @@ -0,0 +1,14 @@ +network: 0.956 +other: 0.788 +device: 0.781 +KVM: 0.685 +vnc: 0.658 +semantic: 0.447 +instruction: 0.445 +assembly: 0.425 +graphic: 0.410 +boot: 0.381 +socket: 0.352 +mistranslation: 0.128 + +Isolated network between VMs not visible to the host diff --git a/results/classifier/105/network/2514 b/results/classifier/105/network/2514 new file mode 100644 index 00000000..3799a148 --- /dev/null +++ b/results/classifier/105/network/2514 @@ -0,0 +1,14 @@ +network: 0.981 +other: 0.825 +mistranslation: 0.596 +vnc: 0.593 +device: 0.556 +graphic: 0.498 +socket: 0.458 +semantic: 0.408 +boot: 0.364 +KVM: 0.323 +instruction: 0.106 +assembly: 0.085 + +network unreachable to esxi 8 guest diff --git a/results/classifier/105/network/2528 b/results/classifier/105/network/2528 new file mode 100644 index 00000000..5c51e103 --- /dev/null +++ b/results/classifier/105/network/2528 @@ -0,0 +1,22 @@ +network: 0.940 +device: 0.797 +graphic: 0.597 +instruction: 0.588 +vnc: 0.402 +socket: 0.327 +semantic: 0.311 +boot: 0.309 +other: 0.077 +KVM: 0.059 +assembly: 0.044 +mistranslation: 0.038 + +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/105/network/2552 b/results/classifier/105/network/2552 new file mode 100644 index 00000000..5c06b3f2 --- /dev/null +++ b/results/classifier/105/network/2552 @@ -0,0 +1,85 @@ +network: 0.789 +KVM: 0.661 +graphic: 0.616 +semantic: 0.602 +device: 0.561 +socket: 0.532 +mistranslation: 0.458 +instruction: 0.434 +other: 0.385 +assembly: 0.372 +vnc: 0.351 +boot: 0.232 + +system libfdt said to be too old (1.5.1 min required) but 1.7.1 is installed. +Description of problem: +<-- +I am running an update build of the latest qemu version 9.0.2 to update it from 8.1.2 in the IPFire firewall distribution. +The build command being run was + +` +./configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --enable-kvm \ + --disable-attr \ + --target-list="$(TARGETS)" \ + --extra-cflags="$(CFLAGS)" \ + --enable-spice \ + --enable-usb-redir \ + --enable-seccomp \ + --disable-docs \ + --disable-sdl \ + --enable-slirp +` + +and where $TARGETS is + +` x86_64-linux-user \ + aarch64-linux-user \ + riscv64-linux-user \ + x86_64-softmmu \ + aarch64-softmmu \ + riscv64-softmmu +` + +and $CFLAGS is + +` "-O2" + "-g0" + "-pipe" + "-Wall" + "-fexceptions" + "-fPIC" + "-Wp,-U_FORTIFY_SOURCE" + "-Wp,-D_FORTIFY_SOURCE=3" + "-Wp,-D_GLIBCXX_ASSERTIONS" + "-fstack-protector-strong" + "-fstack-clash-protection" +` + +This built qemu successfully with version 8.1.2 and earlier versions. + +From version 9.0.1 onwards the subproject dtc has been removed from the Source Tarball and the build came back with the error message + +Library fdt found: NO + +../meson.build:3190:18: ERROR: Git command failed: ['/usr/bin/git', 'fetch', '--depth', '1', 'origin', 'b6910bec11614980a21e46fbccc35934b671bd81'] + +The git command failed as the distribution build is done with no network connection. All packages have to be available in the build and so the package cannot be downloaded during the build. + +Therefore I moved the dtc package in the IPFire build to before building qemu and added --disable-download to the ./configure options. + +The error message changed to + +Library fdt found: YES + +../meson.build:3182:7: ERROR: Problem encountered: system libfdt requested, but it is too old (1.5.1 or newer required) + +However the dtc libfdt version is 1.7.1 - definitely newer than 1.5.1 + +Why is the version being seen as too old? +How do I get this to detect the dtc libfdt version correctly (it has detected that libfdt is present in the IPFire build environment). + +--> diff --git a/results/classifier/105/network/2553 b/results/classifier/105/network/2553 new file mode 100644 index 00000000..ff16e70b --- /dev/null +++ b/results/classifier/105/network/2553 @@ -0,0 +1,95 @@ +network: 0.957 +device: 0.949 +graphic: 0.945 +assembly: 0.944 +socket: 0.933 +other: 0.931 +boot: 0.930 +instruction: 0.928 +semantic: 0.912 +mistranslation: 0.907 +KVM: 0.869 +vnc: 0.863 + +Joining IP multicast fails when emulating 64-bit Linux +Description of problem: +I have some code that joins IP multicast groups and I'd like to use QEMU to test it on big-endian and/or 32-bit platforms. But when I compile it for 64-bit big-endian platforms (e.g. PowerPC64) and run it under QEMU user-mode emulation, the setsockopt(IP_ADD_MEMBERSHIP) call fails with ENODEV. + +This appears to refer to the imr_ifindex ("interface index") field in struct ip_mreqn not being valid, which in turn appears to be because it's not being correctly marshalled from the binary under emulation, to the host's *actual* setsockopt system call. + +I *think* this may be because linux-user/syscall_defs.h (https://github.com/qemu/qemu/blob/master/linux-user/syscall_defs.h) contains the following at line 210: + +``` +struct target_ip_mreqn { + struct target_in_addr imr_multiaddr; + struct target_in_addr imr_address; + abi_long imr_ifindex; +}; +``` + +but the actual Linux ip_mreqn has imr_ifindex as an int (32-bit everywhere) not a long (64-bit on PPC64); the size of this structure is 12 on all Linux platforms. + +I opted to submit an issue instead of just patching it, in case there was some wider context I hadn't seen? +Steps to reproduce: +1. take the following C program (distilled from a larger program): + +``` +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <arpa/inet.h> +#include <stdio.h> +#include <stdlib.h> + +int main(int argc, char *argv[]) +{ + int fd = socket(AF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + perror("socket"); + return 1; + } + + struct ip_mreqn mreq; + mreq.imr_multiaddr.s_addr = inet_addr("239.255.255.250"); + mreq.imr_address.s_addr = htonl(INADDR_ANY); + mreq.imr_ifindex = 1; + int size = sizeof(mreq); + printf("size=%u\n", size); + if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, + (char*) &mreq, sizeof(mreq)) < 0) { + perror("setsockopt"); + return 1; + } + printf("OK\n"); + return 0; +} +``` + +2. confirm it works compiled native on amd64/x86_64: + +``` +[peter@amd64 misc]$ gcc mcast.c -o mcast +[peter@amd64 misc]$ ./mcast +size=12 +OK +``` + +3. watch it *not* work emulated: + +``` +[peter@amd64 misc]$ powerpc64-linux-gnu-gcc mcast.c -o mcast.ppc64 +[peter@amd64 misc]$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 ./mcast.ppc64 +size=12 +setsockopt: No such device +``` +Additional information: +If the target_ip_mreqn issue is real, the following code in syscall.c helped conceal it: + + if (optlen < sizeof (struct target_ip_mreq) || + optlen > sizeof (struct target_ip_mreqn)) { + return -TARGET_EINVAL; + } + +Should this instead be testing for size equal to target_ip_mreq or equal to target_ip_mreqn, not anywhere in between? in this case target_ip_mreq is 8 bytes, target_ip_mreqn is 16 bytes, but optlen is 12. The end result is that QEMU passes 4 bytes of uninitialised stack memory as imr_ifindex! + +The actual kernel behaviour appears to be: smaller than ip_mreq, EINVAL; between ip_mreq and ip_mreqn, silently treat as ip_mreq; larger or equal to ip_mreqn, silently treat as ip_mreqn. see https://github.com/torvalds/linux/blob/b31c4492884252a8360f312a0ac2049349ddf603/net/ipv4/ip_sockglue.c#L1234 diff --git a/results/classifier/105/network/2623 b/results/classifier/105/network/2623 new file mode 100644 index 00000000..fbab6f52 --- /dev/null +++ b/results/classifier/105/network/2623 @@ -0,0 +1,14 @@ +network: 0.951 +device: 0.869 +other: 0.450 +semantic: 0.435 +instruction: 0.424 +boot: 0.364 +mistranslation: 0.301 +graphic: 0.232 +socket: 0.209 +vnc: 0.191 +KVM: 0.097 +assembly: 0.093 + +Timeout waiting for ARP/RARP packets diff --git a/results/classifier/105/network/2668 b/results/classifier/105/network/2668 new file mode 100644 index 00000000..a7eb5950 --- /dev/null +++ b/results/classifier/105/network/2668 @@ -0,0 +1,16 @@ +network: 0.943 +vnc: 0.915 +device: 0.909 +socket: 0.762 +other: 0.759 +graphic: 0.658 +mistranslation: 0.657 +boot: 0.628 +semantic: 0.606 +assembly: 0.411 +instruction: 0.333 +KVM: 0.237 + +h.264 encoding/compression support +Additional information: +noVNC now support h.264 decoding. diff --git a/results/classifier/105/network/2670 b/results/classifier/105/network/2670 new file mode 100644 index 00000000..902397da --- /dev/null +++ b/results/classifier/105/network/2670 @@ -0,0 +1,57 @@ +network: 0.911 +instruction: 0.840 +vnc: 0.821 +device: 0.812 +socket: 0.742 +boot: 0.712 +mistranslation: 0.703 +graphic: 0.685 +semantic: 0.590 +other: 0.569 +KVM: 0.439 +assembly: 0.434 + +The virglrenderer depency causes qemu native recipe building to fail for NXP QEMU +Description of problem: +nativesdk-qemu-8.2.2.imx-r0 do_compile: oe_runmake failed +... + [87/4472] Compiling C object libcommon.fa.p/hw_display_virtio-gpu.c.o +| FAILED: libcommon.fa.p/hw_display_virtio-gpu.c.o +... + ../hw/display/virtio-gpu.c:36:10: fatal error: virglrenderer.h: No such file or directory +| 36 | #include <virglrenderer.h> +| | ^~~~~~~~~~~~~~~~~ +| compilation terminated. + +This issue was originally exposed after updating Yocto release to Scarthgap + +https://lists.yoctoproject.org/g/yocto/topic/building_sdk_fails_after/109275322 + +which seems to relate to commit https://github.com/nxp-imx/imx-qemu/commit/628105edbd816458dbf154a128cc3dd3ac809c7e that seemingly induces dependency to virglrenderer.h for virtio_gpu driver. + +Enabling opengl in our Distribution features is not a solution because that pulls in VGA graphics dependencies to our target binaries and we have no graphics hardware on our system. I have tried to disable the virglrenderer through QEMU build configuration but that does not fix the issue. +Steps to reproduce: +1. Clone NXP BSP Scarthgap +``` +$ mkdir nxp-bsp +$ cd nxp-bsp +nxp-bsp$ repo init -u https://github.com/nxp-imx/imx-manifest -b scarthgap -m imx-6.6.36-2.1.0.xml +nxp-bsp$ repo sync +``` + +2. Remove opengl from `fsl-imx-xwayland` DISTRO_FEATURES + +``` +sources/meta-imx/meta-imx-sdk/conf/distro/fsl-imx-wayland.conf: +... ++DISTRO_FEATURES:remove = "opengl " +... +``` + +3. Build qemu-native_8.2.2.imx + +``` +$ bitbake qemu-native_8.2.2.imx +``` +Additional information: + diff --git a/results/classifier/105/network/2685 b/results/classifier/105/network/2685 new file mode 100644 index 00000000..ce31424e --- /dev/null +++ b/results/classifier/105/network/2685 @@ -0,0 +1,14 @@ +network: 0.926 +device: 0.769 +instruction: 0.651 +graphic: 0.383 +semantic: 0.279 +boot: 0.270 +mistranslation: 0.259 +vnc: 0.172 +other: 0.140 +socket: 0.099 +assembly: 0.024 +KVM: 0.011 + +Netbsd 10.0 AMD64 as host fails in tcg? diff --git a/results/classifier/105/network/2688 b/results/classifier/105/network/2688 new file mode 100644 index 00000000..a20173cf --- /dev/null +++ b/results/classifier/105/network/2688 @@ -0,0 +1,14 @@ +instruction: 0.963 +network: 0.956 +device: 0.742 +vnc: 0.635 +KVM: 0.413 +semantic: 0.403 +socket: 0.393 +graphic: 0.367 +boot: 0.357 +assembly: 0.315 +other: 0.299 +mistranslation: 0.168 + +Add `disable_host_loopback` for network user backend diff --git a/results/classifier/105/network/2727 b/results/classifier/105/network/2727 new file mode 100644 index 00000000..ec26ba1f --- /dev/null +++ b/results/classifier/105/network/2727 @@ -0,0 +1,14 @@ +network: 0.890 +device: 0.802 +instruction: 0.676 +vnc: 0.496 +graphic: 0.455 +boot: 0.368 +semantic: 0.262 +socket: 0.222 +mistranslation: 0.189 +other: 0.105 +assembly: 0.066 +KVM: 0.008 + +`Debian testing` (2024-12-16) - `qemu-system-x86_64 9.2.0` : bug with the `virtio-net` and a DHCP connection with a virtual bridge. diff --git a/results/classifier/105/network/2745 b/results/classifier/105/network/2745 new file mode 100644 index 00000000..94540950 --- /dev/null +++ b/results/classifier/105/network/2745 @@ -0,0 +1,39 @@ +network: 0.922 +instruction: 0.784 +graphic: 0.715 +other: 0.660 +device: 0.652 +semantic: 0.543 +socket: 0.535 +boot: 0.330 +KVM: 0.293 +mistranslation: 0.289 +vnc: 0.281 +assembly: 0.269 + +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/105/network/2746 b/results/classifier/105/network/2746 new file mode 100644 index 00000000..58e1bff3 --- /dev/null +++ b/results/classifier/105/network/2746 @@ -0,0 +1,14 @@ +network: 0.847 +instruction: 0.813 +semantic: 0.787 +device: 0.780 +mistranslation: 0.572 +graphic: 0.555 +socket: 0.341 +vnc: 0.271 +other: 0.226 +assembly: 0.196 +boot: 0.178 +KVM: 0.090 + +NO_CAST.INTEGER_OVERFLOW in /hw/net/e1000.c diff --git a/results/classifier/105/network/2756 b/results/classifier/105/network/2756 new file mode 100644 index 00000000..3b00c4d2 --- /dev/null +++ b/results/classifier/105/network/2756 @@ -0,0 +1,55 @@ +network: 0.991 +device: 0.984 +socket: 0.975 +graphic: 0.954 +vnc: 0.933 +KVM: 0.911 +boot: 0.843 +instruction: 0.789 +mistranslation: 0.765 +semantic: 0.742 +assembly: 0.533 +other: 0.484 + +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/105/network/2758 b/results/classifier/105/network/2758 new file mode 100644 index 00000000..2d3bf4fc --- /dev/null +++ b/results/classifier/105/network/2758 @@ -0,0 +1,36 @@ +network: 0.972 +instruction: 0.910 +device: 0.808 +graphic: 0.741 +vnc: 0.587 +socket: 0.557 +semantic: 0.419 +boot: 0.341 +KVM: 0.303 +assembly: 0.271 +other: 0.084 +mistranslation: 0.075 + +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/105/network/2767 b/results/classifier/105/network/2767 new file mode 100644 index 00000000..c82e68f8 --- /dev/null +++ b/results/classifier/105/network/2767 @@ -0,0 +1,50 @@ +network: 0.925 +socket: 0.894 +device: 0.723 +graphic: 0.642 +vnc: 0.532 +instruction: 0.471 +boot: 0.323 +assembly: 0.265 +semantic: 0.250 +other: 0.246 +mistranslation: 0.238 +KVM: 0.213 + +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/105/network/277 b/results/classifier/105/network/277 new file mode 100644 index 00000000..c52e7df6 --- /dev/null +++ b/results/classifier/105/network/277 @@ -0,0 +1,14 @@ +network: 0.800 +device: 0.794 +graphic: 0.562 +instruction: 0.523 +semantic: 0.251 +boot: 0.232 +vnc: 0.230 +other: 0.215 +mistranslation: 0.165 +socket: 0.031 +KVM: 0.024 +assembly: 0.007 + +Multi-queue vhost-user fails to reconnect with qemu version >=4.2 diff --git a/results/classifier/105/network/2780 b/results/classifier/105/network/2780 new file mode 100644 index 00000000..b3dc1240 --- /dev/null +++ b/results/classifier/105/network/2780 @@ -0,0 +1,30 @@ +network: 0.981 +device: 0.910 +instruction: 0.907 +graphic: 0.906 +socket: 0.573 +vnc: 0.510 +semantic: 0.420 +assembly: 0.280 +boot: 0.272 +mistranslation: 0.271 +KVM: 0.190 +other: 0.108 + +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/105/network/2814 b/results/classifier/105/network/2814 new file mode 100644 index 00000000..3b866cd0 --- /dev/null +++ b/results/classifier/105/network/2814 @@ -0,0 +1,14 @@ +network: 0.622 +device: 0.565 +instruction: 0.390 +vnc: 0.334 +semantic: 0.283 +graphic: 0.207 +boot: 0.168 +socket: 0.141 +other: 0.065 +mistranslation: 0.042 +KVM: 0.028 +assembly: 0.007 + +Convert gdb_core_xml_file to function for https://linaro.atlassian.net/browse/QEMU-487 diff --git a/results/classifier/105/network/282 b/results/classifier/105/network/282 new file mode 100644 index 00000000..69857079 --- /dev/null +++ b/results/classifier/105/network/282 @@ -0,0 +1,14 @@ +network: 0.829 +device: 0.699 +socket: 0.567 +other: 0.458 +vnc: 0.359 +graphic: 0.290 +KVM: 0.255 +boot: 0.250 +mistranslation: 0.234 +semantic: 0.212 +instruction: 0.146 +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/105/network/2827 b/results/classifier/105/network/2827 new file mode 100644 index 00000000..6aa7e480 --- /dev/null +++ b/results/classifier/105/network/2827 @@ -0,0 +1,14 @@ +network: 0.915 +instruction: 0.815 +device: 0.801 +graphic: 0.265 +boot: 0.217 +semantic: 0.172 +mistranslation: 0.105 +socket: 0.076 +vnc: 0.032 +other: 0.030 +assembly: 0.011 +KVM: 0.001 + +Document how to use QEMU user mode networking with passt diff --git a/results/classifier/105/network/2829 b/results/classifier/105/network/2829 new file mode 100644 index 00000000..295d5a2b --- /dev/null +++ b/results/classifier/105/network/2829 @@ -0,0 +1,34 @@ +network: 0.939 +instruction: 0.861 +device: 0.833 +socket: 0.798 +graphic: 0.760 +vnc: 0.759 +semantic: 0.691 +other: 0.652 +mistranslation: 0.591 +boot: 0.454 +assembly: 0.281 +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/105/network/2849 b/results/classifier/105/network/2849 new file mode 100644 index 00000000..b38780fe --- /dev/null +++ b/results/classifier/105/network/2849 @@ -0,0 +1,31 @@ +network: 0.899 +device: 0.706 +graphic: 0.640 +vnc: 0.621 +instruction: 0.599 +semantic: 0.555 +other: 0.448 +KVM: 0.433 +mistranslation: 0.398 +boot: 0.339 +socket: 0.271 +assembly: 0.237 + +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/105/network/2872 b/results/classifier/105/network/2872 new file mode 100644 index 00000000..af660a47 --- /dev/null +++ b/results/classifier/105/network/2872 @@ -0,0 +1,14 @@ +network: 0.945 +device: 0.884 +mistranslation: 0.763 +socket: 0.651 +vnc: 0.490 +semantic: 0.487 +instruction: 0.444 +boot: 0.434 +graphic: 0.357 +KVM: 0.261 +other: 0.202 +assembly: 0.149 + +hw/net: Parameter 'driver' expects a pluggable device type diff --git a/results/classifier/105/network/2884 b/results/classifier/105/network/2884 new file mode 100644 index 00000000..808e5225 --- /dev/null +++ b/results/classifier/105/network/2884 @@ -0,0 +1,48 @@ +network: 0.982 +device: 0.908 +graphic: 0.843 +KVM: 0.809 +socket: 0.772 +instruction: 0.767 +other: 0.681 +vnc: 0.630 +semantic: 0.528 +mistranslation: 0.451 +boot: 0.408 +assembly: 0.384 + +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/105/network/2951 b/results/classifier/105/network/2951 new file mode 100644 index 00000000..a70c3a0c --- /dev/null +++ b/results/classifier/105/network/2951 @@ -0,0 +1,34 @@ +network: 0.935 +graphic: 0.840 +device: 0.838 +vnc: 0.799 +instruction: 0.765 +socket: 0.693 +other: 0.646 +boot: 0.561 +semantic: 0.529 +KVM: 0.277 +assembly: 0.249 +mistranslation: 0.142 + +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/105/network/2970 b/results/classifier/105/network/2970 new file mode 100644 index 00000000..0a73769d --- /dev/null +++ b/results/classifier/105/network/2970 @@ -0,0 +1,14 @@ +network: 0.782 +device: 0.777 +instruction: 0.567 +socket: 0.523 +graphic: 0.514 +boot: 0.474 +semantic: 0.299 +vnc: 0.297 +mistranslation: 0.148 +other: 0.128 +assembly: 0.067 +KVM: 0.016 + +qemu version 10.0.0 fails to build with clang-21 (current trunk) diff --git a/results/classifier/105/network/299 b/results/classifier/105/network/299 new file mode 100644 index 00000000..f5c88029 --- /dev/null +++ b/results/classifier/105/network/299 @@ -0,0 +1,14 @@ +network: 0.957 +device: 0.790 +graphic: 0.599 +semantic: 0.409 +other: 0.296 +instruction: 0.256 +mistranslation: 0.193 +boot: 0.185 +vnc: 0.141 +assembly: 0.036 +socket: 0.026 +KVM: 0.007 + +Tulip NIC not working on OpenBSD/hppa (and more) diff --git a/results/classifier/105/network/308 b/results/classifier/105/network/308 new file mode 100644 index 00000000..636a8fdf --- /dev/null +++ b/results/classifier/105/network/308 @@ -0,0 +1,14 @@ +network: 0.947 +instruction: 0.810 +device: 0.785 +graphic: 0.394 +mistranslation: 0.377 +boot: 0.300 +semantic: 0.162 +other: 0.081 +assembly: 0.033 +socket: 0.027 +vnc: 0.018 +KVM: 0.005 + +QEMU: net: vmxnet: integer overflow may crash guest diff --git a/results/classifier/105/network/309 b/results/classifier/105/network/309 new file mode 100644 index 00000000..5e5eb351 --- /dev/null +++ b/results/classifier/105/network/309 @@ -0,0 +1,14 @@ +network: 0.919 +device: 0.714 +instruction: 0.629 +socket: 0.606 +vnc: 0.466 +graphic: 0.406 +semantic: 0.337 +boot: 0.260 +KVM: 0.146 +mistranslation: 0.136 +assembly: 0.101 +other: 0.067 + +assert issue locates in hw/net/vmxnet3.c:1793:vmxnet3_io_bar1_write: code should not be reach diff --git a/results/classifier/105/network/335 b/results/classifier/105/network/335 new file mode 100644 index 00000000..e6b02fc3 --- /dev/null +++ b/results/classifier/105/network/335 @@ -0,0 +1,14 @@ +network: 0.975 +device: 0.858 +graphic: 0.663 +mistranslation: 0.239 +vnc: 0.234 +other: 0.149 +socket: 0.134 +boot: 0.124 +instruction: 0.100 +semantic: 0.090 +KVM: 0.085 +assembly: 0.014 + +Broken tap networking on macOS host diff --git a/results/classifier/105/network/336 b/results/classifier/105/network/336 new file mode 100644 index 00000000..c1f0351c --- /dev/null +++ b/results/classifier/105/network/336 @@ -0,0 +1,14 @@ +network: 0.859 +device: 0.803 +mistranslation: 0.354 +graphic: 0.330 +semantic: 0.155 +boot: 0.118 +instruction: 0.053 +vnc: 0.050 +assembly: 0.044 +other: 0.026 +KVM: 0.007 +socket: 0.003 + +Built-in DHCP server: SiAddr diff --git a/results/classifier/105/network/348 b/results/classifier/105/network/348 new file mode 100644 index 00000000..f94fea40 --- /dev/null +++ b/results/classifier/105/network/348 @@ -0,0 +1,14 @@ +network: 0.824 +device: 0.463 +socket: 0.387 +graphic: 0.371 +semantic: 0.301 +instruction: 0.290 +mistranslation: 0.281 +boot: 0.174 +other: 0.171 +vnc: 0.100 +assembly: 0.015 +KVM: 0.003 + +qemu-user fails to run container using systemd-networkd: "Could not create manager: Protocol not supported" diff --git a/results/classifier/105/network/360 b/results/classifier/105/network/360 new file mode 100644 index 00000000..f22b4dc7 --- /dev/null +++ b/results/classifier/105/network/360 @@ -0,0 +1,14 @@ +network: 0.804 +device: 0.793 +mistranslation: 0.761 +socket: 0.695 +instruction: 0.638 +vnc: 0.414 +other: 0.273 +graphic: 0.270 +semantic: 0.252 +boot: 0.249 +assembly: 0.137 +KVM: 0.010 + +load_helper() do_unaligned_access path doesn't return correct result with MMIO diff --git a/results/classifier/105/network/377 b/results/classifier/105/network/377 new file mode 100644 index 00000000..fd677925 --- /dev/null +++ b/results/classifier/105/network/377 @@ -0,0 +1,14 @@ +network: 0.947 +mistranslation: 0.753 +device: 0.563 +socket: 0.497 +graphic: 0.469 +other: 0.426 +vnc: 0.340 +semantic: 0.324 +boot: 0.284 +KVM: 0.266 +assembly: 0.094 +instruction: 0.065 + +Indentation should be done with spaces, not with TABs, in the net subsystem diff --git a/results/classifier/105/network/401 b/results/classifier/105/network/401 new file mode 100644 index 00000000..df11d7ef --- /dev/null +++ b/results/classifier/105/network/401 @@ -0,0 +1,14 @@ +network: 0.863 +semantic: 0.824 +device: 0.814 +mistranslation: 0.642 +instruction: 0.593 +graphic: 0.447 +assembly: 0.267 +vnc: 0.256 +boot: 0.093 +KVM: 0.048 +socket: 0.046 +other: 0.021 + +Wishlist: nvme-ns: allow specifying eui-64 diff --git a/results/classifier/105/network/428 b/results/classifier/105/network/428 new file mode 100644 index 00000000..e06297ea --- /dev/null +++ b/results/classifier/105/network/428 @@ -0,0 +1,14 @@ +network: 0.962 +device: 0.852 +graphic: 0.468 +semantic: 0.301 +mistranslation: 0.227 +boot: 0.215 +vnc: 0.212 +instruction: 0.153 +socket: 0.108 +other: 0.006 +assembly: 0.005 +KVM: 0.001 + +Windows: Very low network throughput with tap-netdev & virtio-serial diff --git a/results/classifier/105/network/460 b/results/classifier/105/network/460 new file mode 100644 index 00000000..80f47942 --- /dev/null +++ b/results/classifier/105/network/460 @@ -0,0 +1,14 @@ +network: 0.952 +device: 0.940 +instruction: 0.804 +graphic: 0.389 +socket: 0.372 +boot: 0.260 +mistranslation: 0.172 +semantic: 0.170 +assembly: 0.160 +vnc: 0.044 +KVM: 0.019 +other: 0.013 + +vmxnet3: Assertion failure in eth_setup_ip4_fragmentation diff --git a/results/classifier/105/network/465 b/results/classifier/105/network/465 new file mode 100644 index 00000000..e26b3407 --- /dev/null +++ b/results/classifier/105/network/465 @@ -0,0 +1,20 @@ +network: 0.980 +device: 0.806 +vnc: 0.759 +mistranslation: 0.683 +graphic: 0.649 +semantic: 0.562 +instruction: 0.514 +socket: 0.502 +other: 0.428 +boot: 0.305 +KVM: 0.138 +assembly: 0.074 + +Support network virtualization for Macos Big Sur+ +Additional information: +The following implementation are already submitted as a patch and they seem to work well on my mbp 2019 Big Sur. The only prob is that the qemu-system command should be run as root. + +[https://patchwork.kernel.org/project/qemu-devel/list/?series=502533](https://patchwork.kernel.org/project/qemu-devel/list/?series=502533) + +[https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/](https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/) diff --git a/results/classifier/105/network/485250 b/results/classifier/105/network/485250 new file mode 100644 index 00000000..635662a9 --- /dev/null +++ b/results/classifier/105/network/485250 @@ -0,0 +1,46 @@ +network: 0.966 +mistranslation: 0.966 +semantic: 0.944 +device: 0.935 +instruction: 0.915 +boot: 0.907 +graphic: 0.904 +other: 0.891 +vnc: 0.865 +socket: 0.825 +KVM: 0.655 +assembly: 0.634 + +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/105/network/495566 b/results/classifier/105/network/495566 new file mode 100644 index 00000000..0968e36b --- /dev/null +++ b/results/classifier/105/network/495566 @@ -0,0 +1,45 @@ +network: 0.758 +graphic: 0.640 +device: 0.597 +instruction: 0.583 +semantic: 0.569 +vnc: 0.403 +socket: 0.340 +other: 0.301 +boot: 0.262 +KVM: 0.136 +mistranslation: 0.136 +assembly: 0.084 + +qemu network adapter initialization fails when using macaddr=<multicast MAC-address> + +Not sure if ultra-strange, nondocumented feature in qemu (or linux kernel) or really bug: Network card initialization fails if first byte of mac address is not 00. The problem occurs at least with model=pcnet/rtl8139, in both cases the network adapter is not usable. + +How to reproduce: + +* Take standard initrd/kernel (tested with hardy) + +* Start qemu (cmd see below) and enter "modprobe pcnet32" at prompt: +qemu -name SetupTest -no-acpi -m 128 -drive file=/dev/null,if=ide,index=0 -net nic,macaddr=00:22:33:44:55:66,model=pcnet -net user -kernel vmlinuz-2.6.24-26-generic -initrd initrd.img-2.6.24-26-generic -append break=premount + +You will see "pcnet32 ... at 0x..., 00:22:33:44:55:66 + +* Do same with mac address 11:22:33:44:55:66 +qemu -name SetupTest -no-acpi -m 128 -drive file=/dev/null,if=ide,index=0 -net nic,macaddr=11:22:33:44:55:66,model=pcnet -net user -kernel vmlinuz-2.6.24-26-generic -initrd initrd.img-2.6.24-26-generic -append break=premount + +You will see "pcnet32 ... at 0x..., 00:00:00:00:00:00 + +The network adapter is non-functional, "ip link set eth0 up" does not report error, but does not work (indicates at least some linux kernel influence) + +With the rtl8139 adapter, mac-address in guest is correct, but adapter does not work either (indicates qemu influence) + +Tested other mac addrs, seems that the first byte has to be even. Would it make sense to issue a warning if a user requests a mac address with an odd first byte? What is the special meaning of the bit 0? + +That bit indicates whether the address is a multicast or unicast address. A network card cannot have a multicast address. + +It would make sense to do sanity checking for this. + +A check for multicast MAC addresses has been introduced by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d60b20cf2ae6644b051 +So I think we can close this ticket now. + diff --git a/results/classifier/105/network/517 b/results/classifier/105/network/517 new file mode 100644 index 00000000..fa0511b9 --- /dev/null +++ b/results/classifier/105/network/517 @@ -0,0 +1,14 @@ +network: 0.887 +instruction: 0.855 +device: 0.844 +socket: 0.468 +mistranslation: 0.349 +graphic: 0.337 +semantic: 0.304 +boot: 0.123 +other: 0.082 +assembly: 0.065 +vnc: 0.056 +KVM: 0.012 + +Abort in vmxnet3_setup_tx_offloads diff --git a/results/classifier/105/network/524447 b/results/classifier/105/network/524447 new file mode 100644 index 00000000..ba4d71bd --- /dev/null +++ b/results/classifier/105/network/524447 @@ -0,0 +1,336 @@ +network: 0.899 +device: 0.896 +assembly: 0.895 +other: 0.893 +vnc: 0.871 +mistranslation: 0.869 +instruction: 0.866 +socket: 0.858 +graphic: 0.841 +semantic: 0.839 +KVM: 0.832 +boot: 0.795 + +virsh save is very slow + +As reported here: http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html + +"virsh save" is very slow - it writes the image at around 1MB/sec on my test system. + +(I think I saw a bug report for this issue on Fedora's bugzilla, but I can't find it now...) + +Confirmed under Karmic. + +Anthony- + +Any upstream update here? Looks like this issue has been reported on the qemu-devel@mailing list. Curious if or when we might expect a fix for this? + +Thanks! + +I'm marking confirmed, since there's external references to this situation happening. + +This stops me migrating away from VMware Server to KVM/libvirt. I use suspend (to disk) for backup an when shutting down the host. It would need nearly an hour to save all domains on our server. Why are there so few responses here an in the qemu-Mailinglist? Does nobody care? + +I can reproduce with: + +x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img -snapshot -m 4G -monitor stdio -enable-kvm +QEMU 0.12.50 monitor - type 'help' for more information +(qemu) migrate_set_speed 1G +(qemu) migrate -d "exec:dd of=foo.img" + +On: + +commit d9b73e47a3d596c5b33802597ec5bd91ef3348e2 +Author: Corentin Chary <email address hidden> +Date: Tue Jun 1 23:05:44 2010 +0200 + + vnc: add missing target for vnc-encodings-*.o + + +Even though the rate limit is set at 1G, we're not getting more than 1-2MB/s of migration traffic. + +This actually turns out to be related to dd's default block size. By default, dd uses a block size of 512. The effect of this is that qemu fills the pipe buffer very quickly because dd just is submitting very small requests (that will require a RMW). + +If you set an explict block size with dd (via bs=1M), you'll notice a significant improvement in throughput. + +So I think this turns out to be a libvirt issue, not a qemu issue. + +I filed an upstream libvirt bug for the dd block size issue: + +https://bugzilla.redhat.com/show_bug.cgi?id=599091 + +Changing to libvirt as commentary here, and on the upstream bug report by Cole indicate a fix has been commit that improves this performance. + +Re-introducing qemu-kvm, as commentary on qemu-devel mailing list suggest there could be a timing concern meaning poor performance. Leaving Libvirt on this report, as upstream libvirt have quoted improved performance adjusting the block size for dd. However, Qemu feel that the real issue is in the qemu/kvm code. + +Thanks. + +Do you have a link for the qemu-devel thread? I had a look at http://lists.gnu.org/archive/html/qemu-devel/ but couldn't see anything. + +Just a note that the 0.8.1 release available in maverick gives me about +a 50-second save for a 512M memory image (producing 100M outfile). The +patch listed above and suspected of speeding the saves is not in 0.8.1. +When I hand-apply just that patch, saves take about 8 seconds, but +restore fails. Presumably taking the whole of latest git (or 0.8.2 +whenever it is released) will result in both working and fast +save/restore. + + +You may want to try the patch to qemu that avi just posted to the qemu-devel mailing list. I think this would probably fix your issue. + +Iggy, which patch exactly? I don't seem to be able to find it. + +Frederic, this patch: +http://<email address hidden>/msg37743.html + +Frederick, + +please let me know if you can confirm that this patch fixes it for you. If you need +me to set up a ppa with that patch, please let me know. + +@earl, + +thanks for finding the specific patch! + +Will a fix for this go into maverick? + +This is quite critical for using kvm/libvirt for virtual server hosting on maverick. + +The patch is in 0.13.0, so changing the status. + +How should I interpret "Fix Released"? + +qemu in maverick is still 0.12.5 and 0.12.3 in lucid. + +Will this not be fixed in current stable LTS and non-LTS releases? + +Michael Tokarev <email address hidden> writes: + +> 03.01.2011 16:23, EsbenHaabendal wrote: +>> How should I interpret "Fix Released"? +>> +>> qemu in maverick is still 0.12.5 and 0.12.3 in lucid. +> +> Not all the world is ubuntu. In qemu (and qemu-kvm) the +> issue is fixed in 0.13, which were released quite some +> time ago. +> +>> Will this not be fixed in current stable LTS and non-LTS releases? +> +> There's no "stable LTS" and "non-LTS" releases in qemu, +> there are plain releases. + +Ok. I see. + +And the current importance for libvirt (Ubuntu) and qemu-kvm (Ubuntu) is +marked as "Wishlist". + +So my question goes to these two components. When can we expect to see +this fixed in current Ubuntu releases, of which I currently count at +least maverick and lucid. + +Hi, + +please test the qemu-kvm packages in ppa:serge-hallyn/virt for lucid (0.12.3+noroms-0ubuntu10slowsave2) and maverick (0.12.5+noroms-0ubuntu7slowsave2), which have the proposed patch from upstream. If they succeed, then I will proceed with the SRU. + + + + + + +In order to proceed with SRU, we need someone to confirm that the debs in comment #21 or #22 work for them. + +Using ubuntu natty narwhal installed today (2011-03-24) I tried to do a snapshot with the help of libvirt. Here are the results using natty version of qemu-kvm and libvirt and using presented slowdown packages. + +root@koberec:~# time virsh snapshot-create 1 +Domain snapshot 1300968929 created + +real 4m39.594s +user 0m0.000s +sys 0m0.020s +root@koberec:~# cd /storage/slowsave/ +root@koberec:/storage/slowsave# dpkg -l | grep -E 'libvirt|qemu' +ii libvirt-bin 0.8.8-1ubuntu5 the programs for the libvirt library +ii libvirt0 0.8.8-1ubuntu5 library for interfacing with different virtualization systems +ii qemu-common 0.14.0+noroms-0ubuntu3 qemu common functionality (bios, documentation, etc) +ii qemu-kvm 0.14.0+noroms-0ubuntu3 Full virtualization on i386 and amd64 hardware +root@koberec:/storage/slowsave# dpkg -r qemu-common qemu-kvm +root@koberec:/storage/slowsave# dpkg -i qemu-common_0.12.5+noroms-0ubuntu7.2_all.deb qemu-kvm_0.12.5+noroms-0ubuntu7.2_amd64.deb +root@koberec:/storage/slowsave# pkill kvm; sleep 5; service libvirt-bin restart +root@koberec:/storage/slowsave# time virsh snapshot-create 1 +Domain snapshot 1300969754 created + +real 2m22.055s +user 0m0.000s +sys 0m0.010s +root@koberec:/storage/slowsave# qemu-img snapshot -l /storage/debian.qcow2 | tail -n 1 +8 1300969754 57M 2011-03-24 08:29:14 00:03:37.652 +root@koberec:/storage/slowsave# virsh console 1 +Connected to domain vm +Escape character is ^] + +Debian GNU/Linux 5.0 debian ttyS0 + +debian login: root +Password: +Last login: Thu Mar 24 08:15:18 EDT 2011 on ttyS0 +Linux debian 2.6.26-2-amd64 #1 SMP Thu Sep 16 15:56:38 UTC 2010 x86_64 + +The programs included with the Debian GNU/Linux system are free software; +the exact distribution terms for each program are described in the +individual files in /usr/share/doc/*/copyright. + +Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent +permitted by applicable law. +debian:~# free -m + total used free shared buffers cached +Mem: 561 39 521 0 4 16 +-/+ buffers/cache: 19 542 +Swap: 478 0 478 +debian:~# +root@koberec:/storage/slowsave# dd if=/dev/urandom of=/storage/emptyfile bs=1M count=40 +40+0 records in +40+0 records out +41943040 bytes (42 MB) copied, 5.4184 s, 7.7 MB/s + + +I am not sure if my measurements are relevant to anything in here, but I hope so. + +Thanks for that info. That is unexpected. Could you send the xml description of the domain you were snapshotting, as well as the format of the backing file (i.e. qemu-img info filename.img) and what filesystem it is stored on (or whether it is LVM)? I'd like to try to reproduce it. + +Since you are seeing this in natty, it seems certain that while your symptom is the same as that in the original bug report, the cause is different. So it may be best to open a new bug report to track down the new issue in natty. + + +To be clear, please re-install the stock natty packages, do a virsh snapshot-create, and then do 'ubuntu-bug libvirt-bin' to file a new bug. Then please give the info I asked for in comment 25 in that bug. + +Thanks! + +In reply to question #26 https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/741887 + +In reply to question #25: everything is included in #27. Is it enough? + +Yes, thanks. + +I'd like to help get this fixed, particularly in Lucid. What can I do? Does #21 and #22 still need testing? + +@Jeff, + +they do still need testing. However at this point new ones need to be generated. There is a bit of a backlog on libvirt updates to push. Depending on how those go, I could get packages into -proposed either next week or in 2-3 weeks. + +I'll make a note to queue this, and ping here when I've pushed a fix to -proposed, asking you to test. + +Thanks! + +Oops, this is for qemu-kvm, not libvirt. That can go immediately. + +(setting importance to medium because it has a moderate impact on a core application, and especially because it has no workaround) + +Ok, great! Thanks for the quick response. I did just now get finished testing the packages you attached in #21 using my lucid box. Saves of a 256Mb guest went from ~50 seconds to ~3. So it does seem to fix the issue. I can set up a Maverick box if you need it tested there as well. + +I checked for basic functionality with the packages you provided and the basics seem to work, (virsh start, stop, restore, save. Guest disk, net, vnc) but I didn't do much more. How deep should I go testing for regressions? + +Actually maverick is waiting for a fix for bug 790145 to be verified, but lucid is free. I've uploaded the proposed fix to lucid-proposed, it's waiting for an SRU admin to approve it. I will also post the amd64 lucid .debs at http://people.canonical.com/~serge/qemu-slow-save/. + +Hello Chris, or anyone else affected, + +Accepted qemu-kvm into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance! + +Tested 0.12.3+noroms-0ubuntu9.14 on Lucid amd64 with all available updates. Save speed is now approx 3 seconds for a 256Mb guest. Tested virsh with start, stop, save, restore, suspend, resume, shutdown, destroy. Tested guest with smp, virtio disk, virtio net, vnc display. Everything worked as expected. + +If there's more I can do, let me know. Thanks! + +Jeff thanks for the testing! + +I'll take that as verification.. marking verification-done. It just needs to wait 7 days to clear -proposed in case it causes any unintended regressions. + +I'm sorry, the lucid qemu-kvm update has been superseded by a security update in 0.12.3+noroms-0ubuntu9.15. + +I'm sorry - per the rules listed in https://wiki.ubuntu.com/StableReleaseUpdates, only bugs which are >= high priority are eligible for SRU. If you feel this bug should be high priority, please say so (with rationale) here. + +An updated package for lucid through natty will be placed in the ubuntu-virt ppa (https://launchpad.net/~ubuntu-virt/+archive/ppa) as an alternative way to get this fix. + + +The page you referenced doesn't include anything that I can find about the ticket priority level. It states that "Stable release updates will, in general, only be issued in order to fix high-impact bugs" and provides several examples. Among them is "Bugs which do not fit under above categories, [security vulnerabilities, severe regressions, or loss of user data] but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)." + +I submit that this is an "obviously safe patch." The change is small, simple, isolated, has been tested to work, and doesn't change any interfaces. Is qemu-kvm considered a "critical infrastructure package" or not? I don't know the answer to that, but I can see valid arguments both for and against. + +I also have an example of a potential data loss situation, though it is admittedly somewhat weak. I'll spare everyone the narrative but I'll share it if it would be helpful. + +Serge - why do you think this can't be SRU'd? It's already been accepted into lucid-proposed once, then verified, and the only reason it's not in lucid-updates is that it got superseded by a security upload before the 7-day testing period had elapsed. + +If you made a new upload to lucid-proposed based on the new security upload I see no reason why it couldn't be accepted and then copied to -updates after it's been verified and the 7-day testing period has ended. + +I see activity around this bug is going on and on, but I don't understand -- is the talk about this patch -- +http://anonscm.debian.org/gitweb/?p=collab-maint/qemu-kvm.git;a=commit;h=7e32b4ca0ea280a2e8f4d9ace1a15d5e633d9a95 + +? + +Michael: Yes, that is the correct patch. + +I just wanted to point out that we've this patch in Debian since ages, and it's been included in upstream for a long time too. Added a debbug reference for this as well. + +@Serge @Chris - So it sounds like this _could_ make it into Lucid? Anyone I can bribe to make that happen? + +As an aside, I have been running LTS versions for 8 years and I must say it seems we need a different priority scale for LTS. This bug renders the use of kvm in 10.04 very painful and the plan would be to let that exist for 5 years? Feels like a lot of key improvements are overlooked because they don't make your machine explode, but from a sys admins perspective, it feels like the risks of running the latest versions so bug fixes trickle in outweighs the missing bits in an unmaintained LTS :/ + +This issue + this one (https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/555981) makes for a sad day. + +Hello Chris, or anyone else affected, + +Accepted qemu-kvm into lucid-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance! + +Lucid 10.04.4 amd64 host. 2.6.32-38-server. All packages up to date. + +Guest: + Win 7 64bit + 1Gb RAM (all in use in guest) + 2 vproc + VirtIO disk (virtio-win-0.1-22) + VirtIO network + 2 IDE cdroms + VNC display + +virsh save: + 0.12.3+noroms-0ubuntu9.17 503.8 seconds + 0.12.3+noroms-0ubuntu9.18 26.4 seconds + +Tested virsh start, stop, save, restore, suspend, resume, shutdown, destroy. All works as expected. Guest functionality unchanged. + +Thanks Jeff! Barring any regressions being reported, this should arrive in lucid-updates around the 24th. + +Is something holding up the release to lucid-updates? + +Ben, yes, sorry I missed the fact that there was already another bug that needs verification in lucid-proposed. Bug #592010 needs to be verified, or reverted, before this one can proceed to lucid-updates. Verification is tricky, since one needs to do a hardy -> lucid upgrade to verify it. + +I'll go stand up some vms to test that one out. + +I tested that other bug. As far as I can tell it is not fixed. I haven't gotten any sort of response on it for a week. So... now what? + +This bug was fixed in the package qemu-kvm - 0.12.3+noroms-0ubuntu9.18 + +--------------- +qemu-kvm (0.12.3+noroms-0ubuntu9.18) lucid-proposed; urgency=low + + [ Michael Tokarev ] + * QEMUFileBuffered:-indicate-that-were-ready-when-the-underlying-file-is-ready.diff + (patch from upstream to speed up migration dramatically) + (closes: #597517) (LP: #524447) + + [ Serge Hallyn ] + * debian/control: make qemu-common replace qemu (<< 0.12.3+noroms-0ubuntu9.17) + (LP: #592010) + -- Serge Hallyn <email address hidden> Mon, 13 Feb 2012 11:24:18 -0600 + +Just wanted to say thanks to everyone who got this fix out. Works great! + +See https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/524447/comments/5 + +Apparently increasing the dd block size greatly increases the speed of the domain save operation. + +commit 20206a4bc9f1293c69eca79290a55a5fa19976d5 in libvirt git changes the dd blocksize to 1M. This decreased the time required for a save of a suspended 512MB guest from 3min47sec to 56sec. + +An additional patch avoids the overhead of seeking to a 1M alignment: +https://www.redhat.com/archives/libvir-list/2010-June/msg00239.html + +This is included in 0.8.2. In addition upstream QEMU has identified & fixed a flaw that had significant speed impact + diff --git a/results/classifier/105/network/539 b/results/classifier/105/network/539 new file mode 100644 index 00000000..94fa1487 --- /dev/null +++ b/results/classifier/105/network/539 @@ -0,0 +1,14 @@ +network: 0.872 +device: 0.836 +instruction: 0.731 +graphic: 0.317 +semantic: 0.293 +mistranslation: 0.250 +socket: 0.105 +boot: 0.052 +other: 0.046 +vnc: 0.035 +assembly: 0.008 +KVM: 0.006 + +Abort in vmxnet3_validate_interrupt_idx diff --git a/results/classifier/105/network/551545 b/results/classifier/105/network/551545 new file mode 100644 index 00000000..3dfd2fe0 --- /dev/null +++ b/results/classifier/105/network/551545 @@ -0,0 +1,500 @@ +network: 0.920 +assembly: 0.920 +device: 0.912 +graphic: 0.881 +boot: 0.853 +socket: 0.845 +instruction: 0.837 +KVM: 0.835 +vnc: 0.821 +other: 0.803 +semantic: 0.701 +mistranslation: 0.699 + +PXE netboot not booting localboot from virtio-disk + +Binary package hint: qemu-kvm + +lsb_release -rd +Description: Ubuntu lucid (development branch) +Release: 10.04 + +apt-cache policy qemu-kvm +qemu-kvm: + Installiert: 0.12.3+noroms-0ubuntu3 + Kandidat: 0.12.3+noroms-0ubuntu3 + Versions-Tabelle: + *** 0.12.3+noroms-0ubuntu3 0 + 500 http://intranet/ubuntu/ lucid/main Packages + 100 /var/lib/dpkg/status + +Description of the problem: + +Starting a guest like this: + +vdekvm \ + -m 256M \ + -cpu host \ + -smp 1 \ + -name karmic \ + -boot order=nc \ + -drive file=/dev/vg01/test,if=virtio,boot=on,cache=none \ + -net nic,vlan=0,macaddr=00:2f:8d:b6:cf:d0,model=virtio \ + -net vde,vlan=0,sock=/var/run/vde2/vde0.ctl \ + -watchdog i6300esb \ + -vnc :0 \ + -serial telnet:localhost:23,server,nowait \ + -monitor tcp:127.0.0.1:12000,server,nowait \ + -runas kvmguest + +On "telnet localhost" you can see that the following boot-menu appears: + +- Boot Menu - +============= + +local +rescue + +It is loaded from this pxelinux.cfg/default file: + +SERIAL 0 9600n8 + +DISPLAY boot.txt + +TIMEOUT 120 +DEFAULT local +PROMPT 1 + +LABEL local + localboot 0 + +LABEL rescue + kernel lucid + append initrd=lucid-initrd.gz rescue/enable=true -- quiet console=ttyS0,9600n8 + + +After the timeout, the guest tries to boot, but fails and reloads the boot menu. This is an endless loop, until I break it or choose the rescue menu entry. + +I would expect that it boots from first virtio-disk + +ProblemType: Bug +DistroRelease: Ubuntu 10.04 +Package: qemu-kvm 0.12.3+noroms-0ubuntu3 +ProcVersionSignature: Ubuntu 2.6.32-18.27-generic 2.6.32.10+drm33.1 +Uname: Linux 2.6.32-18-generic x86_64 +Architecture: amd64 +Date: Tue Mar 30 11:40:59 2010 +ExecutablePath: /usr/bin/qemu-system-x86_64 +MachineType: MICRO-STAR INTERANTIONAL CO.,LTD MS-7368 +ProcCmdLine: root=UUID=0d27271c-feaa-40d9-bbbd-baff4ca1d3cc rw init=/bin/bash +ProcEnviron: + LANG=de_DE.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-kvm +dmi.bios.date: 10/31/2007 +dmi.bios.vendor: American Megatrends Inc. +dmi.bios.version: V1.5B2 +dmi.board.asset.tag: To Be Filled By O.E.M. +dmi.board.name: MS-7368 +dmi.board.vendor: MICRO-STAR INTERANTIONAL CO.,LTD +dmi.board.version: 1.0 +dmi.chassis.asset.tag: To Be Filled By O.E.M. +dmi.chassis.type: 3 +dmi.chassis.vendor: To Be Filled By O.E.M. +dmi.chassis.version: To Be Filled By O.E.M. +dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV1.5B2:bd10/31/2007:svnMICRO-STARINTERANTIONALCO.,LTD:pnMS-7368:pvr1.0:rvnMICRO-STARINTERANTIONALCO.,LTD:rnMS-7368:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: +dmi.product.name: MS-7368 +dmi.product.version: 1.0 +dmi.sys.vendor: MICRO-STAR INTERANTIONAL CO.,LTD + + + +According to your command line: + +-boot order=nc \ + + +I don't think that this include a local hard disk as part of the list of devices to be considered for booting. + +Directly from the manpage: + +-boot [order=drives][,once=drives][,menu=on|off] + Specify boot order drives as a string of drive letters. Valid drive letters depend on the target achitecture. The x86 PC uses: a, b (floppy 1 and + 2), c (first hard disk), d (first CD-ROM), n-p (Etherboot from network adapter 1-4), hard disk boot is the default. To apply a particular boot + order only on the first startup, specify it via once. + + Interactive boot menus/prompts can be enabled via menu=on as far as firmware/BIOS supports them. The default is non-interactive boot. + + # try to boot from network first, then from hard disk + qemu -boot order=nc + +So this should work?? Don't know. Even does not work with not specifying if=virtio. + +By the way: PXELinux ignores timeout, if prompt is set. So this seems to be a second bug (this worked on karmic). + +Also, vde networking will not work with Lucid's kvm. To use vde +networking, we'd need to build qemu-kvm with libvde2, which we cannot +do because it's in Universe. + +Please consider using one of the other more secure, officially +supported networking models: + * https://help.ubuntu.com/community/KVM/Networking + +VDE is very great. I use it since many months and had NEVER any problems. There is no better solution than cde. And I do not understand, why you do not put it into main repo. Sayin: insecure is not a good answer without telling where. + +So does it mean, the wrapper vdekvm will be kicked in Lucid? That would break all servers, which used it! + +this bug has nothing to do with VDE. It seems that ubuntu's current version of libvirt/kvm-qemu does not implement boot ordering correctly. + +this seems to be present in fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=472236 + +Hi, + +could you test whether you still have this problem with lucid-proposed? + +lucid-updates and lucid-proposed ship the same package and from the changelog I cannot see what change would be related to this big. + +I've just confirmed by testing that the bug still applies to the most uptodate packages that are available for lucid. + +Still a problem in Lucid, making automatic installation and deployment of VMs (using Cobbler or Foreman) pretty much impossible without manual intervention. This, of course, defeats the whole point of automatic installation and deployment. + +This issue should be fixed in the qemu-kvm version included in precise. + +Since it has been fixed in Precise ... I assume this has also been fixed in upstream QEMU? Or is there still anything left to do here? + +There hasn't been a reply to my question in the last comment within months, so I assume this has been fixed in upstream, too. Closing this ticket now... + +Description of problem: + +All QA automated systems rely on PXE local booting for proper provisioning and testing. All systems are configured in the BIOS to boot PXE first. + +When we want to provision the systems, we modify the PXE target (using RHTS or now cobbler). + +When we want to boot locally to run tests, we set the default PXE target to "local". + +KVM guests do no honor the PXE "local" target. It seems that once you boot PXE, KVM doesn't attach the already installed disks. + +Version-Release number of selected component (if applicable): + +kernel-2.6.27.5-113.fc10.x86_64 +libvirt-0.4.6-3.fc10.x86_64 +kvm-74-5.fc10.x86_64 + +How reproducible: + +Every time. + +Steps to Reproduce: +1. Set KVM guest PXE target to "Network Boot" using virt-manager +2. Boot the KVM guest. +3. In the PXE menu, type "local" + +Actual results: + + * See attached screenshot, xml, and libvirt logfile. + +Expected results: + +The system should behave as a "real" system behaves and boot the local disk. + +Additional info: + + * This makes adding KVM guests into test automation a bit funky since we'll need to do a workaround which involves: + +When you want to reprovision a guest: + 1) virsh destroy $GUEST + 2) virsh undefine $GUEST + 3) Edit xml to boot off network + 4) virsh define $XMLFILE + 5) virsh start $GUEST + +We'd then need to repeat to have it boot to local disk. + +Created attachment 324048 +Screenshot + +Created attachment 324049 +Guest XML configuration + +Created attachment 324050 +/var/log/libvirt/qemu/vguest2.log + +Being able to boot KVM-via-PXE statefully would be highly useful for my testing in Cobbler land as well, and would help with virtual deployment (and re-deployment) of non-Linux guests. + +The XML only specifies a single device for booting. Can you try setting multiple devices + + <boot dev='network'/> + <boot dev='cdrom'/> + <boot dev='hd'/> + +Which should tell the BIOS to try to boot network, then cdrom, then harddisk in that order. + +Using ... + + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='network'/> + <boot dev='cdrom'/> + <boot dev='hd'/> + </os> + +Results in ... + +# cat /var/log/libvirt/qemu/vguest2.log +/usr/bin/qemu-kvm -S -M pc -m 1024 -smp 2 -name vguest2 -monitor pty -boot ndc -drive file=/dev/VolGroup00/vguest2,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:29:89:e5,vlan=0,model=virtio -net tap,fd=16,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:1 -k en-us +char device redirected to /dev/pts/3 +char device redirected to /dev/pts/4 +Too many option ROMS + +Amy I doing that right? + +Wow! I didn't know you could specify multiple boot devs. Using + + <boot dev='network'/> + <boot dev='hd'/> + +And then pressing 'q' to not boot from networking successfully boots from disk. James, try just the above and see if it does the job for you. + +Cole, what we are looking for is when the bootloader is fed the following PXE configuration it should boot from the local disk: + +DEFAULT local +PROMPT 0 +TIMEOUT 0 +TOTALTIMEOUT 0 +ONTIMEOUT local + +LABEL local + LOCALBOOT 0 + + +This will enable us to create a KVM "empty shell" that we can assign what OS it is running just based on changing the PXE configuration. + +Pressing "q" would be interactive and less useful -- you'd have to catch it really really quickly or you'd be reinstalling. + +(In reply to comment #7) +> Wow! I didn't know you could specify multiple boot devs. Using +> +> <boot dev='network'/> +> <boot dev='hd'/> +> +> James, try just the above and see if it does the job for you. + +With those options in my XML ... my guest fails to start. + +# virsh dumpxml vguest2 | grep -C2 "<boot" + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='network'/> + <boot dev='hd'/> + </os> + <features> + +# virsh start vguest2 +libvir: QEMU error : internal error QEMU quit during monitor startup +error: Failed to start domain vguest2 + +# tail /var/log/libvirt/qemu/vguest2.log +/usr/bin/qemu-kvm -S -M pc -m 1024 -smp 2 -name vguest2 -monitor pty -boot nc -drive file=/dev/VolGroup00/vguest2,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:29:89:e5,vlan=0,model=virtio -net tap,fd=12,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:1 -k en-us +char device redirected to /dev/pts/3 +char device redirected to /dev/pts/4 +Too many option ROMS + +What am I missing? + +jlaska: hmm, works on F9. sounds like a bug. + +mdehaan: you may just have to test it and see what happens. I let the guest boot to our pxe server which doesn't seem to have an explicit 'local' option. Hitting enter without a selection seems to imply local, but qemu then prompts for the boot from (n)etwork or (q)uit. + +Maybe qemu is smart enough to notice a 'boot from local' directive from the PXE server, and won't prompt. You'll just have to test it since I'm not sure how to go about it. + +Cole, that's what james was trying to do above when he filed the bug, and I watched it happen. + +""" +KVM guests do no honor the PXE "local" target. It seems that once you boot +PXE, KVM doesn't attach the already installed disks. +""" + +What specifically should I test? + +I just wasn't sure if: + +not entering a selection on my pxe server & pressing enter == deliberately selecting 'boot from local' on another pxe server == having the pxe server tell the machine/VM 'hey, boot from local' (which is what I understand RHTS does). + +If those are all equivalent, then it sounds like qemu needs fixing to not prompt based on the pxe request. + +My take on this bug is that the F10 kvm/libvirt doesn't let me specify multiple <boot> options. If that were fixed, I suspect it would open the door for PXE "local" booting. + +Yes, this is a bug in KVM. The trouble is the new -drive flag and its boot=on syntax is broken wrt to normal -boot arg. We need to use boot=on for VirtIO based disks, but when we do that, then this conflicts with the option ROM for PXE boot. This is a big mess and I'm not sure how to fix it, but it certainly needs addressing somehow, because this is a valid use case + + +This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. +Changing version to '10'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +James, + +Do you still have this problem if you switch from virtio to e1000? + +You should use this XML excerpt: + <boot dev='network'/> + <boot dev='hd'/> + +Created attachment 324720 +vguest1.xml (w/ multiple <boot> and dev="virtio") + +Glauber, + +Yeah, I still seem to have this problem using virtio. + +# virsh start vguest1 +libvir: QEMU error : internal error QEMU quit during monitor startup +error: Failed to start domain vguest1 + +# cat /var/log/libvirt/qemu/vguest1.log +/usr/bin/qemu-kvm -S -M pc -m 1024 -smp 2 -name vguest1 -monitor pty -boot nc -drive file=/dev/VolGroup00/vguest1,if=ide,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:55:c8:17,vlan=0,model=virtio -net tap,fd=14,script=,vlan=0,ifname=vnet2 -serial pty -parallel none -usb -vnc 127.0.0.1:3 -k en-us +char device redirected to /dev/pts/8 +char device redirected to /dev/pts/9 +Too many option ROMS + +# virsh dumpxml vguest1 + <!-- see attachment --> + +Created attachment 324721 +vguest1.xml (w/ multiple <boot> and dev="e1000") + +Now with dev="e1000" + +# virsh start vguest1 +libvir: QEMU error : internal error QEMU quit during monitor startup +error: Failed to start domain vguest1 + +# cat /var/log/libvirt/qemu/vguest1.log +/usr/bin/qemu-kvm -S -M pc -m 1024 -smp 2 -name vguest1 -monitor pty -boot nc -drive file=/dev/VolGroup00/vguest1,if=ide,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:55:c8:17,vlan=0,model=e1000 -net tap,fd=19,script=,vlan=0,ifname=vnet2 -serial pty -parallel none -usb -vnc 127.0.0.1:3 -k en-us +char device redirected to /dev/pts/8 +char device redirected to /dev/pts/9 +Too many option ROMS + +I believe the problem itself is very simple (although I don't really know a good solution without thinking a little bit...) + +there's only 64k of memory available for option roms, and the virtio rom that ships with our packages is... 64k in size!. So after loading the virtio PXE option rom, we're unable to keep loading option roms, in particular, the extboot option rom we need to kick out virtio boots. ;-( + +James said he could boot with an older rom I handled to him, which is 32k in size, +and the problem os "Too many option ROMS" went away. + +However, he was still unable to boot from the local target, despite of the fact that he could do a local boot by pressing "q" + +So we really have two problems in here: + +The first one is that we cannot boot from our current virtio ROM, because it is too large. We can try to quick fix it by building smaller images. This should be a new BZ agains the etherboot package. + +And the other, the fact that roms do not honor the local target. For that, I believe we can keep using this BZ. + +(In reply to comment #19) +> So we really have two problems in here: +> +> The first one is that we cannot boot from our current virtio ROM, because it is +> too large. We can try to quick fix it by building smaller images. This should +> be a new BZ agains the etherboot package. + +Filed this as bug#473137 + +Apparently this is still a problem with gPXE: + +http://www.redhat.com/archives/fedora-virt/2009-October/msg00052.html + +Glauber - please take a look + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + + +This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. +Changing version to '13'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +Still problem on Fedora 13 final + updates testing. Any change to fix this? + +I have some success to boot using PXE by booting manually. May be there is too short default timeout for dhcp request. Try this: + +1. start virtual machine +2. when you are prompted to press CTRL-B do it +3. try to get dhcp address running this command: dhcp net0 +4. repeat step 3 until you do not get address (reply "ok") +5. boot using command: autoboot + +If you run "dhcp net0" command immediatelly, it will fail fist time, but second run gets IP address. Then I am able to boot from PXE. + +I think local boot works well on current fedora 13 stable. Do you still have this problem? + +But another problem described here (timeout to boot from PXE) is still present. Should I open a new bug for this? Looks like it's enough to increase PXE network timeout by aprox. 3 seconds. Most simpler workaround is to select "Send Key -> Ctrl-Alt-Del" from menu immediatelly (or after 1-3 seconds) after guest start. + +I'm still having this dhcp timeout issue on f13. + +Opened https://bugzilla.redhat.com/show_bug.cgi?id=638735 to track it. + + +This message is a reminder that Fedora 13 is nearing its end of life. +Approximately 30 (thirty) days from now Fedora will stop maintaining +and issuing updates for Fedora 13. It is Fedora's policy to close all +bug reports from releases that are no longer maintained. At that time +this bug will be closed as WONTFIX if it remains open with a Fedora +'version' of '13'. + +Package Maintainer: If you wish for this bug to remain open because you +plan to fix it in a currently maintained version, simply change the 'version' +to a later Fedora version prior to Fedora 13's end of life. + +Bug Reporter: Thank you for reporting this issue and we are sorry that +we may not be able to fix it before Fedora 13 is end of life. If you +would still like to see this bug fixed and are able to reproduce it +against a later version of Fedora please change the 'version' of this +bug to the applicable version. If you are unable to change the version, +please add a comment here and someone will do it for you. + +Although we aim to fix as many bugs as possible during every release's +lifetime, sometimes those efforts are overtaken by events. Often a +more recent Fedora release includes newer upstream software that fixes +bugs or makes them obsolete. + +The process we are following is described here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + + +Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is +no longer maintained, which means that it will not receive any further +security or bug fix updates. As a result we are closing this bug. + +If you can reproduce this bug against a currently maintained version of +Fedora please feel free to reopen this bug against that version. + +Thank you for reporting this bug and we are sorry it could not be fixed. + +Reopen, bump to rawhide, I haven't been able to test this recently. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +With virt-manager on F17 this works for me, you just need to make sure that both network and harddrive boot options are selected, otherwise the disks aren't marked as bootable and things probably won't work. + +Closing as WORKSFORME, please reopen if anyone still has issues on F17+ + +Created attachment 600144 +no prompt + +it seems it's not even prompting for ipxe now. I think something got hardcoded into the rom by accident. + +Can somebody verify? + +Renich, given how old and long this bug report is, let's keep it closed. If you are still experiencing a similar issue, please open a new bug report with the following info: + +Fedora version +qemu version +qemu command line (if using libvirt, /var/log/libvirt/qemu/$vmname.log) + + +At least on F17, PXE and boot from local is working fine for me. + diff --git a/results/classifier/105/network/557 b/results/classifier/105/network/557 new file mode 100644 index 00000000..01bc320f --- /dev/null +++ b/results/classifier/105/network/557 @@ -0,0 +1,14 @@ +network: 0.800 +device: 0.661 +graphic: 0.546 +instruction: 0.471 +boot: 0.099 +semantic: 0.047 +mistranslation: 0.046 +assembly: 0.040 +other: 0.027 +socket: 0.020 +vnc: 0.011 +KVM: 0.002 + +Stack-overflow through pcnet_tmd_load diff --git a/results/classifier/105/network/559 b/results/classifier/105/network/559 new file mode 100644 index 00000000..41de3789 --- /dev/null +++ b/results/classifier/105/network/559 @@ -0,0 +1,14 @@ +network: 0.553 +mistranslation: 0.526 +device: 0.501 +semantic: 0.205 +graphic: 0.181 +boot: 0.162 +instruction: 0.089 +socket: 0.076 +other: 0.061 +KVM: 0.049 +vnc: 0.024 +assembly: 0.003 + +info does not recognize file format of vpc with subformat=fixed diff --git a/results/classifier/105/network/580 b/results/classifier/105/network/580 new file mode 100644 index 00000000..1a6ebf74 --- /dev/null +++ b/results/classifier/105/network/580 @@ -0,0 +1,30 @@ +network: 0.995 +graphic: 0.991 +device: 0.926 +socket: 0.893 +mistranslation: 0.850 +semantic: 0.814 +instruction: 0.775 +vnc: 0.765 +boot: 0.694 +other: 0.693 +assembly: 0.596 +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/105/network/590552 b/results/classifier/105/network/590552 new file mode 100644 index 00000000..801c6cde --- /dev/null +++ b/results/classifier/105/network/590552 @@ -0,0 +1,36 @@ +network: 0.851 +mistranslation: 0.719 +graphic: 0.716 +semantic: 0.701 +device: 0.685 +other: 0.643 +socket: 0.502 +instruction: 0.479 +vnc: 0.403 +boot: 0.292 +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/105/network/593 b/results/classifier/105/network/593 new file mode 100644 index 00000000..11c41741 --- /dev/null +++ b/results/classifier/105/network/593 @@ -0,0 +1,20 @@ +network: 0.973 +device: 0.920 +graphic: 0.760 +vnc: 0.551 +other: 0.495 +socket: 0.477 +mistranslation: 0.464 +semantic: 0.450 +boot: 0.405 +instruction: 0.264 +KVM: 0.175 +assembly: 0.060 + +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/105/network/605 b/results/classifier/105/network/605 new file mode 100644 index 00000000..70c0e831 --- /dev/null +++ b/results/classifier/105/network/605 @@ -0,0 +1,28 @@ +network: 0.992 +graphic: 0.986 +boot: 0.973 +device: 0.949 +instruction: 0.912 +vnc: 0.889 +semantic: 0.638 +socket: 0.616 +mistranslation: 0.442 +KVM: 0.235 +other: 0.215 +assembly: 0.057 + +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/105/network/62179944 b/results/classifier/105/network/62179944 new file mode 100644 index 00000000..7be6c389 --- /dev/null +++ b/results/classifier/105/network/62179944 @@ -0,0 +1,39 @@ +network: 0.966 +graphic: 0.907 +device: 0.818 +instruction: 0.693 +socket: 0.608 +boot: 0.567 +mistranslation: 0.533 +other: 0.519 +vnc: 0.498 +semantic: 0.454 +assembly: 0.275 +KVM: 0.153 + +[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/105/network/626 b/results/classifier/105/network/626 new file mode 100644 index 00000000..824204d3 --- /dev/null +++ b/results/classifier/105/network/626 @@ -0,0 +1,14 @@ +network: 0.682 +device: 0.641 +instruction: 0.507 +graphic: 0.415 +semantic: 0.372 +boot: 0.369 +mistranslation: 0.345 +other: 0.175 +socket: 0.130 +assembly: 0.117 +vnc: 0.106 +KVM: 0.035 + +plugin reference to qemu_plugin_hwaddr_phys_addr fails to dynamically link diff --git a/results/classifier/105/network/641118 b/results/classifier/105/network/641118 new file mode 100644 index 00000000..1dccfc22 --- /dev/null +++ b/results/classifier/105/network/641118 @@ -0,0 +1,30 @@ +network: 0.989 +device: 0.805 +boot: 0.802 +mistranslation: 0.763 +vnc: 0.734 +graphic: 0.724 +instruction: 0.717 +socket: 0.679 +semantic: 0.670 +other: 0.418 +KVM: 0.324 +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/105/network/676029 b/results/classifier/105/network/676029 new file mode 100644 index 00000000..4d43ed61 --- /dev/null +++ b/results/classifier/105/network/676029 @@ -0,0 +1,62 @@ +network: 0.578 +socket: 0.570 +instruction: 0.519 +KVM: 0.508 +device: 0.445 +other: 0.396 +semantic: 0.377 +mistranslation: 0.368 +graphic: 0.276 +boot: 0.178 +vnc: 0.131 +assembly: 0.082 + +Silently fail with wrong vde socket dir + +Hi, + +Using qemu 0.12.5, kvm silently fail with exit code 1 when using -net vde and a wrong path for sock. Actually, the sock option is mean to be the socket dir of the vde_switch, not the socket itself. + +With -net vde,sock=/var/run/vde/vde0/ctl , strace ends with the following messages : + +connect(7, {sa_family=AF_FILE, path="/var/run/vde/vde0/ctl/ctl"}, 110) = -1 ENOTDIR (Not a directory) +close(7) = 0 +close(8) = 0 +exit_group(1) = ? +root ~# + +Please add a meaningful message. + +Regards, +Étienne + +Hello, + +Could you please provide more data, what kinda of system and version are you running on? + +Jes + + +There's no need to add any more specific information. The bug's in the code in qemu. + +net/vde.c: + +static int net_vde_init(VLANState *vlan, const char *model, + const char *name, const char *sock, + int port, const char *group, int mode) +{ +... + vde = vde_open(init_sock, (char *)"QEMU", &args); + if (!vde){ + return -1; + } +... +} + +There's no message generated there. Callers merely pass the failure up the road, where it's finally handled as exit(1). If _anything_ is wrong in vde_open() (which can fail due to variety of reasons, including wrong path to the listening socket and what not), nothing will indicate that, just a trivial, silent exit. + +Given that you know what the problem is, it would probably have been faster to post a patch than just updating the bug and marking it confirmed.... + +A fix for this problem has finally been contributed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7587855cd23755a7a6bd + diff --git a/results/classifier/105/network/676934 b/results/classifier/105/network/676934 new file mode 100644 index 00000000..16efeacc --- /dev/null +++ b/results/classifier/105/network/676934 @@ -0,0 +1,31 @@ +network: 0.812 +socket: 0.755 +device: 0.684 +mistranslation: 0.673 +graphic: 0.502 +other: 0.501 +semantic: 0.455 +boot: 0.300 +instruction: 0.283 +vnc: 0.242 +KVM: 0.056 +assembly: 0.044 + +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/105/network/741 b/results/classifier/105/network/741 new file mode 100644 index 00000000..9eafcc62 --- /dev/null +++ b/results/classifier/105/network/741 @@ -0,0 +1,14 @@ +network: 0.925 +semantic: 0.403 +mistranslation: 0.277 +graphic: 0.145 +instruction: 0.121 +socket: 0.103 +vnc: 0.067 +device: 0.057 +assembly: 0.050 +KVM: 0.048 +boot: 0.012 +other: 0.003 + +Document "net/net.h" API diff --git a/results/classifier/105/network/762 b/results/classifier/105/network/762 new file mode 100644 index 00000000..45d26693 --- /dev/null +++ b/results/classifier/105/network/762 @@ -0,0 +1,14 @@ +network: 0.855 +instruction: 0.787 +device: 0.780 +graphic: 0.426 +vnc: 0.274 +semantic: 0.173 +boot: 0.147 +KVM: 0.067 +assembly: 0.057 +mistranslation: 0.056 +socket: 0.022 +other: 0.021 + +Assertion failure in iov_from_buf_full `offset == 0' failed through virtio-net diff --git a/results/classifier/105/network/774 b/results/classifier/105/network/774 new file mode 100644 index 00000000..d30fce42 --- /dev/null +++ b/results/classifier/105/network/774 @@ -0,0 +1,28 @@ +network: 0.976 +device: 0.971 +graphic: 0.958 +boot: 0.932 +instruction: 0.850 +vnc: 0.807 +other: 0.764 +semantic: 0.757 +socket: 0.705 +mistranslation: 0.675 +assembly: 0.328 +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/105/network/806656 b/results/classifier/105/network/806656 new file mode 100644 index 00000000..3c2db3bd --- /dev/null +++ b/results/classifier/105/network/806656 @@ -0,0 +1,35 @@ +network: 0.889 +vnc: 0.865 +graphic: 0.853 +mistranslation: 0.816 +semantic: 0.799 +socket: 0.760 +device: 0.751 +other: 0.706 +instruction: 0.622 +KVM: 0.515 +boot: 0.474 +assembly: 0.444 + +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/105/network/807 b/results/classifier/105/network/807 new file mode 100644 index 00000000..1e74a8fa --- /dev/null +++ b/results/classifier/105/network/807 @@ -0,0 +1,31 @@ +network: 0.941 +graphic: 0.934 +other: 0.924 +device: 0.823 +socket: 0.805 +semantic: 0.796 +vnc: 0.723 +assembly: 0.525 +instruction: 0.467 +mistranslation: 0.448 +KVM: 0.322 +boot: 0.251 + +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/105/network/811 b/results/classifier/105/network/811 new file mode 100644 index 00000000..849e0102 --- /dev/null +++ b/results/classifier/105/network/811 @@ -0,0 +1,14 @@ +network: 0.665 +device: 0.642 +mistranslation: 0.527 +instruction: 0.452 +other: 0.327 +semantic: 0.324 +graphic: 0.220 +boot: 0.210 +socket: 0.128 +assembly: 0.105 +vnc: 0.069 +KVM: 0.017 + +qemu_irq_split() callers should use TYPE_SPLIT_IRQ device instead diff --git a/results/classifier/105/network/812 b/results/classifier/105/network/812 new file mode 100644 index 00000000..de7a6776 --- /dev/null +++ b/results/classifier/105/network/812 @@ -0,0 +1,137 @@ +network: 0.569 +device: 0.559 +vnc: 0.530 +other: 0.527 +KVM: 0.515 +instruction: 0.511 +assembly: 0.510 +semantic: 0.501 +graphic: 0.500 +mistranslation: 0.493 +boot: 0.444 +socket: 0.415 + +Multicast packets (mDNS) are not sent out of VM +Description of problem: +The app is sending multicast packets (mDNS), but they are not sent out of VM. +Here is the configuration of the network: `-netdev user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::50051-:50051,hostfwd=tcp::50050-:50050` +Steps to reproduce: +1. Install arduino-cli from https://github.com/arduino/arduino-cli/releases (eg. 0.20.2) +2. `arduino-cli config init` +3. `vi ~/.arduino15/arduino-cli.yaml` +4. edit it to have it as follows: +``` +board_manager: + additional_urls: ["http://arduino.esp8266.com/stable/package_esp8266com_index.json"] +daemon: + port: "50051" +directories: + data: /root/app/data + downloads: /root/app/downloads + user: /root/app/user +library: + enable_unsafe_install: false +logging: + file: "" + format: text + level: info +metrics: + addr: :9090 + enabled: false +output: + no_color: false +sketch: + always_export_binaries: false +updater: + enable_notification: true +``` + +5. `arduino-cli core update-index` +6. `arduino-cli core install esp8266:esp8266` +7. `arduino-cli board list -v` + +This will give an output similar to: +``` +INFO[0000] Using config file: /root/.arduino15/arduino-cli.yaml +INFO[0000] arduino-cli.x86_64 version git-snapshot +INFO[0000] Checking if CLI is Bundled into the IDE +INFO[0000] Adding libraries dir dir=/root/app/user/libraries location=user +INFO[0000] Checking signature index=/root/app/data/package_index.json signatureFile=/root/app/data/package_index.json.sig = +INFO[0000] Checking signature error="opening signature file: open /root/app/data/package_esp8266com_index.json.sig: no such file or d= +INFO[0000] Loading hardware from: /root/app/data/packages +INFO[0000] Loading package builtin from: /root/app/data/packages/builtin +INFO[0000] Checking existence of 'tools' path: /root/app/data/packages/builtin/tools +INFO[0000] Loading tools from dir: /root/app/data/packages/builtin/tools +INFO[0000] Loaded tool tool="builtin:ctags@5.8-arduino11" +INFO[0000] Loaded tool tool="builtin:mdns-discovery@1.0.2" +INFO[0000] Loaded tool tool="builtin:serial-discovery@1.3.1" +INFO[0000] Loaded tool tool="builtin:serial-monitor@0.9.1" +INFO[0000] Loading package esp8266 from: /root/app/data/packages/esp8266/hardware +INFO[0000] Checking signature error="opening signature file: open /root/app/data/packages/esp8266/hardware/esp8266/3.0.2/installed.js= +INFO[0000] Adding monitor tool protocol=serial tool="builtin:serial-monitor" +INFO[0000] Loaded platform platform="esp8266:esp8266@3.0.2" +INFO[0000] Checking existence of 'tools' path: /root/app/data/packages/esp8266/tools +INFO[0000] Loading tools from dir: /root/app/data/packages/esp8266/tools +INFO[0000] Loaded tool tool="esp8266:mklittlefs@3.0.4-gcc10.3-1757bed" +INFO[0000] Loaded tool tool="esp8266:mkspiffs@3.0.4-gcc10.3-1757bed" +INFO[0000] Loaded tool tool="esp8266:python3@3.7.2-post1" +INFO[0000] Loaded tool tool="esp8266:xtensa-lx106-elf-gcc@3.0.4-gcc10.3-1757bed" +INFO[0000] Adding libraries dir dir=/root/app/data/packages/esp8266/hardware/esp8266/3.0.2/libraries location=platform +INFO[0007] Executing `arduino-cli board list` +INFO[0007] starting discovery builtin:serial-discovery process +INFO[0007] started discovery builtin:serial-discovery process +INFO[0007] sending command HELLO 1 "arduino-cli git-snapshot" to discovery builtin:serial-discovery +INFO[0007] starting discovery builtin:mdns-discovery process +INFO[0007] started discovery builtin:mdns-discovery process +INFO[0007] sending command HELLO 1 "arduino-cli git-snapshot" to discovery builtin:mdns-discovery +INFO[0007] from discovery builtin:serial-discovery received message type: hello, message: OK, protocol version: 1 +INFO[0007] from discovery builtin:mdns-discovery received message type: hello, message: OK, protocol version: 1 +INFO[0007] sending command START to discovery builtin:serial-discovery +INFO[0007] sending command START to discovery builtin:mdns-discovery +INFO[0007] from discovery builtin:mdns-discovery received message type: start, message: OK +INFO[0007] from discovery builtin:serial-discovery received message type: start, message: OK +INFO[0008] sending command LIST to discovery builtin:serial-discovery +INFO[0008] sending command LIST to discovery builtin:mdns-discovery +INFO[0008] from discovery builtin:mdns-discovery received message type: list +INFO[0008] from discovery builtin:serial-discovery received message type: list, ports: [/dev/ttyS0] +INFO[0008] sending command STOP to discovery builtin:serial-discovery +INFO[0008] sending command STOP to discovery builtin:mdns-discovery +INFO[0008] from discovery builtin:mdns-discovery received message type: stop, message: OK +INFO[0008] from discovery builtin:serial-discovery received message type: stop, message: OK +Port Protocol Type Board Name FQBN Core +/dev/ttyS0 serial Unknown +``` + +Note `builtin:mdns-discovery` discovery started. It is expected to send the packets as follows (the screenshot from the host with Wireshark): + + + +The screenshot is taken if running the same app (but for macOS) from the host and **i can't see the packets sent if executed from the QEMU guest os**. +I believe i either configured it the wrong way (`-netdev user,id=net0,...`) or it's a QEMU bug. +Additional information: +I've tested on macOS host with qemu 6.0.0 and on Linux (Android) host with qemu 6.1.0 and both were not working. + +the network interface seems to be configured for multicasting: +``` +# ifconfig +eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:57 + inet addr:10.0.2.15 Bcast:0.0.0.0 Mask:255.255.255.0 + inet6 addr: fec0::5054:ff:fe12:3457/64 Scope:Site + inet6 addr: fe80::5054:ff:fe12:3457/64 Scope:Link + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:91955 errors:0 dropped:0 overruns:0 frame:0 + TX packets:25203 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:119904373 (114.3 MiB) TX bytes:1868274 (1.7 MiB) + +lo Link encap:Local Loopback + inet addr:127.0.0.1 Mask:255.0.0.0 + inet6 addr: ::1/128 Scope:Host + UP LOOPBACK RUNNING MTU:65536 Metric:1 + RX packets:0 errors:0 dropped:0 overruns:0 frame:0 + TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) +``` + +It might be easier to skip using arduino-cli and just use any mdns discovery app. diff --git a/results/classifier/105/network/829455 b/results/classifier/105/network/829455 new file mode 100644 index 00000000..14cec404 --- /dev/null +++ b/results/classifier/105/network/829455 @@ -0,0 +1,56 @@ +network: 0.843 +mistranslation: 0.799 +socket: 0.696 +KVM: 0.677 +other: 0.587 +device: 0.566 +vnc: 0.432 +semantic: 0.422 +instruction: 0.402 +boot: 0.292 +assembly: 0.265 +graphic: 0.242 + +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/105/network/838974 b/results/classifier/105/network/838974 new file mode 100644 index 00000000..6aea305a --- /dev/null +++ b/results/classifier/105/network/838974 @@ -0,0 +1,27 @@ +network: 0.905 +semantic: 0.872 +device: 0.802 +socket: 0.709 +vnc: 0.646 +mistranslation: 0.645 +graphic: 0.645 +instruction: 0.617 +other: 0.614 +KVM: 0.586 +boot: 0.526 +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/105/network/874 b/results/classifier/105/network/874 new file mode 100644 index 00000000..960f5516 --- /dev/null +++ b/results/classifier/105/network/874 @@ -0,0 +1,14 @@ +network: 0.803 +device: 0.679 +instruction: 0.393 +boot: 0.389 +graphic: 0.382 +mistranslation: 0.231 +other: 0.196 +semantic: 0.157 +vnc: 0.145 +socket: 0.056 +assembly: 0.004 +KVM: 0.002 + +New Python QMP library races on NetBSD diff --git a/results/classifier/105/network/894037 b/results/classifier/105/network/894037 new file mode 100644 index 00000000..f05ab96d --- /dev/null +++ b/results/classifier/105/network/894037 @@ -0,0 +1,125 @@ +semantic: 0.928 +network: 0.928 +graphic: 0.918 +other: 0.916 +device: 0.910 +assembly: 0.907 +boot: 0.897 +vnc: 0.890 +instruction: 0.889 +mistranslation: 0.851 +socket: 0.851 +KVM: 0.843 + +With VNC, "-usbdevice tablet" no longer makes mouse pointers line up + +I use qemu in VNC mode. In order to get the client and server mouse pointers to line up, I've had to use the "-usbdevice tablet" option. This no longer works, and it behaves the same as if the option is not there. This makes my VMs unusable to me. + +Here's how I'm booting WinXP: + +qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm & + +The Windows install hasn't changed, only qemu. + +I'm running this version of QEMU: + +QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008 Fabrice Bellard + +I'll see about upgrading to 0.15.1, but since I haven't seen other reports of this particular problem in your DB, I'm assuming that this problem has not been fixed between 0.15.0 and 0.15.1. + +Also observed on Fedora 16, qemu-kvm-0.15.1-3.fc16.x86_64 +https://bugzilla.redhat.com/show_bug.cgi?id=754149 + + +Also observed on Ubuntu, extra/qemu-kvm 0.15.0-2 +https://bugs.launchpad.net/qemu/+bug/894037 + + +This bug isn't getting any attention, but it's a total show-stopper for me. It priority should be raised to Critical. I cannot use any of my VMs at all. Please help! + +Thanks. + + +On Mon, Dec 19, 2011 at 3:23 PM, Timothy Miller <email address hidden> wrote: +> This bug isn't getting any attention, but it's a total show-stopper for +> me. It priority should be raised to Critical. I cannot use any of my +> VMs at all. Please help! + +Have you checked that the guest operating system is using the USB +tablet as the mouse input? If it is falling back to the PS/2 mouse +then you will not get synced mouse pointers. + +Stefan + + +That's easier said than done, because it's pretty unusable. And as I said, the OS didn't change. QEMU got updated, and then it broke. So if it was or wasn't using the tablet before, then it still is or isn't now. Either way, it used to work. + +I'll see what I can figure out about what it thinks its input device is. + +Ok, I'm seeing two devices that Windows XP doesn't recognize. One is "QEMU USB Tablet", and the other is "VGA Controller (VGA Compatible)". It doesn't appear to have drivers for these. + +Both of these used to work just fine. I'm not sure why it's complaining about either one, since things were fine before. Did identifying information about these devices change over an update? Is there a way to get back the old behavior from QEMU? + + +Can you please upgrade to 1.0 and see if that fixes the problem. The following patch should fix your problem (and is present in 1.0): + +commit 21635e121ae0f0ab7874152a7c2f96e9d8cd642f +Author: Gerd Hoffmann <email address hidden> +Date: Tue Aug 9 12:35:57 2011 +0200 + + usb/hid: add hid_pointer_activate, use it + + HID reorganziation broke the usb tablet in windows xp. The reason is + that xp activates idle before it starts polling, which creates a + chicken-and-egg issue: We don't call hid_pointer_poll because there are + no pending events. We don't get any events because the activation code + in hid_pointer_poll is never executed and thus all pointer events are + routed to the PS/2 mouse by qemu. + + Fix this by creating a hid_pointer_activate function and call it from + usb-hid when the guest sets the idle state. + + Signed-off-by: Gerd Hoffmann <email address hidden> + + +Windows XP does not have a VESA compatible driver by default. -std vga therefore won't work out of the box for Windows XP. This is not a regression, this has always been the case. + +This is strange. On a lark, I right-clicked the unknown tablet device and told Windows to find a driver for it. It told me it couldn't find a better one than what I already had, and then it appeared as a HID-compliant device. Now it works fine! + +I'm thinking that what has happened is that some characteristic (name? PCI ID?) of the tablet device changed, and Windows XP doesn't automatically adapt to the "new hardware", but if you fiddle with it, Windows will decide to attach the right driver. + +It works fine for me now, but that doesn't completely invalidate the bug. At the very least, the bug is that this change wasn't documented well. I tried googling for this, but I found nothing relevant. + + +Is qemu 1.0 headed for fedora-rawhide any time soon? I only see qemu-0.15.1-3.fc17 available... + +From the Qemu Monitor, try looking at "info mice" +I'm not exactly sure ho to access the Qemu Monitor from VNC. You might have +to start qemu with additional parameters: -monitor +telnet:localhost:12341,server,nowait +then use "telnet localhost 12341" to access the monitor... + +On Monday 19 December 2011 18:54:19 Timothy Miller wrote: +> That's easier said than done, because it's pretty unusable. And as I +> said, the OS didn't change. QEMU got updated, and then it broke. So if +> it was or wasn't using the tablet before, then it still is or isn't now. +> Either way, it used to work. +> +> I'll see what I can figure out about what it thinks its input device is. + + +From VNC, you access the monitor via Ctrl-Alt-2 and Ctrl-Alt-1. It works the same. + +"info mice" gives me: +* Mouse #1: QEMU USB Tablet (absolute) + Mouse #0: QEMU PS/2 Mouse + +As for Windows and VESA, I'm not sure what it's doing, but I can select all sorts of resolutions, like 1440x900. The default adaptor in the past (cirrus?) was much more limited. It must be doing some kind of BIOS thunking, but I bet it would be more efficient to have a VESA driver, no? + + +According to comment #6 this has been fixed in version 1.0 ... is there still something left to do here? + +There hasn't been a reply to my question in the last comment within +months, so I assume nobody cares about this anymore. So I'm closing this +ticket now... + diff --git a/results/classifier/105/network/898 b/results/classifier/105/network/898 new file mode 100644 index 00000000..5bbfa893 --- /dev/null +++ b/results/classifier/105/network/898 @@ -0,0 +1,14 @@ +network: 0.890 +device: 0.834 +instruction: 0.655 +semantic: 0.392 +graphic: 0.386 +boot: 0.330 +other: 0.208 +vnc: 0.179 +mistranslation: 0.172 +assembly: 0.165 +socket: 0.155 +KVM: 0.094 + +check-tcg sha512-mvx test is failing on s390x hosts diff --git a/results/classifier/105/network/899 b/results/classifier/105/network/899 new file mode 100644 index 00000000..9d0150b5 --- /dev/null +++ b/results/classifier/105/network/899 @@ -0,0 +1,27 @@ +network: 0.983 +graphic: 0.982 +boot: 0.945 +instruction: 0.943 +device: 0.942 +vnc: 0.891 +assembly: 0.873 +semantic: 0.862 +socket: 0.654 +mistranslation: 0.617 +KVM: 0.223 +other: 0.207 + +HVF: Ubuntu Server fails to boot Linux 5.4.0-104 +Description of problem: +On macOS with HVF, when Ubuntu Server updates the Linux kernel to 5.4.0-104, it no longer boots and gets stuck at `EFI stub: Exiting boot services and installing virtual address map...`. This is not the case with QEMU 6.0.0 (with @agraf's HVF patches applied). + +It seems like 5.4.0-104 is the culprit because 5.4.0-100 boots fine. +Steps to reproduce: +1. Download Ubuntu Server 20.04 ARM64 ISO: https://ubuntu.com/download/server/arm +2. Run the above QEMU command (make sure networking is disabled so Ubuntu installer does not auto-upgrade the kernel) +3. Install Ubuntu with the default settings and reboot +4. It will not reboot (expected) so Ctrl+C and restart the command adding `-device virtio-net-pci,netdev=net0 -netdev user,id=net0` to the end to get networking +5. Boot into Ubuntu and install 5.4.0-104 kernel: `sudo apt install linux-image-5.4.0-104-generic` +6. Reboot and it will get stuck at `EFI stub: Exiting boot services and installing virtual address map...` +Additional information: + diff --git a/results/classifier/105/network/903365 b/results/classifier/105/network/903365 new file mode 100644 index 00000000..ba65e960 --- /dev/null +++ b/results/classifier/105/network/903365 @@ -0,0 +1,23 @@ +network: 0.813 +other: 0.744 +graphic: 0.585 +mistranslation: 0.531 +device: 0.509 +semantic: 0.500 +socket: 0.475 +instruction: 0.350 +vnc: 0.337 +boot: 0.208 +assembly: 0.186 +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/105/network/912 b/results/classifier/105/network/912 new file mode 100644 index 00000000..957ace8f --- /dev/null +++ b/results/classifier/105/network/912 @@ -0,0 +1,14 @@ +network: 0.940 +device: 0.909 +instruction: 0.650 +other: 0.527 +mistranslation: 0.492 +semantic: 0.464 +graphic: 0.358 +assembly: 0.275 +vnc: 0.243 +boot: 0.232 +socket: 0.178 +KVM: 0.003 + +Cannot access RHEL8_s390x installed OS using SSH from host OS network diff --git a/results/classifier/105/network/960 b/results/classifier/105/network/960 new file mode 100644 index 00000000..3bf8fc4a --- /dev/null +++ b/results/classifier/105/network/960 @@ -0,0 +1,14 @@ +network: 0.873 +mistranslation: 0.762 +device: 0.664 +semantic: 0.449 +other: 0.379 +graphic: 0.341 +boot: 0.250 +socket: 0.165 +vnc: 0.106 +instruction: 0.037 +assembly: 0.034 +KVM: 0.005 + +Windows host / win98 guest, i don't understand how to use network diff --git a/results/classifier/105/network/97 b/results/classifier/105/network/97 new file mode 100644 index 00000000..e7a9e90e --- /dev/null +++ b/results/classifier/105/network/97 @@ -0,0 +1,14 @@ +network: 0.880 +device: 0.766 +instruction: 0.627 +semantic: 0.466 +mistranslation: 0.392 +graphic: 0.248 +other: 0.106 +KVM: 0.078 +boot: 0.068 +assembly: 0.023 +socket: 0.007 +vnc: 0.003 + +-serial tcp should hang up when DTR goes low diff --git a/results/classifier/105/network/974 b/results/classifier/105/network/974 new file mode 100644 index 00000000..e116060a --- /dev/null +++ b/results/classifier/105/network/974 @@ -0,0 +1,16 @@ +network: 0.837 +device: 0.736 +mistranslation: 0.607 +semantic: 0.417 +graphic: 0.339 +boot: 0.304 +other: 0.287 +instruction: 0.262 +vnc: 0.220 +socket: 0.085 +assembly: 0.033 +KVM: 0.011 + +Enable virtio-9pfs on windows hosts +Additional information: +attn: @schoenebeck diff --git a/results/classifier/105/network/976 b/results/classifier/105/network/976 new file mode 100644 index 00000000..d6a64b1a --- /dev/null +++ b/results/classifier/105/network/976 @@ -0,0 +1,14 @@ +network: 0.935 +device: 0.734 +graphic: 0.612 +mistranslation: 0.304 +semantic: 0.224 +vnc: 0.118 +other: 0.082 +boot: 0.080 +instruction: 0.055 +socket: 0.034 +assembly: 0.029 +KVM: 0.003 + +Qemu - Bridge direct network connection not working diff --git a/results/classifier/105/network/984476 b/results/classifier/105/network/984476 new file mode 100644 index 00000000..a925992e --- /dev/null +++ b/results/classifier/105/network/984476 @@ -0,0 +1,27 @@ +network: 0.890 +vnc: 0.828 +mistranslation: 0.814 +device: 0.780 +semantic: 0.770 +socket: 0.758 +graphic: 0.641 +boot: 0.533 +instruction: 0.516 +KVM: 0.238 +other: 0.214 +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/105/network/999 b/results/classifier/105/network/999 new file mode 100644 index 00000000..d63d63e7 --- /dev/null +++ b/results/classifier/105/network/999 @@ -0,0 +1,19 @@ +network: 0.841 +device: 0.838 +graphic: 0.796 +socket: 0.695 +instruction: 0.626 +boot: 0.584 +semantic: 0.483 +mistranslation: 0.436 +vnc: 0.414 +other: 0.262 +assembly: 0.092 +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 |