diff options
Diffstat (limited to 'results/classifier/zero-shot/108/permissions')
179 files changed, 42646 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/permissions/1013888 b/results/classifier/zero-shot/108/permissions/1013888 new file mode 100644 index 000000000..b1281c096 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1013888 @@ -0,0 +1,119 @@ +permissions: 0.921 +semantic: 0.919 +other: 0.909 +graphic: 0.904 +debug: 0.896 +PID: 0.893 +device: 0.892 +performance: 0.883 +socket: 0.867 +files: 0.856 +vnc: 0.846 +network: 0.826 +boot: 0.826 +KVM: 0.816 + +windows xp sp3 setup blank screen on boot + +When attempting to run Windows XP SP3 setup in qemu on a Lubuntu host with the following kernel: + +Linux michael-XPS-M1530 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +Qemu does not get past a blank screen after "Setup is inspecting your computer's hardware configuration" + +Qemu 1.0.1 - Doesn't have a problem +Qemu 1.1.0 - has the problem +Qemu master commit eb2aeacf983a2a88a2b31e8fee067c38bd10abd3 - has the problem + +qemu-system-x86_64 -L ../path/to/bios -cdrom winxp.iso -hda winxp.img -boot d + +where ../path/to/bios is the location of the pc-bios files from that version of qemu + +hi, +same problem on centos 6.2 with vanilla kernel 3.4.2. +I compiled qemu 1.0.1 from source and qemu 1.1.0 from source. + +/opt/qemu-1.0.1/bin/qemu-system-i386 -m 2048 -cdrom Win_XP_Pro_SP3.iso -hda test.winXP.qcow2 : works + +/opt/qemu-1.1.0/bin/qemu-system-i386 -m 2048 -cdrom Win_XP_Pro_SP3.iso -hda test.winXP.qcow2 : hangs + +/opt/qemu-1.1.0/bin/qemu-system-i386 -m 2048 -cdrom Win_XP_Pro_SP3.iso -hda test.winXP.qcow2 -L /opt/qemu-1.0.1/data/ : hangs and on stderr give: Could not open option rom 'kvmvapic.bin': No such file or directory + +/opt/qemu-1.1.0/bin/qemu-system-i386 -m 2048 -cdrom Win_XP_Pro_SP3.iso -hda test.winXP.qcow2 -L /opt/qemu-1.0.1/data/ -cpu qemu32,-apic : hangs + + +regards +Luigi + +On Fri, Jun 15, 2012 at 11:49:36PM -0000, Michael Sabino wrote: +> Qemu 1.0.1 - Doesn't have a problem +> Qemu 1.1.0 - has the problem +> Qemu master commit eb2aeacf983a2a88a2b31e8fee067c38bd10abd3 - has the problem + +I was also able to reproduce with commit: + +eb2aeacf983a2a88a2b31e8fee067c38bd10abd3 + +The problem appears to have been fixed upstream though. A reverse bisect +points to this patch being the fix: + +commit c52acf60b6c12ff5eb58eb6ac568c159ae0c8737 +Author: Pavel Hrdina <email address hidden> +Date: Wed Jun 13 15:43:11 2012 +0200 + + fdc: fix implied seek while there is no media in drive + + The Windows uses 'READ' command at the start of an instalation + without checking the 'dir' register. We have to abort the transfer + with an abnormal termination if there is no media in the drive. + + Signed-off-by: Pavel Hrdina <email address hidden> + Signed-off-by: Kevin Wolf <email address hidden> + +Please try your scenario again using that commit, and if all if it does the +trick we'll get it included in the next stable-1.1 release. + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1013888 +> +> Title: +> windows xp sp3 setup blank screen on boot +> +> Status in QEMU: +> New +> +> Bug description: +> When attempting to run Windows XP SP3 setup in qemu on a Lubuntu host +> with the following kernel: +> +> Linux michael-XPS-M1530 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 +> 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux +> +> Qemu does not get past a blank screen after "Setup is inspecting your +> computer's hardware configuration" +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1013888/+subscriptions +> + + +I confirm it works. +just compiled from commit c52acf60b6c12ff5eb58eb6ac568c159ae0c8737. +Windows XP SP3 installation iso boot and start installation process. + +I tested both i368-softmmu and x86_64-softmmu targets. + +thanks +Luigi + +The bug also applies to Debian Qemu 1.1.0 + +Adding the changes of commit c52acf60b6c12ff5eb58eb6ac568c159ae0c8737 on top of the 1.1.0 Debian package fixes the issue. + +Which debian package do you mean? The fix is included is current debian qemu-kvm 1.1.0+dfsg-3 release. qemu package in debian does not have this fix however. + +Marking this bug as fixed, according to comment #4 and #5 + diff --git a/results/classifier/zero-shot/108/permissions/1042084 b/results/classifier/zero-shot/108/permissions/1042084 new file mode 100644 index 000000000..dfdaec2ed --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1042084 @@ -0,0 +1,107 @@ +permissions: 0.972 +graphic: 0.957 +semantic: 0.953 +performance: 0.949 +other: 0.948 +PID: 0.945 +boot: 0.942 +debug: 0.933 +vnc: 0.901 +files: 0.901 +device: 0.900 +socket: 0.886 +KVM: 0.875 +network: 0.806 + +Windows 7 guest cannot boot after seabios updated + +Hi, + +I can no longer boot my Windows 7 guest after this commit (update seabios to latest master) + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=01afdadc92e71e29700e64f3a5f42c1c543e3cf9 + +When I tried to boot Windows, it BSOD and said "The BIOS in this system is not fully ACPI compliant. Please contact your system vendor for an updated BIOS". Reverting this commit will fix the issue. + +On Mon, Aug 27, 2012 at 7:54 AM, Vic <llyzs@163.com> wrote: +> Public bug reported: +> +> Hi, +> +> I can no longer boot my Windows 7 guest after this commit (update +> seabios to latest master) +> +> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=01afdadc92e71e29700e64f3a5f42c1c543e3cf9 +> +> When I tried to boot Windows, it BSOD and said "The BIOS in this system +> is not fully ACPI compliant. Please contact your system vendor for an +> updated BIOS". Reverting this commit will fix the issue. + +Gerd, Kevin: Any ideas? + +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1042084 +> +> Title: +> Windows 7 guest cannot boot after seabios updated +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> I can no longer boot my Windows 7 guest after this commit (update +> seabios to latest master) +> +> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=01afdadc92e71e29700e64f3a5f42c1c543e3cf9 +> +> When I tried to boot Windows, it BSOD and said "The BIOS in this +> system is not fully ACPI compliant. Please contact your system vendor +> for an updated BIOS". Reverting this commit will fix the issue. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1042084/+subscriptions +> + + +On 08/28/12 10:07, Stefan Hajnoczi wrote: +> On Mon, Aug 27, 2012 at 7:54 AM, Vic <llyzs@163.com> wrote: +>> Public bug reported: +>> +>> Hi, +>> +>> I can no longer boot my Windows 7 guest after this commit (update +>> seabios to latest master) +>> +>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=01afdadc92e71e29700e64f3a5f42c1c543e3cf9 +>> +>> When I tried to boot Windows, it BSOD and said "The BIOS in this system +>> is not fully ACPI compliant. Please contact your system vendor for an +>> updated BIOS". Reverting this commit will fix the issue. +> +> Gerd, Kevin: Any ideas? + +Not yet. My win7 32bit guests boots fine. Installing 64bit version +right now to see how that behaves, at least the windows setup booted +just fine too. + +cheers, + Gerd + + +I have tried both 32-bit and 64-bit Windows 7, both have the same issue. But I can also boot into the Window 7 setup. I have tried to use the repair option but it cannot repair it. I then recreated the partion and do a fresh installation and it then boots fine. So this issue only affects the guest which was installed before the BIOS update. + +I am now trying to reinstall a new instance without the BIOS update, then update the BIOS after that to see if I can reproduce the issue. + +I cannot reproduce the issue with newly created image, so looks like this is not a qemu bug, but just a problem of my corrupted image. Sorry for the noise, please close the issue and I will report another one if I find other things. + +Closing, according to comment #5. + diff --git a/results/classifier/zero-shot/108/permissions/1066 b/results/classifier/zero-shot/108/permissions/1066 new file mode 100644 index 000000000..3bc634540 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1066 @@ -0,0 +1,47 @@ +permissions: 0.939 +device: 0.895 +PID: 0.823 +performance: 0.816 +graphic: 0.799 +network: 0.697 +semantic: 0.601 +boot: 0.568 +files: 0.561 +vnc: 0.521 +socket: 0.484 +debug: 0.440 +KVM: 0.358 +other: 0.285 + +virtfs fails to access contents of non-readable directories +Description of problem: +Attempting to access a directory inside a non-readable directory via virtfs fails. +Steps to reproduce: +On host: +1. `mkdir -p test/foo/bar` +2. `echo hello world >test/foo/bar/baz.txt` +3. `chmod -r test/foo` + +The following works on host: + +``` +$ ls test +foo +$ ls test/foo +ls: cannot open directory 'test/foo': Permission denied +$ ls test/foo/bar +baz.txt +``` + +However on guest: + +``` +bash-5.1# ls /test/ +foo +bash-5.1# ls /test/foo/ +ls: cannot open directory '/test/foo/': Permission denied +bash-5.1# ls /test/foo/bar/ +ls: cannot access '/test/foo/bar/': Permission denied +``` +Additional information: +I am guessing virtfs attempts to check rights (via access?) on the directory itself when obtaining an inode to give to the guest, however not having read access doesn't mean something can't be executed, especially for directories. diff --git a/results/classifier/zero-shot/108/permissions/1067 b/results/classifier/zero-shot/108/permissions/1067 new file mode 100644 index 000000000..2f61ce2cf --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1067 @@ -0,0 +1,99 @@ +permissions: 0.958 +performance: 0.930 +PID: 0.914 +network: 0.882 +graphic: 0.865 +device: 0.848 +files: 0.801 +socket: 0.713 +vnc: 0.679 +boot: 0.573 +semantic: 0.550 +debug: 0.204 +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/zero-shot/108/permissions/1077116 b/results/classifier/zero-shot/108/permissions/1077116 new file mode 100644 index 000000000..467746433 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1077116 @@ -0,0 +1,115 @@ +permissions: 0.926 +debug: 0.919 +performance: 0.893 +semantic: 0.887 +graphic: 0.882 +device: 0.862 +PID: 0.858 +files: 0.847 +socket: 0.847 +network: 0.812 +KVM: 0.798 +other: 0.794 +boot: 0.779 +vnc: 0.718 + +automoc4 segfaults when building in an armhf pbuilder on an amd64 host + +When trying to build kde4libs in an armhf pbuilder created with the pbuilder-scripts running on an amd64 host automoc4 recieves a segmentation fault and I can't get any useful information out of it: + +root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# /usr/bin/automoc4 kdeui_automoc.cpp ../../kdeui/ . moc-qt4 cmake +unable to dump 00102c00 +Segmentation fault (core dumped) +root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# gdb /usr/bin/automoc4 qemu_automoc4_20121108-211818_15839.core +GNU gdb (GDB) 7.5-ubuntu +Copyright (C) 2012 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "arm-linux-gnueabihf". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /usr/bin/automoc4...done. +BFD: Warning: /tmp/kde4libs-4.9.3/build/kdeui/qemu_automoc4_20121108-211818_15839.core is truncated: expected core file size >= 5150720, found: 974848. +[New LWP 15839] +[New LWP 15866] +Cannot access memory at address 0xf67fe954 +Cannot access memory at address 0xf67fe950 +(gdb) bt +#0 0xf6630306 in ?? () +#1 0xf6415ff8 in ?? () +#2 0xf6415ff8 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) + +automoc4 runs fine when building on a nexus7 so this sounds like an issue in qemu. +Tested in quantal and raring. + +ProblemType: Bug +DistroRelease: Ubuntu 13.04 +Package: qemu-user-static 1.2.0-2012.09-0ubuntu1 +Uname: Linux 3.6.2-030602-generic x86_64 +NonfreeKernelModules: nvidia +ApportVersion: 2.6.2-0ubuntu3 +Architecture: amd64 +Date: Fri Nov 9 19:29:28 2012 +EcryptfsInUse: Yes +InstallationDate: Installed on 2011-10-08 (398 days ago) +InstallationMedia: Kubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20111007) +MarkForUpload: True +ProcEnviron: + SHELL=/bin/bash + TERM=xterm + PATH=(custom, user) + LANG=en_US.UTF-8 + LANGUAGE=en_US.UTF-8 +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install) + + + +This still applies to raring's qemu with the linaro patches. + +Thanks for reporting this bug. There seem to be a few bugs in the armhf qemu-user-static right now. I'll test against bleeding edge upstream. + +Buildlog from an armfh PPA build as reference. + +Same for me + +make[2]: Entering directory `/builddir/build/BUILD/kdelibs-4.10.5/build' + +cd /builddir/build/BUILD/kdelibs-4.10.5/build/kdeui && /usr/bin/automoc4 /builddir/build/BUILD/kdelibs-4.10.5/build/kdeui/kdeui_automoc.cpp /builddir/build/BUILD/kdelibs-4.10.5/kdeui /builddir/build/BUILD/kdelibs-4.10.5/build/kdeui /usr/lib/qt4/bin/moc /usr/bin/cmake + +Unable to load library icui18n "Cannot load library icui18n: (icui18n: cannot open shared object file: No such file or directory)" + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +/bin/sh: line 1: 8056 Segmentation fault (core dumped) /usr/bin/automoc4 /builddir/build/BUILD/kdelibs-4.10.5/build/kdeui/kdeui_automoc.cpp /builddir/build/BUILD/kdelibs-4.10.5/kdeui /builddir/build/BUILD/kdelibs-4.10.5/build/kdeui /usr/lib/qt4/bin/moc /usr/bin/cmake + +make[2]: *** [kdeui/CMakeFiles/kdeui_automoc] Error 139 + +make[2]: Leaving directory `/builddir/build/BUILD/kdelibs-4.10.5/build' + +make[1]: *** [kdeui/CMakeFiles/kdeui_automoc.dir/all] Error 2 + +make[1]: Leaving directory `/builddir/build/BUILD/kdelibs-4.10.5/build' + +make: *** [all] Error 2 + +make: Leaving directory `/builddir/build/BUILD/kdelibs-4.10.5/build' + +error: Bad exit status from /var/tmp/rpm-tmp.50015 (%install) + +RPM build errors: + + Bad exit status from /var/tmp/rpm-tmp.50015 (%install) + +I was able to reproduce this failure with QEMU 2.5, and the code runs OK under QEMU current master, so I think this is fixed by the threading/signal handling bugfixes we've done between then and now. I'm going to close this as will-be-fixed-in-2.11 (though it's quite possible it's already fixed in 2.10). + + +We have had a few more issues around armhf qemu-static that mostly resolved in Artful (qemu 2.10) and finally one that was good in Bionic (qemu 2.11). +This also included some updates to other components but should be good now. + +If the issue here really still applies to a newer version please reopen and state an updated test and version that it ran on. + diff --git a/results/classifier/zero-shot/108/permissions/1079 b/results/classifier/zero-shot/108/permissions/1079 new file mode 100644 index 000000000..444f372c3 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1079 @@ -0,0 +1,47 @@ +permissions: 0.963 +device: 0.921 +graphic: 0.919 +debug: 0.895 +PID: 0.798 +semantic: 0.781 +boot: 0.755 +files: 0.599 +performance: 0.525 +vnc: 0.518 +network: 0.497 +socket: 0.385 +other: 0.172 +KVM: 0.111 + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Description of problem: +I am trying to build `arm64` image on my `x86_64` machine using `buildx` and I have encountered `qemu: uncaught target signal 11 (Segmentation fault) - core dumped` Error. <br> +# +Steps to reproduce: +1. Create a Dockerfile +``` +FROM python:3.8-slim + +ENV PYTHONDONTWRITEBYTECODE=1 + +# Install packages +RUN apt update +RUN apt-get install -y python3-pip +``` +2. Run binfmt container +``` +docker run --privileged --rm tonistiigi/binfmt --install all +``` +3. Setup new builder +``` +$ docker buildx create --name mybuilder +$ docker buildx use mybuilder +$ docker buildx inspect --bootstrap +``` +4. Build Image +``` +$ docker buildx build --platform linux/amd64,linux/arm64 --push -t user/failure-case . +``` +# +Additional information: + diff --git a/results/classifier/zero-shot/108/permissions/1094950 b/results/classifier/zero-shot/108/permissions/1094950 new file mode 100644 index 000000000..935b02cc4 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1094950 @@ -0,0 +1,341 @@ +permissions: 0.988 +debug: 0.982 +device: 0.947 +PID: 0.932 +other: 0.932 +files: 0.920 +socket: 0.917 +performance: 0.914 +semantic: 0.905 +network: 0.904 +graphic: 0.902 +boot: 0.884 +KVM: 0.870 +vnc: 0.839 + +crash at qemu_iohandler_poll (iohandler.c:124) on macos 10.8.2 + +I'm seeing consistent hangs / crashes on MacOS 10.8.2 with 1.3.0. I've tried both gcc-4.2 and clang. I've tried a half a dozen different images/kernels. + +I configured qemu like this: + +./configure --disable-sdl --disable-kvm --enable-cocoa --cc=gcc-4.2 --host-cc=gcc-4.2 --enable-debug --extra-cflags=-g --extra-ldflags=-g + +And ran it like this: + +qemu-system-arm -nographic -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1 console=ttyAMA0" + +With images, kernel, and initrd described here: + +http://psellos.com/2012/08/2012.08.qemu-arm-osx.html + +And I get: + +Program received signal EXC_BAD_ACCESS, Could not access memory. +Reason: KERN_PROTECTION_FAILURE at address: 0x000000010142f2d0 +0x000000010142f2d0 in ?? () + +(gdb) bt +#0 0x000000010142f2d0 in ?? () +#1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124 +#2 0x0000000100172acf in main_loop_wait (nonblocking=0) at main-loop.c:418 +#3 0x0000000100207bbf in main_loop () at vl.c:1765 +#4 0x000000010020e7b0 in qemu_main (argc=12, argv=0x7fff5fbff360, envp=0x7fff5fbff3c8) at vl.c:3992 +#5 0x00000001001d6013 in main (argc=12, argv=0x7fff5fbff360) at ui/cocoa.m:884 +(gdb) frame 1 +#1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124 +124 ioh->fd_read(ioh->opaque); +Current language: auto; currently c +(gdb) p ioh +$1 = (IOHandlerRecord *) 0x10142f110 +(gdb) p *ioh +$2 = { + fd_read_poll = 0, + fd_read = 0x10017212b <sigfd_handler>, + fd_write = 0, + opaque = 0x3, + next = { + le_next = 0x0, + le_prev = 0x105d00bc0 + }, + fd = 3, + deleted = false +} + +On Mon, Dec 31, 2012 at 08:46:45PM -0000, Christopher Mason wrote: +> Public bug reported: +> +> I'm seeing consistent hangs / crashes on MacOS 10.8.2 with 1.3.0. I've +> tried both gcc-4.2 and clang. I've tried a half a dozen different +> images/kernels. + +Which QEMU version are you building? Have you tried qemu.git/master? + +> Program received signal EXC_BAD_ACCESS, Could not access memory. +> Reason: KERN_PROTECTION_FAILURE at address: 0x000000010142f2d0 +> 0x000000010142f2d0 in ?? () +> +> (gdb) bt +> #0 0x000000010142f2d0 in ?? () +> #1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124 +> #2 0x0000000100172acf in main_loop_wait (nonblocking=0) at main-loop.c:418 +> #3 0x0000000100207bbf in main_loop () at vl.c:1765 +> #4 0x000000010020e7b0 in qemu_main (argc=12, argv=0x7fff5fbff360, envp=0x7fff5fbff3c8) at vl.c:3992 +> #5 0x00000001001d6013 in main (argc=12, argv=0x7fff5fbff360) at ui/cocoa.m:884 +> (gdb) frame 1 +> #1 0x000000010016e209 in qemu_iohandler_poll (readfds=0x10097ca00, writefds=0x10097ca80, xfds=0x10097cb00, ret=4) at iohandler.c:124 +> 124 ioh->fd_read(ioh->opaque); +> Current language: auto; currently c +> (gdb) p ioh +> $1 = (IOHandlerRecord *) 0x10142f110 +> (gdb) p *ioh +> $2 = { +> fd_read_poll = 0, +> fd_read = 0x10017212b <sigfd_handler>, + +The fd_read() function pointer should be called here. But somehow we +end up with 0x000000010142f2d0, which is awefully close to the +IOHandlerRecord (0x10142f110). + +Perhaps printing out the entire io_handlers list would be interesting +too. + +Does this happen at an unspecified point or is it always when the +fd_read sigfd_handler() callback is invoked? (You could put a +breakpoint on sigfd_handler() and continue the first time it is hit to +check this.) + +Stefan + + +Using qemu master rev dbd99ae..25bbf61 configured with: + +./configure --disable-sdl --disable-kvm --enable-cocoa --enable-debug --extra-cflags=-g --extra-ldflags=-g + +(I'm using clang 4.1 now. Should I be using clang or gcc 4.2? Are these the right config args?) + +(gdb) b sigfd_handler +Breakpoint 1 at 0x1001c098d: file main-loop.c, line 41. + +(gdb) r -nographic -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1 console=ttyAMA0" +... +Breakpoint 1, sigfd_handler (opaque=0x3) at main-loop.c:41 +41 int fd = (intptr_t)opaque; +(gdb) bt +#0 sigfd_handler (opaque=0x3) at main-loop.c:41 +#1 0x00000001001baaee in qemu_iohandler_poll (readfds=0x100a0938c, writefds=0x100a0940c, xfds=0x100a0948c, ret=3) at iohandler.c:124 +#2 0x00000001001c00bb in main_loop_wait (nonblocking=0) at main-loop.c:418 +#3 0x000000010027bde4 in main_loop () at vl.c:1765 +#4 0x00000001002765c2 in qemu_main (argc=12, argv=0x7fff5fbff340, envp=0x7fff5fbff3a8) at vl.c:4014 +#5 0x0000000100239a13 in main (argc=12, argv=0x7fff5fbff340) at ui/cocoa.m:884 +Current language: auto; currently minimal +(gdb) p io_handlers +$1 = { + lh_first = 0x102102ab0 +} +(gdb) p * io_handlers.lh_first +$2 = { + fd_read_poll = 0x1001fad60 <stdio_read_poll>, + fd_read = 0x1001fae20 <stdio_read>, + fd_write = 0, + opaque = 0x1021029c0, + next = { + le_next = 0x102100000, + le_prev = 0x100a09368 + }, + fd = 0, + deleted = false +} +(gdb) p * io_handlers.lh_first->next.le_prev +$3 = (struct IOHandlerRecord *) 0x102102ab0 +(gdb) p * io_handlers.lh_first->next.le_next +$4 = { + fd_read_poll = 0, + fd_read = 0x1001c0970 <sigfd_handler>, + fd_write = 0, + opaque = 0x3, + next = { + le_next = 0x0, + le_prev = 0x102102ad0 + }, + fd = 3, + deleted = false +} + +(gdb) c + +Program received signal EXC_BAD_ACCESS, Could not access memory. +Reason: KERN_PROTECTION_FAILURE at address: 0x0000000102100040 +0x0000000102100040 in ?? () +(gdb) bt +#0 0x0000000102100040 in ?? () +#1 0x00000001001baaee in qemu_iohandler_poll (readfds=0x100a0938c, writefds=0x100a0940c, xfds=0x100a0948c, ret=3) at iohandler.c:124 +#2 0x00000001001c00bb in main_loop_wait (nonblocking=0) at main-loop.c:418 +#3 0x000000010027bde4 in main_loop () at vl.c:1765 +#4 0x00000001002765c2 in qemu_main (argc=12, argv=0x7fff5fbff340, envp=0x7fff5fbff3a8) at vl.c:4014 +#5 0x0000000100239a13 in main (argc=12, argv=0x7fff5fbff340) at ui/cocoa.m:884 + +(gdb) p io_handlers +$5 = { + lh_first = 0x102102ab0 +} +(gdb) p * io_handlers.lh_first +$6 = { + fd_read_poll = 0x1001fad60 <stdio_read_poll>, + fd_read = 0x1001fae20 <stdio_read>, + fd_write = 0, + opaque = 0x1021029c0, + next = { + le_next = 0x102100000, + le_prev = 0x100a09368 + }, + fd = 0, + deleted = false +} +(gdb) p * io_handlers.lh_first->next.le_next +$8 = { + fd_read_poll = 0, + fd_read = 0x1001c0970 <sigfd_handler>, + fd_write = 0, + opaque = 0x3, + next = { + le_next = 0x0, + le_prev = 0x102102ad0 + }, + fd = 3, + deleted = false +} +(gdb) p * io_handlers.lh_first->next.le_prev +$9 = (struct IOHandlerRecord *) 0x102102ab0 + + +On Fri, Jan 04, 2013 at 06:09:30PM -0000, Christopher Mason wrote: +> Using qemu master rev dbd99ae..25bbf61 configured with: +> +> ./configure --disable-sdl --disable-kvm --enable-cocoa --enable-debug +> --extra-cflags=-g --extra-ldflags=-g +> +> (I'm using clang 4.1 now. Should I be using clang or gcc 4.2? Are these +> the right config args?) + +I have never used QEMU on Mac myself, sorry. Maybe someone else can +help. + +> (gdb) b sigfd_handler +> Breakpoint 1 at 0x1001c098d: file main-loop.c, line 41. +> +> (gdb) r -nographic -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1 console=ttyAMA0" +> ... +> Breakpoint 1, sigfd_handler (opaque=0x3) at main-loop.c:41 +> 41 int fd = (intptr_t)opaque; +> (gdb) bt +> #0 sigfd_handler (opaque=0x3) at main-loop.c:41 +> #1 0x00000001001baaee in qemu_iohandler_poll (readfds=0x100a0938c, writefds=0x100a0940c, xfds=0x100a0948c, ret=3) at iohandler.c:124 +> #2 0x00000001001c00bb in main_loop_wait (nonblocking=0) at main-loop.c:418 +> #3 0x000000010027bde4 in main_loop () at vl.c:1765 +> #4 0x00000001002765c2 in qemu_main (argc=12, argv=0x7fff5fbff340, envp=0x7fff5fbff3a8) at vl.c:4014 +> #5 0x0000000100239a13 in main (argc=12, argv=0x7fff5fbff340) at ui/cocoa.m:884 +> Current language: auto; currently minimal +> (gdb) p io_handlers +> $1 = { +> lh_first = 0x102102ab0 +> } +> (gdb) p * io_handlers.lh_first +> $2 = { +> fd_read_poll = 0x1001fad60 <stdio_read_poll>, +> fd_read = 0x1001fae20 <stdio_read>, +> fd_write = 0, +> opaque = 0x1021029c0, +> next = { +> le_next = 0x102100000, +> le_prev = 0x100a09368 +> }, +> fd = 0, +> deleted = false +> } +> (gdb) p * io_handlers.lh_first->next.le_prev +> $3 = (struct IOHandlerRecord *) 0x102102ab0 +> (gdb) p * io_handlers.lh_first->next.le_next +> $4 = { +> fd_read_poll = 0, +> fd_read = 0x1001c0970 <sigfd_handler>, +> fd_write = 0, +> opaque = 0x3, +> next = { +> le_next = 0x0, +> le_prev = 0x102102ad0 +> }, +> fd = 3, +> deleted = false +> } +> +> (gdb) c +> +> Program received signal EXC_BAD_ACCESS, Could not access memory. +> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000102100040 +> 0x0000000102100040 in ?? () +> (gdb) bt +> #0 0x0000000102100040 in ?? () +> #1 0x00000001001baaee in qemu_iohandler_poll (readfds=0x100a0938c, writefds=0x100a0940c, xfds=0x100a0948c, ret=3) at iohandler.c:124 +> #2 0x00000001001c00bb in main_loop_wait (nonblocking=0) at main-loop.c:418 +> #3 0x000000010027bde4 in main_loop () at vl.c:1765 +> #4 0x00000001002765c2 in qemu_main (argc=12, argv=0x7fff5fbff340, envp=0x7fff5fbff3a8) at vl.c:4014 +> #5 0x0000000100239a13 in main (argc=12, argv=0x7fff5fbff340) at ui/cocoa.m:884 +> +> (gdb) p io_handlers +> $5 = { +> lh_first = 0x102102ab0 +> } +> (gdb) p * io_handlers.lh_first +> $6 = { +> fd_read_poll = 0x1001fad60 <stdio_read_poll>, +> fd_read = 0x1001fae20 <stdio_read>, +> fd_write = 0, +> opaque = 0x1021029c0, +> next = { +> le_next = 0x102100000, +> le_prev = 0x100a09368 +> }, +> fd = 0, +> deleted = false +> } +> (gdb) p * io_handlers.lh_first->next.le_next +> $8 = { +> fd_read_poll = 0, +> fd_read = 0x1001c0970 <sigfd_handler>, +> fd_write = 0, +> opaque = 0x3, +> next = { +> le_next = 0x0, +> le_prev = 0x102102ad0 +> }, +> fd = 3, +> deleted = false +> } +> (gdb) p * io_handlers.lh_first->next.le_prev +> $9 = (struct IOHandlerRecord *) 0x102102ab0 + +This is interesting. The iohandlers are intact - there was no +memory corruption there. The fact that it crashes after executing +sigfd_handler() once is suspicious. + +My next suggestion is to break on iohandler.c:124 and find out why +0x0000000102100040 is getting called. Really it should be +sigfd_handler() that gets called again. This may require a few tries +and probably familiarity with assembly to debug. + +I have pinged other QEMU contributors who have Macs. Perhaps they can +help better from here. + +Stefan + + +Just a note that IME trying to debug QEMU under gdb on MacOS doesn't work very well. In particular as far as I can tell gdb breaks sigwait() such that the sigwait() in sigwait_compat() can return 0 without setting the int* sig. This causes QEMU to write an uninitialized value into the qemu_signalfd_siginfo struct it sends down the pipe, and then sigfd_handler() calls sigaction() with this bogus data as the signal number. Since sigfd_handler() doesn't check the return value from sigaction() we then proceed to leap off into nowhere. + +sigfd_handler() should probably be checking the return value from sigaction() but the underlying problem is MacOS and/or its gdb breaking sigwait() behaviour somehow. + + +Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0) and macOS, or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1128935 b/results/classifier/zero-shot/108/permissions/1128935 new file mode 100644 index 000000000..dfe469edb --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1128935 @@ -0,0 +1,396 @@ +permissions: 0.960 +other: 0.927 +semantic: 0.926 +debug: 0.919 +socket: 0.902 +device: 0.884 +performance: 0.883 +files: 0.880 +graphic: 0.868 +vnc: 0.864 +PID: 0.860 +network: 0.839 +KVM: 0.799 +boot: 0.766 + +MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction + +I occasionally see that the TLBP instruction fails to find the corresponding TLB entry in the TLB Modified exception handler. This behavior is unexpected, because the invocation of the TLB Modified exception suggests there indeed is such an entry in the TLB and only requires its dirty bit to be set. + +The operating system which can trigger and is susceptible to this behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta. The QEMU version on which this is reproducible is QEMU 1.4.0 and also some others. + +When I looked into the QEMU sources, I noticed the following discrepancy, which could potentially explain the behavior: + + 65 /* MIPS32/MIPS64 R4000-style MMU emulation */ + 66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot, + 67 target_ulong address, int rw, int access_type) + 68 { + <snip> + 72 for (i = 0; i < env->tlb->tlb_in_use; i++) { + +1865 void r4k_helper_tlbp(CPUMIPSState *env) +1866 { + <snip> +1875 for (i = 0; i < env->tlb->nb_tlb; i++) { + +From the above it appears as if the the code which searches the TLB for a matching entry searched also the QEMU-specific "shadow" TLB entries, which is, however, not in line with how the TLBP instruction searches the TLB. So if a matching entry is found on index >= tlb_in_use, the HelenOS exception handler using TLBP to locate the entry would hit an assertion on seeing the Index register bit P set. + +I also suspect there is a similar issue with the TLB Invalid exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is not susceptible in this case. + +Linux under QEMU does not hit this issue because it turns out that its "TLB modified" handler does not check the P bit of the Index register after the TLBP instruction. + +hello, +in the past year gsoc qemu proposed projects there where on eproject that i +liked, which were: qemu IA64 emulation : +http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation + +this year i have not seen this project to be proposed, so i would like to +know if the qemu will be selected i would like to know if i will be able to +begin to make this project. +i am also a very novice in the asm programming (so very noobish in the +field, so u will have to answer a lot of noobish questions :) ), so would u +accept such a student to make this project? + +i thank you in advance for the answer +best regards + + +On 04/04/2013 07:34 PM, Gigi D'Agostino wrote: +> in the past year gsoc qemu proposed projects there where on eproject that i +> liked, which were: qemu IA64 emulation : +> http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation +> +> this year i have not seen this project to be proposed, so i would like to +> know if the qemu will be selected i would like to know if i will be able to +> begin to make this project. +> i am also a very novice in the asm programming (so very noobish in the +> field, so u will have to answer a lot of noobish questions :) ), so would u +> accept such a student to make this project? + +I can't speak for QEMU as I am from the HelenOS mentoring organization, +but according to how GSoC works, a student is free to suggest any +project. The organizations will then pick the best student applications +for things they like and can provide mentors for. + +HTH, +Jakub + + + +Hi Lurie, + +On 04.04.2013, at 19:34, Iurie wrote: + +> hello, +> in the past year gsoc qemu proposed projects there where on eproject that i liked, which were: qemu IA64 emulation : http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation +> +> this year i have not seen this project to be proposed, so i would like to know if the qemu will be selected i would like to know if i will be able to begin to make this project. +> i am also a very novice in the asm programming (so very noobish in the field, so u will have to answer a lot of noobish questions :) ), so would u accept such a student to make this project? + +We had a student working on IA64 emulation last year. Typically, to get a new target working, you start off implementing Linux user space emulation, then continue to system emulation. User space emulation is a lot easier to debug, you need less features of the CPU (no MMU emulation, no privileged instructions) and you don't need device emulation code. + +However, IA64 maps its virtual memory to locations that x86_64 can not map at all. Since in QEMU, Linux user emulation leverages the host's MMU to do virtual memory maps, IA64 programs can't be mapped on x86_64 hosts, which are the typical development environment for QEMU target code. + +So at the end of the day, we had to cancel the IA64 emulation project last year. + +There is still the slight chance to do IA64 emulation if you take the KVM IA64 code from ~3-4 years ago, forward port that to current QEMU, get the device model running with KVM on a real IA64 machine, and then implement system emulation straight on. + +However, that is not an easy task. It requires quite in-depth knowledge of all the changes that happened in QEMU device models within the last years and a lot of debugging skills to get KVM working. So unless you have a lot of IA64 background, I'm afraid this is vastly out of scope for summer of code. Unfortunately. + + +Alex + + + +hi, +thank you very much for the answer. i will try do some more easy projects +durring this summer related to asm and things like that and i hope in the +following year to do this project. + +best regards + + +On 6 April 2013 10:31, Alexander Graf <email address hidden> wrote: + +> Hi Lurie, +> +> On 04.04.2013, at 19:34, Iurie wrote: +> +> hello, +> in the past year gsoc qemu proposed projects there where on eproject that +> i liked, which were: qemu IA64 emulation : +> http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation +> +> this year i have not seen this project to be proposed, so i would like to +> know if the qemu will be selected i would like to know if i will be able to +> begin to make this project. +> i am also a very novice in the asm programming (so very noobish in the +> field, so u will have to answer a lot of noobish questions :) ), so would u +> accept such a student to make this project? +> +> +> We had a student working on IA64 emulation last year. Typically, to get a +> new target working, you start off implementing Linux user space emulation, +> then continue to system emulation. User space emulation is a lot easier to +> debug, you need less features of the CPU (no MMU emulation, no privileged +> instructions) and you don't need device emulation code. +> +> However, IA64 maps its virtual memory to locations that x86_64 can not map +> at all. Since in QEMU, Linux user emulation leverages the host's MMU to do +> virtual memory maps, IA64 programs can't be mapped on x86_64 hosts, which +> are the typical development environment for QEMU target code. +> +> So at the end of the day, we had to cancel the IA64 emulation project last +> year. +> +> There is still the slight chance to do IA64 emulation if you take the KVM +> IA64 code from ~3-4 years ago, forward port that to current QEMU, get the +> device model running with KVM on a real IA64 machine, and then implement +> system emulation straight on. +> +> However, that is not an easy task. It requires quite in-depth knowledge of +> all the changes that happened in QEMU device models within the last years +> and a lot of debugging skills to get KVM working. So unless you have a lot +> of IA64 background, I'm afraid this is vastly out of scope for summer of +> code. Unfortunately. +> +> +> Alex +> +> + + +On Sat, Apr 6, 2013 at 9:31 AM, agraf <email address hidden> wrote: +> Hi Lurie, +> +> On 04.04.2013, at 19:34, Iurie wrote: +> +>> hello, +>> in the past year gsoc qemu proposed projects there where on eproject that i liked, which were: qemu IA64 emulation : http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation +>> +>> this year i have not seen this project to be proposed, so i would like to know if the qemu will be selected i would like to know if i will be able to begin to make this project. +>> i am also a very novice in the asm programming (so very noobish in the field, so u will have to answer a lot of noobish questions :) ), so would u accept such a student to make this project? +> +> We had a student working on IA64 emulation last year. Typically, to get +> a new target working, you start off implementing Linux user space +> emulation, then continue to system emulation. User space emulation is a +> lot easier to debug, you need less features of the CPU (no MMU +> emulation, no privileged instructions) and you don't need device +> emulation code. +> +> However, IA64 maps its virtual memory to locations that x86_64 can not +> map at all. Since in QEMU, Linux user emulation leverages the host's MMU +> to do virtual memory maps, IA64 programs can't be mapped on x86_64 +> hosts, which are the typical development environment for QEMU target +> code. + +Out of curiosity, why doesn't GUEST_BASE help? + +> +> So at the end of the day, we had to cancel the IA64 emulation project +> last year. +> +> There is still the slight chance to do IA64 emulation if you take the +> KVM IA64 code from ~3-4 years ago, forward port that to current QEMU, +> get the device model running with KVM on a real IA64 machine, and then +> implement system emulation straight on. +> +> However, that is not an easy task. It requires quite in-depth knowledge +> of all the changes that happened in QEMU device models within the last +> years and a lot of debugging skills to get KVM working. So unless you +> have a lot of IA64 background, I'm afraid this is vastly out of scope +> for summer of code. Unfortunately. +> +> +> Alex +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1128935 +> +> Title: +> MIPS r4k "TLB modified exception" generated for TLB entries that are +> not visible to the TLBP instruction +> +> Status in Home for various HelenOS development branches: +> New +> Status in QEMU: +> New +> +> Bug description: +> I occasionally see that the TLBP instruction fails to find the +> corresponding TLB entry in the TLB Modified exception handler. This +> behavior is unexpected, because the invocation of the TLB Modified +> exception suggests there indeed is such an entry in the TLB and only +> requires its dirty bit to be set. +> +> The operating system which can trigger and is susceptible to this +> behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta. +> The QEMU version on which this is reproducible is QEMU 1.4.0 and also +> some others. +> +> When I looked into the QEMU sources, I noticed the following +> discrepancy, which could potentially explain the behavior: +> +> 65 /* MIPS32/MIPS64 R4000-style MMU emulation */ +> 66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot, +> 67 target_ulong address, int rw, int access_type) +> 68 { +> <snip> +> 72 for (i = 0; i < env->tlb->tlb_in_use; i++) { +> +> 1865 void r4k_helper_tlbp(CPUMIPSState *env) +> 1866 { +> <snip> +> 1875 for (i = 0; i < env->tlb->nb_tlb; i++) { +> +> From the above it appears as if the the code which searches the TLB +> for a matching entry searched also the QEMU-specific "shadow" TLB +> entries, which is, however, not in line with how the TLBP instruction +> searches the TLB. So if a matching entry is found on index >= +> tlb_in_use, the HelenOS exception handler using TLBP to locate the +> entry would hit an assertion on seeing the Index register bit P set. +> +> I also suspect there is a similar issue with the TLB Invalid +> exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is +> not susceptible in this case. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/helenos/+bug/1128935/+subscriptions +> + + +Guys, perhaps we should move this dialogue to a different thread as we +are abusing the unrelated Bug 1128935. + +Jakub + +On 04/06/2013 07:01 PM, blueswirl wrote: +> On Sat, Apr 6, 2013 at 9:31 AM, agraf <email address hidden> wrote: +>> Hi Lurie, +>> +>> On 04.04.2013, at 19:34, Iurie wrote: +>> +>>> hello, +>>> in the past year gsoc qemu proposed projects there where on eproject that i liked, which were: qemu IA64 emulation : http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation +>>> +>>> this year i have not seen this project to be proposed, so i would like to know if the qemu will be selected i would like to know if i will be able to begin to make this project. +>>> i am also a very novice in the asm programming (so very noobish in the field, so u will have to answer a lot of noobish questions :) ), so would u accept such a student to make this project? +>> +>> We had a student working on IA64 emulation last year. Typically, to get +>> a new target working, you start off implementing Linux user space +>> emulation, then continue to system emulation. User space emulation is a +>> lot easier to debug, you need less features of the CPU (no MMU +>> emulation, no privileged instructions) and you don't need device +>> emulation code. +>> +>> However, IA64 maps its virtual memory to locations that x86_64 can not +>> map at all. Since in QEMU, Linux user emulation leverages the host's MMU +>> to do virtual memory maps, IA64 programs can't be mapped on x86_64 +>> hosts, which are the typical development environment for QEMU target +>> code. +> +> Out of curiosity, why doesn't GUEST_BASE help? +> +>> +>> So at the end of the day, we had to cancel the IA64 emulation project +>> last year. +>> +>> There is still the slight chance to do IA64 emulation if you take the +>> KVM IA64 code from ~3-4 years ago, forward port that to current QEMU, +>> get the device model running with KVM on a real IA64 machine, and then +>> implement system emulation straight on. +>> +>> However, that is not an easy task. It requires quite in-depth knowledge +>> of all the changes that happened in QEMU device models within the last +>> years and a lot of debugging skills to get KVM working. So unless you +>> have a lot of IA64 background, I'm afraid this is vastly out of scope +>> for summer of code. Unfortunately. +>> +>> +>> Alex +>> +>> -- +>> You received this bug notification because you are a member of qemu- +>> devel-ml, which is subscribed to QEMU. +>> https://bugs.launchpad.net/bugs/1128935 +>> +>> Title: +>> MIPS r4k "TLB modified exception" generated for TLB entries that are +>> not visible to the TLBP instruction +>> +>> Status in Home for various HelenOS development branches: +>> New +>> Status in QEMU: +>> New +>> +>> Bug description: +>> I occasionally see that the TLBP instruction fails to find the +>> corresponding TLB entry in the TLB Modified exception handler. This +>> behavior is unexpected, because the invocation of the TLB Modified +>> exception suggests there indeed is such an entry in the TLB and only +>> requires its dirty bit to be set. +>> +>> The operating system which can trigger and is susceptible to this +>> behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta. +>> The QEMU version on which this is reproducible is QEMU 1.4.0 and also +>> some others. +>> +>> When I looked into the QEMU sources, I noticed the following +>> discrepancy, which could potentially explain the behavior: +>> +>> 65 /* MIPS32/MIPS64 R4000-style MMU emulation */ +>> 66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot, +>> 67 target_ulong address, int rw, int access_type) +>> 68 { +>> <snip> +>> 72 for (i = 0; i < env->tlb->tlb_in_use; i++) { +>> +>> 1865 void r4k_helper_tlbp(CPUMIPSState *env) +>> 1866 { +>> <snip> +>> 1875 for (i = 0; i < env->tlb->nb_tlb; i++) { +>> +>> From the above it appears as if the the code which searches the TLB +>> for a matching entry searched also the QEMU-specific "shadow" TLB +>> entries, which is, however, not in line with how the TLBP instruction +>> searches the TLB. So if a matching entry is found on index >= +>> tlb_in_use, the HelenOS exception handler using TLBP to locate the +>> entry would hit an assertion on seeing the Index register bit P set. +>> +>> I also suspect there is a similar issue with the TLB Invalid +>> exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is +>> not susceptible in this case. +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/helenos/+bug/1128935/+subscriptions +>> +> + + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Yes, running the following command line with QEMU 2.11.0 on the HelenOS 0.7.1 image downloaded from http://www.helenos.org/releases/HelenOS-0.7.1-mips32-malta-be.boot will result in occasional "failures" of the TLBP instruction as described in this bug and as evidenced by a warning printed by HelenOS, which goes like: + + tlb_modified: TLBP failed in exception handler (badvaddr=0x7001d7d8, ASID=29). + +The command line to reproduce: + + qemu-system-mips -cpu 4Kc -drive file=hdisk.img,index=0,media=disk,format=raw -device e1000,vlan=0 -net user,hostfwd=udp::8080-:8080,hostfwd=udp::8081-:8081,hostfwd=tcp::8080-:8080,hostfwd=tcp::8081-:8081,hostfwd=tcp::2223-:2223 -usb -device intel-hda -device hda-duplex -kernel HelenOS-0.7.1-mips32-malta-be.boot -nographic + +It would be good if someone familiar with the mips target had a look at this. + +A shorter command line to reproduce this with QEMU 2.11.0 and HelenOS 0.7.1 would be: + +$ qemu-system-mips -cpu 4Kc -kernel HelenOS-0.7.1-mips32-malta-be.boot -nographic + + +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/94 + + diff --git a/results/classifier/zero-shot/108/permissions/1143 b/results/classifier/zero-shot/108/permissions/1143 new file mode 100644 index 000000000..5fe276244 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1143 @@ -0,0 +1,93 @@ +permissions: 0.949 +other: 0.939 +graphic: 0.934 +semantic: 0.919 +device: 0.910 +network: 0.908 +debug: 0.900 +performance: 0.887 +PID: 0.885 +files: 0.885 +KVM: 0.867 +vnc: 0.863 +boot: 0.792 +socket: 0.775 + +Breakpoints missed when a function is split into two memory pages. +Description of problem: +Qemu seems to ignore some breakpoints when the start of a function is +in another page than where the breakpoint is set. + +In my case, I've a function `__gnat_debug_raise_exception` which starts at `0x10bff2` and I've set with gdb a breakpoint at `0x10c00e` (in another page). +While running with `qemu -d in_asm,exec`, I can see that the whole function is executed at once and that no breakpoint is fired. + +``` +(gdb) b *0x00108fbc +(gdb) b *0x0010c00e +(gdb) target remote :1234 +(gdb) c + +Trace 0: 0x7f277c0174c0 [0000000000000000/0000000000108fb9/0040c0b0/ff000201] ada__exceptions__complete_occurrence +---------------- + +// gdb hits first breakpoint here. +Breakpoint 3, 0x0000000000108fbc .... +(gdb) ni + +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f277c000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp +0x0010bff3: 48 89 e5 movq %rsp, %rbp +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +0x0010bffa: 48 89 d1 movq %rdx, %rcx +0x0010bffd: 48 89 f0 movq %rsi, %rax +0x0010c000: 48 89 fa movq %rdi, %rdx +0x0010c003: 48 89 ca movq %rcx, %rdx +0x0010c006: 48 89 45 e0 movq %rax, -0x20(%rbp) +0x0010c00a: 48 89 55 e8 movq %rdx, -0x18(%rbp) +0x0010c00e: 48 8b 45 e0 movq -0x20(%rbp), %rax +0x0010c012: 90 nop +0x0010c013: 5d popq %rbp +0x0010c014: c3 retq + +Trace 0: 0x7f277c000100 [0000000000000000/000000000010bff2/0040c0b0/ff000000] __gnat_debug_raise_exception +Digging a bit more, it seems that it seems related to + +// gdb ni stop here. Breakpoints at 0x10c00e have been ignored. +``` + +Note that if I'm setting another breakpoint at `0x0010bffd` (thus not at the start of the function but still in the same page), the execution +will be executed step by step and the breakpoint at 0x10c00e will be triggered normally. + + +``` +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f6af4000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp + +Trace 0: 0x7f6af4000100 [0000000000000000/000000000010bff2/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff3: 48 89 e5 movq %rsp, %rbp + +Trace 0: 0x7f6af4000280 [0000000000000000/000000000010bff3/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +... +``` + +I've dug a bit into qemu translator code and I guess `check_for_breakpoint` should check that the whole function is in the same page before skipping step by step. But I'm not sure if it's possible because the TB is created after `check_for_breakpoint` IIUC. + +Sadly as of now, I don't have a C reproducer. I can try to provide you my "foo" program which is an Ada program. But maybe if you've a better idea how to reproduce that or an idea of to fix that, I'll be glad to help you. + +Thanks, +Clément diff --git a/results/classifier/zero-shot/108/permissions/1163474 b/results/classifier/zero-shot/108/permissions/1163474 new file mode 100644 index 000000000..80c0a2ca0 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1163474 @@ -0,0 +1,29 @@ +permissions: 0.977 +device: 0.864 +boot: 0.739 +graphic: 0.702 +network: 0.661 +other: 0.659 +socket: 0.586 +PID: 0.577 +semantic: 0.501 +vnc: 0.456 +performance: 0.416 +files: 0.367 +debug: 0.241 +KVM: 0.192 + +qemu mount usb permission denied + +I use debian with kde and the new Qemu 14.0 . I use this Qemu start arguments: + +/usr/bin/qemu-system-x86_64 -monitor stdio -smp 2 -soundhw es1370,ac97 -k de -enable-kvm -m 4096 -localtime -cdrom /dev/sr0 -hda /home/....../.aqemu/Windows_7_x64_HDA.img -boot once=d,menu=off -net nic,vlan=0 -net user,vlan=0 -usb -usbdevice tablet -device usb-host,hostbus=1,hostaddr=2 -device usb-host,hostbus=2,hostaddr=2 -name "Windows 7 x64" + +Then I get this error: /dev/bus/usb/000/001: Permission denied + +Some says I must change the permissions /dev/bus/usb to 777 but I think that can't be the solution and when I restart the changes are lost. I think there is also a problem with the automount in KDE. + +The user user who starts Qemu has also full access to usb device (member of the group plugdev) + +Triaging old bug tickets ... Sounds like this was rather a problem with your distro / udev than with qemu. In case you still have the problem, please report it to the Debian bug tracker first. + diff --git a/results/classifier/zero-shot/108/permissions/1175513 b/results/classifier/zero-shot/108/permissions/1175513 new file mode 100644 index 000000000..18279b321 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1175513 @@ -0,0 +1,125 @@ +permissions: 0.928 +graphic: 0.880 +debug: 0.862 +semantic: 0.851 +device: 0.842 +performance: 0.841 +other: 0.838 +network: 0.832 +boot: 0.820 +files: 0.815 +socket: 0.814 +KVM: 0.808 +PID: 0.808 +vnc: 0.761 + +Qemu 1.5-git gpu clock control doesn`t work after guest reboot + +I run qemu from git with such command: + +qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 -cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on -device vfio-pci,host=02:00.0,x-vga=on \ +-enable-kvm -monitor stdio -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device intel-hda -device hda-duplex \ +-drive file='/home/<user>/qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \ +-drive file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \ +-spice port=5930,disable-ticketing + +Before guest (Windows 7) reboot, videocard works in 3D mode with full frequency. But after reboot videocard works in 3D only with powersafe frequency. Then I must reboot host for recover gpu clock control. + + + + + +Linux localhost 3.8.10-gentoo #3 SMP PREEMPT Wed May 1 19:30:30 MSK 2013 x86_64 AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux + + +One-shot use is about the state of the art until we implement a way for vfio to do a bus reset on devices. A couple comments on the usage; we're using the x-vga option to vfio-pci and also using -vga qxl. Without specifying a bus for the vfio-pci device this will put qxl vga and vfio vga both on the root complex with no way to switch between them aside from completely disabling the device. This likely means qxl is disabled and effectively the same as booting with -vga none. Second oddity, vfio vga support wasn't added to the kernel until 3.9, how does this qemu command like work on 3.8? + +First I added radeon.ko and fglrx.ko to the blacklist. + +Second I ran the + +modprobe vfio-pci +echo "0000:02:00.0" > /sys/bus/pci/devices/0000\:02\:00.0/driver/unbind +echo "0000:02:00.1" > /sys/bus/pci/devices/0000\:02\:00.1/driver/unbind +echo "1002 6739" > /sys/bus/pci/drivers/vfio-pci/new_id +echo "1002 aa88" > /sys/bus/pci/drivers/vfio-pci/new_id + +And third I ran qemu with the -device vfio-pci,host=02:00.0,x-vga=on options + +4-th I installed the Catalyst drivers in windows 7 and change display to HDMI output. But during a reboot the Catalyst driver switches the graphics card to powersave mode. + +With kernel-3.9.0 host system hangs after guest (win 7) poweroff or reboot. + +Try these: + +git://github.com/awilliam/linux-vfio.git vfio-vga-reset +git://github.com/awilliam/qemu-vfio.git vfio-vga-reset + +When using both this kernel and this qemu, we'll do a PCI bus reset, which should give you much more consistent behavior both between instances of the guest and at guest reset. + +With VFIO_PCI_VGA, vfio-vga-reset branches and "-vga none -device vfio-pci,host=02:00.0,x-vga=on" host system hangs after guest restarting or turning off. + +With no VFIO_PCI_VGA, vfio-vga-reset branches and "-vga none -device vfio-pci,host=02:00.0" catalyst drivers works fine in guest. But after guest restarting the video card is running in powersafe mode. + +With VFIO_PCI_VGA, vfio-vga-reset branches and "-vga none -device vfio-pci,host=02:00.0,x-vga=on" I also received an error: + +"qemu-system-x86_64: Attempt to reset PCI bus for VGA support failed (Inappropriate ioctl for device). VGA may not work." + +But the drivers were run without problems. + +I installed Windows 8 with VFIO_PCI_VGA, vfio-vga-reset branches and "-vga none -device vfio-pci,host=02:00.0,x-vga=on" I received an error: + +"qemu-system-x86_64: Attempt to reset PCI bus for VGA support failed (Inappropriate ioctl for device). VGA may not work." on start. + +Then I installed the catalyst drivers. I started the Valley benchmark and the video card is working in normally 3D mode. After rebooting the host system does not hang, but in guest graphics card was in powersafe mode with 100 mhz GPU and 300 mhz memry clocks. + + +Please confirm that you're running the kernel from this branch on the host system: + +git://github.com/awilliam/linux-vfio.git vfio-vga-reset + +Both host kernel and qemu changes are required. Unfortunately the error code from the ioctl makes it difficult to tell if it isn't available in the kernel or failed, something I need to correct in getting them upstream. These branches only modify the x-vga=on path. Comment #8 indicates using this hangs the host, but comments #9 & #10 says the bus reset call didn't work, did you perhaps boot back into the wrong kernel after the system hang? + +From your lspci, 02:00.0 and 02:00.1 are below the 00:0b.0 root port. The properties of 00:0b.0 seem to indicate that 02:00.0 and 02:00.1 should be the only iommu group below this root port, so a bus reset should be available, assuming we're using the correct kernel. In addition to verifying the kernel in use, please attach the output of `find /sys/kernel/iommu_groups/` + +When I use vga none -device vfio-pci,host=02:00.0,x-vga=on with "Linux localhost 3.9.0-rc2 #2 SMP PREEMPT Sat May 4 11:45:12 MSK 2013 x86_64 AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux" and VFIO_PCI_VGA support. System starting with "qemu-system-x86_64: Attempt to reset PCI bus for VGA support failed (Inappropriate ioctl for device). VGA may not work" warning. And Windows 7 loading with the catalyst drivers. But when I reboot the guest, the host hangs up. + +On #8, #9, #10 comments I ran system with vfio-vga-reset branch. + + + +The above linux tree is based on 3.9.0, not -rc2, so it appears you're not using the correct kernel. + +Sry. With x-vga=on and "Linux localhost 3.9.0+ #3 SMP PREEMPT Sun May 5 00:58:56 MSK 2013 x86_64 AMD FX(tm)-8120 Eight-Core Processor AuthenticAMD GNU/Linux" it`s work fine. + +On Sunday or Monday I will test Geforce gt210 and gt610. + +And bad news too. System hangs after guest poweroff. + +Also I tested nvidia gt210. All works fine: 3D, reboot, poweroff, clocks control, bios initialization. + +So the result is: + +HD6850 - works fully, host hang on guest poweroff +GT210 - works fully, no host issues + +Is that correct? Are you attempting to rebind the HD6850 to host drivers after qemu is shutdown, or does the host hang happen prior to where that would be possible? What about killing qemu with a ^C, does it hang the host the same way? If you could run the host in text mode or with a serial or net console so we can see if there are any messages prior to the hang, that would be extremely useful. + + + +>Are you attempting to rebind the HD6850 to host drivers after qemu is shutdown + +No, I did not rebind HD6850 to the host system. System hangs at shutdown guest + +>HD6850 - works fully, host hang on guest poweroff + +Yes. + +In text mode and on net console there are no errors, host system just freezes after guest poweroff. This may be a hang-up the pcie? + +And all work after killing qemu with ^C. + +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/zero-shot/108/permissions/1207686 b/results/classifier/zero-shot/108/permissions/1207686 new file mode 100644 index 000000000..cde41f97f --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1207686 @@ -0,0 +1,258 @@ +permissions: 0.972 +vnc: 0.959 +network: 0.949 +debug: 0.942 +PID: 0.940 +semantic: 0.932 +socket: 0.930 +device: 0.928 +performance: 0.923 +other: 0.919 +KVM: 0.917 +boot: 0.916 +files: 0.878 +graphic: 0.870 + +qemu-1.4.0 and onwards, linux kernel 3.2.x, heavy I/O leads to kernel_hung_tasks_timout_secs message and unresponsive qemu-process + +Hi, + +after some testing I tried to narrow down a problem, which was initially reported by some users. +Seen on different distros - debian 7.1, ubuntu 12.04 LTS, IPFire-2.3 as reported by now. + +All using some flavour of linux-3.2.x kernel. + +Tried e.g. under Ubuntu an upgrade to "Linux 3.8.0-27-generic x86_64" which solves the problem. +Problem could be triggert with some workload ala: + +spew -v --raw -P -t -i 3 -b 4k -p random -B 4k 1G /tmp/doof.dat +and in parallel do some apt-get install/remove/whatever. + +That results in a somewhat stuck qemu-session with the bad "kernel_hung_task..." messages. + +A typical command-line is as follows: + +/usr/local/qemu-1.6.0/bin/qemu-system-x86_64 -usbdevice tablet -enable-kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run/qemu-server/760.vnc,password -qmp unix:/var/run/qemu-server/760.qmp,server,nowait -nodefaults -serial none -parallel none -device virtio-net-pci,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 -device virtio-blk-pci,drive=virtio0 -drive format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0,aio=native -drive format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1,aio=native -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc + +no "system_reset", "sendkey ctrl-alt-delete" or "q" in monitoring-session is accepted, need to hard-kill the process. + +Please give any advice on what to do for tracing/debugging, because the number of tickets here are raising, and noone knows, what users are doing inside their VM. + +Kind regards, + +Oliver Francke. + +On Fri, Aug 02, 2013 at 09:58:29AM -0000, Oliver Francke wrote: +> after some testing I tried to narrow down a problem, which was initially reported by some users. +> Seen on different distros - debian 7.1, ubuntu 12.04 LTS, IPFire-2.3 as reported by now. +> +> All using some flavour of linux-3.2.x kernel. +> +> Tried e.g. under Ubuntu an upgrade to "Linux 3.8.0-27-generic x86_64" which solves the problem. + +Is that a guest kernel upgrade? + +> Problem could be triggert with some workload ala: +> +> spew -v --raw -P -t -i 3 -b 4k -p random -B 4k 1G /tmp/doof.dat +> and in parallel do some apt-get install/remove/whatever. +> +> That results in a somewhat stuck qemu-session with the bad +> "kernel_hung_task..." messages. +> +> A typical command-line is as follows: +> +> /usr/local/qemu-1.6.0/bin/qemu-system-x86_64 -usbdevice tablet -enable- +> kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor +> unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run/qemu- +> server/760.vnc,password -qmp unix:/var/run/qemu- +> server/760.qmp,server,nowait -nodefaults -serial none -parallel none +> -device virtio-net-pci,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev +> type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh +> -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 +> -device virtio-blk-pci,drive=virtio0 -drive +> format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0,aio=native +> -drive +> format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1,aio=native +> -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive +> if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc +> +> no "system_reset", "sendkey ctrl-alt-delete" or "q" in monitoring- +> session is accepted, need to hard-kill the process. + +Yesterday I saw a possibly related report on IRC. It was a Windows +guest running under OpenStack with images on Ceph. + +They reported that the QEMU process would lock up - ping would not work +and their management tools showed 0 CPU activity for the guest. +However, they were able to "kick" the guest by taking a VNC screenshot +(I think). Then it would come back to life. + +If you have a Linux guest that is reporting kernel_hung_task, then it +could be a similar scenario. + +Please confirm that the hung task message is from inside the guest. + +If you are able to reproduce this and have an alternative non-Ceph +storage pool, please try that since Ceph is common to both these bug +reports. + +Stefan + + +Hi Stefan, + +Am 02.08.2013 um 17:24 schrieb Stefan Hajnoczi <email address hidden>: + +> On Fri, Aug 02, 2013 at 09:58:29AM -0000, Oliver Francke wrote: +>> after some testing I tried to narrow down a problem, which was initially reported by some users. +>> Seen on different distros - debian 7.1, ubuntu 12.04 LTS, IPFire-2.3 as reported by now. +>> +>> All using some flavour of linux-3.2.x kernel. +>> +>> Tried e.g. under Ubuntu an upgrade to "Linux 3.8.0-27-generic x86_64" which solves the problem. +> +> Is that a guest kernel upgrade? + +yeah, sorry if that was not clear enough. + +> +>> Problem could be triggert with some workload ala: +>> +>> spew -v --raw -P -t -i 3 -b 4k -p random -B 4k 1G /tmp/doof.dat +>> and in parallel do some apt-get install/remove/whatever. +>> +>> That results in a somewhat stuck qemu-session with the bad +>> "kernel_hung_task..." messages. +>> +>> A typical command-line is as follows: +>> +>> /usr/local/qemu-1.6.0/bin/qemu-system-x86_64 -usbdevice tablet -enable- +>> kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor +>> unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run/qemu- +>> server/760.vnc,password -qmp unix:/var/run/qemu- +>> server/760.qmp,server,nowait -nodefaults -serial none -parallel none +>> -device virtio-net-pci,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev +>> type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh +>> -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 +>> -device virtio-blk-pci,drive=virtio0 -drive +>> format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0,aio=native +>> -drive +>> format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1,aio=native +>> -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive +>> if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc +>> +>> no "system_reset", "sendkey ctrl-alt-delete" or "q" in monitoring- +>> session is accepted, need to hard-kill the process. +> +> Yesterday I saw a possibly related report on IRC. It was a Windows +> guest running under OpenStack with images on Ceph. +> +> They reported that the QEMU process would lock up - ping would not work +> and their management tools showed 0 CPU activity for the guest. +> However, they were able to "kick" the guest by taking a VNC screenshot +> (I think). Then it would come back to life. +> +> If you have a Linux guest that is reporting kernel_hung_task, then it +> could be a similar scenario. +> +> Please confirm that the hung task message is from inside the guest. +> + +confirmed. + +> If you are able to reproduce this and have an alternative non-Ceph +> storage pool, please try that since Ceph is common to both these bug +> reports. +> + +I can reproduce it with: kernel 3.2.something + qemu-1.[456] ( never spent much time on 1.3) and high I/O. +I took this VM later this day and converted it to local-storage-qcow2, no prob with any kernel. I already asked on ceph-users-list for assistance, especially from Josh ( if he's not on summer holiday ;) ) + +What is strange, I have a session via VNC-console opened and have a loop ala: + +while true; do apt-get install -y ntp libopts25; apt-get remove -y ntp-libopts25; done +and and parallel spew as described, the apt-"session" dies and one can see the hung_task-thingy, but I still can restart the spew-test. +Just for completeness. + +Thnx for you attention, + +Oliver. + +> Stefan +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1207686 +> +> Title: +> qemu-1.4.0 and onwards, linux kernel 3.2.x, heavy I/O leads to +> kernel_hung_tasks_timout_secs message and unresponsive qemu-process +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> after some testing I tried to narrow down a problem, which was initially reported by some users. +> Seen on different distros - debian 7.1, ubuntu 12.04 LTS, IPFire-2.3 as reported by now. +> +> All using some flavour of linux-3.2.x kernel. +> +> Tried e.g. under Ubuntu an upgrade to "Linux 3.8.0-27-generic x86_64" which solves the problem. +> Problem could be triggert with some workload ala: +> +> spew -v --raw -P -t -i 3 -b 4k -p random -B 4k 1G /tmp/doof.dat +> and in parallel do some apt-get install/remove/whatever. +> +> That results in a somewhat stuck qemu-session with the bad +> "kernel_hung_task..." messages. +> +> A typical command-line is as follows: +> +> /usr/local/qemu-1.6.0/bin/qemu-system-x86_64 -usbdevice tablet +> -enable-kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor +> unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run +> /qemu-server/760.vnc,password -qmp unix:/var/run/qemu- +> server/760.qmp,server,nowait -nodefaults -serial none -parallel none +> -device virtio-net-pci,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev +> type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh +> -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 +> -device virtio-blk-pci,drive=virtio0 -drive +> format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0,aio=native +> -drive +> format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1,aio=native +> -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive +> if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc +> +> no "system_reset", "sendkey ctrl-alt-delete" or "q" in monitoring- +> session is accepted, need to hard-kill the process. +> +> Please give any advice on what to do for tracing/debugging, because +> the number of tickets here are raising, and noone knows, what users +> are doing inside their VM. +> +> Kind regards, +> +> Oliver Francke. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1207686/+subscriptions + + + +Hi, + +opened a ticket with the ceph-guys, and it turned out to be a bug in "librados aio flush". + +With latest "wip-librados-aio-flush (bobtail)" I got no error even with _very_ high load. + +Thnx for the attention ;) + +Oliver. + + +Closing as "Invalid" since this was not a QEMU bug according to comment #3. + diff --git a/results/classifier/zero-shot/108/permissions/12360755 b/results/classifier/zero-shot/108/permissions/12360755 new file mode 100644 index 000000000..3de2a3c4a --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/12360755 @@ -0,0 +1,306 @@ +permissions: 0.930 +debug: 0.922 +semantic: 0.911 +device: 0.902 +graphic: 0.899 +performance: 0.895 +other: 0.886 +PID: 0.876 +files: 0.851 +boot: 0.818 +vnc: 0.810 +socket: 0.805 +KVM: 0.770 +network: 0.738 + +[Qemu-devel] [BUG] virtio-net linux driver fails to probe on MIPS Malta since 'hw/virtio-pci: fix virtio behaviour' + +Hi, + +I've bisected the following failure of the virtio_net linux v4.10 driver +to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: + +virtio_net virtio0: virtio: device uses modern interface but does not have +VIRTIO_F_VERSION_1 +virtio_net: probe of virtio0 failed with error -22 + +To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). + +It appears that adding ",disable-modern=on,disable-legacy=off" to the +virtio-net -device makes it work again. + +I presume this should really just work out of the box. Any ideas why it +isn't? + +Cheers +James +signature.asc +Description: +Digital signature + +On 03/17/2017 11:57 PM, James Hogan wrote: +Hi, + +I've bisected the following failure of the virtio_net linux v4.10 driver +to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: + +virtio_net virtio0: virtio: device uses modern interface but does not have +VIRTIO_F_VERSION_1 +virtio_net: probe of virtio0 failed with error -22 + +To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). + +It appears that adding ",disable-modern=on,disable-legacy=off" to the +virtio-net -device makes it work again. + +I presume this should really just work out of the box. Any ideas why it +isn't? +Hi, + + +This is strange. This commit changes virtio devices from legacy to virtio +"transitional". +(your command line changes it to legacy) +Linux 4.10 supports virtio modern/transitional (as far as I know) and on QEMU +side +there is nothing new. + +Michael, do you have any idea? + +Thanks, +Marcel +Cheers +James + +On Mon, Mar 20, 2017 at 05:21:22PM +0200, Marcel Apfelbaum wrote: +> +On 03/17/2017 11:57 PM, James Hogan wrote: +> +> Hi, +> +> +> +> I've bisected the following failure of the virtio_net linux v4.10 driver +> +> to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: +> +> +> +> virtio_net virtio0: virtio: device uses modern interface but does not have +> +> VIRTIO_F_VERSION_1 +> +> virtio_net: probe of virtio0 failed with error -22 +> +> +> +> To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). +> +> +> +> It appears that adding ",disable-modern=on,disable-legacy=off" to the +> +> virtio-net -device makes it work again. +> +> +> +> I presume this should really just work out of the box. Any ideas why it +> +> isn't? +> +> +> +> +Hi, +> +> +> +This is strange. This commit changes virtio devices from legacy to virtio +> +"transitional". +> +(your command line changes it to legacy) +> +Linux 4.10 supports virtio modern/transitional (as far as I know) and on QEMU +> +side +> +there is nothing new. +> +> +Michael, do you have any idea? +> +> +Thanks, +> +Marcel +My guess would be firmware mishandling 64 bit BARs - we saw such +a case on sparc previously. As a result you are probably reading +all zeroes from features register or something like that. +Marcel, could you send a patch making the bar 32 bit? +If that helps we know what the issue is. + +> +> Cheers +> +> James +> +> + +On 03/20/2017 05:43 PM, Michael S. Tsirkin wrote: +On Mon, Mar 20, 2017 at 05:21:22PM +0200, Marcel Apfelbaum wrote: +On 03/17/2017 11:57 PM, James Hogan wrote: +Hi, + +I've bisected the following failure of the virtio_net linux v4.10 driver +to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: + +virtio_net virtio0: virtio: device uses modern interface but does not have +VIRTIO_F_VERSION_1 +virtio_net: probe of virtio0 failed with error -22 + +To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). + +It appears that adding ",disable-modern=on,disable-legacy=off" to the +virtio-net -device makes it work again. + +I presume this should really just work out of the box. Any ideas why it +isn't? +Hi, + + +This is strange. This commit changes virtio devices from legacy to virtio +"transitional". +(your command line changes it to legacy) +Linux 4.10 supports virtio modern/transitional (as far as I know) and on QEMU +side +there is nothing new. + +Michael, do you have any idea? + +Thanks, +Marcel +My guess would be firmware mishandling 64 bit BARs - we saw such +a case on sparc previously. As a result you are probably reading +all zeroes from features register or something like that. +Marcel, could you send a patch making the bar 32 bit? +If that helps we know what the issue is. +Sure, + +Thanks, +Marcel +Cheers +James + +On 03/20/2017 05:43 PM, Michael S. Tsirkin wrote: +On Mon, Mar 20, 2017 at 05:21:22PM +0200, Marcel Apfelbaum wrote: +On 03/17/2017 11:57 PM, James Hogan wrote: +Hi, + +I've bisected the following failure of the virtio_net linux v4.10 driver +to probe in QEMU v2.9.0-rc1 emulating a MIPS Malta machine: + +virtio_net virtio0: virtio: device uses modern interface but does not have +VIRTIO_F_VERSION_1 +virtio_net: probe of virtio0 failed with error -22 + +To QEMU commit 9a4c0e220d8a ("hw/virtio-pci: fix virtio behaviour"). + +It appears that adding ",disable-modern=on,disable-legacy=off" to the +virtio-net -device makes it work again. + +I presume this should really just work out of the box. Any ideas why it +isn't? +Hi, + + +This is strange. This commit changes virtio devices from legacy to virtio +"transitional". +(your command line changes it to legacy) +Linux 4.10 supports virtio modern/transitional (as far as I know) and on QEMU +side +there is nothing new. + +Michael, do you have any idea? + +Thanks, +Marcel +My guess would be firmware mishandling 64 bit BARs - we saw such +a case on sparc previously. As a result you are probably reading +all zeroes from features register or something like that. +Marcel, could you send a patch making the bar 32 bit? +If that helps we know what the issue is. +Hi James, + +Can you please check if the below patch fixes the problem? +Please note it is not a solution. + +diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c +index f9b7244..5b4d429 100644 +--- a/hw/virtio/virtio-pci.c ++++ b/hw/virtio/virtio-pci.c +@@ -1671,9 +1671,7 @@ static void virtio_pci_device_plugged(DeviceState *d, +Error **errp) + } + + pci_register_bar(&proxy->pci_dev, proxy->modern_mem_bar_idx, +- PCI_BASE_ADDRESS_SPACE_MEMORY | +- PCI_BASE_ADDRESS_MEM_PREFETCH | +- PCI_BASE_ADDRESS_MEM_TYPE_64, ++ PCI_BASE_ADDRESS_SPACE_MEMORY, + &proxy->modern_bar); + + proxy->config_cap = virtio_pci_add_mem_cap(proxy, &cfg.cap); + + +Thanks, +Marcel + +Hi Marcel, + +On Tue, Mar 21, 2017 at 04:16:58PM +0200, Marcel Apfelbaum wrote: +> +Can you please check if the below patch fixes the problem? +> +Please note it is not a solution. +> +> +diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c +> +index f9b7244..5b4d429 100644 +> +--- a/hw/virtio/virtio-pci.c +> ++++ b/hw/virtio/virtio-pci.c +> +@@ -1671,9 +1671,7 @@ static void virtio_pci_device_plugged(DeviceState *d, +> +Error **errp) +> +} +> +> +pci_register_bar(&proxy->pci_dev, proxy->modern_mem_bar_idx, +> +- PCI_BASE_ADDRESS_SPACE_MEMORY | +> +- PCI_BASE_ADDRESS_MEM_PREFETCH | +> +- PCI_BASE_ADDRESS_MEM_TYPE_64, +> ++ PCI_BASE_ADDRESS_SPACE_MEMORY, +> +&proxy->modern_bar); +> +> +proxy->config_cap = virtio_pci_add_mem_cap(proxy, &cfg.cap); +Sorry for the delay trying this, I was away last week. + +No, it doesn't seem to make any difference. + +Thanks +James +signature.asc +Description: +Digital signature + diff --git a/results/classifier/zero-shot/108/permissions/1253777 b/results/classifier/zero-shot/108/permissions/1253777 new file mode 100644 index 000000000..f6ffa1757 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1253777 @@ -0,0 +1,103 @@ +permissions: 0.948 +semantic: 0.936 +KVM: 0.922 +debug: 0.921 +device: 0.905 +PID: 0.903 +vnc: 0.900 +graphic: 0.897 +performance: 0.896 +files: 0.891 +network: 0.887 +other: 0.881 +socket: 0.874 +boot: 0.839 + +OpenBSD VM running on OpenBSD host has sleep calls taking twice as long as they should + +Running a script like + +while [ 1 ] +do + date + sleep 1 +done + +on the VM will result in the (correct) date being displayed, but it is displayed only every two (!) seconds. We have also noticed that if we connect to the VM's console using VNC, and move the mouse pointer constantly in the VNC window, the script runs normally with updates every second! Note that the script doesn't have to be running on the VM's console - it's also possible to (say) ssh to the VM from a separate machine and run the script and it will display the '2 second' issue, but as soon as you move the mouse pointer constantly in the VNC console window the script starts behaving normally with updates every second. + +I have only seen this bug when running an OpenBSD VM on an OpenBSD host. Running an OpenBSD VM on a Linux host does not exhibit the problem for me. I also belive (am told) that a Linux VM running on an OpenBSD host does not exhibit the problem. + +I have been using the OpenBSD 5.4 64 bit distro which comes with qemu 1.5.1 in a package, however I tried compiling qemu 1.6.1 and that has the same bug. In fact older OpenBSD distros have the same issue - going back to OpenBSD distros from two years ago still have the problem. This is not a 'new' bug recently introduced. + +Initially I wondered if it could be traced to an incorrectly set command line option, but I've since gone through many of the options in the man page simply trying different values (eg. different CPU types ( -cpu) , different emulated PC (-M)) but so far the problem remains. + +I'm quite happy to run tests in order to track this bug down better. We use qemu running on OpenBSD extensively and find it very useful! + +Hi, please test qemu 1.7.0-rc. There were several changes to the timer machinery that can help this bug. + +I'll have a look at it now. + +Regards, + +-Martin + + +On 28/11/13 01:58, Paolo Bonzini wrote: +> Hi, please test qemu 1.7.0-rc. There were several changes to the timer +> machinery that can help this bug. +> + + +-- +R A Ward Ltd. | We take the privacy of our customers seriously. +Christchurch | All sensitive E-Mail attachments MUST be encrypted. +New Zealand + + + +I downloaded 1.7.0-rc2 and compiled it. Running it, I see the version +number reported as 1.6.92!? + +In any case, I don't see any improvement, ie. the bug is still there. + +Regards, + +-Martin + + +On 28/11/13 01:58, Paolo Bonzini wrote: +> Hi, please test qemu 1.7.0-rc. There were several changes to the timer +> machinery that can help this bug. +> + + + +Hadn't heard any news on this bug so decided to check the latest source. 1.7.0 now available so downloaded it and compiled it. No mean feat in itself for OpenBSD. FWIW it seemed a lot more difficult than for earlier (1.6.x) versions. 1.7.0 now reports its version as 1.7.0 - a good start. Alas the "2 second" bug still appears to be there. + +This issue was fixed in the openstack/python-tripleoclient 0.0.10 release. + +What does comment #5 mean? Is this issue now fixed with the latest version of QEMU? + +I hadn't seen comment #5. Not sure how that affects qemu. +Unfortunately I'm not in a position to set up a system any time soon +with the latest versions of everything to see if the bug is still present. + + +On 24/01/17 08:32, Thomas Huth wrote: +> What does comment #5 mean? Is this issue now fixed with the latest +> version of QEMU? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + +-- +R A Ward Ltd. | We take the privacy of our customers seriously. +Christchurch | All sensitive E-Mail attachments MUST be encrypted. +New Zealand + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1254940 b/results/classifier/zero-shot/108/permissions/1254940 new file mode 100644 index 000000000..707e47a4c --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1254940 @@ -0,0 +1,111 @@ +permissions: 0.963 +graphic: 0.962 +other: 0.953 +performance: 0.948 +device: 0.945 +debug: 0.941 +socket: 0.940 +semantic: 0.940 +PID: 0.933 +boot: 0.918 +files: 0.914 +network: 0.897 +KVM: 0.824 +vnc: 0.777 + +qemu-KVM guest OS occurs many ext3-fs errors after multiple forced shutdown + +Hi: +I met some filesysterm errors in a sles guest on KVM. My system environment is: +HOST: + suse 10, the kernel version is 2.6.32.43 + Qemu-KVM 1.2 + Libvirt 1.0 +guest OS: + suse 10, the kernel version is 2.6.32.43 +VMs use a qcow2 disk. + +Description of problem: +I have 20+ VMs with qcow2 disk, these VMs have been forced to shut down by +"virsh destroy" many times during and after VM installation. +When these vm reboot,dmesg show a ext3-fs mount error occurred on /usr/local +partion /dev/vda3: + EXT3-fs warning: mounting fs with errors, running e2fsck is recommendedand +when I wrote into partion /dev/vda3,some errors occurred in dmesg: +1.error (device vda3): ext3_free_blocks: Freeing blocks not in datazone - block += 1869619311, count = 1error (device vda3): ext3_free_blocks_sb: bit already +cleared for block 2178152error (device vda3): ext3_readdir: bad entry in +directory #1083501: +2.[347470.661893] attempt to access beyond end of device[347470.661896] vda3: +rw=0, want=6870892952, limit=41945715[347470.661897] EXT3-fs error (device +vda3): ext3_free_branches: Read failure, inode=1083508, block=858861618 +3.EXT3-fs error (device vda3): ext3_new_block: block(4295028581) >= blocks +count(-1) - block_group = 1, es == ffff88021b6c7400 + +I suspect this fs-error is caused by multiple forced shutdown, but I can't +reproduce this bug now. + +Could anyone has an idea or suggestion to help me? + +Thanks in Advance +Regards +Ben + +Reproducible: Always + +Steps to Reproduce: +I can't reproduce this bug now. + + +additional: +1.multiple forced shutdown during and after the vm installing +2.vm with qcow2 disk +3.different vm dmesg different errors in above error list(1/2/3) + +On Tue, Nov 26, 2013 at 01:59:41AM -0000, benjamin_zb wrote: +> I met some filesysterm errors in a sles guest on KVM. My system environment is: +> HOST: +> suse 10, the kernel version is 2.6.32.43 +> Qemu-KVM 1.2 +> Libvirt 1.0 +> guest OS: +> suse 10, the kernel version is 2.6.32.43 +> VMs use a qcow2 disk. +> +> Description of problem: +> I have 20+ VMs with qcow2 disk, these VMs have been forced to shut down by +> "virsh destroy" many times during and after VM installation. +> When these vm reboot,dmesg show a ext3-fs mount error occurred on /usr/local +> partion /dev/vda3: +> EXT3-fs warning: mounting fs with errors, running e2fsck is recommendedand +> when I wrote into partion /dev/vda3,some errors occurred in dmesg: +> 1.error (device vda3): ext3_free_blocks: Freeing blocks not in datazone - block +> = 1869619311, count = 1error (device vda3): ext3_free_blocks_sb: bit already +> cleared for block 2178152error (device vda3): ext3_readdir: bad entry in +> directory #1083501: +> 2.[347470.661893] attempt to access beyond end of device[347470.661896] vda3: +> rw=0, want=6870892952, limit=41945715[347470.661897] EXT3-fs error (device +> vda3): ext3_free_branches: Read failure, inode=1083508, block=858861618 +> 3.EXT3-fs error (device vda3): ext3_new_block: block(4295028581) >= blocks +> count(-1) - block_group = 1, es == ffff88021b6c7400 +> +> I suspect this fs-error is caused by multiple forced shutdown, but I can't +> reproduce this bug now. +> +> Could anyone has an idea or suggestion to help me? + +What are the mount options for this ext3 file system? + +In particular, make sure the barrier=1 option is set. + +From linux/Documentation/filesystems/ext3.txt: + + Write barriers enforce proper on-disk ordering of journal commits, + making volatile disk write caches safe to use, at some performance + penalty. + +Stefan + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1279500 b/results/classifier/zero-shot/108/permissions/1279500 new file mode 100644 index 000000000..59413f982 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1279500 @@ -0,0 +1,148 @@ +permissions: 0.946 +other: 0.941 +KVM: 0.936 +boot: 0.931 +device: 0.931 +files: 0.918 +performance: 0.918 +debug: 0.916 +socket: 0.915 +vnc: 0.913 +graphic: 0.912 +network: 0.908 +semantic: 0.902 +PID: 0.898 + +system_powerdown causes SMP OpenBSD guest to freeze + +system_powerdown causes an SMP OpenBSD guest to freeze. I can reproduce it with the following systems/versions: + + - Debian 6: QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5) + - Fedora 20: + qemu-system-x86-1.6.1 (from Fedora repository) + qemu-1.7.0 (latest release version) + qemu-1.7.50 (latest development snapshot, "git cloned" today, 20140212) + +all of the above hosts are running x86_64 linux. + +The first OpenBSD version that I ran as a VM, v5.1, experienced the problem. All subsequent versions experience the problem. The above tests were performed using OpenBSD v5.4 (amd64). + +I will open an OpenBSD bug report for this problem as well, and update this report with the OpenBSD bug ID. + +There's an interesting RedHat bug report concerning this problem: + URL: https://bugzilla.redhat.com/show_bug.cgi?id=508801#c34 + +Here an excerpt: +-snip- +Gleb Natapov 2009-12-23 10:37:44 EST + +I posted patch to provide correct PCI irq routing info in mptable to kvm +mailing list. It works for all devices except for SCI interrupt. BIOS +programs SCI interrupt to be 9 as spec requires, but OpenBSD thinks that +it is smarter and moves it to interrupts 10. Qemu will still send it on +vector 9 and OpenBSD will enter the same infinity recursion. This can +be triggered by issuing system_powerdown on qemu monitor. +-snip- + +Michael Tokarev reported this problem on the kvm mailing list in 2011: + URL: http://www.spinics.net/lists/kvm/msg51311.html + +I compiled qemu as follows: +-snip- +cd qemu-src-dir +mkdir -p bin/native +cd bin/native +../../configure \ + --prefix=/usr/local/qemu-dev-snapshot-20140212 \ + --target-list=x86_64-softmmu \ + --enable-kvm \ + --enable-spice \ + --with-gtkabi="3.0" \ + --audio-drv-list=pa,sdl,alsa,oss \ + --extra-cflags='-I/usr/include/SDL' +-snip- + +I'm running OpenBSD with the following command: +-snip- +#!/bin/bash + +DEF=/usr/bin/qemu-system-x86_64 +QEMU_LATEST=/usr/local/qemu-1.7.0/bin/qemu-system-x86_64 +QEMU_DEV=/usr/local/qemu-dev-snapshot-20140212/bin/qemu-system-x86_64 + +$QEMU_DEV \ + -machine accel=kvm \ + -name obsdtest-v54 \ + -S \ + -machine pc-i440fx-1.6,accel=kvm,usb=off \ + -boot c \ + -m 2048 \ + -realtime mlock=off \ + -smp 2,sockets=2,cores=1,threads=1 \ + -uuid 8b685793-2510-473e-b97e-822a4cf2fbca \ + -no-user-config \ + -monitor stdio \ + -rtc base=utc,driftfix=slew \ + -global kvm-pit.lost_tick_policy=discard \ + -no-hpet \ + -drive file=/guest_images/obsdtest_v54.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none \ + -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ + -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw \ + -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ + -chardev pty,id=charserial0 \ + -device isa-serial,chardev=charserial0,id=serial0 \ + -k en-us \ + -device cirrus-vga,id=video0,bus=pci.0,addr=0x3 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ + -net nic \ + -net user +-snip- + +The OpenBSD disk image I used for testing is 143MB compressed, 10G uncompressed. It can be found here: + + http://www.spielwiese.de/OpenBSD/obsd54.raw.7z + +The root password is "x". + +Rob Urban + +I opened an OpenBSD bug. OpenBSD does not use a bug-tracking database, AFAICT, but rather the mailing-list <email address hidden>. I will post any replies to the OpenBSD bug report in comments here. + +hoping to increase the OpenBSD developers' inclination to investigate this bug, I reproduced it using OpenBSD 5.4 as the host. + +I used the stock qemu-1.5.1 that is available as an OpenBSD package. Booting the GENERIC.MP kernel in the VM was painfully slow, but it eventually came up to multi-user mode. + +The script to run the OpenBSD 5.4 guest on the OpenBSD 5.4 host: +-snip- +#!/bin/sh + +qemu-system-x86_64 \ + -S \ + -m 2048 \ + -smp 2,sockets=2,cores=1,threads=1 \ + -monitor stdio \ + -vnc :0 \ + -no-fd-bootchk \ + -net nic \ + -net user \ + -cdrom /space/install54.iso \ + -drive file=/space/obsd54test.raw,index=0,media=disk,cache=none,format=raw +-snip- + +As usual, issuing the "system_powerdown" command in the monitor caused the guest to freeze totally. + +Rob Urban + +If someone needs to coordinate with someone from the OpenBSD team, please talk to Mike Larkin <email address hidden>. He expressed an intention to look into this problem from the OpenBSD side. I would be delighted if I could supply Mike with a qemu contact person, of if someone could contact him directly (and copy me, please), as I think he wanted to investigate shortly. + +Also worth mentioning: the problem can be reproduced using the OpenBSD uniprocessor kernel in the guest, as long as mpbios(4) is enabled, which is the default. Thus, a VM configured with a single CPU is sufficient to reproduce. + +To boot the uniprocessor kernel from my guest image, at the OpenBSD boot prompt, type "boot /bsd". To make it permanent, edit /etc/boot.conf and change "bsd.mp" to "bsd", or remove boot.conf entirely. + +Rob Urban + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU and OpenBSD? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1283 b/results/classifier/zero-shot/108/permissions/1283 new file mode 100644 index 000000000..b63be1fa4 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1283 @@ -0,0 +1,97 @@ +permissions: 0.950 +semantic: 0.934 +performance: 0.931 +other: 0.926 +graphic: 0.923 +debug: 0.922 +files: 0.918 +PID: 0.901 +device: 0.899 +socket: 0.895 +KVM: 0.882 +vnc: 0.862 +boot: 0.860 +network: 0.853 + +Live migration cause scsi_req_unref: Assertion `req->refcount > 0' failed +Description of problem: +During live migration, copy file from one folder to another. Migration can succeed. After a while, copy can't finish and in target host qemu crash: +``` +qemu-system-x86_64: ../hw/scsi/scsi-bus.c:1366: scsi_req_unref: Assertion `req->refcount > 0' failed. +2022-10-28 03:22:54.948+0000: shutting down, reason=crashed +``` +libvirt configure related: +``` + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/images/gen-l-vrt-295-008/swx-jd01-001-new.img'/> + <target dev='sda' bus='scsi'/> + <alias name='ua-box-volume-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='scsi' index='0' model='lsilogic'> + <address type='pci' domain='0x0000' bus='0x03' slot='0x01' function='0x0'/> + </controller> +``` +If change `bus='scsi'` to `bus='sata'`, same test steps can pass. +Steps to reproduce: +1. Inside VM +``` +fallocate -l 10G /tmp/test.img +cp /tmp/test.img / +``` +2. Same time, migrate VM to another server +``` +virsh migrate --verbose --live --persistent swx-jd01-001 qemu+ssh://gen-l-vrt-294/system --unsafe --auto-converge --auto-converge-initial 60 --auto-converge-increment 20 + +``` +3. After a while, cp can't finish and qemu crash on destination server with assert fail. +Additional information: +stack traces: +``` +#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140544841483840) at ./nptl/pthread_kill.c:44 +#1 __pthread_kill_internal (signo=6, threadid=140544841483840) at ./nptl/pthread_kill.c:78 +#2 __GI___pthread_kill (threadid=140544841483840, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 +#3 0x00007fd3284f9476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#4 0x00007fd3284df7f3 in __GI_abort () at ./stdlib/abort.c:79 +#5 0x00007fd3284df71b in __assert_fail_base + (fmt=0x7fd328694150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55791c97acbb "req->refcount > 0", file=0x55791c97ac7f "../hw/scsi/scsi-bus.c", line=1366, function=<optimized out>) + at ./assert/assert.c:92 +#6 0x00007fd3284f0e96 in __GI___assert_fail + (assertion=assertion@entry=0x55791c97acbb "req->refcount > 0", file=file@entry=0x55791c97ac7f "../hw/scsi/scsi-bus.c", line=line@entry=1366, function=function@entry=0x55791c97b2a0 <__PRETTY_FUNCTION__.14> "scsi_req_unref") at ./assert/assert.c:101 +#7 0x000055791c499a2e in scsi_req_unref (req=<optimized out>) at ../hw/scsi/scsi-bus.c:1366 +#8 0x000055791c49b61f in scsi_device_purge_requests (sdev=sdev@entry=0x55791e6e0c00, sense=...) at ../hw/scsi/scsi-bus.c:1639 +#9 0x000055791c49d704 in scsi_disk_reset (dev=0x55791e6e0c00) at ../hw/scsi/scsi-disk.c:2336 +#10 0x000055791c72a6ed in qdev_reset_one (dev=<optimized out>, opaque=<optimized out>) at ../hw/core/qdev.c:254 +#11 0x000055791c726fa9 in qbus_walk_children + (bus=<optimized out>, pre_devfn=0x55791c728770 <qdev_prereset>, pre_busfn=0x55791c7286a0 <qbus_prereset>, post_devfn=0x55791c72a6e0 <qdev_reset_one>, post_busfn=0x55791c728ae0 <qbus_reset_one>, opaque=0x0) at ../hw/core/bus.c:54 +#12 0x000055791c72a790 in qdev_walk_children + (opaque=0x0, post_busfn=0x55791c728ae0 <qbus_reset_one>, post_devfn=0x55791c72a6e0 <qdev_reset_one>, pre_busfn=0x55791c7286a0 <qbus_prereset>, pre_devfn=0x55791c728770 <qdev_prereset>, dev=0x55791ed2a430) at ../hw/core/qdev.c:413 +#13 qdev_reset_all (dev=0x55791ed2a430) at ../hw/core/qdev.c:272 +#14 0x000055791c688134 in memory_region_write_accessor (mr=mr@entry=0x55791ed2ae60, addr=20, value=value@entry=0x7fd32559f618, size=size@entry=1, shift=<optimized out>, mask=mask@entry=255, attrs=...) + at ../softmmu/memory.c:492 +#15 0x000055791c6858c6 in access_with_adjusted_size + (addr=addr@entry=20, value=value@entry=0x7fd32559f618, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55791c6880b0 <memory_region_write_accessor>, mr=0x55791ed2ae60, attrs=...) at ../softmmu/memory.c:554 +#16 0x000055791c689bf2 in memory_region_dispatch_write (mr=mr@entry=0x55791ed2ae60, addr=20, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../softmmu/memory.c:1521 +#17 0x000055791c690cf0 in flatview_write_continue (fv=fv@entry=0x55791e729ac0, addr=addr@entry=4257226772, attrs=..., + attrs@entry=..., ptr=ptr@entry=0x7fd328d36028, len=len@entry=1, addr1=<optimized out>, l=<optimized out>, mr=0x55791ed2ae60) at /opt/qemu/include/qemu/host-utils.h:166 +#18 0x000055791c690fb0 in flatview_write (fv=0x55791e729ac0, addr=addr@entry=4257226772, attrs=attrs@entry=..., buf=buf@entry=0x7fd328d36028, len=len@entry=1) at ../softmmu/physmem.c:2867 +#19 0x000055791c694799 in address_space_write (len=1, buf=0x7fd328d36028, attrs=..., addr=4257226772, as=0x55791d08a740 <address_space_memory>) at ../softmmu/physmem.c:2963 +#20 address_space_rw (as=0x55791d08a740 <address_space_memory>, addr=4257226772, attrs=attrs@entry=..., buf=buf@entry=0x7fd328d36028, len=1, is_write=<optimized out>) at ../softmmu/physmem.c:2973 +#21 0x000055791c71d19e in kvm_cpu_exec (cpu=cpu@entry=0x55791dc9d890) at ../accel/kvm/kvm-all.c:2954 +#22 0x000055791c71e6c5 in kvm_vcpu_thread_fn (arg=arg@entry=0x55791dc9d890) at ../accel/kvm/kvm-accel-ops.c:49 +#23 0x000055791c885be1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:504 +#24 0x00007fd32854bb43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#25 0x00007fd3285dcbb4 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100 +``` +Guest disk partition +``` +root@swx-jd01-001:~# lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 64G 0 disk +├─sda1 8:1 0 512M 0 part /boot/efi +├─sda2 8:2 0 1K 0 part +└─sda5 8:5 0 63.5G 0 part + ├─vgwin--dbausdhrjgi-root 253:0 0 62.6G 0 lvm / + └─vgwin--dbausdhrjgi-swap_1 253:1 0 980M 0 lvm [SWAP] +``` diff --git a/results/classifier/zero-shot/108/permissions/1323758 b/results/classifier/zero-shot/108/permissions/1323758 new file mode 100644 index 000000000..2a4ac15d1 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1323758 @@ -0,0 +1,388 @@ +permissions: 0.961 +graphic: 0.955 +other: 0.954 +semantic: 0.952 +performance: 0.952 +boot: 0.947 +socket: 0.944 +device: 0.944 +debug: 0.939 +PID: 0.938 +network: 0.930 +vnc: 0.920 +KVM: 0.893 +files: 0.890 + +Mouse stops working when connected usb-storage-device + +I'm running a guest that has Windows 8 Pro (x64) installed. Every time I pass through a usb storage device from the host to the guest, the mouse stops working in the vnc client. When I remove the usb-device the mouse works again. + +The mouse only stops working when I pass through a usb storage device and then make the vlc viewer (client) inactief by clicking on another program on the local computer (where I'm running the vnc viewer (client)). As long as I keep the vnc viewer active, the mouse works without any problems. But as soon as I make the vnc viewer inactief and then active again, the mouse will no longer work. I have to reboot the guest or remove the usb storage device. + +I can't find any related problems on the internet, so it may be just me? + +I hope someone can help me with this. + +Thanks for reporting this bug. + +Could you tell us which Ubuntu release you are running? Was 'vlc viewer' a typo, or is that another program you have running beside the vnc viewer? + +If you are starting this VM using libvirt, please attach the xml definition for the VM (virsh dumpxml vm-name). If using the command line, please show us the full exact command you are using. + +Also please show the result of 'sudo lsusb' after plugging in the usb storage but before passing it through to the guest, then again after passing it through. + +Finally please show exactly how you are passing through the usb device. + +If these don't show anything obvious then I'll try to reproduce. + +(marking low priority because there is a workaround - unplugging the usb device) + +Actually I had three more questions - + +1. If you exit the vnc viewer and restart it, does the mouse work again? + +2. What window manager are you using? + +3. Which vnc client are you using? (What command do you use, and what does 'dpkg -l | grep vnc' show?) + +Thanks for the reply! + +First of all, vlc was a type. Should have been vnc. If I restart the vnc viewer (client) the mouse still does not work. Even connecting from another computer does not seem to fix the problem. + +I'm using Virtual Machine Manager (virt-manager) to assign the usb-device to the guest. I do this by clicing on 'Add device', select USB Host device, then select the usb external hard drive and click 'Apply'. After this action, the hard drive is visible and working on the guest. + +I'm using Ubuntu 14.04 LTS with libvirt 1.2.2. Here is my xml-file before and after adding the usb device: + + + +A little more information I discovered: + +I told before that the mouse only stops working when making the vnc viewer (client) inactive. This is not true after some more testing. It just happens when adding the usb external storage device to the guest and wait for like 10 seconds. Then the mouse stops working (clicking, moving...). The keyboard still works without any problems. I'm sorry for the wrong information above. + +I' very sorry, but I forgot to add the xml files before clicking 'Post Comment' and it seems that I cannot edit my posts (only the poststart). + +Here they are: + +[BEFORE ADDING DEVICE] + +<domain type='kvm'> + <name>vm01</name> + <uuid>4ffa27ba-cb99-6375-23ab-92913e18cf75</uuid> + <description>THUIS-SERVER</description> + <memory unit='KiB'>3145728</memory> + <currentMemory unit='KiB'>3145728</currentMemory> + <vcpu placement='static'>4</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu> + <topology sockets='1' cores='4' threads='1'/> + </cpu> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm-spice</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='raw'/> + <source file='/var/lib/libvirt/images/vm01.img'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='hda' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:8f:1b:a4'/> + <source bridge='br0'/> + <model type='rtl8139'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='5901' autoport='no' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='9216' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='apparmor' relabel='yes'/> +</domain> + + +[AFTER ADDING DEVICE] + +<domain type='kvm'> + <name>vm01</name> + <uuid>4ffa27ba-cb99-6375-23ab-92913e18cf75</uuid> + <description>THUIS-SERVER</description> + <memory unit='KiB'>3145728</memory> + <currentMemory unit='KiB'>3145728</currentMemory> + <vcpu placement='static'>4</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu> + <topology sockets='1' cores='4' threads='1'/> + </cpu> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm-spice</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='raw'/> + <source file='/var/lib/libvirt/images/vm01.img'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='hda' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:8f:1b:a4'/> + <source bridge='br0'/> + <model type='rtl8139'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='5901' autoport='no' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='9216' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <hostdev mode='subsystem' type='usb' managed='yes'> + <source> + <vendor id='0x03f0'/> + <product id='0x070c'/> + </source> + </hostdev> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='apparmor' relabel='yes'/> +</domain> + + +[LSUSB BEFORE] +Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + +[LSUSB AFTER] + +Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 001 Device 004: ID 03f0:070c Hewlett-Packard +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + +I hope you have enough information with this. Thanks again for the reply! + +Some more information that I think is relevant: + +The motherboard that the server uses is an IPIBL-LA (http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01247779&tmp_task=prodinfoCategory&cc=be&dlc=nl&lc=nl&product=3627668#N84) and according to the specifications it has all USB 2.0 ports. However in Ubuntu when using 'lsusb' I only see 2 EHCI (USB 2.0) controllers/ports. All the rest are 1.1. + +Is this normal or is this a bug? I couldn't find any more information on the internet for this bug/problem. It seems that Ubuntu does not recognize all of the USB 2.0 ports and sees them as 1.1 insteid? I'm also receiving this error on host boot (when booting the server): kvm [1698]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0xffff. After some research I found that some say this is not an error. But it is related to Qemu. Could this also be something to do with my mouse problem? + +Again, many thanks for reading! + +the + +kvm [1698]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0xffff + +should be innocuous and unrelated. The host motherboard info may +be relevant, but shouldn't be. Libvirt should be able to pass in +just the right device. + +The xml descriptions look correct. The lspci outputs seem backward, +as device + +Bus 001 Device 004: ID 03f0:070c Hewlett-Packard + +shows up in the after, but not before, outputs. + +I'll try to reproduce after I manage to set up a remote windows +vm, using a usb flash drive. + +Can you confirm whether the hard drive appears to become available +in the windows vm? + + +Thanks for the response! + +Yes, the hard drive does become available in the Windows vm. I can use it as I would normally do in a non-virtual environment. I have not yet tried any other Windows version. I'm running Windows 8.1 x64. + +Any news on this yet? I do not want to hurry you but it has been a bit quiet. + +I am now installing Windows 7 SP1 x64 to see if it suffers from the same bug/problem. I'll report back when I have more information! + +I can confirm that this bug/problem does not seem to exist in Windows 7 SP1 x64! I could use this version of Windows w/ my external hard drives, but it's strange that this exact same set-up does not work on Windows 8 (causing the vnc mouse to freeze). This could and should be a Windows 8 driver problem with the Qemu mouse-driver. I hope this can be reproduced and fixed a.s.a.p.! + +If you need any more information or help, just ask me and I'll be free to help you reproduce this bug. + +I finally found a fix for this bug/problem! It is in fact a bug, but I don't know wether it is a Windows bug or a Qemu/VNC-bug. After connecting a massive storage device to the Windows 8.1 guest, the mouse stops working because it goes into a sleep-state. + +This bug can be fixed by going to WIN + X, Control Panel, Devices and Printers. There you can see the QEMU USB Tablet which is a tablet/mouse device used for the VNC-mouse to work on the guest. Right click it and select Properties. Next click on the tab Hardware. Normally you should see two devices (based on what hardware you assigned to the guest), HID-compliant mouse and USB Input Device. + +Now select the USB Input Device and click Properties at the bottom. This will open a new window with the device's properties. Next click on Change settings (you'll need Admin.-powers for this) and go to the Power Management tab on the newly opened window. There you should see an option ticked with the following explanation: Allow the computer to turn off this device to save power. + +Unchecking that option and pressing OK solves the problem. This whole route can be done with keyboard-only (as the keyboard still works). Press ENTER to open things, use TAB to move to different menus and press SPACE to simulate a single mouse-click (for unchecking the checkbox). + +I hope this helps a lot of people who are suffering from the same issue. I still can't find any related topics of people having the same issues as I did, but it is a bug and should be fixed. I have no idea if it is Windows or Qemu related and I hope that the Qemu-team can further inspect this. + +Thanks for all the help! + +Hi, + +Are you running 12.04, or 14.04? If 12.04, would it be possible to test 14.04 to see if it has the same issue? If 14.04, could you try with the following ppa: https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream to see if the very latest upstream qemu still has the same behavior? + +I'm using 14.04. I could give it a try. Is it easy to revert to the older version of Qemu once upgraded to the upstream one? + +Using the latest upstream version the bug still exists. I have to disable the option that Windows can put the USB Input Device to sleep in order to make the mouse move again. + +Any news on this? + +Sorry, no. So to summarize for anyone on the qemu-devel mailing list who might have ideas, Rubin found that disabling power management for the mouse device in windows fixes the issue. With power management enabled, plugging in a usb storage device and passing it through to the guest stops the mouse from working in the windows guest. + +Ok, thanks for the info! By Rubin, do you mean Ruben (a.k.a. me)? :D + +> Ok, thanks for the info! By Rubin, do you mean Ruben (a.k.a. me)? :D + +D'oh - yes, apologies. + + +Magic! I'd been trying to figure out how to prevent my mouse from stopping at apparently random points... Works like magic! + +Glad to hear you solved they issue by reading this bug report, Maarten! As you can see the bug has been updated with the confirmed-status on October 21st of 2015 and I hope they can fix this a.s.a.p. I don't have a Windows-guest anymore, but even for all the other Qemu-users out there that do, I'd like this bug fixed. + +@Stefan or Chris, or any other developer: is there any news/updates about this issue? + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +It's been a very very long time since I've last ran a Windows virtual machine on Ubuntu, so I can't really tell. I do remember I never got it "fixed", but did find a fix for it by disabling the Windows power plan option "Allow Windows to put this device to sleep". Over the years I did get some thankful comments on the StackOverflow threat where I posted this exact issue with the workaround (fix), which can be viewed here: https://unix.stackexchange.com/questions/131942/qemu-2-0-windows-guest-mouse-stops-working-vnc-when-using-usb-passthrough + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + +I have had this issue happen multiple times on multiple versions of kvm with both ubuntu and cantos. I just the other day tried installing win8.1 again for testing and ran across ruban's post. this happens in win10 as well and I think I had seen it in win7. + +I reinstalled another win8 vm from a usb instead of an iso later that day and realized that the mouse was working normally which surprised me. I then manually installed the virtio nic driver. the system still worked normally. I then installed the baloon driver and that make the mouse stop working untill i pulled the flash drive. after changing the power settings the mouse would again start working with the flash drive. + +I have always used virt manager for connecting to the servers and spice for the display + +@Kendrick could you please tell us which version of Ubuntu and qemu you are using? + + +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/102 + + +I have used rel 7.x 8.x ubuntu 18.04 and see this happening in all of them the original user had it only in ubuntu. + diff --git a/results/classifier/zero-shot/108/permissions/1326 b/results/classifier/zero-shot/108/permissions/1326 new file mode 100644 index 000000000..fd0e463cc --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1326 @@ -0,0 +1,73 @@ +permissions: 0.963 +debug: 0.930 +semantic: 0.926 +other: 0.924 +PID: 0.924 +graphic: 0.915 +KVM: 0.914 +performance: 0.911 +vnc: 0.889 +socket: 0.876 +device: 0.876 +files: 0.867 +boot: 0.840 +network: 0.801 + +qemu-system-aarch64: piix3 or ehci usb controller and usb kbd don't work +Description of problem: +the usb device initialization failed in vm, and can not input in vnc console + +message for virtual machine: + +``` +root@localhost ~]# dmesg | grep -i usb +[ 0.925798] ACPI: bus type USB registered +[ 0.927204] usbcore: registered new interface driver usbfs +[ 0.928980] usbcore: registered new interface driver hub +[ 0.930746] usbcore: registered new device driver usb +[ 2.329004] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 2.332659] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 2.336069] uhci_hcd: USB Universal Host Controller Interface driver +[ 2.342659] uhci_hcd 0000:02:02.0: new USB bus registered, assigned bus number 1 +[ 2.348905] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.18 +[ 2.352268] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 2.354598] usb usb1: Product: UHCI Host Controller +[ 2.356194] usb usb1: Manufacturer: Linux 4.18.0-305.3.1.el8.aarch64 uhci_hcd +[ 2.358474] usb usb1: SerialNumber: 0000:02:02.0 +[ 2.360228] hub 1-0:1.0: USB hub found +[ 2.363347] usbcore: registered new interface driver usbserial_generic +[ 2.365456] usbserial: USB Serial support registered for generic +[ 2.384154] usbcore: registered new interface driver usbhid +[ 2.385962] usbhid: USB HID core driver +[ 2.730277] usb 1-1: new full-speed USB device number 2 using uhci_hcd +[ 18.509908] usb 1-1: device descriptor read/64, error -110 +[ 34.509908] usb 1-1: device descriptor read/64, error -110 +[ 34.779906] usb 1-1: new full-speed USB device number 3 using uhci_hcd +[ 50.509910] usb 1-1: device descriptor read/64, error -110 +[ 66.509907] usb 1-1: device descriptor read/64, error -110 +[ 66.629982] usb usb1-port1: attempt power cycle +[ 67.119904] usb 1-1: new full-speed USB device number 4 using uhci_hcd +[ 78.079921] usb 1-1: device not accepting address 4, error -110 +[ 78.229962] usb 1-1: new full-speed USB device number 5 using uhci_hcd +[ 89.079917] usb 1-1: device not accepting address 5, error -110 +[ 89.082006] usb usb1-port1: unable to enumerate USB device +[ 89.229908] usb 1-2: new full-speed USB device number 6 using uhci_hcd +[ 105.009910] usb 1-2: device descriptor read/64, error -110 +[ 121.009910] usb 1-2: device descriptor read/64, error -110 +[ 121.279907] usb 1-2: new full-speed USB device number 7 using uhci_hcd +[ 137.009910] usb 1-2: device descriptor read/64, error -110 +[ 153.009925] usb 1-2: device descriptor read/64, error -110 +[ 153.129984] usb usb1-port2: attempt power cycle +[ 153.619917] usb 1-2: new full-speed USB device number 8 using uhci_hcd +[ 164.579912] usb 1-2: device not accepting address 8, error -110 +[ 164.729913] usb 1-2: new full-speed USB device number 9 using uhci_hcd +[ 175.329921] usb 1-2: device not accepting address 9, error -110 +[ 175.331973] usb usb1-port2: unable to enumerate USB device +``` +Steps to reproduce: +1. ./configure +2. make -j60 +3.virsh create vm.xml +[vm.xml](/uploads/9f946b3637f68c9cd029dfb650f5bd57/vm.xml) +Additional information: +the commit "1c2cb7e0b3" cause the problem, but i don't know the reason diff --git a/results/classifier/zero-shot/108/permissions/1329956 b/results/classifier/zero-shot/108/permissions/1329956 new file mode 100644 index 000000000..c78b09d73 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1329956 @@ -0,0 +1,240 @@ +permissions: 0.962 +graphic: 0.958 +semantic: 0.944 +performance: 0.938 +debug: 0.935 +device: 0.932 +other: 0.923 +PID: 0.920 +boot: 0.914 +KVM: 0.902 +network: 0.900 +vnc: 0.898 +files: 0.874 +socket: 0.846 + +multi-core FreeBSD guest hangs after warm reboot + +On some Linux KVM hosts in our environment, FreeBSD guests fail to reboot properly if they have more than one CPU (socket, core, and/or thread). They will boot fine the first time, but after issuing a "reboot" command via the OS the guest starts to boot but hangs during SMP initialization. Fully shutting down and restarting the guest works in all cases. + +The only meaningful difference between hosts with the problem and those without is the CPU. Hosts with Xeon E5-26xx v2 processors have the problem, including at least the "Intel(R) Xeon(R) CPU E5-2667 v2" and the "Intel(R) Xeon(R) CPU E5-2650 v2". +Hosts with any other CPU, including "Intel(R) Xeon(R) CPU E5-2650 0", "Intel(R) Xeon(R) CPU E5-2620 0", or "AMD Opteron(TM) Processor 6274" do not have the problem. Note the "v2" in the names of the problematic CPUs. + +On hosts with a "v2" Xeon, I can reproduce the problem under Linux kernel 3.10 or 3.12 and Qemu 1.7.0 or 2.0.0. + +The problem occurs with all currently-supported versions of FreeBSD, including 8.4, 9.2, 10.0 and 11-CURRENT. + +On a Linux KVM host with a "v2" Xeon, this command line is adequate to reproduce the problem: + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name bsdtest -m 512 -smp 2,sockets=1,cores=1,threads=2 -drive file=./20140613_FreeBSD_9.2-RELEASE_ufs.qcow2,if=none,id=drive0,format=qcow2 -device virtio-blk-pci,scsi=off,drive=drive0 -vnc 0.0.0.0:0 -net none + +I have tried many variations including different models of -machine and -cpu for the guest with no visible difference. + +A native FreeBSD installation on a host with a "v2" Xeon does not have the problem, nor do a paravirtualized FreeBSD guests under bhyve (the BSD legacy-free hypervisor) using the same FreeBSD disk images as on the Linux hosts. So it seems unlikely the cause is on the FreeBSD side of things. + +I would greatly appreciate any feedback or developer attention to this. I am happy to provide additional details, test patches, etc. + +I'm having this same issue. Tried with both FreeNAS (which uses FreeBSD 9), and a minimal install of FreeBSD 10. Everything seems to work great up until you try to do a warm boot. I've compiled a custom FreeBSD kernel with everything unnecessary removed, and also changed the number of CPUs assigned to the guest. Nothing seems to work above a single CPU. + +I'm on a fully patched Ubuntu 14.04 system. Here is the top of my /proc/cpuinfo from the Ubuntu hypervisor. + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 62 +model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz +stepping : 4 +microcode : 0x416 +cpu MHz : 2500.010 +cache size : 25600 KB +physical id : 0 +siblings : 20 +core id : 0 +cpu cores : 10 + +Hi, + +could you verify that you have the same result when using +https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream + + status: incomplete + importance: medium + + +Our KVM hosts run CentOS 6 plus a custom 3.12 kernel rather than Ubuntu or Debian, so I won't be able to use the PPA directly. However, I will build and test with the latest Qemu git sources. + +On Jun 16, 2014, at 12:17 PM, Serge Hallyn <email address hidden> wrote: + +> Hi, +> +> could you verify that you have the same result when using +> https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream + + + +I have the same result when running Qemu built today from: + +commit af44da87e926ff64260b95f4350d338c4fc113ca +Merge: f277015 9dbae97 +Author: Peter Maydell <email address hidden> +Date: Mon Jun 16 18:26:21 2014 +0100 + +I also tried a 3.15 kernel to see if any recent KVM changes would help, but the problem remains. + + +Problem also remains with CPU microcode revision 0x427 (2014-04-10). + +I have the same issue : +KMV veriosn: 3.10.0-123.el7.x86_64 SMP mod_unload modversions +author: Qumranet + + + +For the benefit of the last commenter and anyone else who comes across this ticket: + +As determined on the mailing list in June, the bug appears to be with KVM's apicv on processors that support the feature. I haven't heard anything about a fix, but the best workaround is to disable apicv when loading the KVM kernel module, e.g.: + +# modprobe kvm_intel enable_apicv=N + +You can verify the parameter by checking the contents of /sys/module/kvm_intel/parameters/enable_apicv. + + +Thanks John !! Let me try that + +In my testing disable apicv does not needed, but i need latest stable seabios from seabios site. + +Vasiliy, + +if a different SeaBIOS is needed, that's another bug. You can use hint.atkbd.0.disabled="1" to work around it. + +But if disable apicv is not needed, can you please include your cpuinfo here? + +I am no longer able to reproduce this issue on a fully-updated server. My guess is that the issue was fixed in the kernel somewhere between 3.12 and 4.0, but for all I know it could be a Qemu (or even Seabios) change. Here are details of my test that failed and the one that succeeded. + +Breaks (VM hangs during boot after pressing ctrl-alt-del): +kernel 3.12.22 +qemu-kvm-1.7.0-3.el6.x86_64 +seabios-1.7.3.1-1.el6.noarch +Intel(R) Xeon(R) CPU E5-2667 v2 @ 3.30GHz + +Works (VM reboots normally): +kernel 4.0.4 +qemu-kvm-2.3.0-6.el7.centos.x86_64 +seabios-bin-1.8.1-1.el7.centos.noarch +Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz + +I'd still like to narrow down the change that fixed it if possible. + +Can you please tell me whether the issue is fixed with the latest kernel? If so, what version has the fix? + + +Yes it is. Not sure what version first fixed it but I know 4.1 works. + +> On Aug 20, 2015, at 2:30 AM, Venkateswara Rao Dokku <email address hidden> wrote: +> +> Can you please tell me whether the issue is fixed with the latest +> kernel? If so, what version has the fix? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1329956 +> +> Title: +> multi-core FreeBSD guest hangs after warm reboot +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> On some Linux KVM hosts in our environment, FreeBSD guests fail to +> reboot properly if they have more than one CPU (socket, core, and/or +> thread). They will boot fine the first time, but after issuing a +> "reboot" command via the OS the guest starts to boot but hangs during +> SMP initialization. Fully shutting down and restarting the guest works +> in all cases. +> +> The only meaningful difference between hosts with the problem and those without is the CPU. Hosts with Xeon E5-26xx v2 processors have the problem, including at least the "Intel(R) Xeon(R) CPU E5-2667 v2" and the "Intel(R) Xeon(R) CPU E5-2650 v2". +> Hosts with any other CPU, including "Intel(R) Xeon(R) CPU E5-2650 0", "Intel(R) Xeon(R) CPU E5-2620 0", or "AMD Opteron(TM) Processor 6274" do not have the problem. Note the "v2" in the names of the problematic CPUs. +> +> On hosts with a "v2" Xeon, I can reproduce the problem under Linux +> kernel 3.10 or 3.12 and Qemu 1.7.0 or 2.0.0. +> +> The problem occurs with all currently-supported versions of FreeBSD, +> including 8.4, 9.2, 10.0 and 11-CURRENT. +> +> On a Linux KVM host with a "v2" Xeon, this command line is adequate to +> reproduce the problem: +> +> /usr/bin/qemu-system-x86_64 -machine accel=kvm -name bsdtest -m 512 +> -smp 2,sockets=1,cores=1,threads=2 -drive +> file=./20140613_FreeBSD_9.2-RELEASE_ufs.qcow2,if=none,id=drive0,format=qcow2 +> -device virtio-blk-pci,scsi=off,drive=drive0 -vnc 0.0.0.0:0 -net none +> +> I have tried many variations including different models of -machine +> and -cpu for the guest with no visible difference. +> +> A native FreeBSD installation on a host with a "v2" Xeon does not have +> the problem, nor do a paravirtualized FreeBSD guests under bhyve (the +> BSD legacy-free hypervisor) using the same FreeBSD disk images as on +> the Linux hosts. So it seems unlikely the cause is on the FreeBSD side +> of things. +> +> I would greatly appreciate any feedback or developer attention to +> this. I am happy to provide additional details, test patches, etc. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1329956/+subscriptions +> + + +Can you please let us know the exact version of the kernel it got fixed? + +OK, according to the last comments, the bug has been fixed somewhere with the last kernel or QEMU releases, so I'm closing this ticket now. + +I'm able to reproduce this issue, but using latest debian 9. + +Debian 9 +qemu version: 1:2.8+dfsg-6+deb9u3 +kernel version: Linux vm2 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux + +I'm attempting to cold boot, or warm reboot, pfsense 2.4.2 amd64 iso image guest. If I have > 1 in virt-manager view -> details -> cpu -> allocation and maximum allocation, then the guest will not boot. My workaround was to set those both to 1, then in configuration I needed to uncheck "Copy Host CPU Configuration" (pfsense used to need this for hardware crypto support) and set the model to "clear cpu configuration" in order for it to boot. This doesn't appear to be Intel specific. I'm running amd .. + +/proc/cpuinfo : + +processor : 0 +vendor_id : AuthenticAMD +cpu family : 21 +model : 1 +model name : AMD FX(tm)-8120 Eight-Core Processor +stepping : 2 +microcode : 0x6000629 +cpu MHz : 1400.000 +cache size : 2048 KB +physical id : 0 +siblings : 8 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold +bugs : fxsave_leak sysret_ss_attrs null_seg +bogomips : 6241.40 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb + + + +I found this bug report through https://redmine.pfsense.org/issues/7925 , btw. + +sorry, make that https://redmine.pfsense.org/issues/4377 + +Matt, does disabling apicv on the hypervisor as above work around the issue for you? + diff --git a/results/classifier/zero-shot/108/permissions/1332297 b/results/classifier/zero-shot/108/permissions/1332297 new file mode 100644 index 000000000..f098f5137 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1332297 @@ -0,0 +1,180 @@ +permissions: 0.966 +graphic: 0.951 +debug: 0.936 +PID: 0.933 +device: 0.932 +boot: 0.929 +semantic: 0.927 +performance: 0.918 +files: 0.907 +KVM: 0.897 +socket: 0.896 +other: 0.883 +vnc: 0.873 +network: 0.848 + +qemu-img: crash on check of an image with large value in the 'size' header field + +The qemu-img crashes on the next command: + +qemu-img check test_image + +'test_image' can be found in the attachment. It's a fuzzed test image with the qcow2 image header only. Suppositional cause of the failure is the value of 'size' header field set to maximum uint_64 value. + +System information: + +qemu.git: 6baa963f4dcc2118 +Host: Linux 3.14.7-200.fc20.x86_64 #1 SMP Wed Jun 11 22:38:05 UTC 2014 x86_64 GNU/Linux + + + +The bug description missed qemu-img error: + +(process:12283): GLib-ERROR **: gmem.c:110: failed to allocate 18446744059294601304 bytes + + +On Thu, Jun 19, 2014 at 07:19:55PM -0000, Maria Kustova wrote: +> The bug description missed qemu-img error: +> +> (process:12283): GLib-ERROR **: gmem.c:110: failed to allocate +> 18446744059294601304 bytes + +Thanks, there has been recent work by Kevin Wolf to handle memory +allocation failures gracefully without terminating QEMU. This sounds +like a candidate for g_try_malloc() and friends. + +Does the following patch series solve the problem? +https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01275.html + +Stefan + + +Am 24.06.2014 um 15:19 hat M.Kustova geschrieben: +> On Mon, Jun 23, 2014 at 12:02 PM, Stefan Hajnoczi <email address hidden> wrote: +> > On Thu, Jun 19, 2014 at 07:19:55PM -0000, Maria Kustova wrote: +> >> The bug description missed qemu-img error: +> >> +> >> (process:12283): GLib-ERROR **: gmem.c:110: failed to allocate +> >> 18446744059294601304 bytes +> > +> > Thanks, there has been recent work by Kevin Wolf to handle memory +> > allocation failures gracefully without terminating QEMU. This sounds +> > like a candidate for g_try_malloc() and friends. +> > +> > Does the following patch series solve the problem? +> > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01275.html +> +> These patches are conflicting with current master. So I can't test +> them as they are. +> +> Do you have a developer repository or branch containing these patches, +> so I could test it on the pre-release base? + +I'm just about to send a new version, I'll keep you CCed there. + +Kevin + + +Am 25.06.2014 um 11:32 hat M.Kustova geschrieben: +> On Tue, Jun 24, 2014 at 7:36 PM, Kevin Wolf <email address hidden> wrote: +> > Am 24.06.2014 um 15:19 hat M.Kustova geschrieben: +> >> On Mon, Jun 23, 2014 at 12:02 PM, Stefan Hajnoczi <email address hidden> wrote: +> >> > On Thu, Jun 19, 2014 at 07:19:55PM -0000, Maria Kustova wrote: +> >> >> The bug description missed qemu-img error: +> >> >> +> >> >> (process:12283): GLib-ERROR **: gmem.c:110: failed to allocate +> >> >> 18446744059294601304 bytes +> >> > +> >> > Thanks, there has been recent work by Kevin Wolf to handle memory +> >> > allocation failures gracefully without terminating QEMU. This sounds +> >> > like a candidate for g_try_malloc() and friends. +> >> > +> >> > Does the following patch series solve the problem? +> >> > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01275.html +> >> +> >> These patches are conflicting with current master. So I can't test +> >> them as they are. +> >> +> >> Do you have a developer repository or branch containing these patches, +> >> so I could test it on the pre-release base? +> > +> > I'm just about to send a new version, I'll keep you CCed there. +> +> "[PATCH v4 21/21] qcow2: Return useful error code in refcount_init()" +> is still broken for the current master. + +In which way? I can cleanly apply the whole patch series on master (even +tried applying the emails from my inbox to be sure). + +Kevin + + +Am 25.06.2014 um 11:54 hat M.Kustova geschrieben: +> On Wed, Jun 25, 2014 at 1:42 PM, Kevin Wolf <email address hidden> wrote: +> > Am 25.06.2014 um 11:32 hat M.Kustova geschrieben: +> >> On Tue, Jun 24, 2014 at 7:36 PM, Kevin Wolf <email address hidden> wrote: +> >> > Am 24.06.2014 um 15:19 hat M.Kustova geschrieben: +> >> >> On Mon, Jun 23, 2014 at 12:02 PM, Stefan Hajnoczi <email address hidden> wrote: +> >> >> > On Thu, Jun 19, 2014 at 07:19:55PM -0000, Maria Kustova wrote: +> >> >> >> The bug description missed qemu-img error: +> >> >> >> +> >> >> >> (process:12283): GLib-ERROR **: gmem.c:110: failed to allocate +> >> >> >> 18446744059294601304 bytes +> >> >> > +> >> >> > Thanks, there has been recent work by Kevin Wolf to handle memory +> >> >> > allocation failures gracefully without terminating QEMU. This sounds +> >> >> > like a candidate for g_try_malloc() and friends. +> >> >> > +> >> >> > Does the following patch series solve the problem? +> >> >> > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01275.html +> >> >> +> >> >> These patches are conflicting with current master. So I can't test +> >> >> them as they are. +> >> >> +> >> >> Do you have a developer repository or branch containing these patches, +> >> >> so I could test it on the pre-release base? +> >> > +> >> > I'm just about to send a new version, I'll keep you CCed there. +> >> +> >> "[PATCH v4 21/21] qcow2: Return useful error code in refcount_init()" +> >> is still broken for the current master. +> > +> > In which way? I can cleanly apply the whole patch series on master (even +> > tried applying the emails from my inbox to be sure). +> +> Beginning from line #49 in master: +> +> if (s->refcount_table_size > 0) { +> BLKDBG_EVENT(bs->file, BLKDBG_REFTABLE_LOAD); +> ret = bdrv_pread(bs->file, s->refcount_table_offset, +> +> The patch: +> +> if (s->refcount_table_size > 0) {^M +> if (s->refcount_table == NULL) {^M +> + ret = -ENOMEM;^M +> goto fail;^M +> }^M +> BLKDBG_EVENT(bs->file, BLKDBG_REFTABLE_LOAD);^M +> ret = bdrv_pread(bs->file, s->refcount_table_offset,^M +> +> At least master version doesn't have this condition. + +It is code added in patch 11 of the same series. + +Kevin + + +The series fixed the crash, but qemu-img started to produce the confusing output: + +$ qemu-img check test_image + +ERROR: I/O error in check_refcounts_l1 +No errors were found on the image. + +QEMU nowadays seems to report "Check failed: Cannot allocate memory" ... so I assume that is OK and we can now close this bug? + +[Expired for QEMU because there has been no activity for 60 days.] + +Have the same proble: qemu-img: Check failed: Cannot allocate memory + diff --git a/results/classifier/zero-shot/108/permissions/1353947 b/results/classifier/zero-shot/108/permissions/1353947 new file mode 100644 index 000000000..94ac16fbb --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1353947 @@ -0,0 +1,103 @@ +permissions: 0.933 +network: 0.897 +debug: 0.889 +semantic: 0.872 +boot: 0.866 +KVM: 0.854 +device: 0.851 +files: 0.849 +PID: 0.847 +other: 0.840 +vnc: 0.831 +graphic: 0.823 +performance: 0.803 +socket: 0.777 + +Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with CirrOS or Ubuntu 12.04 + +The issue observed when running an hypervisor with QEMU 2.0/libvirtd 1.2.2 +The VM network interface is attached to a PCI virtual function (SR-IOV). + +When we ran VM with guest OS CirrOS or Ubuntu 12.04 we observed an hipervisor hang shortly after the VM is loaded +We observed the same issue with Mellanox NIC and with Intel NIC + +We’ve tried few combinations of {GuestOS}X{Hypervisor} and we got the following findings: +When a hypervisor is running QEMU 1.5/libvirtd 1.1.1 - no issue observed +When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CirrOS and Ubuntu 12.04 guest OSes caused hypervisor hang +When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CentOS 6.4 and Ubuntu 13.10 - no issue observed + +The problematic guest OSes are with kernel versions ~3.2.y + + + +Sorry, I'm having trouble following your findings. Could you please give a new table, like +this: + +====================================================================================================================== +GuestOS | Guestkernel | HostOS | Hostkernel | qemu version | libvirt version | nic type | Pass/Fail +====================================================================================================================== +cirros | ??? | 12.04 | 3.2 | 1.0+noroms-0ubuntu13 | 0.9.8-2ubuntu17 | intel SR-IOV | F +====================================================================================================================== +cirros | ??? | 12.04 | 3.13 | 1.0+noroms-0ubuntu13 | 0.9.8-2ubuntu17 | intel SR-IOV | P +====================================================================================================================== +(...0 +====================================================================================================================== + +Ideally we could determine whether the kernel version is at all related, or whether it +is purely tied to qemu version. + + +Hi Serge, +1. Please see the table below +2. We also observed this issue with Intel NICs +=============================================================================================================================================== +GuestOS | Guestkernel | HostOS | Hostkernel | qemu version | libvirt version | nic type | Pass/Fail +=============================================================================================================================================== +Ubuntu 12.04 | 3.2.0-63-generic | Ubuntu 12.04 | 3.11.0-18-generic | 2.0.0+dfsg-2ubuntu1.1 | 1.2.2-0ubuntu13.2 | Mellanox SR-IOV | F +=============================================================================================================================================== +Ubuntu 13.10 | 3.11.0-26-generic | Ubuntu 12.04 | 3.11.0-18-generic | 2.0.0+dfsg-2ubuntu1.1 | 1.2.2-0ubuntu13.2 | Mellanox SR-IOV | P +=============================================================================================================================================== + + +Thanks, so the problem appears to be that a feature is missing from the guest's precise kernel, which was present in the saucy (13.10) kernel. + +Could you verify whether using the LTS backport kernel packages in the precies guest fixes the issue? + +(Note I don't believe this bug should be marked as affecting the QEMU project) + +This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run: + +apport-collect 1353947 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +Can't run apport-collect after the kernel hang + +Hello Serge, +I agree that there is probably some missing feature in the guest kernel. +However, I don't believe it is acceptable for the hyper-visor kernel to be affected from this. +Actually, this is a security issue if a VM user can crash i't Host kernel and probably some other VMs as well. + + +Sorry, when the table only had the two entries i drew some bad assumptions from that, and I also missed the fact that hangs were in the host kernel. + +To be clear, running qemu 1.5 on the same host kernel has no issues with any guest, while qemu 2.0 causes host kernel to hang (indefinately) with some guests? + +Then indeed disregard my comment #5. + +Is this 100% reproducible, every time? Would you be able to bisect qemu to figure out where the problem was introduced? + +Indeed, with qemu 1.5 we did not observed this issue at all. +Sorry, but I don't have the resources at the moment to do the bisecting. + + +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 linux (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1359383 b/results/classifier/zero-shot/108/permissions/1359383 new file mode 100644 index 000000000..b8d67995e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1359383 @@ -0,0 +1,232 @@ +permissions: 0.930 +other: 0.910 +graphic: 0.897 +debug: 0.863 +boot: 0.858 +network: 0.853 +device: 0.825 +KVM: 0.816 +vnc: 0.801 +semantic: 0.782 +files: 0.780 +PID: 0.761 +performance: 0.758 +socket: 0.719 + +kernel panic at smpboot.c:134 when rebooting qemu with multiple cores + +Hi all, + +I can reproduce this with kernel 3.14 and 3.17rc1. I suspect it is a qemu issue, but I'm not sure. The test case is the following script: + +qemu-system-x86_64 -machine accel=kvm -pidfile /tmp/pid$$ -m 512M -smp 8,sockets=8 -kernel vmlinuz -append "init=/sbin/reboot -f console=ttyS0,115200 kgdboc=ttyS2,115200 root=/dev/sda rw" -nographic -serial stdio -drive format=raw,snapshot=on,file=/var/lib/ktest/root + +Note that we pass /sbin/reboot as the init program so it just reboots forever. After a dozen or so iterations, I hit this: + +[ 0.000000] Initializing cgroup subsys cpuset +[ 0.000000] Initializing cgroup subsys cpu +[ 0.000000] Initializing cgroup subsys cpuacct +[ 0.000000] Linux version 3.17.0-rc1-0-2014.sp (sp@vodka) (gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) ) #209 SMP Wed Aug 20 20:17:46 UTC 2014 +[ 0.000000] Command line: init=/sbin/reboot -f console=ttyS0,115200 kgdboc=ttyS2,115200 root=/dev/sda rw ktest.priority=9 +[ 0.000000] e820: BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffcfff] usable +[ 0.000000] BIOS-e820: [mem 0x000000001fffd000-0x000000001fffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +[ 0.000000] process: using polling idle threads +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] SMBIOS 2.4 present. +[ 0.000000] Hypervisor detected: KVM +[ 0.000000] e820: last_pfn = 0x1fffd max_arch_pfn = 0x400000000 +[ 0.000000] PAT not supported by CPU. +[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] +[ 0.000000] init_memory_mapping: [mem 0x1fc00000-0x1fdfffff] +[ 0.000000] init_memory_mapping: [mem 0x1c000000-0x1fbfffff] +[ 0.000000] init_memory_mapping: [mem 0x00100000-0x1bffffff] +[ 0.000000] init_memory_mapping: [mem 0x1fe00000-0x1fffcfff] +[ 0.000000] ACPI: Early table checksum verification disabled +[ 0.000000] ACPI: RSDP 0x00000000000F0A90 000014 (v00 BOCHS ) +[ 0.000000] ACPI: RSDT 0x000000001FFFFC21 000034 (v01 BOCHS BXPCRSDT 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACP 0x000000001FFFEF40 000074 (v01 BOCHS BXPCFACP 00000001 BXPC 00000001) +[ 0.000000] ACPI: DSDT 0x000000001FFFDDC0 001180 (v01 BOCHS BXPCDSDT 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000001FFFDD80 000040 +[ 0.000000] ACPI: SSDT 0x000000001FFFEFB4 000B85 (v01 BOCHS BXPCSSDT 00000001 BXPC 00000001) +[ 0.000000] ACPI: APIC 0x000000001FFFFB39 0000B0 (v01 BOCHS BXPCAPIC 00000001 BXPC 00000001) +[ 0.000000] ACPI: HPET 0x000000001FFFFBE9 000038 (v01 BOCHS BXPCHPET 00000001 BXPC 00000001) +[ 0.000000] No NUMA configuration found +[ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000001fffcfff] +[ 0.000000] Initmem setup node 0 [mem 0x00000000-0x1fffcfff] +[ 0.000000] NODE_DATA [mem 0x1fffa000-0x1fffcfff] +[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00 +[ 0.000000] kvm-clock: cpu 0, msr 0:1fff9001, primary cpu clock +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x00001000-0x00ffffff] +[ 0.000000] DMA32 [mem 0x01000000-0xffffffff] +[ 0.000000] Normal empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x00001000-0x0009efff] +[ 0.000000] node 0: [mem 0x00100000-0x1fffcfff] +[ 0.000000] ACPI: PM-Timer IO Port: 0xb008 +[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) +[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) +[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) +[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled) +[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled) +[ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled) +[ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled) +[ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled) +[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) +[ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.000000] Using ACPI (MADT) for SMP configuration information +[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs +[ 0.000000] e820: [mem 0x20000000-0xfeffbfff] available for PCI devices +[ 0.000000] Booting paravirtualized kernel on KVM +[ 0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:8 nr_node_ids:1 +[ 0.000000] PERCPU: Embedded 27 pages/cpu @ffff88001fc00000 s80064 r8192 d22336 u262144 +[ 0.000000] KVM setup async PF for cpu 0 +[ 0.000000] kvm-stealtime: cpu 0, msr 1fc0d000 +[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 128902 +[ 0.000000] Policy zone: DMA32 +[ 0.000000] Kernel command line: mlx4_core.port_type_array=2,2 intel_idle.max_cstate=0 processor.max_cstate=1 idle=poll init=/sbin/reboot -f console=ttyS0,115200 kgdboc=ttyS2,115200 root=/dev/sda rw ktest.priority=9 +[ 0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes) +[ 0.000000] Memory: 497836K/523884K available (6197K kernel code, 845K rwdata, 2312K rodata, 968K init, 2676K bss, 26048K reserved) +[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 +[ 0.000000] Hierarchical RCU implementation. +[ 0.000000] RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=8. +[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 +[ 0.000000] NR_IRQS:4352 nr_irqs:488 0 +[ 0.000000] Console: colour VGA+ 80x25 +[ 0.000000] console [ttyS0] enabled +[ 0.000000] tsc: Detected 3491.912 MHz processor +[ 0.008000] Calibrating delay loop (skipped) preset value.. 6983.82 BogoMIPS (lpj=13967648) +[ 0.008000] pid_max: default: 32768 minimum: 301 +[ 0.008000] ACPI: Core revision 20140724 +[ 0.008000] ACPI: All ACPI Tables successfully acquired +[ 0.008000] Security Framework initialized +[ 0.008000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) +[ 0.008000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) +[ 0.008000] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) +[ 0.008000] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes) +[ 0.008106] Initializing cgroup subsys devices +[ 0.008379] Initializing cgroup subsys freezer +[ 0.008647] Initializing cgroup subsys net_cls +[ 0.008913] Initializing cgroup subsys blkio +[ 0.009169] Initializing cgroup subsys perf_event +[ 0.009486] mce: CPU supports 10 MCE banks +[ 0.009759] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0 +[ 0.009759] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 +[ 0.010597] Freeing SMP alternatives memory: 28K (ffffffff81dc7000 - ffffffff81dce000) +[ 0.013902] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.014366] smpboot: CPU0: Intel QEMU Virtual CPU version 2.0.0 (fam: 06, model: 06, stepping: 03) +[ 0.016000] Performance Events: Broken PMU hardware detected, using software events only. +[ 0.016000] Failed to access perfctr msr (MSR c1 is 0) +[ 0.016000] NMI watchdog: disabled (cpu0): hardware events not enabled +[ 0.016000] x86: Booting SMP configuration: +[ 0.016000] .... node #0, CPUs: #1 +[ 0.008000] kvm-clock: cpu 1, msr 0:1fff9041, secondary cpu clock +[ 0.028010] KVM setup async PF for cpu 1 +[ 0.028358] #2 +[ 0.028358] kvm-stealtime: cpu 1, msr 1fc4d000 +[ 0.008000] kvm-clock: cpu 2, msr 0:1fff9081, secondary cpu clock +[ 0.044008] KVM setup async PF for cpu 2 +[ 0.044506] #3 +[ 0.044507] kvm-stealtime: cpu 2, msr 1fc8d000 +[ 0.008000] kvm-clock: cpu 3, msr 0:1fff90c1, secondary cpu clock +[ 0.060011] KVM setup async PF for cpu 3 +[ 0.060416] #4 +[ 0.060416] kvm-stealtime: cpu 3, msr 1fccd000 +[ 0.008000] kvm-clock: cpu 4, msr 0:1fff9101, secondary cpu clock +[ 0.072010] KVM setup async PF for cpu 4 +[ 0.072461] #5 +[ 0.072461] kvm-stealtime: cpu 4, msr 1fd0d000 +[ 0.008000] kvm-clock: cpu 5, msr 0:1fff9141, secondary cpu clock +[ 0.088001] KVM setup async PF for cpu 5 +[ 0.088001] #6 +[ 0.088001] kvm-stealtime: cpu 5, msr 1fd4d000 +[ 0.008000] kvm-clock: cpu 6, msr 0:1fff9181, secondary cpu clock +[ 0.108008] ------------[ cut here ]------------ +[ 0.108366] WARNING: CPU: 0 PID: 1 at /src/linux-bcache/kernel/workqueue.c:4473 workqueue_cpu_up_callback+0x36e/0x380() +[ 0.109172] Modules linked in: +[ 0.109419] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc1-0-2014.sp #209 +[ 0.112001] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 +[ 0.112606] 0000000000000009 ffff88001e927db8 ffffffff81601466 0000000000000000 +[ 0.113208] ffff88001e927df0 ffffffff810b4bb8 ffff88001fd92400 ffff88001fd92730 +[ 0.113813] ffff88001fd92708 0000000000000006 ffff88001ea92540 ffff88001e927e00 +[ 0.114422] Call Trace: +[ 0.114616] [<ffffffff81601466>] dump_stack+0x45/0x56 +[ 0.115011] [<ffffffff810b4bb8>] warn_slowpath_common+0x78/0xa0 +[ 0.115474] [<ffffffff810b4c95>] warn_slowpath_null+0x15/0x20 +[ 0.116002] [<ffffffff810cca2e>] workqueue_cpu_up_callback+0x36e/0x380 +[ 0.116507] [<ffffffff810d0f5c>] notifier_call_chain+0x4c/0x70 +[ 0.116962] [<ffffffff810d1059>] __raw_notifier_call_chain+0x9/0x10 +[ 0.117458] [<ffffffff810b4dee>] cpu_notify+0x1e/0x40 +[ 0.117857] [<ffffffff810b5006>] cpu_up+0x186/0x1b0 +[ 0.118249] [<ffffffff81d06272>] smp_init+0x63/0x7d +[ 0.118633] [<ffffffff81cea12e>] kernel_init_freeable+0xe9/0x200 +[ 0.119114] [<ffffffff815f99a0>] ? rest_init+0x80/0x80 +[ 0.119524] [<ffffffff815f99a9>] kernel_init+0x9/0xf0 +[ 0.120002] [<ffffffff816077bc>] ret_from_fork+0x7c/0xb0 +[ 0.120443] [<ffffffff815f99a0>] ? rest_init+0x80/0x80 +[ 0.120867] ---[ end trace bac34f2af212d79e ]--- +[ 0.121255] ------------[ cut here ]------------ +[ 0.121243] KVM setup async PF for cpu 6 +[ 0.121243] kvm-stealtime: cpu 6, msr 1fd8d000 +[ 0.122309] kernel BUG at /src/linux-bcache/kernel/smpboot.c:134! +[ 0.122799] invalid opcode: 0000 [#1] SMP +[ 0.123150] Modules linked in: +[ 0.123406] CPU: 0 PID: 36 Comm: watchdog/6 Tainted: G W 3.17.0-rc1-0-2014.sp #209 +[ 0.124000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 +[ 0.124000] task: ffff88001eb00000 ti: ffff88001eb08000 task.ti: ffff88001eb08000 +[ 0.124000] RIP: 0010:[<ffffffff810d390f>] [<ffffffff810d390f>] smpboot_thread_fn+0x19f/0x1b0 +[ 0.124000] RSP: 0000:ffff88001eb0be88 EFLAGS: 00010206 +[ 0.124000] RAX: 0000000000000000 RBX: ffff88001eb00000 RCX: 0000000000000000 +[ 0.124000] RDX: ffff88001eb0bfd8 RSI: ffff88001eb00000 RDI: 0000000000000006 +[ 0.124000] RBP: ffff88001eb0bec8 R08: ffff88001eb08000 R09: ffff88001eb01a89 +[ 0.124000] R10: 0000000000000010 R11: 0000000000000001 R12: ffff88001e801930 +[ 0.124000] R13: ffffffff81c4b720 R14: ffff88001eb00000 R15: ffff88001eb00000 +[ 0.124000] FS: 0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 +[ 0.124000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +[ 0.124000] CR2: 00000000ffffffff CR3: 0000000001c14000 CR4: 00000000000006f0 +[ 0.124000] Stack: +[ 0.124000] 0000000000000000 ffff88001eb0bea0 ffffffff81603714 ffff88001e90bb00 +[ 0.124000] ffff88001e801930 ffffffff810d3770 0000000000000000 0000000000000000 +[ 0.124000] ffff88001eb0bf48 ffffffff810d00cd 0000000000000001 0000000000000006 +[ 0.124000] Call Trace: +[ 0.124000] [<ffffffff81603714>] ? schedule+0x24/0x70 +[ 0.124000] [<ffffffff810d3770>] ? SyS_setgroups+0x190/0x190 +[ 0.124000] [<ffffffff810d00cd>] kthread+0xcd/0xf0 +[ 0.124000] [<ffffffff810d0000>] ? kthread_create_on_node+0x170/0x170 +[ 0.124000] [<ffffffff816077bc>] ret_from_fork+0x7c/0xb0 +[ 0.124000] [<ffffffff810d0000>] ? kthread_create_on_node+0x170/0x170 +[ 0.124000] Code: 89 fa 48 0f a3 11 19 d2 31 f6 85 d2 40 0f 95 c6 ff d0 4c 89 e7 e8 82 16 0f 00 48 83 c4 18 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 0f 0b 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 89 d0 55 48 +[ 0.124000] RIP [<ffffffff810d390f>] smpboot_thread_fn+0x19f/0x1b0 +[ 0.124000] RSP <ffff88001eb0be88> +[ 0.124002] ---[ end trace bac34f2af212d79f ]--- +[ 0.124456] Kernel panic - not syncing: Fatal exception +[ 0.128000] Shutting down cpus with NMI +[ 0.128000] ---[ end Kernel panic - not syncing: Fatal exception + +Note there's an SMP-related warning coming out of workqueue.c right before the panic. + +I have attached the .config I'm using with the kernel. + + + +The bug is probably fixed by +https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dd9d3843755da95f63dd3a376f62b3e45c011210 + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU and the kernel, or did the patch mentioned in comment #2 fix it? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1364 b/results/classifier/zero-shot/108/permissions/1364 new file mode 100644 index 000000000..7131ab1fb --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1364 @@ -0,0 +1,30 @@ +permissions: 0.983 +network: 0.981 +device: 0.939 +graphic: 0.935 +other: 0.901 +vnc: 0.763 +performance: 0.726 +semantic: 0.694 +PID: 0.639 +debug: 0.478 +boot: 0.401 +socket: 0.382 +KVM: 0.331 +files: 0.052 + +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/zero-shot/108/permissions/1395217 b/results/classifier/zero-shot/108/permissions/1395217 new file mode 100644 index 000000000..1f4cfcbb0 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1395217 @@ -0,0 +1,332 @@ +permissions: 0.931 +semantic: 0.905 +debug: 0.832 +graphic: 0.801 +other: 0.800 +socket: 0.789 +network: 0.781 +device: 0.776 +vnc: 0.719 +performance: 0.719 +PID: 0.704 +KVM: 0.655 +files: 0.632 +boot: 0.588 + +Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11 + +The networking code in qemu in versions 2.0.0 and beyond is non-functional with Solaris/Illumos 5.11 images. + +Building 1.7.1, 2.0.0, 2.0.2, 2.1.2,and 2.2.0rc1with the following standard Slackware config: + +# From Slackware build tree . . . +./configure \ + --prefix=/usr \ + --libdir=/usr/lib64 \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --enable-gtk \ + --enable-system \ + --enable-kvm \ + --disable-debug-info \ + --enable-virtfs \ + --enable-sdl \ + --audio-drv-list=alsa,oss,sdl,esd \ + --enable-libusb \ + --disable-vnc \ + --target-list=x86_64-linux-user,i386-linux-user,x86_64-softmmu,i386-softmmu \ + --enable-spice \ + --enable-usb-redir + + +And attempting to run the same VM image with the following command (or via virt-manager): + +macaddress="DE:AD:BE:EF:3F:A4" + +qemu-system-x86_64 nex4x -cdrom /dev/cdrom -name "Nex41" -cpu Westmere +-machine accel=kvm -smp 2 -m 4000 -net nic,macaddr=$macaddress -net bridge,br=b +r0 -net dump,file=/usr1/tmp/<FILENAME> -drive file=nex4x_d1 -drive file=nex4x_d2 + -enable-kvm + +Gives success on 1.7.1, and a deaf VM on all subsequent versions. + +Notable in validating my config, is that a Windows 7 image runs cleanly with networking on *all* builds, so my configuration appears to be good - qemu just hates Solaris at this point. + +Watching with wireshark (as well as pulling network traces from qemu as noted above) it appears that the notable difference in the two configs is that for some reason, Solaris gets stuck arping for it's own interface on startup, and never really comes on line on the network. If other hosts attempt to ping the Solaris instance, they can successfully arp the bad VM, but not the other way around. + + + + + +Note that the host system, network config, etc. are identical, qemu is built with an identical config, and started with the same command - the *ONLY* variable is the qemu version. This is utilizing the bridge-helper binary, but as noted earlier, using virt-manager whether allowing it to define it's on network, or using the existing bridge config on this box, the behaviour is the same, and only Solaris is failing. + +I note also that the failure happens with both the e1000 and the rtl8139 interfaces - this does not appear to be an issue with the drivers, but more a case of how qemu passes traffic to and from the tap device. Looking at the tap device with wireshark, I can see the external traffic as well as traffic from qemu - it just appears that some does not make it into Solaris. + +I also noted discussions several years ago regarding a very similar issue, but do not have a bug number at this point (2010 vintage). Not certain that that is relevant, but it definitely is similar. + +Host platform is Slackware 14.1, x86_64 . . . cc 4.8.2, kernel 3.10.17 + + +Can you try bisecting between 1.7 and 2.0 with git? + +Paolo - I should have some time to do that this week, as well as bone up on git (it's been a bit . . .) + +And thanks for the quick reply! + +Bisected merrily away, and this is where it definitively begins to fail . . . To verify, I checked out both commits, and confirmed change in function at this point. I attempted a revoke of this commit on my clone to test, but too many merge errors to make that a simple task, so that was not done. + +commit ef02ef5f4536dba090b12360a6c862ef0e57e3bc +Author: Eduardo Habkost <email address hidden> +Date: Wed Feb 19 11:58:12 2014 -0300 + + target-i386: Enable x2apic by default on KVM + + When on KVM mode, enable x2apic by default on all CPU models. + + Normally we try to keep the CPU model definitions as close as the real + CPUs as possible, but x2apic can be emulated by KVM without host CPU + support for x2apic, and it improves performance by reducing APIC access + overhead. x2apic emulation is available on KVM since 2009 (Linux + 2.6.32-rc1), there's no reason for not enabling x2apic by default when + running KVM. + + Signed-off-by: Eduardo Habkost <email address hidden> + Acked-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Andreas Färber <email address hidden> + +:040000 040000 ebdc1ecd08cb507db62cc465696925a4cde6174f e83d9c32f821714600c48594 +15911910d4b37c0d M hw +:040000 040000 9064bc796128ba1380b67a86af9718dcc1022f0d 5cb337c72259b54780856806 +8f56f4abfa628579 M target-i386 + + +This does not appear to be run-time selectable (or I have not found the option yet . . . ) so not quire sure how to verify if backing this out will resolve the issue in later versions. + + +Additional test (I just don't know when to go to bed . . . *sigh* . . . ). + +In a checkout of the 2.1.2 code base, and based on the above failing commit as per bisect, I removed the change in the commit for target-i386/cpu.c of the line: + +[FEAT_1_ECX] = CPUID_EXT_X1APIC, + +as added by the errant commit, recompiled, and networking is now working with Illumos in 2.1.2, so this commit is definitely not as innocent as it may appear. + +It is runtime selectable using "-cpu ...,-x2apic" (as indicated by Markus on qemu-devel). + +First thing we need to find out is if it fails on the newest CPU model that can be run in enforce mode. + +So, assuming you are running on an Intel host CPU, it would be interesting to test those CPU models in this order, until you have one that actually boots: + + -cpu Broadwell,enforce + -cpu Haswell,enforce + -cpu SandyBridge,enforce + -cpu Westmere,enforce + -cpu Nehalem,enforce + -cpu Penryn,enforce + -cpu Conroe,enforce + +Testing of: + -cpu host +would be interesting, too. + +If the latest CPU model (or -cpu host) have working networking, that means Solaris (or QEMU NIC emulation code) doesn't like to see an old CPU with x2apic enabled. If it doesn't work even using the latest CPU model (and -cpu host), that means Solaris (or QEMU NIC emulation) doesn't like the x2apic implementation of KVM at all (and that could mean a Solaris bug, a QEMU bug, or a KVM x2apic emulation bug). + + +Broadwell - Fails, Host won't support it: + +warning: host doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: host doesn't support requested feature: CPUID.01H:ECX.movbe [bit 22] +warning: host doesn't support requested feature: CPUID.07H:EBX.fsgsbase [bit 0] +warning: host doesn't support requested feature: CPUID.07H:EBX.bmi1 [bit 3] +warning: host doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: host doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: host doesn't support requested feature: CPUID.07H:EBX.smep [bit 7] +warning: host doesn't support requested feature: CPUID.07H:EBX.bmi2 [bit 8] +warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9] +warning: host doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: host doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +warning: host doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +warning: host doesn't support requested feature: CPUID.07H:EBX.adx [bit 19] +warning: host doesn't support requested feature: CPUID.07H:EBX.smap [bit 20] +warning: host doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8] +qemu-system-x86_64: Host doesn't support requested features + +Haswell fails, host won't support it: + +warning: host doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: host doesn't support requested feature: CPUID.01H:ECX.movbe [bit 22] +warning: host doesn't support requested feature: CPUID.07H:EBX.fsgsbase [bit 0] +warning: host doesn't support requested feature: CPUID.07H:EBX.bmi1 [bit 3] +warning: host doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: host doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: host doesn't support requested feature: CPUID.07H:EBX.smep [bit 7] +warning: host doesn't support requested feature: CPUID.07H:EBX.bmi2 [bit 8] +warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9] +warning: host doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: host doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +qemu-system-x86_64: Host doesn't support requested features + + +SandyBridge (this is the test box physical CPU) fails, no errors, networking dead, as per initial problem. + +Westmere fails, no networking. + +Nehalem fails, no networking + +Panryn fails, no networking + +Conroe fails, no networking + +host fails, no networking + +Just to ensure that all else was good, I tested SandyBridge, Westmere, Conroe, and host with "-x2apic" and every one works with x2apic disabled. + +This test box is a laptop, and I am only testing on it since I am away from my primary server (Dell 2950) for the holiday. Both Intel, but not even close to the same CPU . . . same problem observed on both, although workaround not tested yet on primary. + + +Test box (for this data) CPU into: + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 42 +model name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz +stepping : 7 +microcode : 0x25 +cpu MHz : 1200.000 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov +pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm c +onstant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu + pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid s +se4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb + xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid +bogomips : 4984.29 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +(Repeats for 4 cores) + + + + +Primary system: + +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 15 +model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz +stepping : 7 +microcode : 0x6b +cpu MHz : 2000.000 +cache size : 4096 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 10 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov +pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant +_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vm +x est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm dtherm tpr_shadow +bogomips : 4655.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +(Repeats for 8 cores) + + +Note that this Illumos image is certified/runs cleanly on Intel hardware from the last 5 years when natively on it. I doubt that it is a kernel problem with Illumos with regard to the actual CPU architecture. Older releases that are OpenSolaris based also see the problem. + +Generally speaking, I don't think that an issue of this nature has ever been seen with this OS image on any Intel or AMD CPU ever tested . . . so unless there is something in Illumos that is only triggered by qemu, I find it hard to imagine it being an Illumos bug, but then again, it's not like oddities like this never happen . . . + +And thanks for all the quick attention! If nothing else, it got me to a point whereby I can work around the problem, and not be stuck on older builds that virt-manager hates . . . . + +(Wow . . . that last was incredibly redundant . . . staying up most of the night working on this has apparently left me a bit stupid this morning/afternoon . . . sorry!) + + +So, if it breaks even with -cpu SandyBridge and -cpu host, it is likely to be a KVM or QEMU bug. Thanks for the testing! + +Much appreciated! Please let me know if there is anything else I can do to help this bug progress . . . . + +- Tim + +FWIW there's some other hits on this: + +Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040500 +Openstack mailing list: http://lists.openstack.org/pipermail/openstack-dev/2014-December/053478.html + +Hello to all, I confirm this bug in qemu. + +12 different Linux versions/distributions and 1 Windows 7 VM are running fine without any networking issue. +Solaris 5.11 Version 11.2 can be installed (text version) and is running but network is broken. + +DHCPOFFER will not be received by Solaris 5.11 VM's (RX not working) for Automatic profile. +If DefaultFixed profile is online there is the same behavior. +Arp table on Solaris containes the own entry which is completed. +If I ping another host, the IP will be added but no MAC, which indicates that also no ARP package will be received. + +I could NOT get it working with disabled x2apic (tested with different CPU types). +Is there something additional which has to be changed? + +qemu version is 2.0.0+dfsg-2ubuntu1.10 @ ubuntu 14.04.2 LTS, Kernel 3.13.0-49-generic. + + + +See also bug #638955 + +See the following bug report for a working Solaris 10 KVM guest configuration: +https://bugzilla.redhat.com/show_bug.cgi?id=1262093 + +#17 +I have the same situtaion +when I use cpu line as "-cpu qemu64,-x2apic" the network still doesn't work. +maybe there is another way to remove x2apic,but I don't get it. +for the arp ,as you say ,there is not MAC. +Have you solve the problem ? + + +host: ubuntu 14.04 +qemu img:openindiana 5.11 + + +any one have a right way ? + +I fixed this by adding the configuration in the xml configuration file: + <cpu mode='custom' match='exact'> + <model fallback='allow'>SandyBridge</model> + <feature policy='disable' name='x2apic'/> + </cpu> + +See also attachement (https://bugzilla.redhat.com/attachment.cgi?id=1072357) of bug https://bugzilla.redhat.com/show_bug.cgi?id=1262093. + +Note that I tested with Solaris 10, not openindiana 5.11 + +On Fedora, I had to use this command to edit the VM config file: +virsh edit <put_here_name_of_your_vm> + +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/zero-shot/108/permissions/1400 b/results/classifier/zero-shot/108/permissions/1400 new file mode 100644 index 000000000..729823295 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1400 @@ -0,0 +1,16 @@ +permissions: 0.931 +network: 0.861 +device: 0.852 +vnc: 0.665 +socket: 0.564 +performance: 0.526 +debug: 0.494 +KVM: 0.360 +graphic: 0.263 +boot: 0.239 +PID: 0.233 +semantic: 0.230 +files: 0.193 +other: 0.155 + +helper_access_check_cp_reg() raising Undefined Instruction on big-endian host diff --git a/results/classifier/zero-shot/108/permissions/1415181 b/results/classifier/zero-shot/108/permissions/1415181 new file mode 100644 index 000000000..94ac5643e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1415181 @@ -0,0 +1,104 @@ +permissions: 0.943 +semantic: 0.935 +graphic: 0.931 +other: 0.931 +vnc: 0.928 +debug: 0.921 +device: 0.918 +PID: 0.908 +boot: 0.906 +KVM: 0.899 +performance: 0.898 +socket: 0.897 +network: 0.890 +files: 0.887 + +Access raw partitions from Windows + +I'm using a windows tablet that makes imposible usb booting. It would be nice to have access to raw partitions in order to run linux installers using qemu. I can successfully install several boot loaders using uefi, so I gues this feature would be very helpful. +Thanks! + +I am not sure whether I have understood your request completely. QEMU can access raw partitions if the OS supports them. MS Windows supports physical partitions and calls them \\.\PhysicalDrive0, \\.\PhysicalDrive1 and so on. Admin rights are required to access these devices. Depending on your shell, the backslashes might need to be escaped, or you will have to write //./PhysicalDrive0. + +Using raw partitions from QEMU can be really dangerous, so you should know what you are doing, overwise the result might be that your windows tablet no longer boots at all. + +Well, the tablet calls \\.\PhysicalDrive0 to the entire disk and +\\.\PhysicalDrive2 a mounted pendrive. Looking at disk administration,, +\\.\PhysicalDrive0 has the following partition schema: +- 2GB Recover partition +- 500M EFI partition +- 15,04 Windows C: Partition +- 6G Raw partition (no data, here is where I want to install linux) +- 5,46G Recover partition +The idea is to install a linux distro in the 6G partition, obviously I +wouldn't use the partition editor of the installer nor install a bootloader +in theese conditions. If I need to modify the partitions I would do in +advance from Windows, and for the booting I would use refind or grub, which +both work as I could test. + +El Wed Jan 28 2015 at 4:40:48, Stefan Weil (<email address hidden>) +escribió: + +> I am not sure whether I have understood your request completely. QEMU +> can access raw partitions if the OS supports them. MS Windows supports +> physical partitions and calls them \\.\PhysicalDrive0, +> \\.\PhysicalDrive1 and so on. Admin rights are required to access these +> devices. Depending on your shell, the backslashes might need to be +> escaped, or you will have to write //./PhysicalDrive0. +> +> Using raw partitions from QEMU can be really dangerous, so you should +> know what you are doing, overwise the result might be that your windows +> tablet no longer boots at all. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1415181 +> +> Title: +> Access raw partitions from Windows +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1415181/+subscriptions +> + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +Well, it's not an issue for me, but is a nice to have feature. I don't use +the tablet in question anymore. The tablet had an uefi that didn't allow +pendrive boot, but if it could be done what I proposed with qemu, a linux +distro could be booted with qemu and this installed manually in a +partition. The Uefi of the tablet did allow a grub install and also I could +install another bootloader, but any of them recognized pendrives. +So, personally I don't care anymore for now. But would allow a beautiful +method to override insane manufacturers setups. +Thanks, regards! +Sebastián + +El vie., 7 ago. 2020 a las 15:05, Thomas Huth (<email address hidden>) +escribió: + +> Looking through old bug tickets... is this still an issue with the +> latest version of QEMU? Or could we close this ticket nowadays? +> +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1415181 +> +> Title: +> Access raw partitions from Windows +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1415181/+subscriptions +> + + +Ok, thanks for your answer! Apparently no developer looked into this during the past 5 years, so it likely won't happen in the future, and since you don't need it anymore, let's simply close this ticket. + diff --git a/results/classifier/zero-shot/108/permissions/1421 b/results/classifier/zero-shot/108/permissions/1421 new file mode 100644 index 000000000..eabbbdd73 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1421 @@ -0,0 +1,34 @@ +permissions: 0.976 +graphic: 0.843 +device: 0.804 +debug: 0.803 +performance: 0.739 +semantic: 0.534 +vnc: 0.443 +PID: 0.401 +other: 0.385 +socket: 0.372 +boot: 0.317 +network: 0.296 +files: 0.161 +KVM: 0.028 + +GDB memory reads fail on Cortex-M33 +Description of problem: +GDB fails to read memory from the guest. There appear to be at least two problems: + +1. In `arm_cpu_get_phys_page_attrs_debug`, `arm_is_secure(env)` returns false, because the implementation doesn't seem to know about Armv7-M or Armv8-M secure states. However, `arm_mmu_idx(env)` does know how to check `env->v7m.secure`, so it returns `ARMMMUIdx_MSPriv` (the S stands for secure). The mismatch between an apparently non-secure access to a secure MMU seems to cause the read to fail laster. +2. With the MPU enabled (not the case in this repro, but I can provide one), `cpu_memory_rw_debug` computes `page = addr & TARGET_PAGE_MASK`, and uses the page to compute permissions. However, TARGET_PAGE_MASK is based on 4K pages on this platform, but the MPU granularity is 32 bytes. So the wrong page is used for checking. +Steps to reproduce: +``` +# Sorry for the large clone. It's mostly unused files in CMSIS. +git clone --recursive -b qemu-repro-1 https://github.com/dreiss/mpu_experiments +cd mpu_experiments +git checkout origin/qemu-repro-1 +cmake -S . -B build -DBOARD=qemu-mps2-an505 -DAPP=mpu_stacktrace -DCMAKE_BUILD_TYPE=Debug +cmake --build build +/path/to/qemu-system-arm -machine mps2-an505 -nographic -kernel build/kernel.elf -s -S -d int +# Open a separate terminal and cd into mpu_experiments +gdb build/kernel.elf -ex 'target remote :1234' -ex 'break base_case' -ex continue -ex backtrace -ex quit +# Note the memory read failures in the backtrace. +``` diff --git a/results/classifier/zero-shot/108/permissions/1446 b/results/classifier/zero-shot/108/permissions/1446 new file mode 100644 index 000000000..cbea826ed --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1446 @@ -0,0 +1,190 @@ +permissions: 0.980 +other: 0.979 +debug: 0.974 +graphic: 0.972 +device: 0.970 +semantic: 0.968 +vnc: 0.966 +KVM: 0.966 +PID: 0.965 +files: 0.965 +performance: 0.962 +boot: 0.944 +socket: 0.936 +network: 0.885 + +Heap buffer overflow in nand_blk_write_512() +Description of problem: +I captured the negative-size-param (memcpy) in nand_blk_load_512() like below. + +``` +diff --git a/hw/block/nand.c b/hw/block/nand.c +index 8bc80e351..f68b23d05 100644 +--- a/hw/block/nand.c ++++ b/hw/block/nand.c +@@ -790,6 +790,10 @@ static void glue(nand_blk_load_, NAND_PAGE_SIZE)(NANDFlashState *s, + s->ioaddr = s->io + (PAGE_START(addr) & 0x1ff) + offset; + } + } else { ++ int size = NAND_PAGE_SIZE + OOB_SIZE - offset; ++ if (size < 0) { ++ return; ++ } + memcpy(s->io, s->storage + PAGE_START(s->addr) + + offset, NAND_PAGE_SIZE + OOB_SIZE - offset); + s->ioaddr = s->io; + +``` + +Then, I triggered an integer overflow in nand_blk_write_512() resulting in a +heap buffer overflow. Specifically, s->iolen is a signed integer[1], but based +on the function signature of mem_and(), s->iolen will be casted to an unsigned +integer[2]. Asan then captures a heap buffer overflow[3]. + +``` +static void glue(nand_blk_write_, NAND_PAGE_SIZE)(NANDFlashState *s) +{ + // ... + if (!s->blk) { + mem_and(s->storage + PAGE_START(s->addr) + (s->addr & PAGE_MASK) + + s->offset, s->io, s->iolen); // <--------------- [1] + } else if (s->mem_oob) { + // ... + +static void mem_and(uint8_t *dest, const uint8_t *src, size_t n) // <--- [2] +{ + int i; + for (i = 0; i < n; i++) { + dest[i] &= src[i]; // <----------------------------------------- [3] + } +} +``` +Steps to reproduce: +Please patch your hw/block/nand.c first. + +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine tosa -monitor none -serial none \ +-display none -qtest stdio +write 0x10000111 0x1 0xca +write 0x10000104 0x1 0x47 +write 0x1000ca04 0x1 0xd7 +write 0x1000ca01 0x1 0xe0 +write 0x1000ca04 0x1 0x71 +write 0x1000ca00 0x1 0x50 +write 0x1000ca04 0x1 0xd7 +read 0x1000ca02 0x1 +write 0x1000ca01 0x1 0x10 +EOF +``` +Additional information: +``` +==15750==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x560e65814d70). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 4218744906 +INFO: Loaded 1 modules (601336 inline 8-bit counters): 601336 [0x560e68702000, 0x560e68794cf8), +INFO: Loaded 1 PC tables (601336 PCs): 601336 [0x560e67dd42a0,0x560e68701220), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *tc6393xb* +This process will fuzz the following MemoryRegions: + * tc6393xb.vram[0] (size 100000) + * tc6393xb[0] (size 10000) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * tc6393xb.vram, EVENT_TYPE_MMIO_READ, 0x10100000 +0x100000, 1,4 + * tc6393xb.vram, EVENT_TYPE_MMIO_WRITE, 0x10100000 +0x100000, 1,4 + * tc6393xb, EVENT_TYPE_MMIO_READ, 0x10000000 +0x10000, 1,1 + * tc6393xb, EVENT_TYPE_MMIO_WRITE, 0x10000000 +0x10000, 1,1 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 281Mb +Running: /root/videzzo/videzzo_qemu/out-san/poc-qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb-crash-35f3f537422c4e74ce65177b3d6369045e60b47f.minimized +================================================================= +==15750==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61f000000de0 at pc 0x560e61557210 bp 0x7ffcfc4a59f0 sp 0x7ffcfc4a59e8 +READ of size 1 at 0x61f000000de0 thread T0 + #0 0x560e6155720f in mem_and /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:101:20 + #1 0x560e6155ac9c in nand_blk_write_512 /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:663:9 + #2 0x560e61544200 in nand_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:293:13 + #3 0x560e6153cc83 in nand_setio /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:520:13 + #4 0x560e61a0a69e in tc6393xb_nand_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:380:13 + #5 0x560e619f9bf7 in tc6393xb_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:524:9 + #6 0x560e647c7d03 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #7 0x560e647c7641 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #8 0x560e647c5f66 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #9 0x560e6485409e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #10 0x560e648421eb in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #11 0x560e64841ca8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #12 0x560e61170162 in qemu_writeb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1080:5 + #13 0x560e6116eef7 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1227:28 + #14 0x560e6581072f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #15 0x560e65807aab in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #16 0x560e65807980 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #17 0x560e611780fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12 + #18 0x560e65815012 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #19 0x560e61059816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #20 0x560e6103c444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #21 0x560e610473ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #22 0x560e610339d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #23 0x7f79587d0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #24 0x560e61033a2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb+0x300fa2d) + +0x61f000000de0 is located 0 bytes to the right of 3424-byte region [0x61f000000080,0x61f000000de0) +allocated by thread T0 here: + #0 0x560e611276cf in malloc /root/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 + #1 0x7f7959a87e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) + #2 0x560e64b98871 in object_new /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:749:12 + #3 0x560e64b5d1a1 in qdev_new /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:153:19 + #4 0x560e61547ea5 in nand_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:639:11 + #5 0x560e619f8772 in tc6393xb_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:558:16 + #6 0x560e6390bad2 in tosa_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/arm/tosa.c:250:12 + #7 0x560e61730887 in machine_run_board_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/machine.c:1400:5 + #8 0x560e633bdd5b in qemu_init_board /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2485:5 + #9 0x560e633bda6c in qmp_x_exit_preconfig /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2581:5 + #10 0x560e633c4fef in qemu_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:3584:9 + #11 0x560e611763f3 in LLVMFuzzerInitialize /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1761:5 + #12 0x560e61043fab in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:664:29 + #13 0x560e610339d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #14 0x7f79587d0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:101:20 in mem_and +Shadow bytes around the buggy address: + 0x0c3e7fff8160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c3e7fff8170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c3e7fff8180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c3e7fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c3e7fff81a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +=>0x0c3e7fff81b0: 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa + 0x0c3e7fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e7fff81d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e7fff81e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e7fff81f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e7fff8200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==15750==ABORTING +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x1,0xb,0x12,0x1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xca,0x4f,0x4d,0x5f,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0x1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x47,0xf0,0xc8,0x58,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0xa1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xd7,0x38,0xfc,0x29,0x0,0x0,0x0,0x0,0x1,0xb,0x1,0x9a,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xe0,0xb0,0x63,0x62,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0x8a,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x71,0xaa,0x20,0x60,0x0,0x0,0x0,0x0,0x1,0xb,0x0,0x5,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x50,0x9f,0x0,0x40,0x0,0x0,0x0,0x0,0x1,0xb,0x4,0xa1,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0xd7,0x38,0xfc,0x29,0x0,0x0,0x0,0x0,0x0,0xa,0x2,0x24,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x1,0xb,0x1,0xc5,0x0,0x10,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x10,0x8b,0x36,0x70,0x0,0x0,0x0,0x0, +\x01\x0b\x12\x01\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xcaOM_\x00\x00\x00\x00\x01\x0b\x04\x01\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00G\xf0\xc8X\x00\x00\x00\x00\x01\x0b\x04\xa1\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xd78\xfc)\x00\x00\x00\x00\x01\x0b\x01\x9a\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xe0\xb0cb\x00\x00\x00\x00\x01\x0b\x04\x8a\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00q\xaa `\x00\x00\x00\x00\x01\x0b\x00\x05\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00P\x9f\x00@\x00\x00\x00\x00\x01\x0b\x04\xa1\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\xd78\xfc)\x00\x00\x00\x00\x00\x0a\x02$\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\x01\x0b\x01\xc5\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\x10\x8b6p\x00\x00\x00\x00 +``` diff --git a/results/classifier/zero-shot/108/permissions/14488057 b/results/classifier/zero-shot/108/permissions/14488057 new file mode 100644 index 000000000..6fa010b72 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/14488057 @@ -0,0 +1,721 @@ +permissions: 0.940 +PID: 0.930 +device: 0.929 +debug: 0.925 +other: 0.922 +performance: 0.911 +semantic: 0.905 +boot: 0.892 +graphic: 0.887 +vnc: 0.882 +KVM: 0.880 +network: 0.846 +socket: 0.825 +files: 0.823 + +[Qemu-devel] [BUG] user-to-root privesc inside VM via bad translation caching + +This is an issue in QEMU's system emulation for X86 in TCG mode. +The issue permits an attacker who can execute code in guest ring 3 +with normal user privileges to inject code into other processes that +are running in guest ring 3, in particular root-owned processes. + +== reproduction steps == + + - Create an x86-64 VM and install Debian Jessie in it. The following + steps should all be executed inside the VM. + - Verify that procmail is installed and the correct version: + address@hidden:~# apt-cache show procmail | egrep 'Version|SHA' + Version: 3.22-24 + SHA1: 54ed2d51db0e76f027f06068ab5371048c13434c + SHA256: 4488cf6975af9134a9b5238d5d70e8be277f70caa45a840dfbefd2dc444bfe7f + - Install build-essential and nasm ("apt install build-essential nasm"). + - Unpack the exploit, compile it and run it: + address@hidden:~$ tar xvf procmail_cache_attack.tar + procmail_cache_attack/ + procmail_cache_attack/shellcode.asm + procmail_cache_attack/xp.c + procmail_cache_attack/compile.sh + procmail_cache_attack/attack.c + address@hidden:~$ cd procmail_cache_attack + address@hidden:~/procmail_cache_attack$ ./compile.sh + address@hidden:~/procmail_cache_attack$ ./attack + memory mappings set up + child is dead, codegen should be complete + executing code as root! :) + address@hidden:~/procmail_cache_attack# id + uid=0(root) gid=0(root) groups=0(root),[...] + +Note: While the exploit depends on the precise version of procmail, +the actual vulnerability is in QEMU, not in procmail. procmail merely +serves as a seldomly-executed setuid root binary into which code can +be injected. + + +== detailed issue description == +QEMU caches translated basic blocks. To look up a translated basic +block, the function tb_find() is used, which uses tb_htable_lookup() +in its slowpath, which in turn compares translated basic blocks +(TranslationBlock) to the lookup information (struct tb_desc) using +tb_cmp(). + +tb_cmp() attempts to ensure (among other things) that both the virtual +start address of the basic block and the physical addresses that the +basic block covers match. When checking the physical addresses, it +assumes that a basic block can span at most two pages. + +gen_intermediate_code() attempts to enforce this by stopping the +translation of a basic block if nearly one page of instructions has +been translated already: + + /* if too long translation, stop generation too */ + if (tcg_op_buf_full() || + (pc_ptr - pc_start) >= (TARGET_PAGE_SIZE - 32) || + num_insns >= max_insns) { + gen_jmp_im(pc_ptr - dc->cs_base); + gen_eob(dc); + break; + } + +However, while real X86 processors have a maximum instruction length +of 15 bytes, QEMU's instruction decoder for X86 does not place any +limit on the instruction length or the number of instruction prefixes. +Therefore, it is possible to create an arbitrarily long instruction +by e.g. prepending an arbitrary number of LOCK prefixes to a normal +instruction. This permits creating a basic block that spans three +pages by simply appending an approximately page-sized instruction to +the end of a normal basic block that starts close to the end of a +page. + +Such an overlong basic block causes the basic block caching to fail as +follows: If code is generated and cached for a basic block that spans +the physical pages (A,E,B), this basic block will be returned by +lookups in a process in which the physical pages (A,B,C) are mapped +in the same virtual address range (assuming that all other lookup +parameters match). + +This behavior can be abused by an attacker e.g. as follows: If a +non-relocatable world-readable setuid executable legitimately contains +the pages (A,B,C), an attacker can map (A,E,B) into his own process, +at the normal load address of A, where E is an attacker-controlled +page. If a legitimate basic block spans the pages A and B, an attacker +can write arbitrary non-branch instructions at the start of E, then +append an overlong instruction +that ends behind the start of C, yielding a modified basic block that +spans all three pages. If the attacker then executes the modified +basic block in his process, the modified basic block is cached. +Next, the attacker can execute the setuid binary, which will reuse the +cached modified basic block, executing attacker-controlled +instructions in the context of the privileged process. + +I am sending this to qemu-devel because a QEMU security contact +told me that QEMU does not consider privilege escalation inside a +TCG VM to be a security concern. +procmail_cache_attack.tar +Description: +Unix tar archive + +On 20 March 2017 at 14:36, Jann Horn <address@hidden> wrote: +> +This is an issue in QEMU's system emulation for X86 in TCG mode. +> +The issue permits an attacker who can execute code in guest ring 3 +> +with normal user privileges to inject code into other processes that +> +are running in guest ring 3, in particular root-owned processes. +> +I am sending this to qemu-devel because a QEMU security contact +> +told me that QEMU does not consider privilege escalation inside a +> +TCG VM to be a security concern. +Correct; it's just a bug. Don't trust TCG QEMU as a security boundary. + +We should really fix the crossing-a-page-boundary code for x86. +I believe we do get it correct for ARM Thumb instructions. + +thanks +-- PMM + +On Mon, Mar 20, 2017 at 10:46 AM, Peter Maydell wrote: +> +On 20 March 2017 at 14:36, Jann Horn <address@hidden> wrote: +> +> This is an issue in QEMU's system emulation for X86 in TCG mode. +> +> The issue permits an attacker who can execute code in guest ring 3 +> +> with normal user privileges to inject code into other processes that +> +> are running in guest ring 3, in particular root-owned processes. +> +> +> I am sending this to qemu-devel because a QEMU security contact +> +> told me that QEMU does not consider privilege escalation inside a +> +> TCG VM to be a security concern. +> +> +Correct; it's just a bug. Don't trust TCG QEMU as a security boundary. +> +> +We should really fix the crossing-a-page-boundary code for x86. +> +I believe we do get it correct for ARM Thumb instructions. +How about doing the instruction size check as follows? + +diff --git a/target/i386/translate.c b/target/i386/translate.c +index 72c1b03a2a..94cf3da719 100644 +--- a/target/i386/translate.c ++++ b/target/i386/translate.c +@@ -8235,6 +8235,10 @@ static target_ulong disas_insn(CPUX86State +*env, DisasContext *s, + default: + goto unknown_op; + } ++ if (s->pc - pc_start > 15) { ++ s->pc = pc_start; ++ goto illegal_op; ++ } + return s->pc; + illegal_op: + gen_illegal_opcode(s); + +Thanks, +-- +Pranith + +On 22 March 2017 at 14:55, Pranith Kumar <address@hidden> wrote: +> +On Mon, Mar 20, 2017 at 10:46 AM, Peter Maydell wrote: +> +> On 20 March 2017 at 14:36, Jann Horn <address@hidden> wrote: +> +>> This is an issue in QEMU's system emulation for X86 in TCG mode. +> +>> The issue permits an attacker who can execute code in guest ring 3 +> +>> with normal user privileges to inject code into other processes that +> +>> are running in guest ring 3, in particular root-owned processes. +> +> +> +>> I am sending this to qemu-devel because a QEMU security contact +> +>> told me that QEMU does not consider privilege escalation inside a +> +>> TCG VM to be a security concern. +> +> +> +> Correct; it's just a bug. Don't trust TCG QEMU as a security boundary. +> +> +> +> We should really fix the crossing-a-page-boundary code for x86. +> +> I believe we do get it correct for ARM Thumb instructions. +> +> +How about doing the instruction size check as follows? +> +> +diff --git a/target/i386/translate.c b/target/i386/translate.c +> +index 72c1b03a2a..94cf3da719 100644 +> +--- a/target/i386/translate.c +> ++++ b/target/i386/translate.c +> +@@ -8235,6 +8235,10 @@ static target_ulong disas_insn(CPUX86State +> +*env, DisasContext *s, +> +default: +> +goto unknown_op; +> +} +> ++ if (s->pc - pc_start > 15) { +> ++ s->pc = pc_start; +> ++ goto illegal_op; +> ++ } +> +return s->pc; +> +illegal_op: +> +gen_illegal_opcode(s); +This doesn't look right because it means we'll check +only after we've emitted all the code to do the +instruction operation, so the effect will be +"execute instruction, then take illegal-opcode +exception". + +We should check what the x86 architecture spec actually +says and implement that. + +thanks +-- PMM + +On Wed, Mar 22, 2017 at 11:04 AM, Peter Maydell +<address@hidden> wrote: +> +> +> +> How about doing the instruction size check as follows? +> +> +> +> diff --git a/target/i386/translate.c b/target/i386/translate.c +> +> index 72c1b03a2a..94cf3da719 100644 +> +> --- a/target/i386/translate.c +> +> +++ b/target/i386/translate.c +> +> @@ -8235,6 +8235,10 @@ static target_ulong disas_insn(CPUX86State +> +> *env, DisasContext *s, +> +> default: +> +> goto unknown_op; +> +> } +> +> + if (s->pc - pc_start > 15) { +> +> + s->pc = pc_start; +> +> + goto illegal_op; +> +> + } +> +> return s->pc; +> +> illegal_op: +> +> gen_illegal_opcode(s); +> +> +This doesn't look right because it means we'll check +> +only after we've emitted all the code to do the +> +instruction operation, so the effect will be +> +"execute instruction, then take illegal-opcode +> +exception". +> +The pc is restored to original address (s->pc = pc_start), so the +exception will overwrite the generated illegal instruction and will be +executed first. + +But yes, it's better to follow the architecture manual. + +Thanks, +-- +Pranith + +On 22 March 2017 at 15:14, Pranith Kumar <address@hidden> wrote: +> +On Wed, Mar 22, 2017 at 11:04 AM, Peter Maydell +> +<address@hidden> wrote: +> +> This doesn't look right because it means we'll check +> +> only after we've emitted all the code to do the +> +> instruction operation, so the effect will be +> +> "execute instruction, then take illegal-opcode +> +> exception". +> +The pc is restored to original address (s->pc = pc_start), so the +> +exception will overwrite the generated illegal instruction and will be +> +executed first. +s->pc is the guest PC -- moving that backwards will +not do anything about the generated TCG IR that's +already been written. You'd need to rewind the +write pointer in the IR stream, which there is +no support for doing AFAIK. + +thanks +-- PMM + +On Wed, Mar 22, 2017 at 11:21 AM, Peter Maydell +<address@hidden> wrote: +> +On 22 March 2017 at 15:14, Pranith Kumar <address@hidden> wrote: +> +> On Wed, Mar 22, 2017 at 11:04 AM, Peter Maydell +> +> <address@hidden> wrote: +> +>> This doesn't look right because it means we'll check +> +>> only after we've emitted all the code to do the +> +>> instruction operation, so the effect will be +> +>> "execute instruction, then take illegal-opcode +> +>> exception". +> +> +> The pc is restored to original address (s->pc = pc_start), so the +> +> exception will overwrite the generated illegal instruction and will be +> +> executed first. +> +> +s->pc is the guest PC -- moving that backwards will +> +not do anything about the generated TCG IR that's +> +already been written. You'd need to rewind the +> +write pointer in the IR stream, which there is +> +no support for doing AFAIK. +Ah, OK. Thanks for the explanation. May be we should check the size of +the instruction while decoding the prefixes and error out once we +exceed the limit. We would not generate any IR code. + +-- +Pranith + +On 03/23/2017 02:29 AM, Pranith Kumar wrote: +On Wed, Mar 22, 2017 at 11:21 AM, Peter Maydell +<address@hidden> wrote: +On 22 March 2017 at 15:14, Pranith Kumar <address@hidden> wrote: +On Wed, Mar 22, 2017 at 11:04 AM, Peter Maydell +<address@hidden> wrote: +This doesn't look right because it means we'll check +only after we've emitted all the code to do the +instruction operation, so the effect will be +"execute instruction, then take illegal-opcode +exception". +The pc is restored to original address (s->pc = pc_start), so the +exception will overwrite the generated illegal instruction and will be +executed first. +s->pc is the guest PC -- moving that backwards will +not do anything about the generated TCG IR that's +already been written. You'd need to rewind the +write pointer in the IR stream, which there is +no support for doing AFAIK. +Ah, OK. Thanks for the explanation. May be we should check the size of +the instruction while decoding the prefixes and error out once we +exceed the limit. We would not generate any IR code. +Yes. +It would not enforce a true limit of 15 bytes, since you can't know that until +you've done the rest of the decode. But you'd be able to say that no more than +14 prefix + 1 opc + 6 modrm+sib+ofs + 4 immediate = 25 bytes is used. +Which does fix the bug. + + +r~ + +On 22/03/2017 21:01, Richard Henderson wrote: +> +> +> +> Ah, OK. Thanks for the explanation. May be we should check the size of +> +> the instruction while decoding the prefixes and error out once we +> +> exceed the limit. We would not generate any IR code. +> +> +Yes. +> +> +It would not enforce a true limit of 15 bytes, since you can't know that +> +until you've done the rest of the decode. But you'd be able to say that +> +no more than 14 prefix + 1 opc + 6 modrm+sib+ofs + 4 immediate = 25 +> +bytes is used. +> +> +Which does fix the bug. +Yeah, that would work for 2.9 if somebody wants to put together a patch. + Ensuring that all instruction fetching happens before translation side +effects is a little harder, but perhaps it's also the opportunity to get +rid of s->rip_offset which is a little ugly. + +Paolo + +On Thu, Mar 23, 2017 at 6:27 AM, Paolo Bonzini <address@hidden> wrote: +> +> +> +On 22/03/2017 21:01, Richard Henderson wrote: +> +>> +> +>> Ah, OK. Thanks for the explanation. May be we should check the size of +> +>> the instruction while decoding the prefixes and error out once we +> +>> exceed the limit. We would not generate any IR code. +> +> +> +> Yes. +> +> +> +> It would not enforce a true limit of 15 bytes, since you can't know that +> +> until you've done the rest of the decode. But you'd be able to say that +> +> no more than 14 prefix + 1 opc + 6 modrm+sib+ofs + 4 immediate = 25 +> +> bytes is used. +> +> +> +> Which does fix the bug. +> +> +Yeah, that would work for 2.9 if somebody wants to put together a patch. +> +Ensuring that all instruction fetching happens before translation side +> +effects is a little harder, but perhaps it's also the opportunity to get +> +rid of s->rip_offset which is a little ugly. +How about the following? + +diff --git a/target/i386/translate.c b/target/i386/translate.c +index 72c1b03a2a..67c58b8900 100644 +--- a/target/i386/translate.c ++++ b/target/i386/translate.c +@@ -4418,6 +4418,11 @@ static target_ulong disas_insn(CPUX86State +*env, DisasContext *s, + s->vex_l = 0; + s->vex_v = 0; + next_byte: ++ /* The prefixes can atmost be 14 bytes since x86 has an upper ++ limit of 15 bytes for the instruction */ ++ if (s->pc - pc_start > 14) { ++ goto illegal_op; ++ } + b = cpu_ldub_code(env, s->pc); + s->pc++; + /* Collect prefixes. */ + +-- +Pranith + +On 23/03/2017 17:50, Pranith Kumar wrote: +> +On Thu, Mar 23, 2017 at 6:27 AM, Paolo Bonzini <address@hidden> wrote: +> +> +> +> +> +> On 22/03/2017 21:01, Richard Henderson wrote: +> +>>> +> +>>> Ah, OK. Thanks for the explanation. May be we should check the size of +> +>>> the instruction while decoding the prefixes and error out once we +> +>>> exceed the limit. We would not generate any IR code. +> +>> +> +>> Yes. +> +>> +> +>> It would not enforce a true limit of 15 bytes, since you can't know that +> +>> until you've done the rest of the decode. But you'd be able to say that +> +>> no more than 14 prefix + 1 opc + 6 modrm+sib+ofs + 4 immediate = 25 +> +>> bytes is used. +> +>> +> +>> Which does fix the bug. +> +> +> +> Yeah, that would work for 2.9 if somebody wants to put together a patch. +> +> Ensuring that all instruction fetching happens before translation side +> +> effects is a little harder, but perhaps it's also the opportunity to get +> +> rid of s->rip_offset which is a little ugly. +> +> +How about the following? +> +> +diff --git a/target/i386/translate.c b/target/i386/translate.c +> +index 72c1b03a2a..67c58b8900 100644 +> +--- a/target/i386/translate.c +> ++++ b/target/i386/translate.c +> +@@ -4418,6 +4418,11 @@ static target_ulong disas_insn(CPUX86State +> +*env, DisasContext *s, +> +s->vex_l = 0; +> +s->vex_v = 0; +> +next_byte: +> ++ /* The prefixes can atmost be 14 bytes since x86 has an upper +> ++ limit of 15 bytes for the instruction */ +> ++ if (s->pc - pc_start > 14) { +> ++ goto illegal_op; +> ++ } +> +b = cpu_ldub_code(env, s->pc); +> +s->pc++; +> +/* Collect prefixes. */ +Please make the comment more verbose, based on Richard's remark. We +should apply it to 2.9. + +Also, QEMU usually formats comments with stars on every line. + +Paolo + +On Thu, Mar 23, 2017 at 1:37 PM, Paolo Bonzini <address@hidden> wrote: +> +> +> +On 23/03/2017 17:50, Pranith Kumar wrote: +> +> On Thu, Mar 23, 2017 at 6:27 AM, Paolo Bonzini <address@hidden> wrote: +> +>> +> +>> +> +>> On 22/03/2017 21:01, Richard Henderson wrote: +> +>>>> +> +>>>> Ah, OK. Thanks for the explanation. May be we should check the size of +> +>>>> the instruction while decoding the prefixes and error out once we +> +>>>> exceed the limit. We would not generate any IR code. +> +>>> +> +>>> Yes. +> +>>> +> +>>> It would not enforce a true limit of 15 bytes, since you can't know that +> +>>> until you've done the rest of the decode. But you'd be able to say that +> +>>> no more than 14 prefix + 1 opc + 6 modrm+sib+ofs + 4 immediate = 25 +> +>>> bytes is used. +> +>>> +> +>>> Which does fix the bug. +> +>> +> +>> Yeah, that would work for 2.9 if somebody wants to put together a patch. +> +>> Ensuring that all instruction fetching happens before translation side +> +>> effects is a little harder, but perhaps it's also the opportunity to get +> +>> rid of s->rip_offset which is a little ugly. +> +> +> +> How about the following? +> +> +> +> diff --git a/target/i386/translate.c b/target/i386/translate.c +> +> index 72c1b03a2a..67c58b8900 100644 +> +> --- a/target/i386/translate.c +> +> +++ b/target/i386/translate.c +> +> @@ -4418,6 +4418,11 @@ static target_ulong disas_insn(CPUX86State +> +> *env, DisasContext *s, +> +> s->vex_l = 0; +> +> s->vex_v = 0; +> +> next_byte: +> +> + /* The prefixes can atmost be 14 bytes since x86 has an upper +> +> + limit of 15 bytes for the instruction */ +> +> + if (s->pc - pc_start > 14) { +> +> + goto illegal_op; +> +> + } +> +> b = cpu_ldub_code(env, s->pc); +> +> s->pc++; +> +> /* Collect prefixes. */ +> +> +Please make the comment more verbose, based on Richard's remark. We +> +should apply it to 2.9. +> +> +Also, QEMU usually formats comments with stars on every line. +OK. I'll send a proper patch with updated comment. + +Thanks, +-- +Pranith + diff --git a/results/classifier/zero-shot/108/permissions/14887122 b/results/classifier/zero-shot/108/permissions/14887122 new file mode 100644 index 000000000..ae50ba435 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/14887122 @@ -0,0 +1,268 @@ +permissions: 0.964 +files: 0.944 +debug: 0.934 +semantic: 0.928 +device: 0.919 +PID: 0.914 +socket: 0.914 +graphic: 0.910 +performance: 0.897 +other: 0.890 +vnc: 0.871 +network: 0.855 +boot: 0.831 +KVM: 0.814 + +[BUG][RFC] CPR transfer Issues: Socket permissions and PID files + +Hello, + +While testing CPR transfer I encountered two issues. The first is that the +transfer fails when running with pidfiles due to the destination qemu process +attempting to create the pidfile while it is still locked by the source +process. The second is that the transfer fails when running with the -run-with +user=$USERID parameter. This is because the destination qemu process creates +the UNIX sockets used for the CPR transfer before dropping to the lower +permissioned user, which causes them to be owned by the original user. The +source qemu process then does not have permission to connect to it because it +is already running as the lesser permissioned user. + +Reproducing the first issue: + +Create a source and destination qemu instance associated with the same VM where +both processes have the -pidfile parameter passed on the command line. You +should see the following error on the command line of the second process: + +qemu-system-x86_64: cannot create PID file: Cannot lock pid file: Resource +temporarily unavailable + +Reproducing the second issue: + +Create a source and destination qemu instance associated with the same VM where +both processes have -run-with user=$USERID passed on the command line, where +$USERID is a different user from the one launching the processes. Then attempt +a CPR transfer using UNIX sockets for the main and cpr sockets. You should +receive the following error via QMP: +{"error": {"class": "GenericError", "desc": "Failed to connect to 'cpr.sock': +Permission denied"}} + +I provided a minimal patch that works around the second issue. + +Thank you, +Ben Chaney + +--- +include/system/os-posix.h | 4 ++++ +os-posix.c | 8 -------- +util/qemu-sockets.c | 21 +++++++++++++++++++++ +3 files changed, 25 insertions(+), 8 deletions(-) + +diff --git a/include/system/os-posix.h b/include/system/os-posix.h +index ce5b3bccf8..2a414a914a 100644 +--- a/include/system/os-posix.h ++++ b/include/system/os-posix.h +@@ -55,6 +55,10 @@ void os_setup_limits(void); +void os_setup_post(void); +int os_mlock(bool on_fault); + ++extern struct passwd *user_pwd; ++extern uid_t user_uid; ++extern gid_t user_gid; ++ +/** +* qemu_alloc_stack: +* @sz: pointer to a size_t holding the requested usable stack size +diff --git a/os-posix.c b/os-posix.c +index 52925c23d3..9369b312a0 100644 +--- a/os-posix.c ++++ b/os-posix.c +@@ -86,14 +86,6 @@ void os_set_proc_name(const char *s) +} + + +-/* +- * Must set all three of these at once. +- * Legal combinations are unset by name by uid +- */ +-static struct passwd *user_pwd; /* NULL non-NULL NULL */ +-static uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */ +-static gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */ +- +/* +* Prepare to change user ID. user_id can be one of 3 forms: +* - a username, in which case user ID will be changed to its uid, +diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c +index 77477c1cd5..987977ead9 100644 +--- a/util/qemu-sockets.c ++++ b/util/qemu-sockets.c +@@ -871,6 +871,14 @@ static bool saddr_is_tight(UnixSocketAddress *saddr) +#endif +} + ++/* ++ * Must set all three of these at once. ++ * Legal combinations are unset by name by uid ++ */ ++struct passwd *user_pwd; /* NULL non-NULL NULL */ ++uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */ ++gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */ ++ +static int unix_listen_saddr(UnixSocketAddress *saddr, +int num, +Error **errp) +@@ -947,6 +955,19 @@ static int unix_listen_saddr(UnixSocketAddress *saddr, +error_setg_errno(errp, errno, "Failed to bind socket to %s", path); +goto err; +} ++ if (user_pwd) { ++ if (chown(un.sun_path, user_pwd->pw_uid, user_pwd->pw_gid) < 0) { ++ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", +path); ++ goto err; ++ } ++ } ++ else if (user_uid != -1 && user_gid != -1) { ++ if (chown(un.sun_path, user_uid, user_gid) < 0) { ++ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", +path); ++ goto err; ++ } ++ } ++ +if (listen(sock, num) < 0) { +error_setg_errno(errp, errno, "Failed to listen on socket"); +goto err; +-- +2.40.1 + +Thank you Ben. I appreciate you testing CPR and shaking out the bugs. +I will study these and propose patches. + +My initial reaction to the pidfile issue is that the orchestration layer must +pass a different filename when starting the destination qemu instance. When +using live update without containers, these types of resource conflicts in the +global namespaces are a known issue. + +- Steve + +On 3/14/2025 2:33 PM, Chaney, Ben wrote: +Hello, + +While testing CPR transfer I encountered two issues. The first is that the +transfer fails when running with pidfiles due to the destination qemu process +attempting to create the pidfile while it is still locked by the source +process. The second is that the transfer fails when running with the -run-with +user=$USERID parameter. This is because the destination qemu process creates +the UNIX sockets used for the CPR transfer before dropping to the lower +permissioned user, which causes them to be owned by the original user. The +source qemu process then does not have permission to connect to it because it +is already running as the lesser permissioned user. + +Reproducing the first issue: + +Create a source and destination qemu instance associated with the same VM where +both processes have the -pidfile parameter passed on the command line. You +should see the following error on the command line of the second process: + +qemu-system-x86_64: cannot create PID file: Cannot lock pid file: Resource +temporarily unavailable + +Reproducing the second issue: + +Create a source and destination qemu instance associated with the same VM where +both processes have -run-with user=$USERID passed on the command line, where +$USERID is a different user from the one launching the processes. Then attempt +a CPR transfer using UNIX sockets for the main and cpr sockets. You should +receive the following error via QMP: +{"error": {"class": "GenericError", "desc": "Failed to connect to 'cpr.sock': +Permission denied"}} + +I provided a minimal patch that works around the second issue. + +Thank you, +Ben Chaney + +--- +include/system/os-posix.h | 4 ++++ +os-posix.c | 8 -------- +util/qemu-sockets.c | 21 +++++++++++++++++++++ +3 files changed, 25 insertions(+), 8 deletions(-) + +diff --git a/include/system/os-posix.h b/include/system/os-posix.h +index ce5b3bccf8..2a414a914a 100644 +--- a/include/system/os-posix.h ++++ b/include/system/os-posix.h +@@ -55,6 +55,10 @@ void os_setup_limits(void); +void os_setup_post(void); +int os_mlock(bool on_fault); + ++extern struct passwd *user_pwd; ++extern uid_t user_uid; ++extern gid_t user_gid; ++ +/** +* qemu_alloc_stack: +* @sz: pointer to a size_t holding the requested usable stack size +diff --git a/os-posix.c b/os-posix.c +index 52925c23d3..9369b312a0 100644 +--- a/os-posix.c ++++ b/os-posix.c +@@ -86,14 +86,6 @@ void os_set_proc_name(const char *s) +} + + +-/* +- * Must set all three of these at once. +- * Legal combinations are unset by name by uid +- */ +-static struct passwd *user_pwd; /* NULL non-NULL NULL */ +-static uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */ +-static gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */ +- +/* +* Prepare to change user ID. user_id can be one of 3 forms: +* - a username, in which case user ID will be changed to its uid, +diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c +index 77477c1cd5..987977ead9 100644 +--- a/util/qemu-sockets.c ++++ b/util/qemu-sockets.c +@@ -871,6 +871,14 @@ static bool saddr_is_tight(UnixSocketAddress *saddr) +#endif +} + ++/* ++ * Must set all three of these at once. ++ * Legal combinations are unset by name by uid ++ */ ++struct passwd *user_pwd; /* NULL non-NULL NULL */ ++uid_t user_uid = (uid_t)-1; /* -1 -1 >=0 */ ++gid_t user_gid = (gid_t)-1; /* -1 -1 >=0 */ ++ +static int unix_listen_saddr(UnixSocketAddress *saddr, +int num, +Error **errp) +@@ -947,6 +955,19 @@ static int unix_listen_saddr(UnixSocketAddress *saddr, +error_setg_errno(errp, errno, "Failed to bind socket to %s", path); +goto err; +} ++ if (user_pwd) { ++ if (chown(un.sun_path, user_pwd->pw_uid, user_pwd->pw_gid) < 0) { ++ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", +path); ++ goto err; ++ } ++ } ++ else if (user_uid != -1 && user_gid != -1) { ++ if (chown(un.sun_path, user_uid, user_gid) < 0) { ++ error_setg_errno(errp, errno, "Failed to change permissions on socket %s", +path); ++ goto err; ++ } ++ } ++ +if (listen(sock, num) < 0) { +error_setg_errno(errp, errno, "Failed to listen on socket"); +goto err; +-- +2.40.1 + diff --git a/results/classifier/zero-shot/108/permissions/1490853 b/results/classifier/zero-shot/108/permissions/1490853 new file mode 100644 index 000000000..b56c1ee4c --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1490853 @@ -0,0 +1,236 @@ +permissions: 0.936 +vnc: 0.924 +other: 0.924 +boot: 0.921 +KVM: 0.916 +files: 0.906 +performance: 0.905 +device: 0.903 +debug: 0.897 +graphic: 0.892 +socket: 0.892 +network: 0.890 +semantic: 0.881 +PID: 0.866 + +qemu windows guest hangs on 100% cpu usage + +hi: +I have two VM , one is winXP Prefessional SP3 32bit, another on is WindowsServer2008 Enterprise SP2 64bit. +When I hot reboot winXP in guest OS, it'll hangs on progress bar, and all the vcpu thread in qemu is 100% usage. +I try to rebuild kvm and add some debug info , I found the cpu exit reason is EXIT_REASON_PAUSE_INSTRUCTION. +It seems like all the vcpu always in spinlock waiting. I not sure it's qemu's bug or kvm's. +Any help would be appreciated. + +How reproducible: +WinXP: seems always. +WinServer2008: rare. + +Steps to Reproduce: +winXP: 1. hot reboot the xp guest os, hot reboot is necessary. +WinServer2008: not sure, I didn't do anything, it just happened. + +The different between WinXP and WInServer2008: +1. When WinXP hangs, the boot progress bar is rolling, I think that vnc is work fine. +2. When WinServer2008 hangs, the vnc show the last screen and the screen won't change anything include system time. +3. When the VM hangs , if I execute "virsh suspend vm-name" and "virsh resume vm-name", the WinServer2008 will change to normal , and work fine not hangs anymore. But WinXP not change anything, still hangs. + +qemu version: +QEMU emulator version 1.5.0, Copyright (c) 2003-2008 Fabrice Bellard +host info: +Ubuntu 12.04 LTS \n \l +Linux cvknode2026 3.13.6 #1 SMP Fri Dec 12 09:17:35 CST 2014 x86_64 x86_64 x86_64 GNU/Linux + + + qemu command line (guest OS XP): +root 7124 1178 7.6 7750360 3761644 ? Sl 14:02 435:23 /usr/bin/kvm -name x -S -machine pc-i440fx-1.5,accel=kvm,usb=off,system=windows -cpu qemu64,hv_relaxed,hv_spinlocks=0x2000 -m 6144 -smp 12,maxcpus=72,sockets=12,cores=6,threads=1 -uuid d3832129-f77d-4b21-bbf7-fd337f53e572 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/x.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=ehci,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/vms/images/sn1-of-ff.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=directsync -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-1,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -netdev tap,fd=24,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=0c:da:41:1d:f8:40,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/x.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0 -vnc 0.0.0.0:0 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 + + + all qemu thread (guest OS XP): +root@cvknode2026:/proc/7124/task# top -d 1 -H -p 7124 +top - 14:37:05 up 7 days, 4:07, 1 user, load average: 10.71, 10.90, 10.19 +Tasks: 14 total, 12 running, 2 sleeping, 0 stopped, 0 zombie +Cpu(s): 38.8%us, 11.2%sy, 0.0%ni, 50.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st +Mem: 49159888k total, 35665128k used, 13494760k free, 436312k buffers +Swap: 8803324k total, 0k used, 8803324k free, 28595100k cached + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P SWAP WCHAN COMMAND + 7130 root 20 0 7568m 3.6g 6628 R 101 7.7 33:43.48 3 3.8g - kvm + 7132 root 20 0 7568m 3.6g 6628 R 101 7.7 33:43.13 1 3.8g - kvm + 7133 root 20 0 7568m 3.6g 6628 R 101 7.7 33:42.70 6 3.8g - kvm + 7135 root 20 0 7568m 3.6g 6628 R 101 7.7 33:42.33 11 3.8g - kvm + 7137 root 20 0 7568m 3.6g 6628 R 101 7.7 33:42.59 17 3.8g - kvm + 7126 root 20 0 7568m 3.6g 6628 R 100 7.7 34:06.76 4 3.8g - kvm + 7127 root 20 0 7568m 3.6g 6628 R 100 7.7 33:44.14 8 3.8g - kvm + 7128 root 20 0 7568m 3.6g 6628 R 100 7.7 33:43.64 13 3.8g - kvm + 7129 root 20 0 7568m 3.6g 6628 R 100 7.7 33:43.64 7 3.8g - kvm + 7131 root 20 0 7568m 3.6g 6628 R 100 7.7 33:44.24 10 3.8g - kvm + 7134 root 20 0 7568m 3.6g 6628 R 100 7.7 33:42.47 12 3.8g - kvm + 7136 root 20 0 7568m 3.6g 6628 R 100 7.7 33:42.16 2 3.8g - kvm + 7124 root 20 0 7568m 3.6g 6628 S 1 7.7 0:30.65 14 3.8g poll_sche kvm + 7139 root 20 0 7568m 3.6g 6628 S 0 7.7 0:01.71 14 3.8g futex_wai kvm + +all thread's kernel stack (guest OS XP): +root@cvknode2026:/proc/7124/task# cat 7130/stack +[<ffffffffa02b1fa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7132/stack +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7133/stack +[<ffffffffa02b1fa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7135/stack +[<ffffffffa02b1fa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffa02b6788>] vmx_vcpu_run+0x88/0x760 [kvm_intel] +[<ffffffffa0413aec>] __vcpu_run+0x63c/0xc30 [kvm] +[<ffffffffa0414188>] kvm_arch_vcpu_ioctl_run+0xa8/0x270 [kvm] +[<ffffffffa03fc042>] kvm_vcpu_ioctl+0x512/0x6d0 [kvm] +[<ffffffff811d4326>] do_vfs_ioctl+0x86/0x4f0 +[<ffffffff811d4821>] SyS_ioctl+0x91/0xb0 +[<ffffffff817610ad>] system_call_fastpath+0x1a/0x1f +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7137/stack +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7126/stack +[<ffffffffa02b1fa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7127/stack +[<ffffffffa02b74f6>] handle_pause+0x16/0x30 [kvm_intel] +[<ffffffffa02ba0d4>] vmx_handle_exit+0x94/0x8b0 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7128/stack +[<ffffffffa02b1fa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7129/stack +[<ffffffffa02b1fa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7131/stack +[<ffffffffa02b1fa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7134/stack +[<ffffffffa02b74fe>] handle_pause+0x1e/0x30 [kvm_intel] +[<ffffffffa02ba0d4>] vmx_handle_exit+0x94/0x8b0 [kvm_intel] +[<ffffffffa0413aec>] __vcpu_run+0x63c/0xc30 [kvm] +[<ffffffffa0414188>] kvm_arch_vcpu_ioctl_run+0xa8/0x270 [kvm] +[<ffffffffa03fc042>] kvm_vcpu_ioctl+0x512/0x6d0 [kvm] +[<ffffffff811d4326>] do_vfs_ioctl+0x86/0x4f0 +[<ffffffff811d4821>] SyS_ioctl+0x91/0xb0 +[<ffffffff817610ad>] system_call_fastpath+0x1a/0x1f +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7136/stack +[<ffffffffa02b1fa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7124/stack +[<ffffffff811d50c9>] poll_schedule_timeout+0x49/0x70 +[<ffffffff811d678a>] do_sys_poll+0x50a/0x590 +[<ffffffff811d68eb>] SyS_poll+0x6b/0x100 +[<ffffffff817610ad>] system_call_fastpath+0x1a/0x1f +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvknode2026:/proc/7124/task# cat 7139/stack +[<ffffffff810daf77>] futex_wait_queue_me+0xd7/0x150 +[<ffffffff810dc087>] futex_wait+0x1a7/0x2c0 +[<ffffffff810ddc14>] do_futex+0x334/0xb70 +[<ffffffff810de592>] SyS_futex+0x142/0x1a0 +[<ffffffff817610ad>] system_call_fastpath+0x1a/0x1f +[<ffffffffffffffff>] 0xffffffffffffffff + + qemu command line (guest OS WinServer2008): +root 25258 996 21.5 21174412 14181580 ? Sl Aug27 73740:11 /usr/bin/kvm -name zjx_1-clone -S -machine pc-i440fx-1.5,accel=kvm,usb=off,system=windows -cpu qemu64,hv_relaxed,hv_spinlocks=0x2000 -m 16384 -smp 12,maxcpus=72,sockets=12,cores=6,threads=1 -uuid 8c8b9abf-e9a6-4c3e-93cd-137a9550e593 -no-user-config -nodefaults -chardev so +cket,id=charmonitor,path=/var/lib/libvirt/qemu/zjx_1-clone.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=ehci,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus +=pci.0,addr=0x5 -drive file=/vms/aaa/zjx_1-clone.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=directsync -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/vms/isos/virtio-win2008R2.vfd,if=none,id=drive-fdc0-0-0,readonly=on,format=raw,cache=directsync -global isa-fdc.driveA=drive-fdc0-0-0 -drive if=none,id=drive-ide0-1-1,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=0c:da:41:1d:b6:47,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-ser +ial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/zjx_1-clone.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0 -vnc 0.0.0.0:3 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 + + all qemu thread (guest OS WinServer2008): + top -d 1 -H -p 25258 +top - 14:53:37 up 24 days, 21:27, 2 users, load average: 19.12, 20.56, 20.20 +Tasks: 14 total, 13 running, 1 sleeping, 0 stopped, 0 zombie +Cpu(s): 48.1%us, 18.2%sy, 0.0%ni, 33.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st +Mem: 65674944k total, 64651012k used, 1023932k free, 194608k buffers +Swap: 8803324k total, 4140324k used, 4663000k free, 363712k cached + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P WCHAN COMMAND +25281 root 20 0 20.2g 13g 4020 R 157 21.6 5864:12 14 - kvm +25284 root 20 0 20.2g 13g 4020 R 155 21.6 5863:02 4 - kvm +25294 root 20 0 20.2g 13g 4020 R 153 21.6 5851:59 3 - kvm +25287 root 20 0 20.2g 13g 4020 R 152 21.6 5861:20 15 - kvm +25299 root 20 0 20.2g 13g 4020 R 152 21.6 5847:14 1 - kvm +25258 root 20 0 20.2g 13g 4020 R 122 21.6 3372:41 13 - kvm +25269 root 20 0 20.2g 13g 4020 R 101 21.6 5929:42 5 - kvm +25301 root 20 0 20.2g 13g 4020 R 101 21.6 5847:26 10 - kvm +25292 root 20 0 20.2g 13g 4020 R 100 21.6 5853:18 7 - kvm +25297 root 20 0 20.2g 13g 4020 R 100 21.6 5843:37 16 - kvm +25272 root 20 0 20.2g 13g 4020 R 98 21.6 5872:52 2 - kvm +25277 root 20 0 20.2g 13g 4020 R 93 21.6 5878:21 0 - kvm +25290 root 20 0 20.2g 13g 4020 R 51 21.6 5863:15 8 - kvm +25314 root 20 0 20.2g 13g 4020 S 0 21.6 0:41.42 1 futex_wai kvm + +all thread's kernel stack (guest OS WinServer2008): +root@cvk11:/proc/25258/task# cat 25281/stack +[<ffffffffa03cdfa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffa03d60d4>] vmx_handle_exit+0x94/0x8b0 [kvm_intel] +[<ffffffffa062cbb4>] __vcpu_run+0x704/0xc30 [kvm] +[<ffffffffa062d188>] kvm_arch_vcpu_ioctl_run+0xa8/0x270 [kvm] +[<ffffffffa0615042>] kvm_vcpu_ioctl+0x512/0x6d0 [kvm] +[<ffffffff811d4326>] do_vfs_ioctl+0x86/0x4f0 +[<ffffffff811d4821>] SyS_ioctl+0x91/0xb0 +[<ffffffff817610ad>] system_call_fastpath+0x1a/0x1f +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25284/stack +[<ffffffffa0613537>] kvm_vcpu_yield_to+0x47/0xa0 [kvm] +[<ffffffffa06136ab>] kvm_vcpu_on_spin+0x11b/0x150 [kvm] +[<ffffffffa03cdfa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25294/stack +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25287/stack +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25299/stack +[<ffffffffa03d34f6>] handle_pause+0x16/0x30 [kvm_intel] +[<ffffffffa03d60d4>] vmx_handle_exit+0x94/0x8b0 [kvm_intel] +[<ffffffffa062caec>] __vcpu_run+0x63c/0xc30 [kvm] +[<ffffffffa062d188>] kvm_arch_vcpu_ioctl_run+0xa8/0x270 [kvm] +[<ffffffffa0615042>] kvm_vcpu_ioctl+0x512/0x6d0 [kvm] +[<ffffffff811d4326>] do_vfs_ioctl+0x86/0x4f0 +[<ffffffff811d4821>] SyS_ioctl+0x91/0xb0 +[<ffffffff817610ad>] system_call_fastpath+0x1a/0x1f +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25258/stack +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25269/stack +[<ffffffffa03d34fe>] handle_pause+0x1e/0x30 [kvm_intel] +[<ffffffffa03d60d4>] vmx_handle_exit+0x94/0x8b0 [kvm_intel] +[<ffffffffa062caec>] __vcpu_run+0x63c/0xc30 [kvm] +[<ffffffffa062d188>] kvm_arch_vcpu_ioctl_run+0xa8/0x270 [kvm] +[<ffffffffa0615042>] kvm_vcpu_ioctl+0x512/0x6d0 [kvm] +[<ffffffff811d4326>] do_vfs_ioctl+0x86/0x4f0 +[<ffffffff811d4821>] SyS_ioctl+0x91/0xb0 +[<ffffffff817610ad>] system_call_fastpath+0x1a/0x1f +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25301/stack +[<ffffffffa03d34fe>] handle_pause+0x1e/0x30 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25292/stack +[<ffffffffa03cdfa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25297/stack +[<ffffffffa03cdfa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25272/stack +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25277/stack +[<ffffffffa03cdfa3>] clear_atomic_switch_msr+0x133/0x170 [kvm_intel] +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25290/stack +[<ffffffffffffffff>] 0xffffffffffffffff +root@cvk11:/proc/25258/task# cat 25314/stack +[<ffffffff810daf77>] futex_wait_queue_me+0xd7/0x150 +[<ffffffff810dc087>] futex_wait+0x1a7/0x2c0 +[<ffffffff810ddc14>] do_futex+0x334/0xb70 +[<ffffffff810de592>] SyS_futex+0x142/0x1a0 +[<ffffffff817610ad>] system_call_fastpath+0x1a/0x1f +[<ffffffffffffffff>] 0xffffffffffffffff + +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/zero-shot/108/permissions/1505 b/results/classifier/zero-shot/108/permissions/1505 new file mode 100644 index 000000000..6bde8051e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1505 @@ -0,0 +1,16 @@ +permissions: 0.955 +network: 0.714 +device: 0.697 +performance: 0.643 +other: 0.415 +boot: 0.362 +semantic: 0.361 +socket: 0.283 +KVM: 0.252 +PID: 0.239 +vnc: 0.212 +graphic: 0.193 +files: 0.067 +debug: 0.030 + +guest agent: add --allow-rpcs / whitelist mode diff --git a/results/classifier/zero-shot/108/permissions/1525 b/results/classifier/zero-shot/108/permissions/1525 new file mode 100644 index 000000000..7da79b794 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1525 @@ -0,0 +1,93 @@ +semantic: 0.967 +permissions: 0.966 +graphic: 0.962 +debug: 0.960 +other: 0.937 +device: 0.935 +socket: 0.928 +PID: 0.909 +files: 0.905 +boot: 0.905 +performance: 0.893 +KVM: 0.856 +vnc: 0.845 +network: 0.840 + +Wrong initial value of stack pointer on AVR devices +Description of problem: +The initial value of stack pointer of AVR MCUs should be RAMEND (address of the end of their RAM), but QEMU initialize them to 0. + +`qemu-system-avr -machine help` lists 4 flavors of MCUs which are ATmega168, ATmega2560, ATmega1280, ATmega328P. According to their datasheets, the stack pointer should be initialized as follows on reset. + +- [ATmega168](https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-9365-Automotive-Microcontrollers-ATmega88-ATmega168_Datasheet.pdf#page=12): RAMEND (which is 0x04FF) +- [ATmega2560 and ATmega1280](https://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf#page=15): RAMEND (which is 0x21FF) +- [ATmega328P](https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf#page=22): RAMEND (which is 0x08FF) +Steps to reproduce: +1. Assemble the assembly code below: `avrasm2 -fI test.asm` + + ```asm + ;; test.asm + .INCLUDE "m328Pdef.inc" + + .EQU F_CPU = 16000000 + .EQU BAUD_RATE = 9600 + .EQU PRESCALE = (F_CPU / (16 * BAUD_RATE)) - 1 + + .CSEG + start: + ;; initialize USART (serial port) + LDI R16, LOW(PRESCALE) + LDI R17, HIGH(PRESCALE) + STS UBRR0L, R16 + STS UBRR0H, R17 + LDI R16, (1 << RXEN0) | (1 << TXEN0) + STS UCSR0B, R16 + + ;; Get stack pointer low byte and print it in ASCII + IN R16, SPL + LDI R17, 0x30 + ADD R16, R17 + print1: + LDS r17, UCSR0A + SBRS r17, UDRE0 + RJMP print1 + STS UDR0, r16 + + ;; Get stack pointer high byte and print it in ASCII + IN R16, SPH + LDI R17, 0x30 + ADD R16, R17 + print2: + LDS r17, UCSR0A + SBRS r17, UDRE0 + RJMP print2 + STS UDR0, r16 + + end: + RJMP end + ``` + +2. Convert it to bin file: `avr-objcopy --input-target=ihex --output-target=binary test.hex test.bin` + +3. Run it with QEMU: `qemu-system-avr -machine uno -bios test.bin -serial stdio` + +This should print 00 which means that the stack pointer is initialized to 0. +Additional information: +I examined the source code and I think that editing the function `avr_cpu_reset_hold` in `/target/avr/cpu.c` might fix this issue. This is my first time seeing QEMU source code, so I might be wrong, though. + +```c +// in /target/avr/cpu.c line 70 +static void avr_cpu_reset_hold(Object *obj) +{ + // ... + + env->rampD = 0; + env->rampX = 0; + env->rampY = 0; + env->rampZ = 0; + env->eind = 0; + env->sp = 0; // <-- change this value in accordance with board type? + + //... +} +``` diff --git a/results/classifier/zero-shot/108/permissions/1539940 b/results/classifier/zero-shot/108/permissions/1539940 new file mode 100644 index 000000000..507abf919 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1539940 @@ -0,0 +1,184 @@ +permissions: 0.936 +PID: 0.926 +graphic: 0.922 +other: 0.918 +debug: 0.913 +semantic: 0.912 +performance: 0.900 +socket: 0.899 +files: 0.891 +boot: 0.887 +vnc: 0.887 +KVM: 0.876 +device: 0.874 +network: 0.855 + +Qemu 2.5 Solaris 8 and 9 sparc hang after terminal type menu + +Qemu command: +qemu-system-sparc -nographic -monitor null -serial mon:telnet:localhost:3000,server -bios ../../Downloads/ss20_v2.25_rom -M SS-20 -hda ./solsparc -m 512 -cdrom ./sol-9-905hw-ga-sparc-dvd.iso -boot d -cpu "TI SuperSparc 60" -net nic,vlan=1,macaddr=52:54:0:12:34:56 + + +when i do disk2:d, the system loads until the terminal type menu. + +What type of terminal are you using? +1) ANSI Standard CRT +2) DEC VT52 +3) DEC VT100 +4) Heathkit 19 +5) Lear Siegler ADM31 +6) PC Console +7) Sun Command Tool +8) Sun Workstation +9) Televideo 910 +10) Televideo 925 +11) Wyse Model 50 +12) X Terminal Emulator (xterms) +13) CDE Terminal Emulator (dtterm) +14) Other +Type the number of your choice and press Return: 3 +syslog service starting. +savecore: no dump device configured +Running in command line mode + +And nothing happens after that. Anyone encountered this issue? + +On Sat, Jan 30, 2016 at 5:41 PM, Zhen Ning Lim <email address hidden> wrote: +> Public bug reported: +> +> Qemu command: +> qemu-system-sparc -nographic -monitor null -serial mon:telnet:localhost:3000,server -bios ../../Downloads/ss20_v2.25_rom -M SS-20 -hda ./solsparc -m 512 -cdrom ./sol-9-905hw-ga-sparc-dvd.iso -boot d -cpu "TI SuperSparc 60" -net nic,vlan=1,macaddr=52:54:0:12:34:56 +> +> +> when i do disk2:d, the system loads until the terminal type menu. +> +> What type of terminal are you using? +> 1) ANSI Standard CRT +> 2) DEC VT52 +> 3) DEC VT100 +> 4) Heathkit 19 +> 5) Lear Siegler ADM31 +> 6) PC Console +> 7) Sun Command Tool +> 8) Sun Workstation +> 9) Televideo 910 +> 10) Televideo 925 +> 11) Wyse Model 50 +> 12) X Terminal Emulator (xterms) +> 13) CDE Terminal Emulator (dtterm) +> 14) Other +> Type the number of your choice and press Return: 3 +> syslog service starting. +> savecore: no dump device configured +> Running in command line mode +> +> And nothing happens after that. Anyone encountered this issue? +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1539940 +> +> Title: +> Qemu 2.5 Solaris 8 and 9 sparc hang after terminal type menu +> +> Status in QEMU: +> New +> +> Bug description: +> Qemu command: +> qemu-system-sparc -nographic -monitor null -serial mon:telnet:localhost:3000,server -bios ../../Downloads/ss20_v2.25_rom -M SS-20 -hda ./solsparc -m 512 -cdrom ./sol-9-905hw-ga-sparc-dvd.iso -boot d -cpu "TI SuperSparc 60" -net nic,vlan=1,macaddr=52:54:0:12:34:56 +> +> +> when i do disk2:d, the system loads until the terminal type menu. +> +> What type of terminal are you using? +> 1) ANSI Standard CRT +> 2) DEC VT52 +> 3) DEC VT100 +> 4) Heathkit 19 +> 5) Lear Siegler ADM31 +> 6) PC Console +> 7) Sun Command Tool +> 8) Sun Workstation +> 9) Televideo 910 +> 10) Televideo 925 +> 11) Wyse Model 50 +> 12) X Terminal Emulator (xterms) +> 13) CDE Terminal Emulator (dtterm) +> 14) Other +> Type the number of your choice and press Return: 3 +> syslog service starting. +> savecore: no dump device configured +> Running in command line mode +> +> And nothing happens after that. Anyone encountered this issue? + +Does the boot log look like the "good" or the "bad" example from the link below? + +http://tyom.blogspot.de/2010/05/sx-framebuffer-emulation.html + + +-- +Regards, +Artyom Tarasenko + +SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu + + +Looks bad before i did setenv sbus-probe-list f + +Probing Memory Bank #7 64 Megabytes of DRAM +Incorrect configuration checksum; +Setting NVRAM parameters to default values. +Setting diag-switch? NVRAM parameter to true +Probing /iommu@f,e0000000/sbus@f,e0001000 at f,0 espdma esp sd st ledma le SUNW,bpp +Probing /iommu@f,e0000000/sbus@f,e0001000 at e,0 +Probing /iommu@f,e0000000/sbus@f,e0001000 at 0,0 Nothing there +Probing /iommu@f,e0000000/sbus@f,e0001000 at 1,0 Nothing there +Probing /iommu@f,e0000000/sbus@f,e0001000 at 2,0 Nothing there +Probing /iommu@f,e0000000/sbus@f,e0001000 at 3,0 Nothing there + +after: + +Probing Memory Bank #7 64 Megabytes of DRAM +Probing /iommu@f,e0000000/sbus@f,e0001000 at f,0 espdma esp sd st ledma le SUNW,bpp + +SPARCstation 20 (1 X 390Z50), No Keyboard +ROM Rev. 2.25, 512 MB memory installed, Serial #0. + + +This is no longer a problem (for sure in latest git, probably further back than that, as I installed Solaris 9/SPARC on SS-20 a few months ago): + +Type the number of your choice and press Return: 3 +syslog service starting. +savecore: no dump device configured +Running in command line mode + +Please wait while the system information is loaded... / + + + + +Welcome to the Web Start Solaris Command Line installation! + +The following questions will gather information about this system. +This information will be used to configure: + + Network + Kerberos Security + Name Service + Date and Time + Root Password + Power Management + + <Press Return to continue> + + + +This can be resolved. + diff --git a/results/classifier/zero-shot/108/permissions/1556306 b/results/classifier/zero-shot/108/permissions/1556306 new file mode 100644 index 000000000..ee35159e9 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1556306 @@ -0,0 +1,186 @@ +semantic: 0.963 +permissions: 0.960 +graphic: 0.952 +other: 0.943 +debug: 0.940 +socket: 0.931 +performance: 0.924 +PID: 0.921 +boot: 0.914 +device: 0.911 +files: 0.902 +vnc: 0.883 +network: 0.876 +KVM: 0.874 + + vhost-user: qemu stops processing packets under high load of traffic + +Description of problem: +- qemu socket becomes full, causing qemu to send incomplete +SET_VRING_CALL messages to vhost-user backend (without proper fd set in +ancillary data). +- after some time, some interrupts are lost, causing the VM to stop +transmitting packets. + +How reproducible: +Run a stress tests of a vhost-user interface using an UDP +traffic generator. Traffic generator (IXIA) was connected to 2 physical ports that are in turn connected to 2 virtio ports through a linux bridge, VM +(running linux) doing routing to forward packets between the 2 virtio ports. +When traffic reaches high pps rates of small packets, + +Actual results: +- VM stop transmitting packets + +Expected results: +- VM should never stop transmitting packets + +Additional info: +We do propose a fix at: + http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg00652.html + +for tracking, + http://git.qemu.org/?p=qemu.git;a=patch;h=5669655aafdb88a8797c74a989dd0c0ebb1349fa + +On Fri, Mar 11, 2016 at 10:51:33PM -0000, Vincent JARDIN wrote: +> for tracking, +> http://git.qemu.org/?p=qemu.git;a=patch;h=5669655aafdb88a8797c74a989dd0c0ebb1349fa +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1556306 +> +> Title: +> vhost-user: qemu stops processing packets under high load of traffic +> +> Status in QEMU: +> New + +I presume you'll also close this bu at some point? +It's fixed in upstream QEMU. + +> Bug description: +> Description of problem: +> - qemu socket becomes full, causing qemu to send incomplete +> SET_VRING_CALL messages to vhost-user backend (without proper fd set in +> ancillary data). +> - after some time, some interrupts are lost, causing the VM to stop +> transmitting packets. +> +> How reproducible: +> Run a stress tests of a vhost-user interface using an UDP +> traffic generator. Traffic generator (IXIA) was connected to 2 physical ports that are in turn connected to 2 virtio ports through a linux bridge, VM +> (running linux) doing routing to forward packets between the 2 virtio ports. +> When traffic reaches high pps rates of small packets, +> +> Actual results: +> - VM stop transmitting packets +> +> Expected results: +> - VM should never stop transmitting packets +> +> Additional info: +> We do propose a fix at: +> http://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg00652.html +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1556306/+subscriptions + + +Correct, it is fixed in Qemu upstream. Just need to get it used into my ubuntu. + +Let's close it. Sorry, it should be opened into: + https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/ + +you can also add the project 'qemu-kvm' on the bug in order to get it into the ubuntu qemu-kvm bug list. + +apologize but I was corrected that for qemu issues. The bug should be in the following: + +Distribution: ubuntu +package: qemu <--instead of project. + +I will correct this in the bug. + +Status changed to 'Confirmed' because the bug affects multiple users. + +Thanks for reporting this bug. I'll push into the xenial package today. + +Side question, will you apply it to qemu-kvm from + https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/mitaka-staging/+files/qemu-kvm_2.5+dfsg-5ubuntu5~cloud0_amd64.deb +too? + +or should I open another bug? + +This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu6 + +--------------- +qemu (1:2.5+dfsg-5ubuntu6) xenial; urgency=medium + + * Cherrypick upstream patch vhost-user-interrupt-management-fixes.patch + (LP: #1556306) + + -- Serge Hallyn <email address hidden> Wed, 16 Mar 2016 16:35:22 -0700 + +It should also be fixed in the qemu-kvm package. No additional bug needed as this bug covers both qemu and qemu-kvm packages. + +Sergey - any chance you can also push the patch into the qemu-kvm package? + +it seems that the fix was not applied on ppc build: + https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-1ubuntu3/+build/8842754 + https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-1ubuntu3/+build/8842753 + +neither on arm64: + https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-1ubuntu3/+build/8842750 + + + +Quoting Vincent JARDIN (vincent.jardin@6wind.com): +> it seems that the fix was not applied on ppc build: +> https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-1ubuntu3/+build/8842754 +> https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-1ubuntu3/+build/8842753 +> +> neither on arm64: +> https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-1ubuntu3/+build/8842750 + +Hi, + +that is an old version. See https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu6 +and +https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu6/+build/9361116/+files/buildlog_ubuntu-xenial-arm64.qemu_1%3A2.5+dfsg-5ubuntu6_BUILDING.txt.gz + + +Great, thanks for your ack't of the update being available for ppc. + +This is marked as affecting precise, but has anyone reproduced this with qemu-kvm 1.0+noroms-0ubuntu14.27 ? + +The patch is completely inapplicable to that code base, so it would need to be rewritten from scratch if so. + + +(if someone says they have reproduced it on 1.0+noroms-0ubuntu14.27 I'll unmark it invalid.) + + +Actually even porting to trusty is complicated by a set of endianness patches. + + +Hello Vincent, or anyone else affected, + +Accepted qemu into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.3+dfsg-5ubuntu9.3 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 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, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +The wily SRU has been waiting for validation for quite some time. I'm wondering whether that is because noone is using wily, or because it's not high priority? + +The patch does not apply cleanly to trusty. In particular, the chunk in ./hw/net/vhost_net.c.rej is quite obsolete in the trusty source. So I'd like to hear from someone that they are hitting this before risking an erroneous backport. + + +Hi, +cleaning up old issues. +In all the time we had no confirmed report on trusty, also as serge outlined in c#19 the backport would be much harder and therefore carry more risk for the SRU. +Since wily was haniging in verification so long and now is EOD this is dead. + +I'm cleaning up the bug states to match that accordingly. + diff --git a/results/classifier/zero-shot/108/permissions/1577 b/results/classifier/zero-shot/108/permissions/1577 new file mode 100644 index 000000000..fc8ebb76e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1577 @@ -0,0 +1,99 @@ +permissions: 0.940 +graphic: 0.933 +semantic: 0.914 +other: 0.914 +performance: 0.906 +device: 0.899 +debug: 0.887 +vnc: 0.876 +KVM: 0.868 +files: 0.853 +PID: 0.843 +boot: 0.828 +socket: 0.808 +network: 0.806 + +device_del return is already in the process of unplug frequently +Description of problem: +recently we update qemu 6.1.1 to qemu 7.1.0, and run into an issue with the following error: + +command '{ "execute": "device_del", "arguments": { "id": "virtio-diskX" } }' for VM "id" failed ({ "return": {"class": "GenericError", "desc": "Device virtio-diskX is already in the process of unplug"} }). + +The issue is reproducible. With a few seconds delay before hot-unplug, hot-unplug just works fine. + +After a few digging, we found that the commit 9323f892b39 may incur the issue. +------------------ + failover: fix unplug pending detection + + Failover needs to detect the end of the PCI unplug to start migration + after the VFIO card has been unplugged. + + To do that, a flag is set in pcie_cap_slot_unplug_request_cb() and reset in + pcie_unplug_device(). + + But since + 17858a169508 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") + we have switched to ACPI unplug and these functions are not called anymore + and the flag not set. So failover migration is not able to detect if card + is really unplugged and acts as it's done as soon as it's started. So it + doesn't wait the end of the unplug to start the migration. We don't see any + problem when we test that because ACPI unplug is faster than PCIe native + hotplug and when the migration really starts the unplug operation is + already done. + + See c000a9bd06ea ("pci: mark device having guest unplug request pending") + a99c4da9fc2a ("pci: mark devices partially unplugged") + + Signed-off-by: Laurent Vivier <lvivier@redhat.com> + Reviewed-by: Ani Sinha <ani@anisinha.ca> + Message-Id: <20211118133225.324937-4-lvivier@redhat.com> + Reviewed-by: Michael S. Tsirkin <mst@redhat.com> + Signed-off-by: Michael S. Tsirkin <mst@redhat.com> +------------------ +The purpose is for detecting the end of the PCI device hot-unplug. However, we feel the error confusing. How is it possible that a disk "is already in the process of unplug" during the first hot-unplug attempt? So far as I know, the issue was also encountered by libvirt, but they simply ignored it: + + https://bugzilla.redhat.com/show_bug.cgi?id=1878659 + +Hence, a question is: should we have the line below in acpi_pcihp_device_unplug_request_cb()? + + pdev->qdev.pending_deleted_event = true; + +It would be great if you as the author could give us a few hints. + +Thank you very much for your reply! + +Sincerely, + +Yu Zhang @ Compute Platform IONOS + + +The issue is reproducible in our own stack, which is not quite easy to describe in a few command lines. We simplified it a bit by a script instead. Although it's not able to reproduce, it could be somewhat helpful to understand the issue. + +``` +#!/bin/bash + +HOME=~ +QEMU=$HOME/qemu/bin/qemu-system-x86_64 +DISK1=$HOME/img/disk1.qcow2 +DISK4=$HOME/img/disk4.qcow2 +DISK5=$HOME/img/disk5.qcow2 + +$QEMU \ + -cpu host -enable-kvm -m 2048 -smp 2 \ + -object iothread,id=iothread1 \ + -drive file=$DISK1,if=none,id=drive-virtio-disk1,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,iothread=iothread1,num-queues=1,discard=on,id=virtio-disk1 \ + -object iothread,id=iothread4 \ + -drive file=$DISK4,if=none,id=drive-virtio-disk4,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk4,iothread=iothread4,num-queues=1,discard=on,id=virtio-disk4 \ + -object iothread,id=iothread5 \ + -drive file=$DISK5,if=none,id=drive-virtio-disk5,format=qcow2,snapshot=off,discard=on,cache=none \ + -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk5,iothread=iothread5,num-queues=1,discard=on,id=virtio-disk5 \ + -qmp unix:./qmp-sock,server,nowait & + +sleep 5 + +echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock +echo '{"execute":"qmp_capabilities"}{"execute": "device_del","arguments": { "id": "virtio-disk5"}}{"execute": "query-block"}' | nc -U -w 1 ./qmp-sock``` +Additional information: +Possible workaround: https://lore.kernel.org/qemu-devel/20230403131833-mutt-send-email-mst@kernel.org/T/#t diff --git a/results/classifier/zero-shot/108/permissions/1581936 b/results/classifier/zero-shot/108/permissions/1581936 new file mode 100644 index 000000000..83f4b4ef7 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1581936 @@ -0,0 +1,247 @@ +permissions: 0.982 +debug: 0.956 +other: 0.956 +device: 0.949 +performance: 0.949 +semantic: 0.948 +boot: 0.942 +graphic: 0.929 +PID: 0.929 +files: 0.924 +socket: 0.920 +KVM: 0.847 +network: 0.825 +vnc: 0.694 + +Frozen Windows 7 VMs with VGA CVE-2016-3712 fix (2.6.0 and 2.5.1.1) + +Hi, + +As already posted on the QEMU devel list [1] I stumbled upon a problem with QEMU in version 2.5.1.1 and 2.6.0. + +the VM shows Windows loading +files for the installation, then the "Starting Windows" screen appears +here it hangs and never continues. + +Changing the "-vga" option to cirrus solves this, the installation can +proceed and finish. When changing back to std (or also qxl, vmware) the +installed VM also hangs on the "Starting Windows" screen while qemu +showing a little but no excessive load. + +This phenomena appears also with QEMU 2.6.0 but not with 2.6.0-rc4, a +git bisect shows fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 (vga: make +sure vga register setup for vbe stays intact (CVE-2016-3712)) as the +culprit for this regression, as its a fix for a DoS its not an option to +just revert it, I guess. + +The bisect log is: + +git bisect start +# bad: [bfc766d38e1fae5767d43845c15c79ac8fa6d6af] Update version for v2.6.0 release +git bisect bad bfc766d38e1fae5767d43845c15c79ac8fa6d6af +# good: [975eb6a547f809608ccb08c221552f666611af25] Update version for v2.6.0-rc4 release +git bisect good 975eb6a547f809608ccb08c221552f666611af25 +# good: [2068192dcccd8a80dddfcc8df6164cf9c26e0fc4] vga: update vga register setup on vbe changes +git bisect good 2068192dcccd8a80dddfcc8df6164cf9c26e0fc4 +# bad: [53db932604dfa7bb9241d132e0173894cf54261c] Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20160509-1' into staging +git bisect bad 53db932604dfa7bb9241d132e0173894cf54261c +# bad: [fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7] vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). +git bisect bad fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 +# first bad commit: [fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7] vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). + + +I could reproduce that with QEMU 2.5.1 and QEMU 2.6 on a Debian derivate +(Promox VE) with 4.4 Kernel and also with QEMU 2.6 on an Arch Linux +System with a 4.5 Kernel, so it should not be host distro depended. Both +machines have Intel x86_64 processors. +The problem should be reproducible with said Versions or a build from +git including the above mentioned commit (fd3c136) by starting a VM with +an Windows 7 ISO, e.g.: + +Freezing installation (as vga defaults to std I marked it as optional): +./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom win7.iso -m 1024 [-vga (std|qxl|vmware)] + +Working installation: +./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom win7.iso -m 1024 -vga cirrus + +If someone has already an installed Windows 7 VM this behaviour should be +also observable when trying to start it with the new versions of QEMU. + +Noteworthy may be that Windows 10 is working, I do not had time to get +other Windows versions and test them, I'll do that as soon as possible. +Various Linux system also seems do work fine, at least I did not ran +into an issue there yet. + +I also tried testing with SeaBIOS and OVMF as firmware, as initially I +had no idea what broke, both lead to the same result - without the +CVE-2016-3712 fix they both work, with not. +Further, KVM enabled and disabled does not make any difference. + + +[1] http://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg02416.html + +I can confirm this behaviour. Tested on 3 different machines, all Windows 7 VMs are broke because of the latest "patch". Also tested Windows XP and Windows 10, both work with VGA flawlessly. + +I experience the same behavior on RHEL 7.2 since I installed the lastest patch. + +Seem to be a RHEL/Fedora on the same issue: +https://bugzilla.redhat.com/show_bug.cgi?id=1339267 + +supposed to be fixed by <http://git.qemu.org/?p=qemu.git;a=commit;h=94ef4f337fb614f18b765a8e0e878a4c23cdedcd>, please confirm + +I can partly confirm this, see (and parents): +https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg04048.html + +It sounds just a little strange to me, so I'll recheck to be double sure every configure option is the same on my Arch Linux and Debian machine. + +I'm experiencing the same issue. Terrible video performance with Cirrus as it is the only video workable with windows 7. Please, fix it. + +So this is fixed upstream, in Fedora and ARCH. Can we expect a fix for xenial? This is quite a show stopper. + +Commit 94ef4f337fb614f18b7 has been released with QEMU version 2.7 + +Will the fix be backported? Right now, this is a regression in xenial (caused by the security update in 1:2.5+dfsg-5ubuntu10.6). + +... and trusty is affected, too. + +Would it help if I provide patches for trusty/xenial? I'd probably also need to update the description for SRU? + + + + + +Please let me know if there is anything I can do to help get these patches accepted for trusty/xenial. + +The attachment "Proposed fix for trusty" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] + +Hi, +thanks for marking Qemu(Ubuntu) so I could see it - and thanks for the prework on the patches. +We need to clear a few in progress SRUs before that but other than that things look nice. +We can work on the patches a bit until that happened. + +We will need somewhat proper Dep3 headers in [1] the patches - I can add those if you want me to do so. + +[1]: http://dep.debian.net/deps/dep3/ + +I checked and this is in 2.6.1 via a backport as [1] not as the original [2]. + +But that means >=Yakkety is good and Xenial/Trusty are bad since the related Security SRUs. +Updating bug tasks accordingly. + +[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=7ff5dc445d6bb392f9fb3d0a254ef9071304780b +[2]: http://git.qemu.org/?p=qemu.git;a=commit;h=94ef4f337fb614f18b765a8e0e878a4c23cdedcd + +Discussed with the Security Team, this will very likely be in the next round of updates that will follow soon. I'll additionally ping the release team to get the blocking ongoing SRU processed faster. + +This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.34 + +--------------- +qemu (2.0.0+dfsg-2ubuntu1.34) trusty-security; urgency=medium + + * SECURITY UPDATE: denial of service via leak in virtFS + - debian/patches/CVE-2017-7377.patch: fix file descriptor leak in + hw/9pfs/virtio-9p.c. + - CVE-2017-7377 + * SECURITY UPDATE: denial of service in cirrus_vga + - debian/patches/CVE-2017-7718.patch: check parameters in + hw/display/cirrus_vga_rop.h. + - CVE-2017-7718 + * SECURITY UPDATE: code execution via cirrus_vga OOB r/w + - debian/patches/CVE-2017-7980-1.patch: handle negative pitch in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-2.patch: allow zero source pitch in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-3.patch: fix blit address mask handling + in hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-4.patch: fix patterncopy checks in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-5.patch: revert allow zero source pitch + in hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-6.patch: stop passing around dst + pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, + hw/display/cirrus_vga_rop2.h. + - debian/patches/CVE-2017-7980-7.patch: stop passing around src + pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, + hw/display/cirrus_vga_rop2.h. + - debian/patches/CVE-2017-7980-8.patch: fix off-by-one in + hw/display/cirrus_vga_rop.h. + - debian/patches/CVE-2017-7980-9.patch: fix cirrus_invalidate_region in + hw/display/cirrus_vga.c. + - CVE-2017-7980 + * SECURITY UPDATE: denial of service via memory leak in virtFS + - debian/patches/CVE-2017-8086.patch: fix leak in + hw/9pfs/virtio-9p-xattr.c. + - CVE-2017-8086 + * SECURITY UPDATE: denial of service via leak in audio + - debian/patches/CVE-2017-8309.patch: release capture buffers in + audio/audio.c. + - CVE-2017-8309 + * SECURITY UPDATE: denial of service via leak in keyboard + - debian/patches/CVE-2017-8379-1.patch: limit kbd queue depth in + ui/input.c. + - debian/patches/CVE-2017-8379-2.patch: don't queue delay if paused in + ui/input.c. + - CVE-2017-8379 + * SECURITY REGRESSION: Windows 7 VGA compatibility issue (LP: #1581936) + - debian/patches/lp1581936.patch: add sr_vbe register set to + hw/display/vga.c, hw/display/vga_int.h. + + -- Marc Deslauriers <email address hidden> Wed, 10 May 2017 15:50:30 -0400 + +This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.14 + +--------------- +qemu (1:2.5+dfsg-5ubuntu10.14) xenial-security; urgency=medium + + * SECURITY UPDATE: denial of service via leak in virtFS + - debian/patches/CVE-2017-7377.patch: fix file descriptor leak in + hw/9pfs/virtio-9p.c. + - CVE-2017-7377 + * SECURITY UPDATE: denial of service in cirrus_vga + - debian/patches/CVE-2017-7718.patch: check parameters in + hw/display/cirrus_vga_rop.h. + - CVE-2017-7718 + * SECURITY UPDATE: code execution via cirrus_vga OOB r/w + - debian/patches/CVE-2017-7980-1.patch: handle negative pitch in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-2.patch: allow zero source pitch in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-3.patch: fix blit address mask handling + in hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-4.patch: fix patterncopy checks in + hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-5.patch: revert allow zero source pitch + in hw/display/cirrus_vga.c. + - debian/patches/CVE-2017-7980-6.patch: stop passing around dst + pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, + hw/display/cirrus_vga_rop2.h. + - debian/patches/CVE-2017-7980-7.patch: stop passing around src + pointers in hw/display/cirrus_vga.c, hw/display/cirrus_vga_rop.h, + hw/display/cirrus_vga_rop2.h. + - debian/patches/CVE-2017-7980-8.patch: fix off-by-one in + hw/display/cirrus_vga_rop.h. + - debian/patches/CVE-2017-7980-9.patch: fix cirrus_invalidate_region in + hw/display/cirrus_vga.c. + - CVE-2017-7980 + * SECURITY UPDATE: denial of service via memory leak in virtFS + - debian/patches/CVE-2017-8086.patch: fix leak in + hw/9pfs/virtio-9p-xattr.c. + - CVE-2017-8086 + * SECURITY UPDATE: denial of service via leak in audio + - debian/patches/CVE-2017-8309.patch: release capture buffers in + audio/audio.c. + - CVE-2017-8309 + * SECURITY UPDATE: denial of service via leak in keyboard + - debian/patches/CVE-2017-8379-1.patch: limit kbd queue depth in + ui/input.c. + - debian/patches/CVE-2017-8379-2.patch: don't queue delay if paused in + ui/input.c. + - CVE-2017-8379 + * SECURITY REGRESSION: Windows 7 VGA compatibility issue (LP: #1581936) + - debian/patches/lp1581936.patch: add sr_vbe register set to + hw/display/vga.c, hw/display/vga_int.h. + + -- Marc Deslauriers <email address hidden> Wed, 10 May 2017 10:09:29 -0400 + diff --git a/results/classifier/zero-shot/108/permissions/1594069 b/results/classifier/zero-shot/108/permissions/1594069 new file mode 100644 index 000000000..0fa8393a0 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1594069 @@ -0,0 +1,89 @@ +permissions: 0.953 +performance: 0.906 +graphic: 0.897 +other: 0.895 +device: 0.892 +debug: 0.855 +boot: 0.847 +socket: 0.846 +files: 0.823 +semantic: 0.821 +network: 0.782 +PID: 0.757 +vnc: 0.665 +KVM: 0.641 + +SIMD instructions translated to scalar host instructions + +SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are translated to scalar instructions on the host instead of SIMD instructions. It appears that there have been a few efforts to rectify this [1], and even a submitted patch series, but all discussion has effectively died out [2]. + +I would like to see better SIMD performance on qemu, especially as non-x86 architectures are becoming widely used (e.g. ARM). + +[1] http://dl.acm.org/citation.cfm?id=2757098&dl=ACM&coll=DL&CFID=633095244&CFTOKEN=12352103 +[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg01720.html + +On 19 June 2016 at 06:33, Timothy Pearson <email address hidden> wrote: +> Public bug reported: +> +> SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are +> translated to scalar instructions on the host instead of SIMD +> instructions. It appears that there have been a few efforts to rectify +> this [1], and even a submitted patch series, but all discussion has +> effectively died out [2]. +> +> I would like to see better SIMD performance on qemu, especially as +> non-x86 architectures are becoming widely used (e.g. ARM). + +I agree it would be nice, but I'm not sure there's much benefit +from filing a bug about it. Bug reports don't magically become +code changes, and doing SIMD-to-SIMD is very difficult when +you need to support multiple host and guest architectures and +get all the details and corner cases correct. QEMU as it stands +isn't behaving wrongly. + +thanks +-- PMM + + +I mostly filed the bug report since I was seeing multiple different attempts to implement this, and even a proper patch series on the mailing list, but no movement at all toward integrating this feature into mainline qemu. + +What would be needed to e.g. make the patch series on the mailing list acceptable for merge? + +On 20 June 2016 at 15:05, Timothy Pearson <email address hidden> wrote: +> I mostly filed the bug report since I was seeing multiple different +> attempts to implement this, and even a proper patch series on the +> mailing list, but no movement at all toward integrating this feature +> into mainline qemu. +> +> What would be needed to e.g. make the patch series on the mailing list +> acceptable for merge? + +The bare minimum is that things need to not break for any +guest x host combination. The RFC patchset from Kirill says +that it doesn't work for all ARM guest code, for instance. +It also needs to fall back cleanly if the backend doesn't support +vector ops, and I'm not sure if the RFC does that. It needs +to implement more than a single test "vector add". It needs +to be reasonably demonstrated that it's actually a win on +real-life code rather than a trivial microbenchmark. The +various concerns listed in the RFC cover letter need to be +discussed and addressed. + +This is all certainly doable, but the missing thing is "nobody +is actually doing it", not "we didn't know about this". +An RFC patchset is a sketch of a design, and there's a long +way between that and committable code. + +The ACM paper looks like a classic example of a bit of academic +work: maybe they did something interesting, but their intended +end output was a paper, not code, and they never submitted any +patches to us that I'm aware of. (And again, "academic prototype" +and "production code" are often far apart.) + +thanks +-- PMM + + +Closing this because it isn't a bug. (It looks like some of the vector TCG improvements are now in progress and might hit master for 2.12; but in any case having an open bug in the system about this serves no useful purpose.) + + diff --git a/results/classifier/zero-shot/108/permissions/1603693 b/results/classifier/zero-shot/108/permissions/1603693 new file mode 100644 index 000000000..9d5becb57 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1603693 @@ -0,0 +1,143 @@ +permissions: 0.944 +semantic: 0.876 +other: 0.853 +debug: 0.849 +performance: 0.793 +device: 0.775 +graphic: 0.768 +network: 0.767 +boot: 0.754 +PID: 0.715 +files: 0.678 +socket: 0.658 +vnc: 0.560 +KVM: 0.556 + +Disks in mptsas1068 scsi controller not seen by linux + +When using the mptsas1068 scsi controller, linux detects the controller itself but not the drives attached to it. Freebsd works. Using a different controller with linux works. VMware with linux works. + +qemu 2.6.50 (v2.6.0-1925-g6b92bbf) +seabios rel-1.9.0-139-gae3f78f (master branch, required for mptsas1068 support) + +Test script, loosely based off what libvirt runs and the libvirt tests that Paolo Bonzini wrote [1] + +##################### +iso=archlinux-2016.07.01-dual.iso +#iso=FreeBSD-10.3-RELEASE-amd64-bootonly.iso +device=mptsas1068 +#device=lsi + +img=empty.img +qemu-img create -f qcow2 $img 1G + +/usr/bin/qemu-system-x86_64 \ +-enable-kvm \ +-m 1024 \ +-boot menu=on \ +-device $device,id=scsi0,bus=pci.0,addr=0x9 \ +-drive file=$img,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=2 \ +-drive file=$iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 +##################### + +The ISOs can be downloaded from [2] and [3]. + +After booting linux, do "lsblk". /dev/sda should exist. + +After booting freebsd, do "geom disk list". A da0 / "QEMU QEMU HARDDISK" should be mentioned. + +With device=mptsas1068 this fails in linux. + +With device=lsi line it works in both. + +With VMWare and a linux VM (opensuse 10.1, kernel 2.6.18) which only loads modules for mptsas1068, this works. + +I also reproduced this with the debian 8.5 netinstall image, but it insists in making you pick a driver from a list of modules when it fails to mount it, instead of dropping to a shell. + +Arch linux dmesg output snippet (full output attached as arch-linux-dmesg.txt): + +##################### +root@archiso ~ # dmesg | grep -i -e mpt -e scsi -e ioc0 +[ 0.000000] Linux version 4.6.3-1-ARCH (builduser@tobias) (gcc version 6.1.1 20160602 (GCC) ) #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 +[ 0.000000] Normal empty +[ 0.000000] Preemptible hierarchical RCU implementation. +[ 1.879616] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249) +[ 1.951581] SCSI subsystem initialized +[ 1.957113] Fusion MPT base driver 3.04.20 +[ 1.957618] Fusion MPT SAS Host driver 3.04.20 +[ 2.281773] scsi host0: ata_piix +[ 2.285372] scsi host1: ata_piix +[ 2.305803] mptbase: ioc0: Initiating bringup +[ 2.363555] ioc0: LSISAS1068 A0: Capabilities={Initiator} +[ 2.444390] scsi 0:0:1:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 +[ 2.500572] scsi host2: ioc0: LSISAS1068 A0, FwRev=01329200h, Ports=8, MaxQ=128, IRQ=11 +[ 2.507024] sr 0:0:1:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray +[ 2.507274] sr 0:0:1:0: Attached scsi CD-ROM sr0 +##################### + +The controller itself is detected, the disk isn't. + +An early version of this patch [4] said that it was only tested with FreeBSD: + +>Tested with FreeBSD for now. The previous version (before the +>configuration page rewrite) worked with RHEL and Windows guests as well. +> +>TODO: write qtest for (at least) config pages, test Linux and Windows. + +[1]: https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=fc922eb2080a3fa7b24bc8a8b0aabfd394480143 +[2]: https://www.archlinux.org/download +[3]: https://www.freebsd.org/where.html +[4]: https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06475.html + + + + + +Linux requires that you specify a WWN for the disk (through the wwn property of the scsi-disk device). + +Welp. Yeah now I see it, it was in the test case I linked. Thanks. + +Vmware doesn't seem to need this. Seems like it assigns a WWN of 0x5000c293944837df to my disk (not in the vm config files as far as i can see, seems to persist across reboots) + +[ 2.305111] ioc0: LSISAS1068 B0: Capabilities={Initiator} +[ 2.445800] scsi host2: ioc0: LSISAS1068 B0, FwRev=01032920h, Ports=1, MaxQ=128, IRQ=18 +[ 2.447672] mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x5000c293944837df +[ 2.448806] scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2 + +Qemu with the manually specified WWN, for reference: + +[ 3.656894] ioc0: LSISAS1068 A0: Capabilities={Initiator} +[ 3.790680] scsi host0: ioc0: LSISAS1068 A0, FwRev=01329200h, Ports=8, MaxQ=128, IRQ=10 +[ 3.792232] mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x5000c50015ea71ac +[ 3.792476] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 + +Also vmware doesn't populate /dev/disk/by-id/wwn-*: + +# ls /dev/disk/by-id +ata-VMware_Virtual_IDE_CDROM_Drive_00000000000000000001@ dm-name-arch_airootfs@ + +Qemu: + +# ls /dev/disk/by-id +ata-QEMU_DVD-ROM_QM00002@ scsi-35000c50015ea71ac@ scsi-35000c50015ea71ac-part2@ wwn-0x5000c50015ea71ac@ wwn-0x5000c50015ea71ac-part2@ +dm-name-arch_airootfs@ scsi-35000c50015ea71ac-part1@ scsi-35000c50015ea71ac-part3@ wwn-0x5000c50015ea71ac-part1@ wwn-0x5000c50015ea71ac-part3@ + + +Not directly related: after getting the arch iso cd to boot, I found that the VM that I actually wanted to get working uses mptspi instead of mptsas. So I didn't even need this controller... + +The non-working vmware config says `scsi0.virtualDev = "lsilogic"` (that's mptspi, LSI53C1030 or "LSI Logic Ultra 320"). For the mptsas tests above, I changed it to `scsi0.virtualDev = "lsisas1068"`. + +Is it correct to say that the LSI53C1030 parts of [1] were never applied? + +[1]: http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg01608.html + +> The non-working vmware config says `scsi0.virtualDev = "lsilogic"` +> (that's mptspi, LSI53C1030 or "LSI Logic Ultra 320"). For the mptsas +> tests above, I changed it to `scsi0.virtualDev = "lsisas1068"`. +> +> Is it correct to say that the LSI53C1030 parts of [1] were never applied? + +Yes, that's correct. The patch you linked was almost entirely rewritten. + diff --git a/results/classifier/zero-shot/108/permissions/1609968 b/results/classifier/zero-shot/108/permissions/1609968 new file mode 100644 index 000000000..412f25fff --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1609968 @@ -0,0 +1,88 @@ +permissions: 0.983 +other: 0.979 +device: 0.978 +graphic: 0.974 +performance: 0.972 +PID: 0.969 +boot: 0.969 +semantic: 0.968 +vnc: 0.968 +files: 0.963 +socket: 0.951 +debug: 0.930 +KVM: 0.914 +network: 0.785 + +"cannot set up guest memory" b/c no automatic clearing of Linux' cache + +Version: qemu-2.6.0-1 +Kernel: 4.4.13-1-MANJARO +Full script (shouldn't matter though): https://pastebin.com/Hp24PWNE + +Problem: +When host has been up and used for a while cache has been filled as much that guest can't be started without droping caches. + +Expected behavior: +Qemu should be able to request as much Memory as it needs and cause Linux to drop cache pages if needed. A user shouldn't be required to have to come to this conclusion and having to drop caches to start Qemu with the required amount of memory. + +My fix: +Following command (as root) required before qemu start: +# sync && echo 3 > /proc/sys/vm/drop_caches + +Example: +$ sudo qemu.sh -m 10240 && echo success || echo failed +qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory +failed +$ free + total used free shared buff/cache available +Mem: 16379476 9126884 3462688 148480 3789904 5123572 +Swap: 0 0 0 +$ sudo sh -c 'sync && echo 3 > /proc/sys/vm/drop_caches' +$ free + total used free shared buff/cache available +Mem: 16379476 1694528 14106552 149772 578396 14256428 +Swap: 0 0 0 +$ sudo qemu.sh -m 10240 && echo success || echo failed +success + +Hi Celmor, + That shouldn't happen! QEMU's allocation of memory is pretty normal, so really the question is for the kernel guys. + Having chatted to a collague, two questions: + a) Does it still happen if you set /proc/sys/vm/overcommit_memory to 1? + b) What filesystem are you using (some have different behaviour when dealing with the caches). + +@dgilbert-h / Dr. David Alan Gilbert +Thanks for your answer. + +b) +Mounted/used block devices: +NAME MOUNTPOINT TYPE FSTYPE +sda disk crypto_LUKS +└─Data1 crypt zfs_member +├─sdb5 / part ext4 +└─sdb6 /boot part vfat +sdd disk crypto_LUKS +└─Data2 crypt zfs_member +ZFS file system for extra space, also ZFS is the reason I'm not running the latest kernel... + +a) +$ free + total used free shared buff/cache available +Mem: 16379476 7879216 1867196 188180 6633064 3587620 +Swap: 0 0 0 +$ qemu.sh -m 10240 && echo success || echo failed +qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory +failed +$ sudo sh -c 'echo 1 > /proc/sys/vm/overcommit_memory' +$ qemu.sh -m 10240 && echo success || echo failed +success + +So setting /proc/sys/vm/overcommit_memory to 1 works, so I guess I'm gonna need to execute +sudo sh -c 'echo 1 > /proc/sys/vm/overcommit_memory' +at start of my qemu.sh script instead of the 'drop_caches' part. +I still think the kernel should do whatever function overcommit_memory is for automatically, bit it seams to be the fault of the kernel of my distribution then, thanks for your help. + +Thanks Celmor; that might be one for the zfs guys then if that's what's holding onto the caches; I suspect their caching is a bit different from the rest of the Linux filesystems. + +I'm going to close this as 'invalid' because I'm pretty sure this isn't a qemu bug; the kernel should be giving us the RAM we asked for if it's got it. + diff --git a/results/classifier/zero-shot/108/permissions/1622582 b/results/classifier/zero-shot/108/permissions/1622582 new file mode 100644 index 000000000..97d6c3ef2 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1622582 @@ -0,0 +1,110 @@ +permissions: 0.968 +debug: 0.956 +semantic: 0.950 +graphic: 0.947 +boot: 0.946 +performance: 0.945 +other: 0.943 +socket: 0.925 +PID: 0.923 +device: 0.918 +vnc: 0.891 +network: 0.890 +files: 0.883 +KVM: 0.867 + +Can't install Windows 7 with q35 (SATA) + +I'm trying to install Windows 7 on a q35 machine on a "SATA disk". If I use q35 the installation is extremely slow. With extremely slow I mean, that the first few minutes (10-15 minutes) on the second installation step (copying files to disk) nothing happens. Than there is some progress, maybe until 9% and than there is "silence" for another 10 minutes or so. Therefore I used iotop (with --only option) in order to see, if there are any disk operations. But as I mentioned, only a few times qemu writes something to disk (with about < 1M/s). But most of the time there is nothing from qemu. Therefore the installation lasts over an hour. But even worse, after installation I can't boot Windows. Windows-Start-Manager tells me, that windows couldn't be loaded because the kernel is missing or corrupt (Status 0xc0000221, File: \Windows\system32\ntoskrnl.exe). If I use IDE on q35 or pc-i440fx-2.6 everything works fine. There is a continuous installation progress and iotop shows continuous disk writes with max 30M/s (but also 5M/s and other values...). + +I've tried qemu 2.6.0, 2.6.1 and 2.7.0 (all versions from git). + +My host machine: +Ubuntu 14.04.5 LTS +3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux +Intel(R) Core(TM) i5-3470 CPU +16 GB RAM + + +I used the following commands: + +"Standard" command +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -hda win7_qemu_standard_q35.qcow2 -cdrom win7proX64.iso -boot order=d + +I think by using -hda sata will be used?!? + +With explicit ahci: +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -drive file=win7_qemu_standard_q35.qcow2,media=disk,if=none,id=sata-disk -device ich9-ahci,id=ahci -device ide-drive,drive=sata-disk,bus=ahci.0 -drive file=win7proX64.iso,media=cdrom,if=none,id=sata-cdrom -device ide-cd,drive=sata-cdrom,bus=ahci.1 -boot order=d + +I don't know if this is totally correct, because it's a little bit weird that I have to use ide-drive on a ich9 bus. + +Without kvm there is a continious disk write with 100 K/s - 5 M/s (works only with qemu 2.7.0, otherwise I get a 0x000000D1 bluescreen on the setup start screen): +qemu-system-x86_64 -m 2048 -machine q35 -cpu IvyBridge -hda win7_qemu_standard_q35.qcow2 -cdrom win7proX64.iso -boot order=d + +But with all three commands the installed Windows is not working, because always the same error occurs: windows couldn't be loaded because kernel is missing or corrupt + +Interestingly both commands ("standard" command and with explicit ahci) works very well with a Windows 10 installation. + +In my opinion it's a "SATA problem", because if I use e.g. piix4-ide instead of ich9-ahci it works: +qemu-system-x86_64 -m 2048 -machine q35,accel=kvm -cpu host,kvm=off -smp 1,sockets=1,cores=1,threads=1 -enable-kvm -drive file=win7_qemu_standard_q35.qcow2,media=disk,if=none,id=ide-disk -device piix4-ide,id=ide -device ide-drive,drive=ide-disk,bus=ide.0 -drive file=win7proX64.iso,media=cdrom,if=none,id=ide-cdrom -device ide-cd,drive=ide-cdrom,bus=ide.1 -boot order=d + +With this command there is a continuous disk write and the installation is bootable. + +Dennis, what's the exact version, edition, region (etc) of your Windows 7 install media? + +It's been a while since I've tried to install Windows 7 personally, but around the ~2.4 timeframe I didn't have any problems. I'd like to try with your exact media if at all possible; can you give me a checksum? If it's official MSDN media I can correlate that and attempt to reproduce. + +Thanks, +--js + +PS: + +(1) Yes, using -hda et al under the Q35 machine type will give you SATA disks on the AHCI device. + +(2) All ATA-related devices are a type of "ide-drive" in QEMU, there is no explicit "SATA" drive because QEMU does not bother or care to emulate the transport specifics. At that level, ATA and SATA drives are almost exactly the same, apart from an expanded command verb repertoire in the SATA spec. + +Hi John, +thx for your quick reply and the explanation for -hda and ide-drive. + +I'm using Windows 7 Professional x64 German edition. The md5 sum is: 705b6aaa5cf406428c2ab5e4d76c0cc4 + +If you need anything else, please let me know. + +I can reproduce with the English version: +7b7af5fe3a01e9fd76de4dacb45a796b en_windows_7_professional_x64_dvd_x15-65805.iso + +I can't reproduce with SP1, however: +ed15956fe33c13642a6d2cb2c7aa9749 en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso + +We might be bumping up against a driver fix, but I still don't know the root cause just yet. I'll have to investigate. It looks like Windows 7 submits a flurry of NCQ writes, then hangs for a while, then submits an ATA SET FEATURES request, then another flurry of NCQ writes, then hangs for a while again; rinse repeat. + +It doesn't LOOK as if QEMU is dropping any requests, but I will have to investigate to see if there's anything improper happening... + +In the meantime, for you and anyone else who comes across this problem, I recommend using Windows 7 Professional x64 SP1 if at all possible! + +I also face this problem, any idea to resolve. +I am using qemeu 4.2 + whpx support but failed to install + +./qemu-system-x86_64 -m 4096 \ +-vga vmware \ +-machine q35 \ +-accel whpx \ +-usb -device usb-kbd \ +-device usb-mouse -device usb-audio -boot c \ +-netdev tap,id=mynet0,ifname=tap0,script=no,downscript=no \ +-device e1000,netdev=mynet0,mac=52:55:00:d1:55:01 \ + -smp 4 \ +-cdrom /e/Software/OS/WIN7/en_windows_7_ultimate_with_sp1_x64_dvd_u_677332.iso + + +But when using -accel tcg, it's insalled fine. + + + +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/55 + + diff --git a/results/classifier/zero-shot/108/permissions/1630 b/results/classifier/zero-shot/108/permissions/1630 new file mode 100644 index 000000000..0c6cdee57 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1630 @@ -0,0 +1,215 @@ +permissions: 0.962 +other: 0.944 +KVM: 0.928 +graphic: 0.926 +vnc: 0.926 +debug: 0.926 +device: 0.920 +semantic: 0.911 +socket: 0.906 +boot: 0.903 +performance: 0.901 +PID: 0.897 +files: 0.886 +network: 0.870 + +[8.0.0] qemu breaks mac os vm (passed through sata controller) +Description of problem: +I have a mac os montery vm which is not able to boot after upgrading from qemu 7.2.1 to qemu 8.0.0.\ +Mac os bootloader (opencore) logs do not show anything useful, nothing useful also in libvirt logs.\ +Apple screen hangs at "still waiting for root device" with the prohibition symbol.\ +This should point that mac os is not able to find the disk to boot from.\ +The bootloader sees the disk with its partitions.\ +I'm passing through a sata controller with the boot disk attached, together with a usb controller, builtin audio and a gpu.\ +Changing machine type (q35) to older versions change nothing.\ +Downgrading to 7.2.1 and no issue. + +Maybe related to some acpi changes? +Additional information: +This is the libvirt xml I'm using: +``` +<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <name>Montereytest</name> + <memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>33554432</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static'>8</vcpu> + <iothreads>2</iothreads> + <iothreadids> + <iothread id='1'/> + <iothread id='2'/> + </iothreadids> + <cputune> + <vcpupin vcpu='0' cpuset='1'/> + <vcpupin vcpu='1' cpuset='2'/> + <vcpupin vcpu='2' cpuset='3'/> + <vcpupin vcpu='3' cpuset='4'/> + <vcpupin vcpu='4' cpuset='5'/> + <vcpupin vcpu='5' cpuset='6'/> + <vcpupin vcpu='6' cpuset='7'/> + <vcpupin vcpu='7' cpuset='9'/> + </cputune> + <os> + <type arch='x86_64' machine='pc-q35-7.2'>hvm</type> + <loader readonly='yes' type='pflash'>/opt/macos/OVMF_CODE_TEST.fd</loader> + <nvram>/opt/macos/OVMF_VARS_TEST.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'> + <topology sockets='1' dies='1' cores='4' threads='2'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x8'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x9'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0xc'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='c8:2a:14:55:1a:b2'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </interface> + <interface type='bridge'> + <mac address='c8:2a:14:32:2c:ff'/> + <source bridge='br1'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='keyboard' bus='ps2'/> + <input type='mouse' bus='ps2'/> + <audio id='1' type='none'/> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </source> + <rom file='/opt/gpu-bios/6900xt.rom'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/> + </source> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x046d'/> + <product id='0x0892'/> + </source> + <address type='usb' bus='0' port='2'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x148f'/> + <product id='0x3070'/> + </source> + <address type='usb' bus='0' port='1'/> + </hostdev> + <watchdog model='itco' action='reset'/> + <memballoon model='none'/> + </devices> + <qemu:commandline> + <qemu:arg value='-smbios'/> + <qemu:arg value='type=2'/> + <qemu:arg value='-global'/> + <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-speed=8'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-width=16'/> + <qemu:arg value='-cpu'/> + <qemu:arg value='host,+hypervisor,migratable=no,-erms,kvm=on,+invtsc,+topoext,+avx,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+arat,+pclmuldq,+pdpe1gb,+rdtscp,+vme,+umip,check'/> + </qemu:commandline> +</domain> +``` + +06:00.0/1 --> gpu\ +00:1b.0 --> audio\ +0c:00.0 --> sata controller\ +84:00.0 --> usb controller\ +0x046d 0x0892 --> usb webcam\ +0x148f 0x3070 --> usb wifi + + + +[] diff --git a/results/classifier/zero-shot/108/permissions/1636 b/results/classifier/zero-shot/108/permissions/1636 new file mode 100644 index 000000000..448b05dac --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1636 @@ -0,0 +1,117 @@ +permissions: 0.924 +graphic: 0.861 +performance: 0.857 +device: 0.816 +other: 0.814 +debug: 0.812 +files: 0.789 +PID: 0.780 +semantic: 0.778 +socket: 0.762 +KVM: 0.742 +boot: 0.741 +network: 0.726 +vnc: 0.691 + +RISCV: Interrupt not cleared correctly (supervisor external IRQ) +Description of problem: + +Steps to reproduce: +1. Set mie -> 0 +2. Assert all interrupt sources which can be taken in M-mode (i.e. set mei, msi, mti, sei, ssi, sti) +3. I'm using the imsic for the external interrupts and the clint for timer interrupts. +4. Once all IRQs are pending set mie -> 0xFFFF +5. IRQs are taken one by one, all M-level IRQs are cleared without issues. +6. The issue occurs when trying to clear the S-external IRQ, when writing stopei to clear the IRQ mip is not updated correctly. + +I believe I have located the issue in target/riscv/cpu.c:1314 + +**Old code:** +``` +riscv_cpu_update_mip(cpu, 1 << irq, + BOOL_TO_MASK(level | env->software_seip)); +``` +**Changed code:** +``` +riscv_cpu_update_mip(cpu, 1 << irq, + BOOL_TO_MASK(level)); +``` + +When we reach the next code snippet (cpu_helper.c:628) we enter cpu_interrupt instead of cpu_reset_interrupt and thus end up in an infinite loop since the imsic message from that point on will be 0. It looks weird to me to use env->software_seip and not env->external_seip, in any case I changed it to BOOL_TO_MASK(level) and I now see the behavior I expect from my test program. + +```c + env->mip = (env->mip & ~mask) | (value & mask); + + if (env->mip | vsgein | vstip) { + cpu_interrupt(cs, CPU_INTERRUPT_HARD); + } else { + cpu_reset_interrupt(cs, CPU_INTERRUPT_HARD); + } + +``` +Additional information: +Log when getting the error. +``` +TRACE: [src/hart_ctrl.c:35] STARTING CPU 0 +DEBUG: [src/trap_handling.c: 938] Setting up trap handlers +TRACE: [src/page_tables.c:341] Setting up page tables between 0x80000000 -> 0x81c00000 +TRACE: [src/page_tables.c:355] Setting up page tables for UART 0x10000000 +TRACE: [src/page_tables.c:365] Setting up page tables for CLINT 0x2000000 +DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x24000000 +DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x28000000 +DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x28001000 +DEBUG: [src/util_fn.c: 339] Setting satp: 0x8000100000081017 +DEBUG: [src/util_fn.c: 342] Setting hgatp: 0x8000000000081014 +TRACE: [src/main.c:40] Asserting M-level interrupts simultaneously +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine external interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine software interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine timer interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor external interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor software interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor timer interrupt +riscv_cpu_do_interrupt: hart:0, async:1, cause:000000000000000b, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_external +DEBUG: [src/trap_handling.c: 315] mtvec_mei +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause machine external interrupt +DEBUG: [src/trap_handling.c: 76] Cause machine external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +DEBUG: [src/aia_ctrl.c: 352] Popped IMSIC message = 1 +riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000003, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_software +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause machine software interrupt +DEBUG: [src/trap_handling.c: 76] Cause machine software interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000007, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_timer +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause machine timer interrupt +DEBUG: [src/trap_handling.c: 76] Cause machine timer interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000009, epc:0x0000000080004d80, tval:0x0000000000000000, desc=s_external +DEBUG: [src/trap_handling.c: 296] mtvec_sei +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause supervisor external interrupt +DEBUG: [src/trap_handling.c: 76] Cause supervisor external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +mip + ssip (1) = 1 + vssip(2) = 0 + msip (3) = 0 + stip (5) = 1 + vstip(6) = 0 + mtip (7) = 0 + seip (9) = 1 + vseip(10) = 0 + meip (11) = 0 + sgeip(12) = 0 +DEBUG: [src/aia_ctrl.c: 339] Writing stopei -> 0 +DEBUG: [src/aia_ctrl.c: 344] stopei = 0x0000000000000000 +DEBUG: [src/aia_ctrl.c: 352] Popped IMSIC message = 1 +mip + ssip (1) = 1 + vssip(2) = 0 + msip (3) = 0 + stip (5) = 1 + vstip(6) = 0 + mtip (7) = 0 + seip (9) = 1 + vseip(10) = 0 + meip (11) = 0 + sgeip(12) = 0 +riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000009, epc:0x0000000080004d80, tval:0x0000000000000000, desc=s_external +DEBUG: [src/trap_handling.c: 296] mtvec_sei +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause supervisor software interrupt +DEBUG: [src/trap_handling.c: 76] Cause supervisor external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +ERROR: [src/trap_handling.c:121] The following assert failed: masked_cause == cause2check +masked_cause = 9 diff --git a/results/classifier/zero-shot/108/permissions/1636217 b/results/classifier/zero-shot/108/permissions/1636217 new file mode 100644 index 000000000..d49a8b42a --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1636217 @@ -0,0 +1,245 @@ +permissions: 0.957 +other: 0.942 +vnc: 0.942 +device: 0.935 +PID: 0.930 +semantic: 0.923 +debug: 0.919 +files: 0.917 +boot: 0.905 +socket: 0.893 +graphic: 0.891 +KVM: 0.888 +network: 0.880 +performance: 0.837 + +qemu-kvm 2.7 does not boot kvm VMs with virtio on top of VMware ESX + +After todays Proxmox update all my Linux VMs stopped booting. + +# How to reproduce +- Have KVM on top of VMware ESX (I use VMware ESX 6) +- Boot Linux VM with virtio Disk drive. + + +# Result +virtio based VMs do not boot anymore: + +root@demotuxdc:/etc/pve/nodes/demotuxdc/qemu-server# grep virtio0 100.conf +bootdisk: virtio0 +virtio0: pvestorage:100/vm-100-disk-1.raw,discard=on,size=20G + +(initially with cache=writethrough, but that doesn´t matter) + +What happens instead is: + +- BIOS displays "Booting from harddisk..." +- kvm process of VM loops at about 140% of Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz Skylake dual core CPU + +Disk of course has valid bootsector: + +root@demotuxdc:/srv/pvestorage/images/100# file -sk vm-100-disk-1.raw +vm-100-disk-1.raw: DOS/MBR boot sector DOS/MBR boot sector DOS executable (COM), boot code +root@demotuxdc:/srv/pvestorage/images/100# head -c 2048 vm-100-disk-1.raw | hd | grep GRUB +00000170 be 94 7d e8 2e 00 cd 18 eb fe 47 52 55 42 20 00 |..}.......GRUB .| + + +# Workaround 1 +- Change disk from virtio0 to scsi0 +- Debian boots out of the box after this change +- SLES 12 needs a rebuilt initrd +- CentOS 7 too, but it seems that is not even enough and it still fails (even in hostonly="no" mode for dracut) + + +# Workaround 2 +Downgrade pve-qemu-kvm 2.7.0-3 to 2.6.2-2. + + +# Expected results +Disk boots just fine via virtio like it did before. + + +# Downstream bug report +Downstream suggests an issue with upstream qemu-kvm: + +https://bugzilla.proxmox.com/show_bug.cgi?id=1181 + + + +I traced this back to the switch to enabling virtio-1 mode by default in 2.7 in commit 9a4c0e220d8a4f82b5665d0ee95ef94d8e1509d5 + +forcing the old behaviour with a 2.6 machine type works. + +I confirm that "qm set ID -machine pc-i440fx-2.6" on the machine in question lets it boot as a virtio machine again with Qemu 2.7. + +Adding Gerd, Marcel, and Kevin + +On 10/28/16 10:23, Fabian Grünbichler wrote: +> I traced this back to the switch to enabling virtio-1 mode by default in +> 2.7 in commit 9a4c0e220d8a4f82b5665d0ee95ef94d8e1509d5 +> +> forcing the old behaviour with a 2.6 machine type works. + +I think this issue is a duplicate of the following RHBZ: + +https://bugzilla.redhat.com/show_bug.cgi?id=1373154 + +and the *SeaBIOS* commit that makes it all work again is: + +commit 0e21548b15e25e010c362ea13d170c61a3fcc899 +Author: Gerd Hoffmann <email address hidden> +Date: Fri Jul 3 11:07:05 2015 +0200 + + virtio: pci cfg access + +That SeaBIOS commit is part of the SeaBIOS 1.10.0 release. + +However, QEMU 2.7 shipped with bundled SeaBIOS 1.9.3 binaries. See QEMU +commits 6e03a28e1cee (part of v2.7.0) and 6e99f5741ff1 (not part of any +tagged release yet). + +The fix is probably the following: +- backport SeaBIOS commit 0e21548b15e2 to the stable 1.9 branch, for + release 1.9.4 +- bundle SeaBIOS 1.9.4 binaries with QEMU v2.7.1. + +Thanks +Laszlo + + +unfortunately cherry-picking the SeaBIOS 1.10 binary update commit from qemu master (6e99f5741ff1) on top of v2.7.0 does not solve the issue (the only observable change is the version string that is displayed on booting, right when it hangs ;)). + +I can still give your suggested route a try if you think it is worth it, but since the 1.10 release contains your suggested commit, I doubt it will change anything.. + +> However, QEMU 2.7 shipped with bundled SeaBIOS 1.9.3 binaries. See QEMU +> commits 6e03a28e1cee (part of v2.7.0) and 6e99f5741ff1 (not part of any +> tagged release yet). +> +> The fix is probably the following: +> - backport SeaBIOS commit 0e21548b15e2 to the stable 1.9 branch, for +> release 1.9.4 +> - bundle SeaBIOS 1.9.4 binaries with QEMU v2.7.1. + +I'd rather cherry-pick 6e99f5741ff1 into 2.7.1 ... + +cheers, + Gerd + + +This problem still exists as of now on Debian sid. Qemu version is "QEMU emulator version 2.10.1(Debian 1:2.10.0+dfsg-2)". + + +for "-machine type=pc-i440fx-x" where x > 2.6, all stuck at boot if the interface is virtio. + +I use nested virtualization where the first level is VMWARE FUSION (might not be the same as ESX), and the second is qemu-kvm. + + +Hi, + +I have exactly the same problem. + +My stack: +- macOS Sierra 10.12.6 +- VMware Fusion 10.1.1 (tried with 10.0.1 too) +- Linux 4.9.78 (tried with 4.9.65 too) +- Qemu 2.11.0 (tried with 2.10.1 too) + +All is working great with i440fx (or q35) <= 2.6 but it doesn't boot on >= 2.7 and QEMU takes all the CPU. + +It doesn't boot with the disk in virtio and scsci-virtio mode but boot in scsi. + +Exactly the same configuration on a baremetal (so no macOS and VMware) works great. + +So I assume it's a bug with VMware and virtio. + +we still meet similar issue on centos.7 (qemu 2.9.0-16.el7_4.5.1 + libvirt 3.2.0-14.el7_4.3) + +my workaround including: +a) without kvm accel +or +b) as comment #7 said "-machine type=pc-i440fx-x" where x <= 2.6 +or +c) with pci device "disable-modern=on" + +i found the function _farcall16 in seabios was invoked (https://github.com/coreboot/seabios/blob/af0daeb2687ad2595482b8a71b02a082a5672ceb/src/stacks.c#L418) +and failed when guest hang with 'Booting from hard disk'. + +the invoking sequence (in seabios rel-1.11.0-5-g14d91c3) like : +src/boot.c line 614, call_boot_entry-> +src/stacks.c line 427, farcall16-> +src/stack.c line 411, _farcall16 + + +but the issue perform diff in our two clusters. + +I just name them cluster A(6.0.0.0 3029758 E5 2640 v2,ststem x3650 M4) and cluster B (6.0.0.0 3029758 E5 2620 v4,system x3650 M5)for easy. + +This issue in cluster B not be reproduced in cluster A(same qemu/libvirt/esxi) + +my command: +/usr/libexec/qemu-kvm -machine pc-i440fx-rhel7.3.0 \ +-m 256 -drive file=centos.qcow2,if=none,id=drive-virtio-disk0 \ +-device virtio-blk-pci,disable-modern=on,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 \ +-vnc :1 -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios + +hope the above info can help fix the bug. + + +I'd like to share some other available workarounds: + +1. Use "-machine type=pc-i440fx-x" where x <= 2.6 +2. Add "disable-modern=on" option for all virtio block devices +3. Add "-global virtio-blk-pci.disable-modern=on" +3. Use software acceleration for virtual appliances ("-machine accel=tcg") + +Hi Mykola. Thanks you for this information. Any idea about advantages / disadvantages of the different work-arounds? Thanks. + +Well, it appeared that it is not enough to set "disable-modern=on" for virtio-blk-pci devices. You have to do the same for virtio-scsi-pci, and may be for other virtio devices you are using to disable virtio 1.0. But VM will hangs latter on during boot process if you use virtio-rng-pci. + +"-machine accel=tcg" will work but in cost of performance penalty due to software virtualization. + +So I found "-machine type=pc-i440fx-x" where x <= 2.6 the only reliable workaround. + +This is a KVM bug. It has been fixed in mainstream Linux in + +commit d391f1207067268261add0485f0f34503539c5b0 +Author: Vitaly Kuznetsov <email address hidden> +Date: Thu Jan 25 16:37:07 2018 +0100 + + x86/kvm/vmx: do not use vm-exit instruction length for fast MMIO when running nested + + I was investigating an issue with seabios >= 1.10 which stopped working + for nested KVM on Hyper-V. The problem appears to be in + handle_ept_violation() function: when we do fast mmio we need to skip + the instruction so we do kvm_skip_emulated_instruction(). This, however, + depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS. + However, this is not the case. + + Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when + EPT MISCONFIG occurs. While on real hardware it was observed to be set, + some hypervisors follow the spec and don't set it; we end up advancing + IP with some random value. + + I checked with Microsoft and they confirmed they don't fill + VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG. + + Fix the issue by doing instruction skip through emulator when running + nested. + + Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae + Suggested-by: Radim Krčmář <email address hidden> + Suggested-by: Paolo Bonzini <email address hidden> + Signed-off-by: Vitaly Kuznetsov <email address hidden> + Acked-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Radim Krčmář <email address hidden> + + +Although the commit mentions Hyper-V as L0 hypervisor, the same problem +pertains to ESXi. + +The commit is included in v4.16. + +That is great news. Thanks for sharing! + +Marking as fixed, according to comment #13 + diff --git a/results/classifier/zero-shot/108/permissions/1639394 b/results/classifier/zero-shot/108/permissions/1639394 new file mode 100644 index 000000000..79b84c809 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1639394 @@ -0,0 +1,135 @@ +permissions: 0.971 +debug: 0.968 +semantic: 0.962 +other: 0.953 +graphic: 0.946 +device: 0.939 +boot: 0.938 +files: 0.916 +PID: 0.916 +performance: 0.907 +vnc: 0.896 +network: 0.819 +KVM: 0.805 +socket: 0.786 + +Unable to boot Solaris 8/9 x86 under Fedora 24 + +qemu-system-x86_64 -version +QEMU emulator version 2.6.2 (qemu-2.6.2-4.fc24), Copyright (c) 2003-2008 Fabrice Bellard + +Try several ways without success, I think it was a regression because problem seems to be related with ide fixed on 0.6.0: +- int13 CDROM BIOS fix (aka Solaris x86 install CD fix) +- int15, ah=86 BIOS fix (aka Solaris x86 hardware probe hang up fix) + +Solaris 10/11 works without a problem, also booting with "scsi" will circumvent initial problem, but later found problems related with "scsi" cdrom boot and also will not found the "ide" disk device. + + +qemu-system-i386 -m 712 -drive file=/dev/Virtual_hdd/beryllium0,format=raw -cdrom /repo/Isos/sol-9_905_x86.iso + +SunOS Secondary Boot version 3.00 + +prom_panic: Could not mount filesystem. +Entering boot debugger: +[136419] + + +Regards, +\\CA, + +So, if I'm reading you right, Solaris10/11 work just fine, but 8/9 don't -- and have not since qemu version 0.6.0!? From 2004? + +I don't have a copy of Solaris9 to test with, so I doubt I can work on trying to reproduce this. Is there any possibility to reproduce a problem on an older, freely available BSD? + + +yes, 10/11/12 beta work without a problem(and really fast), 8/9 have been +reported to work at least since 0.6.0. with the "ide" fix committed to that +version. +The problem seems related with "ide" emulation and real mode drivers, so I +don't think an older BSD can reproduce. +I will test if an older BSD is also affected by this, I can also provide +you a place for you to get the versions 8/9 x86 iso, if that is ok +in any way. +Many thanks for the time on checking this one. + +On Tue, Nov 8, 2016 at 11:13 PM, John Snow <email address hidden> +wrote: + +> So, if I'm reading you right, Solaris10/11 work just fine, but 8/9 don't +> -- and have not since qemu version 0.6.0!? From 2004? +> +> I don't have a copy of Solaris9 to test with, so I doubt I can work on +> trying to reproduce this. Is there any possibility to reproduce a +> problem on an older, freely available BSD? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1639394 +> +> Title: +> Unable to boot Solaris 8/9 x86 under Fedora 24 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1639394/+subscriptions +> + + +Sorry, I don't understand. + +The two fixes you mentioned were committed and released as part of 0.6.0, so does this work with QEMU version 0.6.0 or not? + +If it works in 0.6.0, can you tell me the first version where it stopped working? I assume it isn't currently working in 2.6.2, so it broke sometime inbetween, is that correct? + +I'm not sure if I am able to download a solaris iso that you've found. However, if you are able to contributes patches upstream, I am willing to review them. + +[Expired for QEMU because there has been no activity for 60 days.] + +I also have this problem. On both QEMU 5.2.0 and QEMU 3.1. The situation is still the same as the original report. +For Solaris 8 the following configuration causes an error when the installer attempts to boot: +-m 256M -display gtk -monitor stdio -hda Sol8.qcow2 -cdrom sol8_x86_install.ISO -boot d -machine pc +The error is given as "prom_panic: Could not mount filesystem", the same as reported originally. It does this even when "hda" is not specified. +I can get into the installer by using SCSI devices instead (as alluded to originally) but the SCSI devices are not detected correctly by the installer and it cannot find the boot media. +A slightly different problem occurs with Solaris 7. This configuration (only CDROM) allows the installer to run and it detects the CDROM media correctly: -m 256M -display gtk -monitor stdio -boot a -fda sol-7_boot.img -cdrom sol-7.iso +But when a "hda" hard disk device is introduced the installer does not load, instead hanging on the first stage (where Solaris 8 installer gives the error). +To ensure the ISO was not corrupted or similar I used VirtualBox which works as expected. + +I have to admit that my time budget for IDE is quite low, so I will be unable to look into this. + +If you'd like to help debug it further and you have the time, you can try building QEMU 6.0 (RC0 or so, something quite modern) and enabling the IDE tracing options and trying to boot Solaris as you have been doing, The logs might help illustrate something obviously wrong. + +You want to enable IDE traces (but exclude the ones that show the actual IO data), so you need an events file that looks something like this; + +ide_ioport_read +ide_ioport_write +ide_status_read +ide_ctrl_write +ide_exec_cmd +ide_cancel_dma_sync_buffered +ide_cancel_dma_sync_remaining +ide_sector_read +ide_sector_write +ide_reset +ide_bus_reset_aio +ide_dma_cb +cd_read_sector_sync +cd_read_sector_cb +cd_read_sector +ide_atapi_cmd_error +ide_atapi_cmd_reply_end +ide_atapi_cmd_reply_end_eot +ide_atapi_cmd_reply_end_bcl +ide_atapi_cmd_reply_end_new +ide_atapi_cmd_check_status +ide_atapi_cmd_read +ide_atapi_cmd +ide_atapi_cmd_read_dma_cb_aio + +And use it using `--trace events=ide_events_file`. A full list of trace events can be found here: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ide/trace-events + +If you can trigger it without `-hda`, it would be good to leave it off to help minimize log reports for IDE devices unrelated to problem. + +Hello, I believe I have solved the underlying issue with the attached patch. Verified against the behavior of an actual i440FX IDE controller. + +See https://lists.nongnu.org/archive/html/qemu-devel/2022-05/msg04229.html . + diff --git a/results/classifier/zero-shot/108/permissions/1644754 b/results/classifier/zero-shot/108/permissions/1644754 new file mode 100644 index 000000000..066f0a8d4 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1644754 @@ -0,0 +1,121 @@ +permissions: 0.991 +other: 0.985 +debug: 0.981 +semantic: 0.973 +PID: 0.972 +performance: 0.971 +graphic: 0.970 +boot: 0.964 +socket: 0.958 +device: 0.939 +vnc: 0.928 +files: 0.925 +KVM: 0.896 +network: 0.888 + +gluster partial reads refusal conflicts with qcow2 + +there is an inconsistency in how qemu creates qcow2 files, which causes an error in the gluster (and possibly other block drivers) + +the problem is that the gluster backend expects the filesize to be 512 byte aligned, which is not the case anymore since 2.7.0 when using the file backend for qcow2 files with a backing file + +the error is then +Could not open 'gluster://gluster01/gv0/bar2.qcow2': Could not read L1 table: Input/output error + +steps to reproduce: + + * create a.qcow2 + * create b.qcow2 with a.qcow2 as base via filesystem (without gluster) + b.qcow2 filesize is not a multiple of 512 bytes + * move both files to a gluster share + * access to b.qcow2 via gluster block driver fails + +example: + +have a gluster server at 'gluster01' with a volume 'gv0' (gluster versions tested: 3.7.15,3.8.5,3.8.5) + +root@pc:~# mount -t glusterfs gluster01:/gv0 /mnt/gluster +root@pc:~# qemu-img create -f qcow2 gluster://gluster01/gv0/foo.qcow2 100M +Formatting 'gluster://gluster01/gv0/foo.qcow2', fmt=qcow2 size=104857600 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/foo.qcow2 +image: /mnt/gluster/foo.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/foo.qcow2 +image: gluster://gluster01/gv0/foo.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img create -f qcow2 -b foo.qcow2 gluster://gluster01/gv0/bar.qcow2 +Formatting 'gluster://gluster01/gv0/bar.qcow2', fmt=qcow2 size=104857600 backing_file=foo.qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/bar.qcow2 +image: /mnt/gluster/bar.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: /mnt/gluster/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/bar.qcow2 +image: gluster://gluster01/gv0/bar.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: gluster://gluster01/gv0/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img create -f qcow2 -b foo.qcow2 /mnt/gluster/bar2.qcow2 +Formatting '/mnt/gluster/bar2.qcow2', fmt=qcow2 size=104857600 backing_file=foo.qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +root@pc:~# qemu-img info /mnt/gluster/bar2.qcow2 +image: /mnt/gluster/bar2.qcow2 +file format: qcow2 +virtual size: 100M (104857600 bytes) +disk size: 193K +cluster_size: 65536 +backing file: foo.qcow2 (actual path: /mnt/gluster/foo.qcow2) +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false +root@pc:~# qemu-img info gluster://gluster01/gv0/bar2.qcow2 +qemu-img: Could not open 'gluster://gluster01/gv0/bar2.qcow2': Could not read L1 table: Input/output error +root@pc:~# ls -l /mnt/gluster/ +total 578 +-rw-r--r-- 1 root root 196616 Nov 25 09:07 bar2.qcow2 +-rw------- 1 root root 197120 Nov 25 09:07 bar.qcow2 +-rw------- 1 root root 197120 Nov 25 09:06 foo.qcow2 +drwxr-xr-x 6 root root 46 Nov 24 16:51 images + +here you can see that the file created with directory path is not 512 byte aligned, while the one created through the gluster api is + +also, when creating a qcow2 with the nfs block driver, the filesize is also a multiple of 512, but reading a non aligned file with nfs works however + +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 all 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/zero-shot/108/permissions/1653419 b/results/classifier/zero-shot/108/permissions/1653419 new file mode 100644 index 000000000..524ee9020 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1653419 @@ -0,0 +1,95 @@ +permissions: 0.952 +other: 0.948 +device: 0.931 +performance: 0.922 +semantic: 0.916 +debug: 0.915 +graphic: 0.915 +PID: 0.896 +KVM: 0.896 +socket: 0.890 +files: 0.887 +vnc: 0.856 +network: 0.855 +boot: 0.828 + +SVM emulation fails due to EIP and FLAG register update optimization + +SVM emulation support has a bug due to which causes KVM emulation error when qemu-kvm is run over KVM installed on top of QEmu in software mode. + +Steps to reproduce +==================== +1. Run KVM inside QEmu(software mode with SVM emulation support). Make sure kvm_amd is running. +2. Run any guest OS on top of the KVM using qemu-kvm. +3. Following KVM emulation error is thrown immediately. + +KVM internal error. Suberror: 1 +emulation failure +EAX=ffffffff EBX=4000004b ECX=00000000 EDX=000f5ea0 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00006fd0 +EIP=40000000 EFL=00000086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 000f7180 00000037 +IDT= 000f71be 00000000 +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +Reason for the error +==================== +Due to performance reasons, EIP and FLAG registers are not updated after executing every guest instructions. There are optimizations done to update these registers intelligently, for eg: EIP is updated at the end of translation block. This means EIP remains the address of the first instruction in the TB throughout the execution. + +In case of a VMEXIT because of a page fault happened after executing an instruction in the middle of the TB, the VMCB is updated with the wrong guest EIP and jumps to the address where host has left off. On the subsequent VMRUN by the host QEmu start executing some of the instructions that has already been executed. This can cause wrong execution flow. + +Following is the instruction execution trace of the above scenario. + +0x00000000000f368f: callq 0xeecc4 +vmexit(00000060, 0000000000000000, 0000000000000000, 00000000000eecc4)! +vmsave! 00000000b72e9000 +vmload! 00000000b72e9000 +vmrun! 00000000b72e9000 +0x00000000000eecc4: push %rbx +0x00000000000eecc5: xor %ecx,%ecx +0x00000000000eecc7: mov (%rax,%rcx,1),%bl +0x00000000000eecca: cmp (%rdx,%rcx,1),%bl +vmexit(0000004e, 0000000000000000, 00000000000f5ea0, 00000000000eecc4)! + +Page fault happens at 0x00000000000eecca which triggers a VMEXIT. vmcb->save->rip is updated with 0x00000000000eecc4 instead of 0x00000000000eecca. + +vmsave! 00000000b72e9000 +vmload! 00000000b72e9000 +vmrun! 00000000b72e9000 +0x00000000000eecc4: push %rbx +0x00000000000eecc5: xor %ecx,%ecx +0x00000000000eecc7: mov (%rax,%rcx,1),%bl +0x00000000000eecca: cmp (%rdx,%rcx,1),%bl +0x00000000000eeccd: je 0xeecdc +0x00000000000eeccf: setl %al +0x00000000000eecd2: movzbl %al,%eax +0x00000000000eecd5: neg %eax +0x00000000000eecd7: or $0x1,%eax +0x00000000000eecda: jmp 0xeece3 +0x00000000000eece3: pop %rbx +0x00000000000eece4: retq +vmexit(0000004e, 0000000000000000, 0000000040000000, 0000000040000000)! + +The subsequent VMRUN again starts executing from 0x00000000000eecc4 which causes %rbx being pushed to the stack for the second time. The retq instruction picks wrong return address and jumps to an illegal location. + +Similar issue is there with updating FLAG register as well. + +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 all 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/zero-shot/108/permissions/1668103 b/results/classifier/zero-shot/108/permissions/1668103 new file mode 100644 index 000000000..299cb6ce4 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1668103 @@ -0,0 +1,85 @@ +permissions: 0.942 +semantic: 0.930 +other: 0.927 +device: 0.905 +PID: 0.900 +graphic: 0.898 +performance: 0.887 +debug: 0.883 +vnc: 0.882 +network: 0.880 +socket: 0.875 +boot: 0.863 +files: 0.842 +KVM: 0.787 + +Possible off-by-one error in priority handling of hw/PL190.c + +I have a problem when reading back VECTADDR in my proprietary OS's interrupt handler. + +Example client code: + + 1) Write INTENCLEAR to clear all interrupt enable bits + 2) Set all 16 vector control registers to zero + 3) Set vector address #2 to value 2 + 4) Set vector control #2 to 0x21 (vector_interrupt_enable(0x20) | vector_interrupt_source(0x1) ) + 5) Enable interrupt 1 by writing 0x2 to INTENABLE + 6) In interrupt handler: read VECTADDR [should read 0x2 (active IRQs vector address as set in step 3), reads 0x0 (active vector address index 3 instead of index 2)] + +Problem: + +So, for me, the block commented with /* Read vector address at the start of an ISR... */ in hw/pl190.c has an off by-one error and does not return the vector address of the pending interrupt, but of the next one in the list of priorities (i.e. vector address 3). + +Solution: + +In pl190_update_vectors(), also set the priority bit for the current priority (1<<i) interrupt (if enabled) in s->prio_mask[i] in addition to those of higher priority enabled interrupts. This will cause the loop in the read handling of VECTADDR to terminate an iteration earlier and will deliver the correct interrupt priority as iteration variable i subsequently used for addressing. + +I'll try to provide a patch for this. + +From 0cd0c1346f9adb7b90df3e4e30a5904eeda33bfa Mon Sep 17 00:00:00 2001 +From: Marc Bommert <email address hidden> +Date: Sun, 26 Feb 2017 22:08:49 +0100 +Subject: [PATCH] Fix off-by-one error in priority handling when reading + VECTADDR: Also, if enabled, have the "current" priority bit (1<<i) set in + s->prio_mask[i]. + +Signed-off-by: Marc Bommert <email address hidden> +--- + hw/intc/pl190.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/hw/intc/pl190.c b/hw/intc/pl190.c +index 55ea15d..0369da8 100644 +--- a/hw/intc/pl190.c ++++ b/hw/intc/pl190.c +@@ -80,12 +80,12 @@ static void pl190_update_vectors(PL190State *s) + mask = 0; + for (i = 0; i < 16; i++) + { +- s->prio_mask[i] = mask; + if (s->vect_control[i] & 0x20) + { + n = s->vect_control[i] & 0x1f; + mask |= 1 << n; + } ++ s->prio_mask[i] = mask; + } + s->prio_mask[16] = mask; + pl190_update(s); +-- +2.5.0 + + +"Fix committed" doesn't seem right -- that's only when a patch is actually committed to QEMU's git tree... + + +We do not take patches from the bug tracker, please send it to the qemu-devel mailing list instead. See http://wiki.qemu-project.org/Contribute/SubmitAPatch for details. + +For a one-off one-liner bugfix patch it's easier for me to grab it from the bug tracker than require the submitter to resend, though... I'll have a look at it later today. + + + +This turns out to be because Marc had a very out-of-date copy of pl190.c which was missing the fix for this bug in commit 14c126baf1c38607c5b. (Further discussion in list thread +https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg06580.html). + + diff --git a/results/classifier/zero-shot/108/permissions/1679126 b/results/classifier/zero-shot/108/permissions/1679126 new file mode 100644 index 000000000..adfddfd23 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1679126 @@ -0,0 +1,106 @@ +permissions: 0.955 +graphic: 0.944 +performance: 0.937 +other: 0.933 +device: 0.930 +boot: 0.929 +KVM: 0.921 +vnc: 0.919 +socket: 0.918 +semantic: 0.917 +files: 0.900 +debug: 0.891 +PID: 0.883 +network: 0.783 + +null pointer access on migration resume of systemrescuecd boot menu with qxl-vga + +With qemu-2.8.0 up to 2.9.0-rc2 and git master (6954cdc), when resuming from a migration state file created from a VM suspended while showing the System Rescue CD 4.9.2 boot menu and using the QXL VGA device, I get a null point access in pixman_image_get_data called from qemu_spice_create_update (spice-display.c:215). When I added assert(ssd->mirror != NULL) above that line, assert failed. I don't get the crash when using standard VGA or cirrus-vga. I am using gcc-4.9.3 on Gentoo x86_64 with Intel i7-4700HQ CPU and kernel: 4.9.15-gentoo. + +Here is the valgrind trace from the git version: +==2634== Thread 1: +==2634== Invalid read of size 4 +==3516== at 0x65F3050: pixman_image_get_data (in /usr/lib64/libpixman-1.so.0.34.0) +==3516== by 0x6F0CEB: qemu_spice_create_update (spice-display.c:215) +==3516== by 0x6F1CC7: qemu_spice_display_refresh (spice-display.c:502) +==3516== by 0x58CF77: display_refresh (qxl.c:1948) +==3516== by 0x6E8084: do_safe_dpy_refresh (console.c:1591) +==3516== by 0x6E80D5: dpy_refresh (console.c:1604) +==3516== by 0x6E4508: gui_update (console.c:201) +==3516== by 0x81898E: timerlist_run_timers (qemu-timer.c:536) +==3516== by 0x8189D6: qemu_clock_run_timers (qemu-timer.c:547) +==3516== by 0x818D98: qemu_clock_run_all_timers (qemu-timer.c:662) +==3516== by 0x81952A: main_loop_wait (main-loop.c:514) +==3516== by 0x4ADD29: main_loop (vl.c:1898) + +Minimal steps to reproduce: + +Compile (debug compile flags are just so valgrind works, the crash occurs with non-debug compile flags as well): +CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure --target-list=i386-softmmu,x86_64-softmmu +./configure +make + +Start VM and leave it on the System Rescue CD graphical boot menu: +x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor unix:monitor.sock,server,nowait -display gtk + +Suspend VM and save state: +socat - unix:monitor.sock + stop + migrate "exec:cat > vm.state" + quit + +Attempt to resume VM (but this crashes): +x86_64-softmmu/qemu-system-x86_64 -nodefaults -machine pc -drive file=systemrescuecd-x86-4.9.2.iso,if=none,id=cdrom-cd,readonly=on -device ide-cd,bus=ide.0,drive=cdrom-cd,bootindex=1 -device qxl-vga -monitor unix:monitor.sock,server,nowait -display gtk -incoming exec:"cat vm.state" + +Yep, I can repeat this here on qemu head; crash at: + +pixman_image_get_data (image=0x0) at pixman-image.c:845 +845 if (image->type == BITS) + +(gdb) p image +$1 = (pixman_image_t *) 0x0 + + +I think this is actually anything that's in text mode grub; I've had a RHEL5 and 6 VM do it as well. + +Thanks for reporting it. + + +Interesting, the culprit is: + +commit cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Author: Marc-André Lureau <email address hidden> +Date: Fri Aug 26 13:47:11 2016 +0400 + + console: skip same-size resize + + virtio-gpu does a set-scanout at each frame (it might be a driver + regression). qemu_console_resize() recreate a surface even if the size + didn't change, and this shows up in profiling reports because the + surface is cleared. With this patch, I get a +15-20% glmark2 + improvement. + + Signed-off-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + +diff --git a/ui/console.c b/ui/console.c +index 3940762851..394786b3c7 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2101,6 +2101,13 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + DisplaySurface *surface; + + assert(s->console_type == GRAPHIC_CONSOLE); ++ ++ if (s->surface && ++ pixman_image_get_width(s->surface->image) == width && ++ pixman_image_get_height(s->surface->image) == height) { ++ return; ++ } + + +The fix has apparently been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a703d3aef5991b72a5a45880e7491232b8032f09 +... and has been released with QEMU v2.9 already. + diff --git a/results/classifier/zero-shot/108/permissions/1687270 b/results/classifier/zero-shot/108/permissions/1687270 new file mode 100644 index 000000000..9e30478f4 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1687270 @@ -0,0 +1,36 @@ +permissions: 0.965 +files: 0.952 +device: 0.755 +graphic: 0.725 +performance: 0.705 +semantic: 0.686 +other: 0.656 +network: 0.655 +vnc: 0.583 +socket: 0.558 +boot: 0.541 +PID: 0.446 +debug: 0.406 +KVM: 0.396 + +Can't write to 9p shared folder with qemu 2.9.0 + +When running a virtual machine with qemu 2.9.0 with this parameter for sharing a folder: + +-virtfs local,id=fsdev1,path=$HOME/git,security_model=none,mount_tag=git + +then the folder is shared to the VM but in some subfolders I can't delete files. The guest system then reports that the file, I want to delete, is "no file or folder". + +I've downgraded to 2.8.0 now, which re-enables deleting my files. + +Is this a known bug which will be fixed with a future version? + +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. + +Independent of the tracker transition, some feedback to your report: from what you described so far, the most common cause for the behaviour you described is a simple file permission issue on host side. Please check which user your qemu process is running with there, then ensure that the files you want to be able to access from guest by 9p has the appropriate file permissions for that user on host side. + +If the problem still persists there, then please provide more details about your configuration, especially an output of some files and their permissions on host side. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1689 b/results/classifier/zero-shot/108/permissions/1689 new file mode 100644 index 000000000..0ef131a0d --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1689 @@ -0,0 +1,26 @@ +permissions: 0.983 +boot: 0.943 +files: 0.933 +performance: 0.922 +device: 0.890 +graphic: 0.882 +other: 0.873 +semantic: 0.851 +debug: 0.699 +network: 0.560 +PID: 0.557 +vnc: 0.547 +socket: 0.305 +KVM: 0.270 + +memory backend file unnecessarily requires write permission while it is only mapped privately +Description of problem: +One day I wanted to boot the machine with physical memory initialized with a file, in a copy-on-write style. That is why I tried out `-mem-path` and `-object memory-backend-file`. Actually `-mem-path` already works if not considering that qemu dislikes the backing file being readonly and requires it to be writeable even when only private mappings are used here. + +I sadly found out that when using memory-backend-file, and when `share=off`, if `readonly=on`, then file is `open`ed with `O_RDONLY` and mmap prot is `PROT_READ`; if `readonly=off`, then the file is `open`ed with `O_RDWR` and mmap prot is `PROT_READ|PROT_WRITE`. I want `O_RDONLY` and `PROT_READ|PROT_WRITE` but I cannot find it anywhere. + +In my opinion, expected behavior should be that if `share=off`, the file can already be opened with `O_RDONLY` no matter what prot the mmap is. That is how linux `MAP_PRIVATE` works - basically copy on write. When I only need copy on write for the content of file, why do I require write permission for it? + +Now I cannot find a setup that opens the file with `fd=open(*, O_RDONLY)` and mmap it with `mmap(*, *, PROT_READ|PROT_WRITE, MAP_PRIVATE|*, fd, *)`. + +Tell me if I misunderstood linux (for example certain file behave differently if one open with O_RDONLY and this behavior is necessary) or qemu or other posix systems where copy-on-write does not work like this. diff --git a/results/classifier/zero-shot/108/permissions/1696353 b/results/classifier/zero-shot/108/permissions/1696353 new file mode 100644 index 000000000..fa7e98b82 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1696353 @@ -0,0 +1,116 @@ +semantic: 0.961 +permissions: 0.957 +vnc: 0.955 +other: 0.944 +device: 0.942 +graphic: 0.934 +PID: 0.931 +debug: 0.915 +performance: 0.907 +KVM: 0.899 +files: 0.883 +socket: 0.851 +network: 0.851 +boot: 0.835 + +golang binaries fail to start under linux-user + +With current master golang binaries fail when run under linux-user, for example: + +[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x45f879, 0x9) + /usr/lib/golang/src/runtime/panic.go:566 +0x78 +runtime.newosproc(0x1092c000, 0x1093bfe0) + /usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0 +runtime.newm(0x4ae1e8, 0x0) + /usr/lib/golang/src/runtime/proc.go:1572 +0x12c +runtime.main.func1() + /usr/lib/golang/src/runtime/proc.go:126 +0x24 +runtime.systemstack(0x5ef900) + /usr/lib/golang/src/runtime/asm_arm.s:247 +0x80 +runtime.mstart() + /usr/lib/golang/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac sp=0x109287a8 +runtime.main() + /usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4 sp=0x109287ac +runtime.goexit() + /usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4 sp=0x109287d4 + +The reason for this is that the golang runtime does not pass the CLONE_SYSVMEM flag to clone so the clone flags checks fail: + +https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155 + +The attached patch allows golang binaries to start under linux-user. + + + +The problem with doing that is that it doesn't actually change the behaviour. We use pthread_create to create the new thread, which glibc does with a clone with CLONE_SYSVSEM set. We can't tell the difference between "guest program needs the new threads to not share SysV semaphore behaviour" and "guest program doesn't care but didn't provide the flag" so we err on the side of caution and refuse to create a thread that doesn't behave the way the guest asked us for it to behave. + + +True, but it used to work albeit with slightly wrong semantics. It now fails hard even though the golang runtime doesn't make any use of Sys V semaphores so the presence of the flag is not noticeable by any normal user. + +You can also apply this patch to go - I don't have an opinion on the correct course of action though! + +diff --git a/src/runtime/os_linux.go b/src/runtime/os_linux.go +index a6efc0e3d1..64218e3f7e 100644 +--- a/src/runtime/os_linux.go ++++ b/src/runtime/os_linux.go +@@ -132,7 +132,8 @@ const ( + _CLONE_FS | /* share cwd, etc */ + _CLONE_FILES | /* share fd table */ + _CLONE_SIGHAND | /* share sig handler table */ +- _CLONE_THREAD /* revisit - okay for now */ ++ _CLONE_THREAD | /* revisit - okay for now */ ++ _CLONE_SYSVSEM + ) + + //go:noescape + + +Note that there is a go bug about this issue too: https://github.com/golang/go/issues/20763 + +The go team have applied the above patch and I can confirm that it is now working properly using go-tip. This means it will be fixed in go 1.10. + +So if you recompile your go binary with go-tip or go 1.10 when it is released, it will run fine under qemu-system-arm. + +Since this has been fixed/worked around on the go side (thanks for following up with that!) I'm going to close this as "wontfix" on QEMU's side. It would be nice to support clone() with non-standard flags but since we can't do that while we still link with libc there's no way we can do this without a massive (and massively painful!) redesign to remove our libc dependency so that all of QEMU's linux-user code runs bare on the kernel. + + +I just gave it a test with qemu-arm and Go binaries still crash for me, albeit differently: + +root@nofan:/# cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} +root@nofan:/# gccgo-7 hello.go -o hello +root@nofan:/# ./hello +mmap errno 9 +fatal error: mmap + +runtime stack: +mmap errno 9 +fatal error: mmap +panic during panic + +runtime stack: +mmap errno 9 +fatal error: mmap +stack trace unavailable +root@nofan:/# + +Should I file a new bug report? + +Yes, new bug please, that's definitely a different symptom and likely an unrelated issue. + + diff --git a/results/classifier/zero-shot/108/permissions/1700380 b/results/classifier/zero-shot/108/permissions/1700380 new file mode 100644 index 000000000..af8bab206 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1700380 @@ -0,0 +1,36 @@ +permissions: 0.986 +socket: 0.942 +network: 0.935 +PID: 0.897 +semantic: 0.884 +device: 0.878 +graphic: 0.869 +debug: 0.844 +performance: 0.830 +other: 0.827 +vnc: 0.822 +boot: 0.606 +files: 0.531 +KVM: 0.359 + +commit snapshot image got Permission denied error + +qemu 2.9.0, adm64, start image with -snapshot param, make some changes in the image, then: + +$telnet localhost 7000 + +(qemu) commit virtio0 +'commit' error for 'virtio0': Permission denied + +Nerver met this problem before, commit is ok. I recently compiled v2.9.0, so is there some new param in qemu-qemu-system-x86_64 to avoid commit Permission denied? + +Regards. + +only the winxp guest image get this error, linux guest do not. + +v2.9.0 must start the image with full path can commit the snapshot changes, <v2.3 no need to. + +close this report. + +Closing, according to comment #2 + diff --git a/results/classifier/zero-shot/108/permissions/1703 b/results/classifier/zero-shot/108/permissions/1703 new file mode 100644 index 000000000..ae49612f7 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1703 @@ -0,0 +1,60 @@ +semantic: 0.947 +permissions: 0.942 +other: 0.933 +performance: 0.921 +debug: 0.916 +graphic: 0.914 +device: 0.900 +PID: 0.889 +network: 0.846 +socket: 0.837 +boot: 0.837 +KVM: 0.831 +vnc: 0.809 +files: 0.758 + +Undefined behaviour when running guest with -enable-kvm and attached debugger +Description of problem: +When attaching a debugger to a Qemu instance with `-enable-kvm` my linux kernel panics on (f.e.) module load. +I am not sure if this is a Qemu bug, however the issue is not occurring if I a) do not attach the debugger (even though Qemu is listening for one) or b) I do not pass `-enable-kvm` (and attach a debugger). +The issue seems to relate to the `lx-symbols` command provided by the Linux kernel gdb script suite. +Every time a module is loaded this script will reload the symbols for said module which may take some time, so maybe there is some race involved? +The issue does not reproduce if you do not run `lx-symbols` prior to continuing (it will however run automatically after first module load as it adds a breakpoint to kernel/module/main.c:do_init_module, so the kernel will crash after the second module load) +Steps to reproduce: +1. Start kernel with some img +2. Attach gdb debugger +3. Run the `lx-symbols` command provided by the Linux kernel gdb scripts in gdb, run `continue` in gdb +3. Load a kernel module +Additional information: +This is the kernel stack trace: +``` +[ 22.930691] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +[ 22.931174] CPU: 2 PID: 241 Comm: modprobe Tainted: G E 6.1.31+ #2 +[ 22.931675] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014 +[ 22.931675] RIP: 0010:do_init_module+0x1/0x210 +[ 22.931675] Code: 74 0c 48 8b 78 08 48 89 de e8 8b df ff ff 65 ff 0d 84 94 ef 7e 0f 85 e5 fe ff ff 0f 1f 44 00 008 +[ 22.931675] RSP: 0018:ffffc90000593e40 EFLAGS: 00010246 +[ 22.931675] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000006e202 +[ 22.931675] RDX: 000000000006e002 RSI: 5b4504de76578f76 RDI: ffffffffc024e180 +[ 22.931675] RBP: ffffc90000593e50 R08: ffffea0000174a88 R09: ffffea0000174ac0 +[ 22.931675] R10: ffff888006a9c270 R11: 0000000000000100 R12: 0000562f9087b4a0 +[ 22.931675] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 22.931675] FS: 00007f0dbc5a4040(0000) GS:ffff88801f500000(0000) knlGS:0000000000000000 +[ 22.931675] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 22.931675] CR2: 00007ffdc94bc3f8 CR3: 0000000006f8e000 CR4: 00000000003506e0 +[ 22.931675] Call Trace: +[ 22.931675] <TASK> +[ 22.931675] ? die+0x32/0x80 +[ 22.931675] ? do_trap+0xd6/0x100 +[ 22.931675] ? do_init_module+0x1/0x210 +[ 22.931675] ? do_error_trap+0x6a/0x90 +[ 22.931675] ? do_init_module+0x1/0x210 +[ 22.931675] ? exc_invalid_op+0x4c/0x60 +[ 22.931675] ? do_init_module+0x1/0x210 +[ 22.931675] ? asm_exc_invalid_op+0x16/0x20 +[ 22.931675] ? do_init_module+0x1/0x210 +[ 22.931675] __do_sys_finit_module+0x9e/0xf0 +[ 22.931675] do_syscall_64+0x63/0x90 +[ 22.931675] ? exit_to_user_mode_prepare+0x1a/0x120 +[ 22.931675] entry_SYSCALL_64_after_hwframe+0x63/0xcd +``` diff --git a/results/classifier/zero-shot/108/permissions/1708 b/results/classifier/zero-shot/108/permissions/1708 new file mode 100644 index 000000000..002db1a2f --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1708 @@ -0,0 +1,82 @@ +permissions: 0.970 +other: 0.970 +performance: 0.956 +device: 0.955 +debug: 0.952 +files: 0.943 +graphic: 0.943 +PID: 0.939 +semantic: 0.933 +vnc: 0.918 +boot: 0.876 +network: 0.876 +KVM: 0.870 +socket: 0.838 + +RISCV: Illegal instruction delegated to VS mode sets the wrong vscause value +Description of problem: +When delegating an illegal instruction exception caused in VS-mode to VS-mode, the vscause value for an illegal instruction is set incorrectly. + +Steps to reproduce: +1. Delegate 2(,6,10) in medeleg and hedeleg. +2. Enter VS-mode +3. Cause an illegal instruction fault, cause 6 can't happen in QEMU since there is misaligned support and 10 can't be delegated to VS mode. +4. The (v)scause CSR is then set to 1, i.e. instruction access fault which isn't correct. + +I have located the issue in the code @ cpu_helper.c:1703 +``` +if ((cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT || + cause == IRQ_VS_EXT)) { + cause = cause - 1; +} +``` + +The if statement should include a check for the async otherwise the cause shouldn't be altered. The patch I propose is simply to **and** the current statement with async. +``` +if (async & (cause == IRQ_VS_TIMER || cause == IRQ_VS_SOFT || + cause == IRQ_VS_EXT)) { + cause = cause - 1; +} +``` +Additional information: +Log where the incorrect cause is set. Note this line: `DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0` +``` +TRACE: [src/hart_ctrl.c:35] STARTING CPU 0 +TRACE: [src/page_tables.c:343] Setting up page tables between 0x80000000 -> 0x81c00000 +TRACE: [src/page_tables.c:359] Setting up page tables between 0x81c01000 -> 0x81c02000 +TRACE: [src/page_tables.c:374] Setting up page tables for UART 0x10000000 +TRACE: [src/page_tables.c:386] Setting up page tables for CLINT 0x2000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x24000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28000000 +DEBUG: [src/page_tables.c: 406] Mapping IMISIC 0x28001000 +TRACE: [src/main.c:32] STARTING HYPERVISOR TESTS +DEBUG: [src/util_fn.c:1175] pmpcfg0 = 0x00000000000f000f +DEBUG: [src/util_fn.c:1176] pmpcfg2 = 0x0000000000000000 +PMP Entry : 0 +Low Address : 0x0 +High Address : 0x81c00000 +Address Range : 0x0 - 0x81c00000 +Mode : TOR +Executable : Yes +Writable : Yes +Readable : Yes +Locked : No +-------------------------------------- +PMP Entry : 2 +Low Address : 0x82000000 +High Address : 0xfffffffffffffffc +Address Range : 0x82000000 - 0xfffffffffffffffc +Mode : TOR +Executable : Yes +Writable : Yes +Readable : Yes +Locked : No +-------------------------------------- +DEBUG: [src/trap_trigger.c: 85] Switching mode to VS +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x00000000800062a4, tval:0x0000000000000000, desc=illegal_instruction +DEBUG: [src/trap_handling.c: 102] Illegal instruction exception: MEPC = 0x800062a4, MTVAL = 0x0 +TRACE: [src/util_fn.c:374] Done switching mode +riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000002, epc:0x0000000080008850, tval:0x0000000000000000, desc=illegal_instruction +DEBUG: [src/trap_handling.c: 105] Instruction access fault exception: SEPC = 0x80008850, STVAL = 0x0 +ERROR: [src/trap_handling.c:158] The following assert failed: mask_cause == cause2check +mask_cause = 0x1 diff --git a/results/classifier/zero-shot/108/permissions/1728256 b/results/classifier/zero-shot/108/permissions/1728256 new file mode 100644 index 000000000..6ae2d0609 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1728256 @@ -0,0 +1,115 @@ +permissions: 0.965 +debug: 0.959 +other: 0.958 +semantic: 0.945 +network: 0.936 +graphic: 0.932 +device: 0.928 +performance: 0.918 +boot: 0.906 +PID: 0.893 +files: 0.866 +vnc: 0.851 +socket: 0.811 +KVM: 0.765 + +Memory corruption in Windows 10 guest / amd64 + +I have a Win 10 Pro x64 guest inside a qemu/kvm running on an Arch x86_64 host. The VM has a physical GPU passed through, as well as the physical USB controllers, as well as a dedicated SSD attached via SATA; you can find the complete libvirt xml here: https://pastebin.com/U1ZAXBNg +I built qemu from source using the qemu-minimal-git AUR package; you can find the build script here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qemu-minimal-git (if you aren't familiar with Arch, this is essentially a bash script where build() and package() are run to build the files, and then install them into the $pkgdir to later tar them up.) + +Starting with qemu v2.10.0, Windows crashes randomly with a bluescreen about CRITICAL_STRUCTURE_CORRUPTION. I also tested the git heads f90ea7ba7c, 861cd431c9 and e822e81e35, before I went back to v2.9.0, which is running stable for over 50 hours right now. + +During my tests I found that locking the memory pages alleviates the problem somewhat, but never completely avoids it. However, with the crashes occuring randomly, that could as well be false conclusions; I had crashes within minutes after boot with that too. + +I will now start `git bisect`ing; if you have any other suggestions on what I could try or possible patches feel free to leave them with me. + +I have a similar setup to yours, running on Ubuntu 17.10 Artful. Symptoms are the same. Did you find out what's wrong with 2.10? (Haven't tested 2.9 here) + +Unfortunately I have bad news, but I also have (kind of) good news. +Bad news is, 2.9 is NOT stable, contrary to what I believed earlier. +Good news is, I found a correlation between the crashes and converting large video files on an SMB share with ffmpeg, so effectively copying slowly with simultaneously high CPU load. In that constellation it crashed a few times after just hours (instead of days sometimes). I suspect it might be a network related issue. I am now testing the different virtual network hardware that qemu supports (which proved to be difficult due to lack of driver support in Windows). + +On that note, I remember right after setting up the VM I had some strange networking related hangup issues with the rtl8139 virtual adapter - the default -, where the VM would slowly grind to a complete halt over a few seconds when I started a very network-heavy task (like copying something from the host via SMB into the VM). I could prevent the hang when I paused the copying for a few seconds. At that time I assumed it was the hardware registering as 100Mbps adapter, but the actual load being about 4 times that on average (during copying of course), with peaks significantly higher (about 15-20 times). That issue completely went away after switching the virtual network hardware to virtio (which registers as 10Gbps adapter), and I considered that case closed. + +It happened again, both with the e1000 and the rtl8139 NICs under qemu 2.11.0.rc0-7-g4ffa88c99c. Kernel is the official Arch one, right now on 4.13.12. + +At this point I have no idea anymore what could be causing this, and am unable to test without having to remove basic functionality from the VM (e.g. the graphics card) or downgrading the host kernel (which I really want to avoid because I'm using btrfs). + +That said, during the last several days I did not experience these weird hangup issues that I described previously, however I did see very high CPU load in the guest that was caused by the network (listed in task manager as System Interrupts, and going as high as one full CPU core during large network operations). + +What is most interesting though is that it survived while I tried my best to get it to crash (stress-testing CPU and network, mostly), and then hit me with a Bluescreen in a most unexpected time almost a week later. Since then however it started crashing anywhere between a few hours and about two days of consecutive uptime again, just like before. + +@larsk, could you elaborate on your setup? Like, in which ways is it different (other than you using Ubuntu and thus different versions of the involved software)? +Which hardware do you pass through, if any? + +I've also had the exact symptoms and issues you've described. I have also noticed that the VM would BSOD with the CRITICAL_STRUCTURE_CORRUPTION message when the host system would read VM memory from swap. + +After disabling swap on the host system I've completely managed to eliminate this BSOD issue. Hopefully it's also applicable to your system so you can atleast figure out how to move forward. + +I'm experiencing this BSOD issue as well. I'm also on Arch x64, and the same versions of everything (though not minimal qemu--just the normal package in the main repos). I also passthru a GPU and a USB card, but not an SSD. It will happen randomly, anytime, at least once a day, and it seems like demanding games make it much more frequent. Since you're on btrfs, I'll see what happens if I downgrade the kernel to 4.12. If that doesn't work, I guess I'll try to confirm the swapoff fix, but my host only gets 4GB of RAM when the VM is running, so no swap would hurt real bad. + +Specifically 4.12.12, because it seems that was the last version I was running before this issue started (I was on 4.12.13 when it started). I, too, can't find any other package upgrade that could have possibly been the culprit. The timing of my upgrades of any qemu or libvirt packages rule them out. + +I am on Arch as well, using a customized kernel using the vfio patchset (in this case 4.13.11). I was having the same issue as you guys, where my Windows 10 VM with an NVIDIA card passed in was getting the CRITICAL_STRUCTURE_CORRUPTION blue screen error message after running for a while. Usually I saw this when hitting some form of memory (GPU or system RAM), and it was quick (~3 hours) to crash while mining on the GPU (as that hits the GPU memory hard). + +It looks like what Jimi said above about swap seeming to be a contributing factor seems to be correct. I have disabled swap on my host and have seen no instability thus far. + +Windows 7 also may be seeing similar issues, though it was just crashing though without displaying an error as far as I could see. This VM has an AMD card in it. Same goes for it, where it also has not crashed after more than a day after disabling swap. + +I have yet to try disabling swap, but in the 5 days since I downgraded the kernel to 4.12.12 from 4.12.13, I have not had a single BSOD. I think 4.12.13 is the culprit. + +I just reported the bug in the kernel: https://bugzilla.kernel.org/show_bug.cgi?id=197951 + +If you reported or commented on the bug here, please go comment on that report confirming as well. A lot of open-source bugzilla projects tend to rarely pay attention to bug reports that only one person has confirmed/reported. + +Status changed to 'Confirmed' because the bug affects multiple users. + +Got similar behavior with windows server 2012r2 VMs. + +Environment: + +uname -a +Linux ubuntu-q87 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +ii linux-image-4.13.0-36-generic 4.13.0-36.40~16.04.1 amd64 Linux kernel image for version 4.13.0 on 64 bit x86 SMP + +apt policy qemu +qemu: + Installed: (none) + Candidate: 1:2.11+dfsg-1ubuntu5~cloud0 + Version table: + 1:2.11+dfsg-1ubuntu5~cloud0 500 + +Windows VMs error out and create a memory dump: + +The computer has rebooted from a bugcheck. The bugcheck was: 0x00000109 (0xa3a01f5891f186c5, 0xb3b72bdee47188a0, 0x0000032000000000, 0x0000000000000017). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 033018-31234-01. + +Based on microsoft docs: + +https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x109---critical-structure-corruption +CRITICAL_STRUCTURE_CORRUPTION Parameters +Parameter Description +1 Reserved +2 Reserved +3 Reserved +4 The type of the corrupted region. (See the following table later on this page.) + +... +0x17 Local APIC modification <--- this + + +Which is the same as with other reports out there: + +https://www.spinics.net/lists/kvm/msg159977.html +https://forum.proxmox.com/threads/new-windows-vm-keeps-dying.39145/#post-193639 + + +From what I see the change was backported but there was no new build yet. + +http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/arch/x86/kvm/x86.c?h=hwe&id=78d2542b88d16 + +See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1738972 + +I suggest this is marked as a duplicate to 1738972 + diff --git a/results/classifier/zero-shot/108/permissions/1732959 b/results/classifier/zero-shot/108/permissions/1732959 new file mode 100644 index 000000000..5af96e6e6 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1732959 @@ -0,0 +1,110 @@ +permissions: 0.962 +other: 0.958 +semantic: 0.957 +debug: 0.945 +graphic: 0.942 +network: 0.935 +performance: 0.924 +device: 0.915 +files: 0.915 +socket: 0.910 +vnc: 0.893 +PID: 0.889 +KVM: 0.887 +boot: 0.861 + +[regression] stop/cont triggers clock jump proportional to host clock drift + +We (ab)use migration + block mirroring to perform transparent zero downtime VM backups. Basically: + +1) do a block mirror of the source VM's disk +2) migrate the source VM to a destination VM using the disk copy +3) cancel the block mirroring +4) resume the source VM +5) shut down the destination VM gracefully and move the disk to backup + +Relatively recently, the source VM's clock started jumping after step #4. More specifically, the clock jumps an amount of time proportional to the time since it was last migrated. With a week between migrations, clock jumps between ~2.5s and ~12s have been observed. For a particular host, the amount of clock jump is fairly consistent, but there is a large variation from one host to the next (this is likely down to hardware variations and the amount of NTP adjusted clock drift on the host). + +This is caused by a kernel regression which I was able to bisect. The result of the bisect was: + +108b249c453dd7132599ab6dc7e435a7036c193f is the first bad commit +commit 108b249c453dd7132599ab6dc7e435a7036c193f +Author: Paolo Bonzini <email address hidden> +Date: Thu Sep 1 14:21:03 2016 +0200 + + KVM: x86: introduce get_kvmclock_ns + + Introduce a function that reads the exact nanoseconds value that is + provided to the guest in kvmclock. This crystallizes the notion of + kvmclock as a thin veneer over a stable TSC, that the guest will + (hopefully) convert with NTP. In other words, kvmclock is *not* a + paravirtualized host-to-guest NTP. + + Drop the get_kernel_ns() function, that was used both to get the base + value of the master clock and to get the current value of kvmclock. + The former use is replaced by ktime_get_boot_ns(), the latter is + the purpose of get_kernel_ns(). + + This also allows KVM to provide a Hyper-V time reference counter that + is synchronized with the time that is computed from the TSC page. + + Reviewed-by: Roman Kagan <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +I am able to reproduce the issue with much newer kernels as well, including 4.12.5 and 4.9.6. + +Reliably reproducing the problem in isolation is difficult, as one must run a VM for many hours before the clock jump from this bug is noticeable over the clock jump inherent with a pause and resume of the VM. The reproducer I am including is set to run the VM for 18 hours before migration and looks for >= 150 ms of clock jump. On different hardware, you may need to let the VM run for more than 18 hours to reliably reproduce the issue. + +To reproduce the issue, please see the attached reproducer. The host needs to have perl, screen and socat installed for the backup script to work. Both the host and guest need to be running NTP (and NTP must autostart at boot in the guest). The host needs to be able to SSH into the guest using SSH keys (to measure the clock jump), so you will need to configure the network and SSH keys appropriately, then change the hardcoded IP address in checktime.sh and test.sh. I have only tested with CentOS 7 guests. + +The qemu command that gets run is in .kvmscreen (the destination VM's command line is programmatically constructed from this command as well), you may need to tweak the bridge configuration. Also, although the reproducer is relatively self contained, it has several built in assumptions that will break if the image file is not in the /var/lib/kvm directory or if the monitor file is not in the /var/lib/kvm/monitor directory, or if the /backup directory does not exist. Finally, if you change the process name or socket name in .kvmscreen, you'll need to adjust the cleanup section in test.sh. + +With all of the above in place, run test.sh and check back in a little over 18 hours, part of the output should include something along these lines: + +Target not found (wanted 150, at 10) + +- or - + +Target found (wanted 150, found 340) + +If the target is reported as found, that means that we have probably reproduced the described issue. + +The version of QEMU in use does not appear to matter. At one point I tested every major version from 2.4 to 2.9 (inclusive) and reproduced the issue in all of them. + +This was initially observed on two different Gentoo hosts. I have also started to see this issue happening with four different RHEL 7 hosts as of the upgrade to RHEL 7.4. This is not too surprising as it appears that the above commit has been backported into RHEL 7. All hosts and guests are 64-bit. + + + +Two important findings: + +1) If I disable ntpd on the host, this issue goes away. +2) If I forcefully induce substantial clock skew on the host (with adjtimex -f 100000000000), it becomes much less time intensive to reproduce this issue. Using the attached reproducer but replacing the 18h sleep with a 20m sleep can still reliably reproduce the issue in this case. + +So, this issue is definitely related to clock skew. + +As a further test, I disabled ntpd on the host and ran ntpdate via cron every 12 hours, so that the clock would be relatively accurate, but no clock skew would be involved. This also reproduced the failure as initially described. + +This is interesting as it means that a much simpler and faster reproduction case is probably feasible, something like: + +1) start guest +2) jump host clock by a few seconds +3) migrate + cont src guest +4) check clock in src guest + +Though, I haven't tried this yet. + +Actually, migration isn't required to reproduce this issue at all, it is the stop/cont involved in the migration here that triggers the bug. It is significantly easier to reproduce the bug with the following steps: + +1) on host, adjtimex -f 100000000000 +2) start guest +3) wait 20 minutes +4) stop and immediately after cont guest + +At this point you will observe a time jump in the guest proportional to the amount of time drift accumulated on the host since the last stop/cont cycle (or guest startup if none). The easiest way to notice the time jump in the guest is by running ntpd in the guest. + +Step one above is optional, but if omitted, you must wait substantially longer in step 3 (~1 day or more, depending on the amount of natural clock drift on the host). + +One upshot of this is that we now have a (very ugly and hacky) workaround, which is to regularly (several times a day) issue a stop/cont to every running VM, which smears the time jump out into enough smaller pieces that it's not as bad as one bigger jump. It would still be nice to have this bug fixed though. + +This appears to be fixed in the kernel as of 0bc48bea36d178aea9d7f83f66a1b397cec9db5c (merged for 4.13, backported to RHEL 7.6). + diff --git a/results/classifier/zero-shot/108/permissions/1738 b/results/classifier/zero-shot/108/permissions/1738 new file mode 100644 index 000000000..20267fcff --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1738 @@ -0,0 +1,164 @@ +permissions: 0.989 +other: 0.978 +files: 0.978 +graphic: 0.978 +device: 0.973 +debug: 0.968 +boot: 0.959 +semantic: 0.956 +performance: 0.955 +vnc: 0.932 +PID: 0.927 +socket: 0.914 +KVM: 0.912 +network: 0.895 + +qemu-system-x86_64 crash during kernel PCI init with large number of busses +Description of problem: +When booting a Linux kernel under qemu-system-x86_64 (tcg) using a large number of PCI busses (25+), qemu crashes with an invalid memory access during kernel PCI init phase. Failure rate is not 100%; some kernel boots do succeed, but the failure rate increases as the number of pci busses increases. Note that no initrd is needed; crash happens before kernel even gets to the point of trying to mount root. +Steps to reproduce: +Launch qemu using command line above along with 4.19.x kernel image (have not tested 5.x). It may take a few tries but within about 20 boot attempts, qemu will crash at least once. +Additional information: +Final kernel logs before crash: +``` +... +[ 1.413615] ACPI: Added _OSI(Module Device) +[ 1.413947] ACPI: Added _OSI(Processor Device) +[ 1.414262] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 1.414421] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.414922] ACPI: Added _OSI(Linux-Dell-Video) +[ 1.415445] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 1.444489] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.468218] ACPI: Interpreter enabled +[ 1.469897] ACPI: (supports S0 S3 S4 S5) +[ 1.470200] ACPI: Using IOAPIC for interrupt routing +[ 1.471811] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and repog +[ 1.474421] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 1.536854] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 1.537996] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] +[ 1.540988] acpi PNP0A08:00: _OSC: platform does not support [LTR] +[ 1.542232] acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability] +[ 1.546310] PCI host bridge to bus 0000:00 +[ 1.546650] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 1.547471] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 1.548039] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 1.548421] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 1.549086] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 1.549945] pci_bus 0000:00: root bus resource [mem 0x280000000-0xa7fffffff window] +[ 1.550994] pci_bus 0000:00: root bus resource [bus 00-ff] +<...crash...> +``` + +QEMU backtrace: +``` +$ gdb build/qemu-system-x86_64 core.3475232 +<...> +Reading symbols from build/qemu-system-x86_64... +[New LWP 3475243] +[New LWP 3475244] +[New LWP 3475241] +[New LWP 3475238] +[New LWP 3475245] +[New LWP 3475239] +[New LWP 3475246] +[New LWP 3475240] +[New LWP 3475232] +[New LWP 3475242] +[New LWP 3475236] +[New LWP 3475247] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +Core was generated by `build/qemu-system-x86_64 -m 8192 -smp cpus=10,threads=2 -nographic -machine q35'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000556065897e0e in memory_region_dispatch_write (mr=mr@entry=0x0, addr=addr@entry=768, data=data@entry=253, + op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1497 +1497 if (mr->alias) { +[Current thread is 1 (Thread 0x7fe2e951d640 (LWP 3475243))] +(gdb) bt full +#0 0x0000556065897e0e in memory_region_dispatch_write + (mr=mr@entry=0x0, addr=addr@entry=768, data=data@entry=253, op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1497 + size = <optimized out> +#1 0x00005560659112c2 in io_writex + (env=env@entry=0x556066bbd5d0, full=0x7fe08401ec70, mmu_idx=mmu_idx@entry=2, val=val@entry=253, addr=addr@entry=18446744073699050240, retaddr=retaddr@entry=140611404753775, op=MO_32) at ../accel/tcg/cputlb.c:1430 + _iothread_lock_auto = 0x1 + cpu = 0x556066bbb1e0 + mr_offset = 768 + section = 0x7fe078d7d570 + mr = 0x0 + r = <optimized out> +#2 0x0000556065915f14 in store_helper + (op=MO_32, retaddr=140611404753775, oi=<optimized out>, val=<optimized out>, addr=18446744073699050240, env=0x556066bbd5d0) + at ../accel/tcg/cputlb.c:2454 + full = <optimized out> + need_swap = false + a_bits = <optimized out> + mmu_idx = 2 + tlb_addr = <optimized out> + haddr = <optimized out> + size = 4 + index = <optimized out> + entry = 0x7fe08401bc40 +#3 full_le_stl_mmu (env=0x556066bbd5d0, addr=18446744073699050240, val=253, oi=<optimized out>, retaddr=140611404753775) + at ../accel/tcg/cputlb.c:2542 +#4 0x00007fe2a4d4eb6f in code_gen_buffer () +#5 0x00005560659065bb in cpu_tb_exec + (cpu=cpu@entry=0x556066bbb1e0, itb=itb@entry=0x7fe2a4d4e9c0 <code_gen_buffer+13953427>, tb_exit=tb_exit@entry=0x7fe2e951c758) + at ../accel/tcg/cpu-exec.c:460 + env = 0x556066bbd5d0 + ret = <optimized out> + last_tb = <optimized out> + tb_ptr = 0x7fe2a4d4ea80 <code_gen_buffer+13953619> + __PRETTY_FUNCTION__ = "cpu_tb_exec" +#6 0x0000556065906ab6 in cpu_loop_exec_tb + (tb_exit=0x7fe2e951c758, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7fe2a4d4e9c0 <code_gen_buffer+13953427>, cpu=0x556066bbb1e0) at ../accel/tcg/cpu-exec.c:893 + insns_left = <optimized out> + __PRETTY_FUNCTION__ = "cpu_loop_exec_tb" + tb = 0x7fe2a4d4e9c0 <code_gen_buffer+13953427> + flags = <optimized out> + cflags = 4280811520 + cs_base = <optimized out> + pc = <optimized out> + last_tb = <optimized out> + tb_exit = 0 +--Type <RET> for more, q to quit, c to continue without paging-- + ret = <optimized out> +#7 cpu_exec_loop (cpu=cpu@entry=0x556066bbb1e0, sc=sc@entry=0x7fe2e951c7f0) at ../accel/tcg/cpu-exec.c:1013 + tb = 0x7fe2a4d4e9c0 <code_gen_buffer+13953427> + flags = <optimized out> + cflags = 4280811520 + cs_base = <optimized out> + pc = <optimized out> + last_tb = <optimized out> + tb_exit = 0 + ret = <optimized out> +#8 0x0000556065907311 in cpu_exec_setjmp (cpu=cpu@entry=0x556066bbb1e0, sc=sc@entry=0x7fe2e951c7f0) at ../accel/tcg/cpu-exec.c:1043 + __func__ = "cpu_exec_setjmp" +#9 0x00005560659079f0 in cpu_exec (cpu=cpu@entry=0x556066bbb1e0) at ../accel/tcg/cpu-exec.c:1069 + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0} +#10 0x000055606592a854 in tcg_cpus_exec (cpu=cpu@entry=0x556066bbb1e0) at ../accel/tcg/tcg-accel-ops.c:81 + ret = <optimized out> + __PRETTY_FUNCTION__ = "tcg_cpus_exec" +#11 0x000055606592a9a7 in mttcg_cpu_thread_fn (arg=arg@entry=0x556066bbb1e0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 + r = <optimized out> + + force_rcu = {notifier = {notify = 0x55606592aac0 <mttcg_force_rcu>, node = {le_next = 0x0, le_prev = 0x7fe2e951d4a0}}, cpu = 0x556066bbb1e0} + cpu = 0x556066bbb1e0 + __PRETTY_FUNCTION__ = "mttcg_cpu_thread_fn" + __func__ = "mttcg_cpu_thread_fn" +#12 0x0000556065aa2e91 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 + + __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {140612553791040, -3809744250012005023, 93872529245600, 25, 140612607756368, 140729970282144, -7051494707616903839, -3809738403745854111}, __mask_was_saved = 0}}, __pad = {0x7fe2e951c970, 0x0, 0x0, 0x0}} + __cancel_routine = 0x556065aa2ee0 <qemu_thread_atexit_notify> + __not_first_call = <optimized out> + start_routine = 0x55606592a8a0 <mttcg_cpu_thread_fn> + arg = 0x556066bbb1e0 + r = <optimized out> +#13 0x00007fe2ec894b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 + ret = <optimized out> + pd = <optimized out> + + unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140729970281792, 7053160723592154465, 140612553791040, 25, 140612607756368, 140729970282144, -7051494707570766495, -7051505217351676575}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} + not_first_call = <optimized out> +#14 0x00007fe2ec926a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/zero-shot/108/permissions/1738283 b/results/classifier/zero-shot/108/permissions/1738283 new file mode 100644 index 000000000..d3895e3c1 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1738283 @@ -0,0 +1,174 @@ +permissions: 0.926 +performance: 0.917 +vnc: 0.912 +graphic: 0.909 +network: 0.907 +device: 0.906 +semantic: 0.891 +other: 0.889 +boot: 0.885 +files: 0.884 +debug: 0.873 +socket: 0.864 +PID: 0.855 +KVM: 0.834 + +'Less than' (<), 'more than' (>), and 'pipe' (|) can't be typed via VNC + +If I start QEMU 2.11 (from https://build.opensuse.org/package/show/Virtualization/qemu) VM with VNC, I am unable to type following three characters: 'less than' (<), 'more than' (>), and 'pipe' (|) on en_US QWERTY keyboard. Other characters work fine. QEMu version 2.10.1 worked fine. + +/usr/bin/qemu-kvm -m 2048 -cpu kvm64 -drive media=cdrom,if=none,id=cd0,format=raw,file=OI-hipster-minimal-20171031.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -vnc :91,share=force-shared + +The ISO can be downloaded here: https://www.openindiana.org/download/ + +Also tried Fedora-Server-dvd-x86_64-25-1.3.iso and it's the same situation. + +If I run the same command without '-vnc :91,share=force-shared', everything works just fine. + +Wondering if it's a SUSE-specific problem: https://build.opensuse.org/package/view_file/Virtualization/qemu/0026-Fix-tigervnc-long-press-issue.patch?expand=1 + +Should have mention I use openSUSE Leap 42.3 with above mentioned virtualization repo. + +Removed the 0026-Fix-tigervnc-long-press-issue patch and rebuilt QEMU but no change. + +But I noticed that if I run the ISO via libvirt and connect to it via virt-manager (virt-manager-1.4.1-4.1.noarch), the keys are there as expected: + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=OI,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-OI/master-key.aes -machine pc-i440fx-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu kvm64 -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 5664149e-26ad-4ee8-8170-16701f107b4b -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-OI/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x3.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x3 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x3.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x3.0x2 -drive file=/var/lib/libvirt/images/OI-hipster-minimal-20171031.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -vnc 127.0.0.1:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +Connection via TigerVNC (tigervnc-1.6.0-21.1.x86_64) to the same VM is unable to write those characters. + +Well, if virt-manager is configured to run the VM with `-k en-us` I can't enter <>| even in virt-manager. keycodemapdb? + +By default virt-manager will *not* enable the '-k en-us' argument, because that forces use of a specific keyboard layout in QEMU's VNC server. For that to work, the VNC client keymap must exactly match the QEMU VNC server keymap, and must also exactly match the guest OS keymap. + +Instead virt-manager leaves off the "-k en-us" argument, which will cause the VNC servers raw scancode extension to be activated with compatible clients. Virt-manager uses GTK-VNC which activates this extension, and so passes raw XT scancodes from virt-manager to QEMU to the guest OS, which generally makes everything "just work" + +IOW, if virt-manager works correctly, but tigerVNC does not work correctly, this probably means that tigervnc is not activating the raw scancode extension. + +Hello, + +I confirm the same problem on Fedora 27 Server using Source code release 2.11.0 + +The problem remains no matter if I use the "-k en-us" parameter or not. + +Worked fine up to 2.10.1 + +If the guess is Windows, then when trying to type the "<" character then the pipe ("|") appears. + +If the guess is Linux, the same key produces the ">" character. + +Both operating systems use the US English keyboard layout. + +Thanks a lot for your time and help. + +Miguel + + + +If I start QEMU with `-k en-gb` at least '<' and '>' work, '|' doesn't (and obviously 'Shift-2' produces '"' not '@'). + +My host `locale` is 'en_US.UTF-8' top to bottom. + +I tried to update TigerVNC to 1.8 but no change. I run `vncviewer` with '-Log *:stderr:100' and QEMU without '-k' option and at least on the VNC client side it reports expected key code names. + +Aha. This looks like my bug! + +I'm running into this in what I suspect is the same situation as Michal Nowak: openQA. But in Fedora. openQA (well, its test runner, os-autoinst) works by running virtual machines and interacting with them over VNC. It seems that with qemu 2.11, typing certain characters doesn't work right, where it worked fine with 2.10. The case I ran into is the < case: when os-autoinst intends to type a < (which it does by sending the keysym for shift and then the keysym 60, for <), it winds up typing a > . This winds up causing os-autoinst's test suite to fail when attempting to build the package on Fedora Rawhide. The test suite passes on Fedora 27 (qemu 2.10). + +The qemu command in my test is: + +/usr/bin/qemu-system-i386 -serial file:serial0 -soundhw ac97 -vga cirrus -m 1024 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -device ide-drive,drive=hd1,serial=1 -drive file=raid/l1,cache=unsafe,if=none,id=hd1,format=qcow2 -drive media=cdrom,if=none,id=cd0,format=raw,file=/builddir/build/BUILD/os-autoinst-25191d50d54eaded10b6b26199bb986728dcd5c2/t/data//Core-7.2.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -smp 1 -no-shutdown -vnc :90,share=force-shared -qmp unix:qmp_socket,server,nowait -monitor unix:hmp_socket,server,nowait -S -monitor telnet:127.0.0.1:15222,server,nowait + +note there doesn't appear to be any explicit keyboard map setting there. + +Note, os-autoinst is its own VNC client. Most of the implementation can be found in https://github.com/os-autoinst/os-autoinst/blob/master/consoles/VNC.pm . The functions relevant to sending key events are `shift_keys`, `init_x11_keymap`, `map_and_send_key`, and `_send_key_event`. + +I also confirm Michal's observation of virt-manager and tigervnc behaving differently with the same VM: I ran a VM set up with VNC display server in virt-manager and can type < from the virt-manager UI fine, but if I connect to the same VM with tigervnc and try to type < , I get > . This is with current Fedora Rawhide qemu, virt-manager and tigervnc: + +qemu-common-2.11.0-1.fc28.x86_64 +virt-manager-1.4.3-2.fc28.noarch +tigervnc-1.8.0-5.fc28.x86_64 + +I found something interesting using showkey in the VM. This is all assuming en-US everywhere, note. On a US keyboard, "<" is a shifted comma (shift-,), ">" is a shifted period (shift-.), and "|" is a shifted backslash (shift-\). + +If I run showkey and try the affected characters in virt-manager, the results are kinda what I'd expect. It reports keycode 42 for the shift key, keycode 51 for comma key, keycode 52 for period key, and keycode 43 for backslash key. If I do shift-, (to get a <), it shows keycode 42 down, keycode 51 down, keycode 51 up, keycode 42 up - just what you'd expect. Ditto for > and |: it shows 42d/52d/52u/42u and 42d/43d/43u/42u in those cases. + +But if I do this while typing in tigervnc, it reports something quite different. Just pressing the keys alone gives the right codes - 51, 52, 43. But when I try the shifted combinations, it reports keycode *86* for all three keys. That is, so long as shift is held down, pressing the comma, period or backslash key reports keycode 86 - not 51, 52 or 43. Somehow this results in the generation of a > character, not sure how. + +I note this block in pc-bios/keymaps/en-us with interest: + +# evdev 86 (0x56), QKeyCode "less", number 0x56 +less 0x56 +greater 0x56 shift +bar 0x56 altgr +brokenbar 0x56 shift altgr + +That block was added in commit a7815faffb2bd594b92aa3542d7b799cc89c5414 , which I am very suspicious was the cause of this problem. I strongly suspect that removing it will fix the problem. Will test now. + +FWIW, I think this keycode represents the key between the left shift key and the first letter key on the fourth row, if there is one. European keyboards have one, and on e.g. a UK keyboard it types a \ unshifted and a | shifted - this is exactly how it looks in the en-gb keymap file: + +# evdev 86 (0x56), QKeyCode "less", number 0x56 +backslash 0x56 +bar 0x56 shift +bar 0x56 altgr +brokenbar 0x56 shift altgr + +The definition that somehow gets into the en-us keymap file appears to be actually how the key is intended to work on *German* keyboards: + +https://en.wikipedia.org/wiki/German_keyboard_layout + +Note how the key is labelled with <, > and | characters there. The French layout has the same key labelled with < and > but not |. So basically it seems like that same definition for this key shows up when you ask xkb for an en_US map. + +Bonus historical note: modern US keyboards don't have a key there at all, they're 101/104-key keyboards, where the left shift key is very wide and the key next to it is the first letter key. But *old* US keyboards, specifically the 83-key 'XT' layout, *DID* have a key there! + +https://en.wikipedia.org/wiki/IBM_PC_keyboard#/media/File:IBM_Model_F_XT.png + +From that picture, the key was labelled with \ and | characters, like a modern UK keyboard (presumably this is where the modern UK keyboard derived its use for the key from). I wonder if there's a keyboard nerd out there somewhere with a working US XT keyboard who we could ask to press that key and see what keycode it generates...:) I suppose if it's this keycode, we could arguably report a bug in xkb that for en_US, that keycode should work like a modern UK keyboard (backslash / bar / bar / brokenbar), not a modern German keyboard...:) + +Confirmed that dropping the offending keycode 86 definition out of keymaps/en-us fixes the problem. Scratch build for Fedora Rawhide was https://koji.fedoraproject.org/koji/taskinfo?taskID=23814932 , I'll probably send this out as an official build so I can get os-autoinst built without hacking up the tests, but as the files are generated by qemu-keymap just hand editing the file isn't really the 'right' solution for upstream; someone will need to tweak qemu-keymap, or else leave the keymap alone but somehow tweak the relevant bits in qemu/ui/keymaps.c and fix the problem that way. + +Note: I wondered if specifying a correct model for qemu-keymap to pass to xkb would help. But it doesn't :( That is, these: + +qemu-keymap -l us +qemu-keymap -l us -m pc101 +qemu-keymap -l us -m pc104 +qemu-keymap -l us -m pc105 + +all produce the same output except for the commented-out 'model' line at the top. It appears xkb doesn't really consider the model when deciding what keycodes to include in the generated keymap. + +I found Adam's patch from Fedora Rawhide (https://src.fedoraproject.org/rpms/qemu/c/f81be8f0261cce74799f946e99f23d57f8db7e17?branch=master) when applied to openSUSE's 2.11.0 QEMU effective in openQA as well as manually with vncviewer. + +We ran into this as well, using qemu 2.11.0. We're not using the "-k en-us" command line flag, and we're using noVNC as a client (which supports the QEMUExtendedKeyEvent encoding) + +FYI this seems to be fixed with qemu.git master, I didn't track down the specific commit but there were several keymap related changes. so qemu 2.12 will be fixed + +QEMU 2.12 has now been release, so marking this one as "Fix Released". + +Indeed the bug does not exist in this exact form any more, but it seems the stray '86' keymap entry *does* still cause problems in current qemu in one specific case: + +https://bugzilla.redhat.com/show_bug.cgi?id=1658676 + +basically, if using 'usb-kbd', we still get trouble when openQA (os-autoinst) tries to type a '<' character, because it does this: + +shift down +comma down +shift up +comma up + +(note it does *not* do shift down, comma down, comma up, shift up), and qemu gets confused and converts that into this sequence of input_event_key_qcode events: + +shift down +comma down +shift up +less up + +and that seems to mess with the key state and cause any subsequent attempts to type a '<' to go wrong. + +Removing the '86' key definition avoids the bug. + +Discussing the problem & likely solution here: + + https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04631.html + +I'm not subscribed there, so will note here: I tried the proposed changes - the commits from https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04819.html , backported to 3.0.0 - and that seems to work. A test which would previously have hit this bug ran OK, without the changes to the en-us keymap. + diff --git a/results/classifier/zero-shot/108/permissions/1738691 b/results/classifier/zero-shot/108/permissions/1738691 new file mode 100644 index 000000000..49622b09f --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1738691 @@ -0,0 +1,260 @@ +permissions: 0.948 +other: 0.942 +performance: 0.927 +debug: 0.922 +device: 0.920 +semantic: 0.910 +boot: 0.909 +KVM: 0.866 +socket: 0.863 +graphic: 0.862 +PID: 0.858 +files: 0.830 +network: 0.826 +vnc: 0.719 + +Guest kernel crashes with kvm_pr on POWER8 + +When attempting to use the kvm_pr module with QEMU 2.10 on a POWER8 host, Debian and Ubuntu guests hang and show crashes. + +Host kernel is 4.14. Issue is observed with host kernels 4.9 and 4.13 as well; no other host kernels were tested. + +Is this the correct place to report a kvm_pr bug? + +Output from Ubuntu 17.10 guest: + +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000002000000 ... +[ 0.000000] Page sizes from device-tree: +[ 0.000000] base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0 +[ 0.000000] base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=1 +[ 0.000000] base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001, tlbiel=0, penc=0 +[ 0.000000] Using 1TB segments +[ 0.000000] Initializing hash mmu with SLB +[ 0.000000] Linux version 4.13.0-16-generic (buildd@bos01-ppc64el-029) (gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu2)) #19-Ubuntu SMP Wed Oct 11 18:37:02 UTC 2017 (Ubuntu 4.13.0-16.19-generic 4.13.4) +[ 0.000000] Found initrd at 0xc000000003b00000:0xc0000000048cf68b +[ 0.000000] Using pSeries machine description +[ 0.000000] bootconsole [udbg0] enabled +[ 0.000000] Partition configured for 2 cpus. +[ 0.000000] CPU maps initialized for 1 thread per core + -> smp_release_cpus() +spinning_secondaries = 1 + <- smp_release_cpus() +[ 0.000000] ----------------------------------------------------- +[ 0.000000] ppc64_pft_size = 0x19 +[ 0.000000] phys_mem_size = 0x100000000 +[ 0.000000] dcache_bsize = 0x80 +[ 0.000000] icache_bsize = 0x80 +[ 0.000000] cpu_features = 0x077c7a6c18500249 +[ 0.000000] possible = 0x5fffffff18500649 +[ 0.000000] always = 0x0000000018100040 +[ 0.000000] cpu_user_features = 0xdc0065c2 0xae000000 +[ 0.000000] mmu_features = 0x7c006001 +[ 0.000000] firmware_features = 0x00000000415a445f +[ 0.000000] htab_hash_mask = 0x3ffff +[ 0.000000] ----------------------------------------------------- +[ 0.000000] numa: NODE_DATA [mem 0xfffd7c80-0xfffe3fff] +[ 0.000000] PCI host bridge /pci@800000020000000 ranges: +[ 0.000000] IO 0x0000200000000000..0x000020000000ffff -> 0x0000000000000000 +[ 0.000000] MEM 0x0000200080000000..0x00002000ffffffff -> 0x0000000080000000 +[ 0.000000] MEM 0x0000210000000000..0x000021ffffffffff -> 0x0000210000000000 +[ 0.000000] PPC64 nvram contains 65536 bytes +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000000000-0x00000000ffffffff] +[ 0.000000] DMA32 empty +[ 0.000000] Normal empty +[ 0.000000] Device empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000000000-0x00000000ffffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000ffffffff] +[ 0.000000] percpu: Embedded 4 pages/cpu @c0000000ffe00000 s162840 r0 d99304 u524288 +[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 65472 +[ 0.000000] Policy zone: DMA +[ 0.000000] Kernel command line: BOOT_IMAGE=/install/vmlinux file=/cdrom/preseed/ubuntu-server.seed no_timer_check printk.time=1 --- +[ 0.000000] PID hash table entries: 4096 (order: -1, 32768 bytes) +[ 0.000000] Memory: 4070016K/4194304K available (12800K kernel code, 2048K rwdata, 3456K rodata, 4608K init, 3021K bss, 124288K reserved, 0K cma-reserved) +[ 0.000000] random: get_random_u64 called from cache_random_seq_create+0x80/0x180 with crng_init=0 +[ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 +[ 0.000000] ftrace: allocating 33631 entries in 13 pages +[ 0.000000] Hierarchical RCU implementation. +[ 0.000000] RCU restricting CPUs from NR_CPUS=2048 to nr_cpu_ids=2. +[ 0.000000] Tasks RCU enabled. +[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 +[ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 +[ 0.000006] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns +[ 0.000696] clocksource: timebase mult[1f40000] shift[24] registered +[ 0.001189] Console: colour dummy device 80x25 +[ 0.001500] console [hvc0] enabled +[ 0.001500] console [hvc0] enabled +[ 0.001751] bootconsole [udbg0] disabled +[ 0.001751] bootconsole [udbg0] disabled +[ 0.002142] pid_max: default: 32768 minimum: 301 +[ 0.002358] Security Framework initialized +[ 0.002377] Yama: becoming mindful. +[ 0.002466] AppArmor: AppArmor initialized +[ 0.007008] Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes) +[ 0.009037] Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes) +[ 0.009144] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes) +[ 0.009282] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes) +[ 0.011066] EEH: pSeries platform initialized +[ 0.011137] POWER8 performance monitor hardware support registered +[ 0.011231] Hierarchical SRCU implementation. +[ 0.012560] smp: Bringing up secondary CPUs ... +[ 0.014620] smp: Brought up 1 node, 2 CPUs +[ 0.014669] numa: Node 0 CPUs: 0-1 +[ 0.017357] devtmpfs: initialized +[ 0.020796] evm: security.selinux +[ 0.020816] evm: security.SMACK64 +[ 0.020832] evm: security.SMACK64EXEC +[ 0.020849] evm: security.SMACK64TRANSMUTE +[ 0.020865] evm: security.SMACK64MMAP +[ 0.020882] evm: security.ima +[ 0.020898] evm: security.capability +[ 0.021384] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.021428] futex hash table entries: 512 (order: 0, 65536 bytes) +[ 0.022217] NET: Registered protocol family 16 +[ 0.023456] EEH: No capable adapters found +[ 0.068790] KVM: Live patching for a fast VM worked +[ 0.069504] cpuidle: using governor ladder +[ 0.069606] cpuidle: using governor menu +[ 0.070109] pstore: using zlib compression +[ 0.070162] pstore: Registered nvram as persistent store backend +Linux ppc64le +#19-Ubuntu SMP W[ 0.073385] PCI: Probing PCI hardware +[ 0.073595] PCI host bridge to bus 0000:00 +[ 0.073650] pci_bus 0000:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff]) +[ 0.073722] pci_bus 0000:00: root bus resource [mem 0x200080000000-0x2000ffffffff] (bus address [0x80000000-0xffffffff]) +[ 0.073827] pci_bus 0000:00: root bus resource [mem 0x210000000000-0x21ffffffffff] +[ 0.073913] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.081145] IOMMU table initialized, virtual merging enabled +[ 0.081231] iommu: Adding device 0000:00:00.0 to group 0 +[ 0.083493] HugeTLB registered 16.0 MiB page size, pre-allocated 0 pages +[ 0.085216] SCSI subsystem initialized +[ 0.085722] vgaarb: loaded +[ 0.085885] usbcore: registered new interface driver usbfs +[ 0.085961] usbcore: registered new interface driver hub +[ 0.086096] usbcore: registered new device driver usb +[ 0.086175] pps_core: LinuxPPS API ver. 1 registered +[ 0.086217] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <email address hidden> +[ 0.086316] PTP clock support registered +[ 0.086629] EDAC MC: Ver: 3.0.0 +[ 0.087455] NetLabel: Initializing +[ 0.087509] NetLabel: domain hash size = 128 +[ 0.087550] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 0.087676] NetLabel: unlabeled traffic allowed by default +[ 0.088226] clocksource: Switched to clocksource timebase +[ 0.109127] VFS: Disk quotas dquot_6.6.0 +[ 0.109244] VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) +[ 0.109543] AppArmor: AppArmor Filesystem Enabled +[ 0.121635] NET: Registered protocol family 2 +[ 0.122074] TCP established hash table entries: 32768 (order: 2, 262144 bytes) +[ 0.122584] TCP bind hash table entries: 32768 (order: 3, 524288 bytes) +[ 0.123346] TCP: Hash tables configured (established 32768 bind 32768) +[ 0.123472] UDP hash table entries: 2048 (order: 0, 65536 bytes) +[ 0.123692] UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes) +[ 0.123937] NET: Registered protocol family 1 +[ 0.124257] Unpacking initramfs... +[ 0.467838] Freeing initrd memory: 14080K +[ 0.472109] audit: initializing netlink subsys (disabled) +[ 0.472949] audit: type=2000 audit(1513569522.428:1): state=initialized audit_enabled=0 res=1 +[ 0.473972] Initialise system trusted keyrings +[ 0.474068] Key type blacklist registered +[ 0.474308] workingset: timestamp_bits=38 max_order=16 bucket_order=0 +[ 0.476124] zbud: loaded +[ 0.477006] squashfs: version 4.0 (2009/01/31) Phillip Lougher +[ 0.477456] fuse init (API version 7.26) +[ 0.478394] random: fast init done +[ 0.483013] Key type asymmetric registered +[ 0.483040] Asymmetric key parser 'x509' registered +[ 0.483150] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245) +[ 0.483363] io scheduler noop registered +[ 0.483383] io scheduler deadline registered +[ 0.483450] io scheduler cfq registered (default) +[ 0.484056] virtio-pci 0000:00:00.0: enabling device (0100 -> 0103) +[ 0.485519] virtio-pci 0000:00:00.0: ibm,query-pe-dma-windows(2026) 0 8000000 20000000 returned 0 +[ 0.485916] virtio-pci 0000:00:00.0: ibm,create-pe-dma-window(2027) 0 8000000 20000000 10 20 returned 0 (liobn = 0x80000001 starting addr = 8000000 0) +[ 0.501557] virtio-pci 0000:00:00.0: Using 64-bit direct DMA at offset 800000000000000 +[ 0.503803] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled +[ 0.507398] Linux agpgart interface v0.103 +[ 0.511296] loop: module loaded +[ 0.511671] libphy: Fixed MDIO Bus: probed +[ 0.511698] tun: Universal TUN/TAP device driver, 1.6 +[ 0.511860] PPP generic driver version 2.4.2 +[ 0.512086] VFIO - User Level meta-driver version: 0.3 +[ 0.512309] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 0.512367] ehci-pci: EHCI PCI platform driver +[ 0.512420] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 0.512457] ohci-pci: OHCI PCI platform driver +[ 0.512501] uhci_hcd: USB Universal Host Controller Interface driver +[ 0.512814] mousedev: PS/2 mouse device common for all mice +[ 0.513152] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0 +[ 0.513200] i2c /dev entries driver +[ 0.513320] device-mapper: uevent: version 1.0.3 +[ 0.513482] device-mapper: ioctl: 4.36.0-ioctl (2017-06-09) initialised: <email address hidden> +[ 0.513710] ledtrig-cpu: registered to indicate activity on CPUs +[ 0.514095] NET: Registered protocol family 10 +[ 0.526547] modprobe[89]: unhandled signal 11 at 0000000000000008 nip 000073724fd9645c lr 000073724fd855c0 code 30001 +[ 0.528919] modprobe[90]: unhandled signal 11 at 00000000001e4250 nip 000076c0ae90e0f8 lr 000076c0ae90e6a4 code 30001 +[ 0.529819] Segment Routing with IPv6 +[ 0.529874] NET: Registered protocol family 17 +[ 0.529922] Key type dns_resolver registered +[ 0.530832] registered taskstats version 1 +[ 0.530902] Loading compiled-in X.509 certificates +[ 0.531719] modprobe[93]: unhandled signal 11 at 0000000000000008 nip 0000741ba74e645c lr 0000741ba74d55c0 code 30001 +[ 0.532899] modprobe[94]: unhandled signal 11 at 0000000000000008 nip 0000764dd97f645c lr 0000764dd97e55c0 code 30001 +[ 0.534414] Loaded X.509 cert 'Build time autogenerated kernel key: bc297e5938e0456833a4c0c157e5483b77785cf1' +[ 0.534505] zswap: loaded using pool lzo/zbud +[ 0.535375] modprobe[97]: unhandled signal 11 at 0000000000000008 nip 00007e85a34b645c lr 00007e85a34a55c0 code 30001 +[ 0.536618] modprobe[98]: unhandled signal 11 at 0000000000000008 nip 0000713d7724645c lr 0000713d772355c0 code 30001 +[ 0.537392] Key type big_key registered +[ 0.537418] Key type trusted registered +[ 0.545589] Key type encrypted registered +[ 0.545642] AppArmor: AppArmor sha1 policy hashing enabled +[ 0.545689] ima: No TPM chip found, activating TPM-bypass! (rc=-19) +[ 0.545799] evm: HMAC attrs: 0x1 +[ 0.551224] rtc-generic rtc-generic: setting system clock to 2017-12-18 03:58:43 UTC (1513569523) +[ 0.552107] Unable to open file: /etc/keys/x509_ima.der (-2) +[ 0.552109] Unable to open file: /etc/keys/x509_evm.der (-2) +[ 0.591193] Freeing unused kernel memory: 4608K +[ 0.591643] This architecture does not have kernel memory protection. +<hang> + +Is this the correct place to file kvm-pr bug reports? + +No, this bug tracker is for QEMU bugs only. Please report KVM-PR bugs to the <email address hidden> mailing list (see also https://www.linux-kvm.org/page/Bugs for how to report KVM kernel bugs in general) + +Hi, Timothy. + +I tried to reproduce this issue on a POWER8 box and couldn't reproduce it. + +Whatever the issue was, it seems to be fixed on kernel v4.16-rc4 with qemu 2.11.50. + +I downloaded vmlinux/initrd.gz from Ubuntu 18.04 to boot guest. It booted fine up to the installer initial screen. + +Please find my environment information listed below. + +I'm closing this bug but feel free to reopen it or file a new one. + +Cheers +Murilo + + +Machine type/model: 8247-22L + +[muriloo@baratheon ~]$ uname -a +Linux localhost.localdomain 4.16.0-rc4+ #1 SMP Thu Mar 8 22:54:31 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +[muriloo@baratheon ~]$ lsmod | grep kvm +kvm_pr 100276 0 +kvm 217753 1 kvm_pr + +[muriloo@baratheon ~]$ ~/qemu/build/ppc64-softmmu/qemu-system-ppc64 --version +QEMU emulator version 2.11.50 (v2.11.0-2108-g83d2e94) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +[muriloo@baratheon ~]$ ~/qemu/build/ppc64-softmmu/qemu-system-ppc64 -kernel ~/ubuntu/18.04/vmlinux -initrd ~/ubuntu/18.04/initrd.gz -append "console=hvc0 verbose" -nodefaults -nographic -serial mon:stdio -accel kvm + +vmlinux: http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux +initrd.gz: http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/initrd.gz + diff --git a/results/classifier/zero-shot/108/permissions/1740219 b/results/classifier/zero-shot/108/permissions/1740219 new file mode 100644 index 000000000..f5bb06bac --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1740219 @@ -0,0 +1,194 @@ +permissions: 0.950 +semantic: 0.891 +performance: 0.875 +debug: 0.874 +device: 0.864 +network: 0.828 +graphic: 0.824 +PID: 0.815 +other: 0.803 +KVM: 0.790 +vnc: 0.784 +files: 0.779 +socket: 0.777 +boot: 0.737 + +static linux-user ARM emulation has several-second startup time + +static linux-user emulation has several-second startup time + +My problem: I'm a Parabola packager, and I'm updating our +qemu-user-static package from 2.8 to 2.11. With my new +statically-linked 2.11, running `qemu-arm /my/arm-chroot/bin/true` +went from taking 0.006s to 3s! This does not happen with the normal +dynamically linked 2.11, or the old static 2.8. + +What happens is it gets stuck in +`linux-user/elfload.c:init_guest_space()`. What `init_guest_space` +does is map 2 parts of the address space: `[base, base+guest_size]` +and `[base+0xffff0000, base+0xffff0000+page_size]`; where it must find +an acceptable `base`. Its strategy is to `mmap(NULL, guest_size, +...)` decide where the first range is, and then check if that ++0xffff0000 is also available. If it isn't, then it starts trying +`mmap(base, ...)` for the entire address space from low-address to +high-address. + +"Normally," it finds an accaptable `base` within the first 2 tries. +With a static 2.11, it's taking thousands of tries. + +---- + +Now, from my understanding, there are 2 factors working together to +cause that in static 2.11 but not the other builds: + + - 2.11 increased the default `guest_size` from 0xf7000000 to 0xffff0000 + - PIE (and thus ASLR) is disabled for static builds + +For some reason that I don't understand, with the smaller +`guest_size` the initial `mmap(NULL, guest_size, ...)` usually +returns an acceptable address range; but larger `guest_size` makes it +consistently return a block of memory that butts right up against +another already mapped chunk of memory. This isn't just true on the +older builds, it's true with the 2.11 builds if I use the `-R` flag to +shrink the `guest_size` back down to 0xf7000000. That is with +linux-hardened 4.13.13 on x86-64. + +So then, it it falls back to crawling the entire address space; so it +tries base=0x00001000. With ASLR, that probably succeeds. But with +ASLR being disabled on static builds, the text segment is at +0x60000000; which is does not leave room for the needed +0xffff1000-size block before it. So then it tries base=0x00002000. +And so on, more than 6000 times until it finally gets to and passes +the text segment; calling mmap more than 12000 times. + +---- + +I'm not sure what the fix is. Perhaps try to mmap a continuous chunk +of size 0xffff1000, then munmap it and then mmap the 2 chunks that we +actually need. The disadvantage to that is that it does not support +the sparse address space that the current algorithm supports for +`guest_size < 0xffff0000`. If `guest_size < 0xffff0000` *and* the big +mmap fails, then it could fall back to a sparse search; though I'm not +sure the current algorithm is a good choice for it, as we see in this +bug. Perhaps it should inspect /proc/self/maps to try to find a +suitable range before ever calling mmap? + +Actually, it seems that the `[base+0xffff0000, base+0xffff0000+page_size]` segment is only mapped on 32-bit ARM. So this is 32-bit ARM-specific. + +To have a link to it from here, on the 28th I submitted a patchset to fix this: https://lists.nongnu.org/archive/html/qemu-devel/2017-12/msg05237.html + +From Alistair Buxton (a-j-buxton) on bug 1756807: +I just tested the patch from https://bugs.launchpad.net/qemu/+bug/1740219 and it fixes the problem for me. Specifically I only tried the final patch of the series. + +I duped the bugs onto this one since it is older and has a suggested patch on the ML. + +Added an qemu(Ubuntu) task to further track this, keeping it incomplete there until this is resolved upstream. + +Everything except for the final patch (which has the actual fix) is now applied on the master branch. + +This is now fixed on master, as of 3be2e41b3323169852dca11ffe6ff772c33e5aaa. + +The sha above is the merge, thanks Luke. + +The actual change by you is +commit 2a53535af471f4bee9d6cb5b363746b8d5ed21dd +Author: Luke Shumaker <email address hidden> +Date: Thu Dec 28 13:08:13 2017 -0500 + + linux-user: init_guest_space: Try to make ARM space+commpage continuous + +I'll be away a week but then look at taking this fix in. + +@Luke - to check in advance, are there depending changes post 2.11.1 that are needed for this that you know of? + +I don't believe so. The patchset applies cleanly on 2.11.0, and fixes the issue there. + +Oh, but it's worth noting that patch 1/10 had a mistake in it, which was corrected when applied as 8756e1361d177e91dc6d88f37749b809fd2407fb. + +Back again, +my question was more about if we are able to JUST take 2a53535af471f4bee9d6cb5b363746b8d5ed21dd without the rest. + +We are already in Feature Freeze for Ubuntu 18.04, so we can either + +a) wait for the next release and pick it up in full by the new qemu version (well we will do that anyway) + +b) identify a fix only (not all the cleanup and reworks) patch that will be good for the 2.11.1 in Bionic + +Especially being "just slow" but not broken makes it harder to consider the closer we get to release (I hate that as well being a performance engineer, but minimizing regressions is a target as well :-) ). +Essentially to some extend being in feature freeze is as if we are under [1] already. + +So will 2a53535af471f4bee9d6cb5b363746b8d5ed21dd alone be good in your opinion? +Or will it need more and if so what would be the minimal set of your changes. + + +[1]: https://wiki.ubuntu.com/StableReleaseUpdates + +Yes, I believe that 2a53535af471f4bee9d6cb5b363746b8d5ed21dd alone is good. + +Considering 2.12-rcX a release set the upstream status to that + +We don't generally mark bugs 'fix released' until the final (non-rc) release is made. + + +I wasn't sure if you'd usually take the interim step to "Fix Committed", thanks Peter. + +For Ubuntu: PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3225 + +Regression test against ppa looked good tonight. + +There are new changes which I need to add for two more bugs. +But testing from the ppa is ok right now already. + +@Luke: Please test against this PPA, as I want to ensure it is working for your case before pushing to Bionic. + +I'm not on a Debian/Ubuntu-ish system, but extracting + + qemu-user-static_2.11+dfsg-1ubuntu6~ppa3_amd64.deb : data.tar.xz : usr/bin/qemu-arm-static + +and testing with that binary: + + $ time usr/bin/qemu-arm-static /var/lib/archbuild/dbscripts@armv7h/luke/usr/bin/ldconfig --help + Usage: ldconfig [OPTION...] + ... + <https://github.com/archlinuxarm/PKGBUILDs/issues>. + + real 0m0.068s + user 0m0.067s + sys 0m0.000s + +That is: LGTM. + +Thanks Luke. +I tried the same from the deb of libc for arm in bionic. + +Down from +real 0m2.031s +to +real 0m0.002s + +So confirmed as well. + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu6 + +--------------- +qemu (1:2.11+dfsg-1ubuntu6) bionic; urgency=medium + + * Remove LP: 1752026 changes to d/p/ubuntu/define-ubuntu-machine-types.patch. + The Kernel fixes are preferred and already committed to the kernel. + Therefore remove the default disabling of the HTM feature (LP: #1761175) + * d/p/ubuntu/lp1739665-SSE-AVX-AVX512-cpu-features.patch: Enable new + SSE/AVX/AVX512 cpu features (LP: #1739665) + * d/p/ubuntu/lp1740219-continuous-space-commpage.patch: make Arm + space+commpage continuous which avoids long startup times on + qemu-user-static (LP: #1740219) + * d/p/ubuntu/lp-1761372-*: provide pseries-bionic-2.11-sxxm type as + convenience with all meltdown/spectre workarounds enabled by default. + This is not the default type following upstream and x86 on that. + (LP: #1761372). + * d/p/ubuntu/lp-1704312-1-* provide means to manually handle filesystem-dax + with pmem by backporting align and unarmed options (LP: #1704312). + * d/p/ubuntu/lp-1762315-slirp-Add-domainname.patch: slirp: Add domainname + option to slirp's DHCP server (LP: #1762315) + + -- Christian Ehrhardt <email address hidden> Wed, 04 Apr 2018 15:16:07 +0200 + diff --git a/results/classifier/zero-shot/108/permissions/1742 b/results/classifier/zero-shot/108/permissions/1742 new file mode 100644 index 000000000..c12bf845e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1742 @@ -0,0 +1,110 @@ +permissions: 0.922 +device: 0.905 +boot: 0.897 +performance: 0.888 +other: 0.879 +debug: 0.862 +files: 0.856 +graphic: 0.845 +vnc: 0.840 +semantic: 0.833 +PID: 0.821 +KVM: 0.811 +network: 0.801 +socket: 0.781 + +Arm64 kernel run with qemu-system-aarch64 crashes handling program using SVE and Streaming SVE modes +Description of problem: +The userspace program shown, which switches between SVE/SME states, crashes the kernel on task switch when running under qemu-system-aarch64. This does not reproduce on an Arm Fast Model, but I can't be sure that that is not a timing difference. + +The kernel appears to have no space allocated to save SVE state for this process, but also believes that it should save the state, where it then faults. +Steps to reproduce: +1. Compile the following program: +``` +#include <sys/prctl.h> + +int main() { + asm volatile("msr s0_3_c4_c7_3, xzr" /*smstart*/); + prctl(PR_SVE_SET_VL, 8 * 4); + asm volatile("msr s0_3_c4_c7_3, xzr" /*smstart*/); + while (1) {} // Wait to be preempted? + return 0; +} +``` +With: +``` +$ aarch64-unknown-linux-gnu-gcc main.c -o main.o -g -O3 -march=armv8.6-a+sve +``` +Compiler version does not matter I don't think, but in case: +``` +$ aarch64-unknown-linux-gnu-gcc --version +aarch64-unknown-linux-gnu-gcc (crosstool-NG 1.25.0.85_61c4cca) 10.4.0 +``` +It is a 10.4.0 built with CrossToolNG. + +2. Boot Linux and run the program in the emulated environment. I've found looping it to be more consistent: +``` +$ while true; do ./main.o; done +``` +Though sometimes it will crash after only one run. +Additional information: +Here is the output from the kernel: +``` +$ /mnt/virt_root/sme_crash/main.o +[ 190.813392] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 +[ 190.818912] Mem abort info: +[ 190.819255] ESR = 0x0000000096000046 +[ 190.819727] EC = 0x25: DABT (current EL), IL = 32 bits +[ 190.820391] SET = 0, FnV = 0 +[ 190.820757] EA = 0, S1PTW = 0 +[ 190.821145] FSC = 0x06: level 2 translation fault +[ 190.821635] Data abort info: +[ 190.821978] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 +[ 190.822490] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 +[ 190.822991] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 +[ 190.823645] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000475f1000 +[ 190.824269] [0000000000000000] pgd=0800000047645003, p4d=0800000047645003, pud=0800000047641003, pmd=0000000000000000 +[ 190.826225] Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP +[ 190.826996] Modules linked in: +[ 190.827748] CPU: 0 PID: 198 Comm: main.o Not tainted 6.4.0-01761-g6aeadf7896bf #1 +[ 190.828638] Hardware name: linux,dummy-virt (DT) +[ 190.829304] pstate: 234000c5 (nzCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) +[ 190.830115] pc : sve_save_state+0x4/0xf0 +[ 190.831378] lr : fpsimd_save+0x184/0x1f0 +[ 190.831848] sp : ffff80008047bc70 +[ 190.832223] x29: ffff80008047bc70 x28: ffff0000036c49c0 x27: 0000000000000000 +[ 190.833182] x26: ffff0000036c4f58 x25: ffff0000036c49c0 x24: ffff0000036c5868 +[ 190.834045] x23: 0000000000000020 x22: ffff24441ea31000 x21: 0000000000000001 +[ 190.834894] x20: ffff00003fdc50b0 x19: ffffdbbc213940b0 x18: 0000000000000000 +[ 190.835759] x17: ffff24441ea31000 x16: ffff800080000000 x15: 0000000000000000 +[ 190.836593] x14: 000000000000026c x13: 0000000000000001 x12: 0000000000000020 +[ 190.837436] x11: 0000000000000000 x10: 0000000000000001 x9 : 0000000000000800 +[ 190.838323] x8 : ffff00003fdcffc0 x7 : ffff00003fdcff40 x6 : 0000000002da9c8c +[ 190.839149] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000000 +[ 190.839976] x2 : 0000000000000001 x1 : ffff0000036c56a0 x0 : 0000000000000440 +[ 190.840936] Call trace: +[ 190.841406] sve_save_state+0x4/0xf0 +[ 190.841993] fpsimd_thread_switch+0x24/0xd4 +[ 190.842572] __switch_to+0x20/0x1d4 +[ 190.843043] __schedule+0x2a0/0xa7c +[ 190.843488] schedule+0x5c/0xc4 +[ 190.843912] do_notify_resume+0x1a4/0x474 +[ 190.844410] el0_interrupt+0xc4/0xd4 +[ 190.844855] __el0_irq_handler_common+0x18/0x24 +[ 190.845350] el0t_64_irq_handler+0x10/0x1c +[ 190.845824] el0t_64_irq+0x190/0x194 +[ 190.846661] Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) +[ 190.847545] ---[ end trace 0000000000000000 ]--- +[ 190.848125] note: main.o[198] exited with irqs disabled +``` + +I have looked the kernel functions in the backtrace and it seems to be loading memory fine, so it's not obviously a code generation problem. The pointer loaded prior to the crash is definitely a nullptr. + +Removing any of the lines (`while (1) {}` aside) from the example seems to avoid the issue but again, could be timing. + +An important point here is that the kernel syscall ABI states that streaming mode will be exited on +a syscall. I have observed that this does happen as expected. This is why the test case does a syscall, then immediately goes back to streaming mode. And it is perhaps where the confusion starts. + +I have confirmed that SME is supported by the emulated CPU and other SME programs do run correctly. + +I initially thought this was to do with having many cores, but it reproduces on a single core also. diff --git a/results/classifier/zero-shot/108/permissions/1745312 b/results/classifier/zero-shot/108/permissions/1745312 new file mode 100644 index 000000000..d91373eba --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1745312 @@ -0,0 +1,2238 @@ +permissions: 0.950 +other: 0.933 +debug: 0.925 +socket: 0.909 +graphic: 0.899 +boot: 0.898 +device: 0.896 +semantic: 0.888 +PID: 0.874 +files: 0.871 +performance: 0.856 +network: 0.855 +vnc: 0.774 +KVM: 0.728 + +Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused] + +[Headsup: This report is long-ish due to the amount of detail I've stumbled on along the way that I think is relevant to include. I can't speak as to the complexity of the actual bugs, but the size of this report should not suggest that the reproduction process is particularly headache-inducing.] + +Hi! + +I recently needed to fire up some ancient software for research purposes and got very distracted discovering and playing with old versions of Windows :). In the process I've discovered some glitches with disk I/O. + +I believe I've stumbled on two completely separate issues that coincidentally surfaced at the same time. It's possible that components of this report will be re-filed as more specific new bugs, but I'm not an authority on QEMU internals or how to narrow down/categorize what I've found. + +- The first bug only surfaces when the "isapc" machine type is used. It intermittently produces "General failure {read,writ}ing drive _" under MS-DOS 6.22, and also somehow interferes with early bootstrap of Windows NT 4 (in NTLDR). Enabling or disabling KVM (I'm on Linux) appears to make no difference whatsoever, which may help with debugging. + +- The second issue involves + - a WinNT4 disk image + - created by running through a bog-standard NT4 install inside QEMU 2.9.0 + - which will now fail to boot in any version of QEMU - even version 1.0 + - but which VirtualBox will boot fine + - but only if I point VirtualBox at QEMU's raw disk image via a + hacked-together VMDK file + - if the raw image is converted to VHD(X), VirtualBox will also fail + to boot the image with exactly the same error as QEMU + - this state of affairs is not affected by image sparseness (which makes + sense) + +I'm confident I've bisected the first issue. + +I wasn't able to bisect the second issue (as all tested versions of QEMU behaved identically), but I've figured out a working repro testcase and I believe I've managed to pin down a solid root cause. + + + +== #1: Intermittent I/O issues when `-M isapc` is used ===== + +These symptoms sometimes take a small amount of time and fiddling to trigger, but I AM able to consistently surface them on my machine after a short while. (I am very very interested to hear if others cannot reproduce them.) + +So, first of all: + +https://github.com/qemu/qemu/commit/306ec6c3cece7004429c79c1ac93d49919f1f1cc + (Jul 30 2013): the last version that works + +https://github.com/qemu/qemu/commit/e689f7c668cbd9d08f330e17c3dd3a059c9553d3 + (Oct 30 2013): the first version that intermittently fails + +Maybe lift out and build these branches while reading. *shrug* +(How to do this can be found at the end of this report - along with a time-saving ./configure line, FWIW) + +Here are the changelists between these two revisions: + +https://github.com/qemu/qemu/compare/306ec6c...e689f7c +(Compare direction: OLD to NEW) (Commits: 166 Files changed: 192) + +https://github.com/qemu/qemu/compare/e689f7c...306ec6c +(Compare direction: NEW to OLD) (Commits: 30 Files changed: 22) + +(Someone else more familiar with Git might know why GitHub returns results for both compare directions, and/or if the 2nd link is useful information. The first link returns a lot more results than the 2nd one, at least. Does comparing new>old return deletions?) + +--- + +Now on to the symptoms. In a moment I'll describe reproduction. + +# MS-DOS 6.22 + +The first symptom I discovered was that trivial read and write operations under MS-DOS would sometimes fail: + + C:\>echo test > hi + + General failure writing drive C + Abort, Retry, Fail? + +Anything else that exercises the disk behaves similarly: + + C:\>dir /s > nul + + General failure reading drive C + Abort, Retry, Fail? + +(Note that the above demonstrates both write and read failures) + +(Also, FWIW, `dir /s` == `ls -R`) + +The behavior of the I/O errors is not possible to characterise as it fluctuates so much. For example something as simple as DIR can produce wildly differing results: in one run, poking around with DIR ended with DOS deciding C:\ was empty at one point; at another point in a different run C:\ mysteriously dropped 50% of its contents only to magically gain it all back moments later after some poking around in one of the subdirectories that was still visible. + +The time it takes to trigger these errors is also highly variable. QEMU may fall over as early as hanging forever at "Starting MS-DOS...", or I might get all the way into Windows 3.1 before it triggers (in which case Win3.1 reports vague memory errors - of all things). + +Very occasionally I've seen _SeaBIOS itself_ report "Booting from Hard Disk..." "Boot failed: could not read the boot disk" ... "No bootable device.", and on one occasion I even got "Non-System disk or disk error" "Replace and strike any key when ready"! + + +# WinNT 4 Terminal Server + +Most of the time, NTLDR will fire up normally. But every so often... + + SeaBIOS (version rel-1.7.3-117-g31b8b4e-20131206_080705-nilsson.home.kraxel.org) + + Booting from Hard Disk... + A disk read error occurred. + Insert a system diskette and restart + the system. + +(NB. You're seeing the old SeaBIOS version included with e689f7c, which was the first buggy commit.) + +If NT gets past this point without erroring out (ie, it makes it to the boot menu), the rest of the system is 100% fine and there are no other disk I/O issues whatsoever. For example, on QEMU 2.9.0 I was able to enable disk compression, answer "Yes" to "Compress entire disk now?" and have the process fully complete. No hitches. + +This makes me vaguely recall/wonder that perhaps this could be somehow related to LBA and/or Int 13h, or something floating around near that bunch of functionality. (I'm woefully ignorant about such low-level details.) Perhaps DOS/Win3.1 are stuck using a disk mode that QEMU has a buggy implementation of, while NT 4 (once NTOSKRNL is up and running) is able to use a different disk mode or access mechanism. + +I'm really interested to get some understanding of what the root issue is here, when this is fixed. (I wonder if it's a timing thing?) + +I've observed some unusual behavior with repeated restarts. In one case, I attempted to start NT4 multiple times, and QEMU consistently failed with "No bootable device" each time. So, I removed `-M isapc`, promptly got a boot menu, hit ^C, readded `-M isapc` - and continued to get a boot menu. Yep. I'll accept "really really big coincidence" but I do very much wonder if something else is going on here. I've observed many similar incidents. It makes me wonder whether the contents of memory or some other system state is an influence. Very probably not, but still... + + + +-- Reproduction -------------------------------------------- + +First of all, there was unfortunately no way for me to avoid having to post entire disk images, but I've managed to compress everything down to 174MB total download size. + +FWIW, WinWorld and many other sites seem to have no operational issues providing clear pointers to CD keys; I consider my distribution of my installed HDD images an extension of the apparent status quo. + +That being said, I've put everything on Google Drive so nobody has to headscratch about Launchpad/Canonical/etc's stance on hosting this data. + +So, this folder contains the disk images: https://drive.google.com/drive/folders/1WdZVBh5Trs9HLC186-nHyKeqaSxfyM2c ("Download all" at the top-right will create a ZIP file, but FWIW downloading the individual files simultaneously would implement a rough form of download acceleration) + +File meta info: + +Compressed +| +| Apparent +| | Actual +| | | +38M -> 200M (103M) win31.img.xz +82M -> 1G (289M) wnt4ts-broken.img.xz +55M -> 350M (146M) wnt4ts-intermittent.img.xz + +SHA-256s: + +win31: 8179b8180a2ab40bd472e8a2f3fb89fc331651e56923f94ceb9e52a78ee220d2 +broken: a2af5f0bc49a063b75f534b6ffe5b82e32ecc706a64a425b6626feccf6e3fdfa +intermittent: 77ae8c458829ebcdd64c71042012f45d5a2788e6ebd22db9d53de9ef1a574784 + +(Wanted to keep the checksum lines within 80 columns) + +And, since I can't figure out where else in this report to put this, wnt4ts-broken.img's password is "admin" but something seems to have happened to the disk and NT doesn't actually boot properly :(, and wnt4ts-intermittent.img's password is "1234". (These were set up as test images. Now I'm _really_ glad I used simple passwords! :) ) + +--- + + +I have two testcases: DOS 6.22 (+ Windows 3.1), and Windows NT 4. + + +# MS-DOS + +DOS is the simplest. It basically consists of + +$ qemu-system-i386 -drive file=win31.img,format=raw -M isapc -enable-kvm + +And then literally just playing around. Things to try include creating files (`echo blah > file`), repeatedly seeking across the entire FAT (`dir /s > nul` or `dir /s`), and launching Windows (`win`). + +win31.img is not special (as far as I can tell) and merely consists of the result of installing DOS 6.22 and Windows 3.1 from WinWorldPC. I've basically just included the image for convenience. + +Generally no single "run" is immune to starting Win3.1 and then launching File Manager; if that doesn't generate an error, something is definitely up. + +The second best trigger is creating new files. That very very frequently produces "General Failure ...", but not always. + + +# WinNT 4 + +Windows NT 4 is a bit more complicated. Because this error only occurs at presumably a single small point very early in boot, the window of opportunity for the glitch to surface within is much much narrower and thus often requires a larger number of tries. + +Anecdotally I've had QEMU hit the boot error at the first try/run, and after as many as 63 "successful" boots. + +I made a small test harness that automates the launch process. It consists of two shell scripts and requires tmux (and netcat). (*Potential epilepsy warning*: if you use a light-colored terminal background, the terminal QEMU is repeatedly invoked from will continuously flash rapidly from white to black.) + +One of the scripts is run inside a tmux session in one terminal, while the other script is run in its own terminal (without any tmux). + + +I named this one `run-qemu-loop`: + +--8<-------------------------------------------------------- + +#!/bin/bash + +# --- + +qemu=/path/to/qemu-system-i386 +#or, alternatively: (I used the following line myself so I +#could tab-complete my way to different qemu executables) +#qemu="$1" + +disk=/path/to/wnt4ts-intermittent.img + +# --- + +port=4444 + +rm -f STOP itercount + +itercount=0 + +while :; do + + [ -f STOP ] && break + + ((itercount++)) + echo $itercount > itercount + + $qemu \ + -enable-kvm -vga cirrus -curses -M isapc \ + -drive file="$disk",format=raw \ + -chardev socket,id=mon0,host=localhost,port=$port,server,nowait \ + -mon chardev=mon0,mode=readline + + #point to an otherwise-unused terminal if you like (see also: `tty`) + #echo "$itercount run(s)" > /dev/pts/__ + +done + +------------------------------------------------------------ + +Not much logic above; this just repeatedly runs QEMU for as long as +the file `STOP` does not exist in the current directory. + +The key "magic" bit is that QEMU is launched in -curses mode. + +The other key bit is that the above script is run inside tmux. + + +Here's `tmux-ctl-loop`: + +--8<-------------------------------------------------------- + +#!/bin/bash + +port=4444 + +tmux=./tmux + +printf -v l '%0.0s-' {0..25} +h1="$l/ buffer dump begin \\$l" +h2="$l-\\ buffer dump end /-$l" + +while :; do + + while :; do + echo | nc localhost $port -q0 -w1 > /dev/null && break + echo 'Start qemu!' + done + + buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)" + + echo "$h1" + [[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )' + echo "$h2" + + if echo "$buffer" | grep -q 'A disk read error occurred.'; then + + s="<Crashed after $(< itercount) runs.>" + echo "$s" + echo "$s" >> stats + + touch STOP + + #echo q | nc localhost $port -q0 > /dev/null + + exit + + elif echo "$buffer" | grep -q 'OS Loader V4.00'; then + + echo '<Booted successfully, trying again>' + + echo q | nc localhost $port -q0 > /dev/null + + else + + echo '<Waiting for boot>' + + fi + +done + +------------------------------------------------------------ + +Nothing particularly amazing going on here either. + +While `qemu-run-loop` is running inside tmux in the first terminal, this is running in the 2nd one. + +The small infinite loop at the top only breaks when it can successfully ping QEMU and it knows it's running. + +Then, a screendump of the contents of the terminal QEMU is in is fetched from tmux, and the buffer's content is analyzed. + +- If NTLDR fails, the script creates `STOP` to halt qemu-run-loop, + sends `q` to QEMU through netcat, and then the script exits. + +- If NTLDR loads successfully, the script sends `q` to QEMU and continues + looping. (qemu-run-loop will not find the `STOP` file, and so restart qemu.) + +The scripts run very quickly, with 2-3 iterations per second on my i3 box. + + + +# Usage + +Save the two scripts above to the same directory as wnt4ts-intermittent.img, +then: + +- (If port 4444 doesn't work, the value needs to be changed in both scripts.) + +- In the first terminal, run `tmux -S <file>`, where <file> names the socket + tmux will use. This needs to match "tmux=" at the top of `tmux-ctl-loop`. + (with `tmux=./tmux`, the command would be `tmux -S tmux`) + +- Still in the first terminal (and now also inside tmux), enter + `./qemu-run-loop`, passing the path to qemu if you're using that approach + (refer to the first few lines of the script). Don't hit enter yet. + +- Now, in the 2nd terminal, type `./tmux-ctl-loop` + +- Hit enter in both terminals. + + +Rationale for timing of Enter key: + +- Running qemu-run-loop first will start QEMU, and if NTLDR starts + successfully it will immediately begin counting down from 30. If NT actually + starts to boot and is then hard-shut-down this /may/ affect the disk image + +- tmux-ctl-loop will annoyingly spam a continuous stream of 'Start qemu!' until + qemu-run-loop is running. + +- Starting both scripts at "more or less" the same time (no rush) works out + well. + + +Hopefully potential script modifications are obvious; for example + +- changing tmux-ctl-loop to not send 'q' to qemu so you can connect to the HMP + yourself + (NB, if `STOP` is not created, when qemu finally exits it will of course + promptly be relaunched) + +- pointing run-qemu-loop to a modified qemu binary + + + +== #2: QEMU-vs-VirtualBox image issue ====================== + +I was initially completely stumped by this issue, perhaps unsurprisingly so. :) + +wnt4ts-broken.img is a perfectly ordinary NT 4 installation that was created in QEMU 2.9.0. I created a 1GB disk with `truncate`, picked NTFS and installed everything (which took a while). + +NT setup reboots a number of times during the boot process, and IIRC those all went just fine. However, at some point, the image began to consistently bomb out with "A disk read error occurred. ...", and stubbornly refused to boot, regardless of the number of boot attempts I tried. + +QEMU 2.0.0, 1.5.0, and 1.0 (the earliest version I was able to build on my system) all consistently hit "disk read error occurred". + +I tried compiling QEMU 1.0 using clang so I could build for 32-bit on my 64-bit system (GCC 7 died with "Frame pointer required, but reserved"). The resulting qemu completely crashed if I didn't enable KVM (ie, TCG was (understandably) broken); with KVM enabled qemu didn't crash, but NTLDR halted with the same error as on 64-bit qemu. (TL;DR, no difference whatsoever.) + +My initial reaction at this point was to try the image on another virtualization platform. My first pick was VirtualBox. + +So, I followed the official instructions for pointing VirtualBox to physical disk images, except I substituted a /dev/loopN device I'd pointed to the image file via losetup. + +And... VirtualBox picked the image up fine and Just Worked(TM). Yay! - but not yay. What gives?! + +Confused, I then tried to convert the disk image to VHD format. Unfortunately, for some reason, if I try `qemu-image convert ... -O vhdx ...`, VirtualBox chokes on the result: + +----- + +VD: error VERR_NOT_SUPPORTED opening image file +'/.../wnt4ts-broken-qemuconv.vhd' (VERR_NOT_SUPPORTED). + +Result Code: NS_ERROR_FAILURE (0x80004005) +Component: MediumWrap +Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda} +Callee: IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945} +Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001) + +----- + +Welp. + +Well, a bit more digging later, and I found I could do + +$ VBoxManage convertfromraw wnt4ts-broken.img wnt4ts-broken.vhd + +but... as soon as I pointed VirtualBox to this, it too began to choke with "A disk read error occurred". + +And yet, the VMDK->raw image setup worked just fine. + +I found I could even replace the loop device with the path of the .img file itself and that worked just fine too. + +At my wits' end, I followed some online instructions to learn about manual CHS configuration so I could try and get the image working in Bochs. "A disk read error occurred". I wasn't surprised. + +It was at this point I began to give up, but I decided to try One Last Thing(TM) before properly throwing in the towel. + +:) + +I decided to learn a bit more about how `VBoxManage internalcommands createrawvmdk` worked, and try one thing in particular: I can edit the .vmdk file, but can I point `createrawvmdk` at the .img file directly too? + +Turns out, yes you can. + +It also turns out that this promptly caused VirtualBox to bomb out. + +Interesting. + +For reference, here's the VMDK file I initially created (by pointing `createrawvmdk` at /dev/loopN) and then later edited to point straight to the .img file, with both approaches resulting in successful boot. + +--8<-------------------------------------------------------- + +# Disk DescriptorFile +version=1 +CID=e35b9a45 +parentCID=ffffffff +createType="fullDevice" + +# Extent description +RW 1536000 FLAT "/absolute/full/path/to/wnt4ts-broken.img" 0 + +# The disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.adapterType="ide" +ddb.geometry.cylinders="1523" +ddb.geometry.heads="16" +ddb.geometry.sectors="63" +ddb.uuid.image="871a6044-c8ca-48ed-b7aa-e6fc49da3db4" +ddb.uuid.parent="00000000-0000-0000-0000-000000000000" +ddb.uuid.modification="3661715c-3906-4e4a-ab65-486d140e03b8" +ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000" +ddb.geometry.biosCylinders="761" +ddb.geometry.biosHeads="32" +ddb.geometry.biosSectors="63" + +------------------------------------------------------------ + + +Here's the _diff_ of what happens if I point `createrawvmdk` at wnt4ts-broken.img directly: + +--8<-------------------------------------------------------- + +ddb.geometry.cylinders="2080" +ddb.geometry.heads="16" +ddb.geometry.sectors="63" + +------------------------------------------------------------ + +:D + +Naturally, + +$ qemu-system-i386 -drive file=wnt4ts-broken.img,format=raw,cyls=1523,heads=16,secs=63 -M isapc -sdl + +will boot happily on 2.9.0 (notwithstanding the occasional "disk read error occurred" documented above). + +It will also boot in 1.6.0. + +(POTENTIAL BUG HEADSUP: 1.0 and 1.5.0 both lock up with a blank 640x480 window and use 0% CPU if I specify `-M isapc`.) + +And, of course, using these CHS values in Bochs also results in successful boot as well (after setting the CPU type to pentium). + +Unfortunately, I have no idea what sequence of events caused the creation of the VMDK file above. No invocation of `createrawvmdk` is producing a VMDK file with the CHS settings above. + +I've only just begun to learn about the intricacies of CHS. Am I to understand that these values are stored amongst the first 512 bytes of the disk? If this is the case, then I wonder what changed the data, and why. I was initially only using QEMU 2.9.0, and didn't move the image to different VMs or QEMU versions. Perhaps Windows NT got confused about the disk CHS and rewrote it? + + +== Sporadic BIOS-level boot failure ======================== + +I have multiple screenshots of SeaBIOS in QEMU 2.9.0 halting with "No bootable device" (et al), even with the above manually-applied CHS settings. + +Commit e689f7c also presents such errors. + +Commit 306ec6c does not suffer from intermittent breakage of any kind: + +- No SeaBIOS flake-outs +- No "Non-system disk or disk error" +- No "A disk error has occurred" +- No "General failure ..." + +While most of my confidence in commit 306ec6c is based on anecdotal evidence, I modified `tmux-ctl-loop` a little to soak-test BIOS-level I/O stability and left this modified version running for a few minutes. + +--8<-------------------------------------------------------- + +#!/bin/bash + +port=4444 + +tmux=./tmux + +printf -v l '%0.0s-' {0..25} +h1="$l/ buffer dump begin \\$l" +h2="$l-\\ buffer dump end /-$l" + +while :; do + + while :; do + echo | nc localhost $port -q0 -w1 > /dev/null && break + echo 'Start qemu!' + done + + buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)" + + echo "$h1" + [[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )' + echo "$h2" + + if echo "$buffer" | grep -q 'Non-system disk' || echo "$buffer" | \ + grep -q 'No bootable device' + then + + s="<Hit error after $(< itercount) runs.>" + echo "$s" + echo "$s" >> stats + + touch STOP + + #echo q | nc localhost $port -q0 > /dev/null + + exit + + elif echo "$buffer" | grep -q 'OS Loader V4.00' || echo "$buffer" | \ + grep -q 'A disk read error' + then + + echo '<Boot did not hang at BIOS, trying again>' + + echo q | nc localhost $port -q0 > /dev/null + + else + + echo '<Waiting for boot>' + + fi + +done + +------------------------------------------------------------ + +For the above to work, the top of run-qemu-loop must also be modified to read something along the lines of + +disk=/path/to/wnt4ts-broken.img,format=raw,cyls=1523,heads=16,secs=63 + +(Suggestion: modify copies of both scripts) + +One small terminal-flicker-headache (and a 57°C CPU) later, I was able to carefully observe just over 350 successful runs in which QEMU commit 306ec6c only ever produced a boot menu. No other hitches. + +** Important: ** + +However, commit 306ec6c will fail to boot, ever, if the cylinders and geometry are not set to the values VirtualBox "discovered". (Of note is the fact that QEMU (2.9.0) was what initially created this image. I must admit that I don't remember what sequence of QEMU versions I fed the image to - and I maybe, possibly, didn't think to back the file up (sorry), so maybe something mangled something somewhere. But VirtualBox figured it out nonetheless!) + +Furthermore, feeding /dev/loopN to any QEMU version will NOT result in correct CHS discovery (and successful boot). + +This is what leads me to conclude that I've discovered two separate issues. + + + +== Appendix: How to build the branches ===================== + +It's very simple. + +First, `git clone https://github.com/qemu/qemu` somewhere if you don't already have a local copy. If you have an old git checkout that's from 2014 or later, you can use that old checkout instead. (If you want to test an old checkout you have, the commands below will either work perfectly or completely bomb out with no side effects.) + +A full checkout is a ~183MB download. Sorry. + +Next, create two new directories somewhere. Name them what you like, eg `qemu-working` and `qemu-broken`. + +Now, cd into the checkout directory, and run: + +$ git archive 306ec6c3cece7004429c79c1ac93d49919f1f1cc | tar xC /path/to/qemu-working/ + +$ git archive e689f7c668cbd9d08f330e17c3dd3a059c9553d3 | tar xC /path/to/qemu-broken/ + +The paths can be relative. + +Now, run this in both of the new directories: + +$ ./configure --python=python2.7 --disable-libssh2 --disable-seccomp --disable-usb-redir --disable-guest-agent --disable-libiscsi --disable-spice --disable-smartcard-nss --disable-vhost-net --disable-docs --disable-attr --disable-cap-ng --disable-vde --disable-user --disable-bluez --disable-vnc-ws --disable-xen --disable-brlapi --enable-debug --target-list=i386-softmmu --disable-fdt + +$ make -j64 + +You can open two terminals and configure and build both simultaneously if you like. + +On my decent but very basic (2-core+HT) i3 box, -j64 actually works out - make doesn't actually launch too many gcc processes. You *will* see your system load spike to ~20 though :) +(NB. Do. not. use. -j64. with. the. linux. kernel.) + +On my system, a single build with -j64 takes only about 35 seconds. C FTW. (Although this has increased to 1min20sec for more recent builds.) + +Most of the configure arguments remove functionality I'll never use (in this situation) and which will only slow down the build. + +Once QEMU is built, run qemu-system-i386 directly from where it has been built. + +$ /path/to/qemu-working/i386-softmmu/qemu-system-i386 ... +$ /path/to/qemu-broken/i386-softmmu/qemu-system-i386 ... + +Again, the paths can be relative. + +On Thu, Jan 25, 2018 at 07:18:52AM -0000, i336_ wrote: +> Public bug reported: +> +> [Headsup: This report is long-ish due to the amount of detail I've +> stumbled on along the way that I think is relevant to include. I can't +> speak as to the complexity of the actual bugs, but the size of this +> report should not suggest that the reproduction process is particularly +> headache-inducing.] + +I've CCed people who may be able to help. + +I don't have time to read through everything you've posted. + +> Hi! +> +> I recently needed to fire up some ancient software for research purposes +> and got very distracted discovering and playing with old versions of +> Windows :). In the process I've discovered some glitches with disk I/O. +> +> I believe I've stumbled on two completely separate issues that +> coincidentally surfaced at the same time. It's possible that components +> of this report will be re-filed as more specific new bugs, but I'm not +> an authority on QEMU internals or how to narrow down/categorize what +> I've found. +> +> - The first bug only surfaces when the "isapc" machine type is used. It +> intermittently produces "General failure {read,writ}ing drive _" under +> MS-DOS 6.22, and also somehow interferes with early bootstrap of Windows +> NT 4 (in NTLDR). Enabling or disabling KVM (I'm on Linux) appears to +> make no difference whatsoever, which may help with debugging. + +Is this using the IDE disk controller? In that case John Snow can help +you debug what's going on at the IDE level. + +> - The second issue involves +> - a WinNT4 disk image +> - created by running through a bog-standard NT4 install inside QEMU 2.9.0 +> - which will now fail to boot in any version of QEMU - even version 1.0 +> - but which VirtualBox will boot fine +> - but only if I point VirtualBox at QEMU's raw disk image via a +> hacked-together VMDK file +> - if the raw image is converted to VHD(X), VirtualBox will also fail +> to boot the image with exactly the same error as QEMU +> - this state of affairs is not affected by image sparseness (which makes +> sense) + +VMDK stores the disk geometry (cylinders, heads, sectors), which may +affect guest software. I've CCed Fam Zheng. + +> +> I'm confident I've bisected the first issue. +> +> I wasn't able to bisect the second issue (as all tested versions of QEMU +> behaved identically), but I've figured out a working repro testcase and +> I believe I've managed to pin down a solid root cause. +> +> +> == #1: Intermittent I/O issues when `-M isapc` is used ===== +> +> These symptoms sometimes take a small amount of time and fiddling to +> trigger, but I AM able to consistently surface them on my machine after +> a short while. (I am very very interested to hear if others cannot +> reproduce them.) +> +> So, first of all: +> +> https://github.com/qemu/qemu/commit/306ec6c3cece7004429c79c1ac93d49919f1f1cc +> (Jul 30 2013): the last version that works +> +> https://github.com/qemu/qemu/commit/e689f7c668cbd9d08f330e17c3dd3a059c9553d3 +> (Oct 30 2013): the first version that intermittently fails +> +> Maybe lift out and build these branches while reading. *shrug* +> (How to do this can be found at the end of this report - along with a time-saving ./configure line, FWIW) +> +> Here are the changelists between these two revisions: +> +> https://github.com/qemu/qemu/compare/306ec6c...e689f7c +> (Compare direction: OLD to NEW) (Commits: 166 Files changed: 192) +> +> https://github.com/qemu/qemu/compare/e689f7c...306ec6c +> (Compare direction: NEW to OLD) (Commits: 30 Files changed: 22) +> +> (Someone else more familiar with Git might know why GitHub returns +> results for both compare directions, and/or if the 2nd link is useful +> information. The first link returns a lot more results than the 2nd one, +> at least. Does comparing new>old return deletions?) +> +> --- +> +> Now on to the symptoms. In a moment I'll describe reproduction. +> +> # MS-DOS 6.22 +> +> The first symptom I discovered was that trivial read and write +> operations under MS-DOS would sometimes fail: +> +> C:\>echo test > hi +> +> General failure writing drive C +> Abort, Retry, Fail? +> +> Anything else that exercises the disk behaves similarly: +> +> C:\>dir /s > nul +> +> General failure reading drive C +> Abort, Retry, Fail? +> +> (Note that the above demonstrates both write and read failures) +> +> (Also, FWIW, `dir /s` == `ls -R`) +> +> The behavior of the I/O errors is not possible to characterise as it +> fluctuates so much. For example something as simple as DIR can produce +> wildly differing results: in one run, poking around with DIR ended with +> DOS deciding C:\ was empty at one point; at another point in a different +> run C:\ mysteriously dropped 50% of its contents only to magically gain +> it all back moments later after some poking around in one of the +> subdirectories that was still visible. +> +> The time it takes to trigger these errors is also highly variable. QEMU +> may fall over as early as hanging forever at "Starting MS-DOS...", or I +> might get all the way into Windows 3.1 before it triggers (in which case +> Win3.1 reports vague memory errors - of all things). +> +> Very occasionally I've seen _SeaBIOS itself_ report "Booting from Hard +> Disk..." "Boot failed: could not read the boot disk" ... "No bootable +> device.", and on one occasion I even got "Non-System disk or disk error" +> "Replace and strike any key when ready"! +> +> +> # WinNT 4 Terminal Server +> +> Most of the time, NTLDR will fire up normally. But every so often... +> +> SeaBIOS (version rel-1.7.3-117-g31b8b4e- +> 20131206_080705-nilsson.home.kraxel.org) +> +> Booting from Hard Disk... +> A disk read error occurred. +> Insert a system diskette and restart +> the system. +> +> (NB. You're seeing the old SeaBIOS version included with e689f7c, which +> was the first buggy commit.) +> +> If NT gets past this point without erroring out (ie, it makes it to the +> boot menu), the rest of the system is 100% fine and there are no other +> disk I/O issues whatsoever. For example, on QEMU 2.9.0 I was able to +> enable disk compression, answer "Yes" to "Compress entire disk now?" and +> have the process fully complete. No hitches. +> +> This makes me vaguely recall/wonder that perhaps this could be somehow +> related to LBA and/or Int 13h, or something floating around near that +> bunch of functionality. (I'm woefully ignorant about such low-level +> details.) Perhaps DOS/Win3.1 are stuck using a disk mode that QEMU has a +> buggy implementation of, while NT 4 (once NTOSKRNL is up and running) is +> able to use a different disk mode or access mechanism. +> +> I'm really interested to get some understanding of what the root issue +> is here, when this is fixed. (I wonder if it's a timing thing?) +> +> I've observed some unusual behavior with repeated restarts. In one case, +> I attempted to start NT4 multiple times, and QEMU consistently failed +> with "No bootable device" each time. So, I removed `-M isapc`, promptly +> got a boot menu, hit ^C, readded `-M isapc` - and continued to get a +> boot menu. Yep. I'll accept "really really big coincidence" but I do +> very much wonder if something else is going on here. I've observed many +> similar incidents. It makes me wonder whether the contents of memory or +> some other system state is an influence. Very probably not, but still... +> +> +> -- Reproduction -------------------------------------------- +> +> First of all, there was unfortunately no way for me to avoid having to +> post entire disk images, but I've managed to compress everything down to +> 174MB total download size. +> +> FWIW, WinWorld and many other sites seem to have no operational issues +> providing clear pointers to CD keys; I consider my distribution of my +> installed HDD images an extension of the apparent status quo. +> +> That being said, I've put everything on Google Drive so nobody has to +> headscratch about Launchpad/Canonical/etc's stance on hosting this data. +> +> So, this folder contains the disk images: +> https://drive.google.com/drive/folders/1WdZVBh5Trs9HLC186-nHyKeqaSxfyM2c +> ("Download all" at the top-right will create a ZIP file, but FWIW +> downloading the individual files simultaneously would implement a rough +> form of download acceleration) +> +> File meta info: +> +> Compressed +> | +> | Apparent +> | | Actual +> | | | +> 38M -> 200M (103M) win31.img.xz +> 82M -> 1G (289M) wnt4ts-broken.img.xz +> 55M -> 350M (146M) wnt4ts-intermittent.img.xz +> +> SHA-256s: +> +> win31: 8179b8180a2ab40bd472e8a2f3fb89fc331651e56923f94ceb9e52a78ee220d2 +> broken: a2af5f0bc49a063b75f534b6ffe5b82e32ecc706a64a425b6626feccf6e3fdfa +> intermittent: 77ae8c458829ebcdd64c71042012f45d5a2788e6ebd22db9d53de9ef1a574784 +> +> (Wanted to keep the checksum lines within 80 columns) +> +> And, since I can't figure out where else in this report to put this, +> wnt4ts-broken.img's password is "admin" but something seems to have +> happened to the disk and NT doesn't actually boot properly :(, and +> wnt4ts-intermittent.img's password is "1234". (These were set up as test +> images. Now I'm _really_ glad I used simple passwords! :) ) +> +> --- +> +> +> I have two testcases: DOS 6.22 (+ Windows 3.1), and Windows NT 4. +> +> +> # MS-DOS +> +> DOS is the simplest. It basically consists of +> +> $ qemu-system-i386 -drive file=win31.img,format=raw -M isapc -enable-kvm +> +> And then literally just playing around. Things to try include creating +> files (`echo blah > file`), repeatedly seeking across the entire FAT +> (`dir /s > nul` or `dir /s`), and launching Windows (`win`). +> +> win31.img is not special (as far as I can tell) and merely consists of +> the result of installing DOS 6.22 and Windows 3.1 from WinWorldPC. I've +> basically just included the image for convenience. +> +> Generally no single "run" is immune to starting Win3.1 and then +> launching File Manager; if that doesn't generate an error, something is +> definitely up. +> +> The second best trigger is creating new files. That very very frequently +> produces "General Failure ...", but not always. +> +> +> # WinNT 4 +> +> Windows NT 4 is a bit more complicated. Because this error only occurs +> at presumably a single small point very early in boot, the window of +> opportunity for the glitch to surface within is much much narrower and +> thus often requires a larger number of tries. +> +> Anecdotally I've had QEMU hit the boot error at the first try/run, and +> after as many as 63 "successful" boots. +> +> I made a small test harness that automates the launch process. It +> consists of two shell scripts and requires tmux (and netcat). +> (*Potential epilepsy warning*: if you use a light-colored terminal +> background, the terminal QEMU is repeatedly invoked from will +> continuously flash rapidly from white to black.) +> +> One of the scripts is run inside a tmux session in one terminal, while +> the other script is run in its own terminal (without any tmux). +> +> +> I named this one `run-qemu-loop`: +> +> --8<-------------------------------------------------------- +> +> #!/bin/bash +> +> # --- +> +> qemu=/path/to/qemu-system-i386 +> #or, alternatively: (I used the following line myself so I +> #could tab-complete my way to different qemu executables) +> #qemu="$1" +> +> disk=/path/to/wnt4ts-intermittent.img +> +> # --- +> +> port=4444 +> +> rm -f STOP itercount +> +> itercount=0 +> +> while :; do +> +> [ -f STOP ] && break +> +> ((itercount++)) +> echo $itercount > itercount +> +> $qemu \ +> -enable-kvm -vga cirrus -curses -M isapc \ +> -drive file="$disk",format=raw \ +> -chardev socket,id=mon0,host=localhost,port=$port,server,nowait \ +> -mon chardev=mon0,mode=readline +> +> #point to an otherwise-unused terminal if you like (see also: `tty`) +> #echo "$itercount run(s)" > /dev/pts/__ +> +> done +> +> ------------------------------------------------------------ +> +> Not much logic above; this just repeatedly runs QEMU for as long as +> the file `STOP` does not exist in the current directory. +> +> The key "magic" bit is that QEMU is launched in -curses mode. +> +> The other key bit is that the above script is run inside tmux. +> +> +> Here's `tmux-ctl-loop`: +> +> --8<-------------------------------------------------------- +> +> #!/bin/bash +> +> port=4444 +> +> tmux=./tmux +> +> printf -v l '%0.0s-' {0..25} +> h1="$l/ buffer dump begin \\$l" +> h2="$l-\\ buffer dump end /-$l" +> +> while :; do +> +> while :; do +> echo | nc localhost $port -q0 -w1 > /dev/null && break +> echo 'Start qemu!' +> done +> +> buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)" +> +> echo "$h1" +> [[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )' +> echo "$h2" +> +> if echo "$buffer" | grep -q 'A disk read error occurred.'; then +> +> s="<Crashed after $(< itercount) runs.>" +> echo "$s" +> echo "$s" >> stats +> +> touch STOP +> +> #echo q | nc localhost $port -q0 > /dev/null +> +> exit +> +> elif echo "$buffer" | grep -q 'OS Loader V4.00'; then +> +> echo '<Booted successfully, trying again>' +> +> echo q | nc localhost $port -q0 > /dev/null +> +> else +> +> echo '<Waiting for boot>' +> +> fi +> +> done +> +> ------------------------------------------------------------ +> +> Nothing particularly amazing going on here either. +> +> While `qemu-run-loop` is running inside tmux in the first terminal, this +> is running in the 2nd one. +> +> The small infinite loop at the top only breaks when it can successfully +> ping QEMU and it knows it's running. +> +> Then, a screendump of the contents of the terminal QEMU is in is fetched +> from tmux, and the buffer's content is analyzed. +> +> - If NTLDR fails, the script creates `STOP` to halt qemu-run-loop, +> sends `q` to QEMU through netcat, and then the script exits. +> +> - If NTLDR loads successfully, the script sends `q` to QEMU and continues +> looping. (qemu-run-loop will not find the `STOP` file, and so restart qemu.) +> +> The scripts run very quickly, with 2-3 iterations per second on my i3 +> box. +> +> +> # Usage +> +> Save the two scripts above to the same directory as wnt4ts-intermittent.img, +> then: +> +> - (If port 4444 doesn't work, the value needs to be changed in both +> scripts.) +> +> - In the first terminal, run `tmux -S <file>`, where <file> names the socket +> tmux will use. This needs to match "tmux=" at the top of `tmux-ctl-loop`. +> (with `tmux=./tmux`, the command would be `tmux -S tmux`) +> +> - Still in the first terminal (and now also inside tmux), enter +> `./qemu-run-loop`, passing the path to qemu if you're using that approach +> (refer to the first few lines of the script). Don't hit enter yet. +> +> - Now, in the 2nd terminal, type `./tmux-ctl-loop` +> +> - Hit enter in both terminals. +> +> +> Rationale for timing of Enter key: +> +> - Running qemu-run-loop first will start QEMU, and if NTLDR starts +> successfully it will immediately begin counting down from 30. If NT actually +> starts to boot and is then hard-shut-down this /may/ affect the disk image +> +> - tmux-ctl-loop will annoyingly spam a continuous stream of 'Start qemu!' until +> qemu-run-loop is running. +> +> - Starting both scripts at "more or less" the same time (no rush) works out +> well. +> +> +> Hopefully potential script modifications are obvious; for example +> +> - changing tmux-ctl-loop to not send 'q' to qemu so you can connect to the HMP +> yourself +> (NB, if `STOP` is not created, when qemu finally exits it will of course +> promptly be relaunched) +> +> - pointing run-qemu-loop to a modified qemu binary +> +> +> == #2: QEMU-vs-VirtualBox image issue ====================== +> +> I was initially completely stumped by this issue, perhaps unsurprisingly +> so. :) +> +> wnt4ts-broken.img is a perfectly ordinary NT 4 installation that was +> created in QEMU 2.9.0. I created a 1GB disk with `truncate`, picked NTFS +> and installed everything (which took a while). +> +> NT setup reboots a number of times during the boot process, and IIRC +> those all went just fine. However, at some point, the image began to +> consistently bomb out with "A disk read error occurred. ...", and +> stubbornly refused to boot, regardless of the number of boot attempts I +> tried. +> +> QEMU 2.0.0, 1.5.0, and 1.0 (the earliest version I was able to build on +> my system) all consistently hit "disk read error occurred". +> +> I tried compiling QEMU 1.0 using clang so I could build for 32-bit on my +> 64-bit system (GCC 7 died with "Frame pointer required, but reserved"). +> The resulting qemu completely crashed if I didn't enable KVM (ie, TCG +> was (understandably) broken); with KVM enabled qemu didn't crash, but +> NTLDR halted with the same error as on 64-bit qemu. (TL;DR, no +> difference whatsoever.) +> +> My initial reaction at this point was to try the image on another +> virtualization platform. My first pick was VirtualBox. +> +> So, I followed the official instructions for pointing VirtualBox to +> physical disk images, except I substituted a /dev/loopN device I'd +> pointed to the image file via losetup. +> +> And... VirtualBox picked the image up fine and Just Worked(TM). Yay! - +> but not yay. What gives?! +> +> Confused, I then tried to convert the disk image to VHD format. +> Unfortunately, for some reason, if I try `qemu-image convert ... -O vhdx +> ...`, VirtualBox chokes on the result: +> +> ----- +> +> VD: error VERR_NOT_SUPPORTED opening image file +> '/.../wnt4ts-broken-qemuconv.vhd' (VERR_NOT_SUPPORTED). +> +> Result Code: NS_ERROR_FAILURE (0x80004005) +> Component: MediumWrap +> Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda} +> Callee: IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945} +> Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001) +> +> ----- +> +> Welp. +> +> Well, a bit more digging later, and I found I could do +> +> $ VBoxManage convertfromraw wnt4ts-broken.img wnt4ts-broken.vhd +> +> but... as soon as I pointed VirtualBox to this, it too began to choke +> with "A disk read error occurred". +> +> And yet, the VMDK->raw image setup worked just fine. +> +> I found I could even replace the loop device with the path of the .img +> file itself and that worked just fine too. +> +> At my wits' end, I followed some online instructions to learn about +> manual CHS configuration so I could try and get the image working in +> Bochs. "A disk read error occurred". I wasn't surprised. +> +> It was at this point I began to give up, but I decided to try One Last +> Thing(TM) before properly throwing in the towel. +> +> :) +> +> I decided to learn a bit more about how `VBoxManage internalcommands +> createrawvmdk` worked, and try one thing in particular: I can edit the +> .vmdk file, but can I point `createrawvmdk` at the .img file directly +> too? +> +> Turns out, yes you can. +> +> It also turns out that this promptly caused VirtualBox to bomb out. +> +> Interesting. +> +> For reference, here's the VMDK file I initially created (by pointing +> `createrawvmdk` at /dev/loopN) and then later edited to point straight +> to the .img file, with both approaches resulting in successful boot. +> +> --8<-------------------------------------------------------- +> +> # Disk DescriptorFile +> version=1 +> CID=e35b9a45 +> parentCID=ffffffff +> createType="fullDevice" +> +> # Extent description +> RW 1536000 FLAT "/absolute/full/path/to/wnt4ts-broken.img" 0 +> +> # The disk Data Base +> #DDB +> +> ddb.virtualHWVersion = "4" +> ddb.adapterType="ide" +> ddb.geometry.cylinders="1523" +> ddb.geometry.heads="16" +> ddb.geometry.sectors="63" +> ddb.uuid.image="871a6044-c8ca-48ed-b7aa-e6fc49da3db4" +> ddb.uuid.parent="00000000-0000-0000-0000-000000000000" +> ddb.uuid.modification="3661715c-3906-4e4a-ab65-486d140e03b8" +> ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000" +> ddb.geometry.biosCylinders="761" +> ddb.geometry.biosHeads="32" +> ddb.geometry.biosSectors="63" +> +> ------------------------------------------------------------ +> +> +> Here's the _diff_ of what happens if I point `createrawvmdk` at wnt4ts-broken.img directly: +> +> --8<-------------------------------------------------------- +> +> ddb.geometry.cylinders="2080" +> ddb.geometry.heads="16" +> ddb.geometry.sectors="63" +> +> ------------------------------------------------------------ +> +> :D +> +> Naturally, +> +> $ qemu-system-i386 -drive file=wnt4ts- +> broken.img,format=raw,cyls=1523,heads=16,secs=63 -M isapc -sdl +> +> will boot happily on 2.9.0 (notwithstanding the occasional "disk read +> error occurred" documented above). +> +> It will also boot in 1.6.0. +> +> (POTENTIAL BUG HEADSUP: 1.0 and 1.5.0 both lock up with a blank 640x480 +> window and use 0% CPU if I specify `-M isapc`.) +> +> And, of course, using these CHS values in Bochs also results in +> successful boot as well (after setting the CPU type to pentium). +> +> Unfortunately, I have no idea what sequence of events caused the +> creation of the VMDK file above. No invocation of `createrawvmdk` is +> producing a VMDK file with the CHS settings above. +> +> I've only just begun to learn about the intricacies of CHS. Am I to +> understand that these values are stored amongst the first 512 bytes of +> the disk? If this is the case, then I wonder what changed the data, and +> why. I was initially only using QEMU 2.9.0, and didn't move the image to +> different VMs or QEMU versions. Perhaps Windows NT got confused about +> the disk CHS and rewrote it? +> +> +> == Sporadic BIOS-level boot failure ======================== +> +> I have multiple screenshots of SeaBIOS in QEMU 2.9.0 halting with "No +> bootable device" (et al), even with the above manually-applied CHS +> settings. +> +> Commit e689f7c also presents such errors. +> +> Commit 306ec6c does not suffer from intermittent breakage of any kind: +> +> - No SeaBIOS flake-outs +> - No "Non-system disk or disk error" +> - No "A disk error has occurred" +> - No "General failure ..." +> +> While most of my confidence in commit 306ec6c is based on anecdotal +> evidence, I modified `tmux-ctl-loop` a little to soak-test BIOS-level +> I/O stability and left this modified version running for a few minutes. +> +> --8<-------------------------------------------------------- +> +> #!/bin/bash +> +> port=4444 +> +> tmux=./tmux +> +> printf -v l '%0.0s-' {0..25} +> h1="$l/ buffer dump begin \\$l" +> h2="$l-\\ buffer dump end /-$l" +> +> while :; do +> +> while :; do +> echo | nc localhost $port -q0 -w1 > /dev/null && break +> echo 'Start qemu!' +> done +> +> buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)" +> +> echo "$h1" +> [[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )' +> echo "$h2" +> +> if echo "$buffer" | grep -q 'Non-system disk' || echo "$buffer" | \ +> grep -q 'No bootable device' +> then +> +> s="<Hit error after $(< itercount) runs.>" +> echo "$s" +> echo "$s" >> stats +> +> touch STOP +> +> #echo q | nc localhost $port -q0 > /dev/null +> +> exit +> +> elif echo "$buffer" | grep -q 'OS Loader V4.00' || echo "$buffer" | \ +> grep -q 'A disk read error' +> then +> +> echo '<Boot did not hang at BIOS, trying again>' +> +> echo q | nc localhost $port -q0 > /dev/null +> +> else +> +> echo '<Waiting for boot>' +> +> fi +> +> done +> +> ------------------------------------------------------------ +> +> For the above to work, the top of run-qemu-loop must also be modified to +> read something along the lines of +> +> disk=/path/to/wnt4ts-broken.img,format=raw,cyls=1523,heads=16,secs=63 +> +> (Suggestion: modify copies of both scripts) +> +> One small terminal-flicker-headache (and a 57°C CPU) later, I was able +> to carefully observe just over 350 successful runs in which QEMU commit +> 306ec6c only ever produced a boot menu. No other hitches. +> +> ** Important: ** +> +> However, commit 306ec6c will fail to boot, ever, if the cylinders and +> geometry are not set to the values VirtualBox "discovered". (Of note is +> the fact that QEMU (2.9.0) was what initially created this image. I must +> admit that I don't remember what sequence of QEMU versions I fed the +> image to - and I maybe, possibly, didn't think to back the file up +> (sorry), so maybe something mangled something somewhere. But VirtualBox +> figured it out nonetheless!) +> +> Furthermore, feeding /dev/loopN to any QEMU version will NOT result in +> correct CHS discovery (and successful boot). +> +> This is what leads me to conclude that I've discovered two separate +> issues. +> +> +> == Appendix: How to build the branches ===================== +> +> It's very simple. +> +> First, `git clone https://github.com/qemu/qemu` somewhere if you don't +> already have a local copy. If you have an old git checkout that's from +> 2014 or later, you can use that old checkout instead. (If you want to +> test an old checkout you have, the commands below will either work +> perfectly or completely bomb out with no side effects.) +> +> A full checkout is a ~183MB download. Sorry. +> +> Next, create two new directories somewhere. Name them what you like, eg +> `qemu-working` and `qemu-broken`. +> +> Now, cd into the checkout directory, and run: +> +> $ git archive 306ec6c3cece7004429c79c1ac93d49919f1f1cc | tar xC /path/to +> /qemu-working/ +> +> $ git archive e689f7c668cbd9d08f330e17c3dd3a059c9553d3 | tar xC /path/to +> /qemu-broken/ +> +> The paths can be relative. +> +> Now, run this in both of the new directories: +> +> $ ./configure --python=python2.7 --disable-libssh2 --disable-seccomp +> --disable-usb-redir --disable-guest-agent --disable-libiscsi --disable- +> spice --disable-smartcard-nss --disable-vhost-net --disable-docs +> --disable-attr --disable-cap-ng --disable-vde --disable-user --disable- +> bluez --disable-vnc-ws --disable-xen --disable-brlapi --enable-debug +> --target-list=i386-softmmu --disable-fdt +> +> $ make -j64 +> +> You can open two terminals and configure and build both simultaneously +> if you like. +> +> On my decent but very basic (2-core+HT) i3 box, -j64 actually works out - make doesn't actually launch too many gcc processes. You *will* see your system load spike to ~20 though :) +> (NB. Do. not. use. -j64. with. the. linux. kernel.) +> +> On my system, a single build with -j64 takes only about 35 seconds. C +> FTW. (Although this has increased to 1min20sec for more recent builds.) +> +> Most of the configure arguments remove functionality I'll never use (in +> this situation) and which will only slow down the build. +> +> Once QEMU is built, run qemu-system-i386 directly from where it has been +> built. +> +> $ /path/to/qemu-working/i386-softmmu/qemu-system-i386 ... +> $ /path/to/qemu-broken/i386-softmmu/qemu-system-i386 ... +> +> Again, the paths can be relative. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: disk io qemu +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1745312 +> +> Title: +> Regression report: Disk subsystem I/O failures/issues surfacing in +> DOS/early Windows [two separate issues: one bisected, one root-caused] +> +> Status in QEMU: +> New +> +> Bug description: +> [Headsup: This report is long-ish due to the amount of detail I've +> stumbled on along the way that I think is relevant to include. I can't +> speak as to the complexity of the actual bugs, but the size of this +> report should not suggest that the reproduction process is +> particularly headache-inducing.] +> +> Hi! +> +> I recently needed to fire up some ancient software for research +> purposes and got very distracted discovering and playing with old +> versions of Windows :). In the process I've discovered some glitches +> with disk I/O. +> +> I believe I've stumbled on two completely separate issues that +> coincidentally surfaced at the same time. It's possible that +> components of this report will be re-filed as more specific new bugs, +> but I'm not an authority on QEMU internals or how to narrow +> down/categorize what I've found. +> +> - The first bug only surfaces when the "isapc" machine type is used. +> It intermittently produces "General failure {read,writ}ing drive _" +> under MS-DOS 6.22, and also somehow interferes with early bootstrap of +> Windows NT 4 (in NTLDR). Enabling or disabling KVM (I'm on Linux) +> appears to make no difference whatsoever, which may help with +> debugging. +> +> - The second issue involves +> - a WinNT4 disk image +> - created by running through a bog-standard NT4 install inside QEMU 2.9.0 +> - which will now fail to boot in any version of QEMU - even version 1.0 +> - but which VirtualBox will boot fine +> - but only if I point VirtualBox at QEMU's raw disk image via a +> hacked-together VMDK file +> - if the raw image is converted to VHD(X), VirtualBox will also fail +> to boot the image with exactly the same error as QEMU +> - this state of affairs is not affected by image sparseness (which makes +> sense) +> +> I'm confident I've bisected the first issue. +> +> I wasn't able to bisect the second issue (as all tested versions of +> QEMU behaved identically), but I've figured out a working repro +> testcase and I believe I've managed to pin down a solid root cause. +> +> +> == #1: Intermittent I/O issues when `-M isapc` is used ===== +> +> These symptoms sometimes take a small amount of time and fiddling to +> trigger, but I AM able to consistently surface them on my machine +> after a short while. (I am very very interested to hear if others +> cannot reproduce them.) +> +> So, first of all: +> +> https://github.com/qemu/qemu/commit/306ec6c3cece7004429c79c1ac93d49919f1f1cc +> (Jul 30 2013): the last version that works +> +> https://github.com/qemu/qemu/commit/e689f7c668cbd9d08f330e17c3dd3a059c9553d3 +> (Oct 30 2013): the first version that intermittently fails +> +> Maybe lift out and build these branches while reading. *shrug* +> (How to do this can be found at the end of this report - along with a time-saving ./configure line, FWIW) +> +> Here are the changelists between these two revisions: +> +> https://github.com/qemu/qemu/compare/306ec6c...e689f7c +> (Compare direction: OLD to NEW) (Commits: 166 Files changed: 192) +> +> https://github.com/qemu/qemu/compare/e689f7c...306ec6c +> (Compare direction: NEW to OLD) (Commits: 30 Files changed: 22) +> +> (Someone else more familiar with Git might know why GitHub returns +> results for both compare directions, and/or if the 2nd link is useful +> information. The first link returns a lot more results than the 2nd +> one, at least. Does comparing new>old return deletions?) +> +> --- +> +> Now on to the symptoms. In a moment I'll describe reproduction. +> +> # MS-DOS 6.22 +> +> The first symptom I discovered was that trivial read and write +> operations under MS-DOS would sometimes fail: +> +> C:\>echo test > hi +> +> General failure writing drive C +> Abort, Retry, Fail? +> +> Anything else that exercises the disk behaves similarly: +> +> C:\>dir /s > nul +> +> General failure reading drive C +> Abort, Retry, Fail? +> +> (Note that the above demonstrates both write and read failures) +> +> (Also, FWIW, `dir /s` == `ls -R`) +> +> The behavior of the I/O errors is not possible to characterise as it +> fluctuates so much. For example something as simple as DIR can produce +> wildly differing results: in one run, poking around with DIR ended +> with DOS deciding C:\ was empty at one point; at another point in a +> different run C:\ mysteriously dropped 50% of its contents only to +> magically gain it all back moments later after some poking around in +> one of the subdirectories that was still visible. +> +> The time it takes to trigger these errors is also highly variable. +> QEMU may fall over as early as hanging forever at "Starting MS- +> DOS...", or I might get all the way into Windows 3.1 before it +> triggers (in which case Win3.1 reports vague memory errors - of all +> things). +> +> Very occasionally I've seen _SeaBIOS itself_ report "Booting from Hard +> Disk..." "Boot failed: could not read the boot disk" ... "No bootable +> device.", and on one occasion I even got "Non-System disk or disk +> error" "Replace and strike any key when ready"! +> +> +> # WinNT 4 Terminal Server +> +> Most of the time, NTLDR will fire up normally. But every so often... +> +> SeaBIOS (version rel-1.7.3-117-g31b8b4e- +> 20131206_080705-nilsson.home.kraxel.org) +> +> Booting from Hard Disk... +> A disk read error occurred. +> Insert a system diskette and restart +> the system. +> +> (NB. You're seeing the old SeaBIOS version included with e689f7c, +> which was the first buggy commit.) +> +> If NT gets past this point without erroring out (ie, it makes it to +> the boot menu), the rest of the system is 100% fine and there are no +> other disk I/O issues whatsoever. For example, on QEMU 2.9.0 I was +> able to enable disk compression, answer "Yes" to "Compress entire disk +> now?" and have the process fully complete. No hitches. +> +> This makes me vaguely recall/wonder that perhaps this could be somehow +> related to LBA and/or Int 13h, or something floating around near that +> bunch of functionality. (I'm woefully ignorant about such low-level +> details.) Perhaps DOS/Win3.1 are stuck using a disk mode that QEMU has +> a buggy implementation of, while NT 4 (once NTOSKRNL is up and +> running) is able to use a different disk mode or access mechanism. +> +> I'm really interested to get some understanding of what the root issue +> is here, when this is fixed. (I wonder if it's a timing thing?) +> +> I've observed some unusual behavior with repeated restarts. In one +> case, I attempted to start NT4 multiple times, and QEMU consistently +> failed with "No bootable device" each time. So, I removed `-M isapc`, +> promptly got a boot menu, hit ^C, readded `-M isapc` - and continued +> to get a boot menu. Yep. I'll accept "really really big coincidence" +> but I do very much wonder if something else is going on here. I've +> observed many similar incidents. It makes me wonder whether the +> contents of memory or some other system state is an influence. Very +> probably not, but still... +> +> +> -- Reproduction -------------------------------------------- +> +> First of all, there was unfortunately no way for me to avoid having to +> post entire disk images, but I've managed to compress everything down +> to 174MB total download size. +> +> FWIW, WinWorld and many other sites seem to have no operational issues +> providing clear pointers to CD keys; I consider my distribution of my +> installed HDD images an extension of the apparent status quo. +> +> That being said, I've put everything on Google Drive so nobody has to +> headscratch about Launchpad/Canonical/etc's stance on hosting this +> data. +> +> So, this folder contains the disk images: +> https://drive.google.com/drive/folders/1WdZVBh5Trs9HLC186-nHyKeqaSxfyM2c +> ("Download all" at the top-right will create a ZIP file, but FWIW +> downloading the individual files simultaneously would implement a +> rough form of download acceleration) +> +> File meta info: +> +> Compressed +> | +> | Apparent +> | | Actual +> | | | +> 38M -> 200M (103M) win31.img.xz +> 82M -> 1G (289M) wnt4ts-broken.img.xz +> 55M -> 350M (146M) wnt4ts-intermittent.img.xz +> +> SHA-256s: +> +> win31: 8179b8180a2ab40bd472e8a2f3fb89fc331651e56923f94ceb9e52a78ee220d2 +> broken: a2af5f0bc49a063b75f534b6ffe5b82e32ecc706a64a425b6626feccf6e3fdfa +> intermittent: 77ae8c458829ebcdd64c71042012f45d5a2788e6ebd22db9d53de9ef1a574784 +> +> (Wanted to keep the checksum lines within 80 columns) +> +> And, since I can't figure out where else in this report to put this, +> wnt4ts-broken.img's password is "admin" but something seems to have +> happened to the disk and NT doesn't actually boot properly :(, and +> wnt4ts-intermittent.img's password is "1234". (These were set up as +> test images. Now I'm _really_ glad I used simple passwords! :) ) +> +> --- +> +> +> I have two testcases: DOS 6.22 (+ Windows 3.1), and Windows NT 4. +> +> +> # MS-DOS +> +> DOS is the simplest. It basically consists of +> +> $ qemu-system-i386 -drive file=win31.img,format=raw -M isapc -enable- +> kvm +> +> And then literally just playing around. Things to try include creating +> files (`echo blah > file`), repeatedly seeking across the entire FAT +> (`dir /s > nul` or `dir /s`), and launching Windows (`win`). +> +> win31.img is not special (as far as I can tell) and merely consists of +> the result of installing DOS 6.22 and Windows 3.1 from WinWorldPC. +> I've basically just included the image for convenience. +> +> Generally no single "run" is immune to starting Win3.1 and then +> launching File Manager; if that doesn't generate an error, something +> is definitely up. +> +> The second best trigger is creating new files. That very very +> frequently produces "General Failure ...", but not always. +> +> +> # WinNT 4 +> +> Windows NT 4 is a bit more complicated. Because this error only occurs +> at presumably a single small point very early in boot, the window of +> opportunity for the glitch to surface within is much much narrower and +> thus often requires a larger number of tries. +> +> Anecdotally I've had QEMU hit the boot error at the first try/run, and +> after as many as 63 "successful" boots. +> +> I made a small test harness that automates the launch process. It +> consists of two shell scripts and requires tmux (and netcat). +> (*Potential epilepsy warning*: if you use a light-colored terminal +> background, the terminal QEMU is repeatedly invoked from will +> continuously flash rapidly from white to black.) +> +> One of the scripts is run inside a tmux session in one terminal, while +> the other script is run in its own terminal (without any tmux). +> +> +> I named this one `run-qemu-loop`: +> +> --8<-------------------------------------------------------- +> +> #!/bin/bash +> +> # --- +> +> qemu=/path/to/qemu-system-i386 +> #or, alternatively: (I used the following line myself so I +> #could tab-complete my way to different qemu executables) +> #qemu="$1" +> +> disk=/path/to/wnt4ts-intermittent.img +> +> # --- +> +> port=4444 +> +> rm -f STOP itercount +> +> itercount=0 +> +> while :; do +> +> [ -f STOP ] && break +> +> ((itercount++)) +> echo $itercount > itercount +> +> $qemu \ +> -enable-kvm -vga cirrus -curses -M isapc \ +> -drive file="$disk",format=raw \ +> -chardev socket,id=mon0,host=localhost,port=$port,server,nowait \ +> -mon chardev=mon0,mode=readline +> +> #point to an otherwise-unused terminal if you like (see also: `tty`) +> #echo "$itercount run(s)" > /dev/pts/__ +> +> done +> +> ------------------------------------------------------------ +> +> Not much logic above; this just repeatedly runs QEMU for as long as +> the file `STOP` does not exist in the current directory. +> +> The key "magic" bit is that QEMU is launched in -curses mode. +> +> The other key bit is that the above script is run inside tmux. +> +> +> Here's `tmux-ctl-loop`: +> +> --8<-------------------------------------------------------- +> +> #!/bin/bash +> +> port=4444 +> +> tmux=./tmux +> +> printf -v l '%0.0s-' {0..25} +> h1="$l/ buffer dump begin \\$l" +> h2="$l-\\ buffer dump end /-$l" +> +> while :; do +> +> while :; do +> echo | nc localhost $port -q0 -w1 > /dev/null && break +> echo 'Start qemu!' +> done +> +> buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)" +> +> echo "$h1" +> [[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )' +> echo "$h2" +> +> if echo "$buffer" | grep -q 'A disk read error occurred.'; then +> +> s="<Crashed after $(< itercount) runs.>" +> echo "$s" +> echo "$s" >> stats +> +> touch STOP +> +> #echo q | nc localhost $port -q0 > /dev/null +> +> exit +> +> elif echo "$buffer" | grep -q 'OS Loader V4.00'; then +> +> echo '<Booted successfully, trying again>' +> +> echo q | nc localhost $port -q0 > /dev/null +> +> else +> +> echo '<Waiting for boot>' +> +> fi +> +> done +> +> ------------------------------------------------------------ +> +> Nothing particularly amazing going on here either. +> +> While `qemu-run-loop` is running inside tmux in the first terminal, +> this is running in the 2nd one. +> +> The small infinite loop at the top only breaks when it can +> successfully ping QEMU and it knows it's running. +> +> Then, a screendump of the contents of the terminal QEMU is in is +> fetched from tmux, and the buffer's content is analyzed. +> +> - If NTLDR fails, the script creates `STOP` to halt qemu-run-loop, +> sends `q` to QEMU through netcat, and then the script exits. +> +> - If NTLDR loads successfully, the script sends `q` to QEMU and continues +> looping. (qemu-run-loop will not find the `STOP` file, and so restart qemu.) +> +> The scripts run very quickly, with 2-3 iterations per second on my i3 +> box. +> +> +> # Usage +> +> Save the two scripts above to the same directory as wnt4ts-intermittent.img, +> then: +> +> - (If port 4444 doesn't work, the value needs to be changed in both +> scripts.) +> +> - In the first terminal, run `tmux -S <file>`, where <file> names the socket +> tmux will use. This needs to match "tmux=" at the top of `tmux-ctl-loop`. +> (with `tmux=./tmux`, the command would be `tmux -S tmux`) +> +> - Still in the first terminal (and now also inside tmux), enter +> `./qemu-run-loop`, passing the path to qemu if you're using that approach +> (refer to the first few lines of the script). Don't hit enter yet. +> +> - Now, in the 2nd terminal, type `./tmux-ctl-loop` +> +> - Hit enter in both terminals. +> +> +> Rationale for timing of Enter key: +> +> - Running qemu-run-loop first will start QEMU, and if NTLDR starts +> successfully it will immediately begin counting down from 30. If NT actually +> starts to boot and is then hard-shut-down this /may/ affect the disk image +> +> - tmux-ctl-loop will annoyingly spam a continuous stream of 'Start qemu!' until +> qemu-run-loop is running. +> +> - Starting both scripts at "more or less" the same time (no rush) works out +> well. +> +> +> Hopefully potential script modifications are obvious; for example +> +> - changing tmux-ctl-loop to not send 'q' to qemu so you can connect to the HMP +> yourself +> (NB, if `STOP` is not created, when qemu finally exits it will of course +> promptly be relaunched) +> +> - pointing run-qemu-loop to a modified qemu binary +> +> +> == #2: QEMU-vs-VirtualBox image issue ====================== +> +> I was initially completely stumped by this issue, perhaps +> unsurprisingly so. :) +> +> wnt4ts-broken.img is a perfectly ordinary NT 4 installation that was +> created in QEMU 2.9.0. I created a 1GB disk with `truncate`, picked +> NTFS and installed everything (which took a while). +> +> NT setup reboots a number of times during the boot process, and IIRC +> those all went just fine. However, at some point, the image began to +> consistently bomb out with "A disk read error occurred. ...", and +> stubbornly refused to boot, regardless of the number of boot attempts +> I tried. +> +> QEMU 2.0.0, 1.5.0, and 1.0 (the earliest version I was able to build +> on my system) all consistently hit "disk read error occurred". +> +> I tried compiling QEMU 1.0 using clang so I could build for 32-bit on +> my 64-bit system (GCC 7 died with "Frame pointer required, but +> reserved"). The resulting qemu completely crashed if I didn't enable +> KVM (ie, TCG was (understandably) broken); with KVM enabled qemu +> didn't crash, but NTLDR halted with the same error as on 64-bit qemu. +> (TL;DR, no difference whatsoever.) +> +> My initial reaction at this point was to try the image on another +> virtualization platform. My first pick was VirtualBox. +> +> So, I followed the official instructions for pointing VirtualBox to +> physical disk images, except I substituted a /dev/loopN device I'd +> pointed to the image file via losetup. +> +> And... VirtualBox picked the image up fine and Just Worked(TM). Yay! - +> but not yay. What gives?! +> +> Confused, I then tried to convert the disk image to VHD format. +> Unfortunately, for some reason, if I try `qemu-image convert ... -O +> vhdx ...`, VirtualBox chokes on the result: +> +> ----- +> +> VD: error VERR_NOT_SUPPORTED opening image file +> '/.../wnt4ts-broken-qemuconv.vhd' (VERR_NOT_SUPPORTED). +> +> Result Code: NS_ERROR_FAILURE (0x80004005) +> Component: MediumWrap +> Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda} +> Callee: IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945} +> Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001) +> +> ----- +> +> Welp. +> +> Well, a bit more digging later, and I found I could do +> +> $ VBoxManage convertfromraw wnt4ts-broken.img wnt4ts-broken.vhd +> +> but... as soon as I pointed VirtualBox to this, it too began to choke +> with "A disk read error occurred". +> +> And yet, the VMDK->raw image setup worked just fine. +> +> I found I could even replace the loop device with the path of the .img +> file itself and that worked just fine too. +> +> At my wits' end, I followed some online instructions to learn about +> manual CHS configuration so I could try and get the image working in +> Bochs. "A disk read error occurred". I wasn't surprised. +> +> It was at this point I began to give up, but I decided to try One Last +> Thing(TM) before properly throwing in the towel. +> +> :) +> +> I decided to learn a bit more about how `VBoxManage internalcommands +> createrawvmdk` worked, and try one thing in particular: I can edit the +> .vmdk file, but can I point `createrawvmdk` at the .img file directly +> too? +> +> Turns out, yes you can. +> +> It also turns out that this promptly caused VirtualBox to bomb out. +> +> Interesting. +> +> For reference, here's the VMDK file I initially created (by pointing +> `createrawvmdk` at /dev/loopN) and then later edited to point straight +> to the .img file, with both approaches resulting in successful boot. +> +> --8<-------------------------------------------------------- +> +> # Disk DescriptorFile +> version=1 +> CID=e35b9a45 +> parentCID=ffffffff +> createType="fullDevice" +> +> # Extent description +> RW 1536000 FLAT "/absolute/full/path/to/wnt4ts-broken.img" 0 +> +> # The disk Data Base +> #DDB +> +> ddb.virtualHWVersion = "4" +> ddb.adapterType="ide" +> ddb.geometry.cylinders="1523" +> ddb.geometry.heads="16" +> ddb.geometry.sectors="63" +> ddb.uuid.image="871a6044-c8ca-48ed-b7aa-e6fc49da3db4" +> ddb.uuid.parent="00000000-0000-0000-0000-000000000000" +> ddb.uuid.modification="3661715c-3906-4e4a-ab65-486d140e03b8" +> ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000" +> ddb.geometry.biosCylinders="761" +> ddb.geometry.biosHeads="32" +> ddb.geometry.biosSectors="63" +> +> ------------------------------------------------------------ +> +> +> Here's the _diff_ of what happens if I point `createrawvmdk` at wnt4ts-broken.img directly: +> +> --8<-------------------------------------------------------- +> +> ddb.geometry.cylinders="2080" +> ddb.geometry.heads="16" +> ddb.geometry.sectors="63" +> +> ------------------------------------------------------------ +> +> :D +> +> Naturally, +> +> $ qemu-system-i386 -drive file=wnt4ts- +> broken.img,format=raw,cyls=1523,heads=16,secs=63 -M isapc -sdl +> +> will boot happily on 2.9.0 (notwithstanding the occasional "disk read +> error occurred" documented above). +> +> It will also boot in 1.6.0. +> +> (POTENTIAL BUG HEADSUP: 1.0 and 1.5.0 both lock up with a blank +> 640x480 window and use 0% CPU if I specify `-M isapc`.) +> +> And, of course, using these CHS values in Bochs also results in +> successful boot as well (after setting the CPU type to pentium). +> +> Unfortunately, I have no idea what sequence of events caused the +> creation of the VMDK file above. No invocation of `createrawvmdk` is +> producing a VMDK file with the CHS settings above. +> +> I've only just begun to learn about the intricacies of CHS. Am I to +> understand that these values are stored amongst the first 512 bytes of +> the disk? If this is the case, then I wonder what changed the data, +> and why. I was initially only using QEMU 2.9.0, and didn't move the +> image to different VMs or QEMU versions. Perhaps Windows NT got +> confused about the disk CHS and rewrote it? +> +> +> == Sporadic BIOS-level boot failure ======================== +> +> I have multiple screenshots of SeaBIOS in QEMU 2.9.0 halting with "No +> bootable device" (et al), even with the above manually-applied CHS +> settings. +> +> Commit e689f7c also presents such errors. +> +> Commit 306ec6c does not suffer from intermittent breakage of any kind: +> +> - No SeaBIOS flake-outs +> - No "Non-system disk or disk error" +> - No "A disk error has occurred" +> - No "General failure ..." +> +> While most of my confidence in commit 306ec6c is based on anecdotal +> evidence, I modified `tmux-ctl-loop` a little to soak-test BIOS-level +> I/O stability and left this modified version running for a few +> minutes. +> +> --8<-------------------------------------------------------- +> +> #!/bin/bash +> +> port=4444 +> +> tmux=./tmux +> +> printf -v l '%0.0s-' {0..25} +> h1="$l/ buffer dump begin \\$l" +> h2="$l-\\ buffer dump end /-$l" +> +> while :; do +> +> while :; do +> echo | nc localhost $port -q0 -w1 > /dev/null && break +> echo 'Start qemu!' +> done +> +> buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)" +> +> echo "$h1" +> [[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )' +> echo "$h2" +> +> if echo "$buffer" | grep -q 'Non-system disk' || echo "$buffer" | \ +> grep -q 'No bootable device' +> then +> +> s="<Hit error after $(< itercount) runs.>" +> echo "$s" +> echo "$s" >> stats +> +> touch STOP +> +> #echo q | nc localhost $port -q0 > /dev/null +> +> exit +> +> elif echo "$buffer" | grep -q 'OS Loader V4.00' || echo "$buffer" | \ +> grep -q 'A disk read error' +> then +> +> echo '<Boot did not hang at BIOS, trying again>' +> +> echo q | nc localhost $port -q0 > /dev/null +> +> else +> +> echo '<Waiting for boot>' +> +> fi +> +> done +> +> ------------------------------------------------------------ +> +> For the above to work, the top of run-qemu-loop must also be modified +> to read something along the lines of +> +> disk=/path/to/wnt4ts-broken.img,format=raw,cyls=1523,heads=16,secs=63 +> +> (Suggestion: modify copies of both scripts) +> +> One small terminal-flicker-headache (and a 57°C CPU) later, I was able +> to carefully observe just over 350 successful runs in which QEMU +> commit 306ec6c only ever produced a boot menu. No other hitches. +> +> ** Important: ** +> +> However, commit 306ec6c will fail to boot, ever, if the cylinders and +> geometry are not set to the values VirtualBox "discovered". (Of note +> is the fact that QEMU (2.9.0) was what initially created this image. I +> must admit that I don't remember what sequence of QEMU versions I fed +> the image to - and I maybe, possibly, didn't think to back the file up +> (sorry), so maybe something mangled something somewhere. But +> VirtualBox figured it out nonetheless!) +> +> Furthermore, feeding /dev/loopN to any QEMU version will NOT result in +> correct CHS discovery (and successful boot). +> +> This is what leads me to conclude that I've discovered two separate +> issues. +> +> +> == Appendix: How to build the branches ===================== +> +> It's very simple. +> +> First, `git clone https://github.com/qemu/qemu` somewhere if you don't +> already have a local copy. If you have an old git checkout that's from +> 2014 or later, you can use that old checkout instead. (If you want to +> test an old checkout you have, the commands below will either work +> perfectly or completely bomb out with no side effects.) +> +> A full checkout is a ~183MB download. Sorry. +> +> Next, create two new directories somewhere. Name them what you like, +> eg `qemu-working` and `qemu-broken`. +> +> Now, cd into the checkout directory, and run: +> +> $ git archive 306ec6c3cece7004429c79c1ac93d49919f1f1cc | tar xC +> /path/to/qemu-working/ +> +> $ git archive e689f7c668cbd9d08f330e17c3dd3a059c9553d3 | tar xC +> /path/to/qemu-broken/ +> +> The paths can be relative. +> +> Now, run this in both of the new directories: +> +> $ ./configure --python=python2.7 --disable-libssh2 --disable-seccomp +> --disable-usb-redir --disable-guest-agent --disable-libiscsi +> --disable-spice --disable-smartcard-nss --disable-vhost-net --disable- +> docs --disable-attr --disable-cap-ng --disable-vde --disable-user +> --disable-bluez --disable-vnc-ws --disable-xen --disable-brlapi +> --enable-debug --target-list=i386-softmmu --disable-fdt +> +> $ make -j64 +> +> You can open two terminals and configure and build both simultaneously +> if you like. +> +> On my decent but very basic (2-core+HT) i3 box, -j64 actually works out - make doesn't actually launch too many gcc processes. You *will* see your system load spike to ~20 though :) +> (NB. Do. not. use. -j64. with. the. linux. kernel.) +> +> On my system, a single build with -j64 takes only about 35 seconds. C +> FTW. (Although this has increased to 1min20sec for more recent +> builds.) +> +> Most of the configure arguments remove functionality I'll never use +> (in this situation) and which will only slow down the build. +> +> Once QEMU is built, run qemu-system-i386 directly from where it has +> been built. +> +> $ /path/to/qemu-working/i386-softmmu/qemu-system-i386 ... +> $ /path/to/qemu-broken/i386-softmmu/qemu-system-i386 ... +> +> Again, the paths can be relative. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1745312/+subscriptions +> + + +QEMU ignores the CHS numbers in VMDK images. From the report, it seems VirtualBox uses it. + +So like what you've discovered, for QEMU the right thing to do for such a guest would be setting the correct values explicitly from the command line, rather than let it decide (guess). + +I have no idea about the first issue, though. + +Can you post your commandline for the MSDOS 6.22 issue? NT is known to have a few problems and may be out of scope for what I can help with, but I was under the assumption that MSDOS 6.22 was well-behaved in QEMU. + +Commandline and steps to reproduce the error may be helpful (any particularly kind of command, workflow, etc that helps trigger the IO errors? How big is the hard disk you are using? etc) + +Thanks, +--John + +I have a similar bug: 1674114 + +Can confirm the DOS issue is present. Here are some steps to recreate: +wget http://www.freedos.org/download/download/FD12CD.iso +apt-get install mbr fdisk parted dosfstools qemu-system-x86 +# dd if=/dev/zero of=dos.img bs=512 count=1032192 +# losetup /dev/loop0 dos.img +# fdisk -u=cylinders /dev/loop0 +command: x +expert: h +heads: 16 (you can try different values, 16, 32, 64, 128, 255) +expert: c +cylinders (default 1024): +expert: r +command: c +DOS compatibility flag is set... +command: n +select: p +partition (default 1): +first cylinder (default 1): +last cylinder (default 1024): +command: a +command: t +selected partition 1 +type: 6 +command: w +# partprobe /dev/loop0 +# install-mbr -f /dev/loop0 +# mkdosfs -F 16 /dev/loop0p1 +# qemu-system-i386 -drive file=/dev/loop0,cache=none,format=raw,index=0 \ +-drive file=FD12CD.iso,cache=none,media=cdrom,if=ide,format=raw,index=1 -boot d \ +-machine isapc +-------- +qemu comes up +"install to harddisk" +select your preferred language +"yes - continue with the installation" +drive C does not appear to be formatted +"yes - please erase and format drive c:" +lbacache flush write error 0c80/chs#0001 +... +etc etc etc. + + +I will try to debug as time permits, but the priority of MS-DOS bugs is not ... measurable with casual tools. However, there are a lot of other IDE bugs on my plate that are very important! so I am hoping to grab a bunch of IDE bugs at once, but no promises here. + +Notably, our geometry detection is not very good, it's more than possible we are misreporting values and confusing DOS. Our IDE disks are also not very consistent about what standard of the spec they are trying to emulate, so there are likely other problems there, too. + +If you'd like to debug on your own, I'd recommend enabling tracing and enabling some of the IDE trace points; some of them can be quite verbose -- don't enable the data dumping ones. The control flow ones can be informational sometimes to guess when the guest OS got confused and then walk your way back to a register read that would have picked up some error bits, or to detect busy-waits on registers not changing and try to guess what it was waiting for. + +https://github.com/qemu/qemu/blob/master/docs/devel/tracing.txt +https://github.com/qemu/qemu/blob/master/hw/ide/trace-events + +Ignore the AHCI and ATAPI traces, and don't use the ide_data_* traces unless you are booting a custom firmware that only performs a strict few IO accesses -- otherwise you'll get flooded off the map. + +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. + + +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/56 + + +Hi, + +Thanks to everyone who contributed information to this report. As far as issue #1 from David, I cannot reproduce the intermittent MS-DOS or Windows NT 4 I/O failures with the latest git revision (a74c66b1). I am similarly unable to reproduce Mdasoh's issue. + +For the NT 4 testing script, I had to substitute '-display curses' for '-curses' to accommodate the changes in QEMU, and match against 'Please select' from the boot loader menu rather than 'OS Loader V4.00', which disappears too quickly. + +For issue #2, the root seems to be that both SeaBIOS and QEMU default to LARGE/ECHS disk translation for small disks (<4 GiB). If you apply the patch at + +https://<email address hidden>/ + +you should be able to get to the NT 4 boot loader using + +qemu-system-i386 -blockdev node-name=hda,driver=file,filename=./wnt4ts-broken.img -device ide-hd,drive=hda,bus=ide.0,unit=0,bios-chs-trans=lba + diff --git a/results/classifier/zero-shot/108/permissions/1753309 b/results/classifier/zero-shot/108/permissions/1753309 new file mode 100644 index 000000000..595a63084 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1753309 @@ -0,0 +1,120 @@ +permissions: 0.927 +semantic: 0.903 +other: 0.885 +network: 0.863 +graphic: 0.860 +device: 0.843 +debug: 0.836 +PID: 0.808 +files: 0.777 +vnc: 0.738 +performance: 0.735 +KVM: 0.702 +boot: 0.644 +socket: 0.627 + +Ethernet interrupt vectors for sabrelite machine are defined backwards + +The sabrelite machine model used by qemu-system-arm is based on the Freescale/NXP i.MX6Q processor. This SoC has an on-board ethernet controller which is supported in QEMU using the imx_fec.c module (actually called imx.enet for this model.) + +The include/hw/arm/fsm-imx6.h file defines the interrupt vectors for the imx.enet device like this: + +#define FSL_IMX6_ENET_MAC_1588_IRQ 118 +#define FSL_IMX6_ENET_MAC_IRQ 119 + +However, this is backwards. The reference manual for the i.MX6D/Q devices can be found here: + +https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf + +On page 225, in Table 3-1. ARM Cortex A9 domain interrupt summary, it shows the following: + +150 ENET +MAC 0 IRQ, Logical OR of: +MAC 0 Periodic Timer Overflow +MAC 0 Time Stamp Available +MAC 0 Time Stamp Available +MAC 0 Time Stamp Available +MAC 0 Payload Receive Error +MAC 0 Transmit FIFO Underrun +MAC 0 Collision Retry Limit +MAC 0 Late Collision +MAC 0 Ethernet Bus Error +MAC 0 MII Data Transfer Done +MAC 0 Receive Buffer Done +MAC 0 Receive Frame Done +MAC 0 Transmit Buffer Done +MAC 0 Transmit Frame Done +MAC 0 Graceful Stop +MAC 0 Babbling Transmit Error +MAC 0 Babbling Receive Error +MAC 0 Wakeup Request [synchronous] + +151 ENET +MAC 0 1588 Timer interrupt [synchronous] request + +Note: +150 - 32 == 118 +151 - 32 == 119 + +In other words, the vector definitions in the fsl-imx6.h file are reversed. The correct definition is: + +#define FSL_IMX6_ENET_MAC_IRQ 118 +#define FSL_IMX6_ENET_MAC_1588_IRQ 119 + +I tested the sabrelite simulation using VxWorks 7 (which supports the SabreLite board) and found that while I was able to send and receive packet data via the simulated ethernet interface, the VxWorks i.MX6 ethernet driver failed to receive any interrupts. When I corrected the interrupt vector definitions as shown above and recompiled QEMU, everything worked as expected. I was able to exchange ICMP packets with the simulated target and telnet to/from the VxWorks instance running in the virtual machine. I used the tap interface for this. + +As a workaround I was also able to make the ethernet work by modifying the VxWorks imx6q-sabrelite.dts file to change the ethernet interrupt property from 150 to 151. + +This problem was observed with the following environment: + +Host: FreeBSD/amd64 11.1-RELEASE +QEMU version: 2.11.0 and 2.11.1 built from source code + +Swapping the interrupt pins fixes the problem on Linux v4.13 and later. Older kernels start failing as follows. + + On v4.12 and earlier, the Ethernet interface fails to instantiate with + fec 2188000.ethernet (unnamed net_device) (uninitialized): MDIO read timeout + fec: probe of 2188000.ethernet failed with error -5 + I have not found the reason yet. Unmodified qemu works fine. +- v4.1 and earlier crash. The crash is due to a bad error path and fixed by commit + 32cba57ba74be ("net: fec: introduce fec_ptp_stop and use in probe fail path"). + + +Followup on #1: The relevant upstream commit is 4c8777892e80b ("ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround"). + +Test results with various kernel versions: +4.14+: Both versions of qemu (as-is and interrupts reverted) work fine +4.9.y: Requires cherry-pick of 4c8777892e80b for both versions of qemu to work +4.4.y: Requires backport of 4c8777892e80b for both versions of qemu to work +4.1.y: Requires backport of 4c8777892e80b for both versions of qemu to work + +I didn't test older kernels. + +Now the big question is if this matches the experience with real hardware. + + +"4.14+: Both versions of qemu (as-is and interrupts reverted) work fine" + +Hm. I really wonder how it can be possible that Linux works with the interrupt vectors reversed, though to be fair I have not looked at the Linux i.MX6 ENET driver code. I suppose it's possible that the driver is binding the same interrupt service routine to both interrupt vectors. If so, then it works by accident. :) + +I think U-Boot uses polling so it wouldn't care if the interrupt vectors are wrong. + +We have several SabreLite boards in house. We also have NXP Sabre SD reference boards which use the same i.MX6Q SoC and the exact same ethernet driver with the same interrupt configuration. I have always used VxWorks with them rather than Linux, and I can say for a fact that the VxWorks ENET driver only binds an ISR to vector 150 (118) (VxWorks doesn't currently support the IEEE 1588 feature with this interface so it never uses vector 151) and it works as expected -- network interrupt events are indeed received via vector 150. + +The same VxWorks image that works with real hardware does not work with QEMU unless I fix the vectors in fsl-imx6.h. + +In short, both the hardware and the manual seem to agree. QEMU is doing it wrong. :) + +Also, the errata sheet for the i.MX6 is here: + +https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf + +Apparently erratum 6687 is related to power management and wakeup events. I'm not sure how that factors in to how Linux behaves. + +#3: Correct, Linux version 4.14 and older registers two interrupt lines, both the correct and the wrong one. With qemu version, the kernel receives interrupts on irq 151, with the other on 150. So, yes, I guess it works by accident. My question is what to do with older (pre-4.14) kernels. Presumably those worked (?) with real hardware, so I am a bit concerned about the impact of applying 4c8777892e80b to those kernels. + + +Submitted https://patchwork.kernel.org/patch/10264615/ + +This is now fixed in git master by commit 6461d7e2678fe4, which updates the defines and also has a workaround for older guest kernels (which we can remove if/when we model the IOMUX). + diff --git a/results/classifier/zero-shot/108/permissions/1753314 b/results/classifier/zero-shot/108/permissions/1753314 new file mode 100644 index 000000000..da9ae28a2 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1753314 @@ -0,0 +1,69 @@ +permissions: 0.986 +boot: 0.985 +debug: 0.984 +other: 0.984 +semantic: 0.983 +socket: 0.980 +device: 0.976 +graphic: 0.975 +performance: 0.973 +vnc: 0.971 +files: 0.959 +PID: 0.958 +KVM: 0.954 +network: 0.900 + +UART in sabrelite machine simulation doesn't work with VxWorks 7 + +The imx_serial.c driver currently implements only partial support for the i.MX6 UART hardware. In particular, it does not implement support for the Transmit Complete Interrupt Enable bit in the UCR4 register. The VxWorks 7 i.MX6 serial driver depends on the behavior of this bit in actual hardware in order to send characters through the UART correctly. The result is that with the current machine model, VxWorks will boot and run in QEMU but it's unable to print any characters to the console serial port. + +I have produced a small patch for the imx_serial.c module to make it nominally functional with VxWorks 7. It works well enough to allow the boot banner to appear and for the user to interact with the target shell. + +I'm not submitting this as a patch to the development list as I'm not fully certain it complies with the hardware spec and doesn't break any other functionality. I would prefer if the maintainer (or someone) reviewed it for any issues/refinements first. + +I'm attaching the patch to this bug report. A copy can also be obtained from: + +http://people.freebsd.org/~wpaul/qemu/imx_serial.zip + +This patch was generated against QEMU 2.11.0 but also works with QEMU 2.11.1. + + + +Hi. Thanks for this patch. I've had a quick look at it against the imx datasheet, and here are my comments: + +* Firstly, we can't do anything with this patch without a Signed-off-by: line from you. In QEMU's process this is how people submitting code state that you're legally OK to contribute the code under QEMU's license and for it to go into QEMU. + + * Secondly, it would be very helpful if you could send patches as a simple patch format, rather than as a zipfile, and to the QEMU mailing list. https://wiki.qemu.org/Contribute/SubmitAPatch has our guidelines on this. + + * Simply adding a new VMSTATE_UINT32() field will break migration. It's better to put the new field into its own vmstate subsection so that this doesn't happen; see docs/devel/migration.rst. If we don't care about cross-version migration we could just bump the version_id/minimum_version_id fields. + + * If you run scripts/checkpatch.pl over your patch it should warn you about minor coding style issues. For instance we prefer all if() statements to use {}, even if there's only one line in them. + + * Your change to imx_update() does this: ++ if (s->ucr4 & UCR4_TXEN) ++ flags |= USR1_TRDY; + +but that isn't what the spec says UCR4_TXEN does; it says we raise an interrupt only if UCR4_TXEN and USR2_TXDC are both high. + + * the imx_update() function is already rather confused in how it handles the 'flags' variable, and this change extends that confusion. The function is trying to treat 'flags' as a single set of interrupt flag bits, but the device doesn't actually have a single unified set of interrupt flags like that, they're spread over UTS and USR1 and USR2. The code as it is looks odd -- should USR1.TXMPTYEN == 0 really suppress USR1_TRDY interrupts ? I suspect this is a bug, and we should also clean things up to make 'flags' be a bool. + + +As I said before: + +"I'm not submitting this as a patch to the development list as I'm not fully certain it complies with the hardware spec and doesn't break any other functionality." + +What I'm trying to say here is that while I may have been able to cobble together a hack to make the UART nominally compatible with VxWorks, I do not understand the hardware or QEMU well enough to really fix this the right way. Even with my hack, every once in a while when printing lots of data on the console, the output from the UART will stall unless I press a key on the serial port, and I don't know why it does that. I did try to investigate it a little but wasn't able to make much progress. (My suspicion is that it has something to do with the fact that the imx_serial module doesn't implement FIFO support, but even if that's true I don't know how to fix it.) + +Even so, I figured it was still worth it to attach my changes to the bug report so that somebody who is better at this than me could use it as a starting point, and so that anybody else who might want to experiment with VxWorks using the QEMU sabrelite machine model wouldn't be totally stuck like I was. + +In short, the changes I made are good enough for my own needs (the output stalls don't happen often enough to really bother me), but they're not a fully debugged fix. That's why I filed a bug report instead of just submitting a patch in the first place: I wanted somebody sexier than me to create a fully debugged fix. + +That's fine; Andrey Smirnov has taken your patch as a basis for a more cleaned-up set of changes: +http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04608.html +http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04609.html +What we would like from you is a Signed-off-by: line to say that you're happy for us to do that, please. (If you have a chance to test that it works for you that would also be great.) + + +Now fixed in git master, should be in 2.12. + + diff --git a/results/classifier/zero-shot/108/permissions/1757323 b/results/classifier/zero-shot/108/permissions/1757323 new file mode 100644 index 000000000..0e12bf92d --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1757323 @@ -0,0 +1,107 @@ +permissions: 0.936 +files: 0.920 +device: 0.920 +other: 0.913 +socket: 0.911 +network: 0.906 +debug: 0.900 +performance: 0.897 +graphic: 0.892 +boot: 0.886 +semantic: 0.883 +PID: 0.882 +KVM: 0.878 +vnc: 0.867 + +blue screen running windows 10 install DVD on qemu + +i get a blue screen at the first screen of the windows 10 DVD setup (Win10_1709_English_x64.iso, available from MS). + +The DVD boots fine, and gets to the first dialog: http://codewithoutborders.com/posted/qemu1.png +and then if i just wait a minute of so it blue screen's. +either DRIVER IRQL NOT LESS OR EQUAL: http://codewithoutborders.com/posted/qemu2.png +or KMODE EXCEPTION NOT HANDLED: http://codewithoutborders.com/posted/qemu3.png + + + + +the qemu command-line is: + +/usr/bin/qemu-system-x87_64 \ + -boot strict=on \ + -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-generic/monitor.sock,server,nowait \ + -chardev spicevmc,id=charchannel0,name=vdagent \ + -cpu core2duo,+lahf_lm,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,kvm=off \ + -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \ + -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 \ + -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \ + -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \ + -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 \ + -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \ + -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ + -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ + -drive file=/mnt/ISOs/Win10_1709_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ + -global kvm-pit.lost_tick_policy=discard \ + -global PIIX4_PM.disable_s3=1 \ + -global PIIX4_PM.disable_s4=1 \ + -m 4096 \ + -machine pc-i440fx-xenial,accel=tcg,usb=off \ + -mon chardev=charmonitor,id=monitor,mode=control \ + -msg timestamp=on \ + -name generic \ + -nodefaults \ + -no-hpet \ + -no-shutdown \ + -no-user-config \ + -realtime mlock=off \ + -rtc base=utc,driftfix=slew \ + -S \ + -smp 2,sockets=2,cores=1,threads=1 \ + -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \ + -uuid 3902a801-42dd-4bf2-8f3a-cbc68f4f8564 + + +$ /usr/bin/qemu-system-x87_64 --version +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24), Copyright (c) 2003-2008 Fabrice Bellard + +$ uname -a +Linux host 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +$ cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 15 +model name : Intel(R) Core(TM)2 Quad CPU @ 2.66GHz +stepping : 7 +microcode : 0x66 +cpu MHz : 2671.406 +cache size : 4096 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 10 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti retpoline tpr_shadow dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 +bogomips : 5342.81 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +... 3 more times + +i should add: i do NOT get these crashes if I boot the same image on the host bare-metal. + +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/zero-shot/108/permissions/1759338 b/results/classifier/zero-shot/108/permissions/1759338 new file mode 100644 index 000000000..ea5bf856b --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1759338 @@ -0,0 +1,142 @@ +permissions: 0.937 +socket: 0.930 +network: 0.920 +boot: 0.915 +vnc: 0.911 +device: 0.901 +graphic: 0.901 +other: 0.900 +performance: 0.876 +PID: 0.875 +debug: 0.846 +semantic: 0.844 +KVM: 0.734 +files: 0.732 + +qemu-system-sparc w/ SS-20 ROM does not add processors + +When booting a SPARCstation-20 with the original ROM, qemu does not set the number of processors in a way that this ROM can understand it, and the ROM always reports only 1 processor installed: + + + ~/qemu /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -cpu "TI SuperSparc 60" -smp 2 -nographic + +Power-ON Reset + + + + + SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95) + + +CPU_#0 TI, TMS390Z50(3.x) 0Mb External cache + +CPU_#1 ******* NOT installed ******* +CPU_#2 ******* NOT installed ******* +CPU_#3 ******* NOT installed ******* + + <<< CPU_00000000 on MBus Slot_00000000 >>> IS RUNNING (MID = 00000008) + + +... + +Cpu #0 TI,TMS390Z50 +Cpu #1 Nothing there +Cpu #2 Nothing there +Cpu #3 Nothing there + +... + +SPARCstation 20 (1 X 390Z50), No Keyboard +ROM Rev. 2.25, 128 MB memory installed, Serial #1193046. +Ethernet address 52:54:0:12:34:56, Host ID: 72123456. + + + + +(It is necessary use SS-20 since it is the only sun4m model that supports 512MB RAM, and I can't get Solaris to install on the SS-20 using OpenBIOS.) + +When booting with OpenBIOS I can't seem to boot any version of Solaris though I had heard this did work. Solaris 8 and 9 do work nicely with this ROM, but I am opening this to see if it is possible to fix this to allow the original OBP ROM to see multiple processors. + +As of QEMU 4 OpenBIOS can boot Solaris again, and it does properly allocate multiple CPUs. Of course, it's a whole lot slower on multiple CPUs which I wasn't really anticipating, but it does work. (And single CPU is so fast anyway compared to the actual hardware it's emulating!) So this bug while still applicable can be closed. + +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. + +Reporter said in comment #1 that the bug can be closed, so let's close it :-) + + +Yes this can be closed, no problems now using open bios to boot Solaris and it does support multiple processors though this is actually slower than one. + +Sent from my mobile device + +On Nov 13, 2020, at 11:41 AM, Peter Maydell <email address hidden> wrote: + + Reporter said in comment #1 that the bug can be closed, so let's close +it :-) + + +** Changed in: qemu +Status: Incomplete => Fix Released + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1759338<https://bugs.launchpad.net/bugs/1759338> + +Title: +qemu-system-sparc w/ SS-20 ROM does not add processors + +Status in QEMU: +Fix Released + +Bug description: +When booting a SPARCstation-20 with the original ROM, qemu does not +set the number of processors in a way that this ROM can understand it, +and the ROM always reports only 1 processor installed: + + +~/qemu /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -cpu "TI SuperSparc 60" -smp 2 -nographic + +Power-ON Reset + + + +SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95) + + +CPU_#0 TI, TMS390Z50(3.x) 0Mb External cache + +CPU_#1 ******* NOT installed ******* +CPU_#2 ******* NOT installed ******* +CPU_#3 ******* NOT installed ******* + +<<< CPU_00000000 on MBus Slot_00000000 >>> IS RUNNING (MID = +00000008) + + +... + +Cpu #0 TI,TMS390Z50 +Cpu #1 Nothing there +Cpu #2 Nothing there +Cpu #3 Nothing there + +... + +SPARCstation 20 (1 X 390Z50), No Keyboard +ROM Rev. 2.25, 128 MB memory installed, Serial #1193046. +Ethernet address 52:54:0:12:34:56, Host ID: 72123456. + + + +(It is necessary use SS-20 since it is the only sun4m model that supports 512MB RAM, and I can't get Solaris to install on the SS-20 using OpenBIOS.) + +When booting with OpenBIOS I can't seem to boot any version of Solaris +though I had heard this did work. Solaris 8 and 9 do work nicely with +this ROM, but I am opening this to see if it is possible to fix this +to allow the original OBP ROM to see multiple processors. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1759338/+subscriptions<https://bugs.launchpad.net/qemu/+bug/1759338/+subscriptions> + + diff --git a/results/classifier/zero-shot/108/permissions/1769053 b/results/classifier/zero-shot/108/permissions/1769053 new file mode 100644 index 000000000..486c2c62a --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1769053 @@ -0,0 +1,1157 @@ +permissions: 0.944 +other: 0.933 +PID: 0.905 +semantic: 0.902 +debug: 0.900 +performance: 0.879 +device: 0.872 +KVM: 0.867 +graphic: 0.857 +boot: 0.853 +files: 0.849 +socket: 0.787 +vnc: 0.751 +network: 0.713 + +Ability to control phys-bits through libvirt + +Attempting to start a KVM guest with more than 1TB of RAM fails. + +It looks like we might need some extra patches: https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html + +ProblemType: Bug +DistroRelease: Ubuntu 18.04 +Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +Uname: Linux 4.15.0-20-generic x86_64 +ApportVersion: 2.20.9-0ubuntu7 +Architecture: amd64 +CurrentDesktop: Unity:Unity7:ubuntu +Date: Fri May 4 16:21:14 2018 +InstallationDate: Installed on 2017-04-05 (393 days ago) +InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) +MachineType: Dell Inc. XPS 13 9360 +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise vt.handoff=1 +SourcePackage: qemu +UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +dmi.bios.date: 02/26/2018 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: 2.6.2 +dmi.board.name: 0PF86Y +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 9 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +dmi.product.family: XPS +dmi.product.name: XPS 13 9360 +dmi.sys.vendor: Dell Inc. + + + +(I'm not trying to start this on my laptop, so ignore the uploaded files. They're just what apport-bug decided to include.) + +Hi Daniel, +might I ask what you expect now? + +The changes to seabios are not even upstream yet in git://git.seabios.org/seabios.git +The changes to qemu are neither upstream in git://git.qemu.org/qemu.git + +The changes linked also are for a qemu way++ back in time (like pre trusty), so they just don't apply. Some of these changes are handled already, but different like the second qemu change of above mail is in qemu since "6c7c3c21 x86: implement la57 paging mode" which is qemu >=2.9. +That said - this one I could track, maybe the other changes are also upstream but in a way different form. + +At least for myself I currently have no >1TB system to even try this - well I have done this on s390x and there it works fine already but you need x86 here. + +Even when all of the above would be resolved, the mail above states that even if those are applied they still have issues when going >1TB. + +I think you'd need a clear this is what I tried and this is what fails with a setup as simple as possible. If it fails in Ubuntu we can build a latest upstream build for you and if failing there we can work with upstream to resolve properly. From there we can think about the backportability of those changes. But the suggested "hey there are these patches, won't work. + +Please don't get me wrong (I want to help), but so far this appears to me so far as a suggestion of a set of non-upstreamed, non-applicable, non-testable, non-working changes. +We need to better sort out how to handle this which is why I ask what you expect to happen now. + +Hi Christian, + +Sorry, I should have been a *lot* more clear. + +I wanted to file the bug so that we have somewhere to figure out what needs +to be done and track the progress - trying to avoid it becoming something +we vaguely know about but don't ever do anything about. + +Thanks so much for your analysis of the patches. I will dig in to the +upstream status and see where they're at with large memory guests. + +I know we're missing test hardware. I will make some enquiries within the +team and see what can dig up, otherwise we have a customer that might be +able to run some tests. + +So for now, the action items are: + - I will hunt down a >1TB machine. + - I will check what the progress of 1TB guests in upstream Qemu is. + +Apologies again, and thanks for the pointers. + +Regards, +Daniel + +On Fri, May 4, 2018 at 5:44 PM, ChristianEhrhardt < +<email address hidden>> wrote: + +> Hi Daniel, +> might I ask what you expect now? +> +> The changes to seabios are not even upstream yet in git:// +> git.seabios.org/seabios.git +> The changes to qemu are neither upstream in git://git.qemu.org/qemu.git +> +> The changes linked also are for a qemu way++ back in time (like pre +> trusty), so they just don't apply. Some of these changes are handled +> already, but different like the second qemu change of above mail is in qemu +> since "6c7c3c21 x86: implement la57 paging mode" which is qemu >=2.9. +> That said - this one I could track, maybe the other changes are also +> upstream but in a way different form. +> +> At least for myself I currently have no >1TB system to even try this - +> well I have done this on s390x and there it works fine already but you +> need x86 here. +> +> Even when all of the above would be resolved, the mail above states that +> even if those are applied they still have issues when going >1TB. +> +> I think you'd need a clear this is what I tried and this is what fails +> with a setup as simple as possible. If it fails in Ubuntu we can build a +> latest upstream build for you and if failing there we can work with +> upstream to resolve properly. From there we can think about the +> backportability of those changes. But the suggested "hey there are these +> patches, won't work. +> +> Please don't get me wrong (I want to help), but so far this appears to me +> so far as a suggestion of a set of non-upstreamed, non-applicable, +> non-testable, non-working changes. +> We need to better sort out how to handle this which is why I ask what you +> expect to happen now. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1769053 +> +> Title: +> Cannot start a guest with more than 1TB of RAM +> +> Status in QEMU: +> New +> Status in qemu package in Ubuntu: +> New +> +> Bug description: +> Attempting to start a KVM guest with more than 1TB of RAM fails. +> +> It looks like we might need some extra patches: +> https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> +> ProblemType: Bug +> DistroRelease: Ubuntu 18.04 +> Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> Uname: Linux 4.15.0-20-generic x86_64 +> ApportVersion: 2.20.9-0ubuntu7 +> Architecture: amd64 +> CurrentDesktop: Unity:Unity7:ubuntu +> Date: Fri May 4 16:21:14 2018 +> InstallationDate: Installed on 2017-04-05 (393 days ago) +> InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 +> (20161012.2) +> MachineType: Dell Inc. XPS 13 9360 +> ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic +> root=/dev/mapper/ubuntu--vg-root ro quiet splash +> transparent_hugepage=madvise vt.handoff=1 +> SourcePackage: qemu +> UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> dmi.bios.date: 02/26/2018 +> dmi.bios.vendor: Dell Inc. +> dmi.bios.version: 2.6.2 +> dmi.board.name: 0PF86Y +> dmi.board.vendor: Dell Inc. +> dmi.board.version: A00 +> dmi.chassis.type: 9 +> dmi.chassis.vendor: Dell Inc. +> dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.: +> pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> dmi.product.family: XPS +> dmi.product.name: XPS 13 9360 +> dmi.sys.vendor: Dell Inc. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +> + + +Thanks for your clarification Daniel, I'll mark both tasks incomplete then until you come back with that data. + +Interesting; I thought this was supposed to work. +I know we (RH) have some downstream patches for >1TB RAM, but the last I'd heard they weren't supposed to be necessary any more, except for compatibility with old versions. + +It's probably worth checking the guest view fo the CPUs physical address bits and making sure it's no bigger than the host (phys-bits=n or host-phys-bits=true on the -cpu) +QEMU often defaults to 40 bits and things get confusing. + +Note also you can do some 1TB+ tests on smaller machines as long as they have a large enough address size on the host CPUs. Tricks like adding empty hot-plug DIMM slots leaving a 1TB hole can tickle some bugs. Even adding 1TB of swap to your host and being careful with your guest can work :-) + +You don't need a >1TB host to spin up a >1TB guest. Unless you're using pci passthru (and/or SRIOV), or something else that requires qemu to alloc and pin all guest mem, you can simply overcommit; normal guests don't require mem pre-allocation or pinning. + +On your host do this to allow overcommitting such a large amount (this allows 16T but can be adjusted as needed): + +$ echo $[ 16 * 1024 * 1024 * 1024 ] | sudo tee /proc/sys/vm/overcommit_kbytes +17179869184 +$ echo 1 | sudo tee /proc/sys/vm/overcommit_memory +1 + + +Then just virsh edit your guest to use >1TB, e.g.: + + <memory unit='GiB'>1500</memory> + + +And of course, stop and restart the guest to pick up the xml change. + +BTW this is the stacktrace I get from a Xenial guest on Xenial host: + +[ 0.000000] BUG: unable to handle kernel paging request at ffffc90000000004 +[ 0.000000] IP: [<ffffffff81f7dc60>] hpet_enable.part.13+0x23/0x2a5 +[ 0.000000] PGD 171629ab067 PUD 171629ac067 PMD 171629ad067 PTE 80000000fed00073 +[ 0.000000] Oops: 0009 [#1] SMP +[ 0.000000] Modules linked in: +[ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-122-generic #146-Ubuntu +[ 0.000000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 +[ 0.000000] task: ffffffff81e13500 ti: ffffffff81e00000 task.ti: ffffffff81e00000 +[ 0.000000] RIP: 0010:[<ffffffff81f7dc60>] [<ffffffff81f7dc60>] hpet_enable.part.13+0x23/0x2a5 +[ 0.000000] RSP: 0000:ffffffff81e03ef0 EFLAGS: 00010282 +[ 0.000000] RAX: ffffc90000000000 RBX: ffffffffffffffff RCX: 0000000000000000 +[ 0.000000] RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000000 +[ 0.000000] RBP: ffffffff81e03f10 R08: 000000000001ad50 R09: 00000000000001f0 +[ 0.000000] R10: ffff89773fa20000 R11: 0000000000000001 R12: ffff89773f99f6c0 +[ 0.000000] R13: ffffffff8200e920 R14: ffffffff8201c2e0 R15: ffffffff81e03fa8 +[ 0.000000] FS: 0000000000000000(0000) GS:ffff897162c00000(0000) knlGS:0000000000000000 +[ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +[ 0.000000] CR2: ffffc90000000004 CR3: 0000000001e0a000 CR4: 0000000000000630 +[ 0.000000] Stack: +[ 0.000000] ffffffffffffffff ffff89773f99f6c0 ffffffff8200e920 ffffffff8201c2e0 +[ 0.000000] ffffffff81e03f20 ffffffff81f7df00 ffffffff81e03f30 ffffffff81f6ee7a +[ 0.000000] ffffffff81e03f40 ffffffff81f6ee4a ffffffff81e03f80 ffffffff81f63f71 +[ 0.000000] Call Trace: +[ 0.000000] [<ffffffff81f7df00>] hpet_enable+0x1e/0x20 +[ 0.000000] [<ffffffff81f6ee7a>] hpet_time_init+0x9/0x19 +[ 0.000000] [<ffffffff81f6ee4a>] x86_late_time_init+0x10/0x17 +[ 0.000000] [<ffffffff81f63f71>] start_kernel+0x3d8/0x4aa +[ 0.000000] [<ffffffff81f63120>] ? early_idt_handler_array+0x120/0x120 +[ 0.000000] [<ffffffff81f63339>] x86_64_start_reservations+0x2a/0x2c +[ 0.000000] [<ffffffff81f63485>] x86_64_start_kernel+0x14a/0x16d +[ 0.000000] Code: 01 00 00 00 41 5c 5d c3 55 48 8b 3d 63 f4 18 00 be 00 04 00 00 48 89 e5 41 56 41 55 41 54 53 e8 f7 f2 0e ff 48 89 05 d8 f4 18 00 <8b> 48 04 b8 e9 03 00 00 48 8b 15 c9 f4 18 00 8b 52 10 ff c2 75 +[ 0.000000] RIP [<ffffffff81f7dc60>] hpet_enable.part.13+0x23/0x2a5 +[ 0.000000] RSP <ffffffff81e03ef0> +[ 0.000000] CR2: ffffc90000000004 +[ 0.000000] ---[ end trace 404be15fe05aa681 ]--- +[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! +[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! + + +And with non-massive mem (so the guest actually boots up), the guest does show only 40 bits of phys mem addressing, so qemu will definitely have to increase that to be able to provide >1TB of phys mem to the guest (assuming qemu doesn't adjust that dynamically based on the total mem provided to the guest) + +ubuntu@largemem:~$ grep -m 1 'address sizes' /proc/cpuinfo +address sizes : 40 bits physical, 48 bits virtual + + +Ah right Dan, if you're seeing the 40 bits physical in the guest you definitely need to try the flags I suggest in comment 6; host-phys-bits=true should work for you. + +> Interesting; I thought this was supposed to work. + +Exactly that was my thought when triaging it initially +Furthermore I assume people working la57 (https://lwn.net/Articles/730925/) and such ran tests on much bigger sizes. + +> Ah right Dan, if you're seeing the 40 bits physical in the guest you definitely need to try the flags I suggest in comment 6; host-phys-bits=true should work for you. + +I tested Bionic to be at least on libvirt 4.0 / qemu 2.11.1 when we want to check things under the "supposed to work now" flag. + +Defaults: +Host: address sizes : 46 bits physical, 48 bits virtual +Guest: address sizes : 40 bits physical, 48 bits virtual + +I ensured that with option -cpu host,host-phys-bits=true set I successfully get what my host can provide in the guest: +Guest: address sizes : 46 bits physical, 48 bits virtual + +Starting a guest with that >1TB (that would be mostly on swap if needed) works just fine as expected. Here ~1063 GB from /proc/meminfo +MemTotal: 1114676492 kB + +I also checked a more compatible approach like -cpu qemu64,phys-bits=42 and that works as well. + +IMHO - if anything - one could argue that libvirt/qemu could be smarter about e.g. auto adding those arguments (or print a warning) when crossing a certain memory size. + +So for now I'd stick to the "actually works" summary and keep the status to incomplete. + +* ChristianEhrhardt (<email address hidden>) wrote: +> > Interesting; I thought this was supposed to work. +> +> Exactly that was my thought when triaging it initially +> Furthermore I assume people working la57 (https://lwn.net/Articles/730925/) and such ran tests on much bigger sizes. + +I assume so, but I've not looked at the detail of that. + +> > Ah right Dan, if you're seeing the 40 bits physical in the guest you +> definitely need to try the flags I suggest in comment 6; host-phys- +> bits=true should work for you. +> +> I tested Bionic to be at least on libvirt 4.0 / qemu 2.11.1 when we want +> to check things under the "supposed to work now" flag. +> +> Defaults: +> Host: address sizes : 46 bits physical, 48 bits virtual +> Guest: address sizes : 40 bits physical, 48 bits virtual +> +> I ensured that with option -cpu host,host-phys-bits=true set I successfully get what my host can provide in the guest: +> Guest: address sizes : 46 bits physical, 48 bits virtual +> +> Starting a guest with that >1TB (that would be mostly on swap if needed) works just fine as expected. Here ~1063 GB from /proc/meminfo +> MemTotal: 1114676492 kB + +OK, good - that suggests there's nothing missing. +We enable host-phys-bits=true by default I think (in our machine type?) + +> I also checked a more compatible approach like -cpu qemu64,phys-bits=42 +> and that works as well. +> +> IMHO - if anything - one could argue that libvirt/qemu could be smarter +> about e.g. auto adding those arguments (or print a warning) when +> crossing a certain memory size. + +The problem is there are a whole bunch of things that are hard to deal +with: + a) Cheaper CPUs tend to have smaller phys-bits even in the same +generation; e.g. my laptop is still 36 bits, a lot are 39 bits. I think +the same is true of the Xeon E3-.... family. It makes it hard to know +what to pick when you're going to allow migration. + + b) Reasoning about the total address size range is difficult; you've +got to take into account PCI address space and hot plug space etc +to know where the upper edge is. + +Dave + +> So for now I'd stick to the "actually works" summary and keep the status +> to incomplete. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1769053 +> +> Title: +> Cannot start a guest with more than 1TB of RAM +> +> Status in QEMU: +> Incomplete +> Status in qemu package in Ubuntu: +> Incomplete +> +> Bug description: +> Attempting to start a KVM guest with more than 1TB of RAM fails. +> +> It looks like we might need some extra patches: +> https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> +> ProblemType: Bug +> DistroRelease: Ubuntu 18.04 +> Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> Uname: Linux 4.15.0-20-generic x86_64 +> ApportVersion: 2.20.9-0ubuntu7 +> Architecture: amd64 +> CurrentDesktop: Unity:Unity7:ubuntu +> Date: Fri May 4 16:21:14 2018 +> InstallationDate: Installed on 2017-04-05 (393 days ago) +> InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) +> MachineType: Dell Inc. XPS 13 9360 +> ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise vt.handoff=1 +> SourcePackage: qemu +> UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> dmi.bios.date: 02/26/2018 +> dmi.bios.vendor: Dell Inc. +> dmi.bios.version: 2.6.2 +> dmi.board.name: 0PF86Y +> dmi.board.vendor: Dell Inc. +> dmi.board.version: A00 +> dmi.chassis.type: 9 +> dmi.chassis.vendor: Dell Inc. +> dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> dmi.product.family: XPS +> dmi.product.name: XPS 13 9360 +> dmi.sys.vendor: Dell Inc. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +On Tue, May 8, 2018 at 10:37 AM, Dr. David Alan Gilbert <<email address hidden> +> wrote: + +> * ChristianEhrhardt (<email address hidden>) wrote: +> > > Interesting; I thought this was supposed to work. +> > +> > Exactly that was my thought when triaging it initially +> > Furthermore I assume people working la57 (https://lwn.net/Articles/ +> 730925/) and such ran tests on much bigger sizes. +> +> I assume so, but I've not looked at the detail of that. +> +> > > Ah right Dan, if you're seeing the 40 bits physical in the guest you +> > definitely need to try the flags I suggest in comment 6; host-phys- +> > bits=true should work for you. +> > +> > I tested Bionic to be at least on libvirt 4.0 / qemu 2.11.1 when we want +> > to check things under the "supposed to work now" flag. +> > +> > Defaults: +> > Host: address sizes : 46 bits physical, 48 bits virtual +> > Guest: address sizes : 40 bits physical, 48 bits virtual +> > +> > I ensured that with option -cpu host,host-phys-bits=true set I +> successfully get what my host can provide in the guest: +> > Guest: address sizes : 46 bits physical, 48 bits virtual +> > +> > Starting a guest with that >1TB (that would be mostly on swap if needed) +> works just fine as expected. Here ~1063 GB from /proc/meminfo +> > MemTotal: 1114676492 kB +> +> OK, good - that suggests there's nothing missing. +> We enable host-phys-bits=true by default I think (in our machine type?) +> + +Interesting approach, I see your comment about that already in [1] when it +was added. +I didn't realize some machine types were setting this already - I assume it +isn't the general default for migratebility to other hosts (like our 36/39 +bit laptops). + +I assume "we" in this context are RedHat downstream changes to the (some) +machine type(s)? +I see the benefit for huge guests to work without setting those properties, +but I wonder if that caused you trouble in regard to migrations? + +[1]: https://patchwork.kernel.org/patch/9223999/ + + + +> > I also checked a more compatible approach like -cpu qemu64,phys-bits=42 +> > and that works as well. +> > +> > IMHO - if anything - one could argue that libvirt/qemu could be smarter +> > about e.g. auto adding those arguments (or print a warning) when +> > crossing a certain memory size. +> +> The problem is there are a whole bunch of things that are hard to deal +> with: +> a) Cheaper CPUs tend to have smaller phys-bits even in the same +> generation; e.g. my laptop is still 36 bits, a lot are 39 bits. I think +> the same is true of the Xeon E3-.... family. It makes it hard to know +> what to pick when you're going to allow migration. +> +> b) Reasoning about the total address size range is difficult; you've +> got to take into account PCI address space and hot plug space etc +> to know where the upper edge is. +> + +I agree that checking the total address size might have too much false +positives for all the complexities around "estimating" that size. +/me is giving up this idea :-) + + +> Dave +> +> > So for now I'd stick to the "actually works" summary and keep the status +> > to incomplete. +> > +> > -- +> > You received this bug notification because you are subscribed to the bug +> > report. +> > https://bugs.launchpad.net/bugs/1769053 +> > +> > Title: +> > Cannot start a guest with more than 1TB of RAM +> > +> > Status in QEMU: +> > Incomplete +> > Status in qemu package in Ubuntu: +> > Incomplete +> > +> > Bug description: +> > Attempting to start a KVM guest with more than 1TB of RAM fails. +> > +> > It looks like we might need some extra patches: +> > https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> > +> > ProblemType: Bug +> > DistroRelease: Ubuntu 18.04 +> > Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> > ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> > Uname: Linux 4.15.0-20-generic x86_64 +> > ApportVersion: 2.20.9-0ubuntu7 +> > Architecture: amd64 +> > CurrentDesktop: Unity:Unity7:ubuntu +> > Date: Fri May 4 16:21:14 2018 +> > InstallationDate: Installed on 2017-04-05 (393 days ago) +> > InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 +> (20161012.2) +> > MachineType: Dell Inc. XPS 13 9360 +> > ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic +> root=/dev/mapper/ubuntu--vg-root ro quiet splash +> transparent_hugepage=madvise vt.handoff=1 +> > SourcePackage: qemu +> > UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> > dmi.bios.date: 02/26/2018 +> > dmi.bios.vendor: Dell Inc. +> > dmi.bios.version: 2.6.2 +> > dmi.board.name: 0PF86Y +> > dmi.board.vendor: Dell Inc. +> > dmi.board.version: A00 +> > dmi.chassis.type: 9 +> > dmi.chassis.vendor: Dell Inc. +> > dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.: +> pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> > dmi.product.family: XPS +> > dmi.product.name: XPS 13 9360 +> > dmi.sys.vendor: Dell Inc. +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +> -- +> Dr. David Alan Gilbert / <email address hidden> / Manchester, UK +> +> -- +> You received this bug notification because you are a member of Ubuntu +> Virtualisation team, which is subscribed to qemu in Ubuntu. +> https://bugs.launchpad.net/bugs/1769053 +> +> Title: +> Cannot start a guest with more than 1TB of RAM +> +> Status in QEMU: +> Incomplete +> Status in qemu package in Ubuntu: +> Incomplete +> +> Bug description: +> Attempting to start a KVM guest with more than 1TB of RAM fails. +> +> It looks like we might need some extra patches: +> https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> +> ProblemType: Bug +> DistroRelease: Ubuntu 18.04 +> Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> Uname: Linux 4.15.0-20-generic x86_64 +> ApportVersion: 2.20.9-0ubuntu7 +> Architecture: amd64 +> CurrentDesktop: Unity:Unity7:ubuntu +> Date: Fri May 4 16:21:14 2018 +> InstallationDate: Installed on 2017-04-05 (393 days ago) +> InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 +> (20161012.2) +> MachineType: Dell Inc. XPS 13 9360 +> ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic +> root=/dev/mapper/ubuntu--vg-root ro quiet splash +> transparent_hugepage=madvise vt.handoff=1 +> SourcePackage: qemu +> UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> dmi.bios.date: 02/26/2018 +> dmi.bios.vendor: Dell Inc. +> dmi.bios.version: 2.6.2 +> dmi.board.name: 0PF86Y +> dmi.board.vendor: Dell Inc. +> dmi.board.version: A00 +> dmi.chassis.type: 9 +> dmi.chassis.vendor: Dell Inc. +> dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.: +> pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> dmi.product.family: XPS +> dmi.product.name: XPS 13 9360 +> dmi.sys.vendor: Dell Inc. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +> + + + +-- +Christian Ehrhardt +Software Engineer, Ubuntu Server +Canonical Ltd + + +* ChristianEhrhardt (<email address hidden>) wrote: +> On Tue, May 8, 2018 at 10:37 AM, Dr. David Alan Gilbert <<email address hidden> +> > wrote: +> +> > * ChristianEhrhardt (<email address hidden>) wrote: +> > > > Interesting; I thought this was supposed to work. +> > > +> > > Exactly that was my thought when triaging it initially +> > > Furthermore I assume people working la57 (https://lwn.net/Articles/ +> > 730925/) and such ran tests on much bigger sizes. +> > +> > I assume so, but I've not looked at the detail of that. +> > +> > > > Ah right Dan, if you're seeing the 40 bits physical in the guest you +> > > definitely need to try the flags I suggest in comment 6; host-phys- +> > > bits=true should work for you. +> > > +> > > I tested Bionic to be at least on libvirt 4.0 / qemu 2.11.1 when we want +> > > to check things under the "supposed to work now" flag. +> > > +> > > Defaults: +> > > Host: address sizes : 46 bits physical, 48 bits virtual +> > > Guest: address sizes : 40 bits physical, 48 bits virtual +> > > +> > > I ensured that with option -cpu host,host-phys-bits=true set I +> > successfully get what my host can provide in the guest: +> > > Guest: address sizes : 46 bits physical, 48 bits virtual +> > > +> > > Starting a guest with that >1TB (that would be mostly on swap if needed) +> > works just fine as expected. Here ~1063 GB from /proc/meminfo +> > > MemTotal: 1114676492 kB +> > +> > OK, good - that suggests there's nothing missing. +> > We enable host-phys-bits=true by default I think (in our machine type?) +> > +> +> Interesting approach, I see your comment about that already in [1] when it +> was added. +> I didn't realize some machine types were setting this already - I assume it +> isn't the general default for migratebility to other hosts (like our 36/39 +> bit laptops). +> +> I assume "we" in this context are RedHat downstream changes to the (some) +> machine type(s)? + +That's right; you sohuld be able to find them if you dig around CentOS's +set. + +> I see the benefit for huge guests to work without setting those properties, +> but I wonder if that caused you trouble in regard to migrations? + +It could, although I don't remember any reports of people hitting it. +The problem is finding a better solution; that's why I added both the +host-phys-bits and the ability to set phys-bits= so that you can make +a smarter choice based on what hardware you actually have. Who or what +should make that smarter choice hasn't really ever been answered. + +> [1]: https://patchwork.kernel.org/patch/9223999/ + +Prior to that patch set, QEMU had always been a fixed 40 bits, so I +didn't change the default behaviour with that set; I just let you change +it by adding the flags. +(As I remember TCG was hard coded as 40 bits in some places so didn't +want to break that either). + +Dave + +> +> +> > > I also checked a more compatible approach like -cpu qemu64,phys-bits=42 +> > > and that works as well. +> > > +> > > IMHO - if anything - one could argue that libvirt/qemu could be smarter +> > > about e.g. auto adding those arguments (or print a warning) when +> > > crossing a certain memory size. +> > +> > The problem is there are a whole bunch of things that are hard to deal +> > with: +> > a) Cheaper CPUs tend to have smaller phys-bits even in the same +> > generation; e.g. my laptop is still 36 bits, a lot are 39 bits. I think +> > the same is true of the Xeon E3-.... family. It makes it hard to know +> > what to pick when you're going to allow migration. +> > +> > b) Reasoning about the total address size range is difficult; you've +> > got to take into account PCI address space and hot plug space etc +> > to know where the upper edge is. +> > +> +> I agree that checking the total address size might have too much false +> positives for all the complexities around "estimating" that size. +> /me is giving up this idea :-) +> +> +> > Dave +> > +> > > So for now I'd stick to the "actually works" summary and keep the status +> > > to incomplete. +> > > +> > > -- +> > > You received this bug notification because you are subscribed to the bug +> > > report. +> > > https://bugs.launchpad.net/bugs/1769053 +> > > +> > > Title: +> > > Cannot start a guest with more than 1TB of RAM +> > > +> > > Status in QEMU: +> > > Incomplete +> > > Status in qemu package in Ubuntu: +> > > Incomplete +> > > +> > > Bug description: +> > > Attempting to start a KVM guest with more than 1TB of RAM fails. +> > > +> > > It looks like we might need some extra patches: +> > > https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> > > +> > > ProblemType: Bug +> > > DistroRelease: Ubuntu 18.04 +> > > Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> > > ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> > > Uname: Linux 4.15.0-20-generic x86_64 +> > > ApportVersion: 2.20.9-0ubuntu7 +> > > Architecture: amd64 +> > > CurrentDesktop: Unity:Unity7:ubuntu +> > > Date: Fri May 4 16:21:14 2018 +> > > InstallationDate: Installed on 2017-04-05 (393 days ago) +> > > InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 +> > (20161012.2) +> > > MachineType: Dell Inc. XPS 13 9360 +> > > ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic +> > root=/dev/mapper/ubuntu--vg-root ro quiet splash +> > transparent_hugepage=madvise vt.handoff=1 +> > > SourcePackage: qemu +> > > UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> > > dmi.bios.date: 02/26/2018 +> > > dmi.bios.vendor: Dell Inc. +> > > dmi.bios.version: 2.6.2 +> > > dmi.board.name: 0PF86Y +> > > dmi.board.vendor: Dell Inc. +> > > dmi.board.version: A00 +> > > dmi.chassis.type: 9 +> > > dmi.chassis.vendor: Dell Inc. +> > > dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.: +> > pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> > > dmi.product.family: XPS +> > > dmi.product.name: XPS 13 9360 +> > > dmi.sys.vendor: Dell Inc. +> > > +> > > To manage notifications about this bug go to: +> > > https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +> > -- +> > Dr. David Alan Gilbert / <email address hidden> / Manchester, UK +> > +> > -- +> > You received this bug notification because you are a member of Ubuntu +> > Virtualisation team, which is subscribed to qemu in Ubuntu. +> > https://bugs.launchpad.net/bugs/1769053 +> > +> > Title: +> > Cannot start a guest with more than 1TB of RAM +> > +> > Status in QEMU: +> > Incomplete +> > Status in qemu package in Ubuntu: +> > Incomplete +> > +> > Bug description: +> > Attempting to start a KVM guest with more than 1TB of RAM fails. +> > +> > It looks like we might need some extra patches: +> > https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> > +> > ProblemType: Bug +> > DistroRelease: Ubuntu 18.04 +> > Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> > ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> > Uname: Linux 4.15.0-20-generic x86_64 +> > ApportVersion: 2.20.9-0ubuntu7 +> > Architecture: amd64 +> > CurrentDesktop: Unity:Unity7:ubuntu +> > Date: Fri May 4 16:21:14 2018 +> > InstallationDate: Installed on 2017-04-05 (393 days ago) +> > InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 +> > (20161012.2) +> > MachineType: Dell Inc. XPS 13 9360 +> > ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic +> > root=/dev/mapper/ubuntu--vg-root ro quiet splash +> > transparent_hugepage=madvise vt.handoff=1 +> > SourcePackage: qemu +> > UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> > dmi.bios.date: 02/26/2018 +> > dmi.bios.vendor: Dell Inc. +> > dmi.bios.version: 2.6.2 +> > dmi.board.name: 0PF86Y +> > dmi.board.vendor: Dell Inc. +> > dmi.board.version: A00 +> > dmi.chassis.type: 9 +> > dmi.chassis.vendor: Dell Inc. +> > dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.: +> > pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> > dmi.product.family: XPS +> > dmi.product.name: XPS 13 9360 +> > dmi.sys.vendor: Dell Inc. +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +> > +> +> +> -- +> Christian Ehrhardt +> Software Engineer, Ubuntu Server +> Canonical Ltd +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1769053 +> +> Title: +> Cannot start a guest with more than 1TB of RAM +> +> Status in QEMU: +> Incomplete +> Status in qemu package in Ubuntu: +> Incomplete +> +> Bug description: +> Attempting to start a KVM guest with more than 1TB of RAM fails. +> +> It looks like we might need some extra patches: +> https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> +> ProblemType: Bug +> DistroRelease: Ubuntu 18.04 +> Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> Uname: Linux 4.15.0-20-generic x86_64 +> ApportVersion: 2.20.9-0ubuntu7 +> Architecture: amd64 +> CurrentDesktop: Unity:Unity7:ubuntu +> Date: Fri May 4 16:21:14 2018 +> InstallationDate: Installed on 2017-04-05 (393 days ago) +> InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) +> MachineType: Dell Inc. XPS 13 9360 +> ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise vt.handoff=1 +> SourcePackage: qemu +> UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> dmi.bios.date: 02/26/2018 +> dmi.bios.vendor: Dell Inc. +> dmi.bios.version: 2.6.2 +> dmi.board.name: 0PF86Y +> dmi.board.vendor: Dell Inc. +> dmi.board.version: A00 +> dmi.chassis.type: 9 +> dmi.chassis.vendor: Dell Inc. +> dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> dmi.product.family: XPS +> dmi.product.name: XPS 13 9360 +> dmi.sys.vendor: Dell Inc. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +Hmm, if we know that QEMU guests will crash & burn when > 1 TB mem, when host-phys-bits/phys-bits are unset, then perhaps libvirt should do the right thing by default here. eg we can't use host-phys-bits=true due to migration compat issues, but if we see > 1TB mem, libvirt could reasonably set phys-bits=NNN for some suitable value of NNN. We should expose this in the XML config for the CPU explicitly too. + +* Daniel Berrange (<email address hidden>) wrote: +> Hmm, if we know that QEMU guests will crash & burn when > 1 TB mem, when +> host-phys-bits/phys-bits are unset, then perhaps libvirt should do the +> right thing by default here. eg we can't use host-phys-bits=true due to +> migration compat issues, but if we see > 1TB mem, libvirt could +> reasonably set phys-bits=NNN for some suitable value of NNN. We should +> expose this in the XML config for the CPU explicitly too. + +Yep: + a) It should be possible to add a setting to the XML to specify the + phys-bits + b) It should be possible for libvirt to check the host it's on can + satisfy that requirement + c) libvirt can check that if RAM > 2^phys-bits it can complain + +but + + d) For smaller amount of RAM it might still fail if +RAM+rounding+pci+hotplug space goes over the limit. + Figuring that limit out is tricky (and I thought it + might be BIOS/EFI dependent as well depending where they + decide to put their PCI devices) + +Dave + +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1769053 +> +> Title: +> Cannot start a guest with more than 1TB of RAM +> +> Status in QEMU: +> Incomplete +> Status in qemu package in Ubuntu: +> Incomplete +> +> Bug description: +> Attempting to start a KVM guest with more than 1TB of RAM fails. +> +> It looks like we might need some extra patches: +> https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> +> ProblemType: Bug +> DistroRelease: Ubuntu 18.04 +> Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> Uname: Linux 4.15.0-20-generic x86_64 +> ApportVersion: 2.20.9-0ubuntu7 +> Architecture: amd64 +> CurrentDesktop: Unity:Unity7:ubuntu +> Date: Fri May 4 16:21:14 2018 +> InstallationDate: Installed on 2017-04-05 (393 days ago) +> InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) +> MachineType: Dell Inc. XPS 13 9360 +> ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise vt.handoff=1 +> SourcePackage: qemu +> UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> dmi.bios.date: 02/26/2018 +> dmi.bios.vendor: Dell Inc. +> dmi.bios.version: 2.6.2 +> dmi.board.name: 0PF86Y +> dmi.board.vendor: Dell Inc. +> dmi.board.version: A00 +> dmi.chassis.type: 9 +> dmi.chassis.vendor: Dell Inc. +> dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> dmi.product.family: XPS +> dmi.product.name: XPS 13 9360 +> dmi.sys.vendor: Dell Inc. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + + Hi, + +> d) For smaller amount of RAM it might still fail if +> RAM+rounding+pci+hotplug space goes over the limit. +> Figuring that limit out is tricky (and I thought it +> might be BIOS/EFI dependent as well depending where they +> decide to put their PCI devices) + +Both seabios and ovmf try to not go too high in address space. Reason +is exactly the phys-bits issue. Using 40 here by default does not only +limit the memory to 1TB. It also has the problem that the guest thinks +it has 1TB of address space but in reality it might be less. Even +recent skylake machines have phys-bits=39 (512G) only, and trying to use +the physical address space above 512G in the guest just doesn't work +because the phys-bits=39 limit applies to EPT too. + +So checking phys-bits in the firmware, for example to place pci bars as +high as possible in physical address space, is not going to work. + +IIRC ovmf uses a 32G sized region with 32G alignment by default, which +will land below 64G (aka phys-bits=36 address space) unless the guest +has more than 30 (q35) or 31 (piix4) GB of memory. + +seabios will not map pci bars above 4G unless it runs out of space below +4G. If needed 64bit PCI bars will be placed right above ram, with +gigabyte alignment. + +cheers, + Gerd + + + +* Gerd Hoffmann (<email address hidden>) wrote: +> Hi, +> +> > d) For smaller amount of RAM it might still fail if +> > RAM+rounding+pci+hotplug space goes over the limit. +> > Figuring that limit out is tricky (and I thought it +> > might be BIOS/EFI dependent as well depending where they +> > decide to put their PCI devices) +> +> Both seabios and ovmf try to not go too high in address space. Reason +> is exactly the phys-bits issue. Using 40 here by default does not only +> limit the memory to 1TB. It also has the problem that the guest thinks +> it has 1TB of address space but in reality it might be less. Even +> recent skylake machines have phys-bits=39 (512G) only, and trying to use +> the physical address space above 512G in the guest just doesn't work +> because the phys-bits=39 limit applies to EPT too. +> +> So checking phys-bits in the firmware, for example to place pci bars as +> high as possible in physical address space, is not going to work. +> +> IIRC ovmf uses a 32G sized region with 32G alignment by default, which +> will land below 64G (aka phys-bits=36 address space) unless the guest +> has more than 30 (q35) or 31 (piix4) GB of memory. +> +> seabios will not map pci bars above 4G unless it runs out of space below +> 4G. If needed 64bit PCI bars will be placed right above ram, with +> gigabyte alignment. + +Yep, I was tempted to set host-phys-bits=true on upstream, but TCG +has a fixed 40 bits last time I looked. + +Dave + +> cheers, +> Gerd +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1769053 +> +> Title: +> Cannot start a guest with more than 1TB of RAM +> +> Status in QEMU: +> Incomplete +> Status in qemu package in Ubuntu: +> Incomplete +> +> Bug description: +> Attempting to start a KVM guest with more than 1TB of RAM fails. +> +> It looks like we might need some extra patches: +> https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html +> +> ProblemType: Bug +> DistroRelease: Ubuntu 18.04 +> Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7 +> ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 +> Uname: Linux 4.15.0-20-generic x86_64 +> ApportVersion: 2.20.9-0ubuntu7 +> Architecture: amd64 +> CurrentDesktop: Unity:Unity7:ubuntu +> Date: Fri May 4 16:21:14 2018 +> InstallationDate: Installed on 2017-04-05 (393 days ago) +> InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) +> MachineType: Dell Inc. XPS 13 9360 +> ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise vt.handoff=1 +> SourcePackage: qemu +> UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago) +> dmi.bios.date: 02/26/2018 +> dmi.bios.vendor: Dell Inc. +> dmi.bios.version: 2.6.2 +> dmi.board.name: 0PF86Y +> dmi.board.vendor: Dell Inc. +> dmi.board.version: A00 +> dmi.chassis.type: 9 +> dmi.chassis.vendor: Dell Inc. +> dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr: +> dmi.product.family: XPS +> dmi.product.name: XPS 13 9360 +> dmi.sys.vendor: Dell Inc. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +Crit prio on Qemu which was explained to work just fine is not correct IMHO. +After checking with David he meant to want to raise the prio on the suggested libvirt extensions instead. I'm re-triaging this bug for that and will ping David Berrange if work on this is already tracked on a libvirt-BZ or worked on in general. + +Actually the qemu tasks are "invalid" not "incomplete" as they currently are - after our discussions here it seems we agreed that qemu is doing what is intended (and the reasons why larger bits are not the default). Therefore set the status to that for the qemu tasks. + +Reported to upstream libvirt's BZ with the suggestions of Daniel Berrage and David Alan Glibert; now available at [1] I linked that up in the LP bug status so that we auto-track this. + +As eventually this has to go upstream using the bug tracker should better ensure that there is no concurrent conflicting work (or opinion) on it. + +[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1578278 + +Since all but the libvirt task to expose these are set to invalid in regard to the issue here I'm changing the title accordingly. + +As a short term solution for Ubuntu users I forked bug 1776189 to provide a machine type based solution until this here is implemented and widely available and exploited. + +Description of problem: +Based on a discussion about Qemus ability to work with Guests >1TB [1] it was identified that it might be wise to have libvirt be able to: + a) add a setting to the XML to specify the phys-bits + b) It should be possible for libvirt to check the host it's on can + satisfy that requirement (enough HW phys bits) + c) libvirt can check that if RAM > 2^phys-bits it can complain + +It is known that (c) can't catch all, as it might still fail if RAM+rounding+pci+hotplug space goes over the limit. Figuring that limit out is tricky and should not be part of the scope here. + +[1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1769053 + +Version-Release number of selected component (if applicable): +Up to latest 4.3 + +How reproducible: +100% - well it essentially is a feature request not an error + +Steps to Reproduce: +1. try to control phys-bits through libvirt xml/api + +Actual results: +No option exposed to do so. + +Expected results: +Be able to control phys-bits + +Additional info: +See the discussion on Launchpad [1] for more details of the qemu side of this. + +Hi + +We are hitting this bug. We have specialist hardwares including hi-memory hypervisors to run HPC workload on virtualised environment. This bug is affecting us at the machines which has more than 1TB of memory. + +(In reply to <email address hidden> from comment #1) +> Hi +> +> We are hitting this bug. We have specialist hardwares including hi-memory +> hypervisors to run HPC workload on virtualised environment. This bug is +> affecting us at the machines which has more than 1TB of memory. + +This bz# is not a bug, but a feature planned to make live migration ability more flexible. The option might be useful to work around bugs or other limitations, though. + +If you are seeing a bug related to large guests or large hosts, please send more details so we can investigate it. + +Hello. + +Recently I had to deal with a VM with ~2.7 TB of RAM. The [open]SUSE QEMU package carries a patch for bumping the default maximum virtual address bits to 42 (from 40). Now, the last entry of the VM's e820 was this one: + + BIOS-e820: [mem 0x0000000100000000-0x000002b57fffffff] usable + +Which, if I have computed correctly, is representable on 42 bits, so things should be fine. However, during boot, the VM shows this: + + L1TF: System has more than MAX_PA/2 memory. L1TF mitigation not effective + +And if I look in /sys/devices/system/cpu/vulnerabilities/l1tf, I see this: + + l1tf: Vulnerable + +This is because, while the RAM fits in MAX_PA=42, as soon as we take 1 bit off for PTE inversion, it does not fit any longer (in MAX_PA/2). + +I understand that this is not critical per-se, but I think it's rather annoying for a user to see messages like the ones above, especially considering they're about vulnerabilities and security. And it's not necessarily easy for everyone to realize that L1TF is reported as vulnerable because QEMU is making the VM think that physical addresses are on 42 (or 40) bits. + +So, I also think we need to be able to tweak this part of the VM configuration more easily, from libvirt. It's doable either by using specially modified CPU-models, or doing things like this, which are rather inconvenient: + + <qemu:commandline> + <qemu:arg value='-cpu'/> + <qemu:arg value='host,host-phys-bits=on'/> + </qemu:commandline> + +I also believe that host-phys-bits=on should be QEMU's default when the user chooses host as CPU model, but that's for another bugzilla. :-) + +While the bugzilla case wasn't updated this landed in v8.7.0 via a series around +https://gitlab.com/libvirt/libvirt/-/commit/e6c29f09e5b75d7a8d79ae670407060446282c78 + +v9.0.0 of libvirt is in Ubuntu Lunar, due to that - from now on - one can control the physical bit settings in a defined way through libvirt. + +See maxphysaddr in [1] for how to use that. + +Mid term Ubuntu will consider no more adding further variants of the workaround, that was providing machine types with the -hpb suffix to allow larger guests. + +[1]: https://libvirt.org/formatdomain.html#cpu-model-and-topology + diff --git a/results/classifier/zero-shot/108/permissions/1773753 b/results/classifier/zero-shot/108/permissions/1773753 new file mode 100644 index 000000000..64dd9023a --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1773753 @@ -0,0 +1,293 @@ +permissions: 0.943 +network: 0.943 +other: 0.928 +device: 0.927 +KVM: 0.909 +files: 0.907 +socket: 0.905 +performance: 0.893 +semantic: 0.885 +PID: 0.883 +vnc: 0.879 +graphic: 0.866 +debug: 0.833 +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/zero-shot/108/permissions/1782300 b/results/classifier/zero-shot/108/permissions/1782300 new file mode 100644 index 000000000..ffab6ccdb --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1782300 @@ -0,0 +1,120 @@ +permissions: 0.938 +graphic: 0.927 +debug: 0.924 +other: 0.922 +semantic: 0.918 +performance: 0.905 +device: 0.903 +PID: 0.878 +network: 0.876 +socket: 0.873 +boot: 0.870 +files: 0.843 +vnc: 0.823 +KVM: 0.789 + +COLO unable to failover to secondary VM + +I test COLO feature on my host following docs/COLO-FT.txt in qemu folder, but fail to failover to secondary VM. +Is there any mistake in my execution steps? + +Execution environment: +QEMU v2.12.0-rc4 +OS: Ubuntu 16.04.3 LTS +Kernel: Linux 4.4.35 +Secondary VM IP: noted as "a.b.c.d" + +Execution steps: +# Primary +${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \ + -enable-kvm \ + -m 512M \ + -smp 2 \ + -qmp stdio \ + -vnc :7 \ + -name primary \ + -device piix3-usb-uhci \ + -device usb-tablet \ + -netdev tap,id=tap0,vhost=off \ + -device virtio-net-pci,id=net-pci0,netdev=tap0 \ + -drive if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ + children.0.file.filename=${IMG_PATH},\ + children.0.driver=raw -S + +# Secondary +${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \ + -enable-kvm \ + -m 512M \ + -smp 2 \ + -qmp stdio \ + -vnc :8 \ + -name secondary \ + -device piix3-usb-uhci \ + -device usb-tablet \ + -netdev tap,id=tap1,vhost=off \ + -device virtio-net-pci,id=net-pci0,netdev=tap1 \ + -drive if=none,id=secondary-disk0,file.filename=${IMG_PATH},driver=raw,node-name=node0 \ + -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ + file.driver=qcow2,top-id=active-disk0,\ + file.file.filename=$ACTIVE_DISK,\ + file.backing.driver=qcow2,\ + file.backing.file.filename=$HIDDEN_DISK,\ + file.backing.backing=secondary-disk0 \ + -incoming tcp:0:8888 + +# Enter into Secondary: +{'execute':'qmp_capabilities'} +{ 'execute': 'nbd-server-start', + 'arguments': {'addr': {'type': 'inet', 'data': {'host': 'a.b.c.d', 'port': '8889'} } } +} +{'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', 'writable': true } } + +# Enter into Primary: +{'execute':'qmp_capabilities'} +{'execute': 'human-monitor-command', + 'arguments': { + 'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=a.b.c.d,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0' + } +} +{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', 'node': 'nbd_client0' } } +{ 'execute': 'migrate-set-capabilities', + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } +{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:a.b.c.d:8888' } } + +# To test failover +Primary +{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'primary-disk0', 'child': 'children.1'}} +{ 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del nbd_client0'}} + +Secondary +{ 'execute': 'nbd-server-stop' } + +Stop Primary +Send ^C signal to terminate PVM. + +Secondary +{ "execute": "x-colo-lost-heartbeat" } + + +# Result: +Primary (Use ^C to terminate) +qemu-system-x86_64: Can't receive COLO message: Input/output error +qemu-system-x86_64: terminating on signal 2 +{"timestamp": {"seconds": 1531815575, "microseconds": 997696}, "event": "SHUTDOWN", "data": {"guest":false}} + +Secondary +{ 'execute': 'nbd-server-stop' } +{"return": {}} +{ "execute": "x-colo-lost-heartbeat" } +{"return": {}} +qemu-system-x86_64: Can't receive COLO message: Input/output error +Segmentation fault + +I also meet the same problem. +Does anybody have solutions for this problem? + +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/zero-shot/108/permissions/1784900 b/results/classifier/zero-shot/108/permissions/1784900 new file mode 100644 index 000000000..388dc83c0 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1784900 @@ -0,0 +1,180 @@ +permissions: 0.964 +other: 0.956 +files: 0.944 +device: 0.943 +debug: 0.943 +graphic: 0.936 +boot: 0.936 +semantic: 0.935 +PID: 0.934 +socket: 0.934 +performance: 0.931 +KVM: 0.904 +network: 0.890 +vnc: 0.869 + +QEMU (frontend) crashes upon warm reboot with virtio-gpu device and vga=775 on Linux cmdline + +With vga=775 on the Linux command line a first boot of the VM running Linux works fine. After a warm reboot it crashes during Linux boot. The VM was used remotely via virt-manager and VNC. + +Bisecting the code lead to the following patch that introduced the bug: + +commit 1fccd7c5a9a722a9cbf1bc91693f4618034f01ac (HEAD, refs/bisect/bad) +Author: Gerd Hoffmann <email address hidden> +Date: Mon Jul 2 18:24:43 2018 +0200 + + virtio-gpu: disable scanout when backing resource is destroyed + + Signed-off-by: Gerd Hoffmann <email address hidden> + Reviewed-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + +diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c +index 336dc59007..08cd567218 100644 +--- a/hw/display/virtio-gpu.c ++++ b/hw/display/virtio-gpu.c +@@ -430,6 +430,16 @@ static void virtio_gpu_disable_scanout(VirtIOGPU *g, int scanout_id) + static void virtio_gpu_resource_destroy(VirtIOGPU *g, + struct virtio_gpu_simple_resource *res) + { ++ int i; ++ ++ if (res->scanout_bitmask) { ++ for (i = 0; i < g->conf.max_outputs; i++) { ++ if (res->scanout_bitmask & (1 << i)) { ++ virtio_gpu_disable_scanout(g, i); ++ } ++ } ++ } ++ + pixman_image_unref(res->image); + virtio_gpu_cleanup_mapping(res); + QTAILQ_REMOVE(&g->reslist, res, next); + + +Reported backtraces can be found here: https://paste.fedoraproject.org/paste/OUDEfCk1IY7xiy0I0PDlkw + +I also hit this with gtk frontend rather than vnc althought he backtrace looks very different. + +The reason for this bug is memory corruption in glibc's memory chunk header that is in front of some bitmap pixman is allocating and maintaining as image->bits.free_me. I set a memory watchpoint to this memory location and this code here triggered it and corrupted what seems to be a memory chunk size indicator, which upon free() causes print of 'invalid pointer' by glibc: + +Thread 1 "qemu-system-x86" hit Hardware watchpoint 2: *0x7f6160361d88 + +Old value = 3145749 +New value = 0 +vga_draw_line8 (vga=vga@entry=0x556d68549b30, d=0x7f6160361d80 "", d@entry=0x7f61603615e0 "", addr=983528, width=<optimized out>) + at /home/stefanb/tmp/qemu-tip/hw/display/vga-helpers.h:297 +297 ((uint32_t *)d)[3] = palette[vga_read_byte(vga, addr + 3)]; + + +(gdb) bt +#0 vga_draw_line8 (vga=vga@entry=0x556d68549b30, d=0x7f6160361d80 "", d@entry=0x7f61603615e0 "", addr=983528, width=<optimized out>) + at /home/stefanb/tmp/qemu-tip/hw/display/vga-helpers.h:297 +#1 0x0000556d659918ee in vga_draw_graphic (full_update=0, s=0x556d68549b30) at /home/stefanb/tmp/qemu-tip/hw/display/vga.c:1695 +#2 vga_update_display (opaque=0x556d68549b30) at /home/stefanb/tmp/qemu-tip/hw/display/vga.c:1782 +#3 0x0000556d65c0cd92 in vnc_refresh (dcl=0x556d683055a8) at ui/vnc.c:3046 +#4 0x0000556d65bff702 in dpy_refresh (s=0x556d686be540) at ui/console.c:1658 +#5 gui_update (opaque=0x556d686be540) at ui/console.c:205 +#6 0x0000556d65d0deac in timerlist_run_timers (timer_list=0x556d66de0e00) at util/qemu-timer.c:536 +#7 0x0000556d65d0e0f7 in qemu_clock_run_timers (type=QEMU_CLOCK_REALTIME) at util/qemu-timer.c:547 +#8 qemu_clock_run_all_timers () at util/qemu-timer.c:674 +#9 0x0000556d65d0e5d1 in main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:503 +#10 0x0000556d65a5f2ee in main_loop () at vl.c:1865 +#11 0x0000556d658ff166 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4643 + + +This patch here fixes the issue, but is likely introducing inefficiency. There are two if statements above the patch that should set full_update = 1 due to 'some change', but none of them triggers it. So I think the surface is wrong and needs to be recreated. + +diff --git a/hw/display/vga.c b/hw/display/vga.c +index ed476e4e80..71b5684994 100644 +--- a/hw/display/vga.c ++++ b/hw/display/vga.c +@@ -1571,6 +1571,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + * must be updated with the new base address */ + full_update = 1; + } ++ full_update = 1; + + if (full_update) { + if (share_surface) { + + +A better solution may be this one here: + +diff --git a/hw/display/vga.c b/hw/display/vga.c +index ed476e4e80..4f365b6d43 100644 +--- a/hw/display/vga.c ++++ b/hw/display/vga.c +@@ -1566,7 +1566,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + full_update = 1; + } + if (surface_data(surface) != s->vram_ptr + (s->start_addr * 4) +- && is_buffer_shared(surface)) { ++ /*&& is_buffer_shared(surface)*/) { + /* base address changed (page flip) -> shared display surfaces + * must be updated with the new base address */ + full_update = 1; + + +Another patch that seems to work tries to remember the old surface: + +diff --git a/hw/display/vga.c b/hw/display/vga.c +index ed476e4e80..1aae6a6d3b 100644 +--- a/hw/display/vga.c ++++ b/hw/display/vga.c +@@ -1554,7 +1554,8 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + height != s->last_height || + s->last_depth != depth || + s->last_byteswap != byteswap || +- share_surface != is_buffer_shared(surface)) { ++ share_surface != is_buffer_shared(surface) || ++ s->last_surface != surface) { + /* display parameters changed -> need new display surface */ + s->last_scr_width = disp_width; + s->last_scr_height = height; +@@ -1563,8 +1564,10 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + s->last_line_offset = s->line_offset; + s->last_depth = depth; + s->last_byteswap = byteswap; ++ s->last_surface = surface; + full_update = 1; + } ++ fprintf(stderr, "%p vs %p share_surface: %d surface: %p\n", surface_data(surface), s->vram_ptr + (s->start_addr * 4), share_surface, surface); + if (surface_data(surface) != s->vram_ptr + (s->start_addr * 4) + && is_buffer_shared(surface)) { + /* base address changed (page flip) -> shared display surfaces +diff --git a/hw/display/vga_int.h b/hw/display/vga_int.h +index f8fcf62a56..91afc52b0e 100644 +--- a/hw/display/vga_int.h ++++ b/hw/display/vga_int.h +@@ -122,6 +122,7 @@ typedef struct VGACommonState { + uint32_t last_width, last_height; /* in chars or pixels */ + uint32_t last_scr_width, last_scr_height; /* in pixels */ + uint32_t last_depth; /* in bits */ ++ void *last_surface; + bool last_byteswap; + bool force_shadow; + uint8_t cursor_start, cursor_end; + + +On my system vga_draw_graphic is called with a surface_width(surface) = 1280, the next time surface_width(surface) = 1024, and then the next time again with surface_width(surface) = 1280. So it's a quick resolution change. Each time the surface pointer changes as well as surface_width(surface) and surface_data(surface). Do NOT try to access the s->last_surface with surface_data(s->last_surface) -- it likely has been freed already. + +So my guess is we could add (a subset of) checks like this one here: + +if (s->last_surface != surface || + s->last_surface_width != surface_width(surface) || + s->last_surface_height != surface_height(surface) || + s->last_surface_data != surface_data(surface)) { + + s->last_surface = surface; + s->last_surface_width = surface_width(surface); + ... + full_update = 1; +} + + +see also "[PATCH] virtio-gpu: fix crashes upon warm reboot with vga mode" for a potential fix + +Fix has been added here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=93f874fe9dbe0b997b5a94 + diff --git a/results/classifier/zero-shot/108/permissions/1787754 b/results/classifier/zero-shot/108/permissions/1787754 new file mode 100644 index 000000000..ba98f0904 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1787754 @@ -0,0 +1,116 @@ +permissions: 0.985 +graphic: 0.981 +performance: 0.963 +other: 0.955 +socket: 0.947 +files: 0.941 +semantic: 0.940 +debug: 0.939 +PID: 0.939 +device: 0.932 +network: 0.918 +boot: 0.909 +vnc: 0.903 +KVM: 0.800 + +qemu sparc -cpu help does not generate correct display + +The output for the "-cpu help" on the Sparc executables is not generating accurate information. + +Running + +./qemu-sparc64 -cpu help + +produces: + +Sparc Fujitsu Sparc64 IU 0004000200000000 FPU 00000000 MMU 00000000 NWINS 4 +Sparc Fujitsu Sparc64 III IU 0004000300000000 FPU 00000000 MMU 00000000 NWINS 5 +Sparc Fujitsu Sparc64 IV IU 0004000400000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc Fujitsu Sparc64 V IU 0004000551000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc TI UltraSparc I IU 0017001040000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc TI UltraSparc II IU 0017001120000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc TI UltraSparc IIi IU 0017001291000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc TI UltraSparc IIe IU 0017001314000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc Sun UltraSparc III IU 003e001434000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc Sun UltraSparc III Cu IU 003e001541000000 FPU 00000000 MMU 00000001 NWINS 8 +Sparc Sun UltraSparc IIIi IU 003e001634000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc Sun UltraSparc IV IU 003e001831000000 FPU 00000000 MMU 00000002 NWINS 8 +Sparc Sun UltraSparc IV+ IU 003e001922000000 FPU 00000000 MMU 00000000 NWINS 8 +cmt +Sparc Sun UltraSparc IIIi+ IU 003e002200000000 FPU 00000000 MMU 00000001 NWINS 8 +Sparc Sun UltraSparc T1 IU 003e002302000000 FPU 00000000 MMU 00000003 NWINS 8 +hypv +cmt +gl +Sparc Sun UltraSparc T2 IU 003e002402000000 FPU 00000000 MMU 00000003 NWINS 8 +hypv +cmt +gl +Sparc NEC UltraSparc I IU 0022001040000000 FPU 00000000 MMU 00000000 NWINS 8 +Default CPU feature flags (use '-' to remove): float swap mul div flush fsqrt fmul vis1 vis2 fsmuld +Available CPU feature flags (use '+' to add): float128 hypv cmt gl +Numerical features (use '=' to set): iu_version fpu_version mmu_version nwindows + +The entries appear to supposed to be (partial list from source code): + +TI-SuperSparc-II +TI-SuperSparc-II +TI-SuperSparc-II +TI-MicroSparc-I +TI-MicroSparc-I +TI-MicroSparc-I +Sun-UltraSparc-T1 +TI-UltraSparc-IIi +Sun-UltraSparc-T1 + +The output is from qemu 2.12.0. + +On Sat, Aug 18, 2018 at 8:56 PM Donald R Laster Jr +<email address hidden> wrote: +> +> Public bug reported: +> +> The output for the "-cpu help" on the Sparc executables is not +> generating accurate information. +> +> Running +> +> ./qemu-sparc64 -cpu help +> +> produces: +> +> Sparc Fujitsu Sparc64 IU 0004000200000000 FPU 00000000 MMU 00000000 NWINS 4 +> Sparc Fujitsu Sparc64 III IU 0004000300000000 FPU 00000000 MMU 00000000 NWINS 5 +> Sparc Fujitsu Sparc64 IV IU 0004000400000000 FPU 00000000 MMU 00000000 NWINS 8 +> Sparc Fujitsu Sparc64 V IU 0004000551000000 FPU 00000000 MMU 00000000 NWINS 8 +> Sparc TI UltraSparc I IU 0017001040000000 FPU 00000000 MMU 00000000 NWINS 8 +> Sparc TI UltraSparc II IU 0017001120000000 FPU 00000000 MMU 00000000 NWINS 8 +> Sparc TI UltraSparc IIi IU 0017001291000000 FPU 00000000 MMU 00000000 NWINS 8 +> Sparc TI UltraSparc IIe IU 0017001314000000 FPU 00000000 MMU 00000000 NWINS 8 +> Sparc Sun UltraSparc III IU 003e001434000000 FPU 00000000 MMU 00000000 NWINS 8 +> Sparc Sun UltraSparc III Cu IU 003e001541000000 FPU 00000000 MMU 00000001 NWINS 8 +> Sparc Sun UltraSparc IIIi IU 003e001634000000 FPU 00000000 MMU 00000000 NWINS 8 +> Sparc Sun UltraSparc IV IU 003e001831000000 FPU 00000000 MMU 00000002 NWINS 8 +> Sparc Sun UltraSparc IV+ IU 003e001922000000 FPU 00000000 MMU 00000000 NWINS 8 +cmt +> Sparc Sun UltraSparc IIIi+ IU 003e002200000000 FPU 00000000 MMU 00000001 NWINS 8 +> Sparc Sun UltraSparc T1 IU 003e002302000000 FPU 00000000 MMU 00000003 NWINS 8 +hypv +cmt +gl +> Sparc Sun UltraSparc T2 IU 003e002402000000 FPU 00000000 MMU 00000003 NWINS 8 +hypv +cmt +gl +> Sparc NEC UltraSparc I IU 0022001040000000 FPU 00000000 MMU 00000000 NWINS 8 +> Default CPU feature flags (use '-' to remove): float swap mul div flush fsqrt fmul vis1 vis2 fsmuld +> Available CPU feature flags (use '+' to add): float128 hypv cmt gl +> Numerical features (use '=' to set): iu_version fpu_version mmu_version nwindows +> +> The entries appear to supposed to be (partial list from source code): +> +> TI-SuperSparc-II +> TI-SuperSparc-II +> TI-SuperSparc-II +> TI-MicroSparc-I +> TI-MicroSparc-I +> TI-MicroSparc-I +> Sun-UltraSparc-T1 +> TI-UltraSparc-IIi +> Sun-UltraSparc-T1 +> +The T1 entries are in the list above. The Micro- and Super- SPARC +entries are not supposed to be there because they are 32 bit CPUs and +thus not compatible with qemu-sparc64. +Works as designed. + +Regards, +Artyom + + diff --git a/results/classifier/zero-shot/108/permissions/1790268 b/results/classifier/zero-shot/108/permissions/1790268 new file mode 100644 index 000000000..f09af9d80 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1790268 @@ -0,0 +1,46 @@ +permissions: 0.983 +device: 0.975 +socket: 0.967 +files: 0.966 +other: 0.965 +PID: 0.955 +graphic: 0.947 +performance: 0.942 +network: 0.940 +debug: 0.924 +vnc: 0.906 +boot: 0.888 +semantic: 0.826 +KVM: 0.735 + +the vhd generated by qemu-img not align with MB again. + +I'm using this version on xenial, +andy@bastion:~/temp$ qemu-img -h +qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31), Copyright (c) 2004-2008 Fabrice Bellard + +steps to repro: + +dd if=/dev/zero of=/tmp/azure_config_disk_image20180901-22672-16zxelu bs=1048576 count=24 +mkfs.ext4 -F /tmp/azure_config_disk_image20180901-22672-16zxelu -L azure_cfg_dsk +sudo -n mount -o loop /tmp/azure_config_disk_image20180901-22672-16zxelu /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +sudo -n chown andy /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +mkdir -p /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat/configs +sudo -n umount /tmp/azure_config_disk_mount66c11d7a-5f2b-4ed5-b959-3b48dbc42a2a20180901-22672-1ejreat +qemu-img convert -f raw -O vpc -o subformat=fixed,force_size /tmp/azure_config_disk_image20180901-22672-16zxelu papapa2.vhd + +unfortunately the papapa2.vhd size is 25166336!=25165824 which means it's not aligned in MiB. + +could you please help? + +last bug report and fixed is https://bugs.launchpad.net/qemu/+bug/1490611 + +and even the format is raw: +andy@bastion:~/temp$ qemu-img info papapa2.vhd +image: papapa2.vhd +file format: raw +virtual size: 24M (25166336 bytes) +disk size: 152K + +It is -o subformat=fixed which breaks the file format detection + diff --git a/results/classifier/zero-shot/108/permissions/1798451 b/results/classifier/zero-shot/108/permissions/1798451 new file mode 100644 index 000000000..52d89fda8 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1798451 @@ -0,0 +1,604 @@ +permissions: 0.937 +graphic: 0.920 +semantic: 0.911 +device: 0.900 +performance: 0.899 +other: 0.885 +boot: 0.884 +debug: 0.881 +PID: 0.880 +vnc: 0.876 +files: 0.866 +socket: 0.862 +network: 0.854 +KVM: 0.819 + +MMX emulation is missing on HVF Acceleration + + +Robs-MacBook-Pro-2:~ robmaskell$ qemu-system-x86_64 --version +QEMU emulator version 3.0.0 + +Host: MacOS - 10.13.6 + Model Name: MacBook Pro + Model Identifier: MacBookPro14,3 + Processor Name: Intel Core i7 + Processor Speed: 2.8 GHz + Number of Processors: 1 + Total Number of Cores: 4 + L2 Cache (per Core): 256 KB + L3 Cache: 6 MB + Memory: 16 GB + +Guest OS: Elementary Linux Loki 0.4.1, patched up to date + +Command used to start QEMU: + +qemu-system-x86_64 \ + -name ElementaryLokiDev \ + -machine pc,accel=hvf \ + -cpu max \ + -smp cpus=2,sockets=2,cores=1,threads=1,maxcpus=2 \ + -numa node,nodeid=0 \ + -numa cpu,node-id=0,socket-id=0 -numa cpu,node-id=0,socket-id=1 \ + -m 8G \ + -vga vmware \ + -hda e4.qcow2 + +Symptoms: Started without the -smp / -numa commands to install the OS, then added -smp / -numa and the machine boots and lscpu reports extra cpu as expected. Restart VM and it hangs on startup. Remove -smp / -numa and machine starts again. + +I've had issues with multiple vcpus previously. + +But I've tried that recently and it worked fine with the fix: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03864.html. + +And I've checked your command, no issues. + +Could you please try to install qemu from my tap and check if it's gone? + +brew tap roolebo/virt +brew install roolebo/virt/qemu --HEAD + + + +Thanks for replying Roman, I switched to your tap but even before that I'm not struggling to get the machines to boot even without the smp/numa lines... vga std flashes a lot then hangs with a black screen and a blinking cursor whereas vga vmware quite unexpectedly. + +Command to start QEMU: + +qemu-system-x86_64 \ + -name Elementary4Dev \ + -machine pc,accel=hvf \ + -cpu max \ + -m 8G \ + -vga vmware \ + -drive file=elem4.qcow2,format=qcow2,media=disk -boot d \ + -cdrom ../VMImages/elementaryos-0.4.1-stable.20180214.iso + +I tried the Elementary 0.4.1 and the new just released 5.0 and I get this... also tried cpu host but no luck. It's weird as single cpu was working the other day but stopped working on QEMU 3.0 before I switched to your tap. + +Process: qemu-system-x86_64 [716] +Path: /usr/local/bin/qemu-system-x86_64 +Identifier: qemu-system-x86_64 +Version: 0 +Code Type: X86-64 (Native) +Parent Process: ??? [713] +Responsible: qemu-system-x86_64 [716] +User ID: 501 + +Date/Time: 2018-10-20 20:58:31.473 +0100 +OS Version: Mac OS X 10.13.6 (17G65) +Report Version: 12 +Bridge OS Version: 3.0 (14Y664) +Anonymous UUID: A83DA3FD-C7C9-DAD6-4F7D-E36F1E90F993 + + +Time Awake Since Boot: 1200 seconds + +System Integrity Protection: enabled + +Crashed Thread: 5 + +Exception Type: EXC_CRASH (SIGABRT) +Exception Codes: 0x0000000000000000, 0x0000000000000000 +Exception Note: EXC_CORPSE_NOTIFY + +Application Specific Information: +abort() called + +Thread 0:: Dispatch queue: com.apple.main-thread +0 libsystem_kernel.dylib 0x00007fff65ad5cf2 __select + 10 +1 libglib-2.0.0.dylib 0x00000001036ae359 g_poll + 407 +2 qemu-system-x86_64 0x0000000102d53bb6 0x1029a8000 + 3849142 +3 qemu-system-x86_64 0x0000000102af1c3e 0x1029a8000 + 1350718 +4 qemu-system-x86_64 0x0000000102aef736 0x1029a8000 + 1341238 +5 qemu-system-x86_64 0x0000000102c684ee 0x1029a8000 + 2884846 +6 com.apple.CoreFoundation 0x00007fff3db57edc __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 +7 com.apple.CoreFoundation 0x00007fff3db57daa _CFXRegistrationPost + 458 +8 com.apple.CoreFoundation 0x00007fff3db57ae1 ___CFXNotificationPost_block_invoke + 225 +9 com.apple.CoreFoundation 0x00007fff3db15880 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1664 +10 com.apple.CoreFoundation 0x00007fff3db149b7 _CFXNotificationPost + 599 +11 com.apple.Foundation 0x00007fff3fc248c7 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 +12 com.apple.AppKit 0x00007fff3b210206 -[NSApplication _postDidFinishNotification] + 313 +13 com.apple.AppKit 0x00007fff3b20fe4f -[NSApplication _sendFinishLaunchingNotification] + 220 +14 com.apple.AppKit 0x00007fff3b0e2ab3 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 562 +15 com.apple.AppKit 0x00007fff3b0e26e9 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 690 +16 com.apple.Foundation 0x00007fff3fc67714 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 287 +17 com.apple.Foundation 0x00007fff3fc67592 _NSAppleEventManagerGenericHandler + 102 +18 com.apple.AE 0x00007fff3ec40dd0 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 1788 +19 com.apple.AE 0x00007fff3ec40677 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 41 +20 com.apple.AE 0x00007fff3ec40565 aeProcessAppleEvent + 383 +21 com.apple.HIToolbox 0x00007fff3ce3c4a0 AEProcessAppleEvent + 55 +22 com.apple.AppKit 0x00007fff3b0ddd32 _DPSNextEvent + 2788 +23 com.apple.AppKit 0x00007fff3b873e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 +24 com.apple.AppKit 0x00007fff3b0d2885 -[NSApplication run] + 764 +25 qemu-system-x86_64 0x0000000102c69ea1 0x1029a8000 + 2891425 +26 libdyld.dylib 0x00007fff65985015 start + 1 + +Thread 1: +0 libsystem_kernel.dylib 0x00007fff65ad5a16 __psynch_cvwait + 10 +1 libsystem_pthread.dylib 0x00007fff65c9e589 _pthread_cond_wait + 732 +2 qemu-system-x86_64 0x0000000102d56db1 0x1029a8000 + 3861937 +3 qemu-system-x86_64 0x0000000102d65659 0x1029a8000 + 3921497 +4 libsystem_pthread.dylib 0x00007fff65c9d661 _pthread_body + 340 +5 libsystem_pthread.dylib 0x00007fff65c9d50d _pthread_start + 377 +6 libsystem_pthread.dylib 0x00007fff65c9cbf9 thread_start + 13 + +Thread 2: +0 libsystem_kernel.dylib 0x00007fff65ad628a __workq_kernreturn + 10 +1 libsystem_pthread.dylib 0x00007fff65c9d009 _pthread_wqthread + 1035 +2 libsystem_pthread.dylib 0x00007fff65c9cbe9 start_wqthread + 13 + +Thread 3: +0 libsystem_kernel.dylib 0x00007fff65ad5cf2 __select + 10 +1 libglib-2.0.0.dylib 0x00000001036ae359 g_poll + 407 +2 qemu-system-x86_64 0x0000000102d547eb 0x1029a8000 + 3852267 +3 qemu-system-x86_64 0x0000000102ae7638 0x1029a8000 + 1308216 +4 libsystem_pthread.dylib 0x00007fff65c9d661 _pthread_body + 340 +5 libsystem_pthread.dylib 0x00007fff65c9d50d _pthread_start + 377 +6 libsystem_pthread.dylib 0x00007fff65c9cbf9 thread_start + 13 + +Thread 4: +0 libsystem_kernel.dylib 0x00007fff65ad603a __sigwait + 10 +1 libsystem_pthread.dylib 0x00007fff65c9fad9 sigwait + 61 +2 qemu-system-x86_64 0x0000000102d54d9a 0x1029a8000 + 3853722 +3 libsystem_pthread.dylib 0x00007fff65c9d661 _pthread_body + 340 +4 libsystem_pthread.dylib 0x00007fff65c9d50d _pthread_start + 377 +5 libsystem_pthread.dylib 0x00007fff65c9cbf9 thread_start + 13 + +Thread 5 Crashed: +0 libsystem_kernel.dylib 0x00007fff65ad5b66 __pthread_kill + 10 +1 libsystem_pthread.dylib 0x00007fff65ca0080 pthread_kill + 333 +2 libsystem_c.dylib 0x00007fff65a311ae abort + 127 +3 qemu-system-x86_64 0x0000000102adcfa1 0x1029a8000 + 1265569 +4 qemu-system-x86_64 0x0000000102adbab4 0x1029a8000 + 1260212 +5 qemu-system-x86_64 0x0000000102adb3fa 0x1029a8000 + 1258490 +6 qemu-system-x86_64 0x0000000102ada385 0x1029a8000 + 1254277 +7 qemu-system-x86_64 0x0000000102ad5963 0x1029a8000 + 1235299 +8 qemu-system-x86_64 0x00000001029ec5ae 0x1029a8000 + 279982 +9 libsystem_pthread.dylib 0x00007fff65c9d661 _pthread_body + 340 +10 libsystem_pthread.dylib 0x00007fff65c9d50d _pthread_start + 377 +11 libsystem_pthread.dylib 0x00007fff65c9cbf9 thread_start + 13 + +Thread 6:: com.apple.NSEventThread +0 libsystem_kernel.dylib 0x00007fff65acc20a mach_msg_trap + 10 +1 libsystem_kernel.dylib 0x00007fff65acb724 mach_msg + 60 +2 com.apple.CoreFoundation 0x00007fff3db43785 __CFRunLoopServiceMachPort + 341 +3 com.apple.CoreFoundation 0x00007fff3db42ad7 __CFRunLoopRun + 1783 +4 com.apple.CoreFoundation 0x00007fff3db42153 CFRunLoopRunSpecific + 483 +5 com.apple.AppKit 0x00007fff3b21afc4 _NSEventThread + 184 +6 libsystem_pthread.dylib 0x00007fff65c9d661 _pthread_body + 340 +7 libsystem_pthread.dylib 0x00007fff65c9d50d _pthread_start + 377 +8 libsystem_pthread.dylib 0x00007fff65c9cbf9 thread_start + 13 + +Thread 7: +0 libsystem_kernel.dylib 0x00007fff65ad628a __workq_kernreturn + 10 +1 libsystem_pthread.dylib 0x00007fff65c9d009 _pthread_wqthread + 1035 +2 libsystem_pthread.dylib 0x00007fff65c9cbe9 start_wqthread + 13 + +Thread 8: +0 libsystem_kernel.dylib 0x00007fff65ad628a __workq_kernreturn + 10 +1 libsystem_pthread.dylib 0x00007fff65c9d20e _pthread_wqthread + 1552 +2 libsystem_pthread.dylib 0x00007fff65c9cbe9 start_wqthread + 13 + +Thread 9: +0 libsystem_kernel.dylib 0x00007fff65ad5a16 __psynch_cvwait + 10 +1 libsystem_pthread.dylib 0x00007fff65c9e589 _pthread_cond_wait + 732 +2 qemu-system-x86_64 0x0000000102d56b2a 0x1029a8000 + 3861290 +3 qemu-system-x86_64 0x0000000102d52a3b 0x1029a8000 + 3844667 +4 libsystem_pthread.dylib 0x00007fff65c9d661 _pthread_body + 340 +5 libsystem_pthread.dylib 0x00007fff65c9d50d _pthread_start + 377 +6 libsystem_pthread.dylib 0x00007fff65c9cbf9 thread_start + 13 + +Thread 5 crashed with X86 Thread State (64-bit): + rax: 0x0000000000000000 rbx: 0x000070000f325000 rcx: 0x000070000f324c38 rdx: 0x0000000000000000 + rdi: 0x0000000000007803 rsi: 0x0000000000000006 rbp: 0x000070000f324c70 rsp: 0x000070000f324c38 + r8: 0x00007fff9e476f78 r9: 0x0000000000000040 r10: 0x0000000000000000 r11: 0x0000000000000206 + r12: 0x0000000000007803 r13: 0x00007f9b4a864400 r14: 0x0000000000000006 r15: 0x000000000000002d + rip: 0x00007fff65ad5b66 rfl: 0x0000000000000206 cr2: 0x00007fff9e475168 + +Logical CPU: 0 +Error Code: 0x02000148 +Trap Number: 133 + + +Binary Images: + 0x1029a8000 - 0x10302cff7 +qemu-system-x86_64 (0) <B403B322-7D8A-314E-8603-87BE55E2B497> /usr/local/bin/qemu-system-x86_64 + 0x1033aa000 - 0x1033e4ff3 +libncursesw.6.dylib (0) <20A2D861-87A5-3B8A-90DE-55BA26EC70DA> /usr/local/opt/ncurses/lib/libncursesw.6.dylib + 0x1033f7000 - 0x10346dff7 +libpixman-1.0.dylib (0) <8D85DEAA-9C08-3BD5-9D6D-99BAD7F1D504> /usr/local/opt/pixman/lib/libpixman-1.0.dylib + 0x103489000 - 0x1034acfff +libpng16.16.dylib (0) <621C81BB-39E7-3301-9D31-307112D1DC55> /usr/local/opt/libpng/lib/libpng16.16.dylib + 0x1034b9000 - 0x1034e5ff7 +libjpeg.9.dylib (0) <C76CAB50-100A-3873-9E2E-7861B0C9D8C4> /usr/local/opt/jpeg/lib/libjpeg.9.dylib + 0x1034ef000 - 0x103515ffb +libnettle.6.dylib (0) <2B221011-3E71-3BA4-ADE4-0C6EC6196E21> /usr/local/opt/nettle/lib/libnettle.6.dylib + 0x103524000 - 0x103626fe7 +libgnutls.30.dylib (0) <A3EDF8A2-A796-3ACE-A130-185C681C2C56> /usr/local/opt/gnutls/lib/libgnutls.30.dylib + 0x103668000 - 0x10366bfff +libgthread-2.0.0.dylib (0) <D695C8FD-A4F0-343A-AA62-A37DCB9D817D> /usr/local/opt/glib/lib/libgthread-2.0.0.dylib + 0x103672000 - 0x103742ff3 +libglib-2.0.0.dylib (0) <59AAEC33-B877-3DE1-A485-B4E711C33408> /usr/local/opt/glib/lib/libglib-2.0.0.dylib + 0x103769000 - 0x103771ff7 +libintl.8.dylib (0) <2BE4B1C7-92C9-39E9-B4A7-F880907047DB> /usr/local/opt/gettext/lib/libintl.8.dylib + 0x103777000 - 0x10381eff3 +libp11-kit.0.dylib (0) <BBD76BEB-F58A-3516-B047-93BDFA31A3F0> /usr/local/opt/p11-kit/lib/libp11-kit.0.dylib + 0x10386e000 - 0x1039d1fff +libunistring.2.dylib (0) <A4545916-E2F4-3D6A-862B-528A6806E9FC> /usr/local/opt/libunistring/lib/libunistring.2.dylib + 0x1039e9000 - 0x1039f4fff +libtasn1.6.dylib (0) <A39E91B7-03B4-3674-9F21-00CED14D080E> /usr/local/opt/libtasn1/lib/libtasn1.6.dylib + 0x1039fa000 - 0x103a22fff +libhogweed.4.dylib (0) <DF0DE14F-2A23-378D-BF21-60DADF53911C> /usr/local/opt/nettle/lib/libhogweed.4.dylib + 0x103a2e000 - 0x103a8afcf +libgmp.10.dylib (0) <7D2A1AB0-B206-3196-954C-5A0E17049998> /usr/local/opt/gmp/lib/libgmp.10.dylib + 0x103a98000 - 0x103a9cfff +libffi.6.dylib (0) <47F6B233-3552-3D42-A3EC-1917E141AC53> /usr/local/opt/libffi/lib/libffi.6.dylib + 0x103aa1000 - 0x103b04ff3 +libpcre.1.dylib (0) <5B4FAAF7-7EC4-36BB-B62E-57DE5F60AB9A> /usr/local/opt/pcre/lib/libpcre.1.dylib + 0x1096fc000 - 0x109833fff com.apple.AMDMTLBronzeDriver (1.68.20 - 1.6.8) <C5D6A803-7CE1-32BD-BE34-C518131CED8B> /System/Library/Extensions/AMDMTLBronzeDriver.bundle/Contents/MacOS/AMDMTLBronzeDriver + 0x10d6db000 - 0x10d725acf dyld (551.4) <8A72DE9C-A136-3506-AA02-4BA2B82DCAF3> /usr/lib/dyld + 0x7fff37a57000 - 0x7fff37c42fff com.apple.driver.AppleIntelKBLGraphicsMTLDriver (10.36.19 - 10.3.6) <A5C358C5-A4EC-3726-A7EB-49300B599A2D> /System/Library/Extensions/AppleIntelKBLGraphicsMTLDriver.bundle/Contents/MacOS/AppleIntelKBLGraphicsMTLDriver + 0x7fff3a036000 - 0x7fff3a036fff com.apple.Accelerate (1.11 - Accelerate 1.11) <8632A9C5-19EA-3FD7-A44D-80765CC9C540> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate + 0x7fff3a037000 - 0x7fff3a04dfef libCGInterfaces.dylib (417.2) <2E67702C-75F6-308A-A023-F28120BEE667> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/Libraries/libCGInterfaces.dylib + 0x7fff3a04e000 - 0x7fff3a54cfc3 com.apple.vImage (8.1 - ???) <A243A7EF-0C8E-3A9A-AA38-44AFD7507F00> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage + 0x7fff3a54d000 - 0x7fff3a6a7fe3 libBLAS.dylib (1211.50.2) <62C659EB-3E32-3B5F-83BF-79F5DF30D5CE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib + 0x7fff3a6a8000 - 0x7fff3a6d6fef libBNNS.dylib (38.1) <7BAEFDCA-3227-3E07-80D8-59B6370B89C6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib + 0x7fff3a6d7000 - 0x7fff3aa96ff7 libLAPACK.dylib (1211.50.2) <40ADBA5F-8B2D-30AC-A7AD-7B17C37EE52D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib + 0x7fff3aa97000 - 0x7fff3aaacff7 libLinearAlgebra.dylib (1211.50.2) <E8E0B7FD-A0B7-31E5-AF01-81781F71EBBE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib + 0x7fff3aaad000 - 0x7fff3aab2ff3 libQuadrature.dylib (3) <3D6BF66A-55B2-3692-BAC7-DEB0C676ED29> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib + 0x7fff3aab3000 - 0x7fff3ab33fff libSparse.dylib (79.50.2) <0DC25CDD-F8C1-3D6E-B472-8B060708424F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib + 0x7fff3ab34000 - 0x7fff3ab47fff libSparseBLAS.dylib (1211.50.2) <722573CC-31CC-34B2-9032-E4F652A9CCFE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib + 0x7fff3ab48000 - 0x7fff3acf5fc3 libvDSP.dylib (622.50.5) <40690941-CF89-3F90-A0AC-A4D200744A5D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib + 0x7fff3acf6000 - 0x7fff3ada7fff libvMisc.dylib (622.50.5) <BA2532DF-2D68-3DD0-9B59-D434BF702AA4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib + 0x7fff3ada8000 - 0x7fff3ada8fff com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <54FF3B43-E66C-3F36-B34B-A2B3B0A36502> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib + 0x7fff3b09c000 - 0x7fff3befafff com.apple.AppKit (6.9 - 1561.60.100) <3C27CF6F-E640-3411-A87D-CCB2222CC754> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit + 0x7fff3bf4c000 - 0x7fff3bf4cfff com.apple.ApplicationServices (48 - 50) <AFFBD94A-AF76-336E-B53E-57524EAE8EF3> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices + 0x7fff3bf4d000 - 0x7fff3bfb3fff com.apple.ApplicationServices.ATS (377 - 445.4) <85E779EE-0219-3181-B4C4-201E4CC82AB5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS + 0x7fff3c04c000 - 0x7fff3c16efff libFontParser.dylib (222.1.6) <6CEBACDD-B848-302E-B4B2-630CB16E663E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib + 0x7fff3c16f000 - 0x7fff3c1b9ff7 libFontRegistry.dylib (221.4) <5FDB4F1A-E15C-3ACB-A5C1-F15458C0C6DC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib + 0x7fff3c25e000 - 0x7fff3c291ff7 libTrueTypeScaler.dylib (222.1.6) <9147F859-8BD9-31D9-AB54-8E9549B92AE9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib + 0x7fff3c2fb000 - 0x7fff3c2ffff3 com.apple.ColorSyncLegacy (4.13.0 - 1) <A5FB2694-1559-34A8-A3D3-2029F68A63CA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/ColorSyncLegacy + 0x7fff3c39f000 - 0x7fff3c3f1ffb com.apple.HIServices (1.22 - 624.1) <66FD9ED2-9630-313C-86AE-4C2FBCB3F351> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices + 0x7fff3c3f2000 - 0x7fff3c400fff com.apple.LangAnalysis (1.7.0 - 1.7.0) <B65FF7E6-E9B5-34D8-8CA7-63D415A8A9A6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis + 0x7fff3c401000 - 0x7fff3c44dfff com.apple.print.framework.PrintCore (13.4 - 503.2) <B90C67C1-0292-3CEC-885D-F1882CD104BE> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore + 0x7fff3c44e000 - 0x7fff3c488fff com.apple.QD (3.12 - 404.2) <38B20AFF-9D54-3B52-A6DC-C0D71380AA5F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD + 0x7fff3c489000 - 0x7fff3c495fff com.apple.speech.synthesis.framework (7.8.1 - 7.8.1) <A08DE016-C8F2-3B0E-BD34-15959D13DBF0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis + 0x7fff3c496000 - 0x7fff3c724ff7 com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <E0B8B5D8-80A0-308B-ABD6-F8612102B5D8> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox + 0x7fff3c726000 - 0x7fff3c726fff com.apple.audio.units.AudioUnit (1.14 - 1.14) <ABF8778E-4F9D-305E-A528-DE406A1A2B68> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit + 0x7fff3ca49000 - 0x7fff3cde3ff7 com.apple.CFNetwork (902.1 - 902.1) <76EB8CB6-BF59-3BDA-BF2B-F21B161611B9> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork + 0x7fff3cdf8000 - 0x7fff3cdf8fff com.apple.Carbon (158 - 158) <F8B370D9-2103-3276-821D-ACC756167F86> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon + 0x7fff3cdf9000 - 0x7fff3cdfcffb com.apple.CommonPanels (1.2.6 - 98) <2391761C-5CAA-3F68-86B7-50B37927B104> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels + 0x7fff3cdfd000 - 0x7fff3d102fff com.apple.HIToolbox (2.1.1 - 911.10) <BF7F9C0E-C732-3FB2-9BBC-362888BDA57B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox + 0x7fff3d103000 - 0x7fff3d106ffb com.apple.help (1.3.8 - 66) <DEBADFA8-C189-3195-B0D6-A1F2DE95882A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help + 0x7fff3d107000 - 0x7fff3d10cfff com.apple.ImageCapture (9.0 - 9.0) <23B4916F-3B43-3DFF-B956-FC390EECA284> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture + 0x7fff3d10d000 - 0x7fff3d1a2ffb com.apple.ink.framework (10.9 - 221) <5206C8B0-22DA-36C9-998E-846EDB626D5B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink + 0x7fff3d1a3000 - 0x7fff3d1bdff7 com.apple.openscripting (1.7 - 174) <1B2A1F9E-5534-3D61-83CA-9199B39E8708> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting + 0x7fff3d1de000 - 0x7fff3d1dffff com.apple.print.framework.Print (12 - 267) <3682ABFB-2561-3419-847D-02C247F4800D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print + 0x7fff3d1e0000 - 0x7fff3d1e2ff7 com.apple.securityhi (9.0 - 55006) <C1406B8D-7D05-3959-808F-9C82189CF57F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI + 0x7fff3d1e3000 - 0x7fff3d1e9fff com.apple.speech.recognition.framework (6.0.3 - 6.0.3) <2ED8643D-B0C3-3F17-82A2-BBF13E6CBABC> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition + 0x7fff3d30a000 - 0x7fff3d30afff com.apple.Cocoa (6.11 - 22) <78E6C28E-4308-3D10-AD14-0CBCF6789B3F> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa + 0x7fff3d318000 - 0x7fff3d3d1fff com.apple.ColorSync (4.13.0 - 3325) <D283C285-447D-3258-A7E4-59532123B8FF> /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync + 0x7fff3d55e000 - 0x7fff3d5f1ff7 com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <EB35D3EC-56EA-33E6-98DC-BDC3A5FA8ACE> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio + 0x7fff3d658000 - 0x7fff3d681ffb com.apple.CoreBluetooth (1.0 - 1) <E1335074-9D07-370E-8440-61C4874BAC56> /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth + 0x7fff3d682000 - 0x7fff3d9d8fef com.apple.CoreData (120 - 851) <A2B59780-FB16-36A3-8EE0-E0EF072454E0> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData + 0x7fff3d9d9000 - 0x7fff3dabcfff com.apple.CoreDisplay (99.14 - 99.14) <A1B91ADD-828D-33A0-8A92-CC3F83DF89D0> /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay + 0x7fff3dabd000 - 0x7fff3df5efef com.apple.CoreFoundation (6.9 - 1454.90) <E5D594BF-9142-3325-A62D-CF4AAF472642> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7fff3df60000 - 0x7fff3e570fef com.apple.CoreGraphics (2.0 - 1161.21) <375C477F-5A89-3C49-9B63-373C81A63F7E> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics + 0x7fff3e572000 - 0x7fff3e861fff com.apple.CoreImage (13.0.0 - 579.5) <AAE2DFD0-9B0A-3D56-8A3E-C460BAF70394> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage + 0x7fff3ec36000 - 0x7fff3ec36fff com.apple.CoreServices (822.36 - 822.36) <C8368F17-1589-3BA5-A0E7-89CB8DF2454F> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices + 0x7fff3ec37000 - 0x7fff3ecabffb com.apple.AE (735.1 - 735.1) <08EBA184-20F7-3725-AEA6-C314448161C6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE + 0x7fff3ecac000 - 0x7fff3ef83fff com.apple.CoreServices.CarbonCore (1178.4 - 1178.4) <0D5E19BF-18CB-3FA4-8A5F-F6C787C5EE08> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore + 0x7fff3ef84000 - 0x7fff3efb8fff com.apple.DictionaryServices (1.2 - 284.2) <6505B075-41C3-3C62-A4C3-85CE3F6825CD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices + 0x7fff3efb9000 - 0x7fff3efc1ffb com.apple.CoreServices.FSEvents (1239.50.1 - 1239.50.1) <3637CEC7-DF0E-320E-9634-44A442925C65> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents + 0x7fff3efc2000 - 0x7fff3f17ffff com.apple.LaunchServices (822.36 - 822.36) <6E68C090-B12D-3D3D-9617-E5D82C36B2D0> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices + 0x7fff3f180000 - 0x7fff3f230ff7 com.apple.Metadata (10.7.0 - 1191.4.13) <B5C22E70-C265-3C9F-865F-B138994A418D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata + 0x7fff3f231000 - 0x7fff3f291fff com.apple.CoreServices.OSServices (822.36 - 822.36) <3BB2E0CE-81AE-3D3D-9FCE-E1B7FC6D6A61> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices + 0x7fff3f292000 - 0x7fff3f300fff com.apple.SearchKit (1.4.0 - 1.4.0) <3662545A-B1CF-3079-BDCD-C83855CEFEEE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit + 0x7fff3f301000 - 0x7fff3f325ffb com.apple.coreservices.SharedFileList (71.21 - 71.21) <35582D88-5975-35E2-A29A-E3148C3EE727> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList + 0x7fff3f5c6000 - 0x7fff3f716fff com.apple.CoreText (352.0 - 578.22) <6129F39D-284D-3BBF-8999-7854AB61C01C> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText + 0x7fff3f717000 - 0x7fff3f751fff com.apple.CoreVideo (1.8 - 0.0) <86CCC036-51BB-3DD1-9601-D93798BCCD0F> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo + 0x7fff3f752000 - 0x7fff3f7ddff3 com.apple.framework.CoreWLAN (13.0 - 1350.1) <E862CC02-69D2-3503-887B-B6E8223081E7> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN + 0x7fff3fa58000 - 0x7fff3fa5dfff com.apple.DiskArbitration (2.7 - 2.7) <A975AD56-4CD3-3A89-8732-858CA9BD3DAA> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration + 0x7fff3fc1e000 - 0x7fff3ffe4fff com.apple.Foundation (6.9 - 1454.90) <8EA924F3-ADAE-3F4B-8482-8B11C027D9A5> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation + 0x7fff40055000 - 0x7fff40085fff com.apple.GSS (4.0 - 2.0) <D774A165-5581-3479-AB5D-2BBDB5CF8882> /System/Library/Frameworks/GSS.framework/Versions/A/GSS + 0x7fff4015f000 - 0x7fff40163ff7 com.apple.Hypervisor (1.0 - 1) <54448501-AF47-3409-BBF4-283F77D2E4A0> /System/Library/Frameworks/Hypervisor.framework/Versions/A/Hypervisor + 0x7fff40197000 - 0x7fff4029bffb com.apple.Bluetooth (6.0.7 - 6.0.7f10) <557F26F9-C7A0-34EA-A905-22E243BF6B48> /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth + 0x7fff402fb000 - 0x7fff40396fff com.apple.framework.IOKit (2.0.2 - 1445.71.1) <2EA4F383-CAA9-3AF0-99C5-90C22ADAA6B6> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit + 0x7fff40398000 - 0x7fff4039ffff com.apple.IOSurface (211.15 - 211.15) <9FD406F1-6BF2-35B0-8339-DF83A1A661EB> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface + 0x7fff403f6000 - 0x7fff40570ff7 com.apple.ImageIO.framework (3.3.0 - 1739.3) <7C579D3F-AE0B-31C9-8F80-67F2290B8DE0> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO + 0x7fff40571000 - 0x7fff40575ffb libGIF.dylib (1739.3) <7AA44C9D-48E8-3090-B044-61FE6F0AEF38> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib + 0x7fff40576000 - 0x7fff4065dfef libJP2.dylib (1739.3) <AEBF7260-0C10-30C0-8F0F-8B347DEE78B3> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib + 0x7fff4065e000 - 0x7fff40681ff7 libJPEG.dylib (1739.3) <D8C966AD-A00C-3E8B-A7ED-D7CC7ECB3224> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib + 0x7fff4095d000 - 0x7fff40983feb libPng.dylib (1739.3) <1737F680-99D1-3F03-BFA5-5CDA30EB880A> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib + 0x7fff40984000 - 0x7fff40986ffb libRadiance.dylib (1739.3) <21746434-FCC7-36DE-9331-11277DF66AA8> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib + 0x7fff40987000 - 0x7fff409d5fef libTIFF.dylib (1739.3) <C4CB5C1D-20F2-3BD4-B0E6-629FDB3EF8E8> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib + 0x7fff4188f000 - 0x7fff418a8ff7 com.apple.Kerberos (3.0 - 1) <F86DCCDF-93C1-38B3-82C2-477C12E8EE6D> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos + 0x7fff418a9000 - 0x7fff418defff com.apple.LDAPFramework (2.4.28 - 194.5) <08888215-BBCE-3402-8142-2C9ADB091580> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP + 0x7fff4228a000 - 0x7fff4230bfff com.apple.Metal (125.30 - 125.30) <975FD6B5-D695-346A-869F-0584A968D100> /System/Library/Frameworks/Metal.framework/Versions/A/Metal + 0x7fff42328000 - 0x7fff42343fff com.apple.MetalPerformanceShaders.MPSCore (1.0 - 1) <AD754E8F-CA00-3878-9AF3-208C224A230B> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSCore.framework/Versions/A/MPSCore + 0x7fff42344000 - 0x7fff423b3fef com.apple.MetalPerformanceShaders.MPSImage (1.0 - 1) <338B7779-E608-3D68-8A07-2ACC11299744> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSImage.framework/Versions/A/MPSImage + 0x7fff423b4000 - 0x7fff423d8fff com.apple.MetalPerformanceShaders.MPSMatrix (1.0 - 1) <9CE072D7-853B-3939-9645-7EB951376B87> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSMatrix.framework/Versions/A/MPSMatrix + 0x7fff423d9000 - 0x7fff424c0ff7 com.apple.MetalPerformanceShaders.MPSNeuralNetwork (1.0 - 1) <0DE891AD-27E5-38FF-AEC8-4A95356C4357> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSNeuralNetwork.framework/Versions/A/MPSNeuralNetwork + 0x7fff424c1000 - 0x7fff424c1ff7 com.apple.MetalPerformanceShaders.MetalPerformanceShaders (1.0 - 1) <2D2D261C-50B0-32F9-BF9A-5C01382BB528> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/MetalPerformanceShaders + 0x7fff434c0000 - 0x7fff434ccffb com.apple.NetFS (6.0 - 4.0) <471DD96F-FA2E-3FE9-9746-2519A6780D1A> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS + 0x7fff462be000 - 0x7fff46318ff7 com.apple.opencl (2.8.24 - 2.8.24) <4D7401A7-6ADD-3632-85AE-7A5012DFFA04> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL + 0x7fff46319000 - 0x7fff46335ffb com.apple.CFOpenDirectory (10.13 - 207.50.1) <29F55F7B-379F-3053-8FF3-5C6675A3DD4D> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory + 0x7fff46336000 - 0x7fff46341fff com.apple.OpenDirectory (10.13 - 207.50.1) <F895547D-4915-353F-9C1E-E95172BA803B> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory + 0x7fff474c0000 - 0x7fff474c2fff libCVMSPluginSupport.dylib (16.7.4) <F9270AE0-CC3B-3E3E-BA32-CC1068DD8F27> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib + 0x7fff474c3000 - 0x7fff474c8ffb libCoreFSCache.dylib (162.9) <7AF87F3E-D5D0-3625-BE09-CA4223195466> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib + 0x7fff474c9000 - 0x7fff474cdfff libCoreVMClient.dylib (162.9) <115FE643-6141-39B4-8193-77DFCBE7A4E0> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib + 0x7fff474ce000 - 0x7fff474d7ff3 libGFXShared.dylib (16.7.4) <EB2BF8A0-E10D-35EA-8F46-B2E3C62C12A8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib + 0x7fff474d8000 - 0x7fff474e3fff libGL.dylib (16.7.4) <2BB333D3-5C61-33DF-8545-06DF2D08B83D> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib + 0x7fff474e4000 - 0x7fff4751ffe7 libGLImage.dylib (16.7.4) <4DA003CE-0B74-3FE4-808C-B2FBCE517EB4> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib + 0x7fff4768e000 - 0x7fff476ccffb libGLU.dylib (16.7.4) <BCB09CD8-EB0E-38FA-8B5A-9E29532EE364> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib + 0x7fff48044000 - 0x7fff48053ff3 com.apple.opengl (16.7.4 - 16.7.4) <9BDE8FF9-5418-3C70-8D1C-09656884CE48> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL + 0x7fff48ea2000 - 0x7fff490eeff7 com.apple.QuartzCore (1.11 - 584.62) <1950D993-DE48-3C97-95A5-66D98BDFC95D> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore + 0x7fff49924000 - 0x7fff49c4ffff com.apple.security (7.0 - 58286.70.7) <9FC166E1-14D0-305C-A086-02B9E83F547E> /System/Library/Frameworks/Security.framework/Versions/A/Security + 0x7fff49c50000 - 0x7fff49cdcff7 com.apple.securityfoundation (6.0 - 55185.50.5) <D708D069-AEDB-36C2-B1DA-479DA91D7711> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation + 0x7fff49d0e000 - 0x7fff49d12ffb com.apple.xpc.ServiceManagement (1.0 - 1) <71B45D83-ECA4-3265-997E-683A8B8DF413> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement + 0x7fff4a0b7000 - 0x7fff4a127ff3 com.apple.SystemConfiguration (1.17 - 1.17) <8532B8E9-7E30-35A3-BC4A-DDE8E0614FDA> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration + 0x7fff4d024000 - 0x7fff4d0b7fff com.apple.APFS (1.0 - 1) <6BBB3988-1C91-314F-A77A-4E093A1B18F0> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS + 0x7fff4dce2000 - 0x7fff4dd0afff com.apple.framework.Apple80211 (13.0 - 1361.7) <16627876-8CF5-3502-A1D6-35FCBDD5E79A> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211 + 0x7fff4dd0c000 - 0x7fff4dd1bfef com.apple.AppleFSCompression (96.60.1 - 1.0) <A7C875C4-F5EE-3272-AFB6-57C9FD5352B3> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression + 0x7fff4de1a000 - 0x7fff4de25ff7 com.apple.AppleIDAuthSupport (1.0 - 1) <2FAF5567-CDB3-33EF-AB71-05D37F2248B7> /System/Library/PrivateFrameworks/AppleIDAuthSupport.framework/Versions/A/AppleIDAuthSupport + 0x7fff4de5f000 - 0x7fff4dea7ff3 com.apple.AppleJPEG (1.0 - 1) <8DD410CB-76A1-3F22-9A9F-0491FA0CEB4A> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG + 0x7fff4ded9000 - 0x7fff4dee1ff3 com.apple.AppleSRP (5.0 - 1) <4CEC34CF-63E3-3023-B61B-F8D133698534> /System/Library/PrivateFrameworks/AppleSRP.framework/Versions/A/AppleSRP + 0x7fff4dee2000 - 0x7fff4df0afff com.apple.applesauce (1.0 - ???) <CCA8B094-1BCE-3AE3-A0A7-D544C818DE36> /System/Library/PrivateFrameworks/AppleSauce.framework/Versions/A/AppleSauce + 0x7fff4e35c000 - 0x7fff4e5f5ffb com.apple.AuthKit (1.0 - 1) <6CA71A11-91C5-307C-B933-9FCDEDCB580A> /System/Library/PrivateFrameworks/AuthKit.framework/Versions/A/AuthKit + 0x7fff4e72c000 - 0x7fff4e733ff7 com.apple.coreservices.BackgroundTaskManagement (1.0 - 57.1) <51A41CA3-DB1D-3380-993E-99C54AEE518E> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement + 0x7fff4e734000 - 0x7fff4e7bbff7 com.apple.backup.framework (1.9.5 - 1.9.5) <5E7B0925-8C71-353D-BB0F-9CA144BB264C> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup + 0x7fff50175000 - 0x7fff5017eff3 com.apple.CommonAuth (4.0 - 2.0) <4D237B25-27E5-3577-948B-073659F6D3C0> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth + 0x7fff50b0d000 - 0x7fff50b16ff7 com.apple.frameworks.CoreDaemon (1.3 - 1.3) <35A43584-2AF8-3202-A139-27D916E444BE> /System/Library/PrivateFrameworks/CoreDaemon.framework/Versions/B/CoreDaemon + 0x7fff50c84000 - 0x7fff50c94ff7 com.apple.CoreEmoji (1.0 - 69.3) <A4357F5C-0C38-3A61-B456-D7321EB2CEE5> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji + 0x7fff51428000 - 0x7fff51430ff3 com.apple.CorePhoneNumbers (1.0 - 1) <A5D41251-9F38-3AB9-9DE7-F77023FAAA44> /System/Library/PrivateFrameworks/CorePhoneNumbers.framework/Versions/A/CorePhoneNumbers + 0x7fff515bb000 - 0x7fff515ecff3 com.apple.CoreServicesInternal (309.1 - 309.1) <4ECD14EA-A493-3B84-A32F-CF928474A405> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal + 0x7fff51929000 - 0x7fff519bafff com.apple.CoreSymbolication (9.3 - 64026.2) <D55A6E5B-0267-3F3A-8D90-4B8F39458420> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication + 0x7fff51a3d000 - 0x7fff51b72fff com.apple.coreui (2.1 - 494.1) <B2C515C3-FCE8-3B28-A225-05AD917F509B> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI + 0x7fff51b73000 - 0x7fff51ca4fff com.apple.CoreUtils (5.6 - 560.11) <1A02D6F0-8C65-3FAE-AD63-56477EDE4773> /System/Library/PrivateFrameworks/CoreUtils.framework/Versions/A/CoreUtils + 0x7fff51cf9000 - 0x7fff51d5dfff com.apple.framework.CoreWiFi (13.0 - 1350.1) <6EC5DEB3-6E2F-3DC2-BE59-1FD05175FB0C> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi + 0x7fff51d5e000 - 0x7fff51d6eff7 com.apple.CrashReporterSupport (10.13 - 1) <A909F468-0648-3F51-A77E-3F9ADBC9A941> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport + 0x7fff51dec000 - 0x7fff51dfbff7 com.apple.framework.DFRFoundation (1.0 - 191.7) <5F486F5A-3795-3CD4-86A2-FD008A23F205> /System/Library/PrivateFrameworks/DFRFoundation.framework/Versions/A/DFRFoundation + 0x7fff51dfe000 - 0x7fff51e02ffb com.apple.DSExternalDisplay (3.1 - 380) <901B7F6D-376A-3848-99D0-170C4D00F776> /System/Library/PrivateFrameworks/DSExternalDisplay.framework/Versions/A/DSExternalDisplay + 0x7fff51e84000 - 0x7fff51efafff com.apple.datadetectorscore (7.0 - 590.3) <7437160E-68A3-3FD7-8868-5E3F92E23C4F> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore + 0x7fff51f48000 - 0x7fff51f88ff7 com.apple.DebugSymbols (181.0 - 181.0) <299A0238-ED78-3676-B131-274D972824AA> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols + 0x7fff51f89000 - 0x7fff520b8fff com.apple.desktopservices (1.12.5 - 1.12.5) <7739C9A5-64D9-31A5-899B-5FFA242AD70D> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv + 0x7fff52ed2000 - 0x7fff53300fff com.apple.vision.FaceCore (3.3.2 - 3.3.2) <B574FE33-4A41-3611-9738-388EBAF03E37> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore + 0x7fff54f5c000 - 0x7fff54f5cfff libmetal_timestamp.dylib (802.4.8) <311A8FAA-5FA9-3AAF-887E-DC9884DE8BE5> /System/Library/PrivateFrameworks/GPUCompiler.framework/Versions/3802/Libraries/libmetal_timestamp.dylib + 0x7fff565c8000 - 0x7fff565cdfff com.apple.GPUWrangler (3.20.13 - 3.20.13) <9C5BD618-69E3-36D5-9BC9-A4841BC00D2A> /System/Library/PrivateFrameworks/GPUWrangler.framework/Versions/A/GPUWrangler + 0x7fff57343000 - 0x7fff57352fff com.apple.GraphVisualizer (1.0 - 5) <B993B8A2-5700-3DFC-9EB7-4CCEE8F959F1> /System/Library/PrivateFrameworks/GraphVisualizer.framework/Versions/A/GraphVisualizer + 0x7fff573d5000 - 0x7fff57449fff com.apple.Heimdal (4.0 - 2.0) <93091531-CC91-34FF-8B93-5D3F02C37BC5> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal + 0x7fff57d4f000 - 0x7fff57d58fff com.apple.IOAccelMemoryInfo (1.0 - 1) <E2416468-8B64-3BB8-A099-361954C8DED7> /System/Library/PrivateFrameworks/IOAccelMemoryInfo.framework/Versions/A/IOAccelMemoryInfo + 0x7fff57d59000 - 0x7fff57d60ff7 com.apple.IOAccelerator (378.26 - 378.26) <2274BE11-18DE-3B13-BCDB-C488C9BB19AD> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator + 0x7fff57d64000 - 0x7fff57d7bfff com.apple.IOPresentment (1.0 - 35.1) <7C6332FF-6535-3064-B437-1E9F70671927> /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment + 0x7fff58146000 - 0x7fff5816cffb com.apple.IconServices (97.6 - 97.6) <A56D826D-20D2-34BE-AACC-A80CFCB4E915> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices + 0x7fff583f1000 - 0x7fff58404ff3 com.apple.security.KeychainCircle.KeychainCircle (1.0 - 1) <AED421B0-90A0-3969-98A4-CCBCF2D3360B> /System/Library/PrivateFrameworks/KeychainCircle.framework/Versions/A/KeychainCircle + 0x7fff58405000 - 0x7fff584faff7 com.apple.LanguageModeling (1.0 - 159.5.3) <7F0AC200-E3DD-39FB-8A95-00DD70B66A9F> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling + 0x7fff584fb000 - 0x7fff5853dfff com.apple.Lexicon-framework (1.0 - 33.5) <DC94CF9E-1EB4-3C0E-B298-CA1190885276> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon + 0x7fff58541000 - 0x7fff58548ff7 com.apple.LinguisticData (1.0 - 238.3) <49A54649-1021-3DBD-99B8-1B2EDFFA5378> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData + 0x7fff5925a000 - 0x7fff592c3ff7 com.apple.gpusw.MetalTools (1.0 - 1) <458F319A-2707-3C83-8351-BD9F02EC05BD> /System/Library/PrivateFrameworks/MetalTools.framework/Versions/A/MetalTools + 0x7fff59443000 - 0x7fff5945cfff com.apple.MobileKeyBag (2.0 - 1.0) <32E63C7B-E133-33DE-A593-C3C10D64FCAA> /System/Library/PrivateFrameworks/MobileKeyBag.framework/Versions/A/MobileKeyBag + 0x7fff594e8000 - 0x7fff59512ffb com.apple.MultitouchSupport.framework (1404.4 - 1404.4) <45374A2A-C0BC-3A70-8183-37295205CDFA> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport + 0x7fff59779000 - 0x7fff59784fff com.apple.NetAuth (6.2 - 6.2) <B3795F63-C14A-33E1-9EE6-02A2E7661321> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth + 0x7fff5b01a000 - 0x7fff5b02affb com.apple.PerformanceAnalysis (1.194 - 194) <2844933E-B71C-3BE9-9A84-27B29E111F13> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis + 0x7fff5cde9000 - 0x7fff5ce07fff com.apple.ProtocolBuffer (1 - 260) <40704740-4A53-3010-A49B-08D1D69D1D5E> /System/Library/PrivateFrameworks/ProtocolBuffer.framework/Versions/A/ProtocolBuffer + 0x7fff5cfde000 - 0x7fff5d001ffb com.apple.RemoteViewServices (2.0 - 125) <592323D1-CB44-35F1-9921-4C2AB8D920A0> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices + 0x7fff5e925000 - 0x7fff5ea3aff7 com.apple.Sharing (1050.22.2 - 1050.22.2) <4E3CCDF2-EA26-334F-8EBA-79BD28486C9D> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing + 0x7fff5ea65000 - 0x7fff5ea66ff7 com.apple.performance.SignpostNotification (1.2.6 - 2.6) <8F04800F-3570-3392-A24D-B229FF03F7F9> /System/Library/PrivateFrameworks/SignpostNotification.framework/Versions/A/SignpostNotification + 0x7fff5f7ae000 - 0x7fff5fa4aff7 com.apple.SkyLight (1.600.0 - 312.103) <27F91170-846C-3E9E-9B8A-788F27C7DAF5> /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight + 0x7fff60213000 - 0x7fff60220fff com.apple.SpeechRecognitionCore (4.6.1 - 4.6.1) <87EE7AB5-6925-3D21-BE00-F155CB457699> /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore + 0x7fff60dc6000 - 0x7fff60e4ffc7 com.apple.Symbolication (9.3 - 64033) <C2C55C9A-C264-3044-A953-16457148190A> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication + 0x7fff613c0000 - 0x7fff613c8ff7 com.apple.TCC (1.0 - 1) <E1EB7272-FE6F-39AB-83CA-B2B5F2A88D9B> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC + 0x7fff615d5000 - 0x7fff61692ff7 com.apple.TextureIO (3.7 - 3.7) <F8BAC954-405D-3CC3-AB7B-048C866EF980> /System/Library/PrivateFrameworks/TextureIO.framework/Versions/A/TextureIO + 0x7fff6173c000 - 0x7fff6173dfff com.apple.TrustEvaluationAgent (2.0 - 31) <39F533B2-211E-3635-AF47-23F27749FF4A> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent + 0x7fff61743000 - 0x7fff618f2fff com.apple.UIFoundation (1.0 - 547.5) <86A2FBA7-2709-3894-A3D5-A00C19BAC48D> /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation + 0x7fff625c7000 - 0x7fff62696ff7 com.apple.ViewBridge (343.2 - 343.2) <5519FCED-1F88-3BE6-9BE1-69992086B01B> /System/Library/PrivateFrameworks/ViewBridge.framework/Versions/A/ViewBridge + 0x7fff62ffb000 - 0x7fff62ffdffb com.apple.loginsupport (1.0 - 1) <D1232C1B-80EA-3DF8-9466-013695D0846E> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport + 0x7fff63164000 - 0x7fff63197ff7 libclosured.dylib (551.4) <3FB6B209-51F4-38DA-B1D8-2EE29D5BDD83> /usr/lib/closure/libclosured.dylib + 0x7fff63251000 - 0x7fff6328aff7 libCRFSuite.dylib (41) <FE5EDB68-2593-3C2E-BBAF-1C52D206F296> /usr/lib/libCRFSuite.dylib + 0x7fff6328b000 - 0x7fff63296fff libChineseTokenizer.dylib (28) <53633C9B-A3A8-36F7-A53C-432D802F4BB8> /usr/lib/libChineseTokenizer.dylib + 0x7fff63328000 - 0x7fff63329ff3 libDiagnosticMessagesClient.dylib (104) <9712E980-76EE-3A89-AEA6-DF4BAF5C0574> /usr/lib/libDiagnosticMessagesClient.dylib + 0x7fff63360000 - 0x7fff6352aff3 libFosl_dynamic.dylib (17.8) <C58ED77A-4986-31C2-994C-34DDFB8106F0> /usr/lib/libFosl_dynamic.dylib + 0x7fff63562000 - 0x7fff63562fff libOpenScriptingUtil.dylib (174) <610F0242-7CE5-3C86-951B-B646562694AF> /usr/lib/libOpenScriptingUtil.dylib + 0x7fff63699000 - 0x7fff6369dffb libScreenReader.dylib (562.18.4) <E239923D-54C9-3BBF-852F-87C09DEF4091> /usr/lib/libScreenReader.dylib + 0x7fff6369e000 - 0x7fff6369fffb libSystem.B.dylib (1252.50.4) <CD555F3B-FDDB-35E5-A2FB-FBBF3D62031A> /usr/lib/libSystem.B.dylib + 0x7fff63732000 - 0x7fff63732fff libapple_crypto.dylib (109.50.14) <48BA2E76-BF2F-3522-A54E-D7FB7EAF7A57> /usr/lib/libapple_crypto.dylib + 0x7fff63733000 - 0x7fff63749ff7 libapple_nghttp2.dylib (1.24) <01402BC4-4822-3676-9C80-50D83F816424> /usr/lib/libapple_nghttp2.dylib + 0x7fff6374a000 - 0x7fff63774ff3 libarchive.2.dylib (54) <8FC28DD8-E315-3C3E-95FE-D1D2CBE49888> /usr/lib/libarchive.2.dylib + 0x7fff63775000 - 0x7fff637f6fdf libate.dylib (1.13.1) <178ACDAD-DE7E-346C-A613-1CBF7929AC07> /usr/lib/libate.dylib + 0x7fff637fa000 - 0x7fff637faff3 libauto.dylib (187) <A05C7900-F8C7-3E75-8D3F-909B40C19717> /usr/lib/libauto.dylib + 0x7fff637fb000 - 0x7fff638b3ff3 libboringssl.dylib (109.50.14) <E6813F87-B5E4-3F7F-A725-E6A7F2BD02EC> /usr/lib/libboringssl.dylib + 0x7fff638b4000 - 0x7fff638c4ff3 libbsm.0.dylib (39) <6BC96A72-AFBE-34FD-91B1-748A530D8AE6> /usr/lib/libbsm.0.dylib + 0x7fff638c5000 - 0x7fff638d2ffb libbz2.1.0.dylib (38) <0A5086BB-4724-3C14-979D-5AD4F26B5B45> /usr/lib/libbz2.1.0.dylib + 0x7fff638d3000 - 0x7fff63929fff libc++.1.dylib (400.9) <7D3DACCC-3804-393C-ABC1-1A580FD00CB6> /usr/lib/libc++.1.dylib + 0x7fff6392a000 - 0x7fff6394eff7 libc++abi.dylib (400.8.2) <EF5E37D7-11D9-3530-BE45-B986612D13E2> /usr/lib/libc++abi.dylib + 0x7fff63950000 - 0x7fff63960fff libcmph.dylib (6) <A5509EE8-7E00-3224-8814-015B077A3CF5> /usr/lib/libcmph.dylib + 0x7fff63961000 - 0x7fff63978fcf libcompression.dylib (47.60.2) <543F07BF-2F2F-37D5-9866-E84BF659885B> /usr/lib/libcompression.dylib + 0x7fff63c23000 - 0x7fff63c3bff7 libcoretls.dylib (155.50.1) <D350052E-DC4D-3185-ADBA-BA48EDCEE955> /usr/lib/libcoretls.dylib + 0x7fff63c3c000 - 0x7fff63c3dff3 libcoretls_cfhelpers.dylib (155.50.1) <B297F5D8-F2FE-3566-A752-E9D998B9C039> /usr/lib/libcoretls_cfhelpers.dylib + 0x7fff63dd6000 - 0x7fff63f67fff libcrypto.35.dylib (22.50.2) <97828BFD-4675-35DF-BE2E-C6D1555BB71D> /usr/lib/libcrypto.35.dylib + 0x7fff6410e000 - 0x7fff64164ff3 libcups.2.dylib (462.2.4) <908099FB-C70E-38FA-9573-88CB98FDDE29> /usr/lib/libcups.2.dylib + 0x7fff6418f000 - 0x7fff641e3ffb libcurl.4.dylib (105.40.1) <B04E7791-EAF9-3D72-B4ED-DD8F135140EC> /usr/lib/libcurl.4.dylib + 0x7fff642a4000 - 0x7fff642a4fff libenergytrace.dylib (16) <A92AB8B8-B986-3CE6-980D-D55090FEF387> /usr/lib/libenergytrace.dylib + 0x7fff642db000 - 0x7fff642e0ff3 libheimdal-asn1.dylib (520.50.6) <E358445A-B84E-31B5-BCCD-7E1397519D96> /usr/lib/libheimdal-asn1.dylib + 0x7fff6430c000 - 0x7fff643fdff7 libiconv.2.dylib (51.50.1) <2FEC9707-3FAF-3828-A50D-8605086D060F> /usr/lib/libiconv.2.dylib + 0x7fff643fe000 - 0x7fff64625ffb libicucore.A.dylib (59180.0.1) <34EBADD6-4092-30EC-90E8-F75241E94D76> /usr/lib/libicucore.A.dylib + 0x7fff64672000 - 0x7fff64673fff liblangid.dylib (128) <39C39393-0D05-301D-93B2-F224FC4949AA> /usr/lib/liblangid.dylib + 0x7fff64674000 - 0x7fff6468dffb liblzma.5.dylib (10) <3D419A50-961F-37D2-8A01-3DC7AB7B8D18> /usr/lib/liblzma.5.dylib + 0x7fff6468e000 - 0x7fff646a4ff7 libmarisa.dylib (9) <D6D2D55D-1D2E-3442-B152-B18803C0ABB4> /usr/lib/libmarisa.dylib + 0x7fff64755000 - 0x7fff6497dff7 libmecabra.dylib (779.7.6) <F462F170-E872-3D09-B219-973D5E99C09F> /usr/lib/libmecabra.dylib + 0x7fff64b55000 - 0x7fff64cd0fff libnetwork.dylib (1229.70.2) <E185D902-AC7F-3044-87C0-AE2887C59CE7> /usr/lib/libnetwork.dylib + 0x7fff64d57000 - 0x7fff651457e7 libobjc.A.dylib (723) <DD9E5EC5-B507-3249-B700-93433E2D5EDF> /usr/lib/libobjc.A.dylib + 0x7fff65158000 - 0x7fff6515cfff libpam.2.dylib (22) <7B4D2CE2-1438-387A-9802-5CEEFBF26F86> /usr/lib/libpam.2.dylib + 0x7fff6515f000 - 0x7fff65193fff libpcap.A.dylib (79.20.1) <FA13918B-A247-3181-B256-9B852C7BA316> /usr/lib/libpcap.A.dylib + 0x7fff65212000 - 0x7fff6522effb libresolv.9.dylib (65) <E8F3415B-4472-3202-8901-41FD87981DB2> /usr/lib/libresolv.9.dylib + 0x7fff6526a000 - 0x7fff6527cfff libsasl2.2.dylib (211) <04EF3F61-12EC-3319-A649-851999F4C7A4> /usr/lib/libsasl2.2.dylib + 0x7fff6527f000 - 0x7fff65412ff7 libsqlite3.dylib (274.8.1) <FCAD6A57-829E-3701-B16E-1833D620E0E8> /usr/lib/libsqlite3.dylib + 0x7fff6546e000 - 0x7fff654c1ffb libssl.35.dylib (22.50.2) <AF523E9B-7183-3A87-8FB4-E26936EC4FDB> /usr/lib/libssl.35.dylib + 0x7fff655e6000 - 0x7fff65646ff3 libusrtcp.dylib (1229.70.2) <1E065228-D0E3-3808-9405-894056C6BEC0> /usr/lib/libusrtcp.dylib + 0x7fff65647000 - 0x7fff6564affb libutil.dylib (51.20.1) <216D18E5-0BAF-3EAF-A38E-F6AC37CBABD9> /usr/lib/libutil.dylib + 0x7fff6564b000 - 0x7fff65658fff libxar.1.dylib (400) <0316128D-3B47-3052-995D-97B4FE5491DC> /usr/lib/libxar.1.dylib + 0x7fff6565c000 - 0x7fff65743fff libxml2.2.dylib (31.11) <C2B5C43F-9C0B-31E6-8EC0-939591EDAC49> /usr/lib/libxml2.2.dylib + 0x7fff65744000 - 0x7fff6576cfff libxslt.1.dylib (15.12) <4A5E011D-8B29-3135-A52B-9A9070ABD752> /usr/lib/libxslt.1.dylib + 0x7fff6576d000 - 0x7fff6577fffb libz.1.dylib (70) <48C67CFC-940D-3857-8DAD-857774605352> /usr/lib/libz.1.dylib + 0x7fff6581b000 - 0x7fff6581fff7 libcache.dylib (80) <092479CB-1008-3A83-BECF-E115F24D13C1> /usr/lib/system/libcache.dylib + 0x7fff65820000 - 0x7fff6582aff3 libcommonCrypto.dylib (60118.50.1) <029F5985-9B6E-3DCB-9B96-FD007678C6A7> /usr/lib/system/libcommonCrypto.dylib + 0x7fff6582b000 - 0x7fff65832fff libcompiler_rt.dylib (62) <968B8E3F-3681-3230-9D78-BB8732024F6E> /usr/lib/system/libcompiler_rt.dylib + 0x7fff65833000 - 0x7fff6583cffb libcopyfile.dylib (146.50.5) <3885083D-50D8-3EEC-B481-B2E605180D7F> /usr/lib/system/libcopyfile.dylib + 0x7fff6583d000 - 0x7fff658c2fff libcorecrypto.dylib (562.70.1) <5C26364F-2269-31EC-84AF-0FED2C902E38> /usr/lib/system/libcorecrypto.dylib + 0x7fff6594a000 - 0x7fff65983ff7 libdispatch.dylib (913.60.2) <232C69BD-022E-3AB9-8807-79F9FA7CB5EC> /usr/lib/system/libdispatch.dylib + 0x7fff65984000 - 0x7fff659a1ff7 libdyld.dylib (551.4) <81BF3A82-5719-3B54-ABA9-76C82D932CAC> /usr/lib/system/libdyld.dylib + 0x7fff659a2000 - 0x7fff659a2ffb libkeymgr.dylib (28) <E34E283E-90FA-3C59-B48E-1277CDB9CDCE> /usr/lib/system/libkeymgr.dylib + 0x7fff659a3000 - 0x7fff659afff3 libkxld.dylib (4570.71.2) <C3C31E1B-3E74-3828-8429-4D442E26D41C> /usr/lib/system/libkxld.dylib + 0x7fff659b0000 - 0x7fff659b0ff7 liblaunch.dylib (1205.70.9) <B184B521-FF24-3142-AFAF-23D170CF918C> /usr/lib/system/liblaunch.dylib + 0x7fff659b1000 - 0x7fff659b5ffb libmacho.dylib (906) <1902A611-081A-3452-B11E-EBD1B166E831> /usr/lib/system/libmacho.dylib + 0x7fff659b6000 - 0x7fff659b8ff3 libquarantine.dylib (86) <26C0BA22-8F93-3A07-9A4E-C8D53D2CE42E> /usr/lib/system/libquarantine.dylib + 0x7fff659b9000 - 0x7fff659baff3 libremovefile.dylib (45) <711E18B2-5BBE-3211-A916-56740C27D17A> /usr/lib/system/libremovefile.dylib + 0x7fff659bb000 - 0x7fff659d2fff libsystem_asl.dylib (356.70.1) <39E46A6F-B228-3E78-B83E-1779F9707A39> /usr/lib/system/libsystem_asl.dylib + 0x7fff659d3000 - 0x7fff659d3fff libsystem_blocks.dylib (67) <17303FDF-0D2D-3963-B05E-B4DF63052D47> /usr/lib/system/libsystem_blocks.dylib + 0x7fff659d4000 - 0x7fff65a5dff7 libsystem_c.dylib (1244.50.9) <1187BFE8-4576-3247-8177-481554E1F9E7> /usr/lib/system/libsystem_c.dylib + 0x7fff65a5e000 - 0x7fff65a61ffb libsystem_configuration.dylib (963.50.8) <DF6B5287-203E-30CB-9947-78DF446C72B8> /usr/lib/system/libsystem_configuration.dylib + 0x7fff65a62000 - 0x7fff65a65ffb libsystem_coreservices.dylib (51) <486000D3-D8CB-3BE7-8EE5-8BF380DE6DF7> /usr/lib/system/libsystem_coreservices.dylib + 0x7fff65a66000 - 0x7fff65a67fff libsystem_darwin.dylib (1244.50.9) <09C21A4A-9EE0-388B-A9D9-DFF8F6758791> /usr/lib/system/libsystem_darwin.dylib + 0x7fff65a68000 - 0x7fff65a6eff7 libsystem_dnssd.dylib (878.70.2) <3290768B-54DE-3AB6-B155-AC0950AC5564> /usr/lib/system/libsystem_dnssd.dylib + 0x7fff65a6f000 - 0x7fff65ab8ff7 libsystem_info.dylib (517.30.1) <AB634A98-B8AA-3804-8436-38261FC8EC4D> /usr/lib/system/libsystem_info.dylib + 0x7fff65ab9000 - 0x7fff65adfff7 libsystem_kernel.dylib (4570.71.2) <F22B8D73-69D8-36D7-BF66-7F9AC70C08C2> /usr/lib/system/libsystem_kernel.dylib + 0x7fff65ae0000 - 0x7fff65b2bfcb libsystem_m.dylib (3147.50.1) <8CFB51C9-B422-3379-8552-064C63943A23> /usr/lib/system/libsystem_m.dylib + 0x7fff65b2c000 - 0x7fff65b4bfff libsystem_malloc.dylib (140.50.6) <7FD43735-9DDD-300E-8C4A-F909A74BDF49> /usr/lib/system/libsystem_malloc.dylib + 0x7fff65b4c000 - 0x7fff65c7cff7 libsystem_network.dylib (1229.70.2) <5E86B2DE-9E15-3354-8714-4094ED5F698D> /usr/lib/system/libsystem_network.dylib + 0x7fff65c7d000 - 0x7fff65c87ffb libsystem_networkextension.dylib (767.70.1) <D23EAFC1-E8BD-34D5-969C-6E45A1C3B4E4> /usr/lib/system/libsystem_networkextension.dylib + 0x7fff65c88000 - 0x7fff65c91ff3 libsystem_notify.dylib (172) <08012EC0-2CD2-34BE-BF93-E7F56491299A> /usr/lib/system/libsystem_notify.dylib + 0x7fff65c92000 - 0x7fff65c99ff7 libsystem_platform.dylib (161.50.1) <6355EE2D-5456-3CA8-A227-B96E8F1E2AF8> /usr/lib/system/libsystem_platform.dylib + 0x7fff65c9a000 - 0x7fff65ca5fff libsystem_pthread.dylib (301.50.1) <0E51CCBA-91F2-34E1-BF2A-FEEFD3D321E4> /usr/lib/system/libsystem_pthread.dylib + 0x7fff65ca6000 - 0x7fff65ca9fff libsystem_sandbox.dylib (765.70.1) <553DFCC6-9D31-3B9C-AB7C-30F6F265786D> /usr/lib/system/libsystem_sandbox.dylib + 0x7fff65caa000 - 0x7fff65cabff3 libsystem_secinit.dylib (30) <DE8D14E8-A276-3FF8-AE13-77F7040F33C1> /usr/lib/system/libsystem_secinit.dylib + 0x7fff65cac000 - 0x7fff65cb3ff7 libsystem_symptoms.dylib (820.60.2) <585BDFA2-D54D-39D0-8046-44E824DABD43> /usr/lib/system/libsystem_symptoms.dylib + 0x7fff65cb4000 - 0x7fff65cc7fff libsystem_trace.dylib (829.70.1) <3A6CB706-8CA6-3616-8AFC-14AAD7FAF187> /usr/lib/system/libsystem_trace.dylib + 0x7fff65cc9000 - 0x7fff65cceff7 libunwind.dylib (35.3) <BEF3FB49-5604-3B5F-82B5-332B80023AC3> /usr/lib/system/libunwind.dylib + 0x7fff65ccf000 - 0x7fff65cfcff7 libxpc.dylib (1205.70.9) <0BC7AD67-671D-31D4-8B88-C317B8379598> /usr/lib/system/libxpc.dylib + +External Modification Summary: + Calls made by other processes targeting this process: + task_for_pid: 1 + thread_create: 0 + thread_set_state: 0 + Calls made by this process: + task_for_pid: 0 + thread_create: 0 + thread_set_state: 0 + Calls made by all processes on this machine: + task_for_pid: 626 + thread_create: 0 + thread_set_state: 0 + +VM Region Summary: +ReadOnly portion of Libraries: Total=350.0M resident=0K(0%) swapped_out_or_unallocated=350.0M(100%) +Writable regions: Total=8.3G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=8.3G(100%) + + VIRTUAL REGION +REGION TYPE SIZE COUNT (non-coalesced) +=========== ======= ======= +Accelerate framework 384K 3 +Activity Tracing 256K 2 +CG backing stores 19.0M 5 +CG image 48K 4 +CoreAnimation 148K 8 +CoreGraphics 8K 2 +CoreImage 24K 3 +CoreUI image data 1764K 13 +CoreUI image file 188K 5 +Dispatch continuations 16.0M 2 +Foundation 4K 2 +IOKit 128K 3 +Kernel Alloc Once 8K 2 +MALLOC 133.4M 38 +MALLOC guard page 48K 10 +MALLOC_LARGE (reserved) 2816K 2 reserved VM address space (unallocated) +Memory Tag 242 12K 2 +STACK GUARD 56.0M 11 +Stack 12.6M 13 +VM_ALLOCATE 8.1G 162 +__DATA 25.3M 255 +__FONT_DATA 4K 2 +__LINKEDIT 194.6M 21 +__TEXT 155.5M 258 +__UNICODE 560K 2 +mapped file 47.1M 18 +shared memory 676K 13 +=========== ======= ======= +TOTAL 8.7G 834 +TOTAL, minus reserved VM space 8.7G 834 + +Model: MacBookPro14,3, BootROM MBP143.0178.B00, 4 processors, Intel Core i7, 2.8 GHz, 16 GB, SMC 2.45f0 +Graphics: Radeon Pro 555, Radeon Pro 555, PCIe +Graphics: Intel HD Graphics 630, Intel HD Graphics 630, Built-In +Memory Module: BANK 0/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320 +Memory Module: BANK 1/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320 +AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x173), Broadcom BCM43xx 1.0 (7.77.37.31.1a9) +Bluetooth: Version 6.0.7f10, 3 services, 18 devices, 1 incoming serial ports +Network Service: Wi-Fi, AirPort, en0 +USB Device: USB 3.0 Bus +USB Device: iBridge +Thunderbolt Bus: MacBook Pro, Apple Inc., 33.1 +Thunderbolt Bus: MacBook Pro, Apple Inc., 33.1 + + +Also seeing quite a few of these errors + +Unimplemented handler (7f7a56978294) for 0 (f 7f) +Unimplemented handler (7f2eaa6c8849) for 0 (f 7f) +Unimplemented handler (7f82f92a9294) for 0 (f 7f) +Unimplemented handler (7f04702f2294) for 0 (f 7f) + +I have tried to run the OS and I can confirm that some instructions that require VMEXIT are not implemented. In your case that's 0F7F or MOVQ (mem from mmxreg) from MMX. In my case that's 0F11 or MOVUPS(xmmreg1 to mem) from SSE. + +I'd recommend you to run -cpu host,-mmx,-sse for a while, but the kernel of the OS explicitly complains that it won't run on CPUs without SSE support. + +Thanks for helping Roman, so I take it my options at this point are wait for VMEXIT to be implemented or try to find a linux distro that doesn't require SSE? + +Considering the fact that both Ubuntu and Elementary require SSE to boot, I'd wait to get decoding fixed. I wrote a test kernel module that reliably reproduces your issue on qemu edu device. Whenever QEMU prints Unimplemented handler Instruction pointer only moves two bytes further, instead of the instruction length. That corrupts code execution as the next instruction after unimplemented handler is decoded from the wrong address. + +Still an issue on 3.1.0 and now Mojave + +Adding a ditto to this. + +== Command and output == + +$ qemu-system-x86_64 -m 2G -hda mydisk.vdi -accel hvf -vga std +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +Unimplemented handler (7fe3aac905e8) for 0 (f 11) + +This is for a customized Ubuntu install. + +== Symptoms == + +Guest window repeatedly alternates between the desktop, then flickers to terminal with the following text: + +/dev/sda4: recovering journal +/dev/sda4: clean, 93356/1264800 files, 1076062/5056592 blocks +[ OK ] Started xrdp session manager. +[ OK ] Started OpenBSD Secure Shell server. +[ OK ] Started Terminate Plymouth Boot Screen. +[ OK ] Started Hold until boot process finishes up. + +== Host system == + +- macOS 10.14.6 +- Bluetooth mouse and keyboard + + +Also, the workaround of using -cpu host,-mmx,-sse doesn't work (the guest appears to never even boot). + +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/155 + + diff --git a/results/classifier/zero-shot/108/permissions/1801933 b/results/classifier/zero-shot/108/permissions/1801933 new file mode 100644 index 000000000..389ef913f --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1801933 @@ -0,0 +1,148 @@ +permissions: 0.974 +debug: 0.964 +socket: 0.950 +vnc: 0.945 +PID: 0.942 +semantic: 0.941 +device: 0.938 +network: 0.935 +files: 0.913 +boot: 0.911 +performance: 0.900 +other: 0.898 +graphic: 0.882 +KVM: 0.863 + +default memory parameter too small on x86_64 today + +Launching a centos7 VM today does not work anymore on x86_64 without increasing the size of the memory parameter. For example with this command : + +$ /opt/qemu-3.0.0/bin/qemu-system-x86_64 --curses -enable-kvm -drive file=file.dd,index=0,media=disk -drive file=centos-x86_64.iso,index=1,media=cdrom + +[ 3.047614] Failed to execute /init +[ 3.048315] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance. +[ 3.049258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-693.21.1.el7.x86 + + + +Increasing the size from the default 128MiB to 512MiB let the VM works without problem. +So, ok, it's not a qemu problem, it's more a "User problem" and interface problem for me. +But it push me in the end to launch VirtualBox instead of qemu, because the default parameter does not work anymore... And I had no time to investigate why it does not work because the message is not visible. +Debian iso with the same command line for example show a message to tell me that there is not enough memory, so it help me to track the real issue behind. + +But... In the end, I think today, the default memory parameter on x86_64 is too small and it can lead some people like me to switch to VirtualBox. +VirtualBox, in the wizard is set by default to 4MiB Ram size, which tell you... Ok I need to put more. But, you know that 4MiB is not enough in the end. + + +Regards, + +Johann + +IMHO, if achieving ease of use comparable to VirtualBox is your benchmark target, then launching QEMU directly is really the wrong way to approach things. QEMU is a very low level piece of infrastructure not a complete end user desktop solution. For that it is better to look at using an application such as virt-manager, or GNOME Boxes. These provide higher level solution over QEMU and do smart things during installation, using libosinfo to automatically determine the best memory, disk, network, etc settings for each particular guest OS rather than relying on some hardcoded defaults. + +That said all said, I don't rule out that we could change our memory defaults, but picking an optimal value is hard. Even 500 MB is considered to be unsupported from a RHEL-7 pov - the documented minimum for RHEL-7 is 1 GB per vCPU. The installer is quite likely to crash with 500 MB depending on what options you select durin intsall. + + +Hi Daniel, + +I use qemu for a long time now so for me it's easier to use than any other +solution. +I think I began to use as my preffered VM tool in 2003. +But, I still think that keeping this value at 128MB is low today. +Maybe in this case reducing this value to make it crash is another option, +for example 4MB. +Or just print a message if it is an iso file that ramsize is set to 128MB, +maybe you need more ram. +It is just quick thought, some OS will handle this correctly, some os won't. +For example in my example I say that debian say it explicitely in the 80x25 +screen in red. + +Today I see all people around me are moving to VirtualBox because it just +work out of the box. +And Qemu is near to work out of the box with 2 or 3 parameter in the end. +Definitely I have a prefference for Qemu, because it's more "shell +friendly". + +It was just my quick thought about it. + +Johann + + + +Le mer. 5 déc. 2018 à 12:31, Daniel Berrange <email address hidden> a +écrit : + +> IMHO, if achieving ease of use comparable to VirtualBox is your +> benchmark target, then launching QEMU directly is really the wrong way +> to approach things. QEMU is a very low level piece of infrastructure not +> a complete end user desktop solution. For that it is better to look at +> using an application such as virt-manager, or GNOME Boxes. These provide +> higher level solution over QEMU and do smart things during installation, +> using libosinfo to automatically determine the best memory, disk, +> network, etc settings for each particular guest OS rather than relying +> on some hardcoded defaults. +> +> That said all said, I don't rule out that we could change our memory +> defaults, but picking an optimal value is hard. Even 500 MB is +> considered to be unsupported from a RHEL-7 pov - the documented minimum +> for RHEL-7 is 1 GB per vCPU. The installer is quite likely to crash with +> 500 MB depending on what options you select durin intsall. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1801933 +> +> Title: +> default memory parameter too small on x86_64 today +> +> Status in QEMU: +> New +> +> Bug description: +> Launching a centos74 iso VM today does not work anymore on x86_64 +> without increasing the size of the memory parameter. For example with +> this command : +> +> $ /opt/qemu-3.0.0/bin/qemu-system-x86_64 --curses -enable-kvm -drive +> file=file.dd,index=0,media=disk -drive file=centos- +> x86_64.iso,index=1,media=cdrom +> +> [ 3.047614] Failed to execute /init +> [ 3.048315] Kernel panic - not syncing: No init found. Try passing +> init= option to kernel. See Linux Documentation/init.txt for guidance. +> [ 3.049258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted +> 3.10.0-693.21.1.el7.x86 +> +> Increasing the size from the default 128MiB to 512MiB let the VM works +> without problem. +> So, ok, it's not a qemu problem, it's more a "User problem" and +> interface problem for me. +> But it push me in the end to launch VirtualBox instead of qemu, because +> the default parameter does not work anymore... And I had no time to +> investigate why it does not work because the message is not visible. +> Debian iso with the same command line for example show a message to tell +> me that there is not enough memory, so it help me to track the real issue +> behind. +> +> But... In the end, I think today, the default memory parameter on x86_64 +> is too small and it can lead some people like me to switch to VirtualBox. +> VirtualBox, in the wizard is set by default to 4MiB Ram size, which tell +> you... Ok I need to put more. And, you know that 4MiB is not enough in the +> end. +> +> Regards, +> +> Johann +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1801933/+subscriptions +> + + +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/zero-shot/108/permissions/1806243 b/results/classifier/zero-shot/108/permissions/1806243 new file mode 100644 index 000000000..974716962 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1806243 @@ -0,0 +1,153 @@ +permissions: 0.935 +debug: 0.930 +device: 0.907 +graphic: 0.905 +semantic: 0.893 +performance: 0.882 +other: 0.873 +network: 0.862 +boot: 0.844 +PID: 0.842 +files: 0.823 +vnc: 0.750 +socket: 0.740 +KVM: 0.705 + +ARM conditional branch after if-then instruction not working + +Hello + +There seems to be an issue with QEMU when debugging if-then condition blocks from the thumb2 instruction set. The following snippet runs fine during normal execution, but keeps hanging at the conditional branch when debugging. The jump at the branch should only be executed as long as $r0 is lower than $r1. Problem is that once both are equal, the execution is not continued past the branch and the program counter never gets popped. + +2000407a: push {lr} +2000407c: movs r0, r6 +2000407e: ldmia r7!, {r1, r6} +20004080: push {r0, r1} +20004082: str.w r6, [r7, #-4]! +20004086: ldr r6, [sp, #0] +20004088: pop {r0, r1} +2000408a: adds r0, #1 +2000408c: cmp r0, r1 +2000408e: itt lt +20004090: pushlt {r0, r1} +20004092: blt.w 0x20004082 ; unpredictable <IT:lt> // <-- GDB hangs here +20004096: pop {pc} + +I have tried to reproduce the problem with inline assembly but for some reason the following example just worked: + +void f() { + static uint8_t stack[256]{}; + stack[255] = 4; + + asm volatile("\n\t" + "push {lr}" + "\n\t" + + // pre-conditions + "movs r7, %[stack]" + "\n\t" + "movs r6, #1" + "\n\t" + + "movs r0, r6" + "\n\t" + "ldmia r7!, {r1, r6}" + "\n\t" + "push {r0, r1}" + "\n\t" + "1:" + "\n\t" + "str.w r6, [r7, #-4]!" + "\n\t" + "ldr r6, [sp, #0]" + "\n\t" + "pop {r0, r1}" + "\n\t" + "adds r0, #1" + "\n\t" + "cmp r0, r1" + "\n\t" + "itt lt" + "\n\t" + "pushlt {r0, r1}" + "\n\t" + + // Original instruction + //"blt.w 0x20004082" // ; unpredictable <IT:lt> + + // Trying to fake it + "blt.w 1b" + "\n\t" + + "pop {pc}" + "\n\t" + : + : [stack] "r"(&stack[255])); +} + +The only real major difference I see to the other code snipped is that the inline assembly is running from flash memory where as the original code runs in ram? Maybe that's a clue somehow? + +Quickly reading through already reported ARM bugs I think this might be related: +https://bugs.launchpad.net/qemu/+bug/1364501 +At least the symptoms sound identical. + + +The versions I'm running are: +QEMU 3.0.0 +arm-none-eabi-gdb 8.2 + +I've also captured some trace output for single stepping from the pushlt to the blt.w instruction with the trace arguments unimp, guest_errors, op, int, exec. + + + +The disassembler is giving you a hint here: + +2000408e: itt lt +20004090: pushlt {r0, r1} +20004092: blt.w 0x20004082 ; unpredictable <IT:lt> // <-- GDB hangs here + +Your code has a "blt" instruction inside an IT block in a way that is archictecturally UNPREDICTABLE, and the CPU is allowed to not behave in the way you might expect it to. + +Your attempt to reproduce the problem is likely generating different instructions (specifically probably a different encoding of the branch instruction). + +On the other hand having QEMU behave differently in singlestep mode and just hang (rather than, say, making the insn UNDEF or treating it as a condition-failed or a condition-passed) is not ideal. + +Do you have a sample binary and QEMU command line that reproduces this? + + +Oh damn it, you're right. Apparently encoding T3 of the branch instruction inside an IT block is always unpredictable... Guess the inline assembly version ignores the .w extension and creates some other encoding that simply works. + +I've attached the .elf which is causing GDB to halt. + +Currently I'm invoking QEMU GNU MCU (some fork with small CortexM extensions) with +qemu-system-gnuarmeclipse -S -s -verbose -semihosting-config enable=on,target=native -mcu STM32F407VG --image arm_unpredictable_branch.elf + +QEMU GNU MCU is currently at version 2.8.0. + +But as I mentioned before I've also tried it with 3.0.0 from the ARCH repository and both versions did the same thing. I think the only difference is the "--image" option which translates to "--kernel" in the original. + +I think this was probably fixed by commit c2d9644e6d517170b, which was in QEMU 3.1.0 -- that commit certainly fixes some kinds of crash if guest code tried to do an UNPREDICTABLE conditional instruction inside an IT block. + +Could you try again with that version of QEMU, or at least provide a repro case with a command line which demonstrates the problem with upstream QEMU? + + +Jesus... I'm sorry about the delay. Eclipse kept dying on me when launching gdb so I had to first set up another IDE since I really really didn't want to single-step through with the command line. + +Anyhow. The behavior of QEMU during debugging is now identical to the one when running it. Even with the unpredictable branch I could step through the code. + +That's great -- thanks for confirming that we've fixed the bug. + + +There might still be some issues... + +Single-stepping works as long as I don't let GDB display the assembly with "display/i $pc". Once GDB decodes and displays every instruction the debugging session gets canceled when I hit the unpredictable branch. I'm not sure if this has anything to do with QEMU though? + +That sounds odd (and also like it might be a gdb bug, since 'display /i' is just implemented as memory reads from QEMU's point of view). I can have a look if you provide repro instructions. + + +I honestly wouldn't know where to start. The wrong branch instructions were created by an embedded forth compiler. I just tried mem-copying a single definition containing one of those erroneous branches to some ram array and then call into it with a pointer. The problem is that the definition assumes certain preconditions like a register pointing to forth's stack and all... Without those preconditions calling the definition immediately hardfaults the core at the very first load instruction. + +After playing around with it for like ~2h I think that's not worth the trouble. I'm glad the QEMU inconsistency is fixed, let's leave it at that (I tested with 3.1.0 btw). :) + +Thank you for all your trouble. + diff --git a/results/classifier/zero-shot/108/permissions/1806824 b/results/classifier/zero-shot/108/permissions/1806824 new file mode 100644 index 000000000..dbca29f27 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1806824 @@ -0,0 +1,144 @@ +permissions: 0.987 +debug: 0.985 +other: 0.978 +semantic: 0.975 +device: 0.973 +PID: 0.965 +performance: 0.964 +socket: 0.963 +boot: 0.956 +vnc: 0.954 +KVM: 0.952 +files: 0.932 +network: 0.889 +graphic: 0.877 + +SIE-200 (TrustZone) MPC: BLK_MAX returns an incorrect value + +Version: +$ qemu-system-arm --version +QEMU emulator version 3.0.92 (v3.1.0-rc2-31-gd522fba244) + +Arm SIE-200 Technical Reference Manual describes that BLK_MAX indicates the maximum value of "block based index register" (BLK_IDX). For example, the value 1 would indicate that BLK_IDX can be 0 or 1. According to my experiments, the AN505 FPGA image apparently follows this behavior. + +In the current implementation of QEMU, it appears to indicate the number of possible values for BLK_IDX, i.e., one plus the value it's supposed to return. + +As per https://www.qemu.org/contribute/report-a-bug/ could you please provide: + + - the command line you are using + - details about the guest you are running (or test case) + + +Command line: + + $ qemu-system-arm -kernel Image.elf -machine mps2-an505 -nographic -d guest_errors -s -semihosting + +The guest I'm running is an unreleased program for a research purpose. I'm not aware of any publicly-known application or operating system that make use of the hardware register concerned by this issue. + +The attached program is an artificial example that reproduces the issue. The program writes a random value to every LUT block within [0, BLK_MAX]. After that, it examines the content of every LUT block to see if it has the intended value or not. + +With the AN505 FPGA image, you get the following output (via UART1, 115200 baud): + + ==== The test program has started ==== + LUT[0x00000000] = 07345a3f + LUT[0x00000001] = 020c7cc6 + ==== The test program has completed ==== + +With QEMU, you get the following output because the LUT index 0x00000040 doesn't actually exist and is wrapped around to the first block: + + $ make qemu + qemu-system-arm -kernel Image.elf -machine mps2-an505 -nographic -d guest_errors -s -semihosting + ==== The test program has started ==== + LUT[0x00000000] = 07345a3f + LUT[0x00000001] = 020c7cc6 + ... + LUT[0x0000003f] = ce3b657b + LUT[0x00000040] = f01ed211 + [ERROR] Verify failed at 0x00000000 - expected 0x07345a3f, got 0xf01ed211. + ==== The test program has completed ==== + +Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch: +http://patchwork.ozlabs.org/patch/1013034/ + + + +Peter Maydell <email address hidden> writes: + +> Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch: +> http://patchwork.ozlabs.org/patch/1013034/ + +I know you had a bunch of M-profile test cases. Once we get tcg system +tests enabled would it be worth porting some of those into the QEMU src +tree? + +There is already one other ARM system test pending for the microbit +tests. + + +> +> +> ** Changed in: qemu +> Status: New => In Progress + + +-- +Alex Bennée + + +On Fri, 14 Dec 2018 at 13:56, Alex Bennée <email address hidden> wrote: +> +> +> Peter Maydell <email address hidden> writes: +> +> > Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch: +> > http://patchwork.ozlabs.org/patch/1013034/ +> +> I know you had a bunch of M-profile test cases. Once we get tcg system +> tests enabled would it be worth porting some of those into the QEMU src +> tree? + +I don't have anything suitable -- unless we have +support for "system test of this guest kernel", in which case +we could add the arm trusted firmware boot/selftests. + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> On Fri, 14 Dec 2018 at 13:56, Alex Bennée <email address hidden> wrote: +>> +>> +>> Peter Maydell <email address hidden> writes: +>> +>> > Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch: +>> > http://patchwork.ozlabs.org/patch/1013034/ +>> +>> I know you had a bunch of M-profile test cases. Once we get tcg system +>> tests enabled would it be worth porting some of those into the QEMU src +>> tree? +> +> I don't have anything suitable -- unless we have +> support for "system test of this guest kernel", in which case +> we could add the arm trusted firmware boot/selftests. + +That's the next step, enabling the building of a known good test case +from an external tree and depositing the images in the right place so we +can use them as tests. + +Things like LTP, kvm-unit-tests and various kernels. + +> +> thanks +> -- PMM + + +-- +Alex Bennée + + +This is now fixed in git master, in commit 619d54a8d854e797bf562, and will be in the upcoming 4.0 release. + + diff --git a/results/classifier/zero-shot/108/permissions/1807073 b/results/classifier/zero-shot/108/permissions/1807073 new file mode 100644 index 000000000..f30268b07 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1807073 @@ -0,0 +1,104 @@ +permissions: 0.958 +performance: 0.956 +semantic: 0.948 +device: 0.943 +other: 0.941 +debug: 0.940 +graphic: 0.936 +vnc: 0.931 +PID: 0.928 +KVM: 0.914 +socket: 0.900 +boot: 0.879 +files: 0.871 +network: 0.856 + +qemu-guest-agent stop work when fsfreeze + +Create a live snapshot, we should first to fsfreeze the file system. We do have only one disk mounted to /: +Filesystem Size Used Avail Use% Mounted on +udev 48G 0 48G 0% /dev +tmpfs 9.5G 8.7M 9.5G 1% /run +/dev/vda1 485G 1.5G 484G 1% / +tmpfs 48G 0 48G 0% /dev/shm +tmpfs 5.0M 0 5.0M 0% /run/lock +tmpfs 48G 0 48G 0% /sys/fs/cgroup +tmpfs 9.5G 0 9.5G 0% /run/user/0 + +snapshot action is OK, when we restore the snapshot, the file system became read-only, and syslog seems stop writing until we fsck /dev/vda1 and mount -o rw,remount /: +Dec 5 00:39:16 systemd[1]: Started Session 180 of user root. +Dec 5 00:45:05 qemu-ga: info: guest-fsfreeze called +Dec 5 07:00:45 kernel: [ 114.623823] EXT4-fs (vda1): re-mounted. Opts: (null) + +So after snapshoting, wo do fsthaw the file system, maybe the qga dose not respond or stop work, this action dose not execute successfully and there is no log to show the status of qemu-guest-agent. + +Version: +libvirt 1.2.17 +qemu 2.3.0 +qemu-guest-agent 2.5 + +Just got almost the same +Ubuntu 16.04 as guest on Centos 7 host, +all will latest updates. + +Execute of +virsh qemu-agent-command inetgw2 '{"execute":"guest-fsfreeze-freeze"}' + +failed with agent not available ( or something like this), but fsfreeze executed in OS +Apr 7 02:28:54 inetgw2 qemu-ga: info: guest-fsfreeze called + +snapshot was created +after this +virsh qemu-agent-command inetgw2 '{"execute":"guest-fsfreeze-thaw"}' +failed too with agent not available + +So Ubuntu 16.04 VM stuck in freezed i/o state. + qemu-guest-age 1:2.5+dfsg-5 + +Same version... + +Thank you! + +btw,I run OEL7 VM on the same host and Ubuntu 18.04 VM, +both have newer qemu-guest-agent: + +18.04: qemu-guest-age 1:2.11+dfsg- + +OEL7: rpm -qi qemu-guest-agent +Name : qemu-guest-agent +Epoch : 10 +Version : 2.12.0 +Release : 2.el7 + +Never had this problem on both oh these. + + +But it happens in some times， this problem dose not occur 100 percent。I can not reproduce when I want to find WHY。So it‘s dangerous in my production environment。 + +I have a problem with fsfreeze that looks very similar to this, though I'm of course not 100% sure it's the same. + +When I try to snapshot one server, fsfreeze-freeze hangs, and after having timeout'ed the qemu agent has crashed: + +# qm guest cmd 105 fsfreeze-status +thawed +# qm guest cmd 105 fsfreeze-freeze +^C << hangs, having to break out of the command +# qm guest cmd 105 fsfreeze-status +QEMU guest agent is not running +# qm reset 105 --skiplock +# qm guest cmd 105 fsfreeze-status +thawed + +Host is Proxmox 5, VM is Centos 7 with Cpanel. This happens every time I try to snapshot the server. Other VM's on the host freeze fine without problem. + +I don't find anything interesting under /var/log. Please let me know if there is anything I can do to help debug this problem. + + + +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.] + +Re-opened in the new bug tracker here: https://gitlab.com/qemu-project/qemu/-/issues/520 + diff --git a/results/classifier/zero-shot/108/permissions/1809075 b/results/classifier/zero-shot/108/permissions/1809075 new file mode 100644 index 000000000..64e0804c8 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1809075 @@ -0,0 +1,96 @@ +permissions: 0.940 +other: 0.922 +semantic: 0.912 +debug: 0.899 +graphic: 0.899 +device: 0.878 +files: 0.868 +network: 0.822 +performance: 0.813 +PID: 0.804 +KVM: 0.793 +vnc: 0.790 +boot: 0.669 +socket: 0.583 + +Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel + +Whenever capslock is pressed on host, both capslock keycode(0x3a 0xba) and capslock LED keycode(0xfa 0xfa) would be sent to the ps2 keycode stream. + +However, capslock LED is handled by another thread, confirmed by tracing `ps2_write_keyboard` with gdb. The keycode of casplock LED might divide + +For example, I sent AaBb but got ABa. I was using vncdotool, so it equals sending `capslock a capslock a capslock b capslock b`. In ps2_queue, I was expecting `3a fa fa ba 1e 9e 3a fa fa ba 1e 9e 3a fa fa ba 30 b0 3a fa fa ba 30 b0`. But actually once in a while, it might not receive such streams. In one case I got `3a fa fa ba 1e 9e 3a ba 1e fa fa 9e 3a ba 30 b0 3a ba 30 b0 fa fa` + +In this specific example, `a` was lost because LED keycode 'jumps in' its keycode. Kernel event device receives below streams +``` +# /dev/input/event receives what is sent from ps2_queue +# I use cap_1 to show capslock key down +cap_1 led caps_0, # 0x3a 0xfa 0xfa 0xba +a_1 a_0 # 0x1e 0x9e +caps_1 caps_0 # 0x3a 0xba +led # 0x1e 0xfa 0xfa 0x1e (we lost `a` here) +caps_1 caps_0 # 0x3a 0xba +b_1 led b_0 # 0x30 0xfa 0xfa 0xb0 +caps_1 caps_0 # 0x3a 0xba +led b_1 b_0 # 0xfa 0xfa 0x30 0xb0 +``` + +I made sure kernel receives the correct key stream as the qemu ps2_queue sends using /proc, ftrace and dynamic_debug. I explained the details in this [post](https://medium.com/@alapha23/quick-peek-into-kernel-land-keyboard-events-handling-with-ftrace-and-dynamic-debug-24a790056d5a) + +So it seems to be a concurrency issue. + +A hacky path on my mind is to skip all `0xfa` in ps2_queue. But I'm not sure if capslock LED is the only stink bug to our ps2 keycode queue as I've seen other keycodes handled by `ps2_write_keyboard` sent to ps2 queue. + +Another solution might be a memory barrier or a lock. Making key down and key up atomic will prevent another thread modifying the ps2 queue unwantedly. + +What do you think? + +### Reproduce steps + +Add `fprintf(stderr, "ps2_queue 0x%x\n", b);` to `hw/input/ps2.c` and re-build qemu. + +- qemu-system-x86_64 -hda <your img> --enable-kvm -m <> -display vnc=:1 +- vncviewer -Shared :5901 + +In guest os, find the keyboard device(very likely to be /dev/input/event0) +``` +sudo evtest /dev/input/event0 +``` + +On host OS +- vncdotool -s 127.0.0.1::5901 type AaBb +Finally, +- record what evtest has received and compared with expected key streams. + +Around once out of five times, we can find keycode lost due to capslock LED. + +Please do not rely on graphics mode output as there are also key loss bugs when wayland internals deal with kernel keyboard events. + +A simply note on some conversion between keycode and keys. Hopefully it would come in handy in debugging: +a 0x1e 0x9e +b 0x30 0xb0 +c 0x2e 0xae +d 0x20 0xa0 +capslock 0x3a 0xba +capslock LED 0xfa 0xfa +ret 0x1c 0x9c +leftshift 0x2a 0xaa + +There is no "capslock LED key event". 0xfa is KBD_REPLY_ACK, and the +device queues it in response to guest port writes. Yes, the ack can +race with actual key events. But IMO that isn't a bug in qemu. + +Probably the linux kernel just throws away everything until it got the +ack for the port write, and that way the key event gets lost. On +physical hardware you will not notice because it is next to impossible +to type fast enough to hit the race window. + +So, go fix the kernel. + +Alternatively fix vncdotool to send uppercase letters properly with +shift key pressed. Then qemu wouldn't generate capslock key events +(that happens because qemu thinks guest and host capslock state is out +of sync) and the guests's capslock led update request wouldn't get into +the way. + + diff --git a/results/classifier/zero-shot/108/permissions/1817239 b/results/classifier/zero-shot/108/permissions/1817239 new file mode 100644 index 000000000..2564de1c5 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1817239 @@ -0,0 +1,105 @@ +permissions: 0.968 +semantic: 0.960 +debug: 0.955 +PID: 0.953 +performance: 0.952 +other: 0.951 +device: 0.947 +graphic: 0.943 +vnc: 0.929 +socket: 0.927 +boot: 0.921 +files: 0.909 +network: 0.867 +KVM: 0.866 + +add '--targets' option to qemu-binfmt-conf.sh + +I'd like to ask for the addition of option '--targets' to scripts/qemu-binfmt-conf.sh, in order to allow registering the interpreters for the given list of architectures only, instead of using all of the ones defined in qemu_target_list. The following is a possible patch that implements it: + + qemu-binfmt-conf.sh | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/qemu-binfmt-conf.sh b/qemu-binfmt-conf.sh +index b5a1674..be4a19b 100644 +--- a/qemu-binfmt-conf.sh ++++ b/qemu-binfmt-conf.sh +@@ -170,6 +170,7 @@ usage() { + Usage: qemu-binfmt-conf.sh [--qemu-path PATH][--debian][--systemd CPU] + [--help][--credential yes|no][--exportdir PATH] + [--persistent yes|no][--qemu-suffix SUFFIX] ++ [--targets TARGETS] + + Configure binfmt_misc to use qemu interpreter + +@@ -189,6 +190,8 @@ Usage: qemu-binfmt-conf.sh [--qemu-path PATH][--debian][--systemd CPU] + --persistent: if yes, the interpreter is loaded when binfmt is + configured and remains in memory. All future uses + are cloned from the open file. ++ --targets: comma-separated list of targets. If provided, only ++ the targets in the list are registered. + + To import templates with update-binfmts, use : + +@@ -324,7 +327,7 @@ CREDENTIAL=no + PERSISTENT=no + QEMU_SUFFIX="" + +-options=$(getopt -o ds:Q:S:e:hc:p: -l debian,systemd:,qemu-path:,qemu-suffix:,exportdir:,help,credential:,persistent: -- "$@") ++options=$(getopt -o ds:Q:S:e:hc:p:t: -l debian,systemd:,qemu-path:,qemu-suffix:,exportdir:,help,credential:,persistent:,targets: -- "$@") + eval set -- "$options" + + while true ; do +@@ -380,6 +383,10 @@ while true ; do + shift + PERSISTENT="$1" + ;; ++ -t|--targets) ++ shift ++ qemu_target_list="$(echo "$1" | tr ',' ' ')" ++ ;; + *) + break + ;; +-- +2.20.1 + +On 22/02/2019 04:31, Launchpad Bug Tracker wrote: +> I'd like to ask for the addition of option '--targets' to scripts/qemu- +> binfmt-conf.sh, in order to allow registering the interpreters for the +> given list of architectures only, instead of using all of the ones +> defined in qemu_target_list. The following is a possible patch that +> implements it: +> +> qemu-binfmt-conf.sh | 9 ++++++++- +> 1 file changed, 8 insertions(+), 1 deletion(-) + +Please send your patch to the qemu-devel mailing list. + +I think it's a good idea but we should homogenize "--debian" and +"--systemd": remove the parameter from "--systemd" to generate by +default all the targets, and allow the user to provide a subset of the +targets using the newly introduced "--target" parameter. + +Thanks, +Laurent + + + +I submitted a first version some days ago, which homogeneized the implementation, as suggested by Laurent Vivier. It received some feedback from Eric Blake. A patchset (v3) is ready for review: https://patchew.org/QEMU/20190306031221.GA53@03612eec87fc/# + +The feature requested in this issue is included in the patchset: + +[Qemu-devel] [PATCH v3 6/10] qemu-binfmt-conf.sh: generalize <CPU> to positional <CPUS> +https://patchew.org/QEMU/20190306031221.GA53@03612eec87fc/20190306045019.GF75@03612eec87fc/ + +Note that, instead of adding a parameter named `--target`, positional arguments are used, which where not being processed at all. + +This series appears to have stalled as of v7: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04241.html -- moving back to 'New' status. + + +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/zero-shot/108/permissions/1818880 b/results/classifier/zero-shot/108/permissions/1818880 new file mode 100644 index 000000000..25f08217b --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1818880 @@ -0,0 +1,249 @@ +permissions: 0.933 +graphic: 0.919 +debug: 0.907 +other: 0.904 +KVM: 0.892 +device: 0.889 +performance: 0.861 +semantic: 0.860 +vnc: 0.859 +socket: 0.831 +boot: 0.822 +network: 0.816 +PID: 0.798 +files: 0.730 + +Deadlock when detaching network interface + +[Impact] +Qemu guests hang indefinitely + +[Description] +When running a Qemu guest with VirtIO network interfaces, detaching an interface that's currently being used can result in a deadlock. The guest instance will hang and become unresponsive to commands, and the only option is to kill -9 the instance. +The reason for this is a dealock between a monitor and an RCU thread, which will fight over the BQL (qemu_global_mutex) and the critical RCU section locks. The monitor thread will acquire the BQL for detaching the network interface, and fire up a helper thread to deal with detaching the network adapter. That new thread needs to wait on the RCU thread to complete the deletion, but the RCU thread wants the BQL to commit its transactions. +This bug is already fixed upstream (73c6e4013b4c rcu: completely disable pthread_atfork callbacks as soon as possible) and included for other series (see below), so we don't need to backport it to Bionic onwards. + +Upstream commit: https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c + +$ git describe --contains 73c6e4013b4c +v2.10.0-rc2~1^2~8 + +$ rmadison qemu +===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe | amd64, ... + qemu | 1:2.11+dfsg-1ubuntu7 | bionic/universe | amd64, ... + qemu | 1:2.12+dfsg-3ubuntu8 | cosmic/universe | amd64, ... + qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe | amd64, ... + +[Test Case] +Being a racing condition, this is a tricky bug to reproduce consistently. We've had reports of users running into this with OpenStack deployments and Windows Server guests, and the scenario is usually like this: +1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network interface +2) Stress the network interface with e.g. Windows HLK test suite or similar +3) Repeatedly attach/detach the network adapter that's in use +It usually takes more than ~4000 attach/detach cycles to trigger the bug. + +[Regression Potential] +Regressions for this might arise from the fact that the fix changes RCU lock code. Since this patch has been upstream and in other series for a while, it's unlikely that it would regressions in RCU code specifically. Other code that makes use of the RCU locks (MMIO and some monitor events) will be thoroughly tested for any regressions with autokpkgtest and scripted Qemu runs. + + + +Patch v2: +Added missing DEP3 info and corrected pkg version + + + +Ok, for such complicated-to-reproduce issues I can understand it might be hard to actually perform verification. In this case besides running the listed test case (which might or might not actually trigger the problem), could you also do some additional smoketesting/dogfooding of the package once it's in -proposed to make sure we didn't regress? (things like running it with different guests and playing around) Thanks! + +Hello Heitor, or anyone else affected, + +Accepted qemu into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.35 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 and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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. + +Hi, + +As this bug is very hard to trigger, I've been running some tests with qemu +1:2.5+dfsg-5ubuntu10.35 to see if we didn't regress or break anything with the +new patch. My test setup is as follows: + +1) Create new QEMU guest with uvt-kvm or virt-install + # uvt-kvm create xenial release=xenial --cpu 8 +2) Install iperf and latest stress-ng from git. Upstream stress-ng is desired to have a consistent load on each guest + # apt install iperf + # git clone git://kernel.ubuntu.com/cking/stress-ng + # cd stress-ng + # make clean + # make +3) Start an iperf server instance on the host + root@host:~# iperf -s +4) Stress the guest instance with the iperf-retry.sh script and stress-ng (run those commands in different screen windows) + # ./stress-ng --cpu 4 --hdd 4 --io 4 --vm 4 + # ./stress-ng --class network --all 2 + # ./iperf-retry.sh +5) Attach and detach network adapter using the hotplug.sh script + root@host:~# ./hotplug.sh xenial 52:54:00:19:7a:21 + +I've tested this with different guests, including Xenial, Bionic and Disco. +Guest instances performed more than ~2000 hotplug cycles each: + root@host:~# ./hotplug.sh xenial 52:54:00:19:7a:21 + Detach #1 + Interface detached successfully + + Detach #2 + Interface detached successfully + + ... + Detach #2168 + Interface detached successfully + +The QEMU guests work correctly through and after the tests, and it doesn't +look like we ran into any regressions due to the RCU patch. + +Thanks, +Heitor + + + + + + +Thanks, this should be enough in that case. Releasing. + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been 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:2.5+dfsg-5ubuntu10.35 + +--------------- +qemu (1:2.5+dfsg-5ubuntu10.35) xenial; urgency=medium + + * Fix deadlock when detaching network interface (LP: #1818880) + Fixed by upstream patch: + - d/p/lp-1818880-rcu-disable-atfork.patch: rcu: completely disable + pthread_atfork callbacks as soon as possible + + -- <email address hidden> (Heitor R. Alves de Siqueira) Fri, 01 Mar 2019 15:59:01 -0300 + +We don't have qemu in the rocky cloud archive so this is fixed via bionic. + +The Stein cloud archive has qemu 1:3.1+dfsg-2ubuntu3~cloud0 which corresponds to the current version in disco, so I'm marking this as fix released for Stein. + +I've just accepted qemu version 1:2.11+dfsg-1ubuntu7.12~cloud0 into queens-proposed however the changelog doesn't mention (LP: #1818880) anywhere. Seeing that bionic is marked as fix released I assume queens can be marked as fix released. + +Heiter, please if fixes are needed for ocata or pike can you provide us with patches? We need to be careful not to skip cloud archive releases (ie. if this is fixed in xenial but not the ocata and pike cloud archive). + +@corey.bryant I just spoke to @halves and he said that the series targets above Bionic are an oversight since this patch landed in anything newer than 2.11 (i.e. bionic version). We do also need this for Trusty-Mitaka though so I have added that as a UCA target. I'll let @halves reply about O/P. + +@@corey.bryant I've checked Pike and it has the fix included already, so I'm attaching a debdiff for Ocata only. + +@hopem About Trusty-Mitaka, it seems that it automatically pulled the patch from Xenial's release so it looks good too. + +Hello Heitor, or anyone else affected, + +Accepted qemu into ocata-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. To enable the -proposed repository: + + sudo add-apt-repository cloud-archive:ocata-proposed + sudo apt-get update + +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, and change the tag from verification-ocata-needed to verification-ocata-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ocata-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Hello Heitor, or anyone else affected, + +Accepted qemu into mitaka-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. To enable the -proposed repository: + + sudo add-apt-repository cloud-archive:mitaka-proposed + sudo apt-get update + +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, and change the tag from verification-mitaka-needed to verification-mitaka-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-mitaka-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + + +Hi, + +I've done some regression testing on qemu from mitaka-proposed, following the procedure from comment #6: + +$ dpkg -l | grep qemu +ii ipxe-qemu 1.0.0+git-20131111.c3d1e78-2ubuntu1.1 all PXE boot firmware - ROM images for qemu +ii qemu-block-extra:amd64 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64 extra block backend modules for qemu- +system and qemu-utils +ii qemu-kvm 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64 QEMU Full virtualization +ii qemu-system-common 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64 QEMU utilities + +$ /hotplug.sh xenial 52:54:00:b3:ef:bc +Detach #1 +Interface detached successfully + +Detach #2 +Interface detached successfully + +... +Detach #2617 +Interface detached successfully + +This was performed while iperf and stress-ng were running. The guest works correctly through and after the tests. + +Thanks, +Heitor + + +Hi, + +I've done some regression testing on qemu from ocata-proposed, following the procedure from comment #6: + +$ dpkg -l | grep qemu +ii ipxe-qemu 1.0.0+git-20150424.a25a16d-1ubuntu1.2 all PXE boot firmware - ROM images for qemu +ii qemu-block-extra:amd64 1:2.8+dfsg-3ubuntu2.9~cloud4 amd64 extra block backend modules for qemu-system and qemu- +utils +ii qemu-kvm 1:2.8+dfsg-3ubuntu2.9~cloud4 amd64 QEMU Full virtualization +ii qemu-system-common 1:2.8+dfsg-3ubuntu2.9~cloud4 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 1:2.8+dfsg-3ubuntu2.9~cloud4 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:2.8+dfsg-3ubuntu2.9~cloud4 amd64 QEMU utilities + +$ /hotplug.sh xenial 52:54:00:bb:23:77 +Detach #1 +Interface detached successfully + +Detach #2 +Interface detached successfully + +... +Detach #2722 +Interface detached successfully + +This was performed while iperf and stress-ng were running. The guest works correctly through and after the tests. + +Thanks, +Heitor + + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. 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:2.8+dfsg-3ubuntu2.9~cloud4 +--------------- + + qemu (1:2.8+dfsg-3ubuntu2.9~cloud4) xenial-ocata; urgency=medium + . + * Fix deadlock when detaching network interface (LP: #1818880) + Fixed by upstream patch: + - d/p/lp-1818880-rcu-disable-atfork.patch: rcu: completely disable + pthread_atfork callbacks as soon as possible + + diff --git a/results/classifier/zero-shot/108/permissions/1821839 b/results/classifier/zero-shot/108/permissions/1821839 new file mode 100644 index 000000000..e2b4674d0 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1821839 @@ -0,0 +1,197 @@ +permissions: 0.965 +other: 0.962 +debug: 0.945 +device: 0.942 +graphic: 0.942 +performance: 0.940 +vnc: 0.939 +semantic: 0.937 +PID: 0.935 +files: 0.921 +KVM: 0.918 +socket: 0.915 +network: 0.900 +boot: 0.870 + +qemu 4.0 doesnt support glsl 3.0 but yes older versions, that have no sense IMO + +tested on qemu 4.0.rc1 on rpi3, mesa 19.x +maybe I am a bit confused, but why it can use and older version from my mesa driver, it should pickup the right version instead of going to the latest. + +pi@pi:~/Desktop/armbian/windows_95_vdi $ qemu-system-i386 -cpu qemu32 -m 32 -display sdl,gl=on -device virtio-vga,virgl=on -soundhw sb16 +qemu_gl_create_compile_shader: compile vertex error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile fragment error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile vertex error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile fragment error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +the sames happen on mesa 13.x (default mesa included on raspbian) + +GLXINFO + +pi@pi:~/Desktop/armbian/windows_95_vdi $ glxinfo +name of display: :0 +display: :0 screen: 0 +direct rendering: Yes +server glx vendor string: SGI +server glx version string: 1.4 +server glx extensions: + GLX_ARB_create_context, GLX_ARB_create_context_profile, + GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, + GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, + GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, + GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_texture_from_pixmap, + GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, + GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, + GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, + GLX_SGI_make_current_read, GLX_SGI_swap_control +client glx vendor string: Mesa Project and SGI +client glx version string: 1.4 +client glx extensions: + GLX_ARB_context_flush_control, GLX_ARB_create_context, + GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, + GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, + GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, + GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, + GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, + GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, + GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, + GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, + GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, + GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, + GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, + GLX_SGI_swap_control, GLX_SGI_video_sync +GLX version: 1.4 +GLX extensions: + GLX_ARB_create_context, GLX_ARB_create_context_profile, + GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, + GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, + GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, + GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, + GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, + GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, + GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, + GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, + GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, + GLX_SGI_swap_control, GLX_SGI_video_sync +Extended renderer info (GLX_MESA_query_renderer): + Vendor: Broadcom (0x14e4) + Device: VC4 V3D 2.1 (0xffffffff) + Version: 19.1.0 + Accelerated: yes + Video memory: 938MB + Unified memory: yes + Preferred profile: compat (0x2) + Max core profile version: 0.0 + Max compat profile version: 2.1 + Max GLES1 profile version: 1.1 + Max GLES[23] profile version: 2.0 +OpenGL vendor string: Broadcom +OpenGL renderer string: VC4 V3D 2.1 +OpenGL version string: 2.1 Mesa 19.1.0-devel (git-f1122f78b7) +OpenGL shading language version string: 1.20 +OpenGL extensions: + GL_AMD_shader_trinary_minmax, GL_APPLE_packed_pixels, + GL_ARB_ES2_compatibility, GL_ARB_buffer_storage, + GL_ARB_clear_buffer_object, GL_ARB_color_buffer_float, + GL_ARB_compressed_texture_pixel_storage, GL_ARB_copy_buffer, + GL_ARB_debug_output, GL_ARB_depth_texture, GL_ARB_draw_buffers, + GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, + GL_ARB_explicit_uniform_location, GL_ARB_fragment_coord_conventions, + GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, + GL_ARB_fragment_shader, GL_ARB_framebuffer_object, + GL_ARB_framebuffer_sRGB, GL_ARB_get_program_binary, + GL_ARB_get_texture_sub_image, GL_ARB_half_float_pixel, + GL_ARB_half_float_vertex, GL_ARB_internalformat_query, + GL_ARB_internalformat_query2, GL_ARB_invalidate_subdata, + GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multi_bind, + GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, + GL_ARB_occlusion_query2, GL_ARB_pixel_buffer_object, + GL_ARB_point_parameters, GL_ARB_point_sprite, + GL_ARB_program_interface_query, GL_ARB_provoking_vertex, + GL_ARB_robustness, GL_ARB_sampler_objects, GL_ARB_separate_shader_objects, + GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, + GL_ARB_sync, GL_ARB_texture_barrier, GL_ARB_texture_border_clamp, + GL_ARB_texture_compression, GL_ARB_texture_cube_map, + GL_ARB_texture_env_add, GL_ARB_texture_env_combine, + GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, + GL_ARB_texture_mirrored_repeat, GL_ARB_texture_multisample, + GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, + GL_ARB_texture_storage, GL_ARB_texture_storage_multisample, + GL_ARB_texture_swizzle, GL_ARB_transpose_matrix, + GL_ARB_vertex_array_object, GL_ARB_vertex_attrib_binding, + GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, + GL_ARB_window_pos, GL_ATI_blend_equation_separate, GL_ATI_draw_buffers, + GL_ATI_fragment_shader, GL_ATI_separate_stencil, + GL_ATI_texture_env_combine3, GL_EXT_abgr, GL_EXT_bgra, + GL_EXT_blend_color, GL_EXT_blend_equation_separate, + GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, + GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, + GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_blit, + GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_multisample_blit_scaled, + GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, + GL_EXT_gpu_program_parameters, GL_EXT_multi_draw_arrays, + GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, + GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, + GL_EXT_provoking_vertex, GL_EXT_rescale_normal, GL_EXT_secondary_color, + GL_EXT_separate_specular_color, GL_EXT_shader_integer_mix, + GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, + GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, + GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, + GL_EXT_texture_env_add, GL_EXT_texture_env_combine, + GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_object, + GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_texture_sRGB_decode, + GL_EXT_texture_swizzle, GL_EXT_vertex_array, GL_IBM_multimode_draw_arrays, + GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, + GL_INGR_blend_func_separate, GL_KHR_context_flush_control, GL_KHR_debug, + GL_KHR_no_error, GL_KHR_texture_compression_astc_ldr, + GL_KHR_texture_compression_astc_sliced_3d, GL_MESA_pack_invert, + GL_MESA_tile_raster_order, GL_MESA_window_pos, GL_NV_blend_square, + GL_NV_fog_distance, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, + GL_NV_texgen_reflection, GL_NV_texture_barrier, + GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_OES_EGL_image, + GL_OES_read_format, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, + GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays + +OpenGL ES profile version string: OpenGL ES 2.0 Mesa 19.1.0-devel (git-f1122f78b7) +OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 +OpenGL ES profile extensions: + GL_APPLE_texture_max_level, GL_EXT_blend_minmax, + GL_EXT_compressed_ETC1_RGB8_sub_texture, GL_EXT_discard_framebuffer, + GL_EXT_draw_buffers, GL_EXT_draw_elements_base_vertex, GL_EXT_frag_depth, + GL_EXT_map_buffer_range, GL_EXT_multi_draw_arrays, + GL_EXT_occlusion_query_boolean, GL_EXT_read_format_bgra, + GL_EXT_separate_shader_objects, GL_EXT_texture_border_clamp, + GL_EXT_texture_format_BGRA8888, GL_EXT_unpack_subimage, + GL_KHR_context_flush_control, GL_KHR_debug, GL_KHR_no_error, + GL_KHR_texture_compression_astc_ldr, + GL_KHR_texture_compression_astc_sliced_3d, GL_MESA_tile_raster_order, + GL_NV_draw_buffers, GL_NV_fbo_color_attachments, GL_NV_read_buffer, + GL_NV_read_depth, GL_NV_read_depth_stencil, GL_NV_read_stencil, + GL_OES_EGL_image, GL_OES_EGL_image_external, GL_OES_EGL_sync, + GL_OES_compressed_ETC1_RGB8_texture, GL_OES_depth24, GL_OES_depth_texture, + GL_OES_draw_elements_base_vertex, GL_OES_element_index_uint, + GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer, + GL_OES_packed_depth_stencil, GL_OES_required_internalformat, + GL_OES_rgb8_rgba8, GL_OES_stencil8, GL_OES_surfaceless_context, + GL_OES_texture_3D, GL_OES_texture_border_clamp, GL_OES_texture_npot, + GL_OES_vertex_array_object, GL_OES_vertex_half_float + +I didnt understand properly the output, it only can use opengl es 3.0. you should put that info because when i compile qemu it pass and it should if doesnt support my opengl setup. + +it shouldn't+ + + +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/167 + + diff --git a/results/classifier/zero-shot/108/permissions/1822012 b/results/classifier/zero-shot/108/permissions/1822012 new file mode 100644 index 000000000..8f9e0b468 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1822012 @@ -0,0 +1,85 @@ +permissions: 0.973 +graphic: 0.971 +semantic: 0.969 +device: 0.964 +debug: 0.963 +performance: 0.959 +socket: 0.958 +other: 0.944 +boot: 0.944 +files: 0.940 +PID: 0.935 +network: 0.927 +vnc: 0.926 +KVM: 0.814 + +powernv machine complains of missing skiboot files + +Hi, I want to use the powernv machine from the qemu-system-ppcle application. However, when I specify this machine, qemu complains that it can't find the skiboot files. + +I noticed that skiboot is available for Ubuntu, but only for the PPC[64] hosts. Well, I just need skiboot files for qemu on amd64 hosts. + +Hmm, looks like Debian has a package for these missing qemu files: + +https://packages.debian.org/sid/qemu-skiboot + +Could we promote these to Ubuntu repositories, and fix the qemu packages so that they automatically depend on the necessary BIOS packages? For example, openbios-ppc should also be installed when qemu-system-ppc[64[le]] are installed. + +This sounds like a bug in the packaging of Ubuntu, so I've moved it to the Ubuntu tracker + +skiboot.lid is available on all architectures as part of qemu-system-data package which is "all", not ppc specific. +The latter is pulled by the binary package qemu-system-ppc, so no particular action is needed. + +--- +ubuntu@ubuntu:~$ uname -a +Linux ubuntu 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux +ubuntu@ubuntu:~$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.2 LTS +Release: 20.04 +Codename: focal +ubuntu@ubuntu:~$ dpkg -S /usr/share/qemu/skiboot.lid +qemu-system-data: /usr/share/qemu/skiboot.lid +ubuntu@ubuntu:~$ dpkg -l|grep qemu +ii ipxe-qemu 1.0.0+git-20190109.133f4c4-0ubuntu3.2 all PXE boot firmware - ROM images for qemu +ii ipxe-qemu-256k-compat-efi-roms 1.0.0+git-20150424.a25a16d-0ubuntu4 all PXE boot firmware - Compat EFI ROM images for qemu +ii qemu-block-extra:amd64 1:4.2-3ubuntu6.15 amd64 extra block backend modules for qemu-system and qemu-utils +ii qemu-slof 20191209+dfsg-1 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system-common 1:4.2-3ubuntu6.15 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-data 1:4.2-3ubuntu6.15 all QEMU full system emulation (data files) +ii qemu-system-gui:amd64 1:4.2-3ubuntu6.15 amd64 QEMU full system emulation binaries (user interface and audio support) +ii qemu-system-ppc 1:4.2-3ubuntu6.15 amd64 QEMU full system emulation binaries (ppc) +ii qemu-utils 1:4.2-3ubuntu6.15 amd64 QEMU utilities +--- + +Debian qemu-skiboot package was initially used to distribute skiboot.lid but it was soon after +replaced by qemu-system-data. At the moment qemu-skiboot is virtual in debian and it is provided +by qemu-system-data. + +I tested powernv emulation on focal with that default setup and following this documentation: +https://qemu.readthedocs.io/en/latest/system/ppc/powernv.html +and I didn't encounter missing skiboot.lid issues. + +Next time please provide logs, details about your ubuntu version and packages versions. + +F. + +Thank you for your bug report, and thanks Frédéric for the initial triage. + +I agree with Frédéric's findings here: the skiboot file is properly installed in a Focal system by qemu-system-data. Also, as he mentioned, qemu-skiboot is a virtual package; it doesn't really provide anything. + +I am marking this bug as Incomplete because we were unable to reproduce the issue. Moreover, I would like to reinforce Frédéric's request here and ask that you please provide more details, like what exactly you're trying to do, the commands you're using, the output you're seeing, etc. + +Thanks. + +As Frederick said (he did the change - thanks!) this is fixed for a while now. +In particular: + +1401 qemu (1:4.2-2) unstable; urgency=medium +... +1406 [ Frédéric Bonnard ] +1407 * Enable powernv emulation with skiboot firmware + +Which in terms of Ubuntu releases translates to >=Focal + diff --git a/results/classifier/zero-shot/108/permissions/1826827 b/results/classifier/zero-shot/108/permissions/1826827 new file mode 100644 index 000000000..ea6722318 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1826827 @@ -0,0 +1,118 @@ +permissions: 0.955 +device: 0.939 +semantic: 0.937 +debug: 0.936 +boot: 0.934 +graphic: 0.925 +vnc: 0.922 +PID: 0.917 +other: 0.911 +performance: 0.905 +files: 0.897 +KVM: 0.857 +socket: 0.843 +network: 0.813 + +dtc crash; pnv_dt_serial cannot find lpc's phandle + +pnv_dt_serial has a line which is supposed to set the interrupt-parent of the "isa-serial@i3f8" node to the phandle of "lpc@0". + +To that end, it calls fdt_get_phandle as shown below: +_FDT((fdt_setprop_cell(fdt, node, "interrupt-parent", fdt_get_phandle(fdt, lpc_off)))); + +The function fdt_get_phandle fails to find the property "phandle" (or "linux,phandle") for the lpc node. Consequently, pnv_dt_serial sets the interrupt-parent to 0. + + + + + +Now boot the qemu-system-ppc64 powernv machine, and extract the fdt by using the qemu monitor's pmemsave command, taking help of the OPAL firmware's messages to locate the fdt in the physical ram. + +qemu-system-ppc64 -m 1g -machine powernv,num-chips=1 \ +-cpu power9 -smp 2,cores=2,threads=1 -accel tcg,thread=multi \ +-kernel ./vmlinux \ +-append 'disable_radix' \ +-serial mon:stdio -nographic -nodefaults + +The kernel vmlinux contains nothing but a single instruction which loops infintely, so that we can gather OPAL's messages, especially the one below: + +[ 0.168845963,5] INIT: Starting kernel at 0x20000000, fdt at 0x304b0b70 14404 bytes + + + + + +Once the fdt is dumped to a file, run the following: + +'dtc -O dtb -I dts -o out.dts dtb' + + +After a few warnings, the dtc application crashes because an assertion was fired. + +1.dts: Warning (unit_address_vs_reg): /lpcm-opb@6030000000000/lpc@0: node has a unit name, but no reg property +1.dts: Warning (simple_bus_reg): /lpcm-opb@6030000000000/lpc@0: missing or empty reg/ranges property +1.dts: Warning (avoid_unnecessary_addr_size): /ibm,opal: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property +1.dts: Warning (unique_unit_address): /interrupt-controller@0: duplicate unit-address (also used in node /memory@0) +1.dts: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 'stdout-path' instead +dtc: livetree.c:575: get_node_by_phandle: Assertion `generate_fixups' failed. +Aborted (core dumped) + + + +The assertion is fired because get_node_by_phandle receives a phandle value of 0, which is unexpected, unless fixups are needed (They are not, when running the dtc command). + + + + +Back inside pnv_dt_serial, if the line that sets "interrupt-parent" for the serial device node is commented out, the dtc crash is prevented. Looking at hw/ppc/e500.c, it takes care of allocating necessary phandle values in the nodes, so a similar method can be adopted for powernv. + + +The dtb is attached. + + + +IIUC there are two bugs here + +1) The powernv machine in qemu is attempting to use a phandle for node that doesn't have one. It will need to assign a phandle to that node and re-use it elsewhere. This should be pretty straightforward. + +2) dtc is crashing with an assertion - that shouldn't happen, even on bad input it should error out rather than crashing. The problem also occurs with current upstream dtc - I'll try to investigate this. + + +Btw, I'm assuming where you say 'dtc -O dtb -I dts -o out.dts dtb' you actually meant 'dtc -I dtb -O dts -o out.dts dtb' (i.e. -I and -O swapped around), since you're trying to decompile a blob to source rather than the other way around. + + +> Btw, I'm assuming where you say... +My bad. Yes, you are correct. The problem is seen when decompiling the blob to source. + + +> 1) The powernv machine in qemu is attempting to use a phandle for node +> that doesn't have one. + +True. + + +> 2) dtc is crashing with an assertion - that shouldn't happen, even on bad +> input it should error out rather than crashing. The problem also occurs +> with current upstream dtc - I'll try to investigate this. + +The assertion says that "if dtc is trying to get a node by its phandle, and if the input phandle is 0 or -1, then we better be processing plugins, as that is the only mode where we allow such values for a phandle." + + +If one removes the specific assertion which is triggered, the crash is avoided. Then, dtc prints +this (relevant) message before exiting: + + +"Warning (interrupts_property): /lpcm-opb@6030000000000/lpc@0/isa-serial@i3f8:interrupt-parent: Bad phandle" + + +The message confirms qemu's inability to set the interrupt-parent of isa-serial@i3f8 to the correct, expected value. Depending on the point of view, that warning can be considered as the error that you want dtc to print (although dtc, instead of stopping at this warning, continues ahead instead, and generates a dts with interrupt-parent of that serial device set to 0). + + +When one looks at that generated dts source, two other siblings of isa-serial@i3f8, ipmi-bt@ie4 and mbox@i1000 are found, which have the correct value for their interrupt-parent property. A bit of debugging showed that these two devices are populated by the skiboot firmware (and not by qemu). + +This assertion should be fixed by upstream commit 8f695676227 "Avoid assertion in check_interrupts_property()". That should be included in dtc v1.5.1 which I hope to release soon. + + +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" or "Confirmed" 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. + diff --git a/results/classifier/zero-shot/108/permissions/1829459 b/results/classifier/zero-shot/108/permissions/1829459 new file mode 100644 index 000000000..4fd5cfc21 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1829459 @@ -0,0 +1,119 @@ +permissions: 0.970 +other: 0.965 +device: 0.949 +performance: 0.945 +PID: 0.942 +graphic: 0.938 +debug: 0.935 +socket: 0.931 +network: 0.913 +vnc: 0.905 +semantic: 0.904 +files: 0.899 +KVM: 0.885 +boot: 0.845 + +qemu seems to lack support for pid namespace. + +# Version + +qemu-4.0.0 + +# commands used to launch qemu-aarch64 in user mode. + +printf '%s\n' ':qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}" >/proc/sys/fs/binfmt_misc/register + +> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin +> sudo chroot $RPI /bin/ksh -l + +# host + +Gentoo Linux amd64 + +# Guest + +Gentoo Linux aarch64 + +# The problem that I have + +"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid argument". +"emerge" is Gentoo's package manager that compiles and installs packages. + +# How to reproduce the issue + +Execute + +unshare --pid -- echo hello world + +or + +python -c "import portage.process; portage.process.spawn(['echo', 'hello', 'world'], unshare_pid=True)" + +PID namespace prevents to execute some syscalls, even if you use --map-root-user. This is managed at kernel level by the capabilities. + +Could you try to do the exact same thing with the native architecture binaries in the chroot to see if the problem really comes from qemu-user? + +Could you try to use the latest unshare version (util-linux package) that adds a "--keep-caps" parameter (v2.35-rc1) to preserve the capabilities? + +In a native chroot, `sudo unshare --pid -- echo hello world` works without a problem. + +In a qemu-aarch64 chroot, `sudo unshare --keep-caps --pid -- echo hello world` fails with the same error described in this issue. + +`qemu: qemu_thread_create: Invalid argument` + +According to `man unshare`, --keep-caps seems to apply only to user namespace. + +I think you should investigate + +`qemu: qemu_thread_create: Invalid argument` + +The same issue persists in qemu-5.2.0. + +----------------------------------------- +# qemu-aarch64 --version +qemu-aarch64 version 5.2.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +----------------------------------------- + +Symptoms when running inside the aarch64 chroot, with both aarch64 and x86_64 binaries: +----------------------------------------- +# which unshare bash +/usr/bin/unshare +/bin/bash +# file $(!!) +file $(which unshare bash) +/usr/bin/unshare: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped +/bin/bash: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped +# unshare --pid -- bash -c 'echo hello world' +qemu: qemu_thread_create: Invalid argument +Aborted (core dumped) +# # --- switch to an x86_64 shell _inside_ the chroot +# LD_LIBRARY_PATH=/x86_64/lib64 PATH=/x86_64/bin:$PATH bash +# which unshare bash +/x86_64/bin/unshare +/x86_64/bin/bash +# file $(!!) +file $(which unshare bash) +/x86_64/bin/unshare: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped +/x86_64/bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped +# unshare --pid -- bash -c 'echo hello world' +hello world +# +----------------------------------------- + +I can share the core dump, in case that's useful. + +On this system, the qemu-aarch64 binary on the host is statically built +and binfmt_misc is configured as follows: +----------------------------------------- +:aarch64:M::\x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-aarch64:CF +----------------------------------------- + + +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/172 + + diff --git a/results/classifier/zero-shot/108/permissions/1829682 b/results/classifier/zero-shot/108/permissions/1829682 new file mode 100644 index 000000000..5770952c2 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1829682 @@ -0,0 +1,834 @@ +permissions: 0.972 +debug: 0.970 +performance: 0.963 +other: 0.958 +device: 0.955 +boot: 0.954 +semantic: 0.950 +graphic: 0.949 +network: 0.937 +vnc: 0.937 +socket: 0.935 +files: 0.933 +PID: 0.930 +KVM: 0.890 + +QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX + +Built from source on a debian system + +Linux db08 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux +gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) + +Last git commit (from queued gdibson repository) + +starting AIX 7.2 TL 2 SP 2 with the following : (the install was done under qemu 3.1.0) + +qemu-system-ppc64 -M pseries \ + -cpu power7 \ + -cdrom AIX_v7.2_Install_7200-02-02-1806_DVD_1_of_2_32018.iso \ + -net nic \ + -net tap,ifname=tap2,script=no \ + -drive file=DISK1.IMG,if=none,id=drive-virtio-disk0 \ + -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ + -m 4G \ + -serial stdio \ + -monitor unix:ms,server,nowait \ + -accel tcg \ + -k fr \ + -nographic \ + -prom-env input-device=/vdevice/vty@71000000 \ + -prom-env output-device=/vdevice/vty@71000000 \ + -prom-env diag-switch?=false \ + -prom-env boot-command="boot /pci@800000020000000/scsi@2/disk@100000000000000 -s verbose" + +Yields this : + + +^M +SLOF^[[0m^[[?25l **********************************************************************^M +^[[1mQEMU Starting^M +^[[0m Build Date = Jan 14 2019 18:00:39^M + FW Version = git-a5b428e1c1eae703^M + Press "s" to enter Open Firmware.^M^M +^M^M +^[[0m^[[?25hC0000^MC0100^MC0120^MC0140^MC0200^MC0240^MC0260^MC02E0^MC0300^MC0320^MC0340^MC0360^MC0370^MC0380^MC0371^MC0372^MC0373^MC0374^MC03F0^MC0400^MC0480^MC04C0^MC04D0^MC0500^MPopulating /vdevice methods^M +Populating /vdevice/vty@71000000^M +Populating /vdevice/nvram@71000001^M +Populating /vdevice/l-lan@71000002^M +Populating /vdevice/v-scsi@71000003^M + SCSI: Looking for devices^M + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"^M +C05A0^MPopulating /pci@800000020000000^M + 00 0000 (D) : 1234 1111 qemu vga^M + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ]^M + 00 1000 (D) : 1af4 1004 virtio [ scsi ]^M +Populating /pci@800000020000000/scsi@2^M + SCSI: Looking for devices^M + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+"^M +C0600^MC06C0^MC0700^MC0800^MC0880^MC0890^MC08A0^MC08A8^MInstalling QEMU fb^M +^M +^M +^M +C08B0^MScanning USB ^M + XHCI: Initializing^M + USB Keyboard ^M + USB mouse ^M +C08C0^MC08D0^MNo console specified using screen & keyboard^M +User selected input-device console: /vdevice/vty@71000000^M +User selected output-device console: /vdevice/vty@71000000^M +C08E0^MC08E8^MC08FF^M ^M + Welcome to Open Firmware^M +^M + Copyright (c) 2004, 2017 IBM Corporation All rights reserved.^M + This program and the accompanying materials are made available^M + under the terms of the BSD License available at^M + http://www.opensource.org/licenses/bsd-license.php^M +^M +^M +Trying to load: -s verbose from: /pci@800000020000000/scsi@2/disk@100000000000000 ... Successfully loaded^M +^M + ---> qemu,pseries detected <---^M +^M +^M +^M +^M +^M +^M +^M +-------------------------------------------------------------------------------^M + Welcome to AIX.^M + boot image timestamp: 05:56:13 04/20/2019^M + processor count: 1; memory size: 4096MB; kernel size: 38426884^M + boot device: /pci@800000020000000/scsi@2/disk@100000000000000^M +^M +8000FFEC bytes of free memory remain at address 7FFF0014^M +load address: 0x00004000 aixmon size: 0x000D2C00 boot image size: 0x01A6B430^M +^LAIX vm,uuid property contains invalid data^Mload address: 0x00004000 aixmon size: 0x000D2C00 boot image size: 0x01A6B430^M +^LAIX vm,uuid property contains invalid data^M +get_ppp return code: 0xFFFFFFFE^M +^M +AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument^M +The temporary memory region list is at 1 percent capacity.^M +The temporary IPLCB is at 1 percent capacity.^M +The IPLCB address is 0x0FFF9000^M +name offset size^M +ipl_cb_and_bit_map 00000000 ......00005958^M +bit_map........... 00000790 ......00000006^M +ipl_info.......... 000001C8 ......00000024^M +splpar_info....... 000001EC ......00000048^M +system_info....... 00000234 ......000000C4^M +processor_info.... 000002F8 ......00000148^M +lpar_id_info...... 00000440 ......00000088^M +dr_proc_info...... 000004C8 ......00000008^M +dr_mem_info....... 000004D0 ......00000028^M +lpar_info......... 000004F8 ......00000014^M +segment page...... 00000518 ......00000028^M +processor page.... 00000540 ......00000010^M +res_asso_id....... 00000550 ......00000050^M +res_asso_group.... 000005A0 ......00000048^M +asso_ref_pnt...... 000005E8 ......00000010^M +residual.......... 00000820 ......00005138^M +fwad_info......... 000005F8 ......00000040^M +contig mem rsv.... 00000738 ......00000058^M + region address region length attr label^M +0 0x0000000000000000 0x000000000FFF7000 0x01 0x01^M +1 0x000000000FFF7000 0x0000000000002000 0x01 0x03^M +2 0x000000000FFF9000 0x0000000000006000 0x01 0x02^M +3 0x000000000FFFF000 0x0000000000000014 0x00 0x05^M +4 0x000000000FFFF014 0x00000000F0000FEC 0x01 0x01^M +5 0x0000000100000000 0xFFFFFFFF00000000 0x00 0x07^M +----------------------------^M +^M +0000012C bytes of free memory remain at address 00004000^M +compressed kernel addr: D6C00; sz: 98CE33; uncompressed kernel addr: 1DB59600^M + name source dest size flags^M + 0 .data 1e6f9840 2000000 12bdd20 1^M + 1 basecfg 1b04000 fff5000 15d9 1^M + 2 ramfs a63a30 efe9000 100b82a 1^M + 3 .text 1db59840 d6c00 ba0000 1^M + 4 .ldr 1f9b7560 c77000 a9523 1^M + 5 symtab 1fe0aaf4 d21000 1f4410 1^M + 6 kern. hdr 1db59600 0 240 1^M + 7 .bss 0 32bdd20 27222e0 2^M +free space between BSS and RAM filesystem: 09609000^M +^M +entry_point: 0x000D6C28^M + kernel debugger setting: enabled^M +-------------------------------------------------------------------------------^M +^LStarLED{A20}^M +Data Storage Interrupt - PROC^M +.dispatch+000098 lwz r0,1830(r6) r0=0,1830(r6)=F00000002FF48E30^M +KDB(0)> + +(apologies for all the ^M - they are emitted by qemu or AIX - not sure) + +Using the same command to boot AIX from 3.1.0 works (no DSI Interrupt). - Other problems occur later, but no Kernel interrupt, only user space problems - and that's another problem - but one at a time ! + +--Ivan + +Forgot that part (debugger output) +KDB(0)> wherre^H ^H^H ^He^M +si_pvthread+000000 STACK:^M +[0008F418]dispatch+000098 (0000000003380000, 0000000002DC3838,^M + F1000816B0036CF0 [??])^M +[00234E34]flih_util+000440 ()^M +____ Exception (02743408) ____^M +iar : 0000000000AD0088 msr : 8000000000001032 cr : 22000888^M +lr : 0000000000AD0078 ctr : 0000000000000000 xer : 00000010^M +mq : 00000000 ^M +r0 : 00000000000000C0 r1 : 0000000002E22280 r2 : 00000000032B5D20^M +r3 : 0000000000000A00 r4 : F10008008012BFF8 r5 : 0000000000000000^M +r6 : F200800011400010 r7 : 0000000000004002 r8 : 0000000000000A00^M +r9 : 0000000000000404 r10 : 0000000000000000 r11 : 0000000000000000^M +r12 : 0000000000AD0078 r13 : 00000000025933F0 r14 : 0000000000B9D470^M +r15 : F10008008012C000 r16 : F20080001143C000 r17 : 000000000003C000^M +r18 : 0000000002004324 r19 : F200800011400006 r20 : 0000000000000000^M +r21 : 0000000000000000 r22 : 0000000002004338 r23 : 0000000000000000^M +r24 : 0000000000000A00 r25 : 0000000000000002 r26 : 0000000000000E3F^M +r27 : 0000000000000001 r28 : 0000000000004002 r29 : 0000000000000000^M +r30 : 0000000000000A00 r31 : F200800011400000 ^M +^M +prev 0000000000000000 stackfix 0000000000000000 int_ticks 0000 ^M +cfar 0000000000163154 capi 0^M +(0)> more (^C to quit) ? ^H ^H^G^M +^M ^Mkjmpbuf 0000000000000000 excbranch 0000000000000000 no_pfault 00 ^M +intpri 00 backt 00 flags 00 ^M +hw_fru_id 00000000 hw_cpu_id 00000000^M +fpscr 0000000000000000 fpscrx 00000000 fpowner 00 ^M +fpeu 00 fpinfo 00 alloc F000 ^M +tmstate 00 tmcontext 00 prevowner 00 ^M +o_iar 0000000000000000 o_toc 0000000000000000 ^M +o_arg1 0000000000000000 o_vaddr 0000000000000000 ^M +krlockp 0000000000000000 rmgrwa 0000000000000000 ^M +amrstackhigh 00000000054B22B8 amrstacklow 00000000054B21B8 ^M +amrstackcur 00000000054B22B8 amrstackfix 0000000000000000 ^M +kstackhigh 0000000000000000 kstacksize 00000000 ^M +frrstart 700DFEED00000000 frrend 700DFEED00000000 ^M +frrcur 700DFEED00000000 frrstatic 0000 kjmpfrroff 0000 ^M +frrovcnt 0000 frrbarrcnt 0000 frrmask 00 callrmgr 00 ^M +Except :^M +excp_type 00000106 EXCEPT_DSI ^M + orgea F10008008012C000 dsisr 0000000040000000 bit set: DSISR_PFT^M + vmh 0000000018008400 curea F10008008012C000 pftyp 0000000000000106^M +[00AD0088]IPRA.$initxpt+0001A8 (0000000000000A00, F10008008012BFF8,^M + 0000000000000000 [??])^M +[00AD02E4]IPRA.$initxpt_vmsi+0000C4 ()^M +(0)> more (^C to quit) ? ^H ^H^G^M +^M ^M[00ACBB08]vmsi+000968 ()^M +[00AC0DF8]main+000098 ()^M +[0053A748].start1+0000B8 ()^M + + +Currently at : +QEMU emulator version 4.0.50 (v2.8.0-rc0-19525-ga4f667b671-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +Got gdb for ppc64 to work and connect to qemu... Here is what I am getting when doing a "info all-registers" + +r0 0x0 0 +r1 0xf1000816b0036890 17365889056675948688 +r2 0x32b5d20 53173536 +r3 0x3380000 54001664 +r4 0x2dc3838 47986744 +r5 0xf1000816b0036cf0 17365889056675949808 +r6 0xf00000002ff47600 17293822569907254784 +r7 0x1007 4103 +r8 0x1000 4096 +r9 0x0 0 +r10 0x0 0 +r11 0x424d2061 1112350817 +r12 0x3282600 52962816 +r13 0x25933f0 39400432 +r14 0x2743408 41169928 +r15 0x3380000 54001664 +r16 0xf1000816b0036d00 17365889056675949824 +r17 0x36000 221184 +r18 0x2004324 33571620 +r19 0xf10008008012c000 17365888961382367232 +r20 0xf10008008 64692977672 +r21 0x0 0 +r22 0x2dc3708 47986440 +r23 0xf10008008012bff8 17365888961382367224 +r24 0x0 0 +r25 0x34e0 13536 +r26 0x0 0 +r27 0x1 1 +r28 0x0 0 +r29 0x2743408 41169928 +r30 0x2079498 34051224 +r31 0x25933f0 39400432 +f0 0 (raw 0x0000000000000000) +f1 0 (raw 0x0000000000000000) +f2 0 (raw 0x0000000000000000) +f3 0 (raw 0x0000000000000000) +f4 0 (raw 0x0000000000000000) +f5 0 (raw 0x0000000000000000) +f6 0 (raw 0x0000000000000000) +f7 0 (raw 0x0000000000000000) +f8 0 (raw 0x0000000000000000) +f9 0 (raw 0x0000000000000000) +f10 0 (raw 0x0000000000000000) +f11 0 (raw 0x0000000000000000) +f12 0 (raw 0x0000000000000000) +f13 0 (raw 0x0000000000000000) +f14 0 (raw 0x0000000000000000) +f15 0 (raw 0x0000000000000000) +f16 0 (raw 0x0000000000000000) +f17 0 (raw 0x0000000000000000) +f18 0 (raw 0x0000000000000000) +f19 0 (raw 0x0000000000000000) +f20 0 (raw 0x0000000000000000) +f21 0 (raw 0x0000000000000000) +f22 0 (raw 0x0000000000000000) +f23 0 (raw 0x0000000000000000) +f24 0 (raw 0x0000000000000000) +f25 0 (raw 0x0000000000000000) +f26 0 (raw 0x0000000000000000) +f27 0 (raw 0x0000000000000000) +f28 0 (raw 0x0000000000000000) +f29 0 (raw 0x0000000000000000) +f30 0 (raw 0x0000000000000000) +f31 0 (raw 0x0000000000000000) +pc 0x8f418 0x8f418 +msr 0x8000000000001032 9223372036854779954 +cr 0x22422280 574759552 +lr 0x234e38 0x234e38 +ctr 0x256b20 2452256 +xer 0x10 16 +fpscr 0x0 0 +vr0 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr1 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr2 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr3 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr4 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr5 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr6 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr7 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr8 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr9 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr10 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr11 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr12 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr13 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr14 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr15 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr16 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr17 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr18 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr19 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr20 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr21 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr22 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr23 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr24 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr25 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr26 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr27 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr28 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr29 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr30 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vr31 {uint128 = 0x00000000000000000000000000000000, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}} +vscr 0x10000 65536 +vrsave 0x0 0 +xer 0x0 0 +lr 0x0 0 +ctr 0x0 0 +uamr 0x0 0 +spr_dscr 0x0 0 +dsisr 0x40000000 1073741824 +dar 0xf10008008012c000 -1080855112327184384 +decr 0x0 0 +srr0 0xad0088 11337864 +srr1 0x8000000000001032 -9223372036854771662 +spr_cfar 0x0 0 +amr 0x0 0 +acop 0x0 0 +pid 0x0 0 +iamr 0x0 0 +tfhar 0x0 0 +tfiar 0x0 0 +texasr 0x0 0 +texasru 0x0 0 +spr_uctrl 0x0 0 +tidr 0x0 0 +spr_ctrl 0x1 1 +fscr 0x0 0 +uamor 0x0 0 +pspb 0x0 0 +dawr 0x0 0 +rpr 0x103070f1f3f 1112514961215 +ciabr 0x0 0 +dawrx 0x0 0 +hfscr 0x0 0 +vrsave 0x0 0 +usprg3 0x0 0 +tbl 0x0 0 +tbu 0x0 0 +sprg0 0x3380000 54001664 +sprg1 0xf1000816b0036d00 -1080855017033601792 +sprg2 0x2e22280 48374400 +sprg3 0x100000000 4294967296 +ear 0x0 0 +tbl 0x0 0 +tbu 0x0 0 +pvr 0x4e1200 5116416 +hsprg0 0x0 0 +hsprg1 0x0 0 +hdsisr 0x0 0 +hdar 0x0 0 +spurr 0x0 0 +purr 0x0 0 +hdec 0x0 0 +rmor 0x0 0 +hrmor 0x0 0 +hsrr0 0x0 0 +hsrr1 0x0 0 +mmcrh 0x0 0 +tfmr 0x0 0 +lpcr 0x403f008 67366920 +lpidr 0x0 0 +hmer 0x0 0 +hmeer 0x0 0 +pcr 0x0 0 +amor 0xffffffffffffffff -1 +tir 0x0 0 +ptcr 0x0 0 +usier 0x0 0 +ummcr2 0x0 0 +ummcra 0x0 0 +upmc1 0x0 0 +upmc2 0x0 0 +upmc3 0x0 0 +upmc4 0x0 0 +upmc5 0x0 0 +upmc6 0x0 0 +ummcr0 0x0 0 +usiar 0x0 0 +usdar 0x0 0 +ummcr1 0x0 0 +sier 0x0 0 +mmcr2 0x0 0 +mmcra 0x0 0 +pmc1 0x0 0 +pmc2 0x0 0 +pmc3 0x0 0 +pmc4 0x0 0 +pmc5 0x0 0 +pmc6 0x0 0 +mmcr0 0x0 0 +siar 0x0 0 +sdar 0x0 0 +mmcr1 0x0 0 +bescrs 0x0 0 +bescrsu 0x0 0 +bescrr 0x0 0 +bescrru 0x0 0 +ebbhr 0x0 0 +ebbrr 0x0 0 +bescr 0x0 0 +tar 0x0 0 +ic 0x0 0 +vtb 0x0 0 +mmcrc 0x0 0 +psscr 0x0 0 +tacr 0x0 0 +tcscr 0x0 0 +csigr 0x0 0 +spmc1 0x0 0 +spmc2 0x0 0 +mmcrs 0x0 0 +wort 0x0 0 +ppr 0x0 0 +tscr 0x0 0 +hid0 0x0 0 +pir 0x0 0 +dl0 0E-6176 (raw 0x00000000000000000000000000000000) +dl1 0E-6176 (raw 0x00000000000000000000000000000000) +dl2 0E-6176 (raw 0x00000000000000000000000000000000) +dl3 0E-6176 (raw 0x00000000000000000000000000000000) +dl4 0E-6176 (raw 0x00000000000000000000000000000000) +dl5 0E-6176 (raw 0x00000000000000000000000000000000) +dl6 0E-6176 (raw 0x00000000000000000000000000000000) +dl7 0E-6176 (raw 0x00000000000000000000000000000000) +dl8 0E-6176 (raw 0x00000000000000000000000000000000) +dl9 0E-6176 (raw 0x00000000000000000000000000000000) +dl10 0E-6176 (raw 0x00000000000000000000000000000000) +dl11 0E-6176 (raw 0x00000000000000000000000000000000) +dl12 0E-6176 (raw 0x00000000000000000000000000000000) +dl13 0E-6176 (raw 0x00000000000000000000000000000000) +dl14 0E-6176 (raw 0x00000000000000000000000000000000) +dl15 0E-6176 (raw 0x00000000000000000000000000000000) +vs0 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs1 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs2 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs3 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs4 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs5 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs6 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs7 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int1 + 0x0 <repeats 16 times>}} +vs8 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs9 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs10 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs11 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs12 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs13 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs14 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs15 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs16 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs17 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs18 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs19 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs20 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs21 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs22 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs23 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs24 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs25 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs26 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs27 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs28 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs29 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs30 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs31 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs32 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs33 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs34 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs35 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs36 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs37 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs38 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs39 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs40 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs41 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs42 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs43 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs44 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs45 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs46 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs47 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs48 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs49 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs50 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs51 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs52 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs53 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs54 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs55 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs56 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs57 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs58 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs59 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs60 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs61 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs62 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +vs63 {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_int8 = { + 0x0 <repeats 16 times>}} +f32 0 (raw 0x0000000000000000) +f33 0 (raw 0x0000000000000000) +f34 0 (raw 0x0000000000000000) +f35 0 (raw 0x0000000000000000) +f36 0 (raw 0x0000000000000000) +f37 0 (raw 0x0000000000000000) +f38 0 (raw 0x0000000000000000) +f39 0 (raw 0x0000000000000000) +f40 0 (raw 0x0000000000000000) +f41 0 (raw 0x0000000000000000) +f42 0 (raw 0x0000000000000000) +f43 0 (raw 0x0000000000000000) +f44 0 (raw 0x0000000000000000) +f45 0 (raw 0x0000000000000000) +f46 0 (raw 0x0000000000000000) +f47 0 (raw 0x0000000000000000) +f48 0 (raw 0x0000000000000000) +f49 0 (raw 0x0000000000000000) +f50 0 (raw 0x0000000000000000) +f51 0 (raw 0x0000000000000000) +f52 0 (raw 0x0000000000000000) +f53 0 (raw 0x0000000000000000) +f54 0 (raw 0x0000000000000000) +f55 0 (raw 0x0000000000000000) +f56 0 (raw 0x0000000000000000) +f57 0 (raw 0x0000000000000000) +f58 0 (raw 0x0000000000000000) +f59 0 (raw 0x0000000000000000) +f60 0 (raw 0x0000000000000000) +f61 0 (raw 0x0000000000000000) +f62 0 (raw 0x0000000000000000) +f63 0 (raw 0x0000000000000000) + +(gdb) where +#0 0x000000000008f418 in ?? () +#1 0x0000000000234e38 in ?? () +#2 0x0000000000234e38 in ?? () +(gdb) x 0x000000000008f418 +0x8f418: 0x80061830 +(gdb) x/i 0x000000000008f418 +=> 0x8f418: lwz r0,6192(r6) +(gdb) +(gdb) x 0xf00000002ff47600 +0xf00000002ff47600: Cannot access memory at address 0xf00000002ff47600 +(gdb) +(gdb) x 0xf00000002ff48e30 (r6+0x1830) + 0xf00000002ff48e30: Cannot access memory at address 0xf00000002ff48e30 +(gdb) + +************************* + +Note again, this works under 3.1.0 + +--Ivan + +From qemu monitor : +(qemu) info tlb +info tlb +SLB ESID VSID +0 0x0000000008000000 0x0000000004002400 +3 0xf100050008000000 0x4000005000000400 +4 0xf100100008000000 0x4000010000000400 +5 0xf100080008000000 0x4000008000000400 +6 0xf100010008000000 0x4000001000000400 +7 0xf200800008000000 0x4000810000000400 +11 0xfffff00000000000 0x0000000012001080 +(qemu) info registers +info registers +NIP 000000000008f418 LR 0000000000234e38 CTR 0000000000256b20 XER 0000000020040010 CPU#0 +MSR 8000000000001032 HID0 0000000000000000 HF 8000000000000030 iidx 1 didx 1 +TB 00000002 11869414363 DECR 1608999296 +GPR00 0000000000000000 f1000816b0036890 00000000032b5d20 0000000003380000 +GPR04 0000000002dc3838 f1000816b0036cf0 f00000002ff47600 0000000000001007 +GPR08 0000000000001000 0000000000000000 0000000000000000 00000000424d2061 +GPR12 0000000003282600 00000000025933f0 0000000002743408 0000000003380000 +GPR16 f1000816b0036d00 0000000000036000 0000000002004324 f10008008012c000 +GPR20 0000000f10008008 0000000000000000 0000000002dc3708 f10008008012bff8 +GPR24 0000000000000000 00000000000034e0 0000000000000000 0000000000000001 +GPR28 0000000000000000 0000000002743408 0000000002079498 00000000025933f0 +CR 22422280 [ E E G E E E L - ] RES ffffffffffffffff +FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPSCR 0000000000000000 + SRR0 0000000000ad0088 SRR1 8000000000001032 PVR 00000000004e1200 VRSAVE 0000000000000000 +SPRG0 0000000003380000 SPRG1 f1000816b0036d00 SPRG2 0000000002e22280 SPRG3 0000000100000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000234e34 + LPCR 000000000403f008 + PTCR 0000000000000000 DAR f10008008012c000 DSISR 0000000040000000 + + +This is the result at the same breakpoint under 3.1.0 (note the difference in the TLB) (notably Segment Lookaside Buffer entry #1) + +(qemu) info tlb +info tlb +SLB ESID VSID +0 0x0000000008000000 0x0000000004002400 +1 0xf000000028000000 0x0000000802001080 +3 0xf100050008000000 0x4000005000000400 +4 0xf100100008000000 0x4000010000000400 +5 0xf100080008000000 0x4000008000000400 +6 0xf100010008000000 0x4000001000000400 +7 0xf200800008000000 0x4000810000000400 +11 0xfffff00000000000 0x000000001a3e5080 +12 0xfffff10000000000 0x0000000824012080 +13 0xfffff20000000000 0x0000000806003080 +19 0x0ffffffff8000000 0x0000000804002c80 +20 0xf100060008000000 0x4000006000000400 +21 0xf100000008000000 0x4000000000000400 +(qemu) info registers +info registers +NIP 000000000008f418 LR 0000000000234e38 CTR 0000000000256b20 XER 0000000020040008 CPU#0 +MSR 8000000000001032 HID0 0000000000000000 HF 8000000000000030 iidx 1 didx 1 +TB 00000003 14758239312 DECR 02912440 +GPR00 0000000000000000 f1000816b0036890 00000000032b5d20 0000000003380000 +GPR04 f100100a00000000 f1000816b0036cf0 f00000002ff47600 0000000000000017 +GPR08 0000000000001000 0000000000000000 0000000000000000 0000000000000000 +GPR12 f1000117d7fad000 f1000117d7faf800 f00000002ff47600 0000000003380000 +GPR16 f1000816b0036d00 0000000002004018 000000000000003d f1000800802de000 +GPR20 0000000f10008008 0000000000000000 f100100a10000000 0000000000000800 +GPR24 0000000000000000 00000000000034e0 f1000117d7faf000 0000000000000001 +GPR28 0000000000000000 f00000002ff47600 f1000117d7fb0800 f1000117d7faf800 +CR 22022480 [ E E - E E G L - ] RES ffffffffffffffff +FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPSCR 0000000000000000 + SRR0 000000000031dec4 SRR1 8000000000009032 PVR 00000000004e1200 VRSAVE 0000000000000000 +SPRG0 0000000003380000 SPRG1 f1000816b0036d00 SPRG2 0000000003380ce8 SPRG3 0000000100000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000234e34 + LPCR 000000000001f008 + PTCR 0000000000000000 DAR f1000800802de000 DSISR 0000000042000000 + + +It might be a red herring... + +The AIX Boot procedure under 3.1.0 issues a + +LED{814} + +which it doesn't issue under 4.0.50 (so a different path is taken at some point by the AIX kernel) + +First I need to determine what AIX code 814 stands for (but it could be auxiliary) + +Before going into the ".dispatch+98" (0x8f418) - so something else must be different between 3.1.0 and 4.0.50... + +I'm probably going to have to "git bisect" this, but that's not going to be easy (the build in itself takes quite a while, although I could optimize it to just include the ppc64 TCG version). + +Apologies for anyone receiving notifications for this, but I'd really like this to work ! + +According to git bisect : + + git bisect bad +c24ba3d0a34f68ad2c6bf1a15bc43770005f6cc0 is the first bad commit +commit c24ba3d0a34f68ad2c6bf1a15bc43770005f6cc0 +Author: Laurent Vivier <email address hidden> +Date: Wed Dec 19 17:35:41 2018 +0100 + + spapr: Add H-Call H_HOME_NODE_ASSOCIATIVITY + + H_HOME_NODE_ASSOCIATIVITY H-Call returns the associativity domain + designation associated with the identifier input parameter + + This fixes a crash when we try to hotplug a CPU in memory-less and + CPU-less numa node. In this case, the kernel tries to online the + node, but without the information provided by this h-call, the node id, + it cannot and the CPU is started while the node is not onlined. + + It also removes the warning message from the kernel: + VPHN is not supported. Disabling polling.. + + Signed-off-by: Laurent Vivier <email address hidden> + Reviewed-by: Greg Kurz <email address hidden> + Signed-off-by: David Gibson <email address hidden> + +:040000 040000 97fe7c5db103c5426f25f2741db918e8cbc03b75 ed55cf6abd483aa01974c18d613461cc9e80e2c3 M hw +:040000 040000 4d51166be64bc71a72bd60eaa412aadc2117fc4c 614be9f9c87d20f7a2c23921a37d771a8956ee7c M include + + +For info : + +I tried Removing the SPAPR H_HOME_NODE_ASSOCIATIVITY H-call support (Not saying it shouldn't be implemented for CPU hotplug support) and AIX 7.2 boots again. with the latest QEMU (as of 8c1ecb590497b0349c550607db923972b37f6963 - git pulled 2019/05/29 @ around 06H30 GMT) + +There must be a very subtle error in how this H-Call works that is bothering AIX... (My setup is single node) + +--Ivan + +I tried removing the H_HOME_NODE_ASSOCIATIVITY H-call from QEMU 4.2.0 and git 5.0.50v5.0.0-997-g9e7f1469b9-dirty, but AIX 7.2 TL4 SP1 still won't boot for me. The last version of QEMU I got it to boot up completely in was 2.11.2 (the version I was able to install AIX). + +ERROR:/home/kens/tmp/qemu/cpus.c:1735:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted) + +If I disable SMP (single CPU) and switch to POWER7, it boots until IPL progress code 00c9/00c0 (dump) then it reboots. I had POWER9 SMP = 8 working with 2.11.2. + +I'm no longer working at IBM. + + +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. + + +We already have a different ticket to track the AIX 7.2 issue here: + https://gitlab.com/qemu-project/qemu/-/issues/269 +Please continue with the discussion there instead, thanks! + diff --git a/results/classifier/zero-shot/108/permissions/1833101 b/results/classifier/zero-shot/108/permissions/1833101 new file mode 100644 index 000000000..084e7d35b --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1833101 @@ -0,0 +1,94 @@ +permissions: 0.978 +other: 0.973 +debug: 0.968 +semantic: 0.966 +device: 0.963 +vnc: 0.949 +PID: 0.943 +performance: 0.933 +graphic: 0.926 +socket: 0.923 +KVM: 0.920 +network: 0.905 +boot: 0.899 +files: 0.893 + +vexpress-a9 (but not -a15) creates two pl111 LCDs due to duplicate sysbus_create_simple("pl111", ...) calls + +Hi, + +Just a small report that (12ec8bd is current master) + +https://github.com/qemu/qemu/blob/12ec8bd/hw/arm/vexpress.c#L652: + + ... + vexpress_common_init() { + ... + sysbus_create_simple("pl111", map[VE_CLCD], pic[14]); + ... + ... + +and + +https://github.com/qemu/qemu/blob/12ec8bd/hw/arm/vexpress.c#L304: + + ... + a9_daughterboard_init() { + ... + sysbus_create_simple("pl111", 0x10020000, pic[44]); + ... + ... + +result in two LCD panels when using vexpress-a9. + +vexpress-a15 does not appear to be affected (my -a9 kernel does not work with it, but I see only one pl111 created). + +Understandably (but still annoyingly), -nodefaults has no effect. + +This bug is most evident when using SDL (so I can use ",frame=off"), which dumps two top-level windows onto the screen. GTK hides this because, coincidentally, the pl111 that ends up being used is the one that is selected (possibly the one created last?), relegating this to an obscure glitch only noticeable if you scrutinize the menu. + +This is a bugreport as opposed to a pull request as I have no idea which call to remove - and complete ignorance of the potential housekeeping and consideration that may be warranted first. + +FWIW, a simple testcase can be made with the vmlinuz from https://people.debian.org/~aurel32/qemu/armhf/ and + +qemu-system-arm -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress -nodefaults -sdl + +Thanks! + +Our vexpress-a9 model instantiates two PL111s because the hardware has two PL111s. One is on the daughterboard, at address 0x10020000, and the other is on the motherboard, at address 0x40001F000. + +The vexpress-a15 hardware has only one PL111, which is why you only see one being created for that hardware. (Instead it has one PL111 and one HDLCD controller, but QEMU has no model of the HDLCD controller at the moment. We might add one one day.) + +In an ideal world we would implement the video multiplexing that the hardware does to allow the guest to select which of the two display devices gets to send output (this is controlled by the SYS_CFG_MUXFPGA system configuration register), at which point we'd be able to only show a single screen window. + + +Ah. + +:) + +As is probably somewhat evident at this point, I'm using vexpress-a9 because it's such a convenient QEMU target, rather than because I have real hardware anywhere. + +Hm, I didn't once stop and think that maybe there actually were two LCD controllers. (And this is where software is great; I got to learn my assumptions were invalid without blowing anything up. :D) + +I tried to find the actual Versatile Express board I'm "using"; the closest I was able to come was https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/50-off-arm-versatile-express-development-boards. It looks like it has two (...three?) processors and four PCIe slots. Very nice. + +Thanks again. + +You might want to check our advice on how to pick a machine type for Arm: https://wiki.qemu.org/Documentation/Platforms/ARM#Guidelines_for_choosing_a_QEMU_machine +Basically we suggest 'virt' unless you have a strong reason for wanting to emulate something else. + +NB that we don't support PCI in our vexpress model (this is one reason we don't recommend it, it makes it a bit inflexible). + + +Thanks for following up, and helping me figure some things out. + +I coincidentally stumbled on https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ a few days ago, landed on the page you linked, and immediately wanted to try it. + +Thanks very much for prompting me to properly think^Wmuddle through and properly model the fussy details of my situation so I could finally see a solution :) + +I happen to be fiddling with an ARMv8 binary built with a Squeeze-era /usr/lib, so I was using vexpress-a9 primarily because a prebuilt Squeeze environment was available from https://people.debian.org/~aurel32/qemu/armel/, and I was able to copy over the /lib/modules/ and kernel image from https://people.debian.org/~aurel32/qemu/armhf/ and have a working system. + +...And so obviously I can get more or less the same result by putting a chroot of my current setup on top of a newer kernel and userspace. Duh/facepalm. That looks to be my next step. Perhaps I'll use Alpine so the environment boots quickly :D (I find Jessie takes 3min, while Wheezy takes 60sec... that was one of my hesitations to fiddle too much actually) + +But first stop, a (prebuilt, most definitely definitely prebuilt) cross compiler. I don't NEED to make my laptop get to 72°C :) + diff --git a/results/classifier/zero-shot/108/permissions/1834113 b/results/classifier/zero-shot/108/permissions/1834113 new file mode 100644 index 000000000..046b58236 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1834113 @@ -0,0 +1,298 @@ +permissions: 0.942 +debug: 0.890 +performance: 0.873 +graphic: 0.867 +other: 0.867 +semantic: 0.861 +device: 0.852 +socket: 0.846 +PID: 0.828 +boot: 0.812 +files: 0.796 +KVM: 0.792 +vnc: 0.787 +network: 0.784 + +QEMU touchpad input erratic after wakeup from sleep + +Using Ubuntu host and guest. Normally the touchpad works great. Within the last few days, suddenly, apparently after a wake from sleep, the touchpad will behave erratically. For example, it will take two clicks to select something, and when moving the cursor it will act as though it is dragging even with the button not clicked. + +A reboot fixes the issue temporarily. + +ProblemType: Bug +DistroRelease: Ubuntu 19.04 +Package: qemu 1:3.1+dfsg-2ubuntu3.1 +Uname: Linux 5.1.14-050114-generic x86_64 +ApportVersion: 2.20.10-0ubuntu27 +Architecture: amd64 +CurrentDesktop: ubuntu:GNOME +Date: Mon Jun 24 20:55:44 2019 +Dependencies: + +EcryptfsInUse: Yes +InstallationDate: Installed on 2019-02-20 (124 days ago) +InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 +Lsusb: + Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 001 Device 002: ID 8087:0025 Intel Corp. + Bus 001 Device 003: ID 0c45:671d Microdia + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +MachineType: Dell Inc. Precision 5530 +ProcEnviron: + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.1.14-050114-generic root=UUID=18e8777c-1764-41e4-a19f-62476055de23 ro mem_sleep_default=deep mem_sleep_default=deep acpi_rev_override=1 scsi_mod.use_blk_mq=1 nouveau.modeset=0 nouveau.runpm=0 nouveau.blacklist=1 acpi_backlight=none acpi_osi=Linux acpi_osi=! +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 04/26/2019 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: 1.10.1 +dmi.board.name: 0FP2W2 +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 10 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvr1.10.1:bd04/26/2019:svnDellInc.:pnPrecision5530:pvr:rvnDellInc.:rn0FP2W2:rvrA00:cvnDellInc.:ct10:cvr: +dmi.product.family: Precision +dmi.product.name: Precision 5530 +dmi.product.sku: 087D +dmi.sys.vendor: Dell Inc. + + + +There wasn't an update in that area that I'd know of except maybe in the kernel (which has too many updates to track all of them). + +Sorry I'm really not a UI expert, lets check a few things still: +- The suspend/wakeup was that just the guest or did you supend/wakeup the host? +- you targetted this for qemu, is the bad effect only happening in the guest UI? +- If you go back to the release kernel instead of the last update does it still happen? +- In general you can always go back to packages in the release pocket, doing so can you identify an + update to one of the packages that caused this to happen? + + +1. Suspend wakeup was on host, not guest. + +2. Yes. Works fine on host, but two guests are both experiencing this. + +I was using 5.1.6, had this issue, updated to latest and it went away, but came back on sleep/awake. If it's a kernel issue, it was introduced before 5.1.6. + +It also doesn't seem to happen on every sleep, and I'm not sure if I can reproduce it. After it happened twice in two days it was enough for me to report. + +The fact that it doesn't happen every time makes it difficult to test against different versions of packages. + +For disco there has been a single qemu update for security, with the following changes: + + * SECURITY UPDATE: Add support for exposing md-clear functionality + to guests + - d/p/ubuntu/enable-md-clear.patch + - d/p/ubuntu/enable-md-no.patch + - CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 + * SECURITY UPDATE: heap overflow when loading device tree blob + - d/p/ubuntu/CVE-2018-20815.patch: specify how large the buffer to + copy the device tree blob into is. + - CVE-2018-20815 + * SECURITY UPDATE: device driver denial of service via NULL pointer + dereference + - d/p/ubuntu/CVE-2019-5008.patch: Define skeleton 'power_mem_read' + routine + - CVE-2019-5008 + * SECURITY UPDATE: information leak in SLiRP + - d/p/ubuntu/CVE-2019-9824.patch: check sscanf result when + emulating ident. + - CVE-2019-9824 + + +$ git show b818da7a1a0dfa55c0f4edf0be10394fe4d7f3f8 | diffstat + changelog | 23 ++++++++++++ + patches/series | 5 ++ + patches/ubuntu/CVE-2018-20815.patch | 38 +++++++++++++++++++ + patches/ubuntu/CVE-2019-5008.patch | 43 ++++++++++++++++++++++ + patches/ubuntu/CVE-2019-9824.patch | 49 +++++++++++++++++++++++++ + patches/ubuntu/enable-md-clear.patch | 67 +++++++++++++++++++++++++++++++++++ + patches/ubuntu/enable-md-no.patch | 28 ++++++++++++++ + 7 files changed, 253 insertions(+) + +I took a cursory look through the five patches, but none leap out as anything relating to touchpads, and don't appear to be related to power management, but hard to say for certain. + + +touchpad issues with power management can be challenging to sort out, and it's not unusual for them to reproduce non-reliably. Power management problems are almost always kernel-related, though I know it can be labor intensive to test. + +However, I've seen the double-action behavior myself with touchpads and keyboards, and the problem wasn't the kernel; in at least one of those cases the cause was a second package that was consuming input events, which resolved through a combination of apt-get purges and reboots. Reviewing the tail end of /var/log/apt/history.log and rolling things back one by one might reveal something, but you'd need to do multiple suspend/resume cycles to test each time. You mentioned seeing this behavior starting a couple days ago, so you could focus attention on changes within the past week or so. (And check when the qemu 1:3.1+dfsg-2ubuntu3.1 update installed (and when you subsequently rebooted)). + +An alternative thing to test would be to see if there are differences in what processes are running when the bug is reproducing, vs. when it is not. You'd want to examine the process tables on both the host and guest. But its possible something starts stealing events after resume, that wasn't doing so before, and diffing process tables won't show that; instead, the way to diagnose this would be to kill X clients one by one (e.g. `xlsclients -la`). + +Beyond that, I can just offer some of the standard troubleshooting techniques for input device troubles: + + * Check if your bios firmware is up to date + * Identify your touchpad device and driver (xinput / sudo lsinput / sudo lshw -C input) + * Check input device properties if using evdev/synaptics (i.e. have any settings changed?) + * xev is a helpful testing tool + * Good luck + + +Rebooting the guest when this is happening does not fix the issue, for what that's worth. + +Last upgrades before this happened are: + +Start-Date: 2019-06-20 23:46:55 +Commandline: apt dist-upgrade +Requested-By: a (1001) +Upgrade: intel-microcode:amd64 (3.20190514.0ubuntu0.19.04.3, 3.20190618.0ubuntu0.19.04.1) +End-Date: 2019-06-20 23:47:11 + +Start-Date: 2019-06-24 08:23:45 +Commandline: apt dist-upgrade +Requested-By: a (1001) +Upgrade: snapd:amd64 (2.38+19.04, 2.39.2+19.04), firefox:amd64 (67.0.3+build1-0ubuntu0.19.04.1, 67.0.4+build1-0ubuntu0.19.04.1) +End-Date: 2019-06-24 08:24:00 + +I also see a bunch of updates to libvirt on 2019-06-19. + +Should I try downgrading intel-microcode? + +Looks like the 3.20190514.0ubuntu0.19.04.3 version of intel-microcode is no longer published, how can I revert to it for testing? + +If you don't have the cache the archive only leaves the release version as well as the latest one in -updates and the latest one in -security. It will not be that easy from apt to use any other. +But Launchpad keeps all of the publishing history [1] and there you'll find the version still [2] and from there at the amd64 build the deb file [3]. + +But that said, I doubt that intel-microcode is really involved - not saying it would not be worth a try, but my hopes on it are low to affect this case. + +[1]: https://launchpad.net/ubuntu/+source/intel-microcode/+publishinghistory +[2]: https://launchpad.net/ubuntu/+source/intel-microcode/3.20190514.0ubuntu0.18.04.3 +[3]: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/16832070/+files/intel-microcode_3.20190514.0ubuntu0.18.04.3_amd64.deb + +Looking into libvirt, the release skipped several version numbers and went straight from 4.6.0 to 5.0.0, which were released 5 months apart. Also, 5.0.0 is itself several releases behind. + +I'll test 4.60 first, then try the latest version of libvirt and see if either fixes the issue. + +Actually, the version of libvirt I'd upgraded from was 5.0.0-1ubuntu2.2 -> 5.0.0-1ubuntu2.3. + +Downgrading all of libvirt-clients libvirt-daemon libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt0 to 5.0.0-1ubuntu2.2 seems to have fixed this after several sleep-resume cycles, although it's hard to be sure. Does any change in libvirt seem relevant? + + +Related changes are + 3 * SECURITY UPDATE: DoS via incorrect permissions check + 4 - debian/patches/CVE-2019-3886-1.patch: disallow virDomainGetHostname + 5 for read-only connections in src/libvirt-domain.c. + 6 - debian/patches/CVE-2019-3886-2.patch: enforce ACL write permission + 7 for getting guest time & hostname in src/remote/remote_protocol.x. + 8 - CVE-2019-3886 + 9 * SECURITY UPDATE: privilege escalation via incorrect socket permissions + 10 - debian/patches/CVE-2019-10132-1.patch: reject clients unless their + 11 UID matches the current UID in src/admin/admin_server_dispatch.c. + 12 - debian/patches/CVE-2019-10132-2.patch: restrict sockets to mode 0600 + 13 in src/locking/virtlockd-admin.socket.in, + 14 src/locking/virtlockd.socket.in. + 15 - debian/patches/CVE-2019-10132-3.patch: restrict sockets to mode 0600 + 16 in src/logging/virtlogd-admin.socket.in, + 17 src/logging/virtlogd.socket.in. + 18 - CVE-2019-10132 + +None of these is important for mouse integration :-/ +So it might be a red herring. + +I'll try a few full boot-sleep-resume cycles on both versions and see how often it replicates + +The issue replicated on the older libvirt, so it wasn't that. Only thing left to try is intel-microcode now + +intel-microcode is closely related to kernel behavior, and so wouldn't surprise me if it's involved - like I mentioned earlier invariably input device + power management bugs are something kernel related. + +However, looking at the diff for the intel-microcode upgrade the changes are highly processor specific, and affects a small handful: + +http://launchpadlibrarian.net/424908874/intel-microcode_3.20190514.0ubuntu0.19.04.1_3.20190514.0ubuntu0.19.04.3.diff.gz + +I'm guessing for a qemu environment these aren't even relevant, but if one of the lines matches your host cpu then perhaps this would be worth more investigation. Otherwise, probably another red herring. + + +There is more you could try though. I suggested some ideas in my previous comment. You could also run xlsclients before and after reproducing the error, and see if there are any new X clients running that might have a grab on the cursor, and then kill them until the touchpad comes back. (See http://who-t.blogspot.com/2010/11/high-level-overview-of-grabs.html) + + +I hate to mention this as a possibility, but like I mentioned earlier, sometimes these bugs can reproduce very non-reliably. I've seen cases where, for instance, the root cause always existed but it was some change in usage or other random things, that caused the input behavior to suddenly start happening, only to disappear again - quite mysteriously - after some other system change. + +The way input devices work, at least in context of this particular bug, is that each movement or click generates an "event", that gets communicated up through the system through various layers until an application consumes it. You can read about this in more extensive detail at https://www.x.org/wiki/Development/Documentation/InputEventProcessing/ +That leads us to two questions for this case: A) Is the event getting generated at all? and B) If it is, then is something unexpectedly consuming it? So a good first step would be to eliminate one or the other of these. You've made some progress towards ruling out B. + +For testing if the event is getting generated, the tool 'xev' is one of the easiest and handiest places to start from. Have you had a chance to give that a test? Run it from the command line when you've got the non-responsive touchpad, and use the touchpad and see if anything prints in the xev window. You can do some googling to get some tips and tricks for filtering xev output and to understand what its output means. + +'xdotool' can also be useful; it's intended for automation but it lets you manhandle mouse events, such as force a click or mouse up/down. Longshot but at least is easy / low risk to try. + +My guess though is the event isn't even getting generated. In that case i'd proceed with the standard troubleshooting techniques to see if something's wrong with the device itself, and go from there. + +>Core Gen8 Mobile + +That's my i9-8950HK. + +What I don't understand is why it works perfectly on the host but not on the guest. And the fact that it persists even when rebooting the guest implies it's not an issue with the guest runtime or anything. It seems like the issue must be with the way qemu is sending the events through to the guest, which I have no idea about. + +Also, it never ignores my clicks. It's generating clicks that I never made - specifically, when moving the cursor it's acting as if I had clicked and dragged. So moving the cursor on a webpage just selects a bunch of text, moving it across the desktop draws a window, etc. + +I will try some of the other troubleshooting methods. + +1. seems like same issue on older intel-microcode. + +2. I checked xev on the guest while issue was occuring with the following results: + +when moving the cursor, a buttonpress event is generated along with a bunch of motionnotify events. After moving it, if I click or touch the touchpad without moving it it shows only a buttonrelease but no buttonpress. + +This is consistent with the behavior I'm seeing: when I move, it's as if I clicked right before, producing the dragging motion. And once it's registered buttonpress, another buttonpress event won't be generated until a buttonrelease one is generated. + +xev works as expected on the host. + +The issue is a phantom buttonpress event being generated on the guest somehow. + + +xlsclients has the same output both times. + +Hi Avi, +for the sake of giving it a try I had a second level guest and suspended/resumed the first level guest a few times. I can't reproduce it. + +OTOH you seem to have a hard time to identify which change introduced this - if it was any change at all and not just by accident not showing up before. + +I feel bad for you, but right now there isn't much we could action to further help. +Especially bad since you were always so prompt in feedback to our questions and suggestions :-/ + +I'll monitor the bug if you come up with new insights or questions on your debugging I'll try to help as I did so far. Thanks to Bryce who understands UI more than I do for his input as well. + +But given the current state, this most likely will stay incomplete and un-actionable :-/ + +Avi, + +Something I have realized we missed as a feedback here - or maybe I missed checking previous comments - is how your mouse is being setup for the guest. Is it being PS/2 emulated (default) or is it being given as an USB device (when qemu cmd line has "-usb -device usb-tablet"). Also, are you using SPICE protocol (perhaps with USB direction option ?). + +Are you able to tell which xserver-xorg-input-XX module is being used inside the guest ? You will probably find that information from Xorg log files (check if you're using xf86-input-wacom or xserver-xorg-input-evdev or some other). + +Another thing that comes to my mind as well, are you using powersaving features ? Specifically the I2C bus I'm concerned. Using "powertop", you are able to change "Runtime PM for I2C Adapter" option under the Tunables Tab (turning the power mgmt to off). I would like to know if you are able to reproduce the issue without having power management enabled for I2C. You can try disabling only I2C and then disabling all PM options as a second attempt. + +From your host: + +Device #1 + +[ 2.834320] input: WCOM488E:00 056A:488E Mouse as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1/i2c-WCOM488E:00/0018:056A:488E.0001/input/input12 + +[ 3.064686] input: Wacom HID 488E Finger as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1/i2c-WCOM488E:00/0018:056A:488E.0001/input/input17 + +Device #2 + +[ 2.834860] input: SYNA2393:00 06CB:7A13 Mouse as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input13 + +[ 2.834929] input: SYNA2393:00 06CB:7A13 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input14 + +Could you describe your input devices ? How many mice, trackpads, pens, etc, you are using connected to the host ? + +Thanks! And sorry for so many questions =). + + + +Right now it stopped happening, although I did see something briefly last week that fixed itself on a reboot. + +If it happens again I'll check those details. + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1835694 b/results/classifier/zero-shot/108/permissions/1835694 new file mode 100644 index 000000000..ea0cf2176 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1835694 @@ -0,0 +1,421 @@ +permissions: 0.969 +boot: 0.966 +network: 0.955 +debug: 0.955 +graphic: 0.953 +performance: 0.950 +semantic: 0.948 +device: 0.946 +PID: 0.943 +other: 0.937 +files: 0.928 +socket: 0.921 +KVM: 0.896 +vnc: 0.893 + +hardware-based time keeping + +Hi all, + +I hope you're all doing well. + +As i was looking for a solution for a particular problem in Qemu/KVM +virtualization. + +My issue is that I have a virtual machine that runs well in VMware and when +I migrated that to Qemu/KVM-enabled environment, it didn't work! I figured +out that under VMware hypervisor, VMware supplies CPU TSC and Performance +Counters values to the guest VM with the option +"monitor_control.pseudo_perfctr = TRUE" set the vmx configuration file, +Ref.: https://www.vmware.com/pdf/vmware_timekeeping.pdf + +My question is, is there any similar option in Qemu/KVM-enabled environment +that I can use to get my VM working the same way as in the VMware +environment? + +I almost tried all options in Qemu with regards to CPU but no avail. + +To elaborate more, the VM I'm trying to port under Qemu/KVM environment is +a an old version of Cisco virtual ASA Firewall. The VM image is actually +meant to be run under VMware ESXi and with that +"*monitor_control.pseudo_perfctr += TRUE*" option it can also run in Vware Workstation as well. *Yes, this +option that makes it run under VMware and if it's removed from the +configuration vmx file then the VM boots half way and crashes the same way +it crashes under Qemu*. That dictates it's the option in interest that +needs to be found in Qemu/KVM. I have a copy of this VM in the below link +in case you would like to try its behavior in under VMware. I downloaded it +from a youtube previously to test it out: + +https://drive.google.com/open?id=1SEXws18hoj2sWGk8iFqqH8RpBZsBNpRH + +Once you power on the VM you can telnet to 127.0.0.1 on port 3000 to see +the boot process. If you remove that option i mentioned to you and boot the +VM again you'll see the crashing in process. + + +I've converted that vmdk disk images into Qemu disks "qcow2" format and i +ran them using the below command line on Ubuntu: + +/opt/qemu/bin/qemu-system-x86_64 -L -nographic -device +e1000-82545em,netdev=net0,mac=50:00:00:6a:00:00 -netdev +tap,id=net0,ifname=vunl0_33_0,script=no -device +e1000-82545em,netdev=net1,mac=50:00:00:6a:00:01 -netdev +tap,id=net1,ifname=vunl0_33_1,script=no -device +e1000-82545em,netdev=net2,mac=50:00:00:6a:00:02 -netdev +tap,id=net2,ifname=vunl0_33_2,script=no -device +e1000-82545em,netdev=net3,mac=50:00:00:6a:00:03 -netdev +tap,id=net3,ifname=vunl0_33_3,script=no -machine type=pc-1.0 *-cpu +host,migratable=off,invtsc=on,pmu=on* -m 4096 -hda hda.qcow2 -hdb hdb.qcow2 +-serial telnet:0.0.0.0:3000,server,nowait -monitor +tcp:127.0.0.1:42379,server,nowait +-nographic -display none -enable-kvm + + +Once you power on the VM you can telnet to xx.xx.xx.xx 3000 (where the xx +IP is the Ubuntu machine IP) to see the crashing in process. You may need +to wait for a while for the status messages to appear in the terminal +window. + +I assume it's a cpu issue because in page 9 of the Vmware pdf reference +file; it says there are machine instructions become available when this +option "*monitor_control.pseudo_perfctr = TRUE*" is enabled: + +The following machine instructions then become available: + +Instruction Time Value Returned +rdpmc 0x10000 Physical host TSC +rdpmc 0x10001 Elapsed real time in ns +rdpmc 0x10002 Elapsed apparent time in ns + +Therefore, I used many of the Qemu cpu options such as these: + +-cpu host,migratable=no,+invtsc (ref: https://wiki.qemu.org/ChangeLog/2.1) +-cpu host, tsc-frequency=xxxx (ref: https://lists.gnu.org/archive/ +html/qemu-devel/2017-01/msg03555.html) + -cpu host,migratable=off,invtsc=true,pmu=true + +Not sure if i'm hitting the wrong option! + +The log I'm getting when the VM boots up looks like the following crash +happens at the blue colored log: + +---------------------------------------------------------------------------------------------------------------------------- +Loading... + +Starting image verification +Hash Computation: 100% Done! +Computed Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 + 5caf64af4cf06cf6a3c5da7200d478dd + 938d380d2b1064f6a349401c7860f50e + cc4eeb98a0ae16c097dbc9447d4d6626 + +Get key records from key storage: Primary, key_store_type: 2 +Embedded Hash SHA2: 63c1e8aa9de3d0c6e738dc91be8e1784 + 5caf64af4cf06cf6a3c5da7200d478dd + 938d380d2b1064f6a349401c7860f50e + cc4eeb98a0ae16c097dbc9447d4d6626 + +The digital signature of the running image verified successfully +Processor memory 3183296512, Reserved memory: 0 + +Total NICs found: 4 +i82545EM rev03 Gigabit Ethernet @ irq10 dev 6 index 03 MAC: 5000.006a.0003 +i82545EM rev03 Gigabit Ethernet @ irq10 dev 5 index 02 MAC: 5000.006a.0002 +i82545EM rev03 Gigabit Ethernet @ irq11 dev 4 index 01 MAC: 5000.006a.0001 +i82545EM rev03 Gigabit Ethernet @ irq11 dev 3 index 00 MAC: 5000.006a.0000 + +Thread Name: lina_flash_init_thread +Page fault: Unknown + r8 0x0000000000000790 + r9 0x00007fff3fa8b000 + r10 0x0000000000000001 + r11 0x000000000210e130 + r12 0x00000000062ebfc0 + r13 0x0000000000010001 + r14 0x0000000000000000 + r15 0x00000000062ebfc0 + rdi 0x00000000062ebfc0 + rsi 0x0000000006c17c20 + rbp 0x00007fff4056f4e0 + rbx 0x00000000062ebfc0 + rdx 0x00007fff40566f10 + rax 0x0000000000000001 + rcx 0x0000000000010001 + rsp 0x00007fff4056f4b0 + rip 0x0000000001581130 + eflags 0x0000000000013202 + csgsfs 0x0000000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 + +Cisco Adaptive Security Appliance Software Version 9.3(1) + +Compiled on Wed 23-Jul-14 18:16 PDT by builders +Hardware: ASAv +Crashinfo collected on 03:42:24.059 UTC Tue Nov 28 2017 + +Traceback: +0: 0x0000000000422118 +1: 0x0000000000422152 +2: 0x0000000000424331 +3: 0x00000000015874a9 +4: 0x00007ffffecd55f0 +5: 0x0000000000558d85 +6: 0x00000000008f5a2b +7: 0x00000000008fd361 +8: 0x0000000000428a15 +Stack dump: base:0x00007fff4056f2e0 size:178, active:178 + entries above '==': return PC preceded by input parameters + entries below '==': local variables followed by saved regs + '==Fn': stack frame n, contains next stack frame + '*': stack pointer at crash + rdi rsi rdx rcx r8 r9 : Arguments 1 through 6 to leaf function + For example: + 0x00007fffeeeeef00: 0x0000000000000009 : arg9 + 0x00007fffeeeeeefc: 0x0000000000000008 : arg8 + 0x00007fffeeeeeef8: 0x0000000000000007 : arg7 + 0x00007fffeeeeeef4: 0x0000000000000abc : return PC + 0x00007fffeeeeeef0: 0x00007fffeeeeef20 ==F2: stack frame F2 + 0x00007fffeeeeeeec: 0x0000000000000def : local variable + 0x00007fffeeeeeee8: 0x0000000000000123 : local variable or saved reg + 0x00007fffeeeeeee4: 0x0000000000000456 : local variable or saved reg + 0x00007fffeeeeeee0: 0x0000000000000789 : local variable or saved reg +0x00007fff4056f870: 0x00007fff4056f7e0 +0x00007fff4056f868: 0x0000000000000000 +0x00007fff4056f860: 0x00000038a11c0123 +0x00007fff4056f858: 0x0000000000000083 +0x00007fff4056f850: 0x00007fff16a864c8 +0x00007fff4056f848: 0x0000000000000000 +0x00007fff4056f840: 0x00000000a11ccdef +0x00007fff4056f838-0x00007fff4056f808: 0x0000000000000000 +0x00007fff4056f800: 0x0000000000429867 +0x00007fff4056f7f8: 0x00007fff4056f860 +0x00007fff4056f7f0: 0x00007fff40567100 +0x00007fff4056f7e8: 0x0000000000000000 +0x00007fff4056f7e0: 0x00000030a11c0123 +0x00007fff4056f7d8: 0x0000000000000083 +0x00007fff4056f7d0: 0x00007fff16a864c8 +0x00007fff4056f7c8: 0x0000000000000000 +0x00007fff4056f7c0: 0x00000000a11ccdef +0x00007fff4056f7b8: 0x0fffffff0fffffff +0x00007fff4056f7b0-0x00007fff4056f7a8: 0x0000000000000000 +0x00007fff4056f7a0: 0x00000000062cc8a0 +0x00007fff4056f798: 0x0000000000000000 +0x00007fff4056f790: 0x00007fff4056f6e0 +0x00007fff4056f788: 0x00007fff4056f758 +0x00007fff4056f780: 0x0000000000000000 +0x00007fff4056f778: 0x00007fff3ff48620 +0x00007fff4056f770-0x00007fff4056f730: 0x0000000000000000 +0x00007fff4056f728: 0x0000000004d14940 +0x00007fff4056f720: 0x000000000041d690 +0x00007fff4056f718: 0x0000000002777640 +0x00007fff4056f710: 0x0000000200010010 +0x00007fff4056f708: 0x0000000006c17d40 +0x00007fff4056f700: 0x00007fff4056f6e0 +0x00007fff4056f6f8: 0x00007fff40150e80 +0x00007fff4056f6f0: 0x000000000638e598 +0x00007fff4056f6e8: 0x00007fff3ff48620 +0x00007fff4056f6e0: 0x00007fff4056f778 +0x00007fff4056f6d8: 0x00000000deadfeed +0x00007fff4056f6d0-0x00007fff4056f6c8: 0x0000000000000000 +0x00007fff4056f6c0: 0x000000000041e1f6 +0x00007fff4056f6b8: 0x00007fff40571fd0 +0x00007fff4056f6b0: 0x00007fff40560cf0 +0x00007fff4056f6a8: 0x0000000000000000 +0x00007fff4056f6a0: 0x000000f0a11c0123 +0x00007fff4056f698: 0x0000000000000143 +0x00007fff4056f690: 0x00007fff16a864c8 +0x00007fff4056f688: 0x0000000000000000 +0x00007fff4056f680: 0x00000000a11ccdef +0x00007fff4056f678-0x00007fff4056f660: 0x0000000000000000 ==F5 +0x00007fff4056f658: 0x000000009abcdef0 +0x00007fff4056f650-0x00007fff4056f5b8: 0x123456789abcdef0 +0x00007fff4056f5b0: 0x0000000000428a01 +0x00007fff4056f5a8: 0x00007fff4056f570 +0x00007fff4056f5a0-0x00007fff4056f590: 0x0000000000000000 +0x00007fff4056f588: 0xffffffffffffdf98 +0x00007fff4056f580: 0x00007fff4056f670 +0x00007fff4056f578: 0x00007fff3ff48370 +0x00007fff4056f570: 0x0000000000000000 +0x00007fff4056f568: 0x0000000000428a15 +0x00007fff4056f560: 0x00007fff4056f670 ==F4 +0x00007fff4056f558: 0x00000000008fd361 +0x00007fff4056f550: 0x00007fff4056f560 ==F3 +0x00007fff4056f548: 0x00000000008f5a2b +0x00007fff4056f540: 0x00007fff4056f550 ==F2 +0x00007fff4056f538: 0x0000000000000000 +0x00007fff4056f530: 0xffffffffffffdf98 +0x00007fff4056f528: 0x00007fff3ff48370 +0x00007fff4056f520: 0x00000000008fba90 +0x00007fff4056f518: 0x00000000008fb908 +0x00007fff4056f510: 0x00007fff4056f550 +0x00007fff4056f508: 0x00000000008fb87e +0x00007fff4056f500: 0x00007fff4056f510 +0x00007fff4056f4f8: 0x0000000000000000 +0x00007fff4056f4f0: 0xffffffffffffdf98 +0x00007fff4056f4e8: 0x0000000000558d85 +0x00007fff4056f4e0: 0x00007fff4056f540 ==F1 +0x00007fff4056f4d8-0x00007fff4056f4d0: 0x0000000000000000 +0x00007fff4056f4c8: 0x0000000000000001 +0x00007fff4056f4c0-0x00007fff4056f4b8: 0x00000000062ebfc0 +0x00007fff4056f4b0: 0x0000000000000000 * +0x00007fff4056f4a8: 0x00000000008fd973 +0x00007fff4056f4a0: 0x00007fff4056f4d0 +0x00007fff4056f498: 0x00007fff40563908 +0x00007fff4056f490: 0x00007fff4056f4d0 +0x00007fff4056f488: 0x00000000009d4b01 +0x00007fff4056f480: 0x00007fff4056f4a0 +0x00007fff4056f478-0x00007fff4056f470: 0x0000000000000000 +0x00007fff4056f468: 0x00007fff418d6390 +0x00007fff4056f460: 0x0000000000000000 +0x00007fff4056f458: 0x000000000201b9f8 +0x00007fff4056f450: 0x00007fff4056f480 +0x00007fff4056f448: 0x00007fff40563908 +0x00007fff4056f440: 0x0000000000000001 +0x00007fff4056f438: 0x00007fff405619a0 +0x00007fff4056f430: 0x00007fff40563908 +0x00007fff4056f428: 0x0000000000000001 +0x00007fff4056f420: 0x0000000000000000 +0x00007fff4056f418: 0x0000000001627125 +0x00007fff4056f410: 0x00007fff4056f450 +0x00007fff4056f408: 0x00007fff3fa8b010 +0x00007fff4056f400: 0x00007fff46505845 +0x00007fff4056f3f8-0x00007fff4056f3c8: 0x0000000000000000 +0x00007fff4056f3c0: 0x0000000000000003 +0x00007fff4056f3b8-0x00007fff4056f3a8: 0x0000000000000000 +0x00007fff4056f3a0: 0x0000000000000240 +0x00007fff4056f398: 0x0000000000000003 +0x00007fff4056f390: 0x0000024446505853 +0x00007fff4056f388-0x00007fff4056f310: 0x0000000000000000 +0x00007fff4056f308: 0x424b7e25fece8fc2 +0x00007fff4056f300: 0x2cc4f98473045e95 +0x00007fff4056f2f8: 0x18fa9b6c57ca0e78 +0x00007fff4056f2f0: 0x081e2a254ab96aa4 +0x00007fff4056f2e8: 0x0000000300000000 + +Begin to dump crashinfo to flash.... + +core0: An internal error occurred. Specifically, a programming assertion +was +violated. Copy the error message exactly as it appears, and get the +output of the show version command and the contents of the configuration +file. Then call your technical support representative. + +assertion "_vf_mode_init" failed: file "vf_api.c", line 136 +core0 same core snap_count=1 signo=6 RIP=7ffffecd43fb + + +----------------------------------------------- +Traceback output aborted. +Flushing first exception frame: +Page fault: Unknown + r8 0x0000000000000790 + r9 0x00007fff3fa8b000 + r10 0x0000000000000001 + r11 0x000000000210e130 + r12 0x00000000062ebfc0 + r13 0x0000000000010001 + r14 0x0000000000000000 + r15 0x00000000062ebfc0 + rdi 0x00000000062ebfc0 + rsi 0x0000000006c17c20 + rbp 0x00007fff4056f4e0 + rbx 0x00000000062ebfc0 + rdx 0x00007fff40566f10 + rax 0x0000000000000001 + rcx 0x0000000000010001 + rsp 0x00007fff4056f4b0 + rip 0x0000000001581130 + eflags 0x0000000000013202 + csgsfs 0x0000000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 +Nested traceback attempted via signal, from: +Abort: Unknown + r8 0x000000000000003c + r9 0x0000000005097a27 + r10 0x00007fff4056de28 + r11 0x0000000000003206 + r12 0x0000000000000001 + r13 0x00007fff4056df80 + r14 0x0000000000000000 + r15 0x0000000000000006 + rdi 0x0000000000000008 + rsi 0x00007fff4056df80 + rbp 0x00007fff4056dfc0 + rbx 0x00007fff29f6b780 + rdx 0x0000000000000010 + rax 0x0000000000000010 + rcx 0xffffffffffffffff + rsp 0x00007fff4056df50 + rip 0x00007ffffecd43fb + eflags 0x0000000000003206 + csgsfs 0x1234000000000033 +error code 0x0000000000000000 + vector 0x000000000000000d + old mask 0xffffffde3e3b5a05 + cr2 0x0000000000000000 + +Cisco Adaptive Security Appliance Software Version 9.3(1) + +Compiled on Wed 23-Jul-14 18:16 PDT by builders +Hardware: ASAv +Crashinfo collected on 03:42:24.059 UTC Tue Nov 28 2017 + +Traceback: +0: 0x0000000000422118 +1: 0x00000000004221f8 +2: 0x000000000042226d +3: 0x0000000001587076 +4: 0x00007ffffecd55f0 +5: 0x00000000015820a0 +6: 0x000000000212d482 +7: 0x000000000139f304 +8: 0x000000000213f315 +9: 0x0000000001460873 +10: 0x0000000001488625 +11: 0x0000000000423e7a +12: 0x00000000004244dc +13: 0x00000000015874a9 +14: 0x00007ffffecd55f0 +15: 0x0000000000558d85 +16: 0x00000000008f5a2b +17: 0x00000000008fd361 +18: 0x0000000000428a15 +----------------------------------------------- +Process shutdown finished +Rebooting..... + +Thanks in advance for your help! :) + +Regards, +Abdullah Alhaddad + +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. + + +not resolved + + +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/180 + + diff --git a/results/classifier/zero-shot/108/permissions/1836558 b/results/classifier/zero-shot/108/permissions/1836558 new file mode 100644 index 000000000..62eb870a5 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1836558 @@ -0,0 +1,460 @@ +permissions: 0.924 +debug: 0.910 +performance: 0.898 +PID: 0.886 +graphic: 0.882 +device: 0.875 +semantic: 0.860 +socket: 0.851 +KVM: 0.840 +other: 0.839 +vnc: 0.824 +files: 0.822 +boot: 0.811 +network: 0.771 + +Qemu-ppc Memory leak creating threads + +When creating c++ threads (with c++ std::thread), the resulting binary has memory leaks when running with qemu-ppc. + +Eg the following c++ program, when compiled with gcc, consumes more and more memory while running at qemu-ppc. (does not have memory leaks when compiling for Intel, when running same binary on real powerpc CPU hardware also no memory leaks). + +(Note I used function getCurrentRSS to show available memory, see https://stackoverflow.com/questions/669438/how-to-get-memory-usage-at-runtime-using-c; calls commented out here) + +Compiler: powerpc-linux-gnu-g++ (Debian 8.3.0-2) 8.3.0 (but same problem with older g++ compilers even 4.9) +Os: Debian 10.0 ( Buster) (but same problem seen on Debian 9/stetch) +qemu: qemu-ppc version 3.1.50 + + + +--- + +#include <iostream> +#include <thread> +#include <chrono> + + +using namespace std::chrono_literals; + +// Create/run and join a 100 threads. +void Fun100() +{ +// auto b4 = getCurrentRSS(); +// std::cout << getCurrentRSS() << std::endl; + for(int n = 0; n < 100; n++) + { + std::thread t([] + { + std::this_thread::sleep_for( 10ms ); + }); +// std::cout << n << ' ' << getCurrentRSS() << std::endl; + t.join(); + } + std::this_thread::sleep_for( 500ms ); // to give OS some time to wipe memory... +// auto after = getCurrentRSS(); + std::cout << b4 << ' ' << after << std::endl; +} + + +int main(int, char **) +{ + Fun100(); + Fun100(); // memory used keeps increasing +} + +Forgive my ignorance of the C++ threading semantics but when do these threads end? Inspection shows we do clear-up CPU and thread structures on exit. That said we do have a comment in linux-user that says: + + /* TODO: Free new CPU state if thread creation failed. */ + +So I wonder if thread creation is actually failing and and that is where we start leaking? + +The thread creating is not failing. The thread is just running the function with line: 'std::this_thread::sleep_for( 10ms );' +in the thread, thus waiting for 10ms. Once finished, the thread function ends, which should also end and cleanup the thread. +(when putting some std::cout console output before the sleep it does show up). +The main thread waits for that in in the join function. + +By running: + + valgrind --leak-check=yes ./qemu-ppc tests/testthread + +I can replicate a leak compared to qemu-arm with the same test.... + +==25789== at 0x483577F: malloc (vg_replace_malloc.c:299) [13/7729] +==25789== by 0x4D7F8D0: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3) +==25789== by 0x1FC65D: create_new_table (translate_init.inc.c:9252) +==25789== by 0x1FC65D: register_ind_in_table (translate_init.inc.c:9291) +==25789== by 0x1FC971: register_ind_insn (translate_init.inc.c:9325) +==25789== by 0x1FC971: register_insn (translate_init.inc.c:9390) +==25789== by 0x1FC971: create_ppc_opcodes (translate_init.inc.c:9450) +==25789== by 0x1FC971: ppc_cpu_realize (translate_init.inc.c:9819) +==25789== by 0x277263: device_set_realized (qdev.c:834) +==25789== by 0x27BBC6: property_set_bool (object.c:2076) +==25789== by 0x28019E: object_property_set_qobject (qom-qobject.c:26) +==25789== by 0x27DAF4: object_property_set_bool (object.c:1334) +==25789== by 0x27AE4B: cpu_create (cpu.c:62) +==25789== by 0x1C89B8: cpu_copy (main.c:188) +==25789== by 0x1CA44F: do_fork (syscall.c:5604) +==25789== by 0x1D665A: do_syscall1.isra.43 (syscall.c:9160) +==25789== +==25789== 6,656 bytes in 26 blocks are possibly lost in loss record 216 of 238 +==25789== at 0x483577F: malloc (vg_replace_malloc.c:299) +==25789== by 0x4D7F8D0: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3) +==25789== by 0x1FC65D: create_new_table (translate_init.inc.c:9252) +==25789== by 0x1FC65D: register_ind_in_table (translate_init.inc.c:9291) +==25789== by 0x1FC9BA: register_dblind_insn (translate_init.inc.c:9337) +==25789== by 0x1FC9BA: register_insn (translate_init.inc.c:9384) +==25789== by 0x1FC9BA: create_ppc_opcodes (translate_init.inc.c:9450) +==25789== by 0x1FC9BA: ppc_cpu_realize (translate_init.inc.c:9819) +==25789== by 0x277263: device_set_realized (qdev.c:834) +==25789== by 0x27BBC6: property_set_bool (object.c:2076) +==25789== by 0x28019E: object_property_set_qobject (qom-qobject.c:26) +==25789== by 0x27DAF4: object_property_set_bool (object.c:1334) +==25789== by 0x27AE4B: cpu_create (cpu.c:62) +==25789== by 0x17304D: main (main.c:681) +==25789== +==25789== 10,752 (1,024 direct, 9,728 indirect) bytes in 4 blocks are definitely lost in loss record 223 of 238 +==25789== at 0x483577F: malloc (vg_replace_malloc.c:299) +==25789== by 0x4D7F8D0: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3) +==25789== by 0x1FC65D: create_new_table (translate_init.inc.c:9252) +==25789== by 0x1FC65D: register_ind_in_table (translate_init.inc.c:9291) +==25789== by 0x1FC998: register_dblind_insn (translate_init.inc.c:9332) +==25789== by 0x1FC998: register_insn (translate_init.inc.c:9384) +==25789== by 0x1FC998: create_ppc_opcodes (translate_init.inc.c:9450) +==25789== by 0x1FC998: ppc_cpu_realize (translate_init.inc.c:9819) +==25789== by 0x277263: device_set_realized (qdev.c:834) +==25789== by 0x27BBC6: property_set_bool (object.c:2076) +==25789== by 0x28019E: object_property_set_qobject (qom-qobject.c:26) +==25789== by 0x27DAF4: object_property_set_bool (object.c:1334) +==25789== by 0x27AE4B: cpu_create (cpu.c:62) +==25789== by 0x1C89B8: cpu_copy (main.c:188) +==25789== by 0x1CA44F: do_fork (syscall.c:5604) +==25789== by 0x1D665A: do_syscall1.isra.43 (syscall.c:9160) + +So something funky happens to the PPC translator for each new thread.... + +Could you try an experiment and put a final 30 second sleep before the program exits. I suspect the RCU cleanup of the per-thread data never gets a chance to cleanup. + +Nope we think we have identified the leak. On CPU realize (ppc_cpu_realize) the translator sets up its tables (create_ppc_opcodes). This will happen for each thread created. This would be fine but linux_user cpu_copy function then does: + + memcpy(new_env, env, sizeof(CPUArchState)); + +which will blindly overwrite the tables in CPUArchState (CPUPPCState) causing the leak. The suggestion is the data should be moved to PowerPCCPU (as it is internal to the translator) and avoid being smashed by the memcpy. However longer term we should replace the memcpy with an arch aware smart copy. + +The opcode decode tables aren't really part of the CPUPPCState but an +internal implementation detail for the translator. This can cause +problems with memcpy in cpu_copy as any table created during +ppc_cpu_realize get written over causing a memory leak. To avoid this +move the tables into PowerPCCPU which is better suited to hold +internal implementation details. + +Attempts to fix: https://bugs.launchpad.net/qemu/+bug/1836558 +Cc: <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + target/ppc/cpu.h | 8 ++++---- + target/ppc/translate.c | 3 ++- + target/ppc/translate_init.inc.c | 16 +++++++--------- + 3 files changed, 13 insertions(+), 14 deletions(-) + +diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h +index c9beba2a5c0..10e34b69b75 100644 +--- a/target/ppc/cpu.h ++++ b/target/ppc/cpu.h +@@ -1104,10 +1104,6 @@ struct CPUPPCState { + bool resume_as_sreset; + #endif + +- /* Those resources are used only during code translation */ +- /* opcode handlers */ +- opc_handler_t *opcodes[PPC_CPU_OPCODES_LEN]; +- + /* Those resources are used only in QEMU core */ + target_ulong hflags; /* hflags is a MSR & HFLAGS_MASK */ + target_ulong hflags_nmsr; /* specific hflags, not coming from MSR */ +@@ -1191,6 +1187,10 @@ struct PowerPCCPU { + int32_t node_id; /* NUMA node this CPU belongs to */ + PPCHash64Options *hash64_opts; + ++ /* Those resources are used only during code translation */ ++ /* opcode handlers */ ++ opc_handler_t *opcodes[PPC_CPU_OPCODES_LEN]; ++ + /* Fields related to migration compatibility hacks */ + bool pre_2_8_migration; + target_ulong mig_msr_mask; +diff --git a/target/ppc/translate.c b/target/ppc/translate.c +index 4a5de280365..c0faab8a824 100644 +--- a/target/ppc/translate.c ++++ b/target/ppc/translate.c +@@ -7857,6 +7857,7 @@ static bool ppc_tr_breakpoint_check(DisasContextBase *dcbase, CPUState *cs, + static void ppc_tr_translate_insn(DisasContextBase *dcbase, CPUState *cs) + { + DisasContext *ctx = container_of(dcbase, DisasContext, base); ++ PowerPCCPU *cpu = POWERPC_CPU(cs); + CPUPPCState *env = cs->env_ptr; + opc_handler_t **table, *handler; + +@@ -7874,7 +7875,7 @@ static void ppc_tr_translate_insn(DisasContextBase *dcbase, CPUState *cs) + opc3(ctx->opcode), opc4(ctx->opcode), + ctx->le_mode ? "little" : "big"); + ctx->base.pc_next += 4; +- table = env->opcodes; ++ table = cpu->opcodes; + handler = table[opc1(ctx->opcode)]; + if (is_indirect_opcode(handler)) { + table = ind_table(handler); +diff --git a/target/ppc/translate_init.inc.c b/target/ppc/translate_init.inc.c +index 86fc8f2e316..9cd2033bb92 100644 +--- a/target/ppc/translate_init.inc.c ++++ b/target/ppc/translate_init.inc.c +@@ -9440,14 +9440,13 @@ static void fix_opcode_tables(opc_handler_t **ppc_opcodes) + static void create_ppc_opcodes(PowerPCCPU *cpu, Error **errp) + { + PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); +- CPUPPCState *env = &cpu->env; + opcode_t *opc; + +- fill_new_table(env->opcodes, PPC_CPU_OPCODES_LEN); ++ fill_new_table(cpu->opcodes, PPC_CPU_OPCODES_LEN); + for (opc = opcodes; opc < &opcodes[ARRAY_SIZE(opcodes)]; opc++) { + if (((opc->handler.type & pcc->insns_flags) != 0) || + ((opc->handler.type2 & pcc->insns_flags2) != 0)) { +- if (register_insn(env->opcodes, opc) < 0) { ++ if (register_insn(cpu->opcodes, opc) < 0) { + error_setg(errp, "ERROR initializing PowerPC instruction " + "0x%02x 0x%02x 0x%02x", opc->opc1, opc->opc2, + opc->opc3); +@@ -9455,7 +9454,7 @@ static void create_ppc_opcodes(PowerPCCPU *cpu, Error **errp) + } + } + } +- fix_opcode_tables(env->opcodes); ++ fix_opcode_tables(cpu->opcodes); + fflush(stdout); + fflush(stderr); + } +@@ -10023,7 +10022,6 @@ static void ppc_cpu_unrealize(DeviceState *dev, Error **errp) + { + PowerPCCPU *cpu = POWERPC_CPU(dev); + PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu); +- CPUPPCState *env = &cpu->env; + Error *local_err = NULL; + opc_handler_t **table, **table_2; + int i, j, k; +@@ -10035,11 +10033,11 @@ static void ppc_cpu_unrealize(DeviceState *dev, Error **errp) + } + + for (i = 0; i < PPC_CPU_OPCODES_LEN; i++) { +- if (env->opcodes[i] == &invalid_handler) { ++ if (cpu->opcodes[i] == &invalid_handler) { + continue; + } +- if (is_indirect_opcode(env->opcodes[i])) { +- table = ind_table(env->opcodes[i]); ++ if (is_indirect_opcode(cpu->opcodes[i])) { ++ table = ind_table(cpu->opcodes[i]); + for (j = 0; j < PPC_CPU_INDIRECT_OPCODES_LEN; j++) { + if (table[j] == &invalid_handler) { + continue; +@@ -10057,7 +10055,7 @@ static void ppc_cpu_unrealize(DeviceState *dev, Error **errp) + ~PPC_INDIRECT)); + } + } +- g_free((opc_handler_t *)((uintptr_t)env->opcodes[i] & ++ g_free((opc_handler_t *)((uintptr_t)cpu->opcodes[i] & + ~PPC_INDIRECT)); + } + } +-- +2.20.1 + + + +When a CPU object is created it is parented during it's realize stage. +If we don't unparent before the "final" unref we will never finzalize +the object leading to a memory leak. For most setups you probably +won't notice but with anything that creates and destroys a lot of +threads this will add up. This goes especially for architectures which +allocate a lot of memory in their CPU structures. + +Fixes: https://bugs.launchpad.net/qemu/+bug/1836558 +Cc: <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + linux-user/syscall.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 39a37496fed..4c9313fd9d0 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -7183,6 +7183,7 @@ static abi_long do_syscall1(void *cpu_env, int num, abi_long arg1, + NULL, NULL, 0); + } + thread_cpu = NULL; ++ object_unparent(OBJECT(cpu)); + object_unref(OBJECT(cpu)); + g_free(ts); + rcu_unregister_thread(); +-- +2.20.1 + + + +Ccing the QOM maintainers to make sure we have the +QOM lifecycle operations right here... + +On Tue, 16 Jul 2019 at 15:02, Alex Bennée <email address hidden> wrote: +> +> When a CPU object is created it is parented during it's realize stage. +> If we don't unparent before the "final" unref we will never finzalize +> the object leading to a memory leak. For most setups you probably +> won't notice but with anything that creates and destroys a lot of +> threads this will add up. This goes especially for architectures which +> allocate a lot of memory in their CPU structures. +> +> Fixes: https://bugs.launchpad.net/qemu/+bug/1836558 +> Cc: <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> linux-user/syscall.c | 1 + +> 1 file changed, 1 insertion(+) +> +> diff --git a/linux-user/syscall.c b/linux-user/syscall.c +> index 39a37496fed..4c9313fd9d0 100644 +> --- a/linux-user/syscall.c +> +++ b/linux-user/syscall.c +> @@ -7183,6 +7183,7 @@ static abi_long do_syscall1(void *cpu_env, int num, abi_long arg1, +> NULL, NULL, 0); +> } +> thread_cpu = NULL; +> + object_unparent(OBJECT(cpu)); +> object_unref(OBJECT(cpu)); +> g_free(ts); +> rcu_unregister_thread(); + +I think (as I mentioned on IRC) that we also need to unrealize +the CPU object, because target/ppc at least does some freeing +of memory in its unrealize method. I think we do that by +setting the QOM "realize" property back to "false" -- but that +might barf if we try it on a CPU that isn't hotpluggable... + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> Ccing the QOM maintainers to make sure we have the +> QOM lifecycle operations right here... +> +> On Tue, 16 Jul 2019 at 15:02, Alex Bennée <email address hidden> wrote: +>> +>> When a CPU object is created it is parented during it's realize stage. +>> If we don't unparent before the "final" unref we will never finzalize +>> the object leading to a memory leak. For most setups you probably +>> won't notice but with anything that creates and destroys a lot of +>> threads this will add up. This goes especially for architectures which +>> allocate a lot of memory in their CPU structures. +>> +>> Fixes: https://bugs.launchpad.net/qemu/+bug/1836558 +>> Cc: <email address hidden> +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> linux-user/syscall.c | 1 + +>> 1 file changed, 1 insertion(+) +>> +>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c +>> index 39a37496fed..4c9313fd9d0 100644 +>> --- a/linux-user/syscall.c +>> +++ b/linux-user/syscall.c +>> @@ -7183,6 +7183,7 @@ static abi_long do_syscall1(void *cpu_env, int num, abi_long arg1, +>> NULL, NULL, 0); +>> } +>> thread_cpu = NULL; +>> + object_unparent(OBJECT(cpu)); +>> object_unref(OBJECT(cpu)); +>> g_free(ts); +>> rcu_unregister_thread(); +> +> I think (as I mentioned on IRC) that we also need to unrealize +> the CPU object, because target/ppc at least does some freeing +> of memory in its unrealize method. I think we do that by +> setting the QOM "realize" property back to "false" -- but that +> might barf if we try it on a CPU that isn't hotpluggable... + +I have tried: + + thread_cpu = NULL; ++ object_unparent(OBJECT(cpu)); ++ object_property_set_bool(OBJECT(cpu), false, "realized", NULL); + object_unref(OBJECT(cpu)); + +but it didn't manifestly change anything (i.e. both with and without +setting realized the thread allocated stuff is freed). Valgrind still +complains about: + +==22483== 6,656 bytes in 26 blocks are possibly lost in loss record 1,639 of 1,654 +==22483== at 0x483577F: malloc (vg_replace_malloc.c:299) +==22483== by 0x4D7F8D0: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.3) +==22483== by 0x27D692: create_new_table (translate_init.inc.c:9252) +==22483== by 0x27D7CD: register_ind_in_table (translate_init.inc.c:9291) +==22483== by 0x27D975: register_dblind_insn (translate_init.inc.c:9337) +==22483== by 0x27DBBB: register_insn (translate_init.inc.c:9384) +==22483== by 0x27DE4E: create_ppc_opcodes (translate_init.inc.c:9449) +==22483== by 0x27E79C: ppc_cpu_realize (translate_init.inc.c:9818) +==22483== by 0x2C6FE8: device_set_realized (qdev.c:834) +==22483== by 0x2D1E3D: property_set_bool (object.c:2076) +==22483== by 0x2D00B3: object_property_set (object.c:1268) +==22483== by 0x2D3185: object_property_set_qobject (qom-qobject.c:26) + +But I don't know if that is just because the final exit_group of the +main CPU just exits without attempting to clean-up. However it is better +than it was. + +-- +Alex Bennée + + + +David Gibson <email address hidden> writes: + +> On Tue, Jul 16, 2019 at 01:13:52PM +0100, Alex Bennée wrote: +>> The opcode decode tables aren't really part of the CPUPPCState but an +>> internal implementation detail for the translator. This can cause +>> problems with memcpy in cpu_copy as any table created during +>> ppc_cpu_realize get written over causing a memory leak. To avoid this +>> move the tables into PowerPCCPU which is better suited to hold +>> internal implementation details. +>> +>> Attempts to fix: https://bugs.launchpad.net/qemu/+bug/1836558 +>> Cc: <email address hidden> +>> Signed-off-by: Alex Bennée <email address hidden> +> +> I've applied this now to ppc-for-4.2. If there's an argument for +> including it in 4.1 during hard freeze, you'll need to spell it out +> for me. + +Well without: + + Subject: [RFC PATCH for 4.1] linux-user: unparent CPU object before unref + Date: Tue, 16 Jul 2019 15:01:33 +0100 + Message-Id: <email address hidden> + +it doesn't matter as we never attempt to free the memory once a thread +is destroyed. This causes all linux-user guests that create and destroy +threads quickly to slowly leak memory. However due to the dynamic opcode +table ppc/ppc64-linux-user guests leak a lot faster than most, in the +order of ~50k each time a thread is created and destroyed. + +However I'm happy to defer to you as the maintainer :-) + +-- +Alex Bennée + + +A fix for this bug has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=28876bf27d2792e6b16cf +It has been released with QEMU v4.2. Can this bug ticket now be closed? + diff --git a/results/classifier/zero-shot/108/permissions/1836855 b/results/classifier/zero-shot/108/permissions/1836855 new file mode 100644 index 000000000..cabe6d241 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1836855 @@ -0,0 +1,167 @@ +permissions: 0.965 +debug: 0.960 +semantic: 0.957 +PID: 0.950 +graphic: 0.950 +socket: 0.945 +other: 0.938 +boot: 0.931 +vnc: 0.927 +performance: 0.925 +device: 0.914 +files: 0.905 +KVM: 0.900 +network: 0.878 + +virtio_scsi_ctx_check failed when detach virtio_scsi disk + +I found a problem that virtio_scsi_ctx_check failed when detaching virtio_scsi disk. The bt is below: + +(gdb) bt +#0 0x0000ffffb02e1bd0 in raise () from /lib64/libc.so.6 +#1 0x0000ffffb02e2f7c in abort () from /lib64/libc.so.6 +#2 0x0000ffffb02db124 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x0000ffffb02db1a4 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=<optimized out>, s=<optimized out>) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 +#5 0x00000000004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 +#6 0x00000000004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 +#7 0x00000000004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xffffae7a6f98) + at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 +#8 0x0000000000877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 +#9 0x00000000008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 +#10 0x00000000005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 +#11 0x000000000087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 +#12 0x00000000008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 +#13 0x0000ffffb041c8bc in start_thread () from /lib64/libpthread.so.0 +#14 0x0000ffffb0382f8c in thread_start () from /lib64/libc.so.6 + +assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. + +I think this patch (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) introduce this problem. + +commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend back to main AioContext on unplug. It set the AioContext of + +SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContext. Is this a bug? + +On Wed, Jul 17, 2019 at 08:20:35AM -0000, 贞贵李 wrote: +> Public bug reported: +> +> I found a problem that virtio_scsi_ctx_check failed when detaching +> virtio_scsi disk. The bt is below: +> +> (gdb) bt +> #0 0x0000ffffb02e1bd0 in raise () from /lib64/libc.so.6 +> #1 0x0000ffffb02e2f7c in abort () from /lib64/libc.so.6 +> #2 0x0000ffffb02db124 in __assert_fail_base () from /lib64/libc.so.6 +> #3 0x0000ffffb02db1a4 in __assert_fail () from /lib64/libc.so.6 +> #4 0x00000000004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=<optimized out>, s=<optimized out>) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 +> #5 0x00000000004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 +> #6 0x00000000004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 +> #7 0x00000000004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xffffae7a6f98) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 +> #8 0x0000000000877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 +> #9 0x00000000008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 +> #10 0x00000000005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 +> #11 0x000000000087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 +> #12 0x00000000008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 +> #13 0x0000ffffb041c8bc in start_thread () from /lib64/libpthread.so.0 +> #14 0x0000ffffb0382f8c in thread_start () from /lib64/libc.so.6 +> +> assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. +> +> I think this patch +> (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) +> introduce this problem. +> +> commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend back +> to main AioContext on unplug. It set the AioContext of +> +> SCSIDevice to the main AioContex, but s->ctx is still the iothread +> AioContext. Is this a bug? + +The backtrace shows that virtqueue processing is happening in the +IOThread. This is expected so now the question is why the +BlockBackend's AioContext is the main AioContext. + +Can you share steps for reproducing this bug? + +Thanks! + +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1836855 +> +> Title: +> virtio_scsi_ctx_check failed when detach virtio_scsi disk +> +> Status in QEMU: +> New +> +> Bug description: +> I found a problem that virtio_scsi_ctx_check failed when detaching +> virtio_scsi disk. The bt is below: +> +> (gdb) bt +> #0 0x0000ffffb02e1bd0 in raise () from /lib64/libc.so.6 +> #1 0x0000ffffb02e2f7c in abort () from /lib64/libc.so.6 +> #2 0x0000ffffb02db124 in __assert_fail_base () from /lib64/libc.so.6 +> #3 0x0000ffffb02db1a4 in __assert_fail () from /lib64/libc.so.6 +> #4 0x00000000004eb9a8 in virtio_scsi_ctx_check (d=d@entry=0xc70d790, s=<optimized out>, s=<optimized out>) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:243 +> #5 0x00000000004ec87c in virtio_scsi_handle_cmd_req_prepare (s=s@entry=0xd27a7a0, req=req@entry=0xafc4b90) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:553 +> #6 0x00000000004ecc20 in virtio_scsi_handle_cmd_vq (s=0xd27a7a0, vq=0xd283410) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi.c:588 +> #7 0x00000000004eda20 in virtio_scsi_data_plane_handle_cmd (vdev=0x0, vq=0xffffae7a6f98) +> at /Images/lzg/code/710/qemu-2.8.1/hw/scsi/virtio-scsi-dataplane.c:57 +> #8 0x0000000000877254 in aio_dispatch (ctx=0xac61010) at util/aio-posix.c:323 +> #9 0x00000000008773ec in aio_poll (ctx=0xac61010, blocking=true) at util/aio-posix.c:472 +> #10 0x00000000005cd7cc in iothread_run (opaque=0xac5e4b0) at iothread.c:49 +> #11 0x000000000087a8b8 in qemu_thread_start (args=0xac61360) at util/qemu-thread-posix.c:495 +> #12 0x00000000008a04e8 in thread_entry_for_hotfix (pthread_cb=0x0) at uvp/hotpatch/qemu_hotpatch_helper.c:579 +> #13 0x0000ffffb041c8bc in start_thread () from /lib64/libpthread.so.0 +> #14 0x0000ffffb0382f8c in thread_start () from /lib64/libc.so.6 +> +> assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed. +> +> I think this patch +> (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b) +> introduce this problem. +> +> commit a6f230c8d13a7ff3a0c7f1097412f44bfd9eff0b move blockbackend +> back to main AioContext on unplug. It set the AioContext of +> +> SCSIDevice to the main AioContex, but s->ctx is still the iothread +> AioContext. Is this a bug? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1836855/+subscriptions +> + + +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/zero-shot/108/permissions/1841592 b/results/classifier/zero-shot/108/permissions/1841592 new file mode 100644 index 000000000..9c908d588 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1841592 @@ -0,0 +1,594 @@ +permissions: 0.935 +other: 0.928 +debug: 0.912 +semantic: 0.906 +vnc: 0.904 +KVM: 0.897 +socket: 0.886 +PID: 0.884 +graphic: 0.860 +device: 0.857 +boot: 0.856 +performance: 0.848 +network: 0.818 +files: 0.790 + +ppc: softfloat float implementation issues + +Per bug #1841491, Richard Henderson (rth) said: +> The float test failure is part of a larger problem for target/powerpc in which all float +> routines are implemented incorrectly. They are all implemented as double operations with +> rounding to float as a second step. Which not only produces incorrect exceptions, as in +> this case, but incorrect > numerical results from the double rounding. +> +> This should probably be split to a separate bug... + + + +-- ppc64le native: +$ gcc -c -O2 ffma.c +$ gcc -O2 test-ffma.c ffma.o -lm -o test-ffma +$ ./test-ffma $(./test-ffma) +ffma(0x1p-149, 0x1p-149, 0x1p-149) +0x0 + +0xa000000 +FE_INEXACT FE_UNDERFLOW +0x1p-149 + +-- qemu-system-ppc64: +$ ./test-ffma $(./test-ffma) +ffma(0x1p-149, 0x1p-149, 0x1p-149) +0x0 + +0x2000000 +FE_INEXACT +0x1p-149 + + +I'm confused by this testcase as it's not a fused multiply-add but as you say two combined operations. + +It should be a fused multiply add; you may need to use -ffast-math or +something to get the compiler to generate the proper instruction. + +However, one can see from target/ppc/translate/fp-impl.inc.c: + +/* fmadd - fmadds */ +GEN_FLOAT_ACB(madd, 0x1D, 1, PPC_FLOAT); + +through to _GEN_FLOAT_ACB: + + gen_helper_f##op(t3, cpu_env, t0, t1, t2); \ + if (isfloat) { \ + gen_helper_frsp(t3, cpu_env, t3); \ + } \ + +That right there is a double-precision fma followed by a round +to single precision. This pattern is replicated for all single +precision operations, and is of course wrong. + +I believe that correct results may be obtained by having +single-precision helpers that first convert the double-precision +input into a single-precision input using helper_tosingle(), +perform the required operation, then convert the result back to +double-precision using helper_todouble(). + +The manual says: + +# For single-precision arithmetic instructions, all input values +# must be representable in single format; if they are not, the +# result placed into the target FPR, and the setting of +# status bits in the FPSCR and in the Condition Register +# (if Rc=1), are undefined. + +The tosingle/todouble conversions are exact and bit-preserving. +They are used by load-single and store-single that convert a +single-precision in-memory value to the double-precision register +value. Therefore the input given to float32_add using this +conversion would be exactly the same as if we had given the +value unmollested from a memory input. + +I don't know what real ppc hw does -- whether it takes all of +the double-precision input bits and rounds to 23-bits, like the +old 80387 hardware does, or truncates the input as I propose. +But for architectural results we don't have to care, because +of the UNDEFINED escape clause. + +Testing on current master shows the behavior is correct. I guess rth's patch fixed this case. + +It looks like the test case isn't properly exercising the code that is likely to be wrong. It sounds like we need a proper comprehensive testcase for fused operations (along the line of the ARM fcvt test case). This can probably be a multiarch testcase which we can build for all the various targets. + +This is a generic floating point multiply and accumulate test for +single precision floating point values. I've split of the common float +functions into a helper library so additional tests can use the same +common code. + +Signed-off-by: Alex Bennée <email address hidden> +--- + tests/tcg/multiarch/Makefile.target | 7 +- + tests/tcg/multiarch/float_helpers.c | 208 ++++++++++++++++++++++++++++ + tests/tcg/multiarch/float_helpers.h | 26 ++++ + tests/tcg/multiarch/float_madds.c | 78 +++++++++++ + 4 files changed, 318 insertions(+), 1 deletion(-) + create mode 100644 tests/tcg/multiarch/float_helpers.c + create mode 100644 tests/tcg/multiarch/float_helpers.h + create mode 100644 tests/tcg/multiarch/float_madds.c + +diff --git a/tests/tcg/multiarch/Makefile.target b/tests/tcg/multiarch/Makefile.target +index 657a04f802d..0446b75c456 100644 +--- a/tests/tcg/multiarch/Makefile.target ++++ b/tests/tcg/multiarch/Makefile.target +@@ -10,12 +10,17 @@ MULTIARCH_SRC=$(SRC_PATH)/tests/tcg/multiarch + # Set search path for all sources + VPATH += $(MULTIARCH_SRC) + MULTIARCH_SRCS =$(notdir $(wildcard $(MULTIARCH_SRC)/*.c)) +-MULTIARCH_TESTS =$(MULTIARCH_SRCS:.c=) ++MULTIARCH_TESTS =$(filter-out float_helpers, $(MULTIARCH_SRCS:.c=)) + + # + # The following are any additional rules needed to build things + # + ++ ++float_madds: LDFLAGS+=-lm ++float_madds: float_madds.c float_helpers.c ++ $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -O2 $< $(MULTIARCH_SRC)/float_helpers.c -o $@ $(LDFLAGS) ++ + testthread: LDFLAGS+=-lpthread + + # We define the runner for test-mmap after the individual +diff --git a/tests/tcg/multiarch/float_helpers.c b/tests/tcg/multiarch/float_helpers.c +new file mode 100644 +index 00000000000..481d8d33317 +--- /dev/null ++++ b/tests/tcg/multiarch/float_helpers.c +@@ -0,0 +1,208 @@ ++/* ++ * Common Float Helpers ++ * ++ * This contains a series of useful utility routines and a set of ++ * floating point constants useful for exercising the edge cases in ++ * floating point tests. ++ * ++ * Copyright (c) 2019 Linaro ++ * ++ * SPDX-License-Identifier: GPL-3.0-or-later ++ */ ++ ++/* we want additional float type definitions */ ++#define __STDC_WANT_IEC_60559_BFP_EXT__ ++#define __STDC_WANT_IEC_60559_TYPES_EXT__ ++ ++#define _GNU_SOURCE ++#include <stdio.h> ++#include <inttypes.h> ++#include <math.h> ++#include <float.h> ++#include <fenv.h> ++ ++#include "float_helpers.h" ++ ++#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) ++ ++/* ++ * Half Precision Numbers ++ * ++ * Not yet well standardised so we return a plain uint16_t for now. ++ */ ++ ++/* no handy defines for these numbers */ ++static uint16_t f16_numbers[] = { ++ 0xffff, /* -NaN / AHP -Max */ ++ 0xfcff, /* -NaN / AHP */ ++ 0xfc01, /* -NaN / AHP */ ++ 0xfc00, /* -Inf */ ++ 0xfbff, /* -Max */ ++ 0xc000, /* -2 */ ++ 0xbc00, /* -1 */ ++ 0x8001, /* -MIN subnormal */ ++ 0x8000, /* -0 */ ++ 0x0000, /* +0 */ ++ 0x0001, /* MIN subnormal */ ++ 0x3c00, /* 1 */ ++ 0x7bff, /* Max */ ++ 0x7c00, /* Inf */ ++ 0x7c01, /* NaN / AHP */ ++ 0x7cff, /* NaN / AHP */ ++ 0x7fff, /* NaN / AHP +Max*/ ++}; ++ ++const int num_f16 = ARRAY_SIZE(f16_numbers); ++ ++uint16_t get_f16(int i) { ++ return f16_numbers[i % num_f16]; ++} ++ ++/* only display as hex */ ++char *fmt_16(uint16_t num) { ++ char *fmt; ++ asprintf(&fmt, "f16 %#04x", num); ++ return fmt; ++} ++ ++/* ++ * Single Precision Numbers ++ */ ++ ++#ifndef SNANF ++/* Signaling NaN macros, if supported. */ ++# if __GNUC_PREREQ(3, 3) ++# define SNANF (__builtin_nansf ("")) ++# define SNAN (__builtin_nans ("")) ++# define SNANL (__builtin_nansl ("")) ++# endif ++#endif ++ ++static float f32_numbers[] = { ++ -SNANF, ++ -NAN, ++ -INFINITY, ++ -FLT_MAX, ++ -1.111E+31, ++ -1.111E+30, ++ -1.08700982e-12, ++ -1.78051176e-20, ++ -FLT_MIN, ++ 0.0, ++ FLT_MIN, ++ 2.98023224e-08, ++ 5.96046E-8, /* min positive FP16 subnormal */ ++ 6.09756E-5, /* max subnormal FP16 */ ++ 6.10352E-5, /* min positive normal FP16 */ ++ 1.0, ++ 1.0009765625, /* smallest float after 1.0 FP16 */ ++ 2.0, ++ M_E, M_PI, ++ 65503.0, ++ 65504.0, /* max FP16 */ ++ 65505.0, ++ 131007.0, ++ 131008.0, /* max AFP */ ++ 131009.0, ++ 1.111E+30, ++ FLT_MAX, ++ INFINITY, ++ NAN, ++ SNANF ++}; ++ ++const int num_f32 = ARRAY_SIZE(f32_numbers); ++ ++float get_f32(int i) { ++ return f32_numbers[i % num_f32]; ++} ++ ++char *fmt_f32(float num) { ++ uint32_t single_as_hex = *(uint32_t *) # ++ char *fmt; ++ asprintf(&fmt, "f32 %02.20e / %#010x", num, single_as_hex); ++ return fmt; ++} ++ ++ ++/* This allows us to initialise some doubles as pure hex */ ++typedef union { ++ double d; ++ uint64_t h; ++} test_doubles; ++ ++static test_doubles f64_numbers[] = { ++ {SNAN}, ++ {-NAN}, ++ {-INFINITY}, ++ {-DBL_MAX}, ++ {-FLT_MAX-1.0}, ++ {-FLT_MAX}, ++ {-1.111E+31}, ++ {-1.111E+30}, /* half prec */ ++ {-2.0}, {-1.0}, ++ {-DBL_MIN}, ++ {-FLT_MIN}, ++ {0.0}, ++ {FLT_MIN}, ++ {2.98023224e-08}, ++ {5.96046E-8}, /* min positive FP16 subnormal */ ++ {6.09756E-5}, /* max subnormal FP16 */ ++ {6.10352E-5}, /* min positive normal FP16 */ ++ {1.0}, ++ {1.0009765625}, /* smallest float after 1.0 FP16 */ ++ {DBL_MIN}, ++ {1.3789972848607228e-308}, ++ {1.4914738736681624e-308}, ++ {1.0}, {2.0}, ++ {M_E}, {M_PI}, ++ {65503.0}, ++ {65504.0}, /* max FP16 */ ++ {65505.0}, ++ {131007.0}, ++ {131008.0}, /* max AFP */ ++ {131009.0}, ++ {.h = 0x41dfffffffc00000 }, /* to int = 0x7fffffff */ ++ {FLT_MAX}, ++ {FLT_MAX + 1.0}, ++ {DBL_MAX}, ++ {INFINITY}, ++ {NAN}, ++ {.h = 0x7ff0000000000001}, /* SNAN */ ++ {SNAN}, ++}; ++ ++const int num_f64 = ARRAY_SIZE(f64_numbers); ++ ++double get_f64(int i) { ++ return f64_numbers[i % num_f64].d; ++} ++ ++char *fmt_f64(double num) { ++ uint64_t double_as_hex = *(uint64_t *) # ++ char *fmt; ++ asprintf(&fmt, "f64 %02.20e / %#020" PRIx64, num, double_as_hex); ++ return fmt; ++} ++ ++/* ++ * Float flags ++ */ ++char *fmt_flags(void) ++{ ++ int flags = fetestexcept(FE_ALL_EXCEPT); ++ char *fmt; ++ ++ if (flags) { ++ asprintf(&fmt, "%s%s%s%s%s", ++ flags & FE_OVERFLOW ? "OVERFLOW " : "", ++ flags & FE_UNDERFLOW ? "UNDERFLOW " : "", ++ flags & FE_DIVBYZERO ? "DIV0 " : "", ++ flags & FE_INEXACT ? "INEXACT " : "", ++ flags & FE_INVALID ? "INVALID" : ""); ++ } else { ++ asprintf(&fmt, "OK"); ++ } ++ ++ return fmt; ++} +diff --git a/tests/tcg/multiarch/float_helpers.h b/tests/tcg/multiarch/float_helpers.h +new file mode 100644 +index 00000000000..4a1e2f3853a +--- /dev/null ++++ b/tests/tcg/multiarch/float_helpers.h +@@ -0,0 +1,26 @@ ++/* ++ * Common Float Helpers ++ * ++ * Copyright (c) 2019 Linaro ++ * ++ * SPDX-License-Identifier: GPL-3.0-or-later ++ */ ++ ++#include <inttypes.h> ++ ++/* Number of constants in each table */ ++extern const int num_f16; ++extern const int num_f32; ++extern const int num_f64; ++ ++/* Accessor helpers */ ++uint16_t get_f16(int i); /* use _Float16 when we can */ ++float get_f32(int i); ++double get_f64(int i); ++ ++/* Return format strings, free after use */ ++char * fmt_f16(uint16_t); ++char * fmt_f32(float); ++char * fmt_f64(double); ++/* exception flags */ ++char * fmt_flags(void); +diff --git a/tests/tcg/multiarch/float_madds.c b/tests/tcg/multiarch/float_madds.c +new file mode 100644 +index 00000000000..bc11eea9084 +--- /dev/null ++++ b/tests/tcg/multiarch/float_madds.c +@@ -0,0 +1,78 @@ ++/* ++ * Fused Multiply Add (Single) ++ * ++ * Copyright (c) 2019 Linaro ++ * ++ * SPDX-License-Identifier: GPL-3.0-or-later ++ */ ++ ++#include <stdio.h> ++#include <stdlib.h> ++#include <math.h> ++#include <float.h> ++#include <fenv.h> ++ ++#include "float_helpers.h" ++ ++#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) ++ ++typedef struct { ++ int flag; ++ char *desc; ++} float_mapping; ++ ++float_mapping round_flags[] = { ++ { FE_TONEAREST, "to nearest" }, ++ { FE_UPWARD, "upwards" }, ++ { FE_DOWNWARD, "downwards" }, ++ { FE_TOWARDZERO, "to zero" } ++}; ++ ++void print_result(float a, float b, float c, float r) ++{ ++ char *a_fmt, *b_fmt, *c_fmt, *r_fmt, *flag_fmt; ++ ++ a_fmt = fmt_f32(a); ++ b_fmt = fmt_f32(b); ++ c_fmt = fmt_f32(c); ++ r_fmt = fmt_f32(r); ++ flag_fmt = fmt_flags(); ++ ++ printf("%s * %s + %s = %s (%s)\n", ++ a_fmt, b_fmt, c_fmt, r_fmt, flag_fmt); ++ ++ free(a_fmt); ++ free(b_fmt); ++ free(c_fmt); ++ free(r_fmt); ++ free(flag_fmt); ++} ++ ++ ++int main(int argc, char *argv[argc]) ++{ ++ int i, j, k, l; ++ float a, b, c, r; ++ ++ for (i = 0; i < ARRAY_SIZE(round_flags); ++i) { ++ fesetround(round_flags[i].flag); ++ printf("### Rounding %s\n", round_flags[i].desc); ++ for (j = 0; j < num_f32; j += 3) { ++ for (k = 1; k < num_f32; k += 3 ) { ++ for (l = 2; l < num_f32; l += 3) { ++ a = get_f32(j); ++ b = get_f32(k); ++ c = get_f32(l); ++ feclearexcept(FE_ALL_EXCEPT); ++ ++ /* must be built with -O2 to generate fused op */ ++ r = a * b + c; ++ ++ print_result(a, b, c, r); ++ } ++ } ++ } ++ } ++ ++ return 0; ++} +-- +2.20.1 + + + +Dave ran the above testcase on: + +> processor : 0 +> cpu : POWER8E (raw), altivec supported +> clock : 3325.000000MHz +> revision : 2.1 (pvr 004b 0201) + +And there are no diffs with what you currently get from master. So I think the invalid flag fault is fixed by a previous commit and the potential precision faults don't get picked up by the test case. I guess we could be a bit smarted about testing the limits. + +On 9/13/19 8:49 AM, Alex Bennée wrote: +> +static float f32_numbers[] = { +> + -SNANF, +> + -NAN, +> + -INFINITY, +> + -FLT_MAX, +> + -1.111E+31, +> + -1.111E+30, +> + -1.08700982e-12, +> + -1.78051176e-20, +> + -FLT_MIN, +> + 0.0, +> + FLT_MIN, +> + 2.98023224e-08, +> + 5.96046E-8, /* min positive FP16 subnormal */ +> + 6.09756E-5, /* max subnormal FP16 */ +> + 6.10352E-5, /* min positive normal FP16 */ +> + 1.0, +> + 1.0009765625, /* smallest float after 1.0 FP16 */ +> + 2.0, +> + M_E, M_PI, +> + 65503.0, +> + 65504.0, /* max FP16 */ +> + 65505.0, +> + 131007.0, +> + 131008.0, /* max AFP */ +> + 131009.0, +> + 1.111E+30, +> + FLT_MAX, +> + INFINITY, +> + NAN, +> + SNANF +> +}; + +I've noticed that Glibc prefers to use hex representation for float values, to ensure an accurate representation. If you care to do so, here they are: +static float f32_numbers[] = { + -SNANF, + -NAN, + -INFINITY, + -FLT_MAX, + -0x1.1874b2p+103, + -0x1.c0bab6p+99, + -0x1.31f75p-40, + -0x1.505444p-66, + -FLT_MIN, + 0.0, + FLT_MIN, + 0x1p-25, + 0x1.ffffe6p-25, /* min positive FP16 subnormal */ + 0x1.ff801ap-15, /* max subnormal FP16 */ + 0x1.00000cp-14, /* min positive normal FP16 */ + 1.0, + 0x1.004p+0, /* smallest float after 1.0 FP16 */ + 2.0, + M_E, M_PI, + 0x1.ffbep+15, + 0x1.ffcp+15, /* max FP16 */ + 0x1.ffc2p+15, + 0x1.ffbfp+16, + 0x1.ffcp+16, /* max AFP */ + 0x1.ffc1p+16, + 0x1.c0bab6p+99, + FLT_MAX, + INFINITY, + NAN, + SNANF +}; + +PC + + + +Richard Henderson <email address hidden> writes: + +> On 9/13/19 9:49 AM, Alex Bennée wrote: +>> + /* must be built with -O2 to generate fused op */ +>> + r = a * b + c; +> +> I would prefer to use fmaf() or __builtin_fmaf() here. +> +> Although you'll need to link with -lm just in case the +> target doesn't support an instruction for fmaf and so +> the builtin expands to the standard library call. + +I can do that - we have other tests that link to libm. + +I was expecting to see more breakage but the ppc64 tests all passed (or +at least against the power8 David ran it on). What am I missing to hit +the cases you know are broken? + +I've also experimented with reducing the number of iterations because if +we want to have golden references we probably don't want to dump several +hundred kilobytes of "golden" references into the source tree. + +> I also like Paul's suggestion to use hex float constants. + +Hmm I guess - look a bit weird but I guess that's lack of familiarity. +Is is still normalised? I guess the frac shows up (without the implicit +bit). + +> +> +> r~ + + +-- +Alex Bennée + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1843073 b/results/classifier/zero-shot/108/permissions/1843073 new file mode 100644 index 000000000..3a6209af3 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1843073 @@ -0,0 +1,227 @@ +permissions: 0.931 +KVM: 0.931 +other: 0.927 +vnc: 0.925 +network: 0.917 +performance: 0.913 +graphic: 0.887 +PID: 0.886 +semantic: 0.885 +debug: 0.884 +device: 0.884 +boot: 0.879 +socket: 0.874 +files: 0.861 + +Network loose connection for long time under light load guest winxp64 with virtio on i5-8350U + +I have issue with qemu and winxp guest on i5-8350U. + +First of all, if i run same vm with same config on i5 9660k i do not see such issue. +Both pc have ubuntu 19.04 x86_64. + +Guest is winxp64, tried: +1) stable guest drivers, latest drivers +2) all virtio, only network r18169, bridge to host eth0, just default virbr0. +3) qemu from ubuntu 19.04, and tried latest libvirt and qeumu compiled from sources. +4) tried zram as block device + +I need really lightweight win to run only one app, so win7 and win10 is not an option. + + +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit winxp +or other application using the libvirt API. +--> + +<domain type='kvm'> + <name>winxp</name> + <uuid>93921ab3-222a-4e5f-89c4-36703fc65cb4</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://microsoft.com/win/xp"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>8388608</memory> + <currentMemory unit='KiB'>8388608</currentMemory> + <vcpu placement='static'>4</vcpu> + <cputune> + <vcpupin vcpu='0' cpuset='2'/> + <vcpupin vcpu='1' cpuset='3'/> + <vcpupin vcpu='2' cpuset='6'/> + <vcpupin vcpu='3' cpuset='7'/> + </cputune> + <os> + <type arch='x86_64' machine='pc-i440fx-4.1'>hvm</type> + </os> + <features> + <acpi/> + <apic/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + <vpindex state='on'/> + <synic state='on'/> + <stimer state='on'/> + </hyperv> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'> + <model fallback='allow'/> + </cpu> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='yes'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/local/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/zram0'/> + <target dev='vdb' bus='virtio'/> + <shareable/> + <boot order='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/var/lib/libvirt/images/virtio-win.iso'/> + <target dev='hdb' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d1:b3:87'/> + <source network='default'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' port='5900' autoport='no' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + <image compression='auto_glz'/> + <jpeg compression='auto'/> + <zlib compression='auto'/> + <playback compression='off'/> + <streaming mode='off'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> +</domain> + +Ping at the load moment: + ping 192.168.152.25 +PING 192.168.152.25 (192.168.152.25) 56(84) bytes of data. +64 bytes from 192.168.152.25: icmp_seq=1 ttl=128 time=0.300 ms +64 bytes from 192.168.152.25: icmp_seq=2 ttl=128 time=0.495 ms +64 bytes from 192.168.152.25: icmp_seq=3 ttl=128 time=0.442 ms +64 bytes from 192.168.152.25: icmp_seq=4 ttl=128 time=0.520 ms +64 bytes from 192.168.152.25: icmp_seq=5 ttl=128 time=0.558 ms +64 bytes from 192.168.152.25: icmp_seq=6 ttl=128 time=0.623 ms +64 bytes from 192.168.152.25: icmp_seq=7 ttl=128 time=0.668 ms +64 bytes from 192.168.152.25: icmp_seq=8 ttl=128 time=0.574 ms +64 bytes from 192.168.152.25: icmp_seq=9 ttl=128 time=0.390 ms +64 bytes from 192.168.152.25: icmp_seq=10 ttl=128 time=363 ms +From 192.168.152.1 icmp_seq=29 Destination Host Unreachable +From 192.168.152.1 icmp_seq=30 Destination Host Unreachable +From 192.168.152.1 icmp_seq=31 Destination Host Unreachable +From 192.168.152.1 icmp_seq=32 Destination Host Unreachable +From 192.168.152.1 icmp_seq=33 Destination Host Unreachable +From 192.168.152.1 icmp_seq=34 Destination Host Unreachable +From 192.168.152.1 icmp_seq=36 Destination Host Unreachable +From 192.168.152.1 icmp_seq=39 Destination Host Unreachable +From 192.168.152.1 icmp_seq=40 Destination Host Unreachable +64 bytes from 192.168.152.25: icmp_seq=11 ttl=128 time=33151 ms +64 bytes from 192.168.152.25: icmp_seq=12 ttl=128 time=32137 ms +From 192.168.152.1 icmp_seq=41 Destination Host Unreachable +From 192.168.152.1 icmp_seq=42 Destination Host Unreachable +From 192.168.152.1 icmp_seq=43 Destination Host Unreachable +From 192.168.152.1 icmp_seq=44 Destination Host Unreachable +From 192.168.152.1 icmp_seq=45 Destination Host Unreachable +From 192.168.152.1 icmp_seq=46 Destination Host Unreachable +From 192.168.152.1 icmp_seq=47 Destination Host Unreachable +From 192.168.152.1 icmp_seq=48 Destination Host Unreachable +From 192.168.152.1 icmp_seq=49 Destination Host Unreachable +From 192.168.152.1 icmp_seq=50 Destination Host Unreachable +64 bytes from 192.168.152.25: icmp_seq=13 ttl=128 time=39259 ms +64 bytes from 192.168.152.25: icmp_seq=14 ttl=128 time=38235 ms +64 bytes from 192.168.152.25: icmp_seq=15 ttl=128 time=37211 ms +64 bytes from 192.168.152.25: icmp_seq=16 ttl=128 time=36187 ms +64 bytes from 192.168.152.25: icmp_seq=17 ttl=128 time=35163 ms +64 bytes from 192.168.152.25: icmp_seq=18 ttl=128 time=34139 ms +64 bytes from 192.168.152.25: icmp_seq=19 ttl=128 time=33115 ms +64 bytes from 192.168.152.25: icmp_seq=20 ttl=128 time=32091 ms +64 bytes from 192.168.152.25: icmp_seq=21 ttl=128 time=31068 ms +64 bytes from 192.168.152.25: icmp_seq=22 ttl=128 time=30044 ms +64 bytes from 192.168.152.25: icmp_seq=23 ttl=128 time=29020 ms +64 bytes from 192.168.152.25: icmp_seq=24 ttl=128 time=27996 ms +64 bytes from 192.168.152.25: icmp_seq=25 ttl=128 time=26968 ms +64 bytes from 192.168.152.25: icmp_seq=26 ttl=128 time=25948 ms +64 bytes from 192.168.152.25: icmp_seq=27 ttl=128 time=24924 ms +64 bytes from 192.168.152.25: icmp_seq=28 ttl=128 time=23900 ms +64 bytes from 192.168.152.25: icmp_seq=51 ttl=128 time=412 ms +64 bytes from 192.168.152.25: icmp_seq=52 ttl=128 time=0.167 ms +64 bytes from 192.168.152.25: icmp_seq=53 ttl=128 time=0.559 ms +64 bytes from 192.168.152.25: icmp_seq=54 ttl=128 time=0.656 ms + + +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/zero-shot/108/permissions/1843205 b/results/classifier/zero-shot/108/permissions/1843205 new file mode 100644 index 000000000..77cb76ae9 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1843205 @@ -0,0 +1,121 @@ +permissions: 0.960 +device: 0.956 +performance: 0.945 +other: 0.941 +debug: 0.938 +graphic: 0.929 +semantic: 0.928 +vnc: 0.924 +PID: 0.911 +KVM: 0.904 +socket: 0.892 +files: 0.871 +network: 0.863 +boot: 0.863 + +Inaccurate Fmod on i386 + +# Qemu Version + +```bash +$ qemu-i386 --version +qemu-i386 version 3.0.1 (qemu-3.0.1-4.fc29) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +``` + +# Failing Source Code (C) + +```c +#include <math.h> +#include <stdio.h> + +int main() +{ + double x = 29860476080414620.0; + double y = 17.0; + double z = fmod(x, y); + printf("%f\n", z); + return 0; +} +``` + +The code was compiled with GCC (8.3.1) on x86-64 with the flags `-O3 -m32 -lm -static`. + +# Emitted (Annotated) Assembly + +In order to facilitate debugging the issue, the following assembly was generated to show nothing unusual occurred during compilation. The assembly was generated with flags `-S -O3 -m32 -lm`, and then annotated to show the operands to fmod. + +```asm + .file "a.c" + .text + .section .rodata.str1.1,"aMS",@progbits,1 +.LC2: + .string "%f\n" + .section .text.startup,"ax",@progbits + .p2align 4,,15 + .globl main + .type main, @function +main: +.LFB16: + .cfi_startproc + leal 4(%esp), %ecx + .cfi_def_cfa 1, 0 + andl $-16, %esp + pushl -4(%ecx) + pushl %ebp + .cfi_escape 0x10,0x5,0x2,0x75,0 + movl %esp, %ebp + pushl %ecx + .cfi_escape 0xf,0x3,0x75,0x7c,0x6 + subl $4, %esp + pushl $1076953088 ; high 32-bits of double for y + pushl $0 ; low 32-bits of double for y + pushl $1130005884 ; high 32-bits of double for x + pushl $2003187687 ; low 32-bits of double for x + call fmod + movl $.LC2, (%esp) + fstpl 4(%esp) + call printf + movl -4(%ebp), %ecx + .cfi_def_cfa 1, 0 + addl $16, %esp + xorl %eax, %eax + leave + .cfi_restore 5 + leal -4(%ecx), %esp + .cfi_def_cfa 4, 4 + ret + .cfi_endproc +.LFE16: + .size main, .-main + .ident "GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)" + .section .note.GNU-stack,"",@progbits +``` + +# Result + +Running the compiled binary on x86_64 produces the expected value of `15.000000`, while using `qemu-i386 <binary>` produces the unexpected result of `-4.000000`. + +This was tested against: + +1. Qemu 3.0.1 for Fedora 29. +2. Qemu 4.1.0 built from source, downloaded from https://download.qemu.org/qemu-4.1.0.tar.xz +3. Qemu built-from-source against commit 90b1e3afd33226b6078fec6d77a18373712a975c. + +# Building Qemu + +Qemu built-from-source was compiled as follows: + +```bash +mkdir build && cd build +../configure --disable-kvm --target-list="i386-linux-user" +make -j 5 +``` + +# Results + +All built versions of Qemu running the 32-bit failed to produce the accurate result. Using qemu-x86_64 against an x86_64 binary built from the same C source code produces correct results. Running the 32-bit binary natively produces the correct result. + +On current head-of-git QEMU I get the correct answer. I think this was probably fixed by the reimplementation of the 'fprem' emulation in commit 5ef396e2ba86, which was in the 5.1.0 release. + + diff --git a/results/classifier/zero-shot/108/permissions/1843651 b/results/classifier/zero-shot/108/permissions/1843651 new file mode 100644 index 000000000..be9922f1c --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1843651 @@ -0,0 +1,113 @@ +permissions: 0.941 +other: 0.936 +debug: 0.924 +device: 0.915 +performance: 0.906 +semantic: 0.906 +KVM: 0.897 +graphic: 0.890 +socket: 0.879 +network: 0.867 +PID: 0.866 +files: 0.858 +vnc: 0.855 +boot: 0.831 + +m68k fpu bug + +On gcc123 cfarm machine, +I was testing m68k executables generated by Free Pascal Compiler. + +muller@gcc123:~/pas/check$ cat inf.pp +function get_double(x : double):double; + begin + get_double:=x; + end; + + +var + y : double; + py : pbyte; + i : byte; +begin + y:=1.0/0.0; + py:=@y; +{$ifdef ENDIAN_LITTLE} + write('little endian y='); + for i:=7 downto 0 do +{$else not ENDIAN_LITTLE} + write('big endian y='); + for i:=0 to 7 do +{$endif} + write(hexstr(py[i],2)); + writeln; + y:=get_double(y)+1; +{$ifdef ENDIAN_LITTLE} + write('little endian y='); + for i:=7 downto 0 do +{$else not ENDIAN_LITTLE} + write('big endian y='); + for i:=0 to 7 do +{$endif} + write(hexstr(py[i],2)); + writeln; +end. +muller@gcc123:~/pas/check$ ppc68k inf +Free Pascal Compiler version 3.3.1-r20:42973M [2019/09/11] for m68k +Copyright (c) 1993-2019 by Florian Klaempfl and others +Target OS: Linux for m68k +Compiling inf.pp +Assembling program +Linking inf +33 lines compiled, 0.1 sec +muller@gcc123:~/pas/check$ ./inf +big endian y=7FF0000000000000 +big endian y=7FFFFFFFFFFFFFFF +muller@gcc123:~/pas/check$ qemu-m68k ./inf +big endian y=7FF0000000000000 +big endian y=7FFFFFFFFFFFFFFF +muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k ./inf +qemu-m68k qemu-m68k-fixed +muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k-fixed ./inf +big endian y=7FF0000000000000 +big endian y=7FF0000000000000 + +~/sys-root/bin/qemu-m68k is 4.1.0 release, +~/sys-root/bin/qemu-m68k-fixed is the same source with a unique change: + +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h:214:#if defined(TARGET_M68K) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-215-#define floatx80_infinity_low LIT64(0x0000000000000000) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-216-#else +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-217-#define floatx80_infinity_low LIT64(0x8000000000000000) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-218-#endif + +the M68K branch value is set to the same value as the other branch. + +The problem of the M68K specific floatx86_infinity_low values +is that is enters in conflict with +muller@gcc123:~/pas/check$ grep -nA6 invalid_enc /home/muller/gnu/qemu/qemu-4.1.0/include/fpu/softfloat.h +752:static inline bool floatx80_invalid_encoding(floatx80 a) +753-{ +754- return (a.low & (1ULL << 63)) == 0 && (a.high & 0x7FFF) != 0; +755-} + +And thus the m68k variant of floatx80 representing +Infinity is +considered as an invalid encoding, and thus converted into a NaN 7FFFFFFFFFFFFFFF + +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. + + + I tested, in release 5.2.0, this issue is fixed. + +Thanks + diff --git a/results/classifier/zero-shot/108/permissions/1856837 b/results/classifier/zero-shot/108/permissions/1856837 new file mode 100644 index 000000000..3a3b03a64 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1856837 @@ -0,0 +1,123 @@ +permissions: 0.961 +other: 0.939 +debug: 0.928 +device: 0.926 +semantic: 0.925 +graphic: 0.920 +files: 0.876 +vnc: 0.873 +socket: 0.872 +performance: 0.856 +PID: 0.842 +KVM: 0.836 +network: 0.793 +boot: 0.793 + +qemu 4.2.0 arm segmentation fault with gcc 9.2 + +As discussed with f4bug yesterday on IRC here comes the bug description. + +I'm building/configured qemu-4.2.0 on an x86_64 (gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516) with target-list "arm-softmmu,arm-linux-user" and debug enabled. I use the arm-linux-user variant, "qemu-arm". + +Then i'm trying to cross-compile (arm gcc) an old version of googles v8 (as i need this version of the lib for binary compatibility) which uses qemu during build. + +It worked with gcc 5.4.0 but not with 9.2.0. I also tried with 6.5.0, 7.4.0 and 8.3.0 but those are also causing the same segmentation fault. + +The executed command wich breaks qemu is: + + qemu-arm /tmp/build/out/arm.release/mksnapshot.arm --log-snapshot-positions --logfile /tmp/build/out/arm.release/obj.host/v8_snapshot/geni/snapshot.log --random-seed 314159265 /tmp/build/out/arm.release/obj.host/v8_snap + +The printed error message is: + +ARMv7=1 VFP3=1 VFP32DREGS=1 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=1 MOVW_MOVT_IMMEDIATE_LOADS=0 USE_EABI_HARDFLOAT=1 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Calling qemu with gdb gives the following information: + + Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault. + 0x0000555555d63d11 in static_code_gen_buffer () + +and + + (gdb) bt + #0 0x0000555555d63d11 in static_code_gen_buffer () + #1 0x0000555555628d58 in cpu_tb_exec (itb=<optimized out>, cpu=0x555557c33930) at + /tmp/build/qemu/accel/tcg/cpu-exec.c:172 + #2 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x555557c33930) at /tmp/build/qemu/accel/tcg/cpu-exec.c:618 + #3 cpu_exec (cpu=cpu@entry=0x555557c2b660) at /tmp/build/qemu/accel/tcg/cpu-exec.c:731 + #4 0x0000555555661578 in cpu_loop (env=0x555557c33930) at /tmp/build/qemu/linux-user/arm/cpu_loop.c:219 +#5 0x00005555555d6d76 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /tmp/build/qemu/linux-user/main.c:865 + +Calling qemu-arm with debug switch "-d in_asm,int,op_opt" shows the log in the attached file. + +Thanks for any hints! +Fabian + + + +Can you provide a repro case (attach binary/etc to the bug) so we can investigate? + +Note that QEMU will produce that segfault message both for bugs in QEMU (where it unexpectedly segfaults) but also for bugs in the guest binary itself where we're correctly emulating "guest did something causing a segfault". + + +Sorry for the delay. I added the sysroot, the binary and the files causing the segfault. +Please let me know if there is something missing. + +I used the following commands to let it run: + +export LD_LIBRARY_PATH=/opt/qemu-test/test1/lib +/opt/qemu-test/test1/bin/qemu-arm "/opt/qemu-test/test1/files/mksnapshot.arm" --log-snapshot-positions --logfile "/tmp/snapshot.log" --random-seed 314159265 "/tmp/snapshot.cc" + + +Thanks again! +Fabian + +At the point of the segfault, QEMU is correctly delivering a segfault to the guest because it has attempted to dereference a NULL pointer. You can see this if you run QEMU with the '-g 1234' option and connect an arm-aware gdb to it: + +(gdb) disas $pc-32,$pc+32 +Dump of assembler code from 0x2bf24c to 0x2bf28c: + 0x002bf24c: ldr r4, [r0, #296] ; 0x128 + 0x002bf250: mov r6, r1 + 0x002bf254: add r8, r0, #40 ; 0x28 + 0x002bf258: mov r5, #0 + 0x002bf25c: b 0x2bf268 + 0x002bf260: cmp r5, r6 + 0x002bf264: bge 0x2bf2d4 + 0x002bf268: mov r12, r4 +=> 0x002bf26c: ldr r4, [r4] + 0x002bf270: ldr r3, [r12, #12] + 0x002bf274: tst r3, #512 ; 0x200 + 0x002bf278: bne 0x2bf2c0 + 0x002bf27c: tst r3, #1024 ; 0x400 + 0x002bf280: ubfx r1, r3, #11, #1 + 0x002bf284: bne 0x2bf2c0 + 0x002bf288: tst r3, #2048 ; 0x800 +End of assembler dump. +(gdb) print /x $r4 +$3 = 0x0 + +It looks like this is in the middle of somebody's garbage collector (the elf symbol is _ZN2v88internal10PagedSpace14AdvanceSweeperEi). + +The next step would be to find out what was going on in the run-up to that that resulted in the NULL pointer. That's a bit of guest-level debugging work that would be much easier with the source code. If you can debug where something unexpected happens to the guest that would probably help -- this is likely to be a much longer piece of debugging than I'm afraid I have time to do. + + +Thanks, this helps a lot! We will now check the code again and see what causes the behaviour. + +Fabian + +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/zero-shot/108/permissions/1867786 b/results/classifier/zero-shot/108/permissions/1867786 new file mode 100644 index 000000000..872995697 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1867786 @@ -0,0 +1,150 @@ +permissions: 0.973 +vnc: 0.967 +semantic: 0.967 +device: 0.960 +PID: 0.957 +other: 0.957 +socket: 0.954 +debug: 0.954 +network: 0.952 +graphic: 0.943 +performance: 0.942 +files: 0.935 +boot: 0.920 +KVM: 0.882 + +Qemu PPC64 freezes with multi-core CPU + +I installed Debian 10 on a Qemu PPC64 VM running with the following flags: + +qemu-system-ppc64 \ + -nographic -nodefaults -monitor pty -serial stdio \ + -M pseries -cpu POWER9 -smp cores=4,threads=1 -m 4G \ + -drive file=debian-ppc64el-qemu.qcow2,format=qcow2,if=virtio \ + -netdev user,id=network01,$ports -device rtl8139,netdev=network01 \ + + +Within a couple minutes on any operation (could be a Go application or simply changing the hostname with hostnamectl, the VM freezes and prints this on the console: + +``` +root@debian:~# [ 950.428255] rcu: INFO: rcu_sched self-detected stall on CPU +[ 950.428453] rcu: 3-....: (5318 ticks this GP) idle=8e2/1/0x4000000000000004 softirq=5957/5960 fqs=2544 +[ 976.244481] watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [zsh:462] + +Message from syslogd@debian at Mar 17 11:35:24 ... + kernel:[ 976.244481] watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [zsh:462] +[ 980.110018] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 3-... } 5276 jiffies s: 93 root: 0x8/. +[ 980.111177] rcu: blocking rcu_node structures: +[ 1013.442268] rcu: INFO: rcu_sched self-detected stall on CPU +[ 1013.442365] rcu: 3-....: (21071 ticks this GP) idle=8e2/1/0x4000000000000004 softirq=5957/5960 fqs=9342 +``` + +If I change to 1 core on the command line, I haven't seen these freezes. + +Is this with KVM or with TCG? +What is your hardware configuration? + +It's soft emulation, running Qemu 4.2.50 (from master branch) on MacOS Mojave. + +Do you have the problem with 4.2.0? +Can you identify the commit introducing the problem? + +I just reverted to 4.2.0 and it works fine. No freezes for the past hour. + +❯ qemu-system-ppc64 --version +QEMU emulator version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Couldn't bisect to find the bad commit. + +Carlos + +Thank you for the test. I'm going to try to reproduce the problem and bisect. + +I'm not able to reproduce (kernel 4.19.0-8-powerpc64le, qemu id d649689a8ecb) + +What is the kernel version in the guest? +What is the QEMU commit id you used to test with 4.2.50? + +Hi Laurent, I'm on a MacOS Mojave running Qemu installed by homebrew from master branch on the day I've opened the bug. + +The option to install was: `brew install --HEAD qemu -s --verbose`. + +Maybe it's a Mac related problem? + +Hi, any news about this? Can I provide any additional info since it might be a Mac issue. +Thanks + +I just built from latest master and got the kernel trace below. + +❯ qemu-system-ppc64 --version +QEMU emulator version 4.2.90 (v4.2.0-2811-g83019e81d1-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + +qemu-system-ppc64 \ + -nographic -nodefaults -monitor pty -serial stdio \ + -M pseries -cpu POWER9 -smp cores=4,threads=1 -m 4G \ + -drive file=debian-ppc64el-qemu.qcow2,format=qcow2,if=virtio \ + -netdev user,id=network01,hostfwd=tcp::$LocalSSHPort-:22 -device rtl8139,netdev=network01 \ + + +[ 376.219450] watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [swapper/3:0] +[ 376.226712] Modules linked in: ctr(E) vmx_crypto(E) gf128mul(E) sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) virtio_blk(E) 8139too(E) virtio_pci(E) virtio_ring(E) 8139cp(E) virtio(E) mii(E) +[ 376.235692] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G E 5.5.0-rc5-powerpc64le #1 Debian 5.5~rc5-1~exp1 +[ 376.236245] NIP: c00000000000af8c LR: c000000000019664 CTR: c000000000af2c80 +[ 376.236365] REGS: c0000000fffcf920 TRAP: 0901 Tainted: G E (5.5.0-rc5-powerpc64le Debian 5.5~rc5-1~exp1) +[ 376.236376] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 44002248 XER: 00000000 +[ 376.236479] CFAR: c000000000af2ce0 IRQMASK: 0 + GPR00: c000000000af2e38 c0000000fffcfbb0 c000000001365700 0000000000000500 + GPR04: 00000000fef90000 0000002be1f69c00 0000002beaa729fa c0000000fffec880 + GPR08: 0000000400000000 00000000000080ff 0000000000000001 c0080000004c6ff0 + GPR12: 0000000000002000 c0000000fffec880 +[ 376.238452] NIP [c00000000000af8c] replay_interrupt_return+0x0/0x4 +[ 376.238488] LR [c000000000019664] arch_local_irq_restore.part.0+0x54/0x70 +[ 376.238984] Call Trace: +[ 376.240707] [c0000000fffcfbb0] [c0000000008ce910] napi_gro_receive+0x1e0/0x210 (unreliable) +[ 376.240824] [c0000000fffcfbd0] [c000000000af2e38] _raw_spin_unlock_irqrestore+0x98/0xb0 +[ 376.242114] [c0000000fffcfbf0] [c0080000004c5588] cp_rx_poll+0x580/0x610 [8139cp] +[ 376.242131] [c0000000fffcfcf0] [c0000000008cf6c8] net_rx_action+0x1f8/0x550 +[ 376.242139] [c0000000fffcfe10] [c000000000af3a8c] __do_softirq+0x16c/0x3d8 +[ 376.242172] [c0000000fffcff30] [c0000000001329e8] irq_exit+0xd8/0x120 +[ 376.242181] [c0000000fffcff60] [c000000000019fb4] __do_irq+0x84/0x1c0 +[ 376.242193] [c0000000fffcff90] [c00000000002cbec] call_do_irq+0x14/0x24 +[ 376.242201] [c0000000fd4b7980] [c00000000001a178] do_IRQ+0x88/0xf0 +[ 376.242209] [c0000000fd4b79c0] [c000000000008d98] hardware_interrupt_common+0x158/0x160 +[ 376.242243] --- interrupt: 501 at plpar_hcall_norets+0x1c/0x28 + LR = check_and_cede_processor+0x48/0x60 +[ 376.243892] [c0000000fd4b7cc0] [c0000000fd4b7cf0] 0xc0000000fd4b7cf0 (unreliable) +[ 376.243922] [c0000000fd4b7d20] [c00000000086c710] shared_cede_loop+0x50/0x160 +[ 376.243942] [c0000000fd4b7d50] [c000000000868844] cpuidle_enter_state+0xa4/0x590 +[ 376.243953] [c0000000fd4b7dd0] [c000000000868dcc] cpuidle_enter+0x4c/0x70 +[ 376.243983] [c0000000fd4b7e10] [c000000000177d4c] call_cpuidle+0x4c/0x90 +[ 376.243991] [c0000000fd4b7e30] [c000000000178358] do_idle+0x2f8/0x400 +[ 376.243998] [c0000000fd4b7ed0] [c0000000001786a8] cpu_startup_entry+0x38/0x40 +[ 376.244011] [c0000000fd4b7f00] [c00000000004e910] start_secondary+0x640/0x670 +[ 376.244020] [c0000000fd4b7f90] [c00000000000b354] start_secondary_prolog+0x10/0x14 +[ 376.244093] Instruction dump: +[ 376.244751] 7d200026 618c8000 2c030900 4182e348 2c030500 4182dcd0 2c030f00 4182f318 +[ 376.244797] 2c030a00 4182ffc8 60000000 60000000 <4e800020> 7c781b78 480003d9 480003f1 + +Could you try to change the network card, with something like "-device e1000e,netdev=network01" or "-device virtio-net-pci,netdev=network01" or "-device spapr-vlan,netdev=network01"? + +Hi Laurent, confirm that after changing the network adapter to the e1000e it worked flawlessly for hours with 4 cores on Macbook Pro. + +Thanks! + +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 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/zero-shot/108/permissions/1868116 b/results/classifier/zero-shot/108/permissions/1868116 new file mode 100644 index 000000000..0acfcdb24 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1868116 @@ -0,0 +1,523 @@ +permissions: 0.984 +other: 0.972 +network: 0.968 +graphic: 0.966 +semantic: 0.958 +device: 0.955 +vnc: 0.954 +PID: 0.950 +files: 0.938 +socket: 0.934 +debug: 0.931 +performance: 0.927 +KVM: 0.912 +boot: 0.887 + +QEMU monitor no longer works + +It was observed that the QEMU console (normally accessible using Ctrl+Alt+2) accepts no input, so it can't be used. This is being problematic because there are cases where it's required to send commands to the guest, or key combinations that the host would grab (as Ctrl-Alt-F1 or Alt-F4). + +ProblemType: Bug +DistroRelease: Ubuntu 20.04 +Package: qemu 1:4.2-3ubuntu2 +Uname: Linux 5.6.0-rc6+ x86_64 +ApportVersion: 2.20.11-0ubuntu20 +Architecture: amd64 +CurrentDesktop: XFCE +Date: Thu Mar 19 12:16:31 2020 +Dependencies: + +InstallationDate: Installed on 2017-06-13 (1009 days ago) +InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + qemu-system-x86 Sl+ 1000 1000 34275 25235 29.2 qemu-system-x86_64 -m 4G -cpu Skylake-Client -device virtio-vga,virgl=true,xres=1280,yres=720 -accel kvm -device nec-usb-xhci -serial vc -serial stdio -hda /home/usuario/Sistemas/androidx86.img -display gtk,gl=on -device usb-audio + kvm-nx-lpage-re S 0 0 34284 2 0.0 [kvm-nx-lpage-re] + kvm-pit/34275 S 0 0 34286 2 0.0 [kvm-pit/34275] +MachineType: LENOVO 80UG +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc6+ root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet ro kvm.ignore_msrs=1 kvm.report_ignored_msrs=0 kvm.halt_poll_ns=0 kvm.halt_poll_ns_grow=0 i915.enable_gvt=1 i915.fastboot=1 cgroup_enable=memory swapaccount=1 zswap.enabled=1 zswap.zpool=z3fold resume=UUID=a82e38a0-8d20-49dd-9cbd-de7216b589fc log_buf_len=16M usbhid.quirks=0x0079:0x0006:0x100000 config_scsi_mq_default=y scsi_mod.use_blk_mq=1 mtrr_gran_size=64M mtrr_chunk_size=64M nbd.nbds_max=2 nbd.max_part=63 +SourcePackage: qemu +UpgradeStatus: Upgraded to focal on 2019-12-22 (87 days ago) +dmi.bios.date: 08/09/2018 +dmi.bios.vendor: LENOVO +dmi.bios.version: 0XCN45WW +dmi.board.asset.tag: NO Asset Tag +dmi.board.name: Toronto 4A2 +dmi.board.vendor: LENOVO +dmi.board.version: SDK0J40679 WIN +dmi.chassis.asset.tag: NO Asset Tag +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Lenovo ideapad 310-14ISK +dmi.modalias: dmi:bvnLENOVO:bvr0XCN45WW:bd08/09/2018:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK: +dmi.product.family: IDEAPAD +dmi.product.name: 80UG +dmi.product.sku: LENOVO_MT_80UG_BU_idea_FM_Lenovo ideapad 310-14ISK +dmi.product.version: Lenovo ideapad 310-14ISK +dmi.sys.vendor: LENOVO +mtime.conffile..etc.apport.crashdb.conf: 2019-08-29T08:39:36.787240 + + + +Hi Leonardo, + +I first ran something in libvirt as usual, and I got monitor access through libvirt as usual. +For example: + $ virsh qemu-monitor-command focal3 --pretty '{"execute":"query-block"}' + +Then I started a most basic qemu to get the usual UI. + $ qemu-system-x86_64 -enable-kvm --drive media=cdrom,file=http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/current/images/netboot/mini.iso + +I can switch to the monitor there + default grab is CTRL+ALT + monitor on SHIFT+2 + +I was only once able to switch to the monitor, and then I failed to enter something just as you describe it. Setting to confirmed, but this needs a deeper look. + +ok CTL+ALT+2 (without shift) is working well to switch - also the GTK UI has a menu to switch which works as well. But on all of those tries no way to enter to the monitor. + +This still worked in Eoan, I double checked and it indeed does. +So it is not the change to GTK which I assumed first to be relate. + +To ease repro of the case, this can be seen even if "ssh -XY" into Eoan/Focal containers. + +I retried with the latest qemu as I recently did some misc fixes in the form of a stable update. +But with that it fails as well. + +I started to consider bisecting: + +#1 check if v4.2.0 from upstream exposes the behavior + => yes it does +#2 check if v4.0.0 from upstream does not expose the behavior + => No, v4.0.0 is as broken as th v4.2.0 build + +Hmm, this used the same build options and the same build environment. +Might it again be an issue with the BIOS or the libraries? + + +Copying the binaries into an Eoan environment makes them work. + +Since they use all sorts of local resources e.g. bios file lets make sure none in the system are avaiable. + +It is not again seabios (bug 1866870), but what is it ... ? +I removed all of the packaged qemu and dependencies. +Behavior still is the same. + +I took a snapshot to later revert and retry as needed. + +$ lxc info e +Name: e +Location: none +Remote: unix:// +Architecture: x86_64 +Created: 2020/03/20 08:52 UTC +Status: Stopped +Type: container +Profiles: default, kvm +Snapshots: + e-with-working-qemu-monitor (taken at 2020/03/24 10:52 UTC) (stateless) + +Then I did a full upgrade eoan to focal and ran the same binary that formerly worked. +Note: 484 packages upgraded + +Now the input is no more working, therefore the next step is to break down those 484 packages to identify which dependency it was that changed the behavior. + +Step 1: libc/libpython +The following additional packages will be installed: + alsa-topology-conf alsa-ucm-conf cryptsetup cryptsetup-initramfs gcc-10-base libasound2 libasound2-data libc-bin libc6 libcanberra0 libcrypt1 libffi7 libgcc-s1 libltdl7 libpython3.8 + libpython3.8-minimal libpython3.8-stdlib libtdb1 libvorbis0a libvorbisenc2 libvorbisfile3 locales sound-theme-freedesktop vim-common vim-runtime vim-tiny +Suggested packages: + keyutils libasound2-plugins alsa-utils glibc-doc libcanberra-gtk0 libcanberra-pulse ctags vim-doc vim-scripts indent +The following NEW packages will be installed: + alsa-topology-conf alsa-ucm-conf gcc-10-base libasound2 libasound2-data libcanberra0 libcrypt1 libffi7 libgcc-s1 libltdl7 libpython3.8 libpython3.8-minimal libpython3.8-stdlib libtdb1 + libvorbisfile3 sound-theme-freedesktop +The following packages will be upgraded: + cryptsetup cryptsetup-initramfs libc-bin libc6 libvorbis0a libvorbisenc2 locales vim vim-common vim-runtime vim-tiny + +=> Still working + +Step 2: zlib1g xxd xkb-data xfsprogs uuid-runtime util-linux usbutils usb.ids update-notifier-common update-manager-core unattended-upgrades ufw ubuntu-mono ubuntu-minimal ubuntu-keyring ubuntu-advantage-tools ubuntu-release-upgrader-core tzdata tmux telnet tcpdump (and dependencies) + +The following additional packages will be installed: + apt apt-utils libapt-pkg6.0 libevent-2.1-7 libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libicu66 libnewt0.52 libpython3-stdlib libseccomp2 python3 python3-apt python3-cffi-backend + python3-dbus python3-distupgrade python3-gi python3-markupsafe python3-minimal python3-netifaces python3-newt python3-simplejson python3-systemd python3-twisted-bin + python3-update-manager python3-yaml python3-zope.interface python3.8 python3.8-minimal +Suggested packages: + apt-doc aptitude | synaptic | wajig dpkg-dev python3-doc python3-tk python3-venv python3-apt-dbg python-apt-doc python-dbus-doc python3-dbus-dbg python3-twisted-bin-dbg python3.8-venv + python3.8-doc binutils binfmt-support bsd-mailx default-mta | mail-transport-agent needrestart util-linux-locales xfsdump attr quota +The following NEW packages will be installed: + libapt-pkg6.0 libevent-2.1-7 libicu66 python3.8 python3.8-minimal +The following packages will be upgraded: + apt apt-utils libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libnewt0.52 libpython3-stdlib libseccomp2 python3 python3-apt python3-cffi-backend python3-dbus python3-distupgrade + python3-gi python3-markupsafe python3-minimal python3-netifaces python3-newt python3-simplejson python3-systemd python3-twisted-bin python3-update-manager python3-yaml + python3-zope.interface tcpdump telnet tmux tzdata ubuntu-advantage-tools ubuntu-keyring ubuntu-mono ubuntu-release-upgrader-core ufw unattended-upgrades update-manager-core + update-notifier-common usb.ids usbutils util-linux uuid-runtime xfsprogs xkb-data xxd zlib1g +44 upgraded, 5 newly installed, 0 to remove and 381 not upgraded. + +=> Still working + +Step 3: systemd systemd-sysv sysvinit-utils udev sudo ssh-import-id snapd + + +The following additional packages will be installed: + libnss-systemd libpam-systemd libsystemd0 libudev1 +Suggested packages: + zenity | kdialog systemd-container +The following packages will be upgraded: + libnss-systemd libpam-systemd libsystemd0 libudev1 snapd ssh-import-id sudo systemd systemd-sysv sysvinit-utils udev +11 upgraded, 0 newly installed, 0 to remove and 370 not upgraded. + +The following packages will be REMOVED: + libevent-2.1-6 libpython3.7 libpython3.7-minimal libpython3.7-stdlib libsodium23 python3-nacl python3-pymacaroons python3.7 python3.7-minimal + + +=> Still working + +Step 4: python* + +The following additional packages will be installed: + command-not-found python3-distutils python3-hamcrest python3-importlib-metadata python3-lib2to3 python3-more-itertools python3-pyrsistent python3-setuptools python3-zipp + software-properties-common +Suggested packages: + python-attr-doc python-blinker-doc python-configobj-doc python-cryptography-doc python3-cryptography-vectors python3-gdbm-dbg python-jinja2-doc python-jsonschema-doc python3-crypto + gnome-keyring libkf5wallet-bin python3-keyrings.alt python3-testresources python-openssl-doc python3-openssl-dbg python3-socks python-secretstorage-doc python3-wxgtk3.0 | python3-wxgtk + python-setuptools-doc python3-tk python3-gtk2 python3-glade2 python3-pampy python3-qt4 python3-wxgtk2.8 +The following NEW packages will be installed: + python3-distutils python3-hamcrest python3-importlib-metadata python3-lib2to3 python3-more-itertools python3-pyrsistent python3-setuptools python3-zipp +The following packages will be upgraded: + command-not-found python-apt-common python3-apport python3-asn1crypto python3-attr python3-automat python3-blinker python3-certifi python3-chardet python3-click python3-colorama + python3-commandnotfound python3-configobj python3-constantly python3-cryptography python3-debian python3-distro python3-distro-info python3-entrypoints python3-gdbm python3-httplib2 + python3-hyperlink python3-idna python3-incremental python3-jinja2 python3-json-pointer python3-jsonschema python3-jwt python3-keyring python3-launchpadlib python3-lazr.restfulclient + python3-lazr.uri python3-oauthlib python3-openssl python3-pkg-resources python3-problem-report python3-pyasn1 python3-pyasn1-modules python3-requests python3-requests-unixsocket + python3-secretstorage python3-serial python3-service-identity python3-six python3-software-properties python3-twisted python3-urllib3 python3-wadllib software-properties-common +49 upgraded, 8 newly installed, 0 to remove and 320 not upgraded. + +=> Still working + +Step 5: further non lib binaries + +The following additional packages will be installed: + bind9-dnsutils bind9-libs libacl1 libbz2-1.0 libcurl4 libdbus-1-3 libdconf1 libdns-export1109 libext2fs2 libfuse2 libfwupd2 libfwupdplugin1 libgcc1 libgusb2 libip4tc2 libip6tc2 + libisc-export1105 libklibc libkmod2 liblocale-gettext-perl liblz4-1 libmagic-mgc libmagic1 libmaxminddb0 libncurses6 libncursesw6 libnftnl11 libpackagekit-glib2-18 libparted2 libpci3 + libperl5.30 libplymouth5 libprocps8 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtinfo6 libtss2-esys0 libuv1 libxmlb1 libxtables12 pci.ids perl-modules-5.30 tpm-udev +Suggested packages: + apparmor-profiles-extra apparmor-utils apport-gtk | apport-kde bash-doc duperemove ccze gnome-terminal | xterm po-debconf speedometer ttf-ubuntu-font-family wireless-tools bzip2-doc + libarchive1 anacron checksecurity default-mta | mail-transport-agent pinentry-gnome3 tor gpart fuse2fs e2fsck-static mlocate | locate gawk-doc git-daemon-run | git-daemon-sysvinit + git-doc git-el git-email git-gui gitk gitweb git-cvs git-mediawiki git-svn parcimonie xloadimage scdaemon groff iproute2-doc firewalld nftables traceroute resolvconf avahi-autoipd + isc-dhcp-client-ddns isoquery mmdb-bin libparted-dev libparted-i18n www-browser nfs-common multipath-tools-boot hunspell network-manager | wpasupplicant keychain libpam-ssh monkeysphere + ssh-askpass molly-guard haveged appstream parted-doc perl-doc libterm-readline-gnu-perl | libterm-readline-perl-perl make libb-debug-perl liblocale-codes-perl desktop-base + plymouth-themes torsocks rsyslog-mysql | rsyslog-pgsql rsyslog-mongodb rsyslog-doc rsyslog-openssl | rsyslog-gnutls rsyslog-gssapi rsyslog-relp +Recommended packages: + e2fsprogs-l10n +The following NEW packages will be installed: + bind9-dnsutils bind9-libs libdns-export1109 libfwupdplugin1 libisc-export1105 libmaxminddb0 libperl5.30 libplymouth5 libprocps8 libtss2-esys0 libuv1 pci.ids perl-modules-5.30 tpm-udev +The following packages will be upgraded: + acl adwaita-icon-theme apparmor apport at-spi2-core base-files base-passwd bash bash-completion bind9-host bsdutils btrfs-progs busybox-initramfs busybox-static byobu bzip2 + cloud-guest-utils cloud-init cloud-initramfs-copymods cloud-initramfs-dyn-netconf console-setup console-setup-linux cpio cron cryptsetup-bin cryptsetup-run curl dbus dbus-user-session + dconf-gsettings-backend dconf-service debianutils dirmngr distro-info-data dmidecode dmsetup dnsutils e2fsprogs ed ethtool fdisk file findutils fuse fwupd fwupd-signed gawk gcc-9-base + gdisk geoip-database gettext-base git git-man gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv grep groff-base gzip hostname htop info + initramfs-tools initramfs-tools-bin initramfs-tools-core install-info iproute2 iptables iputils-ping iputils-tracepath irqbalance isc-dhcp-client isc-dhcp-common iso-codes + keyboard-configuration klibc-utils kmod kpartx krb5-locales landscape-common language-selector-common less libacl1 libbz2-1.0 libcurl4 libdbus-1-3 libdconf1 libext2fs2 libfuse2 libfwupd2 + libgcc1 libgusb2 libip4tc2 libip6tc2 libklibc libkmod2 liblocale-gettext-perl liblz4-1 libmagic-mgc libmagic1 libncurses6 libncursesw6 libnftnl11 libpackagekit-glib2-18 libparted2 + libpci3 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtinfo6 libxmlb1 libxtables12 linux-base login logsave lsb-base lsb-release lshw lsof lz4 man-db manpages mawk mime-support + mount multipath-tools nano ncurses-base ncurses-bin ncurses-term netbase netcat-openbsd netplan.io openssh-client openssh-server openssh-sftp-server openssl overlayroot packagekit + packagekit-tools parted passwd pciutils perl perl-base plymouth plymouth-theme-ubuntu-text pollinate popularity-contest procps psmisc publicsuffix rsyslog screen sensible-utils sg3-utils + sg3-utils-udev sosreport whiptail + +The following packages will be REMOVED: + at-spi2-core gcc-9-base geoip-database libapt-pkg5.90 libbind9-161 libdns-export1104 libdns1104 libgeoip1 libiptc0 libirs161 libisc-export1100 libisc1100 libisccc161 libisccfg163 + liblwres161 libperl5.28 libplymouth4 libxtst6 perl-modules-5.28 python3-asn1crypto x11-common + +=> Still working + +Step 6: non x11/wayland/gtk/readline libs + +The following additional packages will be installed: + libcap2 libhogweed5 libnettle7 +Suggested packages: + lrzip colord cups-common rng-tools gnutls-bin krb5-doc krb5-user gstreamer1.0-tools libpam-doc pulseaudio librsvg2-bin libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal + libsasl2-modules-ldap libsasl2-modules-otp libsasl2-modules-sql libsmbios-doc +Recommended packages: + at-spi2-core libgpg-error-l10n update-motd +The following NEW packages will be installed: + libhogweed5 libnettle7 +The following packages will be upgraded: + libapparmor1 libappstream4 libarchive13 libasn1-8-heimdal libassuan0 libatk-bridge2.0-0 libatk1.0-0 libatk1.0-data libatspi2.0-0 libattr1 libaudit-common libaudit1 libavahi-client3 + libavahi-common-data libavahi-common3 libblkid1 libbrotli1 libcairo-gobject2 libcairo2 libcap2 libcolord2 libcom-err2 libcryptsetup12 libcups2 libcurl3-gnutls libdb5.3 libdebconfclient0 + libdevmapper1.02.1 libelf1 libepoxy0 liberror-perl libexpat1 libfdisk1 libflac8 libfreetype6 libfribidi0 libgcab-1.0-0 libgcrypt20 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin + libgdk-pixbuf2.0-common libglib2.0-data libgmp10 libgnutls30 libgpg-error0 libgpgme11 libgraphite2-3 libgssapi-krb5-2 libgssapi3-heimdal libgstreamer1.0-0 libharfbuzz0b + libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal libjson-c4 libjson-glib-1.0-0 libjson-glib-1.0-common libk5crypto3 libkeyutils1 libkrb5-26-heimdal + libkrb5-3 libkrb5support0 libldap-2.4-2 libldap-common liblzo2-2 libmount1 libmpdec2 libnghttp2-14 libp11-kit0 libpam-cap libpam-modules libpam-modules-bin libpam-runtime libpam0g + libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpcre2-8-0 libpipeline1 libpmem1 libpng16-16 libpopt0 libproxy1v5 libpulse0 libroken18-heimdal librsvg2-2 librsvg2-common librtmp1 + libsasl2-2 libsasl2-modules libsasl2-modules-db libselinux1 libsemanage-common libsemanage1 libsepol1 libsgutils2-2 libsmartcols1 libsmbios-c2 libsndfile1 libsoup-gnome2.4-1 libsoup2.4-1 + libsqlite3-0 libss2 libssh-4 libssl1.1 libstemmer0d libtasn1-6 libtiff5 libusb-1.0-0 libutempter0 libuuid1 libvte-2.91-0 libvte-2.91-common libwayland-client0 libwayland-cursor0 + libwayland-egl1 libwind0-heimdal libwrap0 libxcb-render0 libxcb-shm0 libxcb1 libxkbcommon0 libxml2 libyaml-0-2 libzstd1 +126 upgraded, 2 newly installed, 0 to remove and 19 not upgraded. + +=> Broken - so one of the above was it + +Next - break step 6 into sub-sections + +$ apt install libvte-2.91-0 +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following additional packages will be installed: + libgnutls30 libhogweed5 libnettle7 libp11-kit0 +Suggested packages: + gnutls-bin +The following NEW packages will be installed: + libhogweed5 libnettle7 +The following packages will be upgraded: + libgnutls30 libp11-kit0 libvte-2.91-0 +3 upgraded, 2 newly installed, 0 to remove and 141 not upgraded. +Need to get 1429 kB of archives. +After this operation, 736 kB of additional disk space will be used. + + +And the counter experiment made it work as well, taking a full focal install and then installing the libvte from eoan: + $ apt install libvte-2.91-0=0.58.2-1ubuntu2 + +Version difference of libvte-2.91-0 is 0.58.2-1ubuntu2 <-> 0.59.91-0ubuntu2 + +Debian isn't frozen yet and has 0.60.0-2, but that is broken as well. + +Building vte from git on the tags matching eoan and focal. + +LD_LIBRARY_PATH=/usr/local/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH ldd ./build/x86_64-softmmu/qemu-system-x86_64 | grep vte + libvte-2.91.so.0 => /usr/local/lib/x86_64-linux-gnu/libvte-2.91.so.0 (0x00007ff9b4908000) + +Eoans version 0.58.2 => works +root@e:~/vte# ll /usr/local/lib/x86_64-linux-gnu/ +lrwxrwxrwx 1 root root 16 Mar 24 13:09 libvte-2.91.so -> libvte-2.91.so.0* +lrwxrwxrwx 1 root root 23 Mar 24 13:09 libvte-2.91.so.0 -> libvte-2.91.so.0.5800.2* +-rwxr-xr-x 1 root root 645240 Mar 24 13:08 libvte-2.91.so.0.5800.2* + +Focals version 0.59.91 => Fails +lrwxrwxrwx 1 root root 16 Mar 24 13:13 libvte-2.91.so -> libvte-2.91.so.0* +lrwxrwxrwx 1 root root 23 Mar 24 13:13 libvte-2.91.so.0 -> libvte-2.91.so.0.5991.0* +-rwxr-xr-x 1 root root 695088 Mar 24 13:13 libvte-2.91.so.0.5991.0* + +So we should be able to bisect the offending change in vte ...?!? + +Bisect build +$ ninja -C _build uninstall; rm -rf _build; meson _build && ninja -C _build && ninja -C _build install; echo $?; ll /usr/local/lib/x86_64-linux-gnu/ + +Test +$ LD_LIBRARY_PATH=/usr/local/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH ./build/x86_64-softmmu/qemu-system-x86_64 -enable-kvm --drive media=cdrom,file=http://archive.ubuntu.com/ubuntu/dists/bionic/main/installer-amd64/current/images/netboot/mini.iso + +After a while of testing, build errors and a wrong bisect start I eventually got this: + +git bisect log +# bad: [a444c23eca931cadad321eaf06bc9c437ed9cee3] Version 0.59.91 +# good: [b7440da36396cbdbaca005adef3789d2a8852985] ring: Fix an incorrect assertion +git bisect start '0.59.91' '0.58.2' +# good: [def2f0ee9dfbed821b859c9d59f2bb66ae76dd27] Version 0.57.90 +git bisect good def2f0ee9dfbed821b859c9d59f2bb66ae76dd27 +# bad: [1bdfc0fa1adf1225152068040c8bde0804297805] widget: Move scrollable adjustments up to Widget +git bisect bad 1bdfc0fa1adf1225152068040c8bde0804297805 +# good: [7f6e48ce00eb0fd6992966a66df6464e85cfda84] ring: Tiny code cleanup: maintain GString integrity +git bisect good 7f6e48ce00eb0fd6992966a66df6464e85cfda84 +# good: [416c41be417a051b1d20499754aaa0a827e43b6b] test: Document the changes made to UTF-8-test.txt +git bisect good 416c41be417a051b1d20499754aaa0a827e43b6b +# good: [623f3c66de097eefef44001a4ff70600c11313f9] build: Add configure switch to disable a11y code +git bisect good 623f3c66de097eefef44001a4ff70600c11313f9 +# good: [cdccfe59db102628857086bd3b89de77b6de1d73] introspection: Fix signedness in vte_terminal_feed_child's annotation +git bisect good cdccfe59db102628857086bd3b89de77b6de1d73 +# skip: [9e4fbae2cabcd937ac4d1a984ba844d24b44b83f] lib: Use ICU for legacy charset support +git bisect skip 9e4fbae2cabcd937ac4d1a984ba844d24b44b83f +# skip: [7888602c3a980eee093313b2c0f949c756668070] lib: Rework child exit and EOF handling +git bisect skip 7888602c3a980eee093313b2c0f949c756668070 +# bad: [55e5d53676960feb5dc11400ecdc7c9d7c4ab13e] lib: Add missing files +git bisect bad 55e5d53676960feb5dc11400ecdc7c9d7c4ab13e +# good: [83cbe9998aa1c2babbf32eed0b5fa3909360a83b] widget: Deprecate vte_terminal_feed_child_binary +git bisect good 83cbe9998aa1c2babbf32eed0b5fa3909360a83b +# only skipped commits left to test +# possible first bad commit: [55e5d53676960feb5dc11400ecdc7c9d7c4ab13e] lib: Add missing files +# possible first bad commit: [7888602c3a980eee093313b2c0f949c756668070] lib: Rework child exit and EOF handling +# possible first bad commit: [9e4fbae2cabcd937ac4d1a984ba844d24b44b83f] lib: Use ICU for legacy charset support + +So one of those three that won't build individually should be our candidate, lets take a look. + +commit 55e5d53676960feb5dc11400ecdc7c9d7c4ab13e (refs/bisect/bad) +Author: Christian Persch <email address hidden> +Date: Sun Nov 17 22:15:38 2019 +0100 + + lib: Add missing files + +commit 7888602c3a980eee093313b2c0f949c756668070 (refs/bisect/skip-7888602c3a980eee093313b2c0f949c756668070) +Author: Christian Persch <email address hidden> +Date: Sun Nov 17 21:58:09 2019 +0100 + + lib: Rework child exit and EOF handling + + When the child process exits, we used to immediately unset the PTY, + which causes us to miss data written by the child but not yet read + by vte. + + Instead, only store the child exit status, and defer emitting the + 'child-exited' signal until after all the pending data has been read + and processed. + + Similarly, rework how EOF is processed. Instead of immediately + queuing the emission of the 'eof' signal, only take note of the EOF, + and process it after all pending data has processed. There also was + a bug in that we took the first occurence of G_IO_HUP in + Terminal::pty_io_read() to stop reading more data. Instead, only + take a pure G_IO_HUP without G_IO_IN as EOF, or if reading data + from the PTY returns the EIO error. + + This also fixes the bug where a(ny) partial character(s) not yet fully + decoded by the UTF-8 and ICU decoder would not show in the output; this + now correctly flushes the decoder, which inserts either a replacement + character (for the UTF-8 decoder) or the character(s) in the ICU decoder + internal state (most likely also a replacement character). + + https://bugzilla.gnome.org/show_bug.cgi?id=777686 + + +commit 9e4fbae2cabcd937ac4d1a984ba844d24b44b83f (refs/bisect/skip-9e4fbae2cabcd937ac4d1a984ba844d24b44b83f) +Author: Christian Persch <email address hidden> +Date: Sun Nov 17 21:58:09 2019 +0100 + + lib: Use ICU for legacy charset support + + Instead of converting the whole chunk of input from the input + charset to UTF-8 in one go, we need a decoder that consumes the + input one byte at a time. Since the iconv API is not particularly + suited to this (or, really, any) task, switch to using ICU for this. + + Add functions to get the list of supported legacy charsets, and + to check whether a particular string is a supported charset. + + Fixes https://gitlab.gnome.org/GNOME/vte/issues/40 + +commit 83cbe9998aa1c2babbf32eed0b5fa3909360a83b (HEAD, refs/bisect/good-83cbe9998aa1c2babbf32eed0b5fa3909360a83b) +Author: Christian Persch <email address hidden> +Date: Sun Nov 17 21:58:09 2019 +0100 + + widget: Deprecate vte_terminal_feed_child_binary + + +Lets turn the order around a bit: +83cbe9998aa1c2babbf32eed0b5fa3909360a83b (known good) + + cherry pick 55e5d53676960feb5dc11400ecdc7c9d7c4ab13e lib: Add missing files => Good + + cherry pick 9e4fbae2cabcd937ac4d1a984ba844d24b44b83f Use ICU for legacy => Bad + +83cbe9998aa1c2babbf32eed0b5fa3909360a83b (known good) + + cherry pick 55e5d53676960feb5dc11400ecdc7c9d7c4ab13e lib: Add missing files => Good + + cherry pick 7888602c3a980eee093313b2c0f949c756668070 Doesn't apply without 9e4fbae2 + +So it is this change that breaks things: +commit 9e4fbae2cabcd937ac4d1a984ba844d24b44b83f (refs/bisect/skip-9e4fbae2cabcd937ac4d1a984ba844d24b44b83f) +Author: Christian Persch <email address hidden> +Date: Sun Nov 17 21:58:09 2019 +0100 + + lib: Use ICU for legacy charset support + + +Last commit mentioning VTE is a while ago: +6415994 Thu Oct 11 17:30:39 2018 +0200 gtk: Don't vte_terminal_set_encoding() on new VTE versions + +I built head of qemu against head of vte - to check if I even need to look for existing fixes. +=> That still fails, so it is probably time for a bug report to get other people to think with us. + + + +FYI: Since this affects qemu (and VTE) git head I added an upstream-qemu task to the bug. + +Thanks for this investigation so far! + +We've opened an upstream VTE issue at https://gitlab.gnome.org/GNOME/vte/issues/222 . + +We'd appreciate if QEMU developers joined us there. Apparently QEMU uses the "commit" signal in a way that it was not meant to be used, and thus it's unclear what the best solution would be. + +Thank you Egmont for the bug for VTE in the gnome tracker! + +Graphics isn't something I'm usually at home - the related qemu code is mostly in ui/gtk.c per Maintainers file Gerd Hoffmann is the expert. I subscribed him to the bug here to raise visibility for him. + +For a bit of reverse-confirmation of the findings so far. +If I build qemu without VTE, like (configure) +GTK support yes (3.24.14) +VTE support no + +It works, due to the fallback implemented by [1][2]. +But obviously without all the VTE features, I'd prefer a more fine grained fix than disabling VTE :-) + +[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f8c223f69ac58488ea830597281b7ddd33037c4c +[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=bbbf9bfb9c27e389340cf50a11c22fa46c572150 + +I'm not really a UI guy, so I was checking what I might have lost by disabling VTE and found the very old [1]. That list of features really seems to make disabling VTE not an real option: + "It's also screen reader accessible, supports copy/paste, proper scrolling and + most of the other features you would expect from a terminal widget." + +After seeing that Cole authored the "drop PTY" [3] patch I have subscribed him here as well. + +I have tried to answer and ask a few questions on the VTE issue [2] to get it make progress, but it would really benefit getting the attention of Gerhard and Cole (or anyone else who feels the UI-power). + +[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=d861def367b516055dc4c46dc1305143ee653c84 +[2]: https://gitlab.gnome.org/GNOME/vte/issues/222 +[3]: https://git.qemu.org/?p=qemu.git;a=commit;h=d4370741402a97b8b6d0c38fef18ab38bf25ab22 + +same seems to happen on Fedora 32. + +I'm not sure how many of you are tracking the Vte bug [1] so here a summary of the latest insight from there. + +- Short term it seems that new behavior will be reverted in Vte 0.60.1. +- Long term the Vte devs might want to deprecate no-pty use cases or at least better understand why apps use it that way. + +For more details please read [1]. + +[1]: https://gitlab.gnome.org/GNOME/vte/issues/222 + +Thank you for investigating this. I would bisect QEMU, but wouldn't investigate its libraries. Consequently, I would never find the cause of this problem. + +For now, I am using -monitor telnet:127.0.0.1:55555,server,nowait to have access to the monitor on QEMU guests. + +From IRC: +[16:10] <seb128> cpaelzer, @vte, we should get 0.60.1 for focal, 0.59.91 is a rc1 for 0.60, we are lacking behind merging the stable version from Debian but it's on our backlog (kenvandine was look at that one), the .1 is part of GNOME 3.36.1 which we plan to get before release (I would understand if you would like to backport a patch to help testing rather than waiting though) + +From VTE Bug: +The standard Ubuntu freeze doesn't apply to GNOME packages. Usually Ubuntu aims to ship latest GNOME x.1. VTE is part of GNOME, VTE 0.60.0 is part of GNOME 3.36.0, VTE 0.60.1 belongs to GNOME 3.36.1 etc. Accordingly, 0.60.0 -> 0.60.1 contains important bugfixes only, no new features. In this particular case, 0.60.1 will bring a trivial shell script fix (quite important for non-VTE users), and hopefully this one. It would be outright ridiculous for an LTS distro to ship an unstable VTE. So, the only reasonable thing for Ubuntu 20.04 is to ship VTE 0.60.1. Anyway, this is not the right place to discuss it. + +But gladly there now is a commit with a fix: +https://gitlab.gnome.org/GNOME/vte/-/commit/277ee003066b3993cf6d55a05606009caac69015 + +I agree that we need this for 20.04, and therefore will set this up in prio and assign it to the Desktop team. + +Subscribed and Assigned to Ubuntu Desktop to get to 0.60.1 before Focal releases. +I'd be happy about an update here that this surely is on your todo list. + +As Vte-upstream long term would want to get rid of this implementation style Christian Persch provided a qemu patch [1]. That is too much UI for me to really have an in-depth opinion, but I can say that it builds and input works fine with it. + +I suggested on [2] to send it to qemu-devel, but in case that doesn't happen it might be great if Gerd Hoffmann and Cole Robinson could take a look at it. + +[1]: https://gitlab.gnome.org/GNOME/vte/uploads/1e8ccb6aaf2e8fcef91dd67d23f47fae/qemu.patch +[2]: https://gitlab.gnome.org/GNOME/vte/issues/222 + +THe update should be part of GNOME 3.36.1 which is due this weekend + +This bug was fixed in the package vte2.91 - 0.60.0-2ubuntu2 + +--------------- +vte2.91 (0.60.0-2ubuntu2) focal; urgency=medium + + * debian/libvte-2.91-0.install + - Dropped files duplicated in libvte-2.91-common + * debian/control.in + - Add appropriate Breaks/Replaces for moved files. + + -- Ken VanDine <email address hidden> Fri, 27 Mar 2020 16:07:28 -0400 + +Thanks Ken! +I verified it and the new version indeed fixes the issue in focal. + +Looking at the comments, it seems to me that this was an issue in VTE that got fixed. Is there still anything left to do for upstream QEMU here? + +@Thomas - there is a leftover task here and I've filed [1] for it in the new tracker. +What is the right state to move this bug here into now? + +[1]: https://gitlab.com/qemu-project/qemu/-/issues/137 + +Thanks for opening the new ticket. Let's close this one here as WontFix - since we will only look at the new issue now instead. + diff --git a/results/classifier/zero-shot/108/permissions/1871250 b/results/classifier/zero-shot/108/permissions/1871250 new file mode 100644 index 000000000..c3a4902f1 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1871250 @@ -0,0 +1,101 @@ +semantic: 0.973 +permissions: 0.970 +debug: 0.969 +other: 0.960 +graphic: 0.954 +boot: 0.937 +performance: 0.936 +device: 0.935 +files: 0.930 +PID: 0.923 +vnc: 0.921 +network: 0.919 +socket: 0.918 +KVM: 0.789 + +Failed to create HAX VM + +Hi, + +I'm running the latest (master) of QEMU, though the version doesn't seem to matter - I also checked back to v4.2.0, exactly the same issue. And this isn't about the VM (guest), if I even just try to run, + +> "c:\Program Files\qemu\qemu-system-x86_64.exe" -accel hax + +Basically, just get a window to open, with acceleration enabled ... I get, +Open the vm device error:/dev/hax_vm/vm00, ec:3 +Failed to open vm 0 +Failed to create HAX VM +No accelerator found. + +But I checked - I have installed Intel HAXM, and verified it's running, +> sc query intelhaxm +SERVICE_NAME: intelhaxm + TYPE : 1 KERNEL_DRIVER + STATE : 4 RUNNING + (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) + WIN32_EXIT_CODE : 0 (0x0) + SERVICE_EXIT_CODE : 0 (0x0) + CHECKPOINT : 0x0 + WAIT_HINT : 0x0 + +Just remove the accelerator (-accel hax), and I get a window - so this is related to QEMU being able to contact / use the accelerator. + +Help!?!? + +Thanks! + +I am also seeing this. It was working as of commit d649689a8ecb2e276cc20d3af6d416e3c299cb17 so something must have changed in the past month. I can't see anything HAX-related though. + +I've bisected this back to b319df553707a3d44c7d027a5d5562f672a768a9, which is odd because it's a merge commit about PowerPC. Perhaps I lost my way somewhere or perhaps there's something hiding in here that breaks it. I wasn't able to revert it in a hurry. I'll have a closer look later. + +Hi, + +I received an email yesterday (content below) - and it worked! Not sure why it's not here also (and why only via email), but let me share, hope this helps! And BTW, when I say worked ... I applied this to the latest master (locally), addreses the issue. So add this in to the master (formally)? + +Thanks! + +================================ + +at the moment you need this patch at +https://lists.nongnu.org/archive/html/qemu-devel/2020-03/msg06831.html + +But I can't see why v4.2.0 doesn't work on your system. The bug was introduced later. + +> Basically, just get a window to open, with acceleration enabled ... I +> get, Open the vm device error:/dev/hax_vm/vm00, ec:3 Failed to open vm +> 0 Failed to create HAX VM No accelerator found. +> + +ec:3 is ERROR_PATH_NOT_FOUND + + +Thanks, that does indeed work for me too! Sorry for the confusion there, apparently merge commits play havoc with git bisect. I also thought it was strange that 4.2.0 didn't work for you as my last working commit came after that. + +No worries! And my apologies for some confusion too - I was trying v4.2.0 from the official (recent) downloads, and I think something wasn't quite right ... so I went back, manually built a clean v4.2.0. It worked, as you suspected. + +Good news is - seems we know the fix. Fast, and quite minor ... doesn't get better than that. LOL! How to get this in the formal / official code? + +Thanks! + +It looks like it's been queued for merging already. + +Awesome - thanks! I admit, not sure how you see the queue, but if you say it's there, I trust you :-). + +Any sort of LE? + +Thanks again. + +Just going by https://lists.nongnu.org/archive/html/qemu-devel/2020-03/msg06882.html. + +That makes sense, thanks! + +Do we leave this open until that "hits" (gets pulled in), or close it out? I'm fine with either, whatever you prefer. + +Appreciate all the help! + +Wait, just in case, I guess. I'm just a lowly user here. + +NP, will do. Thanks again for the help! + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9f5a0664187e9411c5c + diff --git a/results/classifier/zero-shot/108/permissions/1871798 b/results/classifier/zero-shot/108/permissions/1871798 new file mode 100644 index 000000000..a3cfd9104 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1871798 @@ -0,0 +1,192 @@ +permissions: 0.944 +graphic: 0.935 +other: 0.933 +debug: 0.932 +semantic: 0.930 +PID: 0.929 +boot: 0.928 +vnc: 0.927 +performance: 0.921 +socket: 0.911 +KVM: 0.910 +network: 0.902 +device: 0.896 +files: 0.888 + +Fails to start on Windows host without explicit --disable-pie + +Since commit d2cd29e30736afd4a1e8cac3cf4da360bbc65978, which removed the x86 conditional around PIE, QEMU completely fails to start on a Windows host unless --disable-pie is explicitly given at build time. Even just requesting the help text doesn't work. To make testing easier, this can be replicated with Wine. + +What compiler and toolchain are you using? + +I'm using GCC 9.3.0 with mingw-w64 7.0.0, all built with Gentoo Linux's crossdev. + +I didn't know whether PIE is generally supported on Windows or not. It was possible that Gentoo is just inadvertently disabling support for it. It did stem from a bug report though and reading around, others elsewhere have reported that PIE on Windows doesn't work. + +It seems on some compilers the test can pass but still give you +broken binaries. + +[AJB untested - please could windows users test] + +Fixes: d2cd29e30736 +Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +Cc: Bug 1871798 <email address hidden> +Cc: James Le Cuirot <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + configure | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/configure b/configure +index a207cce82bc..e9c5f630c14 100755 +--- a/configure ++++ b/configure +@@ -807,6 +807,7 @@ MINGW32*) + audio_drv_list="" + fi + supported_os="yes" ++ pie="no" + ;; + GNU/kFreeBSD) + bsd="yes" +-- +2.20.1 + + + +On Thu, Apr 9, 2020 at 11:18 PM Alex Bennée <email address hidden> wrote: + +> It seems on some compilers the test can pass but still give you +> broken binaries. +> +> [AJB untested - please could windows users test] +> +> Fixes: d2cd29e30736 +> Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +> Cc: Bug 1871798 <email address hidden> +> Cc: James Le Cuirot <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> configure | 1 + +> 1 file changed, 1 insertion(+) +> +> diff --git a/configure b/configure +> index a207cce82bc..e9c5f630c14 100755 +> --- a/configure +> +++ b/configure +> @@ -807,6 +807,7 @@ MINGW32*) +> audio_drv_list="" +> fi +> supported_os="yes" +> + pie="no" +> ;; +> GNU/kFreeBSD) +> bsd="yes" +> -- +> 2.20.1 +> + +Solves my issue! So, + +Tested-by: Howard Spoelstra <email address hidden> + + +Tested and working. Thank you! + +On 4/9/20 11:15 PM, Alex Bennée wrote: +> It seems on some compilers the test can pass but still give you +> broken binaries. +> +> [AJB untested - please could windows users test] +> +> Fixes: d2cd29e30736 +> Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +> Cc: Bug 1871798 <email address hidden> +> Cc: James Le Cuirot <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> configure | 1 + +> 1 file changed, 1 insertion(+) +> +> diff --git a/configure b/configure +> index a207cce82bc..e9c5f630c14 100755 +> --- a/configure +> +++ b/configure +> @@ -807,6 +807,7 @@ MINGW32*) +> audio_drv_list="" +> fi +> supported_os="yes" +> + pie="no" +> ;; +> GNU/kFreeBSD) +> bsd="yes" +> + +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> + + + +It seems on some compilers the test can pass but still give you +broken binaries. + +Fixes: d2cd29e30736 +Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +Cc: Bug 1871798 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +Tested-by: Howard Spoelstra <email address hidden> +Tested-by: James Le Cuirot <email address hidden> +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +--- + configure | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/configure b/configure +index 25f7d915720..23b5e93752b 100755 +--- a/configure ++++ b/configure +@@ -807,6 +807,7 @@ MINGW32*) + audio_drv_list="" + fi + supported_os="yes" ++ pie="no" + ;; + GNU/kFreeBSD) + bsd="yes" +-- +2.20.1 + + + +It seems on some compilers the test can pass but still give you +broken binaries. + +Fixes: d2cd29e30736 +Fixes: https://bugs.launchpad.net/qemu/+bug/1871798 +Cc: Bug 1871798 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +Tested-by: Howard Spoelstra <email address hidden> +Tested-by: James Le Cuirot <email address hidden> +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +Message-Id: <email address hidden> + +diff --git a/configure b/configure +index 25f7d915720..23b5e93752b 100755 +--- a/configure ++++ b/configure +@@ -807,6 +807,7 @@ MINGW32*) + audio_drv_list="" + fi + supported_os="yes" ++ pie="no" + ;; + GNU/kFreeBSD) + bsd="yes" +-- +2.20.1 + + + +Fixed in commit 469a788cdd3c618ef1b8a23a339510082b3eeea7. + diff --git a/results/classifier/zero-shot/108/permissions/1871842 b/results/classifier/zero-shot/108/permissions/1871842 new file mode 100644 index 000000000..8faeb426f --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1871842 @@ -0,0 +1,1345 @@ +permissions: 0.971 +debug: 0.968 +semantic: 0.967 +other: 0.965 +device: 0.961 +graphic: 0.961 +performance: 0.961 +boot: 0.959 +network: 0.958 +PID: 0.950 +socket: 0.938 +vnc: 0.923 +files: 0.914 +KVM: 0.874 + +AMD CPUID leaf 0x8000'0008 reported number of cores inconsistent with ACPI.MADT + +Setup: +CPU: AMD EPYC-v2 or host's EPYC cpu +Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +qemu version: self build +git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' + +Cmdline: +qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 + +Issue: +We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] + +The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +The lower four bits of ECX are the [NC] field and all set. + +When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +Note, ECX is zero. Indicating that this is no SMP capabale CPU. + +I'm debugging it using my local machine and the QEMU provided EPYC-v2 CPU model and it is reproducible there as well and reports: EAX: 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 + +I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. + +The following table shows my findings with the -smp option: +Option | Qemu guest observed ECX value +-smp 4 | 0x0 +-smp 4,cores=4 | 0x3 +-smp 4,cores=2,thread=2 | 0x3 +-smp 4,cores=4,threads=2 | QEMU boot error: topology false. + +Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? + +Querying 0x8000'0008 on the physical processor results in different reports than quering QEMU's model as does it with -enable-kvm -cpu host. + +Furthermore, the ACPI.MADT shows 4 local APICs to be present while the CPU leave reports a single core processor. + +This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the wrong number. + + +Please let me know, if you need more information from my side. + + +[0] https://github.com/kernkonzept/fiasco/blob/522ccc5f29ab120213cf02d71328e2b879cbbd19/src/kern/ia32/kernel_thread-ia32.cpp#L109 +[1] https://github.com/kernkonzept/fiasco/blob/522ccc5f29ab120213cf02d71328e2b879cbbd19/src/kern/ia32/cpu-ia32.cpp#L1120 +[2] https://github.com/qemu/qemu/blob/f2a8261110c32c4dccd84e774d8dd7a0524e00fb/target/i386/cpu.c#L5835 +[3] https://www.amd.com/system/files/TechDocs/24594.pdf + +On Thu, 09 Apr 2020 12:58:11 -0000 +Philipp Eppelt <email address hidden> wrote: + +> Public bug reported: +> +> Setup: +> CPU: AMD EPYC-v2 or host's EPYC cpu +> Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +> qemu version: self build +> git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +> config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' +> +> Cmdline: +> qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 +> +> Issue: +> We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +> In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] +> +> The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +> The lower four bits of ECX are the [NC] field and all set. +> +> When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +> Note, ECX is zero. Indicating that this is no SMP capabale CPU. +> +> I'm debugging it using my local machine and the QEMU provided EPYC-v2 +> CPU model and it is reproducible there as well and reports: EAX: +> 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 +> +> I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +> I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. +> +> The following table shows my findings with the -smp option: +> Option | Qemu guest observed ECX value +> -smp 4 | 0x0 +> -smp 4,cores=4 | 0x3 +> -smp 4,cores=2,thread=2 | 0x3 +> -smp 4,cores=4,threads=2 | QEMU boot error: topology false. +> +> Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +> Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? +I'd say X corresponds to number of logical CPUs. +Depending on presence of other options these are distributed among them in magical manner +(see pc_smp_parse() for starters) + +> Querying 0x8000'0008 on the physical processor results in different +> reports than quering QEMU's model as does it with -enable-kvm -cpu host. +> +> Furthermore, the ACPI.MADT shows 4 local APICs to be present while the +> CPU leave reports a single core processor. +it matches -smp X as it should be. + +> +> This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the +> wrong number. +CCed author of recent epyc patches who might know how AMD should work better than me. + +> +> Please let me know, if you need more information from my side. +> +> +> [0] https://github.com/kernkonzept/fiasco/blob/522ccc5f29ab120213cf02d71328e2b879cbbd19/src/kern/ia32/kernel_thread-ia32.cpp#L109 +> [1] https://github.com/kernkonzept/fiasco/blob/522ccc5f29ab120213cf02d71328e2b879cbbd19/src/kern/ia32/cpu-ia32.cpp#L1120 +> [2] https://github.com/qemu/qemu/blob/f2a8261110c32c4dccd84e774d8dd7a0524e00fb/target/i386/cpu.c#L5835 +> [3] https://www.amd.com/system/files/TechDocs/24594.pdf +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + + + +On 4/9/20 9:00 AM, Igor Mammedov wrote: +> On Thu, 09 Apr 2020 12:58:11 -0000 +> Philipp Eppelt <email address hidden> wrote: +> +>> Public bug reported: +>> +>> Setup: +>> CPU: AMD EPYC-v2 or host's EPYC cpu +>> Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +>> qemu version: self build +>> git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +>> config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' +>> +>> Cmdline: +>> qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 +>> +>> Issue: +>> We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +>> In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] +>> +>> The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +>> The lower four bits of ECX are the [NC] field and all set. +>> +>> When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +>> Note, ECX is zero. Indicating that this is no SMP capabale CPU. +>> +>> I'm debugging it using my local machine and the QEMU provided EPYC-v2 +>> CPU model and it is reproducible there as well and reports: EAX: +>> 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 +>> +>> I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +>> I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. +>> +>> The following table shows my findings with the -smp option: +>> Option | Qemu guest observed ECX value +>> -smp 4 | 0x0 +>> -smp 4,cores=4 | 0x3 +>> -smp 4,cores=2,thread=2 | 0x3 +>> -smp 4,cores=4,threads=2 | QEMU boot error: topology false. +>> +>> Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +>> Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? +> I'd say X corresponds to number of logical CPUs. +> Depending on presence of other options these are distributed among them in magical manner +> (see pc_smp_parse() for starters) +> +>> Querying 0x8000'0008 on the physical processor results in different +>> reports than quering QEMU's model as does it with -enable-kvm -cpu host. +>> +>> Furthermore, the ACPI.MADT shows 4 local APICs to be present while the +>> CPU leave reports a single core processor. +> it matches -smp X as it should be. +> +>> +>> This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the +>> wrong number. +> CCed author of recent epyc patches who might know how AMD should work better than me. + +Hmm.. Interesting.. Not sure why this did not come up during my testing. +Probably this cpuid information is not widely used. + +Yes. I am looking at it right now. I see that EPYC model is reporting +wrong. Not sure why -cpu host is reporting wrong. I thought -cpu host gets +the information directly from the host. Will investigate. + + +Philipp, + Can you please check if this patch works for you. + +diff --git a/target/i386/cpu.c b/target/i386/cpu.c +index 90ffc5f..e467fee 100644 +--- a/target/i386/cpu.c ++++ b/target/i386/cpu.c +@@ -5831,10 +5831,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t +index, uint32_t count, + } + *ebx = env->features[FEAT_8000_0008_EBX]; + *ecx = 0; +- *edx = 0; + if (cs->nr_cores * cs->nr_threads > 1) { +- *ecx |= (cs->nr_cores * cs->nr_threads) - 1; ++ unsigned long max_apicids, bits_required; ++ ++ max_apicids = (cs->nr_cores * cs->nr_threads) - 1; ++ if (max_apicids) { ++ /* Find out the number of bits to represent all the +apicids */ ++ bits_required = find_last_bit(&max_apicids, +BITS_PER_BYTE) + 1; ++ *ecx |= bits_required << 12 | max_apicids; ++ } + } ++ *edx = 0; + break; + case 0x8000000A: + if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { + + + +On 4/9/20 9:00 AM, Igor Mammedov wrote: +> On Thu, 09 Apr 2020 12:58:11 -0000 +> Philipp Eppelt <email address hidden> wrote: +> +>> Public bug reported: +>> +>> Setup: +>> CPU: AMD EPYC-v2 or host's EPYC cpu +>> Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +>> qemu version: self build +>> git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +>> config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' +>> +>> Cmdline: +>> qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 +>> +>> Issue: +>> We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +>> In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] +>> +>> The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +>> The lower four bits of ECX are the [NC] field and all set. +>> +>> When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +>> Note, ECX is zero. Indicating that this is no SMP capabale CPU. +>> +>> I'm debugging it using my local machine and the QEMU provided EPYC-v2 +>> CPU model and it is reproducible there as well and reports: EAX: +>> 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 +>> +>> I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +>> I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. +>> +>> The following table shows my findings with the -smp option: +>> Option | Qemu guest observed ECX value +>> -smp 4 | 0x0 +>> -smp 4,cores=4 | 0x3 +>> -smp 4,cores=2,thread=2 | 0x3 +>> -smp 4,cores=4,threads=2 | QEMU boot error: topology false. +>> +>> Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +>> Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? +> I'd say X corresponds to number of logical CPUs. +> Depending on presence of other options these are distributed among them in magical manner +> (see pc_smp_parse() for starters) +> +>> Querying 0x8000'0008 on the physical processor results in different +>> reports than quering QEMU's model as does it with -enable-kvm -cpu host. +>> +>> Furthermore, the ACPI.MADT shows 4 local APICs to be present while the +>> CPU leave reports a single core processor. +> it matches -smp X as it should be. +> +>> +>> This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the +>> wrong number. +> CCed author of recent epyc patches who might know how AMD should work better than me. +> +>> +>> Please let me know, if you need more information from my side. +>> +>> +>> [0] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkernkonzept%2Ffiasco%2Fblob%2F522ccc5f29ab120213cf02d71328e2b879cbbd19%2Fsrc%2Fkern%2Fia32%2Fkernel_thread-ia32.cpp%23L109&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=hcFJzLAVQoIh5IN9CP%2F9cUQNOZoBnpRA6FliJur1wzQ%3D&reserved=0 +>> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkernkonzept%2Ffiasco%2Fblob%2F522ccc5f29ab120213cf02d71328e2b879cbbd19%2Fsrc%2Fkern%2Fia32%2Fcpu-ia32.cpp%23L1120&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=ANJIbYKbwfq2bDelH%2FRLKnDPIUZc1BwxHspmgxLU7gs%3D&reserved=0 +>> [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fqemu%2Fqemu%2Fblob%2Ff2a8261110c32c4dccd84e774d8dd7a0524e00fb%2Ftarget%2Fi386%2Fcpu.c%23L5835&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=oj3mv9e5YOzUsfUjXK44gC8LybyWgMKo8JBIrRR%2BmDA%3D&reserved=0 +>> [3] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24594.pdf&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=7Yr3J9ihlqSqXCXKN5JJNTByO3NGI%2BGMz2EqBF2Y4hw%3D&reserved=0 +>> +>> ** Affects: qemu +>> Importance: Undecided +>> Status: New +>> +> + + +Hi, + +thanks for looking into this so quickly. + +With this patch applied ontop of git commit +f3bac27cc1e303e1860cc55b9b6889ba39dee587 I still have the issue and it +reports the same numbers. I like the new usage of the ApicIdSize field. + + +I looked into the mentioned pc_smp_parse() and had it print the topology +for -smp 4: + +qemu-system-x86_64: warning: cpu topology: sockets (4) , dies (1) , +cores (1) , threads (1) , maxcpus (4), cpus (4) + +and with -smp 4,cores=4: + +qemu-system-x86_64: warning: cpu topology: sockets (1) , dies (1) , +cores (4) , threads (1) , maxcpus (4), cpus (4) + +As far as I understand it, these are the numbers the cpuid:8000'0008 +code relies on: +`cs->nr_cores`, `cs->nr_threads` with `cs` being of type CPUState. + +So I think the issue is rooted with the preferring sockets over cores +when the -smp cmdline option is parsed, as stated in hw/i386/pc.c:729. + +I guess this is the same code for Intel and AMD CPUs alike and this +issue just didn't surface for us on Intel CPUs, as they don't have this +CPUID leaf and we don't look at the topology. + +This seems to boil down to a more careful use of the -smp option on my end. + +Thanks again for looking into this. + +Cheers, +Philipp + + + +On 4/10/20 2:12 AM, Babu Moger wrote: +> Philipp, +> Can you please check if this patch works for you. +> +> diff --git a/target/i386/cpu.c b/target/i386/cpu.c +> index 90ffc5f..e467fee 100644 +> --- a/target/i386/cpu.c +> +++ b/target/i386/cpu.c +> @@ -5831,10 +5831,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t +> index, uint32_t count, +> } +> *ebx = env->features[FEAT_8000_0008_EBX]; +> *ecx = 0; +> - *edx = 0; +> if (cs->nr_cores * cs->nr_threads > 1) { +> - *ecx |= (cs->nr_cores * cs->nr_threads) - 1; +> + unsigned long max_apicids, bits_required; +> + +> + max_apicids = (cs->nr_cores * cs->nr_threads) - 1; +> + if (max_apicids) { +> + /* Find out the number of bits to represent all the +> apicids */ +> + bits_required = find_last_bit(&max_apicids, +> BITS_PER_BYTE) + 1; +> + *ecx |= bits_required << 12 | max_apicids; +> + } +> } +> + *edx = 0; +> break; +> case 0x8000000A: +> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { +> +> +> On 4/9/20 9:00 AM, Igor Mammedov wrote: +>> On Thu, 09 Apr 2020 12:58:11 -0000 +>> Philipp Eppelt <email address hidden> wrote: +>> +>>> Public bug reported: +>>> +>>> Setup: +>>> CPU: AMD EPYC-v2 or host's EPYC cpu +>>> Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +>>> qemu version: self build +>>> git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +>>> config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' +>>> +>>> Cmdline: +>>> qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 +>>> +>>> Issue: +>>> We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +>>> In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] +>>> +>>> The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +>>> The lower four bits of ECX are the [NC] field and all set. +>>> +>>> When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +>>> Note, ECX is zero. Indicating that this is no SMP capabale CPU. +>>> +>>> I'm debugging it using my local machine and the QEMU provided EPYC-v2 +>>> CPU model and it is reproducible there as well and reports: EAX: +>>> 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 +>>> +>>> I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +>>> I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. +>>> +>>> The following table shows my findings with the -smp option: +>>> Option | Qemu guest observed ECX value +>>> -smp 4 | 0x0 +>>> -smp 4,cores=4 | 0x3 +>>> -smp 4,cores=2,thread=2 | 0x3 +>>> -smp 4,cores=4,threads=2 | QEMU boot error: topology false. +>>> +>>> Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +>>> Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? +>> I'd say X corresponds to number of logical CPUs. +>> Depending on presence of other options these are distributed among them in magical manner +>> (see pc_smp_parse() for starters) +>> +>>> Querying 0x8000'0008 on the physical processor results in different +>>> reports than quering QEMU's model as does it with -enable-kvm -cpu host. +>>> +>>> Furthermore, the ACPI.MADT shows 4 local APICs to be present while the +>>> CPU leave reports a single core processor. +>> it matches -smp X as it should be. +>> +>>> +>>> This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the +>>> wrong number. +>> CCed author of recent epyc patches who might know how AMD should work better than me. +>> +>>> +>>> Please let me know, if you need more information from my side. +>>> +>>> +>>> [0] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkernkonzept%2Ffiasco%2Fblob%2F522ccc5f29ab120213cf02d71328e2b879cbbd19%2Fsrc%2Fkern%2Fia32%2Fkernel_thread-ia32.cpp%23L109&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=hcFJzLAVQoIh5IN9CP%2F9cUQNOZoBnpRA6FliJur1wzQ%3D&reserved=0 +>>> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkernkonzept%2Ffiasco%2Fblob%2F522ccc5f29ab120213cf02d71328e2b879cbbd19%2Fsrc%2Fkern%2Fia32%2Fcpu-ia32.cpp%23L1120&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=ANJIbYKbwfq2bDelH%2FRLKnDPIUZc1BwxHspmgxLU7gs%3D&reserved=0 +>>> [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fqemu%2Fqemu%2Fblob%2Ff2a8261110c32c4dccd84e774d8dd7a0524e00fb%2Ftarget%2Fi386%2Fcpu.c%23L5835&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=oj3mv9e5YOzUsfUjXK44gC8LybyWgMKo8JBIrRR%2BmDA%3D&reserved=0 +>>> [3] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24594.pdf&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=7Yr3J9ihlqSqXCXKN5JJNTByO3NGI%2BGMz2EqBF2Y4hw%3D&reserved=0 +>>> +>>> ** Affects: qemu +>>> Importance: Undecided +>>> Status: New +>>> +>> +> + +-- +<email address hidden> - Tel. 0351-41 883 221 +http://www.kernkonzept.com + +Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. +Geschäftsführer: Dr.-Ing. Michael Hohmuth + + +Hi, + +I have to clarify some things mentioned in my last post: + +I only tested the change with an emulated EPYC-v2 CPU, I cannot test on +a physical EPYC CPU at the moment. However, I doubt that the results +will be different regarding the 0x8000_0008.ECX result. + +The topology information printed is from the EPYC-v2 CPU model. I try to +get access to the machine and have a look if -cpu host affects this +topology. + +So there is still the open question for the -enable-kvm -cpu host -smp 4 +case. Shouldn't in this case the topology of the host CPU be reported? + + +In all emulated-CPU cases it's on the user to define the topology or to +live with the generated one (although I think preferring multi-socket +systems is outdated, but it's likely just the case in my 'world'). + + +Cheers, +Philipp + + +On 4/14/20 10:24 AM, Philipp Eppelt wrote: +> Hi, +> +> thanks for looking into this so quickly. +> +> With this patch applied ontop of git commit +> f3bac27cc1e303e1860cc55b9b6889ba39dee587 I still have the issue and it +> reports the same numbers. I like the new usage of the ApicIdSize field. +> +> +> I looked into the mentioned pc_smp_parse() and had it print the topology +> for -smp 4: +> +> qemu-system-x86_64: warning: cpu topology: sockets (4) , dies (1) , +> cores (1) , threads (1) , maxcpus (4), cpus (4) +> +> and with -smp 4,cores=4: +> +> qemu-system-x86_64: warning: cpu topology: sockets (1) , dies (1) , +> cores (4) , threads (1) , maxcpus (4), cpus (4) +> +> As far as I understand it, these are the numbers the cpuid:8000'0008 +> code relies on: +> `cs->nr_cores`, `cs->nr_threads` with `cs` being of type CPUState. +> +> So I think the issue is rooted with the preferring sockets over cores +> when the -smp cmdline option is parsed, as stated in hw/i386/pc.c:729. +> +> I guess this is the same code for Intel and AMD CPUs alike and this +> issue just didn't surface for us on Intel CPUs, as they don't have this +> CPUID leaf and we don't look at the topology. +> +> This seems to boil down to a more careful use of the -smp option on my end. +> +> Thanks again for looking into this. +> +> Cheers, +> Philipp +> +> +> +> On 4/10/20 2:12 AM, Babu Moger wrote: +>> Philipp, +>> Can you please check if this patch works for you. +>> +>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c +>> index 90ffc5f..e467fee 100644 +>> --- a/target/i386/cpu.c +>> +++ b/target/i386/cpu.c +>> @@ -5831,10 +5831,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t +>> index, uint32_t count, +>> } +>> *ebx = env->features[FEAT_8000_0008_EBX]; +>> *ecx = 0; +>> - *edx = 0; +>> if (cs->nr_cores * cs->nr_threads > 1) { +>> - *ecx |= (cs->nr_cores * cs->nr_threads) - 1; +>> + unsigned long max_apicids, bits_required; +>> + +>> + max_apicids = (cs->nr_cores * cs->nr_threads) - 1; +>> + if (max_apicids) { +>> + /* Find out the number of bits to represent all the +>> apicids */ +>> + bits_required = find_last_bit(&max_apicids, +>> BITS_PER_BYTE) + 1; +>> + *ecx |= bits_required << 12 | max_apicids; +>> + } +>> } +>> + *edx = 0; +>> break; +>> case 0x8000000A: +>> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { +>> +>> +>> On 4/9/20 9:00 AM, Igor Mammedov wrote: +>>> On Thu, 09 Apr 2020 12:58:11 -0000 +>>> Philipp Eppelt <email address hidden> wrote: +>>> +>>>> Public bug reported: +>>>> +>>>> Setup: +>>>> CPU: AMD EPYC-v2 or host's EPYC cpu +>>>> Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +>>>> qemu version: self build +>>>> git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +>>>> config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' +>>>> +>>>> Cmdline: +>>>> qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 +>>>> +>>>> Issue: +>>>> We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +>>>> In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] +>>>> +>>>> The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +>>>> The lower four bits of ECX are the [NC] field and all set. +>>>> +>>>> When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +>>>> Note, ECX is zero. Indicating that this is no SMP capabale CPU. +>>>> +>>>> I'm debugging it using my local machine and the QEMU provided EPYC-v2 +>>>> CPU model and it is reproducible there as well and reports: EAX: +>>>> 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 +>>>> +>>>> I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +>>>> I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. +>>>> +>>>> The following table shows my findings with the -smp option: +>>>> Option | Qemu guest observed ECX value +>>>> -smp 4 | 0x0 +>>>> -smp 4,cores=4 | 0x3 +>>>> -smp 4,cores=2,thread=2 | 0x3 +>>>> -smp 4,cores=4,threads=2 | QEMU boot error: topology false. +>>>> +>>>> Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +>>>> Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? +>>> I'd say X corresponds to number of logical CPUs. +>>> Depending on presence of other options these are distributed among them in magical manner +>>> (see pc_smp_parse() for starters) +>>> +>>>> Querying 0x8000'0008 on the physical processor results in different +>>>> reports than quering QEMU's model as does it with -enable-kvm -cpu host. +>>>> +>>>> Furthermore, the ACPI.MADT shows 4 local APICs to be present while the +>>>> CPU leave reports a single core processor. +>>> it matches -smp X as it should be. +>>> +>>>> +>>>> This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the +>>>> wrong number. +>>> CCed author of recent epyc patches who might know how AMD should work better than me. +>>> +>>>> +>>>> Please let me know, if you need more information from my side. +>>>> +>>>> +>>>> [0] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkernkonzept%2Ffiasco%2Fblob%2F522ccc5f29ab120213cf02d71328e2b879cbbd19%2Fsrc%2Fkern%2Fia32%2Fkernel_thread-ia32.cpp%23L109&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=hcFJzLAVQoIh5IN9CP%2F9cUQNOZoBnpRA6FliJur1wzQ%3D&reserved=0 +>>>> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkernkonzept%2Ffiasco%2Fblob%2F522ccc5f29ab120213cf02d71328e2b879cbbd19%2Fsrc%2Fkern%2Fia32%2Fcpu-ia32.cpp%23L1120&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=ANJIbYKbwfq2bDelH%2FRLKnDPIUZc1BwxHspmgxLU7gs%3D&reserved=0 +>>>> [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fqemu%2Fqemu%2Fblob%2Ff2a8261110c32c4dccd84e774d8dd7a0524e00fb%2Ftarget%2Fi386%2Fcpu.c%23L5835&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=oj3mv9e5YOzUsfUjXK44gC8LybyWgMKo8JBIrRR%2BmDA%3D&reserved=0 +>>>> [3] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24594.pdf&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=7Yr3J9ihlqSqXCXKN5JJNTByO3NGI%2BGMz2EqBF2Y4hw%3D&reserved=0 +>>>> +>>>> ** Affects: qemu +>>>> Importance: Undecided +>>>> Status: New +>>>> +>>> +>> +> + +-- +<email address hidden> - Tel. 0351-41 883 221 +http://www.kernkonzept.com + +Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. +Geschäftsführer: Dr.-Ing. Michael Hohmuth + + +On Tue, 14 Apr 2020 13:27:34 -0000 +Philipp Eppelt <email address hidden> wrote: + +> Hi, +> +> I have to clarify some things mentioned in my last post: +> +> I only tested the change with an emulated EPYC-v2 CPU, I cannot test on +> a physical EPYC CPU at the moment. However, I doubt that the results +> will be different regarding the 0x8000_0008.ECX result. +> +> The topology information printed is from the EPYC-v2 CPU model. I try to +> get access to the machine and have a look if -cpu host affects this +> topology. +> +> So there is still the open question for the -enable-kvm -cpu host -smp 4 +> case. Shouldn't in this case the topology of the host CPU be reported? +topology was never affected by the choice of -cpu, it's up to users to +define it using -smp the way they prefer. + + +> In all emulated-CPU cases it's on the user to define the topology or to +> live with the generated one (although I think preferring multi-socket +> systems is outdated, but it's likely just the case in my 'world'). +> +> +> Cheers, +> Philipp +> +> +> On 4/14/20 10:24 AM, Philipp Eppelt wrote: +> > Hi, +> > +> > thanks for looking into this so quickly. +> > +> > With this patch applied ontop of git commit +> > f3bac27cc1e303e1860cc55b9b6889ba39dee587 I still have the issue and it +> > reports the same numbers. I like the new usage of the ApicIdSize field. +> > +> > +> > I looked into the mentioned pc_smp_parse() and had it print the topology +> > for -smp 4: +> > +> > qemu-system-x86_64: warning: cpu topology: sockets (4) , dies (1) , +> > cores (1) , threads (1) , maxcpus (4), cpus (4) +> > +> > and with -smp 4,cores=4: +> > +> > qemu-system-x86_64: warning: cpu topology: sockets (1) , dies (1) , +> > cores (4) , threads (1) , maxcpus (4), cpus (4) +> > +> > As far as I understand it, these are the numbers the cpuid:8000'0008 +> > code relies on: +> > `cs->nr_cores`, `cs->nr_threads` with `cs` being of type CPUState. +> > +> > So I think the issue is rooted with the preferring sockets over cores +> > when the -smp cmdline option is parsed, as stated in hw/i386/pc.c:729. +> > +> > I guess this is the same code for Intel and AMD CPUs alike and this +> > issue just didn't surface for us on Intel CPUs, as they don't have this +> > CPUID leaf and we don't look at the topology. +> > +> > This seems to boil down to a more careful use of the -smp option on my end. +> > +> > Thanks again for looking into this. +> > +> > Cheers, +> > Philipp +> > +> > +> > +> > On 4/10/20 2:12 AM, Babu Moger wrote: +> >> Philipp, +> >> Can you please check if this patch works for you. +> >> +> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c +> >> index 90ffc5f..e467fee 100644 +> >> --- a/target/i386/cpu.c +> >> +++ b/target/i386/cpu.c +> >> @@ -5831,10 +5831,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t +> >> index, uint32_t count, +> >> } +> >> *ebx = env->features[FEAT_8000_0008_EBX]; +> >> *ecx = 0; +> >> - *edx = 0; +> >> if (cs->nr_cores * cs->nr_threads > 1) { +> >> - *ecx |= (cs->nr_cores * cs->nr_threads) - 1; +> >> + unsigned long max_apicids, bits_required; +> >> + +> >> + max_apicids = (cs->nr_cores * cs->nr_threads) - 1; +> >> + if (max_apicids) { +> >> + /* Find out the number of bits to represent all the +> >> apicids */ +> >> + bits_required = find_last_bit(&max_apicids, +> >> BITS_PER_BYTE) + 1; +> >> + *ecx |= bits_required << 12 | max_apicids; +> >> + } +> >> } +> >> + *edx = 0; +> >> break; +> >> case 0x8000000A: +> >> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { +> >> +> >> +> >> On 4/9/20 9:00 AM, Igor Mammedov wrote: +> >>> On Thu, 09 Apr 2020 12:58:11 -0000 +> >>> Philipp Eppelt <email address hidden> wrote: +> >>> +> >>>> Public bug reported: +> >>>> +> >>>> Setup: +> >>>> CPU: AMD EPYC-v2 or host's EPYC cpu +> >>>> Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +> >>>> qemu version: self build +> >>>> git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +> >>>> config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' +> >>>> +> >>>> Cmdline: +> >>>> qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 +> >>>> +> >>>> Issue: +> >>>> We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +> >>>> In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] +> >>>> +> >>>> The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +> >>>> The lower four bits of ECX are the [NC] field and all set. +> >>>> +> >>>> When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +> >>>> Note, ECX is zero. Indicating that this is no SMP capabale CPU. +> >>>> +> >>>> I'm debugging it using my local machine and the QEMU provided EPYC-v2 +> >>>> CPU model and it is reproducible there as well and reports: EAX: +> >>>> 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 +> >>>> +> >>>> I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +> >>>> I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. +> >>>> +> >>>> The following table shows my findings with the -smp option: +> >>>> Option | Qemu guest observed ECX value +> >>>> -smp 4 | 0x0 +> >>>> -smp 4,cores=4 | 0x3 +> >>>> -smp 4,cores=2,thread=2 | 0x3 +> >>>> -smp 4,cores=4,threads=2 | QEMU boot error: topology false. +> >>>> +> >>>> Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +> >>>> Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? +> >>> I'd say X corresponds to number of logical CPUs. +> >>> Depending on presence of other options these are distributed among them in magical manner +> >>> (see pc_smp_parse() for starters) +> >>> +> >>>> Querying 0x8000'0008 on the physical processor results in different +> >>>> reports than quering QEMU's model as does it with -enable-kvm -cpu host. +> >>>> +> >>>> Furthermore, the ACPI.MADT shows 4 local APICs to be present while the +> >>>> CPU leave reports a single core processor. +> >>> it matches -smp X as it should be. +> >>> +> >>>> +> >>>> This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the +> >>>> wrong number. +> >>> CCed author of recent epyc patches who might know how AMD should work better than me. +> >>> +> >>>> +> >>>> Please let me know, if you need more information from my side. +> >>>> +> >>>> +> >>>> [0] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkernkonzept%2Ffiasco%2Fblob%2F522ccc5f29ab120213cf02d71328e2b879cbbd19%2Fsrc%2Fkern%2Fia32%2Fkernel_thread-ia32.cpp%23L109&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=hcFJzLAVQoIh5IN9CP%2F9cUQNOZoBnpRA6FliJur1wzQ%3D&reserved=0 +> >>>> [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkernkonzept%2Ffiasco%2Fblob%2F522ccc5f29ab120213cf02d71328e2b879cbbd19%2Fsrc%2Fkern%2Fia32%2Fcpu-ia32.cpp%23L1120&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=ANJIbYKbwfq2bDelH%2FRLKnDPIUZc1BwxHspmgxLU7gs%3D&reserved=0 +> >>>> [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fqemu%2Fqemu%2Fblob%2Ff2a8261110c32c4dccd84e774d8dd7a0524e00fb%2Ftarget%2Fi386%2Fcpu.c%23L5835&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=oj3mv9e5YOzUsfUjXK44gC8LybyWgMKo8JBIrRR%2BmDA%3D&reserved=0 +> >>>> [3] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24594.pdf&data=02%7C01%7Cbabu.moger%40amd.com%7C57569f7959744399655b08d7dc8e6e24%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637220379083511672&sdata=7Yr3J9ihlqSqXCXKN5JJNTByO3NGI%2BGMz2EqBF2Y4hw%3D&reserved=0 +> >>>> +> >>>> ** Affects: qemu +> >>>> Importance: Undecided +> >>>> Status: New +> >>>> +> >>> +> >> +> > +> + + + +Thanks. I saw the update in the thread. +https://<email address hidden>/ +Looks like you have found a way to take care of your problem. +But We need to fix the CPUID leaf 0x8000'0008 anyways. +Will send the patch to review later this week. Thanks + + +On 4/9/20 12:48 PM, Babu Moger wrote: +> +> +> On 4/9/20 9:00 AM, Igor Mammedov wrote: +>> On Thu, 09 Apr 2020 12:58:11 -0000 +>> Philipp Eppelt <email address hidden> wrote: +>> +>>> Public bug reported: +>>> +>>> Setup: +>>> CPU: AMD EPYC-v2 or host's EPYC cpu +>>> Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 +>>> qemu version: self build +>>> git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 +>>> config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' +>>> +>>> Cmdline: +>>> qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 +>>> +>>> Issue: +>>> We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. +>>> In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] +>>> +>>> The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 +>>> The lower four bits of ECX are the [NC] field and all set. +>>> +>>> When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 +>>> Note, ECX is zero. Indicating that this is no SMP capabale CPU. +>>> +>>> I'm debugging it using my local machine and the QEMU provided EPYC-v2 +>>> CPU model and it is reproducible there as well and reports: EAX: +>>> 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 +>>> +>>> I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. +>>> I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. +>>> +>>> The following table shows my findings with the -smp option: +>>> Option | Qemu guest observed ECX value +>>> -smp 4 | 0x0 +>>> -smp 4,cores=4 | 0x3 +>>> -smp 4,cores=2,thread=2 | 0x3 +>>> -smp 4,cores=4,threads=2 | QEMU boot error: topology false. +>>> +>>> Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. +>>> Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? +>> I'd say X corresponds to number of logical CPUs. +>> Depending on presence of other options these are distributed among them in magical manner +>> (see pc_smp_parse() for starters) +>> +>>> Querying 0x8000'0008 on the physical processor results in different +>>> reports than quering QEMU's model as does it with -enable-kvm -cpu host. +>>> +>>> Furthermore, the ACPI.MADT shows 4 local APICs to be present while the +>>> CPU leave reports a single core processor. +>> it matches -smp X as it should be. +>> +>>> +>>> This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the +>>> wrong number. +>> CCed author of recent epyc patches who might know how AMD should work better than me. +> +> Hmm.. Interesting.. Not sure why this did not come up during my testing. +> Probably this cpuid information is not widely used. +> +> Yes. I am looking at it right now. I see that EPYC model is reporting +> wrong. Not sure why -cpu host is reporting wrong. I thought -cpu host gets +> the information directly from the host. Will investigate. +> +> + + +CPUID leaf CPUID_Fn80000008_ECX provides information about the +number of threads supported by the processor. It was found that +the field ApicIdSize(bits 15-12) was not set correctly. + +ApicIdSize is defined as the number of bits required to represent +all the ApicId values within a package. + +Valid Values: Value Description +3h-0h Reserved. +4h up to 16 threads. +5h up to 32 threads. +6h up to 64 threads. +7h up to 128 threads. +Fh-8h Reserved. + +Fix the bit appropriately. + +This came up during following thread. +https://lore.kernel.<email address hidden>/#t + +Refer the Processor Programming Reference (PPR) for AMD Family 17h +Model 01h, Revision B1 Processors. The documentation is available +from the bugzilla Link below. +Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 + +Reported-by: Philipp Eppelt <email address hidden> +Signed-off-by: Babu Moger <email address hidden> +--- + target/i386/cpu.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +diff --git a/target/i386/cpu.c b/target/i386/cpu.c +index 90ffc5f..68210f6 100644 +--- a/target/i386/cpu.c ++++ b/target/i386/cpu.c +@@ -5830,11 +5830,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, + *eax = cpu->phys_bits; + } + *ebx = env->features[FEAT_8000_0008_EBX]; +- *ecx = 0; +- *edx = 0; + if (cs->nr_cores * cs->nr_threads > 1) { +- *ecx |= (cs->nr_cores * cs->nr_threads) - 1; ++ unsigned int max_apicids, bits_required; ++ ++ max_apicids = (cs->nr_cores * cs->nr_threads) - 1; ++ /* Find out the number of bits to represent all the apicids */ ++ bits_required = 32 - clz32(max_apicids); ++ *ecx = bits_required << 12 | max_apicids; ++ } else { ++ *ecx = 0; + } ++ *edx = 0; + break; + case 0x8000000A: + if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { + + + +Good catch, thanks for the patch. Comments below: + +On Fri, Apr 17, 2020 at 10:14:32AM -0500, Babu Moger wrote: +> CPUID leaf CPUID_Fn80000008_ECX provides information about the +> number of threads supported by the processor. It was found that +> the field ApicIdSize(bits 15-12) was not set correctly. +> +> ApicIdSize is defined as the number of bits required to represent +> all the ApicId values within a package. +> +> Valid Values: Value Description +> 3h-0h Reserved. +> 4h up to 16 threads. +> 5h up to 32 threads. +> 6h up to 64 threads. +> 7h up to 128 threads. +> Fh-8h Reserved. +> +> Fix the bit appropriately. +> +> This came up during following thread. +> https://lore.kernel.<email address hidden>/#t +> +> Refer the Processor Programming Reference (PPR) for AMD Family 17h +> Model 01h, Revision B1 Processors. The documentation is available +> from the bugzilla Link below. +> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 +> +> Reported-by: Philipp Eppelt <email address hidden> +> Signed-off-by: Babu Moger <email address hidden> +> --- +> target/i386/cpu.c | 12 +++++++++--- +> 1 file changed, 9 insertions(+), 3 deletions(-) +> +> diff --git a/target/i386/cpu.c b/target/i386/cpu.c +> index 90ffc5f..68210f6 100644 +> --- a/target/i386/cpu.c +> +++ b/target/i386/cpu.c +> @@ -5830,11 +5830,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, +> *eax = cpu->phys_bits; +> } +> *ebx = env->features[FEAT_8000_0008_EBX]; +> - *ecx = 0; +> - *edx = 0; +> if (cs->nr_cores * cs->nr_threads > 1) { +> - *ecx |= (cs->nr_cores * cs->nr_threads) - 1; + +I'm not sure we want a compatibility flag to keep ABI on older +machine types, here. Strictly speaking, CPUID must never change +on older machine types, but sometimes trying hard to emulate bugs +of old QEMU versions is a pointless exercise. + + +> + unsigned int max_apicids, bits_required; +> + +> + max_apicids = (cs->nr_cores * cs->nr_threads) - 1; +> + /* Find out the number of bits to represent all the apicids */ +> + bits_required = 32 - clz32(max_apicids); + +This won't work if nr_cores > 1 and nr_threads is not a power of +2, will it? + +For reference, the field is documented[1] as: + +"The number of bits in the initial Core::X86::Apic::ApicId[ApicId] +value that indicate thread ID within a package" + +This sounds like the value already stored at +CPUX86State::pkg_offset. + + +> + *ecx = bits_required << 12 | max_apicids; + +Bits 7:0 are documented as "The number of threads in the package +is NC+1", with no reference to APIC IDs at all. + +Using ((nr_cores * nr_threads) - 1) for bits 7:0 sounds correct, +but the variable name seems misleading. + + +> + } else { +> + *ecx = 0; +> } +> + *edx = 0; +> break; +> case 0x8000000A: +> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { +> +> + +References: + +[1] Processor Programming Reference (PPR) for + AMD Family 17h Model 18h, Revision B1 Processors + 55570-B1 Rev 3.14 - Sep 26, 2019 + https://bugzilla.kernel.org/attachment.cgi?id=287395&action=edit + + +-- +Eduardo + + + + + +On 4/17/20 2:15 PM, Eduardo Habkost wrote: +> Good catch, thanks for the patch. Comments below: +> +> On Fri, Apr 17, 2020 at 10:14:32AM -0500, Babu Moger wrote: +>> CPUID leaf CPUID_Fn80000008_ECX provides information about the +>> number of threads supported by the processor. It was found that +>> the field ApicIdSize(bits 15-12) was not set correctly. +>> +>> ApicIdSize is defined as the number of bits required to represent +>> all the ApicId values within a package. +>> +>> Valid Values: Value Description +>> 3h-0h Reserved. +>> 4h up to 16 threads. +>> 5h up to 32 threads. +>> 6h up to 64 threads. +>> 7h up to 128 threads. +>> Fh-8h Reserved. +>> +>> Fix the bit appropriately. +>> +>> This came up during following thread. +>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fqemu-devel%2F158643709116.17430.15995069125716778943.malonedeb%40wampee.canonical.com%2F%23t&data=02%7C01%7Cbabu.moger%40amd.com%7C1b8d59370cdb403dd54308d7e303adb7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637227477274521298&sdata=NZHLwOkQrbjkGeqYSI0wgRNUd3QHRCf7lBtdqoR5XfI%3D&reserved=0 +>> +>> Refer the Processor Programming Reference (PPR) for AMD Family 17h +>> Model 01h, Revision B1 Processors. The documentation is available +>> from the bugzilla Link below. +>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D206537&data=02%7C01%7Cbabu.moger%40amd.com%7C1b8d59370cdb403dd54308d7e303adb7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637227477274521298&sdata=oNLqu0J49eTrJ8pQ6GKg64ZUDfV3egZN2VVkU0DwMaU%3D&reserved=0 +>> +>> Reported-by: Philipp Eppelt <email address hidden> +>> Signed-off-by: Babu Moger <email address hidden> +>> --- +>> target/i386/cpu.c | 12 +++++++++--- +>> 1 file changed, 9 insertions(+), 3 deletions(-) +>> +>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c +>> index 90ffc5f..68210f6 100644 +>> --- a/target/i386/cpu.c +>> +++ b/target/i386/cpu.c +>> @@ -5830,11 +5830,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, +>> *eax = cpu->phys_bits; +>> } +>> *ebx = env->features[FEAT_8000_0008_EBX]; +>> - *ecx = 0; +>> - *edx = 0; +>> if (cs->nr_cores * cs->nr_threads > 1) { +>> - *ecx |= (cs->nr_cores * cs->nr_threads) - 1; +> +> I'm not sure we want a compatibility flag to keep ABI on older +> machine types, here. Strictly speaking, CPUID must never change +> on older machine types, but sometimes trying hard to emulate bugs +> of old QEMU versions is a pointless exercise. + +Not sure about this. But it seemed like nobody cared about this field before. +> +> +>> + unsigned int max_apicids, bits_required; +>> + +>> + max_apicids = (cs->nr_cores * cs->nr_threads) - 1; +>> + /* Find out the number of bits to represent all the apicids */ +>> + bits_required = 32 - clz32(max_apicids); +> +> This won't work if nr_cores > 1 and nr_threads is not a power of +> 2, will it? + +It seem to work. Tested with threads=5,cores=3. + +> +> For reference, the field is documented[1] as: +> +> "The number of bits in the initial Core::X86::Apic::ApicId[ApicId] +> value that indicate thread ID within a package" +> +> This sounds like the value already stored at +> CPUX86State::pkg_offset. + +Yes, it is already in pkg_offset. We can use it. + +> +> +>> + *ecx = bits_required << 12 | max_apicids; +> +> Bits 7:0 are documented as "The number of threads in the package +> is NC+1", with no reference to APIC IDs at all. +> +> Using ((nr_cores * nr_threads) - 1) for bits 7:0 sounds correct, +> but the variable name seems misleading. + +I can change the variable name to num_threads. +> +> +>> + } else { +>> + *ecx = 0; +>> } +>> + *edx = 0; +>> break; +>> case 0x8000000A: +>> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { +>> +>> +> +> References: +> +> [1] Processor Programming Reference (PPR) for +> AMD Family 17h Model 18h, Revision B1 Processors +> 55570-B1 Rev 3.14 - Sep 26, 2019 +> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fattachment.cgi%3Fid%3D287395%26action%3Dedit&data=02%7C01%7Cbabu.moger%40amd.com%7C1b8d59370cdb403dd54308d7e303adb7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637227477274521298&sdata=UsM3h4vp3dTgigqOvt7GrGiIUHvH8Kn1g%2BO%2FfGMav%2Bc%3D&reserved=0 +> +> + + +CPUID leaf CPUID_Fn80000008_ECX provides information about the +number of threads supported by the processor. It was found that +the field ApicIdSize(bits 15-12) was not set correctly. + +ApicIdSize is defined as the number of bits required to represent +all the ApicId values within a package. + +Valid Values: Value Description +3h-0h Reserved. +4h up to 16 threads. +5h up to 32 threads. +6h up to 64 threads. +7h up to 128 threads. +Fh-8h Reserved. + +Fix the bit appropriately. + +This came up during following thread. +https://lore.kernel.<email address hidden>/#t + +Refer the Processor Programming Reference (PPR) for AMD Family 17h +Model 01h, Revision B1 Processors. The documentation is available +from the bugzilla Link below. +Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 + +Reported-by: Philipp Eppelt <email address hidden> +Signed-off-by: Babu Moger <email address hidden> +--- +v2: + Used env->pkg_offset for bits 15:12 which is already available. + + target/i386/cpu.c | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +diff --git a/target/i386/cpu.c b/target/i386/cpu.c +index 90ffc5f..5e5a605 100644 +--- a/target/i386/cpu.c ++++ b/target/i386/cpu.c +@@ -5830,11 +5830,20 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, + *eax = cpu->phys_bits; + } + *ebx = env->features[FEAT_8000_0008_EBX]; +- *ecx = 0; +- *edx = 0; + if (cs->nr_cores * cs->nr_threads > 1) { +- *ecx |= (cs->nr_cores * cs->nr_threads) - 1; ++ /* ++ * Bits 15:12 is "The number of bits in the initial ++ * Core::X86::Apic::ApicId[ApicId] value that indicate ++ * thread ID within a package". This is already stored at ++ * CPUX86State::pkg_offset. ++ * Bits 7:0 is "The number of threads in the package is NC+1" ++ */ ++ *ecx = (env->pkg_offset << 12) | ++ ((cs->nr_cores * cs->nr_threads) - 1); ++ } else { ++ *ecx = 0; + } ++ *edx = 0; + break; + case 0x8000000A: + if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { + + + +Hi, + +thanks for the patch, I tested it in my setup and I'm seeing numbers +that make sense. + +However, I can create a setup which places the value 02h* into the +ApicIdSize field, which is reserved. However, I deem this a +configuration issue as well. + +* -cpu EPYC-v2 -smp 4,cores=4 --> 0x8000_0008[ECX] = 0x2003 + +Cheers, +Philipp + +On 4/17/20 11:55 PM, Babu Moger wrote: +> CPUID leaf CPUID_Fn80000008_ECX provides information about the +> number of threads supported by the processor. It was found that +> the field ApicIdSize(bits 15-12) was not set correctly. +> +> ApicIdSize is defined as the number of bits required to represent +> all the ApicId values within a package. +> +> Valid Values: Value Description +> 3h-0h Reserved. +> 4h up to 16 threads. +> 5h up to 32 threads. +> 6h up to 64 threads. +> 7h up to 128 threads. +> Fh-8h Reserved. +> +> Fix the bit appropriately. +> +> This came up during following thread. +> https://lore.kernel.<email address hidden>/#t +> +> Refer the Processor Programming Reference (PPR) for AMD Family 17h +> Model 01h, Revision B1 Processors. The documentation is available +> from the bugzilla Link below. +> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 +> +> Reported-by: Philipp Eppelt <email address hidden> +> Signed-off-by: Babu Moger <email address hidden> +> --- +> v2: +> Used env->pkg_offset for bits 15:12 which is already available. +> +> target/i386/cpu.c | 15 ++++++++++++--- +> 1 file changed, 12 insertions(+), 3 deletions(-) +> +> diff --git a/target/i386/cpu.c b/target/i386/cpu.c +> index 90ffc5f..5e5a605 100644 +> --- a/target/i386/cpu.c +> +++ b/target/i386/cpu.c +> @@ -5830,11 +5830,20 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, +> *eax = cpu->phys_bits; +> } +> *ebx = env->features[FEAT_8000_0008_EBX]; +> - *ecx = 0; +> - *edx = 0; +> if (cs->nr_cores * cs->nr_threads > 1) { +> - *ecx |= (cs->nr_cores * cs->nr_threads) - 1; +> + /* +> + * Bits 15:12 is "The number of bits in the initial +> + * Core::X86::Apic::ApicId[ApicId] value that indicate +> + * thread ID within a package". This is already stored at +> + * CPUX86State::pkg_offset. +> + * Bits 7:0 is "The number of threads in the package is NC+1" +> + */ +> + *ecx = (env->pkg_offset << 12) | +> + ((cs->nr_cores * cs->nr_threads) - 1); +> + } else { +> + *ecx = 0; +> } +> + *edx = 0; +> break; +> case 0x8000000A: +> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { +> + +-- +<email address hidden> - Tel. 0351-41 883 221 +http://www.kernkonzept.com + +Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. +Geschäftsführer: Dr.-Ing. Michael Hohmuth + + +If I got that right, there were some patches proposed for this bug ... has this been fixed already? Or is there still anything left to do? + +The patch mentioned earlier has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/cac9edfc4dad2a7d2ad7e +So I assume this has been fixed. If you still have problems, please open a new ticket in the new bug tracker at gitlab. + diff --git a/results/classifier/zero-shot/108/permissions/1873769 b/results/classifier/zero-shot/108/permissions/1873769 new file mode 100644 index 000000000..0d7a06c4d --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1873769 @@ -0,0 +1,103 @@ +permissions: 0.928 +semantic: 0.850 +device: 0.820 +other: 0.817 +network: 0.813 +debug: 0.796 +graphic: 0.791 +PID: 0.787 +vnc: 0.757 +boot: 0.695 +performance: 0.693 +socket: 0.677 +KVM: 0.633 +files: 0.565 + +SB16 audio playback freezes emulation in Windows 95 guest + +- QEMU 4.2.93 (v5.0.0-rc3) built from latest git master 20038cd7a8412feeb49c01f6ede89e36c8995472 using MSYS2 on Windows 10 and launched on same Windows 10 + +- Launched using "qemu-system-i386.exe -drive format=raw,file=hdd-2gb.img -soundhw pcspk,sb16 -m 16 -cpu pentium -vga std -cdrom Windows_95.iso -boot c" + +- I have attached video screen capture of the issue + +--- + +I decided to make my first ever QEMU build after encountering the dsound issues using the latest 4.2.0 binary from https://qemu.weilnetz.de/w64/. In my 5.0.0-rc3 build the sound playback is working correctly, however the whole Windows 95 UI freezes while sound is playing. + + + +This is with GTK UI? Do you still have the same problem if you use Spice and remote-viewer instead? + +(GTK UI and Sound Blaster 16 emulation don't play well together. GTK UI does screen updates only when the main event loop becomes idle, but it never becomes idle when SB16 audio is playing due to the way hw/dma/i8257 works. The combination of GTK UI screen updates + SB16 DMA transfer additionally causes i8257_dma_run() getting called at a very rapid rate.) + + +Hi Allan, +I've hit EXACTLY the same problem, while writing a SB16 driver. + +Reproducing the bug +---------------------- +I've tried to QEMU 4 in several scenarios (GTK UI, text mode with the -curses option, +just serial console with -nographic and with virt-manager which uses Spice). It works +as expected in all the cases EXCEPT for the GTK UI: in that case, the video freezes +while playing the sound, exactly as in the video posted by Marko; even QEMU's menu +doesn't respond while the audio is playing (the bug affects the whole QEMU UI). + +Regression +--------------------- +I've also tried the same test with QEMU 2.11, on another machine with Ubuntu 18.04 (LTS) +and there the problem simply does *not* exist. QEMU's UI (does QEMU 2.x uses GTK?), +works GREAT while playing SB16 audio. + +Conclusion +---------------- +Is there any chance this bug could be fixed easily, or a fix would necessarily require +a (partial) re-design of the way the GTK UI works? In particular, why on QEMU 2.11 the +problem does not exist? + + +Thanks in advance, +Vlad + +P.S.: sorry for the terribly broken lines. I didn't expect launchpad to add additional line breaks that way :-( + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + + +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/469 + + diff --git a/results/classifier/zero-shot/108/permissions/1876678 b/results/classifier/zero-shot/108/permissions/1876678 new file mode 100644 index 000000000..0570dd104 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1876678 @@ -0,0 +1,598 @@ +permissions: 0.927 +performance: 0.907 +device: 0.903 +debug: 0.902 +vnc: 0.900 +KVM: 0.895 +graphic: 0.891 +boot: 0.881 +other: 0.877 +socket: 0.866 +semantic: 0.855 +PID: 0.854 +files: 0.850 +network: 0.846 + +Ubuntu 20.04 KVM / QEMU Failure with nested FreeBSD bhyve + +BUG: + +Starting FreeBSD Layer 2 bhyve Guest within Layer 1 FreeBSD VM Host on Layer 0 Ubuntu 20.04 KVM / QEMU Host result in Layer 1 Guest / Host Pausing with "Emulation Failure" + +TESTING: + +My test scenario is nested virtualisation: +Layer 0 - Ubuntu 20.04 Host +Layer 1 - FreeBSD 12.1 with OVMF + bhyve hypervisor Guest/Host +Layer 2 - FreeBSD 12.1 guest + +Layer 0 Host is: Ubuntu 20.04 LTS KVM / QEMU / libvirt + +<<START QEMU VERSION>> +$ virsh -c qemu:///system version --daemon +Compiled against library: libvirt 6.0.0 +Using library: libvirt 6.0.0 +Using API: QEMU 6.0.0 +Running hypervisor: QEMU 4.2.0 +Running against daemon: 6.0.0 +<<END QEMU VERSION> + +<<START Intel VMX Support & Nesting Enabled>> +$ cat /proc/cpuinfo | grep -c vmx +64 +$ cat /sys/module/kvm_intel/parameters/nested +Y +<<END Intel VMS>> + + + +Layer 1 Guest / Host is: FreeBSD Q35 v4.2 with OVMF: + +Pass Host VMX support to Layer 1 Guest via <cpu mode='host-model> + +<<LIBVIRT CONFIG SNIPPET>> +... +... + <os> + <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram>/home/USER/swarm.bhyve.freebsd/OVMF_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'/> +... +... +<END LIBVIRT CONFIG SNIPPET>> + +Checked that Layer 1 - FreeBSD Quest / Host has VMX feature available: + +<<LAYER 1 - FreeBSD CPU Features>> +# uname -a +FreeBSD swarm.DOMAIN.HERE 12.1-RELEASE FreeBSD 12.1-RELEASE GENERIC amd64 + +# grep Features /var/run/dmesg.boot + Features=0xf83fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,SS> + Features2=0xfffa3223<SSE3,PCLMULQDQ,VMX,SSSE3,FMA,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV> + AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> + AMD Features2=0x121<LAHF,ABM,Prefetch> + Structured Extended Features=0x1c0fbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP> + Structured Extended Features2=0x4<UMIP> + Structured Extended Features3=0xac000400<MD_CLEAR,IBPB,STIBP,ARCH_CAP,SSBD> + XSAVE Features=0x1<XSAVEOPT> +<<END LAYER 1 - FreeBSD CPU Features> + +On Layer 1 FreeBSD Guest / Host start up the Layer 2 guest.. + +<<START LAYER 2 GUEST START>> +# ls +FreeBSD-11.2-RELEASE-amd64-bootonly.iso FreeBSD-12.1-RELEASE-amd64-dvd1.iso bee-hd1-01.img +# /usr/sbin/bhyve -c 2 -m 2048 -H -A -s 0:0,hostbridge -s 1:0,lpc -s 2:0,e1000,tap0 -s 3:0,ahci-hd,bee-hd1-01.img -l com1,stdio -s 5:0,ahci-cd,./FreeBSD-12.1-RELEASE-amd64-dvd1.iso bee +<<END LAYER 2 GUEST START>> + +Result is that Layer 1 - FreeBSD Host guest "paused". + +To Layer 1 machines freezes I cannot get any further diagnostics from this machine, so I run tail on libvirt log from Layer 0 - Ubuntu Host + +<<LAYER 0 LOG TAIL>> +char device redirected to /dev/pts/29 (label charserial0) +2020-05-04T06:09:15.310474Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-05-04T06:09:15.310531Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-05-04T06:09:15.312533Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-05-04T06:09:15.312548Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-05-04T06:09:15.313828Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-05-04T06:09:15.313841Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-05-04T06:09:15.315185Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-05-04T06:09:15.315201Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 00000000 00008000 DPL=0 <hiword> +CS =0000 00000000 00000000 00008000 DPL=0 <hiword> +SS =0000 00000000 00000000 00008000 DPL=0 <hiword> +DS =0000 00000000 00000000 00008000 DPL=0 <hiword> +FS =0000 00000000 00000000 00008000 DPL=0 <hiword> +GS =0000 00000000 00000000 00008000 DPL=0 <hiword> +LDT=0000 00000000 00000000 00008000 DPL=0 <hiword> +TR =0000 00000000 00000000 00008000 DPL=0 <hiword> +GDT= 0000000000000000 00000000 +IDT= 0000000000000000 00000000 +CR0=80050033 CR2=0000000000000000 CR3=0000000000000000 CR4=00372060 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +Code=<??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? +2020-05-04T06:35:39.186799Z qemu-system-x86_64: terminating on signal 15 from pid 2155 (/usr/sbin/libvirtd) +2020-05-04 06:35:39.386+0000: shutting down, reason=destroyed +<<END LAYER 0 LOG TAIL>> + + +I am reporting this bug here as result is very similar to that seen with QEMU seabios failure reported here: https://bugs.launchpad.net/qemu/+bug/1866870 + +However in this case my VM Layer 1 VM is using OVMF. + +NOTE 1: I have also tested with Q35 v3.1 and 2.12 and get the same result. +NOTE 2: Due to bug in FreeBSD networking code, I had to compile custom kernel with "netmap driver disabled". This is known bug in FreeBSD that I have reported separately. +NOTE 3: I will cross posted this bug report on FreeBSD bugzilla as well: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246168 +NOTE 4: Have done extensive testing of Ubuntu 20.04 Nested virtualisation with just Ubuntu hosts and OVMF and the nested virtualisation runs correctly, so problem is specific to using FreeBSD / bhyve guest / host. + +Hi Ubuntu / KVM Maintainers, + +I have now done additional diagnostics on this bug and it appears to be triggered in nested virtualization case when apic virtualisation is available in Layer 0 HW and then passed forward to Layer 1 VM via Libvirt: <cpu mode='host-model' check='partial'> . + +Testing found that in case where Layer 1 FreeBSD host had this feature, see "VID,PostIntr" in "VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr" from CPU Feature below: + +<<START LAYER 1 - FreeBSD CPU Report from dmesg.boot>> +... +... +CPU: Intel Core Processor (Broadwell, IBRS) (2600.09-MHz K8-class CPU) + Origin="GenuineIntel" Id=0x306d2 Family=0x6 Model=0x3d Stepping=2 + Features=0xf83fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,SS> + Features2=0xfffa3223<SSE3,PCLMULQDQ,VMX,SSSE3,FMA,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV> + AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> + AMD Features2=0x121<LAHF,ABM,Prefetch> + Structured Extended Features=0x1c0fbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP> + Structured Extended Features2=0x4<UMIP> + Structured Extended Features3=0xac000400<MD_CLEAR,IBPB,STIBP,ARCH_CAP,SSBD> + XSAVE Features=0x1<XSAVEOPT> + IA32_ARCH_CAPS=0x8<SKIP_L1DFL_VME> + AMD Extended Feature Extensions ID EBX=0x1001000 + VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr +Hypervisor: Origin = "KVMKVMKVM" +... +... +<END LAYER 1 - dimes.log>> + +In my case with Intel Broadwell chipset this is available, in case of desktop "core i5-8250U" chip- this reports as: + +VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID + +For this case HW case, nested: +Layer 0 - Ubuntu 20.04, Layer 1 - FreeBSD 12.1 with bhyve, Layer 2 - FreeBSD 12.1 +Works. + +Workaround is to disable APIC virtual interrupt delivery: + +1. Add entry into Layer 1 - FreeBSD Guest / Host: /boot/loader.conf: +hw.vmm.vmx.use_apic_vid=0 + +2. Reboot + +3. Check via sysctl that virtual_interupt_delivery is disabled: +# sysctl hw.vmm.vmx.cap.virtual_interrupt_delivery +hw.vmm.vmx.cap.virtual_interrupt_delivery: 0 <- should be zero + + +Questions is: + +While FreeBSD triggers this bug, is this a KVM issue or a FreeBSD bhyve one ? + +In doing some searching on Web I see that there is already work being done with KVM 5.6 around APIC virtualisation and its handling. So not sure if this a potentially know problem: https://events19.linuxfoundation.org/wp-content/uploads/2017/12/Improving-KVM-x86-Nested-Virtualization-Liran-Alon-Oracle.pdf + +APIC Virtualisation support was introduced back in FreeBSD 11.0 way back in Sept 2016: + +https://www.freebsd.org/releases/11.0R/relnotes.html#hardware-virtualization + +Thanks to Peter Graham on FreeBSD virtualization bug tracker for helping to find source of problem. + +Should this BUG go to KVM / QEMU upstream ? + +Cheers, + +John Hartley. + + + +Since you were talking about Ubuntu, I moved this to the Ubuntu tracker now. If you can reproduce the problem with upstream QEMU (currently v6.0), then please open a new ticket in the new QEMU issue tracker at gitlab.com. + +Hi John, +could you give it a try with the more recent virtualization stack in [1]. +Since this might as well be in the kernel and not qemu/libvirt you might also consider checking other kernel versions - not sure with your self-built driver, but what kernels have you tried and which newer ones could you try? If you can overcome the other issue in another way you might try [2] which is great to check various versions. + + +That works "in place" on your 20.04 system and if better would indicate that one of the components has a fix that we only need to identify. + +P.S. the PPA does not yet contain qmeu 6.0 which released a few days ago, it will be june until I get to that I guess :-/ + +[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports +[2]: https://kernel.ubuntu.com/~kernel-ppa/mainline/ + +Hi Christian, + +just letting you know I have got email notifications and will re-run tests. +It will likely take me a couple days to complete this. I will post findings once done. +I will try against 20.04 and 21.04 to start and post on various component versions and results. + +Cheers, + +John. + +Hi Christian, + +I have re-tested with Ubuntu 21.04 (Hirsute Hippo). + +It took me a while to set up test environment. + +Summary: + +Ubuntu Version: + +$ cat /etc/*-release +DISTRIB_ID=Ubuntu +DISTRIB_RELEASE=21.04 +DISTRIB_CODENAME=hirsute +DISTRIB_DESCRIPTION="Ubuntu 21.04" +NAME="Ubuntu" +VERSION="21.04 (Hirsute Hippo)" +ID=ubuntu +ID_LIKE=debian +PRETTY_NAME="Ubuntu 21.04" +VERSION_ID="21.04" +HOME_URL="https://www.ubuntu.com/" +SUPPORT_URL="https://help.ubuntu.com/" +BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" +PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" +VERSION_CODENAME=hirsute +UBUNTU_CODENAME=hirsute + +Linux Version: + +$ uname -a +Linux green 5.11.0-17-generic #18-Ubuntu SMP Thu May 6 20:10:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux + +QEMU / Libvirt Version: + +$ sudo virsh version +Compiled against library: libvirt 7.0.0 +Using library: libvirt 7.0.0 +Using API: QEMU 7.0.0 +Running hypervisor: QEMU 5.2.0 + +Nesting Scenario: + +Layer 0 - Ubuntu 21.04 +Layer 1 - FreeBSD 12.2 Bhyve Host +Layer 2 - FreeBSD 12.2 Guest + +Result: + +Virtual Machine Freezes (without work around of turning off APIC interrupt delivery as per existing diagnosis: + +Workaround is to disable APIC virtual interrupt delivery: + +1. Add entry into Layer 1 - FreeBSD Guest / Host: /boot/loader.conf: +hw.vmm.vmx.use_apic_vid=0 + + +Here is the libvirt log taken from Layer 0 - Ubuntu host: + +<<Layer 0 - Ubuntu 21.04 QEMU / KVM Host>> +2021-05-16 09:57:28.970+0000: starting up libvirt version: 7.0.0, package: 2ubuntu2 (Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 13:33:46 +0200), qemu version: 5.2.0Debian 1:5.2+dfsg-9ubuntu3, kernel: 5.11.0-17-generic, hostname: green.in.graphica.com.au +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \ +HOME=/var/lib/libvirt/qemu/domain-10-hive-dev-freebsd-12. \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-10-hive-dev-freebsd-12./.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-10-hive-dev-freebsd-12./.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-10-hive-dev-freebsd-12./.config \ +QEMU_AUDIO_DRV=spice \ +/usr/bin/qemu-system-x86_64 \ +-name guest=hive-dev-freebsd-12.2,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10-hive-dev-freebsd-12./master-key.aes \ +-blockdev '{"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE_4M.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/home/jbh/Documents/virtual-machines/hive.dev.freebsd/OVMF_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ +-machine pc-q35-5.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,memory-backend=pc.ram \ +-cpu Broadwell-IBRS,vme=on,ss=on,vmx=on,pdcm=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaveopt=on,pdpe1gb=on,abm=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on \ +-m 4096 \ +-object memory-backend-ram,id=pc.ram,size=4294967296 \ +-overcommit mem-lock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid 459ff0b9-e0d1-44d4-9862-83315419eeee \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=32,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ +-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \ +-device pcie-pci-bridge,id=pci.7,bus=pci.1,addr=0x0 \ +-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 \ +-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d \ +-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \ +-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \ +-device ide-cd,bus=ide.0,id=sata0-0-0,bootindex=1 \ +-blockdev '{"driver":"file","filename":"/home/jbh/Documents/virtual-machines/hive.dev.freebsd/hive-hd1-01.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device ide-hd,bus=ide.1,drive=libvirt-1-format,id=sata0-0-1,bootindex=2 \ +-netdev tap,fd=35,id=hostnet0 \ +-device vmxnet3,netdev=hostnet0,id=net0,mac=52:54:00:c8:8b:95,bus=pci.7,addr=0x1 \ +-netdev tap,fd=36,id=hostnet1 \ +-device vmxnet3,netdev=hostnet1,id=net1,mac=52:54:00:6c:c9:c1,bus=pci.7,addr=0x2 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev spicevmc,id=charchannel0,name=vdagent \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ +-device usb-kbd,id=input2,bus=usb.0,port=3 \ +-spice port=5902,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \ +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \ +-chardev spicevmc,id=charredir0,name=usbredir \ +-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 \ +-chardev spicevmc,id=charredir1,name=usbredir \ +-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/2 (label charserial0) +KVM internal error. Suberror: 1 +emulation failure +RAX=0000000000000000 RBX=0000000000000000 RCX=0000000000000000 RDX=0000000000000f00 +RSI=0000000000000000 RDI=0000000000000000 RBP=0000000000000000 RSP=fffffe002d9f9700 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=ffffffff828fc5d9 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =003b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] +CS =0020 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0028 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =003b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] +FS =0013 0000000800b368d0 ffffffff 00c0f300 DPL=3 DS [-WA] +GS =001b ffffffff82611000 ffffffff 00c0f300 DPL=3 DS [-WA] +LDT=0000 0000000000000000 ffffffff 00c00000 +TR =0048 ffffffff81f15e08 00002068 00008b00 DPL=0 TSS64-busy +GDT= ffffffff81f1c608 00000067 +IDT= ffffffff81f14da0 00000fff +CR0=8005003b CR2=0000000000000000 CR3=0000000043b2b6ee CR4=003726e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +Code=50 4c 8b 67 58 4c 8b 6f 60 4c 8b 77 68 4c 8b 7f 70 48 8b 3f <0f> 01 c2 48 89 e7 b8 02 00 00 00 eb 07 b8 03 00 00 00 eb 00 41 bb 02 00 00 00 74 06 41 bb +2021-05-16T11:49:21.487500Z qemu-system-x86_64: terminating on signal 15 from pid 1885 (/usr/sbin/libvirtd) +2021-05-16 11:49:21.889+0000: shutting down, reason=destroyed +<<END>> + +So result is unchanged with update from: 20.04 -> 21.04 and FreeBSD 12.1 -> FreeBSD 12.2 + +NOTE: I also did testing of all 21.04 virtualization nesting: +Layer 0 - Ubuntu 21.04 +Layer 1 - Ubuntu 21.04 +Layer 2 - Ubuntu 21.04 +All Working OK !! + +Also Christian, I see your name in log: + +2021-05-16 09:57:28.970+0000: starting up libvirt version: 7.0.0, package: 2ubuntu2 (Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 13:33:46 +0200), qemu version: 5.2 + +Thanks for looking into this, please let me know if there is additional testing you would like to see. + +Cheers, + + +John. + + +Thanks for the test, that ensures it still is in 5.2 +Unfortunately since a few days that isn't the very most recent version [1] as 6.0 release two weeks ago. I don't have a 6.0 version ready as Ubuntu package yet that I could ask you to try. + +Usually for an upstream bug report (which IMHO is the right next step) you'd want to have confirmed that the last release is affected as well. So the question IMHO should now be - how do we get you a qemu 6.0 to try. +And if confirmed there the next step would be getting in touch with upstream at https://gitlab.com/qemu-project/qemu/-/issues + +How comfortable (or not) would you feel building your own qemu for a test? +It should be something like: +$ git clone git://git.qemu.org/qemu.git +$ sudo vim /etc/apt/sources.list +# edit sources.list to have "# deb-src" lines no more commented out +$ sudo apt update +$ sudo apt build-dep qemu +$ cd qemu +$ mkdir build +$ cd build +# you should need almost nothing for your test, so the following (or similar) should give you a quick build +$ ../configure --disable-werror --disable-user --disable-linux-user --disable-docs --disable-guest-agent --disable-sdl --disable-gtk --disable-vnc --disable-xen --disable-brlapi --disable-fdt --disable-bluez --disable-hax --disable-vde --disable-netmap --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-usb-redir --disable-seccomp --disable-glusterfs --disable-tpm --disable-numa --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-vxhs --disable-slirp --disable-blobs --target-list=x86_64-softmmu --disable-rdma --disable-pvrdma --disable-attr --disable-vhost-net --disable-vhost-vsock --disable-vhost-scsi --disable-vhost-crypto --disable-vhost-user --disable-spice --disable-qom-cast-debug --disable-vxhs --disable-bochs --disable-cloop --disable-dmg --disable-qcow1 --disable-vdi --disable-vvfat --disable-qed --disable-parallels --disable-sheepdog --disable-avx2 --disable-nettle --disable-gnutls --disable-capstone --enable-tools +$ make +$ sudo make install + +The above is untested writeup from memory (except the configure line, but that was for a different version) so expect some slight modifications to be needed. +You can then replace the qemu in your system (back it up) at /usr/bin/qemu-system-x86_64 with that new built version for a try. + +I'm currently rather busy, so the delay until I can provide a 6.0 might be a bit. But if you are unable to build your own you can surely wait for that to be ready. + +Or - also an alternative - you can report it upstream despite not having tested in on 6.0 yet. +They might ask for it then, but chances are that someone more familiar with acpi or bhyve immediately recognizes it and can help. +If you happen to do so please leave me a link to the issue here so I'm able to track it. + +[1]: https://wiki.qemu.org/Planning/6.0 + +Hi Christian, + +now I have env setup that test is pretty straight forward. + +Here are results: + +Build QEMU with following configuration: + +../configure --disable-werror --disable-user --disable-linux-user --disable-docs --disable-guest-agent --disable-sdl --disable-gtk --disable-vnc --disable-xen --disable-brlapi --disable-fdt --disable-hax --disable-vde --disable-netmap --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-usb-redir --disable-seccomp --disable-glusterfs --disable-tpm --disable-numa --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-slirp --disable-blobs --target-list=x86_64-softmmu --disable-rdma --disable-pvrdma --disable-attr --disable-vhost-net --disable-vhost-vsock --disable-vhost-scsi --disable-vhost-crypto --disable-vhost-user --disable-spice --disable-qom-cast-debug --disable-bochs --disable-cloop --disable-dmg --disable-qcow1 --disable-vdi --disable-vvfat --disable-qed --disable-parallels --disable-avx2 --disable-nettle --disable-gnutls --disable-capstone --enable-tools + +Version of QEMU SYSTEM: + +$ qemu-system-x86_64 --version +QEMU emulator version 6.0.50 (v6.0.0-540-g6005ee07c3) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +Result when running Layer 2 VM on FreeBSD bhyve Layer 1: + +Layer 1 VM goes into pause as per original test + +<<LIBVIRT LOG Layer 0 - Ubuntu Host>> +2021-05-17 12:31:09.748+0000: starting up libvirt version: 7.0.0, package: 2ubuntu2 (Christian Ehrhardt <email address hidden> Wed, 07 Apr 2021 13:33:46 +0200), qemu version: 5.2.0Debian 1:5.2+dfsg-9ubuntu3, kernel: 5.11.0-17-generic, hostname: green.in.graphica.com.au +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \ +HOME=/var/lib/libvirt/qemu/domain-3-hive-dev-freebsd-12. \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-hive-dev-freebsd-12./.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-hive-dev-freebsd-12./.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-hive-dev-freebsd-12./.config \ +QEMU_AUDIO_DRV=spice \ +/usr/bin/qemu-system-x86_64 \ +-name guest=hive-dev-freebsd-12.2,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-hive-dev-freebsd-12./master-key.aes \ +-blockdev '{"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE_4M.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/home/WHO//OVMF_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ +-machine pc-q35-5.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,memory-backend=pc.ram \ +-cpu Broadwell-IBRS,vme=on,ss=on,vmx=on,pdcm=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaveopt=on,pdpe1gb=on,abm=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on \ +-m 4096 \ +-object memory-backend-ram,id=pc.ram,size=4294967296 \ +-overcommit mem-lock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid 459ff0b9-e0d1-44d4-9862-83315419eeee \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=31,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ +-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \ +-device pcie-pci-bridge,id=pci.7,bus=pci.1,addr=0x0 \ +-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 \ +-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d \ +-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \ +-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \ +-device ide-cd,bus=ide.0,id=sata0-0-0,bootindex=1 \ +-blockdev '{"driver":"file","filename":"/home/WHO//VM-HD.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device ide-hd,bus=ide.1,drive=libvirt-1-format,id=sata0-0-1,bootindex=2 \ +-netdev tap,fd=33,id=hostnet0 \ +-device vmxnet3,netdev=hostnet0,id=net0,mac=52:54:00:c8:8b:95,bus=pci.7,addr=0x1 \ +-netdev tap,fd=34,id=hostnet1 \ +-device vmxnet3,netdev=hostnet1,id=net1,mac=52:54:00:6c:c9:c1,bus=pci.7,addr=0x2 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev spicevmc,id=charchannel0,name=vdagent \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ +-device usb-kbd,id=input2,bus=usb.0,port=3 \ +-device usb-tablet,id=input3,bus=usb.0,port=4 \ +-spice port=5901,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \ +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \ +-chardev spicevmc,id=charredir0,name=usbredir \ +-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 \ +-chardev spicevmc,id=charredir1,name=usbredir \ +-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/1 (label charserial0) +KVM internal error. Suberror: 1 +emulation failure +RAX=0000000000000000 RBX=0000000000000000 RCX=0000000000000000 RDX=0000000000000f00 +RSI=0000000000000000 RDI=0000000000000000 RBP=0000000000000000 RSP=fffffe002dc31700 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=ffffffff828fc5d9 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =003b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] +CS =0020 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0028 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =003b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] +FS =0013 0000000800b268d0 ffffffff 00c0f300 DPL=3 DS [-WA] +GS =001b ffffffff82611000 ffffffff 00c0f300 DPL=3 DS [-WA] +LDT=0000 0000000000000000 ffffffff 00c00000 +TR =0048 ffffffff81f15e08 00002068 00008b00 DPL=0 TSS64-busy +GDT= ffffffff81f1c608 00000067 +IDT= ffffffff81f14da0 00000fff +CR0=8005003b CR2=0000000000000000 CR3=00000000517b9152 CR4=003726e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +Code=50 4c 8b 67 58 4c 8b 6f 60 4c 8b 77 68 4c 8b 7f 70 48 8b 3f <0f> 01 c2 48 89 e7 b8 02 00 00 00 eb 07 b8 03 00 00 00 eb 00 41 bb 02 00 00 00 74 06 41 bb +2021-05-17T12:33:38.922639Z qemu-system-x86_64: terminating on signal 15 from pid 1871 (/usr/sbin/libvirtd) +2021-05-17 12:33:39.323+0000: shutting down, reason=destroyed +<<END LOG>> + +So looks like an upstream candidate. + +Cheers, + +John. + + +On Mon, May 17, 2021 at 3:01 PM John Hartley <email address hidden> wrote: +> +> Hi Christian, +> +> now I have env setup that test is pretty straight forward. + +Glad to hear that1 + +> $ qemu-system-x86_64 --version +> QEMU emulator version 6.0.50 (v6.0.0-540-g6005ee07c3) +... +> +> So looks like an upstream candidate. + +Yeah failing with this (latest release and no Ubuntu Delta applied) +certainly unlocks you to report it there. +As I said, once you do so it would be great to add a link here +pointing to the issue you've filed. + + +Hi Christian, + +I have posted issue to upstream QEMU + +https://gitlab.com/qemu-project/qemu/-/issues/337 + + +Thanks again for assistance / advise. + +Cheers from Oz, + +John. + diff --git a/results/classifier/zero-shot/108/permissions/1879425 b/results/classifier/zero-shot/108/permissions/1879425 new file mode 100644 index 000000000..fa22db9df --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1879425 @@ -0,0 +1,80 @@ +permissions: 0.963 +graphic: 0.941 +semantic: 0.938 +other: 0.920 +debug: 0.910 +performance: 0.853 +socket: 0.850 +PID: 0.846 +device: 0.845 +vnc: 0.838 +files: 0.785 +network: 0.744 +boot: 0.707 +KVM: 0.666 + +The thread of "CPU 0 /KVM" keeping 99.9%CPU + +Hi Expert: + +The VM is hung here after (2, or 3, or 5 and the longest time is 10 hours) by qemu-kvm. +Notes: +for VM: + OS: RHEL 7.6 + CPU: 1 + MEM:4G +For qemu-kvm: + 1) version: + /usr/libexec/qemu-kvm -version + QEMU emulator version 2.10.0(qemu-kvm-ev-2.10.0-21.el7_5.4.1) + 2) once the issue is occurred, the CPU of "CPU0 /KVM" is more than 99% by com "top -p VM_pro_ID" + PID UDER PR NI RES S % CPU %MEM TIME+ COMMAND +872067 qemu 20 0 1.6g R 99.9 0.6 37:08.87 CPU 0/KVM + 3) use "pstack 493307" and below is function trace +Thread 1 (Thread 0x7f2572e73040 (LWP 872067)): +#0 0x00007f256cad8fcf in ppoll () from /lib64/libc.so.6 +#1 0x000055ff34bdf4a9 in qemu_poll_ns () +#2 0x000055ff34be02a8 in main_loop_wait () +#3 0x000055ff348bfb1a in main () + 4) use strace "strace -tt -ff -p 872067 -o cfx" and below log keep printing +21:24:02.977833 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 0}, NULL, 8) = 0 (Timeout) +21:24:02.977918 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 911447}, NULL, 8) = 0 (Timeout) +21:24:02.978945 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=80, events=POLLIN}, {fd=82, events=POLLIN}, {fd=84, events=POLLIN}, {fd=115, events=POLLIN}, {fd=121, events=POLLIN}], 9, {0, 0}, NULL, 8) = 0 (Timeout) +Therefore, I think the thread "CPU 0/KVM" is in tight loop. + 5) use reset can recover this issue. however, it will reoccurred again. +Current work around is increase one CPU for this VM, then issue is gone. + +thanks +Cliff + +one changes: +Guest VM is Red Hat Enterprise Linux 8.1 (Ootpa). +there is no issue once guest VM is RHEL7.6. + +Appreciate any comments or clues + + +Can you try with a newer version of CentOS? I think there should be newer versions of qemu-kvm-ev available, so maybe the problem is gone there. +Otherwise, please either try to reproduce this problem with upstream QEMU, or report it to the CentOS bug tracker (https://bugs.centos.org/), since we do not provide support for distribution builds in the upstream QEMU project here. + +Hi Thomas, +Do you have any quick suggestion before report it on CentOS? + +thanks +Cliff + + + +I think you should definitely try a newer version if available - otherwise they'll likely refuse to help you, too (nobody wants to debug old versions when bugs are already fixed in newer ones) + +Got it! +BTW, you can confirm this is bug for qemu-kvm, right? + +thank you! +Cliff + +Add the ticket link in centos +https://bugs.centos.org/view.php?id=17385 + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1880539 b/results/classifier/zero-shot/108/permissions/1880539 new file mode 100644 index 000000000..0551545a1 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1880539 @@ -0,0 +1,58 @@ +permissions: 0.948 +semantic: 0.941 +debug: 0.941 +graphic: 0.935 +performance: 0.929 +device: 0.924 +other: 0.918 +PID: 0.918 +boot: 0.898 +vnc: 0.895 +network: 0.874 +files: 0.873 +socket: 0.858 +KVM: 0.855 + +I/O write make QXL abort in qxl_set_mode() + +libFuzzer found: + +qxl-0: guest bug: qxl_add_memslot: guest_start > guest_end 0xffffffffffffffff > 0x3ffffff +qemu-fuzz-i386: hw/display/qxl.c:1611: void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0' failed. +==8134== ERROR: libFuzzer: deadly signal + #0 0x55fddfcfb3f0 in __sanitizer_print_stack_trace (qemu-fuzz-i386+0xcb13f0) + #1 0x55fddfc0a3e1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0xbc03e1) + #2 0x55fddfbeac6f in fuzzer::Fuzzer::CrashCallback() (qemu-fuzz-i386+0xba0c6f) + #3 0x55fddfbeacc3 in fuzzer::Fuzzer::StaticCrashSignalCallback() (qemu-fuzz-i386+0xba0cc3) + #4 0x7fd640644c6f (/lib64/libpthread.so.0+0x12c6f) + #5 0x7fd640483e34 in __GI_raise (/lib64/libc.so.6+0x37e34) + #6 0x7fd64046e894 in __GI_abort (/lib64/libc.so.6+0x22894) + #7 0x7fd64046e768 in __assert_fail_base.cold (/lib64/libc.so.6+0x22768) + #8 0x7fd64047c565 in __GI___assert_fail (/lib64/libc.so.6+0x30565) + #9 0x55fde08afd8b in qxl_set_mode (qemu-fuzz-i386+0x1865d8b) + #10 0x55fde08b9602 in ioport_write (qemu-fuzz-i386+0x186f602) + #11 0x55fddff170a7 in memory_region_write_accessor (qemu-fuzz-i386+0xecd0a7) + #12 0x55fddff16c13 in access_with_adjusted_size (qemu-fuzz-i386+0xeccc13) + #13 0x55fddff157b4 in memory_region_dispatch_write (qemu-fuzz-i386+0xecb7b4) + +Can be reproduce doing "writeb 0x06 0x23" on QXL I/O (PCI BAR #3). + +Command line: 'qemu-system-i386 -display none -M pc -vga qxl' + +Here's a qtest reproducer for this: +cat << EOF | ./i386-softmmu/qemu-system-i386 -M q35,accel=qtest -qtest null -nographic -vga qxl -qtest stdio -nodefaults +outl 0xcf8 0x80000804 +outb 0xcfc 0xff +outl 0xcf8 0x80000819 +outl 0xcfc 0x87caff7a +outb 0x86 0x23 +EOF + + +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/232 + + diff --git a/results/classifier/zero-shot/108/permissions/1883984 b/results/classifier/zero-shot/108/permissions/1883984 new file mode 100644 index 000000000..773db521c --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1883984 @@ -0,0 +1,156 @@ +permissions: 0.943 +debug: 0.941 +semantic: 0.931 +performance: 0.925 +network: 0.925 +other: 0.924 +device: 0.915 +boot: 0.902 +PID: 0.902 +graphic: 0.902 +vnc: 0.900 +KVM: 0.877 +files: 0.866 +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/zero-shot/108/permissions/1884095 b/results/classifier/zero-shot/108/permissions/1884095 new file mode 100644 index 000000000..2f50da216 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1884095 @@ -0,0 +1,72 @@ +permissions: 0.925 +semantic: 0.923 +debug: 0.917 +graphic: 0.906 +device: 0.897 +other: 0.889 +performance: 0.884 +vnc: 0.855 +PID: 0.835 +boot: 0.815 +KVM: 0.811 +socket: 0.780 +files: 0.775 +network: 0.694 + +QEMU not sufficiently focused on qEMUlation, with resulting holes in TCG emulation coverage + +It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization. + +My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc. +Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward. + +If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. NeXTSTEP, Windows, earlier versions of MacOS on ARM Macs. + +Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal): + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +And this is emulating a lowly Penryn CPU with the required CPU flags for macOS: +-cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc + +Attempting to emulate a more feature laden intel CPU results in even more issues. + +I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on-native etc. are nice to have, but peripheral to qEMUlation when it boils down to it. At the very least, there should be a CLEAR distinction which CPUs require KVM to be used, and which can be fully emulated. It should not require wasting an afternoon to figure out that an emulation attempt is futile because TCG lacks essential functionality. + +You made this point already in comments in LP:1818075 (and got some responses there). This isn't a bug report, it's just a suggestion about what the project ought to prioritize. If you'd like to have that kind of discussion you can probably do better just starting a qemu-devel thread. + + +Oh, and cut-and-pasting the same long comment into multiple bug reports is not a good idea, so please don't do that. + + +The comments with the other reports were just in support of getting them fixed, and providing a reason as to why that matters. Someone looking at those reports may not read this one, and as the issues are symptoms of the same larger issue, this report was filed as an overarching report, as AVX is just one aspect. Depending on the CPU model picked, an entire slew of error messages are generated. + +Fact is, an emulator that claims it emulates a CPU has a bug, if that CPU cannot be properly emulated. Hence this report. + +For the emulator not to have to be considered buggy, +EITHER +the CPU type has to be delisted as supported +OR +the missing instructions must be implemented. + +But it’s not proper to say QEMU can emulate an x86_64 Penryn system, when trying to do so fails miserably because of instructions unimplemented in TGC. + +At the very least the documentation and online help would have to distinguish between KVM-only CPU types and TGC CPU types. + +Downloading and compiling QEMU 5 sources and compiling them on an ARM64 platform results in + +qemu-system-x86_64 -cpu help + +listing all sorts of CPUs as „available“ even though these have significant gaps in the covered instruction set. If that’s not a bug, I don’t know. + +How you go about fixing it, is a different matter. You could remove the CPUs, mark them as incompletely implemented, or add support for the missing features. +Maybe it might even be possible to interest intel to contribute code from their SDE project to TCG + +BTW: just because I bracket a report with why I think a matter is worth fixing, shouldn’t make it „invalid“. + +The instructions aren’t implemented, yet the CPUs are listed as available, which is a bug in my book, as functionality is advertised that is unavailable. + diff --git a/results/classifier/zero-shot/108/permissions/1884425 b/results/classifier/zero-shot/108/permissions/1884425 new file mode 100644 index 000000000..701e857a1 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1884425 @@ -0,0 +1,57 @@ +permissions: 0.925 +network: 0.898 +graphic: 0.897 +vnc: 0.885 +other: 0.871 +device: 0.850 +boot: 0.832 +files: 0.828 +performance: 0.817 +PID: 0.780 +semantic: 0.747 +KVM: 0.739 +socket: 0.709 +debug: 0.704 + +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/zero-shot/108/permissions/1884728 b/results/classifier/zero-shot/108/permissions/1884728 new file mode 100644 index 000000000..781b1e91f --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1884728 @@ -0,0 +1,88 @@ +permissions: 0.972 +graphic: 0.944 +device: 0.934 +debug: 0.931 +files: 0.927 +semantic: 0.916 +other: 0.913 +performance: 0.911 +vnc: 0.909 +network: 0.904 +PID: 0.898 +socket: 0.896 +KVM: 0.887 +boot: 0.857 + +facing build error for qemu-4.0.0 on SUSE11 OS + +I am trying to compile qemu-4.0.0 on suse11 OS and facing the following error on the console: +ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T. + You probably need to set PKG_CONFIG_LIBDIR + to point to the right pkg-config files for your + build target + +Looking into the config.log file following is the error that is listed: + +config-temp/qemu-conf.c:12:11: error: 'WACS_DEGREE' undeclared (first use in this function) + add_wch(WACS_DEGREE); + ^ +config-temp/qemu-conf.c:12:11: note: each undeclared identifier is reported only once for each function it appears in + +ld: skipping incompatible /usr/lib//libc.so when searching for -lc +ld: skipping incompatible /usr/lib//libc.a when searching for -lc +/tmp/ccmme6E4.o: In function `main': +qemu-conf.c:(.text+0x2b): undefined reference to `resize_term' +qemu-conf.c:(.text+0x32): undefined reference to `stdscr' +qemu-conf.c:(.text+0x49): undefined reference to `waddnwstr' +qemu-conf.c:(.text+0x50): undefined reference to `stdscr' +qemu-conf.c:(.text+0x67): undefined reference to `waddnwstr' +qemu-conf.c:(.text+0x6e): undefined reference to `_nc_wacs' +qemu-conf.c:(.text+0x7f): undefined reference to `stdscr' +qemu-conf.c:(.text+0x8d): undefined reference to `wadd_wch' +collect2: error: ld returned 1 exit status + +Following are the details of the tools versions: +OS version = SUSE Linux Enterprise Server 11 (x86_64) +python = v2.7.10 +glib = v2.56.1 +gcc = v4.8.3 +sdl2 = v2.0.12 + +Can someone help me understand the cause of this error? + +regards, +Harshit + + + +The part of the log you quote isn't the part which caused the failure. This bit is: + + +funcs: do_compiler do_cc compile_prog main +lines: 92 128 3672 0 +/grid/avs/install/xcelium/1803/latest//tools/cdsgcc/gcc/bin/64bit/gcc -pthread -I/grid/common/pkgs/glib/v2.56.1/include/glib-2.0 -I/grid/common/pkgs/glib/v2.56.1/lib/glib-2.0/include -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -fPIC -I/grid/cva/p4_04/harshitm/ltssm_sj/panda/dev/src//Xtor/include -Wendif-labels -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wno-missing-braces -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -L/grid/cva/p4_04/harshitm/ltssm_sj/panda/dev/src//Xtor/lib -L/usr/lib/ -pthread -L/grid/common/pkgs/glib/v2.56.1/lib -lgthread-2.0 -lrt -lglib-2.0 +ld: skipping incompatible /usr/lib//librt.so when searching for -lrt +ld: skipping incompatible /usr/lib//librt.a when searching for -lrt +ld: skipping incompatible /usr/lib//libpthread.so when searching for -lpthread +ld: skipping incompatible /usr/lib//libpthread.a when searching for -lpthread +ld: skipping incompatible /usr/lib//libc.so when searching for -lc +ld: skipping incompatible /usr/lib//libc.a when searching for -lc +/grid/common/pkgs/glib/v2.56.1/lib/libglib-2.0.so: undefined reference to `pthread_setname_np@GLIBC_2.12' +collect2: error: ld returned 1 exit status + + +That is, we tried to link against libglib, and it failed, because the compiler couldn't find a working pthread library. I see from your configure options that you're specifying a different C compiler and also different libraries: + +'--cc=/grid/avs/install/xcelium/1803/latest//tools/cdsgcc/gcc/bin/64bit/gcc' +'--extra-cflags=-I/grid/cva/p4_04/harshitm/ltssm_sj/panda/dev/src//Xtor/include' +'--extra-ldflags=-L/grid/cva/p4_04/harshitm/ltssm_sj/panda/dev/src//Xtor/lib' +'--extra-ldflags=-L/usr/lib/' +'--cxx=/usr/bin/g++' + +This is what's causing your problem -- the compile has picked up a version of libglib from whatever this /grid/ stuff is (/grid/common/pkgs/glib/v2.56.1/lib/libglib-2.0.so) but you're trying to get it to look for system libraries in /usr/lib when they are not compatible with the toolchain you're using (ld complains about them being incompatible). Trying to use this /grid/ gcc and the system g++ is probably not going to work very well either. + +I think you need to either: + (1) drop all this /grid/ tooling and use the system compiler and libraries to build QEMU + (2) don't try to use the system compiler and libraries at all, instead make sure you have all the libraries and tools you need in /grid/ (including the C++ compiler and the pthread library and the C library), and don't tell configure to add the system libraries to the search path + + diff --git a/results/classifier/zero-shot/108/permissions/1892581 b/results/classifier/zero-shot/108/permissions/1892581 new file mode 100644 index 000000000..65e9881c7 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1892581 @@ -0,0 +1,78 @@ +permissions: 0.960 +files: 0.950 +graphic: 0.902 +KVM: 0.888 +device: 0.886 +debug: 0.872 +other: 0.863 +semantic: 0.855 +performance: 0.833 +network: 0.832 +socket: 0.814 +PID: 0.800 +vnc: 0.766 +boot: 0.717 + +QEMU 5.1 no longer says anything about inaccessible devices + +Previously, with QEMU 5.0.0 running a VM with the following command: + +$ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb-host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio + +Would display something like the following: + +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied +libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied +libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. + +With insufficient permissions. + +QEMU 5.1.0 no longer displays anything. + +I did a git bisect and this is the result: + +[diego@thinkpad qemu]$ git bisect bad +9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit +commit 9f815e83e983d247a3cd67579d2d9c1765adc644 +Author: Gerd Hoffmann <email address hidden> +Date: Fri Jun 5 14:59:52 2020 +0200 + + usb: add hostdevice property to usb-host + + The new property allows to specify usb host device name. Uses standard + qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) + and file descriptor passing can be used. + + Requires libusb 1.0.23 or newer. The hostdevice property is only + present in case qemu is compiled against a new enough library version, + so the presence of the property can be used for feature detection. + + Signed-off-by: Gerd Hoffmann <email address hidden> + Message-Id: <email address hidden> + + hw/usb/host-libusb.c | 75 ++++++++++++++++++++++++++++++++++++++++++---------- + hw/usb/trace-events | 1 + + 2 files changed, 62 insertions(+), 14 deletions(-) +[diego@thinkpad qemu]$ + + + +The previous commit is fine, it displays the USB errors: + +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied +libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied +libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. + + +My system is Arch Linux. + +Not sure this is a bug. + +I was changing the /dev file permissions based on the output from above, that's why I decided to submit this bug report. + +Either way, the output from lsusb works too. + +I no longer need this (it's no longer an issue for me), feel free to reopen if this issue affects you. + diff --git a/results/classifier/zero-shot/108/permissions/1892684 b/results/classifier/zero-shot/108/permissions/1892684 new file mode 100644 index 000000000..afe754927 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1892684 @@ -0,0 +1,72 @@ +permissions: 0.924 +graphic: 0.890 +other: 0.860 +files: 0.745 +device: 0.742 +performance: 0.688 +PID: 0.671 +network: 0.665 +semantic: 0.657 +vnc: 0.587 +KVM: 0.528 +debug: 0.500 +socket: 0.499 +boot: 0.366 + +curl and wget segfaults when link has redirects + +Hello, + +I've been using qemu-user-static with aarch64 docker images and faced the problem +using binares from the following release: https://github.com/multiarch/qemu-user-static/releases/tag/v5.0.0-2. + +curl and wget fails with segmentation fault when trying to fetch something from the link +that has some redirects. + +In order to reproduce you can run the following: + +1) Register qemu on x86_64 machine + docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +2) Run arm64v8 docker image and try to run wget or curl + docker run --rm -it arm64v8/ubuntu bash + $ apt update + $ apt install curl wget + $ curl -L http://erratique.ch/software/astring/releases/astring-0.8.3.tbz + $ wget http://erratique.ch/software/astring/releases/astring-0.8.3.tbz + +This error cannot be reproduced with binaries from eariler release https://github.com/multiarch/qemu-user-static/releases/tag/v4.2.0-7. +curl and wget work fine with the given link and don't fail with segfault when using +older qemu-user-static binaries + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1893040 b/results/classifier/zero-shot/108/permissions/1893040 new file mode 100644 index 000000000..eafb06fd8 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1893040 @@ -0,0 +1,312 @@ +permissions: 0.941 +device: 0.932 +other: 0.926 +graphic: 0.873 +semantic: 0.869 +debug: 0.865 +PID: 0.855 +performance: 0.855 +network: 0.845 +files: 0.745 +boot: 0.680 +KVM: 0.677 +vnc: 0.610 +socket: 0.426 + + External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues + +We are observing issue while building go-runner image and we suspect it is due to QEMU version being used. As referred in below issue: +https://github.com/golang/go/issues/40949 + +We tried to build go-runner image using go1.15 and register QEMU (docker run --rm --privileged multiarch/qemu-user-static@sha256:c772ee1965aa0be9915ee1b018a0dd92ea361b4fa1bcab5bbc033517749b2af4 --reset -p yes) as mentioned in PR https://github.com/kubernetes/release/pull/1499. We observed below failure during build: + +------------------------------------------------------------------------------------------------------------- +ERROR: executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc did not terminate successfully +------ + > [builder 7/7] RUN CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner .: +------ +failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc did not terminate successfully +Makefile:52: recipe for target 'container' failed +make: *** [container] Error 1 +------------------------------------------------------------------------------------------------------------- + +> We are observing issue while building go-runner image and we suspect it is due to QEMU version +> being used. As referred in below issue: +> https://github.com/golang/go/issues/40949 + +This issue says the problem was due to https://bugs.launchpad.net/qemu/+bug/1847232/ which was fixed in QEMU 4.2. The commenters there say to try using this newer QEMU to see if it fixes it, and I don't see any confirmation that this has been tried yet. + +IOW, please test with latest QEMU and report back if the problem still occurrs. + +Yes we have observed that the issue persist in later QEMU version too. + +Can you provide a *simple* way to demonstrate the problem. ie some simple Go demo program, that doens't involve building kubernetes. + +We followed below steps to reproduce the error: + +1) Create new folder +$ mkdir -p example.com/hello +$ cd example.com/hello + +2) Create file hello.go as below; +$ cat hello.go +package main +import ( + "fmt" + "rsc.io/quote" +) +func main() { + fmt.Println(quote.Hello()) +} + +3) Create file go.mod as below +$ cat go.mod +module example.com/hello +go 1.15 + +4) Create Dockerfile as below: +$ cat Dockerfile +# Build the manager binary +FROM golang:1.15 +WORKDIR /workspace +# Copy the sources +COPY hello.go ./ +COPY go.mod ./ +# Allow fallback to 'direct' for GOPROXY +# +# The GOPROXY environment variable now supports skipping proxies that return +# errors. Proxy URLs may now be separated with either commas (,) or pipe +# characters (|). If a proxy URL is followed by a comma, the go command will +# only try the next proxy in the list after a 404 or 410 HTTP response. If a +# proxy URL is followed by a pipe character, the go command will try the next +# proxy in the list after any error. Note that the default value of GOPROXY +# remains https://proxy.golang.org,direct, which does not fall back to direct +# in case of errors. +# +# ref: https://golang.org/doc/go1.15#go-command +ENV GOPROXY="https://proxy.golang.org|direct" +RUN go env + +# Cache the go build +RUN go build . + +5) Register QEMU and create buildx instance +$ docker run --rm --privileged multiarch/qemu-user-static@sha256:c772ee1965aa0be9915ee1b018a0dd92ea361b4fa1bcab5bbc033517749b2af4 --reset -p yes +$ docker buildx create --name multiarch-go-runner --use + +6) Error observed while building image +$ docker buildx build --load --progress plain --platform linux/s390x -t go_chk3 . +#1 [internal] booting buildkit +#1 pulling image moby/buildkit:buildx-stable-1 +#1 pulling image moby/buildkit:buildx-stable-1 1.4s done +#1 creating container buildx_buildkit_multiarch-go-runner0 +#1 creating container buildx_buildkit_multiarch-go-runner0 1.3s done +#1 DONE 2.7s +#2 [internal] load .dockerignore +#2 transferring context: 2B done +#2 DONE 0.1s +#3 [internal] load build definition from Dockerfile +#3 transferring dockerfile: 1.50kB done +#3 DONE 0.1s +#4 [internal] load metadata for docker.io/library/golang:1.15 +#4 DONE 4.1s +#7 [internal] load build context +#7 transferring context: 206B done +#7 DONE 0.1s +#5 [1/6] FROM docker.io/library/golang:1.15@sha256:4c3279e05a0131c0565466ac... +#5 resolve docker.io/library/golang:1.15@sha256:4c3279e05a0131c0565466ac538755f104d8d936efbc4c30ba7d717c73f3e2c2 done +#5 sha256:4c3279e05a0131c0565466ac538755f104d8d936efbc4c30ba7d717c73f3e2c2 2.36kB / 2.36kB done +#5 sha256:c5e175e434734f93e9b75f245f05578e7a12cedffed20cae845f57a3c7139b95 0B / 155B 0.1s +#5 sha256:f2b199a6d9adcfa5f879ec8042306ab2f919623f8018d0d7a6f4e9dade5e1a71 0B / 48.97MB 0.1s +#5 sha256:5615f13ce6c82698ac5df02b39113e3a8949db1a7a7f7f5d07c9265ee15b79d0 0B / 7.39MB 0.1s +#5 sha256:8ee3c4544ee6e2d4cd23f1b47d6fde1775c25fab9a77851b118074afa00c9f4f 1.79kB / 1.79kB done +#5 sha256:356049cf27ce547d544a426484dee88b17a1abb2c51e359a15c3565b2f0d33f0 6.18kB / 6.18kB done +#5 sha256:23ffecb808bd421be3db88ff08f67b19f28c1ffe0d4c157be3fcff3360f527bc 0B / 9.88MB 0.1s +#5 sha256:e060fbdc544cffa8f72ebc5c629d0fd77e9f0ea787a2eec80f4a77dd0833d747 0B / 56.74MB 0.1s +#5 sha256:44e2ce491a55134d5e4118405670fcc19b140898dc8ac62156e47a49f52e9f2d 0B / 51.38MB 0.3s +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 0B / 101.17MB 0.3s +#5 sha256:c5e175e434734f93e9b75f245f05578e7a12cedffed20cae845f57a3c7139b95 155B / 155B 1.6s done +#5 sha256:5615f13ce6c82698ac5df02b39113e3a8949db1a7a7f7f5d07c9265ee15b79d0 3.16MB / 7.39MB 1.8s +#5 sha256:23ffecb808bd421be3db88ff08f67b19f28c1ffe0d4c157be3fcff3360f527bc 1.75MB / 9.88MB 1.8s +#5 sha256:f2b199a6d9adcfa5f879ec8042306ab2f919623f8018d0d7a6f4e9dade5e1a71 19.48MB / 48.97MB 2.1s +#5 sha256:5615f13ce6c82698ac5df02b39113e3a8949db1a7a7f7f5d07c9265ee15b79d0 7.39MB / 7.39MB 1.9s done +#5 sha256:23ffecb808bd421be3db88ff08f67b19f28c1ffe0d4c157be3fcff3360f527bc 9.88MB / 9.88MB 1.9s done +#5 sha256:e060fbdc544cffa8f72ebc5c629d0fd77e9f0ea787a2eec80f4a77dd0833d747 20.79MB / 56.74MB 2.1s +#5 sha256:44e2ce491a55134d5e4118405670fcc19b140898dc8ac62156e47a49f52e9f2d 19.40MB / 51.38MB 2.1s +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 19.54MB / 101.17MB 2.1s +#5 sha256:f2b199a6d9adcfa5f879ec8042306ab2f919623f8018d0d7a6f4e9dade5e1a71 37.71MB / 48.97MB 2.4s +#5 sha256:e060fbdc544cffa8f72ebc5c629d0fd77e9f0ea787a2eec80f4a77dd0833d747 35.35MB / 56.74MB 2.4s +#5 sha256:44e2ce491a55134d5e4118405670fcc19b140898dc8ac62156e47a49f52e9f2d 38.91MB / 51.38MB 2.4s +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 39.22MB / 101.17MB 2.4s +#5 sha256:f2b199a6d9adcfa5f879ec8042306ab2f919623f8018d0d7a6f4e9dade5e1a71 45.15MB / 48.97MB 2.5s +#5 sha256:e060fbdc544cffa8f72ebc5c629d0fd77e9f0ea787a2eec80f4a77dd0833d747 43.24MB / 56.74MB 2.5s +#5 sha256:44e2ce491a55134d5e4118405670fcc19b140898dc8ac62156e47a49f52e9f2d 47.92MB / 51.38MB 2.5s +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 48.30MB / 101.17MB 2.5s +#5 sha256:f2b199a6d9adcfa5f879ec8042306ab2f919623f8018d0d7a6f4e9dade5e1a71 48.97MB / 48.97MB 2.7s done +#5 sha256:e060fbdc544cffa8f72ebc5c629d0fd77e9f0ea787a2eec80f4a77dd0833d747 56.74MB / 56.74MB 2.8s +#5 sha256:44e2ce491a55134d5e4118405670fcc19b140898dc8ac62156e47a49f52e9f2d 51.38MB / 51.38MB 2.7s done +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 66.70MB / 101.17MB 2.8s +#5 sha256:e060fbdc544cffa8f72ebc5c629d0fd77e9f0ea787a2eec80f4a77dd0833d747 56.74MB / 56.74MB 3.0s done +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 77.91MB / 101.17MB 3.0s +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 88.63MB / 101.17MB 3.1s +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 99.91MB / 101.17MB 3.3s +#5 sha256:69157c3b9bc7dad5a676fdc6700b95a1a9dbcffc7ccfb7cd20d91f16be6e9ffd 101.17MB / 101.17MB 3.6s done +#5 unpacking docker.io/library/golang:1.15@sha256:4c3279e05a0131c0565466ac538755f104d8d936efbc4c30ba7d717c73f3e2c2 +#5 unpacking docker.io/library/golang:1.15@sha256:4c3279e05a0131c0565466ac538755f104d8d936efbc4c30ba7d717c73f3e2c2 17.8s done +#5 DONE 22.8s +#6 [2/6] WORKDIR /workspace +#6 DONE 2.6s +#8 [3/6] COPY hello.go ./ +#8 DONE 0.2s +#9 [4/6] COPY go.mod ./ +#9 DONE 0.1s +#10 [5/6] RUN go env +#10 1.711 GO111MODULE="" +#10 1.711 GOARCH="s390x" +#10 1.711 GOBIN="" +#10 1.711 GOCACHE="/root/.cache/go-build" +#10 1.711 GOENV="/root/.config/go/env" +#10 1.711 GOEXE="" +#10 1.711 GOFLAGS="" +#10 1.711 GOHOSTARCH="s390x" +#10 1.712 GOHOSTOS="linux" +#10 1.712 GOINSECURE="" +#10 1.712 GOMODCACHE="/go/pkg/mod" +#10 1.712 GONOPROXY="" +#10 1.712 GONOSUMDB="" +#10 1.712 GOOS="linux" +#10 1.712 GOPATH="/go" +#10 1.713 GOPRIVATE="" +#10 1.713 GOPROXY="https://proxy.golang.org|direct" +#10 1.713 GOROOT="/usr/local/go" +#10 1.713 GOSUMDB="sum.golang.org" +#10 1.713 GOTMPDIR="" +#10 1.713 GOTOOLDIR="/usr/local/go/pkg/tool/linux_s390x" +#10 1.713 GCCGO="gccgo" +#10 1.713 AR="ar" +#10 1.713 CC="s390x-linux-gnu-gcc" +#10 1.713 CXX="g++" +#10 1.713 CGO_ENABLED="1" +#10 1.713 GOMOD="/workspace/go.mod" +#10 1.714 CGO_CFLAGS="-g -O2" +#10 1.714 CGO_CPPFLAGS="" +#10 1.714 CGO_CXXFLAGS="-g -O2" +#10 1.714 CGO_FFLAGS="-g -O2" +#10 1.714 CGO_LDFLAGS="-g -O2" +#10 1.714 PKG_CONFIG="pkg-config" +#10 1.714 GOGCCFLAGS="-fPIC -m64 -march=z196 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build803398483=/tmp/go-build -gno-record-gcc-switches" +#10 DONE 1.8s +#11 [6/6] RUN go build . +#11 0.567 go: finding module for package rsc.io/quote +#11 8.056 go: downloading rsc.io/quote v1.5.2 +#11 9.080 hello.go:5:5: <email address hidden>: verifying module: <email address hidden>: Get "https://<email address hidden>": tls: invalid signature by the server certificate: ECDSA verification failure +#11 ERROR: executor failed running [/bin/sh -c go build .]: buildkit-runc did not terminate successfully +------ + > [6/6] RUN go build .: +------ +failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c go build .]: buildkit-runc did not terminate successfully + + +I remember we had these "ECDSA verification failure" issues in older QEMU versions, but these were fixed. + +I just tired building the go file under Fedora 32 running under latest upstream qemu-system-s390x, and using latest go binaries from https://golang.org/dl/: + +[root@atomic-00 hello]# 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 hello]# go version +go version go1.15.7 linux/s390x + +[root@atomic-00 hello]# go build +go: downloading rsc.io/quote v1.5.2 +go: downloading rsc.io/sampler v1.3.0 +go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c + +[root@atomic-00 hello]# ./hello +Hello, world. + +Can you double check that you are really using latest upstream QEMU in your more-advanced cross-build? + +we still observe the same failure even after using latest qemu image i.e https://hub.docker.com/layers/multiarch/qemu-user-static/latest/images/sha256-14ef83[…]27699811f89338b129faa3bd9eb52cd696bc3d84aa81a?context=explore + +I started looking at the issue.Could reproduce issue with steps mentioned in comment #4 +@David Hildenbrand (davidhildenbrand) could you please let me know what exact qemu version/image you used? and you followed exact steps as mentioned in comment #4? + +Any update? + +It's still an issue using qemu-6.0.0-rc4. If you remove the environment variable ENV GOPROXY="https://proxy.golang.org|direct" you get a different error: + + => ERROR [6/6] RUN go build . 5.8s +------ + > [6/6] RUN go build .: +#10 0.854 go: finding module for package rsc.io/quote +#10 4.138 fatal error: grew heap, but no adequate free space found +#10 4.159 +#10 4.159 runtime stack: +#10 4.163 runtime.throw(0x62abce, 0x2b) +#10 4.172 /usr/local/go/src/runtime/panic.go:1116 +0x70 +#10 4.183 runtime.(*mheap).allocSpan(0x9d5c60, 0x10000, 0x100000000000000, 0x9f1920, 0x96c720) +#10 4.199 /usr/local/go/src/runtime/mheap.go:1166 +0x896 + + + +Hello @davidhildenbrand, I have been looking into this bug recently. So far, I noticed a few things: + +1: Similarly as described in comment #5, I also had success building the go file described in the reproducing steps in #4 using Ubunutu-20.04 with recent qemu-system-s390x (I did it 1 - 2 weeks ago, so it is likely qemu-6.0rc2 or rc3) + +2: Similarly as described in commment #9, when qemu-user-static is used, there are "ECDSA verification failure". The failure is using multiarch/qemu-user-static with qemu-s390x 6.0.0-rc3 statically built from source and copied in when building the container + +3: Debugging in a container has been really difficult for me, so I used chroot and debootstrap to emulate a full s390x file system on a x86 host and copy the qemu-s390x binary in. I find that I can still reproduce the error similarly as the container. However, I also find that if I turn the vector instruction off with vx=off and split the go command into multiple steps, I am no longer able to reproduce the error. The reason for splitting the commands is that it looks like go build first calls go mod tidy, then calls go tool compile to compile the program. Through experimentation, those appear to call some other binary so the vx=off is dropped. + +———————————— Build steps ———————————— +root@skewered1:~/example.com/hello# ls +go.mod hello.go +root@skewered1:~/example.com/hello# vim go.mod +root@skewered1:~/example.com/hello# ls +go.mod hello.go +root@skewered1:~/example.com/hello# uname -a +Linux xxx (hidden) 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 s390x GNU/Linux +root@skewered1:~/example.com/hello# file /usr/bin/qemu-s390x-6.0rc5-static +/usr/bin/qemu-s390x-6.0rc5-static: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, Bui +ldID[sha1]=28d90b247aa25813da5b24d07707863f089a78eb, for GNU/Linux 3.2.0, stripped +root@skewered1:~/example.com/hello# /usr/bin/qemu-s390x-6.0rc5-static --version +qemu-s390x version 5.2.95 (v6.0.0-rc5) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +root@skewered1:~/example.com/hello# +root@skewered1:~/example.com/hello# go version + +go version go1.15.11 linux/s390x +root@skewered1:~/example.com/hello# +root@skewered1:~/example.com/hello# which go +/usr/local/go/bin/go +root@skewered1:~/example.com/hello# /usr/bin/qemu-s390x-6.0rc5-static /usr/local/go/bin/go build . +go: finding module for package rsc.io/quote +hello.go:4:5: module rsc.io/quote: Get "https://proxy.golang.org/rsc.io/quote/@v/list": tls: invalid signature by the server certificate: ECDSA verification failure +root@skewered1:~/example.com/hello# /usr/bin/qemu-s390x-6.0rc5-static -cpu qemu,vx=off /usr/local/go/bin/go mod tidy +go: finding module for package rsc.io/quote +go: downloading rsc.io/quote v1.5.2 +go: found rsc.io/quote in rsc.io/quote v1.5.2 +go: downloading rsc.io/sampler v1.3.0 +go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c +root@skewered1:~/example.com/hello# /usr/bin/qemu-s390x-6.0rc5-static -cpu qemu,vx=off /usr/local/go/bin/go build . +root@skewered1:~/example.com/hello# ls +go.mod go.sum hello hello.go +root@skewered1:~/example.com/hello# file hello +hello: ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), statically linked, not stripped +root@skewered1:~/example.com/hello# ./hello +Hello, world. + +4: The above findings make me think that there is some discrepancy between vector instructions handling for qemu user mode vs system mode. Additionally, running tests with vx=off in go/src/crypto/ecdsa will make the test pass while without vx=off, there remains to be a problem. Currently, I am looking into the go source code hoping to narrow down the problem. It looks like the difference (between qemu-user and s390x native host) happens during initTable() function at crypto/elliptic/p256_s390x.go. + +I hope the above findings make sense. It will be great if you can share some possible insights for where that discrepancy (between qemu-user and qemu-system) could be. Much appreciated. + + + + +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/281 + + diff --git a/results/classifier/zero-shot/108/permissions/1894781 b/results/classifier/zero-shot/108/permissions/1894781 new file mode 100644 index 000000000..41aff3af9 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1894781 @@ -0,0 +1,144 @@ +semantic: 0.953 +permissions: 0.951 +debug: 0.940 +network: 0.938 +other: 0.938 +PID: 0.931 +graphic: 0.927 +performance: 0.924 +device: 0.922 +boot: 0.907 +files: 0.839 +socket: 0.819 +KVM: 0.766 +vnc: 0.705 + +[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/zero-shot/108/permissions/1895053 b/results/classifier/zero-shot/108/permissions/1895053 new file mode 100644 index 000000000..cec4cd694 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1895053 @@ -0,0 +1,385 @@ +permissions: 0.952 +debug: 0.934 +other: 0.930 +device: 0.916 +semantic: 0.910 +boot: 0.909 +performance: 0.899 +network: 0.897 +PID: 0.891 +graphic: 0.889 +vnc: 0.865 +files: 0.857 +socket: 0.848 +KVM: 0.782 + +Cannot nspawn raspbian 10 [FAILED] Failed to start Journal Service. + +Hi, I'm using nspawn and asked the question @systemd-devel. They redirected me to you, guessing that nspawn calls a syscall or ioctl qemu isnt aware of and can't implement properly? +They were like: "Sorry, that's not my department." ^^ + +Maybe you can reproduce the issue or help me investigating whats wrong or put the ball right back into their court? :D + +From: "chiasa.men" <email address hidden> +To: <email address hidden> +Date: 09.09.20 14:20 +(cf. https://github.com/systemd/systemd/issues/16975) + +Testscript: +wget https://downloads.raspberrypi.org/raspios_lite_armhf_latest -o r.zip +unzip r.zip +LOOP=$(losetup --show -Pf *raspios-buster-armhf-lite.img) +mount ${LOOP}p2 /mnt +mount ${LOOP}p1 /mnt/boot +systemd-nspawn --bind /usr/bin/qemu-arm-static --boot --directory=/mnt -- systemd.log_level=debug + + +Output: +see attachment + +System: +uname -a +Linux MArch 5.8.7-arch1-1 #1 SMP PREEMPT Sat, 05 Sep 2020 12:31:32 +0000 +x86_64 GNU/Linux + +systemd-nspawn --version +systemd 246 (246.4-1-arch) ++PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP ++GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN ++PCRE2 default-hierarchy=hybrid + + + +Could you try with the patch attached to bug 1823790? + + https://bugs.launchpad.net/qemu/+bug/1823790/+attachment/5405549/+files/SO_PEERGROUPS.patch + +Thanks for the quick response! +I tried the whole day to get the PKGBUILD working... + +Your patch doesnt fix the issue though - see attached log + +can you reproduce the bug locally or is this a client problem? + +Le 10/09/2020 à 18:19, Petunia a écrit : +> can you reproduce the bug locally or is this a client problem? +> + +I didn't try but I will as you describe it clearly. + + +I'm sorry, it works fine for me on Fedora 32 with qemu built from GIT v5.1.0. + +$ uname -r +5.8.4-200.fc32.x86_64 + +wget https://downloads.raspberrypi.org/raspios_lite_armhf_latest +mv raspios_lite_armhf_latest raspios_lite_armhf_latest.zip +unzip raspios_lite_armhf_latest.zip +modprobe loop max_part=8 +mkdir root +sudo losetup -f 2020-08-20-raspios-buster-armhf-lite.img +sudo mount /dev/loop0p2 root +sudo mount /dev/loop0p1 root/boot +sudo systemd-nspawn -D root --boot --bind $HOME/Objects/qemu/linux-user/qemu-arm:/qemu-arm +Spawning container root on /raspios/root. +Press ^] three times within 1s to kill container. +systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) +Detected virtualization systemd-nspawn. +Detected architecture arm. + +Welcome to Raspbian GNU/Linux 10 (buster)! +.... +Raspbian GNU/Linux 10 raspberrypi console +raspberrypi login: pi +Password: +Last login: Thu Sep 10 19:40:15 CEST 2020 on pts/0 +Linux raspberrypi 5.8.4-200.fc32.x86_64 #1 SMP Wed Aug 26 22:28:08 UTC 2020 armv7l + +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. +pi@raspberrypi:~ $ /qemu-arm -version +qemu-arm version 5.1.0 (v5.1.0) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +pi@raspberrypi:~ $ + + + + +Perhaps the problem is triggered by the host systemd version as I have: + +$ systemd-nspawn --version +systemd 245 (v245.7-1.fc32) ++PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified + + +mhm thats somehow unfortunate since I dont know in what direction I would have to go to solve the issue :/ + +I tried 245.7 but without success. + +Do you maybe have an idea on how to investigate further? +Is this some kind of distribution problem? What is the actual problem anyway? + +We can try to see what is failing by enabling qemu strace. +To do that, I don't know a better solution than using a wrapper. + +Once /mnt is mounted, copy qemu-arm-static inside with a new name: + + sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin/qemu-arm-org + +Then create the wrapper: + +cat > qemu-wrapper.c <<EOF +#include <stdio.h> +#include <unistd.h> +#include <string.h> + +static const char *baseargv[] = { + "-strace", +}; + +int main(int argc, char **argv, char **envp) { + char *newargv[argc + sizeof(baseargv) / sizeof(char *) + 1]; + int current = 0; + + newargv[current] = argv[0]; + current++; + + memcpy(&newargv[current], baseargv, sizeof(baseargv)); + current += sizeof(baseargv) / sizeof(char *); + + memcpy(&newargv[current], &argv[1], sizeof(*argv) * (argc - 1)); + current += argc - 1; + + newargv[current] = NULL; + + return execve("/usr/bin/qemu-arm-org", newargv, envp); +} +EOF + cc --static -o qemu-wrapper qemu-wrapper.c + + sudo cp qemu-wrapper /mnt/usr/bin/qemu-arm-static + +And then: + + systemd-nspawn --boot --directory=/mnt + +Hi thanks i ran the above, but where is the strace stored? its neither in the console output nor journalctl + +Normally, they are on the standard output, something like: + +$ sudo systemd-nspawn -D root --boot +Spawning container root on /mnt. +Press ^] three times within 1s to kill container. +1 brk(NULL) = 0x4013f000 +1 uname(0x3ffffa00) = 0 +1 access("/etc/ld.so.preload",R_OK) = 0 +1 openat(AT_FDCWD,"/etc/ld.so.preload",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4 +1 fstat64(4,0x3ffffb38) = 0 +1 mmap2(NULL,54,PROT_READ|PROT_WRITE,MAP_PRIVATE,4,0) = 0x3f7cc000 +1 close(4) = 0 +1 readlink("/proc/self/exe",0x3fffe6f0,4096) = 2 +... + +Check the content of /mnt/usr/bin, you must have "qemu-arm" and "qemu-arg-org". + +You can try "sudo chroot /mnt" to see if you have some traces. + +Mhm, that doesnt work for me. My output is unchanged... + +file /mnt/usr/bin/qemu-arm-* +/mnt/usr/bin/qemu-arm-org: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, stripped +/mnt/usr/bin/qemu-arm-static: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=041f10cff5eeffbbaf3fc7acb3c53db76a52991c, for GNU/Linux 3.2.0, not stripped + +sudo systemd-nspawn --boot --directory=/mnt/ +Spawning container virtual1 on /mnt. +Press ^] three times within 1s to kill container. +systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) +Detected virtualization systemd-nspawn. +Detected architecture arm. + +Welcome to Raspbian GNU/Linux 10 (buster)! + + +How would the be called anyway? Some internal mechanism? + + +sudo chroot /mnt/virtual1 /bin/bash +/usr/bin/file /usr/bin/qemu-arm-* +/usr/bin/qemu-arm-org: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped +/usr/bin/qemu-arm-static: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=041f10cff5eeffbbaf3fc7acb3c53db76a52991c, for GNU/Linux 3.2.0, not stripped + + +But no traces either - i feel retarded :D + +What is the result of the following command? + +for file in /proc/sys/fs/binfmt_misc/* ; do echo "$file"; cat $file; done + + +for file in /proc/sys/fs/binfmt_misc/* ; do echo "$file"; LANG=C cat $file; done +/proc/sys/fs/binfmt_misc/aarch64 +enabled +interpreter /usr/bin/qemu-aarch64-static +flags: OCF +offset 0 +magic 7f454c460201010000000000000000000200b7 +mask ffffffffffffff00fffffffffffffffffeffff +/proc/sys/fs/binfmt_misc/arm +enabled +interpreter /usr/bin/qemu-arm-static +flags: OCF +offset 0 +magic 7f454c4601010100000000000000000002002800 +mask ffffffffffffff00fffffffffffffffffeffffff +/proc/sys/fs/binfmt_misc/armeb +enabled +interpreter /usr/bin/qemu-armeb-static +flags: OCF +offset 0 +magic 7f454c4601020100000000000000000000020028 +mask ffffffffffffff00fffffffffffffffffffeffff +/proc/sys/fs/binfmt_misc/CLR +enabled +interpreter /usr/bin/mono +flags: +offset 0 +magic 4d5a +/proc/sys/fs/binfmt_misc/DOSWin +enabled +interpreter /usr/bin/wine +flags: +offset 0 +magic 4d5a +/proc/sys/fs/binfmt_misc/register +cat: /proc/sys/fs/binfmt_misc/register: Permission denied +/proc/sys/fs/binfmt_misc/status +enabled + +Could this be related to bug 1892604? Although I don't know how Laurent would not be seeing the +problem. + +tldr: i dont have the same issue as described in your bug +see my post there: +https://bugs.launchpad.net/qemu/+bug/1892604/comments/6 + + +I take back everything and claim the opposite... same error as bug reporter + +Le 15/09/2020 à 00:03, Petunia a écrit : +> for file in /proc/sys/fs/binfmt_misc/* ; do echo "$file"; LANG=C cat $file; done +... +> /proc/sys/fs/binfmt_misc/arm +> enabled +> interpreter /usr/bin/qemu-arm-static +> flags: OCF +> offset 0 +> magic 7f454c4601010100000000000000000002002800 +> mask ffffffffffffff00fffffffffffffffffeffffff + +'F'[1] flags means the interpreter is loaded from your host: +your "--bind" arg is not needed and the file I asked you to copy inside +the container is not used. + +So to enable the traces, the easier way to do is to rename the file +directly on the host and to reload the configuration (but warning, if +you have other containers running they will be also run with trace): + +sudo mv /usr/bin/qemu-arm-static /usr/vib/qemu-arm-org +sudo cp qemu-wrapper /usr/bin/qemu-arm-static +sudo systemctl restart systemd-binfmt.service +systemd-nspawn --boot --directory=/mnt + +[1] linux/Documentation/admin-guide/binfmt-misc.rst + +``F`` - fix binary + The usual behaviour of binfmt_misc is to spawn the + binary lazily when the misc format file is invoked. However, + this doesn``t work very well in the face of mount namespaces and + changeroots, so the ``F`` mode opens the binary as soon as the + emulation is installed and uses the opened image to spawn the + emulator, meaning it is always available once installed, + regardless of how the environment changes. + + +I had the same idea but didnt know about the restart part :D + +attached is the strace =) +Thx + +Is that of any help? + +Le 29/09/2020 à 15:05, Petunia a écrit : +> Is that of any help? +> + +We need also the content of /mnt/var/log/syslog that contains the +straces for systemd. + + +There is no syslog and everything else is empty: +ls -ltrR /mnt/var/log/ +/mnt/var/log/: +total 8 +drwxr-xr-x 2 root root 4096 20. Aug 12:33 apt +-rw-r--r-- 1 root root 0 20. Aug 12:47 faillog +-rw-r--r-- 1 root root 0 20. Aug 12:47 dpkg.log +-rw-rw-r-- 1 root tor 0 20. Aug 12:47 lastlog +-rw-r--r-- 1 root root 0 20. Aug 12:47 bootstrap.log +-rw-rw---- 1 root tor 0 20. Aug 12:47 btmp +-rw-r--r-- 1 root root 0 20. Aug 12:47 alternatives.log +-rw-rw-r-- 1 root tor 0 20. Aug 12:47 wtmp +drwxr-xr-x 2 root root 4096 13. Sep 21:58 journal + +/mnt/var/log/apt: +total 0 +-rw-r----- 1 root adm 0 20. Aug 12:47 term.log +-rw-r--r-- 1 root root 0 20. Aug 12:47 history.log +-rw-r--r-- 1 root root 0 20. Aug 12:47 eipp.log.xz + +/mnt/var/log/journal: +total 0 + + +Mhm, weird. On my other machine it works. +There I used the AUR package qemu-user-static instead of qemu-arm-static. +However that seems not to be the problem since it doesnt even work after switching to qemu-user-static. + +With the working setup the log files are also created (which makes sense since it loops at "A start job is running for Journal Service") + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1895080 b/results/classifier/zero-shot/108/permissions/1895080 new file mode 100644 index 000000000..19be0826b --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1895080 @@ -0,0 +1,1342 @@ +permissions: 0.942 +other: 0.927 +device: 0.912 +socket: 0.911 +debug: 0.911 +performance: 0.909 +semantic: 0.906 +KVM: 0.899 +vnc: 0.897 +graphic: 0.897 +PID: 0.893 +network: 0.882 +files: 0.861 +boot: 0.842 + +pgb_reserved_va: Assertion `addr == test' failed + +This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux-user. + +Firstly, compile fails: +Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared here (not in a function) + FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), + +I have to add below include to linux-user/strace.c +diff --git a/linux-user/strace.c b/linux-user/strace.c +index 11fea14fba..22e51d4a8a 100644 +--- a/linux-user/strace.c ++++ b/linux-user/strace.c +@@ -7,6 +7,7 @@ + #include <sys/mount.h> + #include <arpa/inet.h> + #include <netinet/tcp.h> ++#include <linux/falloc.h> + #include <linux/if_packet.h> + #include <linux/netlink.h> + #include <sched.h> + +Then trying qemu-riscv32 with a simple ELF, I get: +linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. + +strace shows that: +mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +) = 103 + +The source code is in the function pgb_reserved_va (linux-user/elfload.c). I think mmap cannot guarantee that the returned pointer (test) equals to the parameter of addr. So is this a bug to assert (addr == test)? + +Attached configure script and test ELF file. + +Thanks. + + + +Le 10/09/2020 à 07:21, Launchpad Bug Tracker a écrit : +> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +> user. + +I tried to build qemu-5.1 on CentOS-7.5.1 but as python 3.5 is not +available, I gave up. + +> Firstly, compile fails: +> Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared here (not in a function) +> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +> +> I have to add below include to linux-user/strace.c +> diff --git a/linux-user/strace.c b/linux-user/strace.c +> index 11fea14fba..22e51d4a8a 100644 +> --- a/linux-user/strace.c +> +++ b/linux-user/strace.c +> @@ -7,6 +7,7 @@ +> #include <sys/mount.h> +> #include <arpa/inet.h> +> #include <netinet/tcp.h> +> +#include <linux/falloc.h> +> #include <linux/if_packet.h> +> #include <linux/netlink.h> +> #include <sched.h> + +In fact, fallocate(2) says fcntl.h must be included. +And qemu/osdep.h includes it. +So you should not have this problem. + +> +> Then trying qemu-riscv32 with a simple ELF, I get: +> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +> +> strace shows that: +> mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +> ) = 103 +> +> The source code is in the function pgb_reserved_va (linux- +> user/elfload.c). I think mmap cannot guarantee that the returned pointer +> (test) equals to the parameter of addr. So is this a bug to assert (addr +> == test)? + +I think Alex Bennée knows better this code than I do, so cc'ing him. + +Thnaks +Laurent + + +> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +> > (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +> > user. +> +> I tried to build qemu-5.1 on CentOS-7.5.1 but as python 3.5 is not +> available, I gave up. +> + +Thank you for your effort. I installed python3 with yum: +python3.x86_64 3.6.8-10.el7 @centos +Then maybe you can specify python3 in configure with +"--python=/bin/python3" in case configure cannot find it. + + +> +> > Firstly, compile fails: +> > Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +> > ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +> undeclared here (not in a function) +> > FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +> > +> > I have to add below include to linux-user/strace.c +> > diff --git a/linux-user/strace.c b/linux-user/strace.c +> > index 11fea14fba..22e51d4a8a 100644 +> > --- a/linux-user/strace.c +> > +++ b/linux-user/strace.c +> > @@ -7,6 +7,7 @@ +> > #include <sys/mount.h> +> > #include <arpa/inet.h> +> > #include <netinet/tcp.h> +> > +#include <linux/falloc.h> +> > #include <linux/if_packet.h> +> > #include <linux/netlink.h> +> > #include <sched.h> +> +> In fact, fallocate(2) says fcntl.h must be included. +> And qemu/osdep.h includes it. +> So you should not have this problem. +> + +I tried to save the file after pre-processing, namely strace.i. Though +_GNU_SOURCE is defined and fcntl.h is included, falloc.h is not included, +in which FALLOC_FL_KEEP_SIZE is defined. I'm not sure if it's some +environmental problem. + +Thanks. + +> +> > Then trying qemu-riscv32 with a simple ELF, I get: +> > linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +> failed. +> > +> > strace shows that: +> > mmap(0x1000, 4294963200, PROT_NONE, +> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> > write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +> test' failed. +> > ) = 103 +> > +> > The source code is in the function pgb_reserved_va (linux- +> > user/elfload.c). I think mmap cannot guarantee that the returned pointer +> > (test) equals to the parameter of addr. So is this a bug to assert (addr +> > == test)? +> +> I think Alex Bennée knows better this code than I do, so cc'ing him. +> +> Thnaks +> Laurent +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1895080 +> +> Title: +> pgb_reserved_va: Assertion `addr == test' failed +> +> Status in QEMU: +> New +> +> Bug description: +> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +> user. +> +> Firstly, compile fails: +> Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +> undeclared here (not in a function) +> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +> +> I have to add below include to linux-user/strace.c +> diff --git a/linux-user/strace.c b/linux-user/strace.c +> index 11fea14fba..22e51d4a8a 100644 +> --- a/linux-user/strace.c +> +++ b/linux-user/strace.c +> @@ -7,6 +7,7 @@ +> #include <sys/mount.h> +> #include <arpa/inet.h> +> #include <netinet/tcp.h> +> +#include <linux/falloc.h> +> #include <linux/if_packet.h> +> #include <linux/netlink.h> +> #include <sched.h> +> +> Then trying qemu-riscv32 with a simple ELF, I get: +> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +> failed. +> +> strace shows that: +> mmap(0x1000, 4294963200, PROT_NONE, +> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +> test' failed. +> ) = 103 +> +> The source code is in the function pgb_reserved_va (linux- +> user/elfload.c). I think mmap cannot guarantee that the returned +> pointer (test) equals to the parameter of addr. So is this a bug to +> assert (addr == test)? +> +> Attached configure script and test ELF file. +> +> Thanks. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions +> + + +Have you got a static version of the test binary (or a mini rootfs with the libraries it needs)? + +Have you got a static version of the test binary (or a mini rootfs with +> the libraries it needs)? +> + +If the problem occurs, it does not reach the stage of the dependent +libraries of the test ELF. Anyway, I've attached the static test binary as +hello.static.elf. +Thanks + + +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1895080 +> +> Title: +> pgb_reserved_va: Assertion `addr == test' failed +> +> Status in QEMU: +> New +> +> Bug description: +> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +> user. +> +> Firstly, compile fails: +> Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +> undeclared here (not in a function) +> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +> +> I have to add below include to linux-user/strace.c +> diff --git a/linux-user/strace.c b/linux-user/strace.c +> index 11fea14fba..22e51d4a8a 100644 +> --- a/linux-user/strace.c +> +++ b/linux-user/strace.c +> @@ -7,6 +7,7 @@ +> #include <sys/mount.h> +> #include <arpa/inet.h> +> #include <netinet/tcp.h> +> +#include <linux/falloc.h> +> #include <linux/if_packet.h> +> #include <linux/netlink.h> +> #include <sched.h> +> +> Then trying qemu-riscv32 with a simple ELF, I get: +> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +> failed. +> +> strace shows that: +> mmap(0x1000, 4294963200, PROT_NONE, +> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +> test' failed. +> ) = 103 +> +> The source code is in the function pgb_reserved_va (linux- +> user/elfload.c). I think mmap cannot guarantee that the returned +> pointer (test) equals to the parameter of addr. So is this a bug to +> assert (addr == test)? +> +> Attached configure script and test ELF file. +> +> Thanks. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions +> + + + +Laurent Vivier <email address hidden> writes: + +> Le 10/09/2020 à 07:21, Launchpad Bug Tracker a écrit : +>> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +>> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +>> user. +> +> I tried to build qemu-5.1 on CentOS-7.5.1 but as python 3.5 is not +> available, I gave up. +> +>> Firstly, compile fails: +>> Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +>> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared here (not in a function) +>> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +>> +>> I have to add below include to linux-user/strace.c +>> diff --git a/linux-user/strace.c b/linux-user/strace.c +>> index 11fea14fba..22e51d4a8a 100644 +>> --- a/linux-user/strace.c +>> +++ b/linux-user/strace.c +>> @@ -7,6 +7,7 @@ +>> #include <sys/mount.h> +>> #include <arpa/inet.h> +>> #include <netinet/tcp.h> +>> +#include <linux/falloc.h> +>> #include <linux/if_packet.h> +>> #include <linux/netlink.h> +>> #include <sched.h> +> +> In fact, fallocate(2) says fcntl.h must be included. +> And qemu/osdep.h includes it. +> So you should not have this problem. +> +>> +>> Then trying qemu-riscv32 with a simple ELF, I get: +>> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +>> +>> strace shows that: +>> mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +>> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +>> ) = 103 +>> +>> The source code is in the function pgb_reserved_va (linux- +>> user/elfload.c). I think mmap cannot guarantee that the returned pointer +>> (test) equals to the parameter of addr. So is this a bug to assert (addr +>> == test)? +> +> I think Alex Bennée knows better this code than I do, so cc'ing him. + +It should be able to do so because the earlier code (pgb_static) checks +for a hole the size of reserved_va in the host memory map. This should +be fairly easy for 32 bit guests given the amount of spare address space +you have on a 64 bit system. + +I'm assuming CentOS 7.5 actually has a definition for +MAP_FIXED_NOREPLACE which should ensure we get what we asked for - +otherwise we are in the position of hoping the kernel honours what we +asked for. + +> +> Thnaks +> Laurent + + +-- +Alex Bennée + + + +Alex Bennée <email address hidden> writes: + +> Laurent Vivier <email address hidden> writes: +> +<snip> +>>> Then trying qemu-riscv32 with a simple ELF, I get: +>>> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +>>> +>>> strace shows that: +>>> mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +>>> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +>>> ) = 103 +>>> +>>> The source code is in the function pgb_reserved_va (linux- +>>> user/elfload.c). I think mmap cannot guarantee that the returned pointer +>>> (test) equals to the parameter of addr. So is this a bug to assert (addr +>>> == test)? +>> +> I'm assuming CentOS 7.5 actually has a definition for +> MAP_FIXED_NOREPLACE which should ensure we get what we asked for - +> otherwise we are in the position of hoping the kernel honours what we +> asked for. + +Doh re-reading I see it's not set in the strace output. Maybe we should +promote the assert case to the failure leg so we have: + + if (addr == MAP_FAILED || addr != test) { + error_report(...) + } + +so we at least fail with a user friendly error rather than an abort? + +-- +Alex Bennée + + +No, it's not set by CentOS-7.5. +Does it mean that we just cannot run the ELF in such a case? I've tried +many times, the assert always fails. Maybe, we can blame CentOS-7.5. +BTW: with the option "-p 65536", the case runs successfully. + +On Fri, Sep 11, 2020 at 5:50 PM Alex Bennée <email address hidden> +wrote: + +> Alex Bennée <email address hidden> writes: +> +> > Laurent Vivier <email address hidden> writes: +> > +> <snip> +> >>> Then trying qemu-riscv32 with a simple ELF, I get: +> >>> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +> failed. +> >>> +> >>> strace shows that: +> >>> mmap(0x1000, 4294963200, PROT_NONE, +> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> >>> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +> test' failed. +> >>> ) = 103 +> >>> +> >>> The source code is in the function pgb_reserved_va (linux- +> >>> user/elfload.c). I think mmap cannot guarantee that the returned +> pointer +> >>> (test) equals to the parameter of addr. So is this a bug to assert +> (addr +> >>> == test)? +> >> +> > I'm assuming CentOS 7.5 actually has a definition for +> > MAP_FIXED_NOREPLACE which should ensure we get what we asked for - +> > otherwise we are in the position of hoping the kernel honours what we +> > asked for. +> +> Doh re-reading I see it's not set in the strace output. Maybe we should +> promote the assert case to the failure leg so we have: +> +> if (addr == MAP_FAILED || addr != test) { +> error_report(...) +> } +> +> so we at least fail with a user friendly error rather than an abort? +> +> -- +> Alex Bennée +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1895080 +> +> Title: +> pgb_reserved_va: Assertion `addr == test' failed +> +> Status in QEMU: +> New +> +> Bug description: +> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +> user. +> +> Firstly, compile fails: +> Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +> undeclared here (not in a function) +> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +> +> I have to add below include to linux-user/strace.c +> diff --git a/linux-user/strace.c b/linux-user/strace.c +> index 11fea14fba..22e51d4a8a 100644 +> --- a/linux-user/strace.c +> +++ b/linux-user/strace.c +> @@ -7,6 +7,7 @@ +> #include <sys/mount.h> +> #include <arpa/inet.h> +> #include <netinet/tcp.h> +> +#include <linux/falloc.h> +> #include <linux/if_packet.h> +> #include <linux/netlink.h> +> #include <sched.h> +> +> Then trying qemu-riscv32 with a simple ELF, I get: +> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +> failed. +> +> strace shows that: +> mmap(0x1000, 4294963200, PROT_NONE, +> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +> test' failed. +> ) = 103 +> +> The source code is in the function pgb_reserved_va (linux- +> user/elfload.c). I think mmap cannot guarantee that the returned +> pointer (test) equals to the parameter of addr. So is this a bug to +> assert (addr == test)? +> +> Attached configure script and test ELF file. +> +> Thanks. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions +> + + + +Hansni Bu <email address hidden> writes: + +> No, it's not set by CentOS-7.5. +> Does it mean that we just cannot run the ELF in such a case? I've tried +> many times, the assert always fails. Maybe, we can blame CentOS-7.5. + +The trouble is without MAP_FIXED_NOREPLACE we are at the mercy of the +host kernel to allow the address request to be honoured. A plain +MAP_FIXED won't do as it can clober existing mappings. In theory a +suitable hole has been identified but sometimes the kernel makes a +decision to offset the suggested mapping for it's own reasons. + +> BTW: with the option "-p 65536", the case runs successfully. + +Hmm interesting. I wonder if we are seeing a fail due to mmap_min_addr? +What does: + + /proc/sys/vm/mmap_min_addr + +give you on the system? + +You can manually set the reserved_va and the base address using -R and +-B although that is more of a developer work around. I think moving the +assert to the condition above would be an improvement just because it +tells us what the requested base address was and what the kernel decided +to give us. + +> +> On Fri, Sep 11, 2020 at 5:50 PM Alex Bennée <email address hidden> +> wrote: +> +>> Alex Bennée <email address hidden> writes: +>> +>> > Laurent Vivier <email address hidden> writes: +>> > +>> <snip> +>> >>> Then trying qemu-riscv32 with a simple ELF, I get: +>> >>> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +>> failed. +>> >>> +>> >>> strace shows that: +>> >>> mmap(0x1000, 4294963200, PROT_NONE, +>> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +>> >>> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +>> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +>> test' failed. +>> >>> ) = 103 +>> >>> +>> >>> The source code is in the function pgb_reserved_va (linux- +>> >>> user/elfload.c). I think mmap cannot guarantee that the returned +>> pointer +>> >>> (test) equals to the parameter of addr. So is this a bug to assert +>> (addr +>> >>> == test)? +>> >> +>> > I'm assuming CentOS 7.5 actually has a definition for +>> > MAP_FIXED_NOREPLACE which should ensure we get what we asked for - +>> > otherwise we are in the position of hoping the kernel honours what we +>> > asked for. +>> +>> Doh re-reading I see it's not set in the strace output. Maybe we should +>> promote the assert case to the failure leg so we have: +>> +>> if (addr == MAP_FAILED || addr != test) { +>> error_report(...) +>> } +>> +>> so we at least fail with a user friendly error rather than an abort? +>> +>> -- +>> Alex Bennée +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1895080 +>> +>> Title: +>> pgb_reserved_va: Assertion `addr == test' failed +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +>> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +>> user. +>> +>> Firstly, compile fails: +>> Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +>> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +>> undeclared here (not in a function) +>> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +>> +>> I have to add below include to linux-user/strace.c +>> diff --git a/linux-user/strace.c b/linux-user/strace.c +>> index 11fea14fba..22e51d4a8a 100644 +>> --- a/linux-user/strace.c +>> +++ b/linux-user/strace.c +>> @@ -7,6 +7,7 @@ +>> #include <sys/mount.h> +>> #include <arpa/inet.h> +>> #include <netinet/tcp.h> +>> +#include <linux/falloc.h> +>> #include <linux/if_packet.h> +>> #include <linux/netlink.h> +>> #include <sched.h> +>> +>> Then trying qemu-riscv32 with a simple ELF, I get: +>> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +>> failed. +>> +>> strace shows that: +>> mmap(0x1000, 4294963200, PROT_NONE, +>> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +>> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +>> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +>> test' failed. +>> ) = 103 +>> +>> The source code is in the function pgb_reserved_va (linux- +>> user/elfload.c). I think mmap cannot guarantee that the returned +>> pointer (test) equals to the parameter of addr. So is this a bug to +>> assert (addr == test)? +>> +>> Attached configure script and test ELF file. +>> +>> Thanks. +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions +>> + + +-- +Alex Bennée + + +> > No, it's not set by CentOS-7.5. +> > Does it mean that we just cannot run the ELF in such a case? I've tried +> > many times, the assert always fails. Maybe, we can blame CentOS-7.5. +> +> The trouble is without MAP_FIXED_NOREPLACE we are at the mercy of the +> host kernel to allow the address request to be honoured. A plain +> MAP_FIXED won't do as it can clober existing mappings. In theory a +> suitable hole has been identified but sometimes the kernel makes a +> decision to offset the suggested mapping for it's own reasons. +> + +MAP_FIXED_NOREPLACE is quite a new feature. + + +> > BTW: with the option "-p 65536", the case runs successfully. +> +> Hmm interesting. I wonder if we are seeing a fail due to mmap_min_addr? +> What does: +> +> /proc/sys/vm/mmap_min_addr +> +> give you on the system? +> + +It gives me 4096. And guest_base has this value. Maybe that's the strange +point. mmap_min_addr give us 0x1000. While we are requesting this address, +the kernel gives us 0x10000. + + +> +> You can manually set the reserved_va and the base address using -R and +> -B although that is more of a developer work around. I think moving the +> assert to the condition above would be an improvement just because it +> tells us what the requested base address was and what the kernel decided +> to give us. +> + +Setting guest_base with -B to 0x10000 works. Tried some -R values, no luck. +Agree to print a more hintful message. + + +> +> > +> > On Fri, Sep 11, 2020 at 5:50 PM Alex Bennée <email address hidden> +> > wrote: +> > +> >> Alex Bennée <email address hidden> writes: +> >> +> >> > Laurent Vivier <email address hidden> writes: +> >> > +> >> <snip> +> >> >>> Then trying qemu-riscv32 with a simple ELF, I get: +> >> >>> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +> >> failed. +> >> >>> +> >> >>> strace shows that: +> >> >>> mmap(0x1000, 4294963200, PROT_NONE, +> >> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> >> >>> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +> >> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr +> == +> >> test' failed. +> >> >>> ) = 103 +> >> >>> +> >> >>> The source code is in the function pgb_reserved_va (linux- +> >> >>> user/elfload.c). I think mmap cannot guarantee that the returned +> >> pointer +> >> >>> (test) equals to the parameter of addr. So is this a bug to assert +> >> (addr +> >> >>> == test)? +> >> >> +> >> > I'm assuming CentOS 7.5 actually has a definition for +> >> > MAP_FIXED_NOREPLACE which should ensure we get what we asked for - +> >> > otherwise we are in the position of hoping the kernel honours what we +> >> > asked for. +> >> +> >> Doh re-reading I see it's not set in the strace output. Maybe we should +> >> promote the assert case to the failure leg so we have: +> >> +> >> if (addr == MAP_FAILED || addr != test) { +> >> error_report(...) +> >> } +> >> +> >> so we at least fail with a user friendly error rather than an abort? +> >> +> >> -- +> >> Alex Bennée +> >> +> >> -- +> >> You received this bug notification because you are subscribed to the bug +> >> report. +> >> https://bugs.launchpad.net/bugs/1895080 +> >> +> >> Title: +> >> pgb_reserved_va: Assertion `addr == test' failed +> >> +> >> Status in QEMU: +> >> New +> >> +> >> Bug description: +> >> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +> >> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +> >> user. +> >> +> >> Firstly, compile fails: +> >> Compiling C object +> libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +> >> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +> >> undeclared here (not in a function) +> >> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +> >> +> >> I have to add below include to linux-user/strace.c +> >> diff --git a/linux-user/strace.c b/linux-user/strace.c +> >> index 11fea14fba..22e51d4a8a 100644 +> >> --- a/linux-user/strace.c +> >> +++ b/linux-user/strace.c +> >> @@ -7,6 +7,7 @@ +> >> #include <sys/mount.h> +> >> #include <arpa/inet.h> +> >> #include <netinet/tcp.h> +> >> +#include <linux/falloc.h> +> >> #include <linux/if_packet.h> +> >> #include <linux/netlink.h> +> >> #include <sched.h> +> >> +> >> Then trying qemu-riscv32 with a simple ELF, I get: +> >> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +> >> failed. +> >> +> >> strace shows that: +> >> mmap(0x1000, 4294963200, PROT_NONE, +> >> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> >> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +> >> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr +> == +> >> test' failed. +> >> ) = 103 +> >> +> >> The source code is in the function pgb_reserved_va (linux- +> >> user/elfload.c). I think mmap cannot guarantee that the returned +> >> pointer (test) equals to the parameter of addr. So is this a bug to +> >> assert (addr == test)? +> >> +> >> Attached configure script and test ELF file. +> >> +> >> Thanks. +> >> +> >> To manage notifications about this bug go to: +> >> https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions +> >> +> +> +> -- +> Alex Bennée +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1895080 +> +> Title: +> pgb_reserved_va: Assertion `addr == test' failed +> +> Status in QEMU: +> New +> +> Bug description: +> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +> user. +> +> Firstly, compile fails: +> Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +> undeclared here (not in a function) +> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +> +> I have to add below include to linux-user/strace.c +> diff --git a/linux-user/strace.c b/linux-user/strace.c +> index 11fea14fba..22e51d4a8a 100644 +> --- a/linux-user/strace.c +> +++ b/linux-user/strace.c +> @@ -7,6 +7,7 @@ +> #include <sys/mount.h> +> #include <arpa/inet.h> +> #include <netinet/tcp.h> +> +#include <linux/falloc.h> +> #include <linux/if_packet.h> +> #include <linux/netlink.h> +> #include <sched.h> +> +> Then trying qemu-riscv32 with a simple ELF, I get: +> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +> failed. +> +> strace shows that: +> mmap(0x1000, 4294963200, PROT_NONE, +> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +> test' failed. +> ) = 103 +> +> The source code is in the function pgb_reserved_va (linux- +> user/elfload.c). I think mmap cannot guarantee that the returned +> pointer (test) equals to the parameter of addr. So is this a bug to +> assert (addr == test)? +> +> Attached configure script and test ELF file. +> +> Thanks. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions +> + + + +Hansni Bu <email address hidden> writes: + +>> > No, it's not set by CentOS-7.5. +>> > Does it mean that we just cannot run the ELF in such a case? I've tried +>> > many times, the assert always fails. Maybe, we can blame CentOS-7.5. +>> +>> The trouble is without MAP_FIXED_NOREPLACE we are at the mercy of the +>> host kernel to allow the address request to be honoured. A plain +>> MAP_FIXED won't do as it can clober existing mappings. In theory a +>> suitable hole has been identified but sometimes the kernel makes a +>> decision to offset the suggested mapping for it's own reasons. +>> +> +> MAP_FIXED_NOREPLACE is quite a new feature. +> +> +>> > BTW: with the option "-p 65536", the case runs successfully. +>> +>> Hmm interesting. I wonder if we are seeing a fail due to mmap_min_addr? +>> What does: +>> +>> /proc/sys/vm/mmap_min_addr +>> +>> give you on the system? +>> +> +> It gives me 4096. And guest_base has this value. Maybe that's the strange +> point. mmap_min_addr give us 0x1000. While we are requesting this address, +> the kernel gives us 0x10000. + +Yeah the meaning of mmap_min_addr should be exactly that which is odd +why the kernel doesn't honour the request. That said it seems to be a +user tweakable knob so you could just up it. + +>> +>> You can manually set the reserved_va and the base address using -R and +>> -B although that is more of a developer work around. I think moving the +>> assert to the condition above would be an improvement just because it +>> tells us what the requested base address was and what the kernel decided +>> to give us. +>> +> +> Setting guest_base with -B to 0x10000 works. Tried some -R values, no luck. +> Agree to print a more hintful message. + +OK - one other test you try is running inside a chroot which *does not* +have visibility of /proc. That will cause it to fall back to the old +probing technique of trying multiple mmap operations to find the hole. I +suspect that works because the attempt to map 0x1000 would fail the +check. The reason we default to probing /proc/self/map now is that brute +force technique falls over when trying to probe for a hole on 64 bit +systems, especially when built with stack protection/clang debug +instrumentation. + +In the meantime I'll spin up a patch to improve the failure mode. + +> +> +>> +>> > +>> > On Fri, Sep 11, 2020 at 5:50 PM Alex Bennée <email address hidden> +>> > wrote: +>> > +>> >> Alex Bennée <email address hidden> writes: +>> >> +>> >> > Laurent Vivier <email address hidden> writes: +>> >> > +>> >> <snip> +>> >> >>> Then trying qemu-riscv32 with a simple ELF, I get: +>> >> >>> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +>> >> failed. +>> >> >>> +>> >> >>> strace shows that: +>> >> >>> mmap(0x1000, 4294963200, PROT_NONE, +>> >> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +>> >> >>> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +>> >> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr +>> == +>> >> test' failed. +>> >> >>> ) = 103 +>> >> >>> +>> >> >>> The source code is in the function pgb_reserved_va (linux- +>> >> >>> user/elfload.c). I think mmap cannot guarantee that the returned +>> >> pointer +>> >> >>> (test) equals to the parameter of addr. So is this a bug to assert +>> >> (addr +>> >> >>> == test)? +>> >> >> +>> >> > I'm assuming CentOS 7.5 actually has a definition for +>> >> > MAP_FIXED_NOREPLACE which should ensure we get what we asked for - +>> >> > otherwise we are in the position of hoping the kernel honours what we +>> >> > asked for. +>> >> +>> >> Doh re-reading I see it's not set in the strace output. Maybe we should +>> >> promote the assert case to the failure leg so we have: +>> >> +>> >> if (addr == MAP_FAILED || addr != test) { +>> >> error_report(...) +>> >> } +>> >> +>> >> so we at least fail with a user friendly error rather than an abort? +>> >> +>> >> -- +>> >> Alex Bennée +>> >> +>> >> -- +>> >> You received this bug notification because you are subscribed to the bug +>> >> report. +>> >> https://bugs.launchpad.net/bugs/1895080 +>> >> +>> >> Title: +>> >> pgb_reserved_va: Assertion `addr == test' failed +>> >> +>> >> Status in QEMU: +>> >> New +>> >> +>> >> Bug description: +>> >> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +>> >> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +>> >> user. +>> >> +>> >> Firstly, compile fails: +>> >> Compiling C object +>> libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +>> >> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +>> >> undeclared here (not in a function) +>> >> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +>> >> +>> >> I have to add below include to linux-user/strace.c +>> >> diff --git a/linux-user/strace.c b/linux-user/strace.c +>> >> index 11fea14fba..22e51d4a8a 100644 +>> >> --- a/linux-user/strace.c +>> >> +++ b/linux-user/strace.c +>> >> @@ -7,6 +7,7 @@ +>> >> #include <sys/mount.h> +>> >> #include <arpa/inet.h> +>> >> #include <netinet/tcp.h> +>> >> +#include <linux/falloc.h> +>> >> #include <linux/if_packet.h> +>> >> #include <linux/netlink.h> +>> >> #include <sched.h> +>> >> +>> >> Then trying qemu-riscv32 with a simple ELF, I get: +>> >> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +>> >> failed. +>> >> +>> >> strace shows that: +>> >> mmap(0x1000, 4294963200, PROT_NONE, +>> >> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +>> >> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +>> >> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr +>> == +>> >> test' failed. +>> >> ) = 103 +>> >> +>> >> The source code is in the function pgb_reserved_va (linux- +>> >> user/elfload.c). I think mmap cannot guarantee that the returned +>> >> pointer (test) equals to the parameter of addr. So is this a bug to +>> >> assert (addr == test)? +>> >> +>> >> Attached configure script and test ELF file. +>> >> +>> >> Thanks. +>> >> +>> >> To manage notifications about this bug go to: +>> >> https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions +>> >> +>> +>> +>> -- +>> Alex Bennée +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1895080 +>> +>> Title: +>> pgb_reserved_va: Assertion `addr == test' failed +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head +>> (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux- +>> user. +>> +>> Firstly, compile fails: +>> Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +>> ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ +>> undeclared here (not in a function) +>> FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), +>> +>> I have to add below include to linux-user/strace.c +>> diff --git a/linux-user/strace.c b/linux-user/strace.c +>> index 11fea14fba..22e51d4a8a 100644 +>> --- a/linux-user/strace.c +>> +++ b/linux-user/strace.c +>> @@ -7,6 +7,7 @@ +>> #include <sys/mount.h> +>> #include <arpa/inet.h> +>> #include <netinet/tcp.h> +>> +#include <linux/falloc.h> +>> #include <linux/if_packet.h> +>> #include <linux/netlink.h> +>> #include <sched.h> +>> +>> Then trying qemu-riscv32 with a simple ELF, I get: +>> linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' +>> failed. +>> +>> strace shows that: +>> mmap(0x1000, 4294963200, PROT_NONE, +>> MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +>> write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: +>> ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == +>> test' failed. +>> ) = 103 +>> +>> The source code is in the function pgb_reserved_va (linux- +>> user/elfload.c). I think mmap cannot guarantee that the returned +>> pointer (test) equals to the parameter of addr. So is this a bug to +>> assert (addr == test)? +>> +>> Attached configure script and test ELF file. +>> +>> Thanks. +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions +>> + + +-- +Alex Bennée + + +On older kernels which don't implement MAP_FIXED_NOREPLACE the kernel +may still fail to give us the address we asked for despite having +already probed the map for a valid hole. Asserting isn't particularly +useful to the user so let us move the check up and expand the +error_report a little to give them a fighting chance of working around +the problem. + +Ameliorates: ee94743034 +Cc: Bug 1895080 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + linux-user/elfload.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index 4961e6119e2..f6022fd7049 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -2331,14 +2331,13 @@ static void pgb_reserved_va(const char *image_name, abi_ulong guest_loaddr, + assert(guest_base != 0); + test = g2h(0); + addr = mmap(test, reserved_va, PROT_NONE, flags, -1, 0); +- if (addr == MAP_FAILED) { ++ if (addr == MAP_FAILED || addr != test) { + error_report("Unable to reserve 0x%lx bytes of virtual address " +- "space (%s) for use as guest address space (check your " +- "virtual memory ulimit setting or reserve less " +- "using -R option)", reserved_va, strerror(errno)); ++ "space at %p (%s) for use as guest address space (check your" ++ "virtual memory ulimit setting, min_mmap_addr or reserve less " ++ "using -R option)", reserved_va, test, strerror(errno)); + exit(EXIT_FAILURE); + } +- assert(addr == test); + } + + void probe_guest_base(const char *image_name, abi_ulong guest_loaddr, +-- +2.20.1 + + + +On older kernels which don't implement MAP_FIXED_NOREPLACE the kernel +may still fail to give us the address we asked for despite having +already probed the map for a valid hole. Asserting isn't particularly +useful to the user so let us move the check up and expand the +error_report a little to give them a fighting chance of working around +the problem. + +Ameliorates: ee94743034 +Cc: Bug 1895080 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + linux-user/elfload.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index 4961e6119e24..f6022fd70493 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -2331,14 +2331,13 @@ static void pgb_reserved_va(const char *image_name, abi_ulong guest_loaddr, + assert(guest_base != 0); + test = g2h(0); + addr = mmap(test, reserved_va, PROT_NONE, flags, -1, 0); +- if (addr == MAP_FAILED) { ++ if (addr == MAP_FAILED || addr != test) { + error_report("Unable to reserve 0x%lx bytes of virtual address " +- "space (%s) for use as guest address space (check your " +- "virtual memory ulimit setting or reserve less " +- "using -R option)", reserved_va, strerror(errno)); ++ "space at %p (%s) for use as guest address space (check your" ++ "virtual memory ulimit setting, min_mmap_addr or reserve less " ++ "using -R option)", reserved_va, test, strerror(errno)); + exit(EXIT_FAILURE); + } +- assert(addr == test); + } + + void probe_guest_base(const char *image_name, abi_ulong guest_loaddr, +-- +2.20.1 + + + +chroot works as you expected. +And the patch makes sense. +Thanks. + +On older kernels which don't implement MAP_FIXED_NOREPLACE the kernel +may still fail to give us the address we asked for despite having +already probed the map for a valid hole. Asserting isn't particularly +useful to the user so let us move the check up and expand the +error_report a little to give them a fighting chance of working around +the problem. + +Ameliorates: ee94743034 +Cc: Bug 1895080 <email address hidden> +Signed-off-by: Alex Bennée <email address hidden> +--- + linux-user/elfload.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index 4961e6119e24..f6022fd70493 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -2331,14 +2331,13 @@ static void pgb_reserved_va(const char *image_name, abi_ulong guest_loaddr, + assert(guest_base != 0); + test = g2h(0); + addr = mmap(test, reserved_va, PROT_NONE, flags, -1, 0); +- if (addr == MAP_FAILED) { ++ if (addr == MAP_FAILED || addr != test) { + error_report("Unable to reserve 0x%lx bytes of virtual address " +- "space (%s) for use as guest address space (check your " +- "virtual memory ulimit setting or reserve less " +- "using -R option)", reserved_va, strerror(errno)); ++ "space at %p (%s) for use as guest address space (check your" ++ "virtual memory ulimit setting, min_mmap_addr or reserve less " ++ "using -R option)", reserved_va, test, strerror(errno)); + exit(EXIT_FAILURE); + } +- assert(addr == test); + } + + void probe_guest_base(const char *image_name, abi_ulong guest_loaddr, +-- +2.20.1 + + + +Le 15/09/2020 à 15:43, Alex Bennée a écrit : +> On older kernels which don't implement MAP_FIXED_NOREPLACE the kernel +> may still fail to give us the address we asked for despite having +> already probed the map for a valid hole. Asserting isn't particularly +> useful to the user so let us move the check up and expand the +> error_report a little to give them a fighting chance of working around +> the problem. +> +> Ameliorates: ee94743034 +> Cc: Bug 1895080 <email address hidden> +> Signed-off-by: Alex Bennée <email address hidden> +> --- +> linux-user/elfload.c | 9 ++++----- +> 1 file changed, 4 insertions(+), 5 deletions(-) +> +> diff --git a/linux-user/elfload.c b/linux-user/elfload.c +> index 4961e6119e24..f6022fd70493 100644 +> --- a/linux-user/elfload.c +> +++ b/linux-user/elfload.c +> @@ -2331,14 +2331,13 @@ static void pgb_reserved_va(const char *image_name, abi_ulong guest_loaddr, +> assert(guest_base != 0); +> test = g2h(0); +> addr = mmap(test, reserved_va, PROT_NONE, flags, -1, 0); +> - if (addr == MAP_FAILED) { +> + if (addr == MAP_FAILED || addr != test) { +> error_report("Unable to reserve 0x%lx bytes of virtual address " +> - "space (%s) for use as guest address space (check your " +> - "virtual memory ulimit setting or reserve less " +> - "using -R option)", reserved_va, strerror(errno)); +> + "space at %p (%s) for use as guest address space (check your" +> + "virtual memory ulimit setting, min_mmap_addr or reserve less " +> + "using -R option)", reserved_va, test, strerror(errno)); +> exit(EXIT_FAILURE); +> } +> - assert(addr == test); +> } +> +> void probe_guest_base(const char *image_name, abi_ulong guest_loaddr, +> + +Reviewed-by: Laurent Vivier <email address hidden> + + +On older kernels which don't implement MAP_FIXED_NOREPLACE the kernel +may still fail to give us the address we asked for despite having +already probed the map for a valid hole. Asserting isn't particularly +useful to the user so let us move the check up and expand the +error_report a little to give them a fighting chance of working around +the problem. + +Signed-off-by: Alex Bennée <email address hidden> +Reviewed-by: Laurent Vivier <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +Cc: Bug 1895080 <email address hidden> +Ameliorates: ee94743034 +Message-Id: <email address hidden> + +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index 4961e6119e24..f6022fd70493 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -2331,14 +2331,13 @@ static void pgb_reserved_va(const char *image_name, abi_ulong guest_loaddr, + assert(guest_base != 0); + test = g2h(0); + addr = mmap(test, reserved_va, PROT_NONE, flags, -1, 0); +- if (addr == MAP_FAILED) { ++ if (addr == MAP_FAILED || addr != test) { + error_report("Unable to reserve 0x%lx bytes of virtual address " +- "space (%s) for use as guest address space (check your " +- "virtual memory ulimit setting or reserve less " +- "using -R option)", reserved_va, strerror(errno)); ++ "space at %p (%s) for use as guest address space (check your" ++ "virtual memory ulimit setting, min_mmap_addr or reserve less " ++ "using -R option)", reserved_va, test, strerror(errno)); + exit(EXIT_FAILURE); + } +- assert(addr == test); + } + + void probe_guest_base(const char *image_name, abi_ulong guest_loaddr, +-- +2.20.1 + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=fb730c8683807d549c4a + +Released with QEMU v5.2.0. + diff --git a/results/classifier/zero-shot/108/permissions/1897680 b/results/classifier/zero-shot/108/permissions/1897680 new file mode 100644 index 000000000..8880a31fa --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1897680 @@ -0,0 +1,133 @@ +permissions: 0.982 +device: 0.980 +other: 0.967 +PID: 0.966 +performance: 0.964 +boot: 0.962 +debug: 0.959 +socket: 0.956 +KVM: 0.954 +files: 0.953 +semantic: 0.951 +vnc: 0.947 +graphic: 0.944 +network: 0.813 + +memory address over 0x2000_7ffc is not accessible in mps2-an505 + +I currently run qemu with the following options +`qemu-system-aarch64 -machine mps2-an505 -cpu cortex-m33 -m 16` + +For some reason, memory address over 0x2000_7ffc is not accessible. +It can be tested in gdb as follow. + +(gdb) x/x 0x20007ffc +0x20007ffc: 0x00000000 +(gdb) x/x 0x20007ffd +0x20007ffd: Cannot access memory at address 0x20007ffd +(gdb) x/x 0x20008000 +0x20008000: Cannot access memory at address 0x20008000 + +This is expected behaviour. The memory at 0x2000_0000 in this board is the "FPGA block RAM", and there is only 32K of it, so it finishes at 0x2000_7fff, and attempts to access beyond that will fail because there is no device or memory at the address immediately after it in the memory map. + + +PS: you don't need to pass "-cpu cortex-m33" as it is the default for the mps2-an505 board, and you don't need to pass a -m argument either, as 16MB is the fixed value for this board. + + +(If you were just interested in having a large area of contiguous RAM, the "PSRAM" is the largest lump on this board: it's 16MB starting at 0x8000_0000.) + + +On 9/29/20 8:57 AM, Changho Choi wrote: +> Public bug reported: +> +> I currently run qemu with the following options +> `qemu-system-aarch64 -machine mps2-an505 -cpu cortex-m33 -m 16` +> +> For some reason, memory address over 0x2000_7ffc is not accessible. +> It can be tested in gdb as follow. +> +> (gdb) x/x 0x20007ffc +> 0x20007ffc: 0x00000000 +> (gdb) x/x 0x20007ffd +> 0x20007ffd: Cannot access memory at address 0x20007ffd + +Works for me: + +(gdb) x/xg 0x20007ff8 +0x20007ff8: 0x0000000000000000 + +(gdb) x/xw 0x20007ffc +0x20007ffc: 0x00000000 + +(gdb) x/xh 0x20007ffe +0x20007ffe: 0x0000 + +(gdb) x/xb 0x20007fff +0x20007fff: 0x00 + +I suppose GDB uses 32-bit access size by default, +so requesting 32-bit at 0x20007ffd would access +out of bound memory. + +> (gdb) x/x 0x20008000 +> 0x20008000: Cannot access memory at address 0x20008000 + +For TYPE_IOTKIT there is only 1 SRAM bank (see armsse_variants[]) +initialized to SRAM_ADDR_WIDTH bits, which is 15 by default: + + DEFINE_PROP_UINT32("SRAM_ADDR_WIDTH", ARMSSE, sram_addr_width, 15), + +So this MPC downstream region is a 32KB SRAM. The size looks correct. + +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + +Thank you for all your kind answers and suggestions. +I also have confirmed that the memory address over 0x2000_8000 is not +accessible in the real board. + +Regards, + +Changho Choi + +2020년 9월 29일 (화) 오후 6:25, Peter Maydell <email address hidden>님이 작성: + +> (If you were just interested in having a large area of contiguous RAM, +> the "PSRAM" is the largest lump on this board: it's 16MB starting at +> 0x8000_0000.) +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1897680 +> +> Title: +> memory address over 0x2000_7ffc is not accessible in mps2-an505 +> +> Status in QEMU: +> New +> +> Bug description: +> I currently run qemu with the following options +> `qemu-system-aarch64 -machine mps2-an505 -cpu cortex-m33 -m 16` +> +> For some reason, memory address over 0x2000_7ffc is not accessible. +> It can be tested in gdb as follow. +> +> (gdb) x/x 0x20007ffc +> 0x20007ffc: 0x00000000 +> (gdb) x/x 0x20007ffd +> 0x20007ffd: Cannot access memory at address 0x20007ffd +> (gdb) x/x 0x20008000 +> 0x20008000: Cannot access memory at address 0x20008000 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1897680/+subscriptions +> + + diff --git a/results/classifier/zero-shot/108/permissions/1900122 b/results/classifier/zero-shot/108/permissions/1900122 new file mode 100644 index 000000000..692d9ec6f --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1900122 @@ -0,0 +1,158 @@ +permissions: 0.941 +performance: 0.917 +device: 0.916 +graphic: 0.911 +other: 0.904 +debug: 0.896 +semantic: 0.890 +socket: 0.874 +PID: 0.869 +files: 0.858 +boot: 0.782 +vnc: 0.729 +network: 0.728 +KVM: 0.723 + +Unsupported ioctl: cmd=0xffffffff80685600 when accessing /dev/video* in aarch64 guest + +**Description:** +Any attempt to work with video in aarch64 architecture emulated on x86_64 leads currently to the error "Function not implemented". For example: + +``` +# v4l2-ctl -l --verbose +Failed to open /dev/video0: Function not implemented + +root@12dd9b6fcfcb:/# ll /dev/video* +crw-rw---- 1 root video 81, 0 Oct 16 09:23 /dev/video0 +crw-rw---- 1 root video 81, 1 Oct 16 09:23 /dev/video1 + +``` + +**Steps to reproduce the issue:** + +I have a following setup: + +Host Hardware: x86_64 equipped with a webcam (tried different webcams) +Host OS: Ubuntu 20.04.1 + +Guest Architecture: aarch64 +Guest OS: Ubuntu 20.04 (also tried 16.x and 18.x) + +Emulation: quemu-user-static (also tried binfmt) + +Guest OS is running via Docker + QEMU + +``` +➜ cat /proc/sys/fs/binfmt_misc/qemu-aarch64 +enabled +interpreter /usr/bin/qemu-aarch64-static +flags: F +offset 0 +magic 7f454c460201010000000000000000000200b700 +mask ffffffffffffff00fffffffffffffffffeffffff +``` + +**Results received:** +see desrciption. + +**Environment:** + +<!-- The host architecture is available for only x86_64 --> +* QEMU version: (if you can know it): + +ipxe-qemu-256k-compat-efi-roms/focal,now 1.0.0+git-20150424.a25a16d-0ubuntu4 all [installed,automatic] +ipxe-qemu/focal-updates,now 1.0.0+git-20190109.133f4c4-0ubuntu3.2 all [installed,automatic] +qemu-block-extra/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-kvm/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] +qemu-system-common/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-system-data/focal-updates,now 1:4.2-3ubuntu6.7 all [installed,automatic] +qemu-system-gui/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-system-x86/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-user-binfmt/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu-user/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] +qemu-utils/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed,automatic] +qemu/focal-updates,now 1:4.2-3ubuntu6.7 amd64 [installed] + +* Container application: Docker + +**Output of `docker version`, `podman version` or `singularity version`** + +``` +➜ docker version +Client: Docker Engine - Community + Version: 20.10.0-beta1 + API version: 1.40 + Go version: go1.13.15 + Git commit: ac365d7 + Built: Tue Oct 13 18:15:22 2020 + OS/Arch: linux/amd64 + Context: default + Experimental: true + +Server: Docker Engine - Community + Engine: + Version: 19.03.13 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.15 + Git commit: 4484c46d9d + Built: Wed Sep 16 17:01:20 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.4.1 + GitCommit: c623d1b36f09f8ef6536a057bd658b3aa8632828 + runc: + Version: 1.0.0-rc92 + GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff + docker-init: + Version: 0.18.0 + GitCommit: fec3683 + +``` + +Guest aarch64 runs in privileged mode: + +`docker run --privileged --device=/dev/video0:/dev/video0 --env DISPLAY=unix$DISPLAY -v $XAUTH:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix -it --rm arm64v8/ubuntu:20.04 bash` + +**Additional information:** +I tried also binfmt way to register emulators. The output of `v4l-ctl` was a little bit different: + +``` +# v4l2-ctl -l +Unsupported ioctl: cmd=0xffffffff80685600 +Failed to open /dev/video0: Function not implemented + +``` + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/1906193 b/results/classifier/zero-shot/108/permissions/1906193 new file mode 100644 index 000000000..3ec4ec264 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1906193 @@ -0,0 +1,173 @@ +permissions: 0.960 +other: 0.952 +device: 0.951 +semantic: 0.936 +PID: 0.934 +debug: 0.934 +performance: 0.931 +graphic: 0.925 +files: 0.916 +socket: 0.915 +boot: 0.903 +network: 0.891 +vnc: 0.890 +KVM: 0.890 + +riscv32 user mode emulation: fork return values broken + +When running in a chroot with riscv32 (on x86_64; qemu git master as of today): + +The following short program forks; the child immediately returns with exit(42). The parent checks for the return value - and obtains 40! + +gcc-10.2 + +=============================================== +#include <stdlib.h> +#include <unistd.h> +#include <stdio.h> +#include <sys/wait.h> + +main(c, v) + int c; + char **v; +{ + pid_t pid, p; + int s, i, n; + + s = 0; + pid = fork(); + if (pid == 0) + exit(42); + + /* wait for the process */ + p = wait(&s); + if (p != pid) + exit (255); + + if (WIFEXITED(s)) + { + int r=WEXITSTATUS(s); + if (r!=42) { + printf("child wants to return %i (0x%X), parent received %i (0x%X), difference %i\n",42,42,r,r,r-42); + } + } +} +=============================================== + +(riscv-ilp32 chroot) farino /tmp # ./wait-test-short +child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 + +=============================================== +(riscv-ilp32 chroot) farino /tmp # gcc --version +gcc (Gentoo 10.2.0-r1 p2) 10.2.0 +Copyright (C) 2020 Free Software Foundation, Inc. +Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es +gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. + +(riscv-ilp32 chroot) farino /tmp # ld --version +GNU ld (Gentoo 2.34 p6) 2.34.0 +Copyright (C) 2020 Free Software Foundation, Inc. +This program is free software; you may redistribute it under the terms of +the GNU General Public License version 3 or (at your option) a later version. +This program has absolutely no warranty. + +This is the (statically linked) binary resulting from the source; with it the problem can be demonstrated "standalone", without any other rv32 libraries or a complete chroot, just running the binary with qemu-riscv32. + +Generated with + +(riscv-ilp32 chroot) farino /tmp # gcc -static -o wait-test-short -g wait-test-short.c + + +I can confirm that the same binary works fine with qemu system emulation: + +(riscv-ilp32 qemu) (none) /tmp # ./wait-test-short +(riscv-ilp32 qemu) (none) /tmp # + + +Here's the (abbreviated) output of strace'ing qemu: + +farino ~ # strace -f /usr/bin/qemu-riscv32 /chroot/riscv-ilp32/tmp/wait-test-short +execve("/usr/bin/qemu-riscv32", ["/usr/bin/qemu-riscv32", "/chroot/riscv-ilp32/tmp/wait-tes"...], 0x7ffd95fb1330 /* 40 vars */) = 0 + +[...] + +[pid 16569] uname({sysname="Linux", nodename="farino", ...}) = 0 +[pid 16569] lstat("/chroot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 +[pid 16569] lstat("/chroot/riscv-ilp32", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0 +[pid 16569] lstat("/chroot/riscv-ilp32/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0 +[pid 16569] lstat("/chroot/riscv-ilp32/tmp/wait-test-short", {st_mode=S_IFREG|0755, st_size=445632, ...}) = 0 +[pid 16569] mmap(0x413f1000, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x413f1000 +[pid 16569] mprotect(0x413eb000, 8192, PROT_READ) = 0 +[pid 16569] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +[pid 16569] clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x1339710) = 16571 +strace: Process 16571 attached +[pid 16571] set_robust_list(0x1339720, 24 <unfinished ...> +[pid 16569] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +[pid 16571] <... set_robust_list resumed>) = 0 +[pid 16569] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 +[pid 16571] rt_sigprocmask(SIG_SETMASK, ~[ILL FPE SEGV RTMIN RT_1], ~[KILL STOP RTMIN RT_1], 8) = 0 +[pid 16571] rt_sigprocmask(SIG_BLOCK, ~[], ~[ILL FPE KILL SEGV STOP RTMIN RT_1], 8) = 0 +[pid 16571] clone(child_stack=0x7fe5b73871f0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[16572], tls=0x7fe5b7387640, child_tidptr=0x7fe5b7387910) = 16572 +[pid 16571] rt_sigprocmask(SIG_SETMASK, ~[ILL FPE KILL SEGV STOP RTMIN RT_1], NULL, 8) = 0 +[pid 16571] rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0 +[pid 16571] gettid() = 16571 +[pid 16571] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +[pid 16571] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 +[pid 16569] waitid(P_ALL, -1, <unfinished ...> +[pid 16571] exit_group(42) = ? +strace: Process 16572 attached +[pid 16572] +++ exited with 42 +++ +[pid 16571] +++ exited with 42 +++ +[pid 16569] <... waitid resumed>{si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16571, si_uid=0, si_status=42, si_utime=3472328296226648184, si_stime=3475143045726351408}, WEXITED, NULL) = 0 +[pid 16569] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16571, si_uid=0, si_status=42, si_utime=0, si_stime=0} --- +[pid 16569] statx(1, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFCHR|0600, stx_size=0, ...}) = 0 +[pid 16569] write(1, "child wants to return 42 (0x2A),"..., 74child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 +) = 74 +[pid 16569] brk(0x13c1000) = 0x13c1000 +[pid 16569] brk(0x13c0000) = 0x13c0000 +[pid 16569] exit_group(0) = ? +[pid 16570] <... futex resumed>) = ? +[pid 16570] +++ exited with 0 +++ ++++ exited with 0 +++ + + +Here's qemu's own strace log: + +farino ~ # /usr/bin/qemu-riscv32 -strace /chroot/riscv-ilp32/tmp/wait-test-short +10123 brk(NULL) = 0x00073000 +10123 brk(0x00073880) = 0x00073880 +10123 uname(0x407ffed8) = 0 +10123 readlinkat(AT_FDCWD,"/proc/self/exe",0x407feff0,4096) = 39 +10123 brk(0x00094880) = 0x00094880 +10123 brk(0x00095000) = 0x00095000 +10123 mprotect(0x0006e000,8192,PROT_READ) = 0 +10123 clone(CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|0x11,child_stack=0x00000000,parent_tidptr=0x00000000,tls=0x00000000,child_tidptr=0x00073068) = 10125 +10123 clone(CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|0x11,child_stack=0x00000000,parent_tidptr=0x00000000,tls=0x00000000,child_tidptr=0x00073068) = 0 +10125 exit_group(42) +10123 waitid(0,-1,0x407fff8c,0x4) = 0 +10123 statx(1,"",AT_EMPTY_PATH,STATX_BASIC_STATS,0x407ff8e8) = 0 +child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 +10123 write(1,0x73ad0,74) = 74 +10123 exit_group(0) + + +I have sent a patch, you can see it here: https://patchwork.ozlabs.org/project/qemu-devel/list/?series=221381 + +It seems like QEMU's waitid implementation has a bug with handling the status. + +Thanks a lot! Will test and post the result on monday when I'm back home. + +After applying this patch on top of qemu-5.2.0, I can confirm that it fixes the problem. + +Thank you!! + +Just as a general remark, while this specific problem seems to be solved, there may still be issues surrounding waitid(). + +(With this patch applied, in a rather complex environment I see bash processes hanging in an infinite loop, with waitid involved. I am working on isolating the problem and providing a simple test case, but so far I have not even found the code triggering it.) + +Can you add a Tested-by: tag to the patch? + +Done (took a while to figure out how...) + +A fix has been merged into master. + diff --git a/results/classifier/zero-shot/108/permissions/1907427 b/results/classifier/zero-shot/108/permissions/1907427 new file mode 100644 index 000000000..ff496ff05 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1907427 @@ -0,0 +1,60 @@ +permissions: 0.924 +other: 0.914 +socket: 0.884 +files: 0.876 +performance: 0.860 +graphic: 0.855 +device: 0.845 +semantic: 0.826 +debug: 0.820 +network: 0.819 +KVM: 0.818 +PID: 0.815 +boot: 0.752 +vnc: 0.738 + +Build on sparc64 fails with "undefined reference to `fdt_check_full'" + +Trying to build QEMU on sparc64 fails with: + +[4648/8435] c++ -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o libcommon.fa.p/hw_input_vhost-user-input.c.o libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o libcommon.fa.p/hw_display_sm501.c.o libcommon.fa.p/hw_net_rocker_rocker_world.c.o libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o libcommon.fa.p/migration_global_state.c.o libcommon.fa.p/backends_rng-random.c.o libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o libcommon.fa.p/hw_core_qdev-properties-system.c.o libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o libcommon.fa.p/audio_audio_legacy.c.o +(...) +libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong libmigration.fa -Wl,--start-group libqemuutil.a contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa @block.syms @qemu.syms /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so /usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm /usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so /usr/lib/sparc64-linux-gnu/libslirp.so /usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 /usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so @block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so /usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug /usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle -lstdc++ -Wl,--end-group +/usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function `h_update_dt': +./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to `fdt_check_full' +collect2: error: ld returned 1 exit status + +Full build log available at: https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=sparc64&ver=1%3A5.2%2Bdfsg-1&stamp=1607502300&raw=0 + +Looking at the build log, it seems like your system libfdt is version 1.4.6. +However, that fdt_check_full function is only properly available with +version >= 1.5.1, if I get that right. + +As a workaround, you could try to run the configure script with +--enable-fdt=git (or of course update your system version to 1.5.1 if +somehow possible). + +Indeed, libfdt has been failing to build from source on sparc64 since version 1.4.7 due to the testsuite crashing with unaligned access: + +> https://buildd.debian.org/status/fetch.php?pkg=device-tree-compiler&arch=sparc64&ver=1.6.0-1&stamp=1605385435&raw=0 + +libfdt-dev probably contains some fancy pointer arithmetic resulting in unaligned access which is not allowed but not recognized by gcc. + +The issue has been fixed in the device-tree-compiler package here: + +> https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=b28464a550c536296439b5785ed8852d1e15b35b + +I have filed a Debian bug report asking to backport the patch: + +> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977031 + +Nevertheless, qemu should check for the presence of libfdt >= 1.5.1, so this is still a valid bug report. + + +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/255 + + diff --git a/results/classifier/zero-shot/108/permissions/1909247 b/results/classifier/zero-shot/108/permissions/1909247 new file mode 100644 index 000000000..786862408 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1909247 @@ -0,0 +1,1607 @@ +permissions: 0.935 +debug: 0.908 +performance: 0.893 +other: 0.886 +graphic: 0.876 +semantic: 0.869 +PID: 0.866 +socket: 0.865 +device: 0.859 +vnc: 0.858 +network: 0.831 +KVM: 0.816 +files: 0.811 +boot: 0.744 + +QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c + +A use-after-free vulnerability was found in the am53c974 SCSI host bus adapter emulation of QEMU. It could occur in the esp_do_dma() function in hw/scsi/esp.c while handling the 'Information Transfer' command (CMD_TI). A privileged guest user may abuse this flaw to crash the QEMU process on the host, resulting in a denial of service or potential code execution with the privileges of the QEMU process. + +This issue was reported by Cheolwoo Myung (Seoul National University). + +Original report: +Using hypervisor fuzzer, hyfuzz, I found a use-after-free issue in +am53c974 emulator of QEMU enabled ASan. + +It occurs while transferring information, as it does not check the +buffer to be transferred. + +A malicious guest user/process could use this flaw to crash the QEMU +process resulting in DoS scenario. + +To reproduce this issue, please run the QEMU with the following command +line. + +# To enable ASan option, please set configuration with the following +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the following command line +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +-device am53c974,id=scsi -device scsi-hd,drive=SysDisk \ +-drive id=SysDisk,if=none,file=./disk.img + +Please find attached the disk images to reproduce this issue. + + + +RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1909996 + +Looks the same, or very similar to this one: +/* + * Autogenerated Fuzzer Test Case + * + * This work is licensed under the terms of the GNU GPL, version 2 or + * later. See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +/* + * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \ + * -m 4G -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ + * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio + * outl 0xcf8 0x80001010 + * outl 0xcfc 0xc000 + * outl 0xcf8 0x80001004 + * outw 0xcfc 0x01 + * outl 0xc046 0x02 + * outl 0xc03f 0x0300 + * outw 0xc00b 0x4300 + * outl 0xc00b 0x9000 + * EOF + */ +static void test_fuzz(void) +{ + QTestState *s = qtest_init( + "-display none , -m 4G -device am53c974,id=scsi -device " + "scsi-hd,drive=disk0 -drive " + "id=disk0,if=none,file=null-co://,format=raw -nodefaults"); + qtest_outl(s, 0xcf8, 0x80001010); + qtest_outl(s, 0xcfc, 0xc000); + qtest_outl(s, 0xcf8, 0x80001004); + qtest_outw(s, 0xcfc, 0x01); + qtest_outl(s, 0xc046, 0x02); + qtest_outl(s, 0xc03f, 0x0300); + qtest_outw(s, 0xc00b, 0x4300); + qtest_outl(s, 0xc00b, 0x9000); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + +Technically, the first one is a heap use-after-free, while the second a stack buffer overflow. They could be two different manifestations of the same issue; they both originate from handle_ti() and the root cause may be the same. + +Heap uaf: +================================================================= +==129653==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290000b5000 at pc 0x7f0c3d947dd3 bp 0x7f0c13bfdac0 sp 0x7f0c13bfd270 +READ of size 27 at 0x6290000b5000 thread T7 + #0 0x7f0c3d947dd2 in __interceptor_memcpy (/lib64/libasan.so.6+0x39dd2) + #1 0x562c1c7292b2 in flatview_write_continue softmmu/physmem.c:2781 + #2 0x562c1c729589 in flatview_write softmmu/physmem.c:2816 + #3 0x562c1c729ef7 in address_space_write softmmu/physmem.c:2908 + #4 0x562c1c729faf in address_space_rw softmmu/physmem.c:2918 + #5 0x562c1c217754 in dma_memory_rw_relaxed include/sysemu/dma.h:8 + #6 0x562c1c2177a1 in dma_memory_rw include/sysemu/dma.h:127 + #7 0x562c1c21791b in pci_dma_rw include/hw/pci/pci.h:803 + #8 0x562c1c21b6e3 in esp_pci_dma_memory_rw hw/scsi/esp-pci.c:283 + #9 0x562c1c21ba6e in esp_pci_dma_memory_write hw/scsi/esp-pci.c:302 + #10 0x562c1c428685 in esp_do_dma hw/scsi/esp.c:526 + #11 0x562c1c429cb5 in handle_ti hw/scsi/esp.c:629 + ... + +Stack bof: +================================================================= +==138588==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc8a90c300 at pc 0x559b1de0780e bp 0x7ffc8a90bd10 sp 0x7ffc8a90bd08 +WRITE of size 4 at 0x7ffc8a90c300 thread T0 + #0 0x559b1de0780d in stl_he_p include/qemu/bswap.h:353 + #1 0x559b1de07dec in stn_he_p include/qemu/bswap.h:486 + #2 0x559b1de23e47 in flatview_read_continue softmmu/physmem.c:2841 + #3 0x559b1de24215 in flatview_read softmmu/physmem.c:2879 + #4 0x559b1de243b5 in address_space_read_full softmmu/physmem.c:2892 + #5 0x559b1de2462c in address_space_rw softmmu/physmem.c:2920 + #6 0x559b1d1ec514 in dma_memory_rw_relaxed include/sysemu/dma.h:88 + #7 0x559b1d1ec561 in dma_memory_rw include/sysemu/dma.h:127 + #8 0x559b1d1ec6db in pci_dma_rw include/hw/pci/pci.h:803 + #9 0x559b1d1f04a3 in esp_pci_dma_memory_rw hw/scsi/esp-pci.c:283 + #10 0x559b1d1f07f8 in esp_pci_dma_memory_read hw/scsi/esp-pci.c:296 + #11 0x559b1d66fab1 in esp_do_dma hw/scsi/esp.c:576 + #12 0x559b1d6746e1 in handle_ti hw/scsi/esp.c:845 + ... + +Note that the use-after-free was found in v5.2.0 and, as far as I can tell, is not reproducible anymore on master. The ESP/NCR53C9x emulator (hw/scsi/esp.c) underwent several changes since v5.2.0. By git-bisecting, it looks like the original reproducer is neutralized after commit [1]. However, the qtest reproducer (comment #3) seems to be working fine on master as of today. + +[1] https://git.qemu.org/?p=qemu.git;a=commit;h=bb0bc7bbc9764a5e9e81756819838c5db88652b8 + +Hi Mauro, +Oops... I missed that it was a stack-overflow. I went through my list of crashes, and the closest one I can find is a heap UAF, but it is a write, rather than a read: + +/* + * Autogenerated Fuzzer Test Case + * + * Copyright (c) 2021 <name of author> + * + * This work is licensed under the terms of the GNU GPL, version 2 or + * later. See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqos/libqtest.h" + +/* + * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \ + * -m 4G -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ + * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio + * outl 0xcf8 0x80001010 + * outl 0xcfc 0xc000 + * outl 0xcf8 0x80001004 + * outw 0xcfc 0x05 + * outb 0xc046 0x02 + * outl 0xc00b 0xc100 + * outl 0xc040 0x03 + * outl 0xc040 0x03 + * write 0x0 0x1 0x41 + * outl 0xc00b 0xc100 + * outw 0xc040 0x02 + * outl 0xc00b 0x9000 + * EOF + */ +static void test_fuzz(void) +{ + QTestState *s = qtest_init( + "-display none , -m 4G -device am53c974,id=scsi -device " + "scsi-hd,drive=disk0 -drive " + "id=disk0,if=none,file=null-co://,format=raw -nodefaults"); + qtest_outl(s, 0xcf8, 0x80001010); + qtest_outl(s, 0xcfc, 0xc000); + qtest_outl(s, 0xcf8, 0x80001004); + qtest_outw(s, 0xcfc, 0x05); + qtest_outb(s, 0xc046, 0x02); + qtest_outl(s, 0xc00b, 0xc100); + qtest_outl(s, 0xc040, 0x03); + qtest_outl(s, 0xc040, 0x03); + qtest_bufwrite(s, 0x0, "\x41", 0x1); + qtest_outl(s, 0xc00b, 0xc100); + qtest_outw(s, 0xc040, 0x02); + qtest_outl(s, 0xc00b, 0x9000); + qtest_quit(s); +} +int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { + qtest_add_func("fuzz/test_fuzz", test_fuzz); + } + + return g_test_run(); +} + + + +Thank you both for the reproducers. Please see the proposed patchset here: + +https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06063.html + + +On Wednesday, 17 March, 2021, 10:26:36 pm IST, Cheolwoo Myung <email address hidden> wrote: +> Hello PJP, Mauro +> +> Of course. you can post the details with our reproducers. +> I'm glad it helped you. +> +> Thank you. +> - Cheolwoo Myung +> + + +2021년 3월 17일 (수) 오후 10:30, P J P <email address hidden>님이 작성: +> +>On Monday, 15 March, 2021, 07:54:30 pm IST, Mauro Matteo Cascella <email address hidden> wrote: +>>JFYI, CVE-2020-35506 was assigned to a very similar (if not the same) +>>issue, see https://bugs.launchpad.net/qemu/+bug/1909247. +> +> * From the QEMU command lines below they do look similar. +> +> * CVE bug above does not link to an upstream fix/patch. Maybe it's not fixed yet? +> +> +>On Mon, Mar 15, 2021 at 6:58 AM P J P <email address hidden> wrote: +> >On Monday, 15 March, 2021, 11:11:14 am IST, Cheolwoo Myung <email address hidden> wrote: +> >Using hypervisor fuzzer, hyfuzz, I found a use-after-free issue in am53c974 emulator of QEMU enabled ASan. +> > +> ># To reproduce this issue, please run the QEMU process with the following command line. +> >$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +> > -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive >id=SysDisk,if=none,file=./disk.img +> > +> > +> > Using hypervisor fuzzer, hyfuzz, I found a stack buffer overflow issue in am53c974 emulator of QEMU enabled ASan. +> > +> ># To reproduce this issue, please run the QEMU process with the following command line. +> >$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +> > -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive >id=SysDisk,if=none,file=./disk.img +> > + +* I was able to reproduce these issues against the latest upstream git source + and following patch helps to fix above two issues. +=== +$ git diff hw/scsi/ +diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c +index c3d3dab05e..4a6f208069 100644 +--- a/hw/scsi/esp-pci.c ++++ b/hw/scsi/esp-pci.c +@@ -98,6 +98,7 @@ static void esp_pci_handle_abort(PCIESPState *pci, uint32_t val) + trace_esp_pci_dma_abort(val); + if (s->current_req) { + scsi_req_cancel(s->current_req); ++ s->async_len = 0; + } + } + +diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c +index 507ab363bc..99bee7bc66 100644 +--- a/hw/scsi/esp.c ++++ b/hw/scsi/esp.c +@@ -564,7 +564,7 @@ static void esp_do_dma(ESPState *s) + int to_device = ((s->rregs[ESP_RSTAT] & 7) == STAT_DO); + uint8_t buf[ESP_CMDFIFO_SZ]; + +- len = esp_get_tc(s); ++ len = MIN(esp_get_tc(s), sizeof(buf)); + if (s->do_cmd) { + /* +=== + + +> >Using hypervisor fuzzer, hyfuzz, I found a heap buffer overflow issue in am53c974 emulator of QEMU enabled ASan. +> > +> ># To reproduce this issue, please run the QEMU process with the following command line. +> >$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ +> > -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive >id=SysDisk,if=none,file=./disk.img + +* This heap OOB access issue seems to occur because + + static void do_busid_cmd(...) + ... + buf = (uint8_t *)fifo8_pop_buf(&s->cmdfifo, cmdlen, &n); <== + +'buf' points towards an end of the 32 byte buffer allocated via + + static void esp_init(Object *obj) + ... + fifo8_create(&s->cmdfifo, ESP_CMDFIFO_SZ(=32)); <== + +and the OOB access could occur at numerous places, one of which is + +scsi_req_new + -> scsi_req_parse_cdb + -> memcpy(cmd->buf, buf, cmd->len); <== buf=27, cmd->len=6 <= 27+6 exceeds limit 32. + + +* This one is quite tricky to fix. Because 'buf[]' is accessed at various + places with hard coded index values. It's not easy to check access + against 's->cmdfifo' object. + + +@Cheolwoo: is it okay with you if we post above details and your reproducers on the upstream bug + + -> https://bugs.launchpad.net/qemu/+bug/1909247 + +It'll help to discuss/prepare a proper fix patch. + + +Thank you. +--- + -P J P +http://feedmug.com + +Can you confirm that this is fixed in the v2 of the above patchset? + +https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06550.html + + +ATB, + +Mark. + + +Hello, + +Thank you all for your comments. Both patches (PJP/comment#8 - Mark/comment#9) seem to properly fix the UAF reported by Alexander in comment #6. However, I'm still able to reproduce the heap-bof from the above hw-esp-oob-issues.zip: + +./x86_64-softmmu/qemu-system-x86_64 -m 512 \ +-drive file=./atch2/hyfuzz.img,index=0,media=disk,format=raw \ +-device am53c974,id=scsi -device scsi-hd,drive=SysDisk \ +-drive id=SysDisk,if=none,file=./atch2/disk.img + + + +Hi, +I can still trigger stack-overflows, heap-UAFs and heap-overflows in the +code, but Mark's patches fixed some of the issues. I didn't want to +flood the issue-tracker with further problems in this code, since it +isn't clear what the security expectations are for this device. Of +course it is only a matter of time until someone sends more reports to +qemu-security. + +Mark, do you want me to provide more reproducers for this device? +-Alex + + + +On 3/24/21 4:53 PM, Alexander Bulekov wrote: +> Hi, +> I can still trigger stack-overflows, heap-UAFs and heap-overflows in the +> code, but Mark's patches fixed some of the issues. I didn't want to +> flood the issue-tracker with further problems in this code, since it +> isn't clear what the security expectations are for this device. Of +> course it is only a matter of time until someone sends more reports to +> qemu-security. + +I'd expect qemu-security to have a template "Thank you for your bug +but this device is not within the 'security' boundary, we will forward +your report to the community". + +> +> Mark, do you want me to provide more reproducers for this device? + +Surely Mark prefers you provide bugfixes instead :D + +Phil. + + +If Alex is interested in having a fuzz-proof device as a starting point for fuzzing QEMU's SCSI layer then I don't mind doing the basic work as I've spent a few months deep in the internals of the ESP controller, and it makes sense to look at this whilst it is all still fresh. I'd say there's at least one more set of ESP changes already waiting for after the 6.0 release. + +PJP: +Your change to esp-pci.c looks like a genuine issue, although there is an inconsistency within ESP as to what determines whether a request is in progress or not. My v2 patchset above uses the request member being non-NULL to indicate a valid request, but this should be made consistent throughout the driver. + +Can you provide a qtest reproducer so that it can be incorporated into the test included in the v2 patchset and also allow me to check that this issue has been fixed? + +Alex: +If you can try PJP's patch to esp-pci.c and if you still see some issues then please update this bug with a test case or two, and I will look at them when I get a moment. + +Mauro: +Thanks for the test case - again I shall look at this when I have some available time. + + +Add some more regression tests for the esp device. + +(Prasad's Patch) +Based-on: <email address hidden> +(Mark's v2 Patchset) +Based-on: <email address hidden> +Signed-off-by: Alexander Bulekov <email address hidden> +--- + +Hi Mark, +Hopefully these are useful. I realized that my previous message was +innacurate (I forgot to apply Prasad's patch, or your v2 +patchset). The only corruptions that I am continuing to see are +heap-overflows. I am guessing that most of these are due to some mututal +root cause, so the number of tests far-exceeds the actual number of +errors, but I am providing all of the crashes with unique-looking +stack-traces, just in case. +Please let me know if I can provide anything else that would help. +-Alex + + tests/qtest/am53c974-test.c | 1137 +++++++++++++++++++++++++++++++++++ + 1 file changed, 1137 insertions(+) + +diff --git a/tests/qtest/am53c974-test.c b/tests/qtest/am53c974-test.c +index c90bd4c187..cb2a5646a6 100644 +--- a/tests/qtest/am53c974-test.c ++++ b/tests/qtest/am53c974-test.c +@@ -9,6 +9,1125 @@ + + #include "libqos/libqtest.h" + ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc000 0x4 ++ * outb 0xc008 0xa0 ++ * outl 0xc03f 0x0300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_0900379669(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc000, 0x4); ++ qtest_outb(s, 0xc008, 0xa0); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc008 0x20 ++ * outw 0xc000 0x1 ++ * outb 0xc040 0x03 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outw 0xc00b 0x4200 ++ * outl 0xc00a 0x410000 ++ * EOF ++ */ ++static void crash_094661a91b(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc008, 0x20); ++ qtest_outw(s, 0xc000, 0x1); ++ qtest_outb(s, 0xc040, 0x03); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outw(s, 0xc00b, 0x4200); ++ qtest_outl(s, 0xc00a, 0x410000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc000 0x4 ++ * outl 0xc007 0x8000 ++ * outl 0xc03f 0x0300 ++ * outl 0xc00b 0x4300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_0fff2155cb(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc000, 0x4); ++ qtest_outl(s, 0xc007, 0x8000); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outl(s, 0xc00b, 0x4300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc00c 0x41 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc006 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x0800 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc006 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x0800 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * EOF ++ */ ++static void crash_1548bd10e7(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc00c, 0x41); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc006, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x0800); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc006, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x0800); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc00a 0x420000 ++ * outl 0xc00a 0x430000 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outb 0xc008 0x00 ++ * outw 0xc00b 0x00 ++ * outb 0xc008 0xa0 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outl 0xc00b 0x1000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_1afe349482(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc00a, 0x420000); ++ qtest_outl(s, 0xc00a, 0x430000); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outb(s, 0xc008, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outb(s, 0xc008, 0xa0); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x1000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc007 0x2000 ++ * outw 0xc00b 0x0100 ++ * outw 0xc00c 0x43 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * EOF ++ */ ++static void crash_1b42581317(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc007, 0x2000); ++ qtest_outw(s, 0xc00b, 0x0100); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc007 0x1500 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x4100 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x1000 ++ * outw 0xc009 0x00 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0x0 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc00b 0xc000 ++ * outl 0xc007 0x00 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x1000 ++ * outl 0xc007 0x00 ++ * outw 0xc00b 0x4100 ++ * EOF ++ */ ++static void crash_30e28cfa86(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc007, 0x1500); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_outw(s, 0xc009, 0x00); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0x0); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc00b, 0xc000); ++ qtest_outl(s, 0xc007, 0x00); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x1000); ++ qtest_outl(s, 0xc007, 0x00); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc008 0x42 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x1000 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outl 0xc00b 0x0300 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_34093bfc7c(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc008, 0x42); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc000 0x1 ++ * outb 0xc040 0x03 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outw 0xc007 0xa000 ++ * outl 0xc00a 0x410000 ++ * EOF ++ */ ++static void crash_3a05434a1f(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc000, 0x1); ++ qtest_outb(s, 0xc040, 0x03); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outw(s, 0xc007, 0xa000); ++ qtest_outl(s, 0xc00a, 0x410000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc000 0x01 ++ * outb 0xc040 0x03 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0x4200 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0x4000 ++ * outl 0xc00b 0xc200 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * EOF ++ */ ++static void crash_3ab5744bc3(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc000, 0x01); ++ qtest_outb(s, 0xc040, 0x03); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0x4200); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0x4000); ++ qtest_outl(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc00b 0x4100 ++ * outw 0xc00b 0xc200 ++ * outl 0xc03f 0x0300 ++ * EOF ++ */ ++static void crash_530ff2e211(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0xc200); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outl 0xc03f 0x0300 ++ * outw 0xc00b 0x4300 ++ * outw 0xc000 0x01 ++ * outw 0xc009 0x00 ++ * outw 0xc00b 0x1000 ++ * outl 0xc00d 0x02000000 ++ * outw 0xc00c 0xc2 ++ * outw 0xc00b 0x4100 ++ * outl 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_76ab101171(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outw(s, 0xc00b, 0x4300); ++ qtest_outw(s, 0xc000, 0x01); ++ qtest_outw(s, 0xc009, 0x00); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_outl(s, 0xc00d, 0x02000000); ++ qtest_outw(s, 0xc00c, 0xc2); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outl(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc000 0x4 ++ * outw 0xc007 0x4000 ++ * outl 0xc03f 0x0300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_7f743a0082(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc000, 0x4); ++ qtest_outw(s, 0xc007, 0x4000); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc000 0x4 ++ * outl 0xc03f 0x0300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outl 0xc00b 0x00 ++ * outl 0xc00b 0xc300 ++ * outl 0xc00b 0xc300 ++ * outw 0xc00b 0x9000 ++ * outw 0xc00b 0x1000 ++ * EOF ++ */ ++static void crash_87744a2e67(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc000, 0x4); ++ qtest_outl(s, 0xc03f, 0x0300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outl(s, 0xc00b, 0xc300); ++ qtest_outw(s, 0xc00b, 0x9000); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc00c 0x41 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00b 0x00 ++ * outw 0xc00c 0x00 ++ * outw 0xc00a 0x00 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x00 ++ * outw 0xc00c 0x43 ++ * outl 0xc00a 0x100000 ++ * outl 0xc00a 0x100000 ++ * EOF ++ */ ++static void crash_9f92a77bd6(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc00c, 0x41); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00b, 0x00); ++ qtest_outw(s, 0xc00c, 0x00); ++ qtest_outw(s, 0xc00a, 0x00); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x00); ++ qtest_outw(s, 0xc00c, 0x43); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_outl(s, 0xc00a, 0x100000); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outb 0xc008 0xa ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x4100 ++ * outw 0xc00b 0x1000 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x0400 ++ * outl 0xc00b 0x4200 ++ * EOF ++ */ ++static void crash_d94dc29565(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outb(s, 0xc008, 0xa); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outw(s, 0xc00b, 0x1000); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x0400); ++ qtest_outl(s, 0xc00b, 0x4200); ++ qtest_quit(s); ++} ++/* ++ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ ++ * 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \ ++ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio ++ * outl 0xcf8 0x80001010 ++ * outl 0xcfc 0xc000 ++ * outl 0xcf8 0x80001004 ++ * outw 0xcfc 0x01 ++ * outw 0xc00b 0x4100 ++ * outl 0xc00b 0x0300 ++ * inl 0xc00b ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x0800 ++ * outl 0xc00b 0x00 ++ * outl 0xc00a 0x410000 ++ * EOF ++ */ ++static void crash_df5a21ccf3(void) ++{ ++ QTestState *s = qtest_init( ++ "-display none -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 " ++ "-drive id=disk0,if=none,file=null-co://,format=raw -nodefaults"); ++ qtest_outl(s, 0xcf8, 0x80001010); ++ qtest_outl(s, 0xcfc, 0xc000); ++ qtest_outl(s, 0xcf8, 0x80001004); ++ qtest_outw(s, 0xcfc, 0x01); ++ qtest_outw(s, 0xc00b, 0x4100); ++ qtest_outl(s, 0xc00b, 0x0300); ++ qtest_inl(s, 0xc00b); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x0800); ++ qtest_outl(s, 0xc00b, 0x00); ++ qtest_outl(s, 0xc00a, 0x410000); ++ qtest_quit(s); ++} + + static void test_cmdfifo_underflow_ok(void) + { +@@ -106,6 +1225,24 @@ int main(int argc, char **argv) + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "i386") == 0) { ++ qtest_add_func("fuzz/crash_0900379669", crash_0900379669); ++ qtest_add_func("fuzz/crash_094661a91b", crash_094661a91b); ++ qtest_add_func("fuzz/crash_0fff2155cb", crash_0fff2155cb); ++ qtest_add_func("fuzz/crash_1548bd10e7", crash_1548bd10e7); ++ qtest_add_func("fuzz/crash_1afe349482", crash_1afe349482); ++ qtest_add_func("fuzz/crash_1b42581317", crash_1b42581317); ++ qtest_add_func("fuzz/crash_30e28cfa86", crash_30e28cfa86); ++ qtest_add_func("fuzz/crash_34093bfc7c", crash_34093bfc7c); ++ qtest_add_func("fuzz/crash_3a05434a1f", crash_3a05434a1f); ++ qtest_add_func("fuzz/crash_3ab5744bc3", crash_3ab5744bc3); ++ qtest_add_func("fuzz/crash_530ff2e211", crash_530ff2e211); ++ qtest_add_func("fuzz/crash_76ab101171", crash_76ab101171); ++ qtest_add_func("fuzz/crash_7f743a0082", crash_7f743a0082); ++ qtest_add_func("fuzz/crash_87744a2e67", crash_87744a2e67); ++ qtest_add_func("fuzz/crash_9f92a77bd6", crash_9f92a77bd6); ++ qtest_add_func("fuzz/crash_d94dc29565", crash_d94dc29565); ++ qtest_add_func("fuzz/crash_dd24c44f80", crash_dd24c44f80); ++ qtest_add_func("fuzz/crash_df5a21ccf3", crash_df5a21ccf3); + qtest_add_func("am53c974/test_cmdfifo_underflow_ok", + test_cmdfifo_underflow_ok); + qtest_add_func("am53c974/test_cmdfifo_overflow_ok", +-- +2.28.0 + + + +Thanks again Alex. I've just posted a v3 to the list which fixes your extra test cases, and also those contained within the uaf and hw-esp-oob attachments: + +https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00015.html + + +This is fixed now, thank you Mark. + +Patchset v4: +https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01000.html + +Upstream commits: +https://git.qemu.org/?p=qemu.git;a=commit;h=0db895361b8a82e1114372ff9f48 +https://git.qemu.org/?p=qemu.git;a=commit;h=e392255766071c8cac480da3a9ae +https://git.qemu.org/?p=qemu.git;a=commit;h=e5455b8c1c6170c788f3c0fd577c +https://git.qemu.org/?p=qemu.git;a=commit;h=c5fef9112b15c4b5494791cdf8bb +https://git.qemu.org/?p=qemu.git;a=commit;h=7b320a8e67a534925048cbabfa51 +https://git.qemu.org/?p=qemu.git;a=commit;h=99545751734035b76bd372c4e721 +https://git.qemu.org/?p=qemu.git;a=commit;h=fa7505c154d4d00ad89a747be2ed +https://git.qemu.org/?p=qemu.git;a=commit;h=fbc6510e3379fa8f8370bf71198f +https://git.qemu.org/?p=qemu.git;a=commit;h=0ebb5fd80589835153a0c2baa1b8 +https://git.qemu.org/?p=qemu.git;a=commit;h=324c8809897c8c53ad05c3a7147d +https://git.qemu.org/?p=qemu.git;a=commit;h=607206948cacda4a80be5b976dba + diff --git a/results/classifier/zero-shot/108/permissions/1909770 b/results/classifier/zero-shot/108/permissions/1909770 new file mode 100644 index 000000000..bd7314016 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1909770 @@ -0,0 +1,257 @@ +permissions: 0.975 +other: 0.973 +semantic: 0.971 +graphic: 0.971 +debug: 0.969 +device: 0.953 +performance: 0.948 +PID: 0.946 +socket: 0.938 +boot: 0.937 +vnc: 0.937 +network: 0.925 +files: 0.923 +KVM: 0.885 + +qemu-cris segfaults upon loading userspace binary + +I am on commit 65a3c5984074313602fb5f61cc5f464abfb020c7 (latest as far as I know). I compiled qemu with --enable-debug. + +I'm trying to run a userspace CRIS binary (`./qemu-cris -cpu crisv10 ./basic`), but this segfaults. When opening the coredump in gdb, I get + +gdb-peda$ bt +#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6 +#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000, + prot=0x3) at ../linux-user/elfload.c:1865 +#2 0x0000564a2f7bff65 in load_elf_image ( + image_name=0x7fffe9f5703d "./basic", image_fd=0x3, + info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0, + bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001") + at ../linux-user/elfload.c:2801 +#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920, + info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104 +#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3, + filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0, + envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0, + bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147 +#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78, + envp=0x7fffe9f54ea0) at ../linux-user/main.c:808 +#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6 +#7 0x0000564a2f786cee in _start () + +Or as a full backtrace: +gdb-peda$ bt full +#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000, + prot=0x3) at ../linux-user/elfload.c:1865 + host_start = 0x92134 + host_map_start = 0x93000 + host_end = 0x94000 +#2 0x0000564a2f7bff65 in load_elf_image ( + image_name=0x7fffe9f5703d "./basic", image_fd=0x3, + info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0, + bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001") + at ../linux-user/elfload.c:2801 + vaddr = 0x82134 + vaddr_em = 0x82140 + vaddr_len = 0x2000 + vaddr_po = 0x134 + vaddr_ps = 0x82000 + vaddr_ef = 0x82134 + elf_prot = 0x3 + eppnt = 0x7fffe9f54974 + ehdr = 0x7fffe9f54920 + phdr = 0x7fffe9f54954 + load_addr = 0x80000 + load_bias = 0x0 + loaddr = 0x80000 + hiaddr = 0x1082140 + error = 0x80000 + i = 0x1 + retval = 0x273d2e9c + prot_exec = 0x4 + err = 0x0 + __func__ = "load_elf_image" +#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920, + info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104 + interp_info = { + load_bias = 0x0, + load_addr = 0x0, + start_code = 0x0, + end_code = 0x0, + start_data = 0x0, + end_data = 0x0, + start_brk = 0x0, + brk = 0x0, + reserve_brk = 0x0, + start_mmap = 0x0, + start_stack = 0x0, + stack_limit = 0x0, + entry = 0x0, + code_offset = 0x0, + data_offset = 0x0, + saved_auxv = 0x0, + auxv_len = 0x0, + arg_start = 0x0, + arg_end = 0x0, + arg_strings = 0x0, + env_strings = 0x0, + file_string = 0x0, + elf_flags = 0x0, + personality = 0x0, + alignment = 0x0, + loadmap_addr = 0x0, + nsegs = 0x0, + loadsegs = 0x0, + pt_dynamic_addr = 0x0, + interpreter_loadmap_addr = 0x0, + interpreter_pt_dynamic_addr = 0x0, + other_info = 0x0, + note_flags = 0x0 + } + elf_ex = { + e_ident = "|\214\t1\000\000\000\000\262\002\356_\000\000\000", + e_type = 0x8c7c, + e_machine = 0x3109, + e_version = 0x0, + e_entry = 0x5fee02b2, + e_phoff = 0x0, + e_shoff = 0x31098c7c, + e_flags = 0x0, + e_ehsize = 0x0, + e_phentsize = 0x0, + e_phnum = 0x0, + e_shentsize = 0x0, + e_shnum = 0x0, + e_shstrndx = 0x0 + } + elf_interpreter = 0x0 + scratch = 0x7f272a358021 <read+97> "H\213D$\bH\203\304(\303\017\037D" +#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3, + filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0, + envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0, + bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147 + retval = 0x400 +#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78, + envp=0x7fffe9f54ea0) at ../linux-user/main.c:808 + regs1 = { + orig_r10 = 0x0, + r0 = 0x0, + r1 = 0x0, + r2 = 0x0, + r3 = 0x0, + r4 = 0x0, + r5 = 0x0, + r6 = 0x0, + r7 = 0x0, + r8 = 0x0, + r9 = 0x0, + r10 = 0x0, + r11 = 0x0, + r12 = 0x0, + r13 = 0x0, + acr = 0x0, + srs = 0x0, + mof = 0x0, + spc = 0x0, + ccs = 0x0, + srp = 0x0, + erp = 0x0, + exs = 0x0, + eda = 0x0 + } + regs = 0x7fffe9f54860 + info1 = { + load_bias = 0x0, + load_addr = 0x80000, + start_code = 0x80000, + end_code = 0x80133, + start_data = 0xffffffff, + end_data = 0x0, + start_brk = 0x0, + brk = 0x80133, + reserve_brk = 0x1000000, + start_mmap = 0x80000000, + start_stack = 0x0, + stack_limit = 0x0, + entry = 0x80106, + code_offset = 0x0, + data_offset = 0x0, + saved_auxv = 0x0, + auxv_len = 0x0, + arg_start = 0x0, + arg_end = 0x0, + arg_strings = 0x0, + env_strings = 0x0, + file_string = 0x0, + elf_flags = 0x0, + personality = 0x0, + alignment = 0x2000, + loadmap_addr = 0x0, + nsegs = 0x2, + loadsegs = 0x0, + pt_dynamic_addr = 0x0, + interpreter_loadmap_addr = 0x0, + interpreter_pt_dynamic_addr = 0x0, + other_info = 0x0, + note_flags = 0x0 + } + info = 0x7fffe9f547c0 + bprm = { + buf = "\177ELF\001\001\001\000\000\000\000\000\000\000\000\000\002\000L\000\001\000\000\000\006\001\b\000\064\000\000\000\264\006\000\000\000\000\000\000\064\000 \000\003\000(\000\016\000\r\000\001\000\000\000\000\000\000\000\000\000\b\000\000\000\b\000\063\001\000\000\063\001\000\000\005\000\000\000\000 \000\000\001\000\000\000\064\001\000\000\064!\b\000\064!\b\000\000\000\000\000\f\000\000\000\006\000\000\000\000 \000\000\004\000\000\000\224\000\000\000\224\000\b\000\224\000\b\000$\000\000\000$\000\000\000\004\000\000\000\004\000\000\000\004\000\000\000\024\000\000\000\003\000\000\000GNU\000PH\017'i\204\231\070e\000\247\376\211\230\236\336Nf7\372\204\342\356\213n\206\214\342\374\201\352\253\370\201\353\273"..., + p = 0x0, + fd = 0x3, + e_uid = 0x3e8, + e_gid = 0x3d9, + argc = 0x1, + envc = 0x43, + argv = 0x564a2f9f3cc0, + envp = 0x564a2fa12600, + filename = 0x7fffe9f5703d "./basic", + core_dump = 0x0 + } + ts = 0x564a2fa25400 + env = 0x564a2fa24a08 + cpu = 0x564a2fa1c730 + optind = 0x3 + target_environ = 0x564a2fa12600 + wrk = 0x7fffe9f550b8 + target_argv = 0x564a2f9f3cc0 + target_argc = 0x1 + i = 0x1 + ret = 0x7fff + execfd = 0x3 + log_mask = 0x0 + max_reserved_va = 0xffffe000 +#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6 +No symbol table info available. +#7 0x0000564a2f786cee in _start () +No symbol table info available. + + +The binary itself is just a basic binary that prints "hello\n" to stdout. I have attached it. + + + +Sounds like it's probably the bug where we don't correctly handle ELF BSS segments which have no content in the file at all (ie they're just "zero this memory" with no content). If so, this patch (currently in review) will fix it: +https://<email address hidden>/ +and you could also work around it by making sure your guest binary has some r/w data so it doesn't have a segment that's purely BSS. + + +That did indeed fix it, thank you! + + +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/123 + + +ON7WPI: Is QEMU version 6.0 now working fine for you? + +Yes, this is working for me now. The binary still crashes, but I think that's a problem in my code instead of QEMU. + +Ok, thanks for the confirmation! + diff --git a/results/classifier/zero-shot/108/permissions/1914117 b/results/classifier/zero-shot/108/permissions/1914117 new file mode 100644 index 000000000..c02f36773 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1914117 @@ -0,0 +1,451 @@ +permissions: 0.983 +semantic: 0.968 +debug: 0.963 +boot: 0.962 +performance: 0.962 +network: 0.961 +other: 0.960 +graphic: 0.956 +device: 0.956 +PID: 0.954 +files: 0.948 +vnc: 0.907 +socket: 0.872 +KVM: 0.769 + +Short files returned via FTP on Qemu with various architectures and OSes + + +Qemu 5.2 on Mac OS X Big Sur. + +I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +Still getting the same problem,. + +On the following architectures: +arm64, amd64 and sometimes i386 running NetBSD host OS; +i386 running OpenBSD host OS: + +I have seen a consistent problem with FTP returning short files. The file will be a couple of bytes too short. I do not believe this is a problem with the OS. Downloading the perl source code from CPAN does not work properly, nor does downloading bind from isc. I've tried this on different architectures as above. + +(Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My gut feel is there is something not right on the Mac OS version of Qemu or a bug in 5.2 - obviously in the network layer somewhere. If you have anything you want me to try, please let me know - happy to help get a resolution.) + +Please provide more information: How did you compile QEMU? Which version did you exactly use? And most important: How do you *run* QEMU? System emulation? User mode? What kind of FTP are you doing?? + +Apologies. + + +Host OS is Big Sur Mac OS X latest - with Xcode latest. Qemu is 5.2 - tar ball directly from the website. + +- Compile Qemu on Mac OS/Big Sur - completely stock build : install Ninja, mkdir build && cd build && ../configure && make && make install +- But also the issue is with the binary in home-brew (e.g. brew install Qemu) - both methods get me to the same problem. + +* Installed NetBSD/amd64 or i386 or OpenBSD/i386. +Qemu-image create -f raw image 10G +qmu-system-ARCH -m 256M -hda image -cdrom “netbsd.iso” -boot d -net user -net nic + +(For i386 & amd64 I tend to add -nographic for the installer) + +* Run the image: +Qmu-system-ARCH -m 256M -hda $IMAGE -net user -net nic + +Also NetBSD/arm64 has the issue using their image. +qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 4 -m 4g \ + -drive if=none,file=netbsd-disk-arm64.img,id=hd0 -device virtio-blk-device,drive=hd0 \ + -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \ + -bios QEMU_EFI.fd -nographic + +* The issue seems to be downloading large files. +In the host OS two files that seem to tickle the bug often are: + +* ftp -a http://cpan.pair.com/src/5.0/perl-5.32.1.tar.xz +On NetBSD this file seems to be one byte shorter than it should be. On arm64 is was several bytes shorter. + +* ftp -a ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Also seems to tickle the bug + +I saw this while trying to use pkgsrc on NetBSD. Saw this on Amd64, i386 and arm64. Tried OpenBSD to rule out NetBSD as the problem. OpenBSD/i386 sees the same issue (ftp returns short read and file is a couple of bytes smaller). + +The screenshot is from amd64 - a fresh boot this morning running on a fairly idle host. + +Kind regards +Chris + + +Apologies. + + +Host OS is Big Sur Mac OS X latest - with Xcode latest. Qemu is 5.2 - tar ball directly from the website. + +- Compile Qemu on Mac OS/Big Sur - completely stock build : install Ninja, mkdir build && cd build && ../configure && make && make install +- But also the issue is with the binary in home-brew (e.g. brew install Qemu) - both methods get me to the same problem. + +* Installed NetBSD/amd64 or i386 or OpenBSD/i386. +Qemu-image create -f raw image 10G +qmu-system-ARCH -m 256M -hda image -cdrom “netbsd.iso” -boot d -net user -net nic + +(For i386 & amd64 I tend to add -nographic for the installer) + +* Run the image: +Qmu-system-ARCH -m 256M -hda $IMAGE -net user -net nic + +Also NetBSD/arm64 has the issue using their image. +qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 4 -m 4g \ + -drive if=none,file=netbsd-disk-arm64.img,id=hd0 -device virtio-blk-device,drive=hd0 \ + -netdev type=user,id=net0 -device virtio-net-device,netdev=net0,mac=00:11:22:33:44:55 \ + -bios QEMU_EFI.fd -nographic + +* The issue seems to be downloading large files. +In the host OS two files that seem to tickle the bug often are: + +* ftp -a http://cpan.pair.com/src/5.0/perl-5.32.1.tar.xz +On NetBSD this file seems to be one byte shorter than it should be. On arm64 is was several bytes shorter. + +* ftp -a ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Also seems to tickle the bug + + + +I saw this while trying to use pkgsrc on NetBSD. Saw this on Amd64, i386 and arm64. Tried OpenBSD to rule out NetBSD as the problem. OpenBSD/i386 sees the same issue (ftp returns short read and file is a couple of bytes smaller). + +The screenshot is from amd64 - a fresh boot this morning running on a fairly idle host. + +Kind regards +Chris + +> On 2 Feb 2021, at 05:24, Thomas Huth <email address hidden> wrote: +> +> Please provide more information: How did you compile QEMU? Which version +> did you exactly use? And most important: How do you *run* QEMU? System +> emulation? User mode? What kind of FTP are you doing?? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions + + + +Some more info. + +This evening I've tried some more things. + +Qemu 5.2/Mac OS X Catalina (Qemu from home-brew) + +Host OS - OpenBSD/i386 +1. Booted with + +2. Booted with +qemu-system-i386 -m 256M -hda openbsd-disk-i386.img -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 + +With both ftp'ed ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz +Both were short and did not match the find at ISC. + +See attached. SHA1 should be 1bfb5725c85fd9dffe868d8e826a1f8c0de509cc + + +First boot in previous comment was with: +qemu-system-i386 -m 256M -hda openbsd-disk-i386.img -net user -net nic + +I've spent some more time on this. +I've tcpdump'ed the connection whilst doing the download (via both HTTP & FTP). + +In the last data packet, the last byte that is missing on the filesystem is in the packet, but the packet has the urgent bit set with the urgent pointer the same as the length of the packet. + +I'm not sure but this might cause the client app to discard part of the packet? +Unclear. + +Also I've build Qemu 4.2.1 on MacOS X/Big Sur - I'm seeing the same issue on FreeBSD/amd64. +This bug might be related: +https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237441 + + +The more I look at this, the more I think it may be a macOS bug underneath. + +I've tested OpenBSD as a guest on a Debian AWS instance running 4.2.1 - all is fine. +I've tested OpenBSD as a guest on a FreeBSD AWS instance running whatever is in ports and all is fine. + +Also others are having trouble: +https://twitter.com/astr0baby/status/1354952352713887754 +Mac OS on M1 silicon with Free and NetBSD as guest OS. + + +This is NOT a fix but we can get working FTPs again with this patch - narrowing into where the problem is. Looks like the behaviour of this code is different on macOS to other OSes. + +--- slirp.c.orig 2021-02-08 21:05:20.000000000 +0000 ++++ slirp.c 2021-02-10 11:00:00.000000000 +0000 +@@ -621,18 +621,7 @@ + * This will soread as well, so no need to + * test for SLIRP_POLL_IN below if this succeeds + */ +- if (revents & SLIRP_POLL_PRI) { +- ret = sorecvoob(so); +- if (ret < 0) { +- /* Socket error might have resulted in the socket being +- * removed, do not try to do anything more with it. */ +- continue; +- } +- } +- /* +- * Check sockets for reading +- */ +- else if (revents & ++ if (revents & + (SLIRP_POLL_IN | SLIRP_POLL_HUP | SLIRP_POLL_ERR)) { + /* + * Check for incoming connections + +ok - one of my friends has written a test program. we will provide a writeup tomorrow, but basically towards the end of a stream both HUP & PRI are getting set on a poll call (on Mac) which means the code above would be invoked - on other platforms these aren't see. Better explanation & more details to follow tomorrow. + + +Writeup as promised. + +Symptom: +-------- +Qemu on Mac OS X - both Catalina and Big Sur. +The issue occurs in both 5.2 and 4.2* branches of Qemu. + +Applications such as ftp that read large amounts of data from the network +may ignore valid data due to the Urgent flag being set on packets in the +stream. + +- Install a Unix VM (e.g. NetBSD, OpenBSD, etc) on Qemu using Mac OS X. +- Try to FTP a large file, such as + ftp://ftp.isc.org/isc/bind9/9.16.11/bind-9.16.11.tar.xz + and you will be one byte short (not just this file, it's just an ex). + +Synopsis: +--------- +- On inspection, the urgent flag is being set on the last packet of data +- As a result data is missing and is not received by the client app + because it is considered out of band. +- poll() on Mac OS X has different behaviour to other Unices. +- towards the end of a stream, PRI and HUP are sent (whereas on FreeBSD + and others it is not) +- as a result of PRI, the slirp library used in Qemu for the user + network interface adds an urgent bit to the relevant packets + +To see the different behaviour, we setup a server to serve a large file +and wrote a client to receive it, using poll() and dumping information about the flags. + +Here is FreeBSD - the IN flag is set throughout. + +ec2-user@freebsd:~/polltest $ ./a.out -w -P lXXX.net +Resolving lXXX.net: trying XXX.XXX.XXX.XXX... OK +FD 3 ready: POLLIN +Read 1024 byte(s) +FD 3 ready: POLLIN +Read 1024 total byte(s) +[snipped] + +FD 3 ready: POLLIN +Read 102400 total byte(s) +ec2-user@freebsd:~/polltest $ + +Here is Mac OS X (Big Sur). You can see at the end of the stream, +both PRI & HUP are set. + +Resolving lXXX.net: trying XXX.XXX.XXX.XXX .. OK +FD 5 ready: POLLIN +Read 1024 byte(s) +[Snipped] + +FD 5 ready: POLLIN +Read 416 byte(s) +FD 5 ready: POLLIN POLLPRI POLLHUP +Hangup on FD 5 +Read 160 byte(s) +FD 5 ready: POLLIN POLLPRI POLLHUP +Hangup on FD 5 +Read 102400 total byte(s) + +Towards a fix: +-------------- +The following patch removes the symptom simply by ignoring these flags. +This is not necessarily the final answer, but we have run with this patch +for a couple of days and haven't seen any negative behaviour. + +diff -ru qemu-5.2.0/slirp/src/slirp.c qemu-5.2.0-wrk/slirp/src/slirp.c +--- qemu-5.2.0/slirp/src/slirp.c 2021-02-10 11:02:07.000000000 +0000 ++++ qemu-5.2.0-wrk/slirp/src/slirp.c 2021-02-10 13:07:17.000000000 +0000 +@@ -23,7 +23,7 @@ + * THE SOFTWARE. + */ + #include "slirp.h" +- ++#define IGNOREPOLLPRI + + #ifndef _WIN32 + #include <net/if.h> +@@ -621,6 +621,8 @@ + * This will soread as well, so no need to + * test for SLIRP_POLL_IN below if this succeeds + */ ++ ++#ifndef IGNOREPOLLPRI + if (revents & SLIRP_POLL_PRI) { + ret = sorecvoob(so); + if (ret < 0) { +@@ -633,6 +635,9 @@ + * Check sockets for reading + */ + else if (revents & ++#else ++ if (revents & ++#endif + (SLIRP_POLL_IN | SLIRP_POLL_HUP | SLIRP_POLL_ERR)) { + /* + * Check for incoming connections + + +Adam Chappell figured most of this out (because a. he is (mostly) cleverer than me, b. he didn't sell his copy of Stevens UNIX Network Programming like I did in the 00s). + +Maybe related: +https://bugs.launchpad.net/qemu/+bug/1916344 +(and https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 ) + +libslirp now has a workaround for this in slirp.c. + +Could we close this ticket now if there is a workaround in libslirp now? + +If it’s included in qemu when one downloads the sources I’m happy. + +Sent from my iPhone + +> On 15 May 2021, at 11:55, Thomas Huth <email address hidden> wrote: +> +> Could we close this ticket now if there is a workaround in libslirp now? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions + + +slirp has been updated for QEMU 6.1-rc2, so this should be fixed in the latest 6.1 release candidate. If you've got some spare minutes, could you please check whether it's working for you now in 6.1-rc4 ? + +I tested Qemu 6.1 (MacOS using brew to install) with guest OS NetBSD/i386. The bind distribution file downloaded fine by FTP. +Libslurp has a workaround for MacOS and it looks like its gone in. +I think this one can be closed. +Sorry for the delay +Kind regards +Chris + + +> On 25 Aug 2021, at 08:18, Thomas Huth <email address hidden> wrote: +> +> ** Changed in: qemu +> Status: Fix Committed => Fix Released +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1914117 +> +> Title: +> Short files returned via FTP on Qemu with various architectures and +> OSes +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> +> Qemu 5.2 on Mac OS X Big Sur. +> +> I originally thought that it might be caused by the home-brew version of Qemu, but this evening I have removed the brew edition and compiled from scratch (using Ninja & Xcode compiler). +> Still getting the same problem,. +> +> On the following architectures: +> arm64, amd64 and sometimes i386 running NetBSD host OS; +> i386 running OpenBSD host OS: +> +> I have seen a consistent problem with FTP returning short files. The +> file will be a couple of bytes too short. I do not believe this is a +> problem with the OS. Downloading the perl source code from CPAN does +> not work properly, nor does downloading bind from isc. I've tried this +> on different architectures as above. +> +> (Qemu 4.2 on Ubuntu/x86_64 with NetBSD/i386 seems to function fine. My +> gut feel is there is something not right on the Mac OS version of Qemu +> or a bug in 5.2 - obviously in the network layer somewhere. If you +> have anything you want me to try, please let me know - happy to help +> get a resolution.) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914117/+subscriptions +> + + + diff --git a/results/classifier/zero-shot/108/permissions/1920913 b/results/classifier/zero-shot/108/permissions/1920913 new file mode 100644 index 000000000..ff9b80d29 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1920913 @@ -0,0 +1,447 @@ +permissions: 0.938 +other: 0.932 +debug: 0.925 +PID: 0.898 +performance: 0.881 +semantic: 0.868 +device: 0.862 +files: 0.856 +socket: 0.851 +vnc: 0.849 +KVM: 0.848 +graphic: 0.847 +network: 0.831 +boot: 0.811 + +Openjdk11+ fails to install on s390x + +While installing openjdk11 or higher from repo, it crashes while configuring ca-certificates-java. +Although `java -version` passes, `jar -version` crashes. Detailed logs attached to this issue. + +``` +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x00000040126f9980, pid=8425, tid=8430 +# +# JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-Ubuntu-0ubuntu1.20.04) +# Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode, tiered, compressed oops, g1 gc, linux-s390x) +# Problematic frame: +# J 4 c1 java.lang.StringLatin1.hashCode([B)I java.base@11.0.10 (42 bytes) @ 0x00000040126f9980 [0x00000040126f9980+0x0000000000000000] +# +# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to //core.8425) +# +# An error report file with more information is saved as: +# //hs_err_pid8425.log +sed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /root/core.10740) +# +# An error report file with more information is saved as: +# /root/hs_err_pid10740.log +``` + +Observed this on s390x/ubuntu as well as alpine when run on amd64. +Please note, on native s390x, the installation is successful. Also this crash is not observed while installing openjdk-8-jdk. + +Qemu version: 5.2.0 + +Please let me know if any more details are needed. + + + +You don't say how you're invoking QEMU (system emulation? usermode? what command line?) Please give the full commandline, repro steps, and any files/images we would need to reproduce the failure. + + +Please find below steps to reproduce the issue(Running on amd64 VM): + +``` +apt-get install -y qemu qemu-user-static +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +docker run -it s390x/ubuntu:20.04 bash +--> apt-get update && apt-get install -y openjdk-11-jdk + jar --version +``` + + + +Same BUG as https://bugs.launchpad.net/qemu/+bug/1862874 + +Tried building jdk 11 from source, the generated executable still crashes(fastdebug as well as release mode): + +``` +root@24d396a17e00:~/jdk# build/linux-s390x-normal-server-release/jdk/bin/java -version +# +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x000000400b234440, pid=18175, tid=18178 +# +# JRE version: OpenJDK Runtime Environment (11.0) (build 11-internal+0-adhoc..jdk) +# Java VM: OpenJDK 64-Bit Server VM (11-internal+0-adhoc..jdk, mixed mode, tiered, compressed oops, g1 gc, linux-s390x) +# Problematic frame: +# J 78 c1 java.util.HashMap.afterNodeInsertion(Z)V java.base (1 bytes) @ 0x000000400b234440 [0x000000400b234400+0x0000000000000040] +# +# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /root/jdk/core.18175) +# +# An error report file with more information is saved as: +# /root/jdk/hs_err_pid18175.log +Compiled method (c1) 1795 78 3 java.util.HashMap::afterNodeInsertion (1 bytes) + total in heap [0x000000400b234210,0x000000400b2345b0] = 928 + relocation [0x000000400b234378,0x000000400b2343a0] = 40 + constants [0x000000400b2343c0,0x000000400b234400] = 64 + main code [0x000000400b234400,0x000000400b234500] = 256 + stub code [0x000000400b234500,0x000000400b234558] = 88 + metadata [0x000000400b234558,0x000000400b234568] = 16 + scopes data [0x000000400b234568,0x000000400b234578] = 16 + scopes pcs [0x000000400b234578,0x000000400b2345a8] = 48 + dependencies [0x000000400b2345a8,0x000000400b2345b0] = 8 +Compiled method (c1) 1806 74 3 java.util.HashMap::putVal (300 bytes) + total in heap [0x000000400b230210,0x000000400b231f20] = 7440 + relocation [0x000000400b230378,0x000000400b230690] = 792 + constants [0x000000400b2306c0,0x000000400b230a00] = 832 + main code [0x000000400b230a00,0x000000400b231980] = 3968 + stub code [0x000000400b231980,0x000000400b231a68] = 232 + metadata [0x000000400b231a68,0x000000400b231ad0] = 104 + scopes data [0x000000400b231ad0,0x000000400b231ce8] = 536 + scopes pcs [0x000000400b231ce8,0x000000400b231eb8] = 464 + dependencies [0x000000400b231eb8,0x000000400b231ec0] = 8 + nul chk table [0x000000400b231ec0,0x000000400b231f20] = 96 +Could not load hsdis-s390x.so; library not loadable; PrintAssembly is disabled +# +# If you would like to submit a bug report, please visit: +# http://bugreport.java.com/bugreport/crash.jsp +# +Aborted (core dumped) +root@24d396a17e00:~/jdk# +``` + +@davidhildenbrand The other issue which you have mentioned as duplicate shows java getting stuck for long, whereas for me it crashes right away. Do you think these 2 are related? + +Also observed another behaviour : +java -version randomly passes, sometimes. + +I can also confirm that it is observed under s390x chroot as well(logs below): +``` +root@XX:/# ulimit -c unlimited +root@XX:/# java -version +openjdk version "11.0.10" 2021-01-19 +OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubuntu1.20.04) +OpenJDK 64-Bit Server VM (build 11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode) +root@XX:/# java -version +# +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x0000004012705b40, pid=156601, tid=156604 +# +# JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-Ubuntu-0ubuntu1.20.04) +# Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode, tiered, compressed oops, g1 gc, linux-s390x) +# Problematic frame: +# J 5 c1 java.lang.Object.<init>()V java.base@11.0.10 (1 bytes) @ 0x0000004012705b40 [0x0000004012705b00+0x0000000000000040] +# +# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to //core.156601) +# +# An error report file with more information is saved as: +# //hs_err_pid156601.log +Compiled method (c1) 956 5 3 java.lang.Object::<init> (1 bytes) + total in heap [0x0000004012705910,0x0000004012705cb8] = 936 + relocation [0x0000004012705a70,0x0000004012705aa0] = 48 + constants [0x0000004012705ac0,0x0000004012705b00] = 64 + main code [0x0000004012705b00,0x0000004012705c00] = 256 + stub code [0x0000004012705c00,0x0000004012705c58] = 88 + metadata [0x0000004012705c58,0x0000004012705c70] = 24 + scopes data [0x0000004012705c70,0x0000004012705c80] = 16 + scopes pcs [0x0000004012705c80,0x0000004012705cb0] = 48 + dependencies [0x0000004012705cb0,0x0000004012705cb8] = 8 +Compiled method (c1) 960 5 3 java.lang.Object::<init> (1 bytes) + total in heap [0x0000004012705910,0x0000004012705cb8] = 936 + relocation [0x0000004012705a70,0x0000004012705aa0] = 48 + constants [0x0000004012705ac0,0x0000004012705b00] = 64 + main code [0x0000004012705b00,0x0000004012705c00] = 256 + stub code [0x0000004012705c00,0x0000004012705c58] = 88 + metadata [0x0000004012705c58,0x0000004012705c70] = 24 + scopes data [0x0000004012705c70,0x0000004012705c80] = 16 + scopes pcs [0x0000004012705c80,0x0000004012705cb0] = 48 + dependencies [0x0000004012705cb0,0x0000004012705cb8] = 8 +Could not load hsdis-s390x.so; library not loadable; PrintAssembly is disabled +# +# If you would like to submit a bug report, please visit: +# https://bugs.launchpad.net/ubuntu/+source/openjdk-lts +# +Aborted (core dumped) +root@XX:/# ulimit -c unlimited +root@XX:/# java -version +# +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x0000004012706a40, pid=156619, tid=156622 +# +# JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-Ubuntu-0ubuntu1.20.04) +# Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode, tiered, compressed oops, g1 gc, linux-s390x) +# Problematic frame: +# J 4 c1 java.lang.Object.<init>()V java.base@11.0.10 (1 bytes) @ 0x0000004012706a40 [0x0000004012706a00+0x0000000000000040] +# +. +(truncating logs) + +Aborted (core dumped) +root@XX:/# +``` + +Increasing core limit worked once, but it fails eventually. + +Could you please share your thoughts and provide some pointers on debugging further? + + + + +As java -version passes few times, further also checked behaviour of Maven. Observed that mvn -v crashes in a similar fashion, however after setting below: +export MAVEN_OPTS="-XX:-TieredCompilation -XX:+UseG1GC -Dcount=1000000" + +mvn -v always passes. + +root@XX:/# mvn -v +OpenJDK 64-Bit Server VM warning: You have loaded library /apache-maven-3.6.3/lib/jansi-native/linux64/libjansi.so which might have disabled stack guard. The VM will try to fix the stack guard now. +It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'. +Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) +Maven home: /apache-maven-3.6.3 +Java version: 11.0.7, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-s390x +Default locale: en_US, platform encoding: ANSI_X3.4-1968 +OS name: "linux", version: "5.4.0-70-generic", arch: "s390x", family: "unix" + + +However what I am really interested in, is mvn clean install command which never passes with above settings. + +@davidhildenbrand, any help would be appreciated. + + +Hi @davidhildenbrand, I'm on the same team as @nam121 and I've been looking at this issue as well. + +I think this is the same issue as: https://github.com/multiarch/qemu-user-static/issues/129 + +I've been running an s390x docker image on a master build (with latest s390x commit from Apr 23) of user mode qemu-s390x-static with some debug logging on: + +$ sudo docker run -e QEMU_CPU="qemu" -e QEMU_LOG="unimp,guest_errors" -e QEMU_LOG_FILENAME="/s390x/qemu_s390x.log" + +I ran a simple java program with: + +$ java -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:PrintAssemblyOptions=hsdis-print-bytes -XX:+LogCompilation -XX:LogFile=java_compilation_log.log Main > java_out.txt + +and the qemu log contained just one line: + +unimplemented opcode 0x0000 + +Note that if the JIT is turned off with 'java -Xint', then all programs I've tried run without problem. + +The hs_err file reports a SIGILL in the same spot as in the other comments: + +--- SNIP +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x00000040126d7680, pid=208, tid=211 +# +# JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-Ubuntu-0ubuntu1.20.04) +# Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-Ubuntu-0ubuntu1.20.04, compiled mode, tiered, compressed oops, g1 gc, linux-s390x) +# Problematic frame: +# J 9 c1 java.lang.String.hashCode()I java.base (49 bytes) @ 0x00000040126d7680 [0x00000040126d7640+0x0000000000000040] +--- SNIP +--- SNIP +Instructions: (pc=0x00000040126d7680) +0x00000040126d7580: 00000040 5f5f4140 00000040 5f5f4140 +0x00000040126d7590: 00000040 5f5f4140 00000040 5f5f4140 +0x00000040126d75a0: 00000040 5f5f4358 00000040 5f5f4358 +0x00000040126d75b0: 00000040 5f5f4358 00000040 5f5f4358 +0x00000040126d75c0: 00000040 5f5f4140 00000040 5f5f4140 +0x00000040126d75d0: 00000000 00000000 ffffffff ffffffff +0x00000040126d75e0: 00000040 5f5f4140 00000000 00000000 +0x00000040126d75f0: ffffffff ffffffff 00000040 5f3fb9d0 +0x00000040126d7600: 00000040 12238c00 00000040 12232800 +0x00000040126d7610: 00000040 5f3fef18 00000040 12238c00 +0x00000040126d7620: 00000040 12235000 00000000 00000000 +0x00000040126d7630: 00000000 00000000 00000000 00000000 +0x00000040126d7640: b9040009 cc08ffff fff85500 2008a784 # <-- String.hashCode() entry point at 0x00000040126d7640 +0x00000040126d7650: 0019a51d 0040c019 12167a80 07f10700 +0x00000040126d7660: 07000700 07000700 07000700 07000700 +0x00000040126d7670: 07000700 07000700 07000700 07000700 +0x00000040126d7680: 0000f000 ec51e3e0 f0080024 b904000f # <-- note 0x0000 at 0x00000040126d7680 +0x00000040126d7690: a7fbffa0 e300f000 0024c438 ffffff73 +--- SNIP + +The assembly printed by java looks like: + +--- SNIP +[Entry Point] + # {method} {0x000000405f3fb9d0} 'hashCode' '()I' in 'java/lang/String' + # [sp+0x60] (sp of caller) + 0x00000040126d7640: lgr %r0,%r9 ;...b9040009 + ; {no_reloc} + 0x00000040126d7644: aih %r0,-8 ;...cc08ffff fff8 + + 0x00000040126d764a: cl %r0,8(%r2) ;...55002008 + + 0x00000040126d764e: je 0x00000040126d7680 ;...a7840019 + + 0x00000040126d7652: llihl %r1,64 ;...a51d0040 + + 0x00000040126d7656: iilf %r1,303463040 ;...c0191216 7a80 + + 0x00000040126d765c: br %r1 ;...07f1 + + 0x00000040126d765e: nopr ;...0700 + + 0x00000040126d7660: nopr ;...0700 + + 0x00000040126d7662: nopr ;...0700 + + 0x00000040126d7664: nopr ;...0700 + + 0x00000040126d7666: nopr ;...0700 + + 0x00000040126d7668: nopr ;...0700 + + 0x00000040126d766a: nopr ;...0700 + + 0x00000040126d766c: nopr ;...0700 + + 0x00000040126d766e: nopr ;...0700 + + 0x00000040126d7670: nopr ;...0700 + + 0x00000040126d7672: nopr ;...0700 + + 0x00000040126d7674: nopr ;...0700 + + 0x00000040126d7676: nopr ;...0700 + + 0x00000040126d7678: nopr ;...0700 + + 0x00000040126d767a: nopr ;...0700 + + 0x00000040126d767c: nopr ;...0700 + + 0x00000040126d767e: nopr ;...0700 + +[Verified Entry Point] + 0x00000040126d7680: tmy -81920(%r15),222 ;...ebdef000 ec51 + + 0x00000040126d7686: stg %r14,8(%r15) ;...e3e0f008 0024 + + 0x00000040126d768c: lgr %r0,%r15 ;...b904000f + + 0x00000040126d7690: aghi %r15,-96 ;...a7fbffa0 + + 0x00000040126d7694: stg %r0,0(%r15) ;...e300f000 0024 + + 0x00000040126d769a: lgrl %r3,0x00000040126d7580 + ;...c438ffff ff73 + ; {metadata(method data for {method} {0x000000405f3fb9d0} 'hashCode' '()I' in 'java/lang/String')} +--- SNIP + +so IIUC java says its generating 0xebde at 0x00000040126d7680 instead of 0x0000. + +Hope the above makes sense. I'm not sure where to go from here so any suggestions would be a great help. + +From looking at the in_asm logs, it looks like that instruction starting with 0xebde is executed once with no problem but the second time its changed to 0x0000. + +... # First Time +---------------- +IN: +0x40126d6880: ebde f000 ec51 tmy -0x14000(%r15), 0xde +0x40126d6886: e3e0 f008 0024 stg %r14, 8(%r15) +0x40126d688c: b904 000f lgr %r0, %r15 +0x40126d6890: a7fb ffa0 aghi %r15, -0x60 +0x40126d6894: e300 f000 0024 stg %r0, 0(%r15) +0x40126d689a: c438 ffff ff73 lgrl %r3, 0x40126d6780 +0x40126d68a0: 5840 30dc l %r4, 0xdc(%r3) +0x40126d68a4: c248 0000 0008 agfi %r4, 8 +0x40126d68aa: 5040 30dc st %r4, 0xdc(%r3) +0x40126d68ae: c0f4 0000 00d1 jg 0x40126d6a50 +PSW=mask 0000000180000000 addr 00000040126d6880 cc CC_OP_LTGT0_64 +R00=0000000000000000 R01=00000040126d6880 R02=00000006296f5d20 R03=00000006296f5d20 +R04=000000405f45fcd8 R05=00000006000000e8 R06=0000004012169380 R07=0000004002c410e8 +R08=0000004004019000 R09=000000405f2d29d0 R10=0000004002c41048 R11=00000006296095e0 +R12=000000400280ec50 R13=0000004002c411d0 R14=00000040126d5c64 R15=0000004002c40e88 + +... # Second Time +unimplemented opcode 0x0000 +---------------- +IN: +PSW=mask 0000000180000000 addr 00000040126d6880 cc CC_OP_LTUGTU_32 +R00=0000000000001808 R01=00000040126d53c0 R02=00000006296f5d78 R03=00000006296f5d78 +R04=000000405f45fcd8 R05=00000006000000f0 R06=0000004012114000 R07=5f9dbb3700003030 +R08=0000004004019000 R09=0000000800001808 R10=0000004002c41048 R11=00000006296095e0 +R12=000000400280ec50 R13=0000004002c411d0 R14=00000040126d5c64 R15=0000004002c40e88 + +Some more analysis: +Tried to explicitely compile as well as exclude few methods during compilation such as 'java.lang.StringLatin1::hashCode', 'java.util.concurrent.ConcurrentHashMap', 'java.lang.String*' which are part of trace as logged in above comments, with the help of advanced JIT options. +However it is not good enough to draw any conclusion as `java -version` command passes on random runs. `mvn -v` which consistently fails, is seen to be passing always with any of above combination set using MAVEN_OPTS. + +Also compared the assembly log as @jonalbrecht mentioned above on qemu setup vs native s390x for `mvn -v` command. +The initial few compiled methods match, however it fails for 'java.lang.String::isLatin1': + +Failure in qemu : +ImmutableOopMap{Z_R2=Oop }pc offsets: 170 232 244 272 Compiled method (c1) 1077 12 2 java.lang.String::equalsIgnoreCase (45 bytes) + total in heap [0x00000040117f2210,0x00000040117f28b0] = 1696 + relocation [0x00000040117f2370,0x00000040117f23c8] = 88 + constants [0x00000040117f2400,0x00000040117f2440] = 64 + main code [0x00000040117f2440,0x00000040117f2600] = 448 + stub code [0x00000040117f2600,0x00000040117f2668] = 104 + metadata [0x00000040117f2668,0x00000040117f2688] = 32 + scopes data [0x00000040117f2688,0x00000040117f2738] = 176 + scopes pcs [0x00000040117f2738,0x00000040117f2888] = 336 + dependencies [0x00000040117f2888,0x00000040117f2890] = 8 + nul chk table [0x00000040117f2890,0x00000040117f28b0] = 32 + +ImmutableOopMap{}pc offsets: 288 +ImmutableOopMap{Z_R2=Oop Z_R5=Oop }pc offsets: 372 +ImmutableOopMap{Z_R5=Oop Z_R2=Oop }pc offsets: 384 392 400 unimplemented opcode 0x0000 +# +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x00000040117f1680, pid=11738, tid=11787 +# +# JRE version: OpenJDK Runtime Environment (11.0.11+9) (build 11.0.11+9-Ubuntu-0ubuntu2.20.04) +# Java VM: OpenJDK 64-Bit Server VM (11.0.11+9-Ubuntu-0ubuntu2.20.04, compiled mode, tiered, compressed oops, g1 gc, linux-s390x) +# Problematic frame: +# J 9 c1 java.lang.String.hashCode()I java.base (49 bytes) @ 0x00000040117f1680 [0x00000040117f1640+0x0000000000000040] +# +# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to //core.11738) +# +# An error report file with more information is saved as: +# //hs_err_pid11738.log + + +vs + +Native s390x log: +ImmutableOopMap{Z_R2=Oop }pc offsets: 170 232 244 272 Compiled method (c1) 34 12 2 java.lang.String::equalsIgnoreCase (45 bytes) + total in heap [0x000003ff7a097110,0x000003ff7a0977b0] = 1696 + relocation [0x000003ff7a097270,0x000003ff7a0972c8] = 88 + constants [0x000003ff7a097300,0x000003ff7a097340] = 64 + main code [0x000003ff7a097340,0x000003ff7a097500] = 448 + stub code [0x000003ff7a097500,0x000003ff7a097568] = 104 + metadata [0x000003ff7a097568,0x000003ff7a097588] = 32 + scopes data [0x000003ff7a097588,0x000003ff7a097638] = 176 + scopes pcs [0x000003ff7a097638,0x000003ff7a097788] = 336 + dependencies [0x000003ff7a097788,0x000003ff7a097790] = 8 + nul chk table [0x000003ff7a097790,0x000003ff7a0977b0] = 32 + +ImmutableOopMap{}pc offsets: 276 +ImmutableOopMap{Z_R2=Oop Z_R5=Oop }pc offsets: 360 +ImmutableOopMap{Z_R5=Oop Z_R2=Oop }pc offsets: 372 380 388 Compiled method (c1) 34 13 2 java.lang.String::isLatin1 (19 bytes) + total in heap [0x000003ff7a097810,0x000003ff7a097c10] = 1024 + relocation [0x000003ff7a097970,0x000003ff7a097990] = 32 + constants [0x000003ff7a0979c0,0x000003ff7a097a00] = 64 + main code [0x000003ff7a097a00,0x000003ff7a097b40] = 320 + stub code [0x000003ff7a097b40,0x000003ff7a097b98] = 88 + metadata [0x000003ff7a097b98,0x000003ff7a097ba0] = 8 + scopes data [0x000003ff7a097ba0,0x000003ff7a097bb8] = 24 + scopes pcs [0x000003ff7a097bb8,0x000003ff7a097c08] = 80 + dependencies [0x000003ff7a097c08,0x000003ff7a097c10] = 8 + +.................................................. + + +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/319 + + diff --git a/results/classifier/zero-shot/108/permissions/1921468 b/results/classifier/zero-shot/108/permissions/1921468 new file mode 100644 index 000000000..058ba9837 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1921468 @@ -0,0 +1,324 @@ +permissions: 0.933 +semantic: 0.889 +other: 0.884 +network: 0.878 +boot: 0.846 +graphic: 0.841 +PID: 0.832 +performance: 0.811 +socket: 0.797 +device: 0.797 +debug: 0.761 +KVM: 0.748 +files: 0.732 +vnc: 0.706 + +[UBUNTU 20.04] KVM guest fails to find zipl boot menu index + +---Problem Description--- +A KVM guest fails to find the zipl boot menu index if the "zIPL" magic value is listed at the end of a disk block. + +---System Hang--- +System sits in disabled wait, last console display +LOADPARM=[ ] +Using virtio-blk. +Using ECKD scheme (block size 4096), CDL +VOLSER=[0X0067] + + +---Steps to Reproduce--- +1. Install Distro KVM guest from ISO on a DASD, e.g. using virt-install, my invocation was +$ virt-install --name secguest2 --memory 2048 --disk path=/dev/disk/by-path/ccw-0.0.af6a --cdrom /var/lib/libvirt/images/xxxxxx.iso + +2. Select DHCP networking and ASCII console, and accept all defaults of the installer + +3. Let the installer reboot after the installation completes + +It is possible to recover by editing the domain XML with an explicit loadparm to select a boot menu entry. E.g. I changed the disk definition to + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/disk/by-path/ccw-0.0.af6a'/> + <target dev='vda' bus='virtio'/> + <boot order='1' loadparm='1'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0xaf6a'/> + </disk> + +The patches are now upstream: +5f97ba0c74cc ("pc-bios/s390-ccw: fix off-by-one error") +468184ec9024 ("pc-bios/s390-ccw: break loop if a null block number is reached") + +Current versions of qemu within Ubuntu + +focal (20.04LTS) 1:4.2-3ubuntu6 [ports]: arm64 armhf ppc64el s390x +focal-updates (metapackages): 1:4.2-3ubuntu6.14: amd64 arm64 armhf ppc64el s390x + +groovy (20.10) (metapackages): 1:5.0-5ubuntu9 [ports]: arm64 armhf ppc64el s390x +groovy-updates (metapackages): 1:5.0-5ubuntu9.6: amd64 arm64 armhf ppc64el s390x + +hirsute (metapackages): 1:5.2+dfsg-9ubuntu1: amd64 arm64 armhf ppc64el s390x + + +git-commits will apply seamlessley for the requested levels if not already integrated + +------- Comment From <email address hidden> 2021-03-26 04:38 EDT------- +Just to avoid any bad surprise, these patches require a rebuild of the bios image so the binary must also be updated. + +This already is in upstream qemu 5.2, thereby Hirsute is fixed already. +I'll prep PPAs for a try for Focal/Groovy in a bit + +PPA is here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4504 + +Would you mind to check if this really is enough and all that you'd need? +Once that is confirmed I can prep this for the SRU process. + +Hi @Christan B. :-) +With "rebuild of the bios image" I guess you meant: + /usr/share/qemu/s390-ccw.img + /usr/share/qemu/s390-netboot.img +Those are built from the same source, so fixing and building src:qemu fixes this in one go. + +If you had other binaries in mind let me know. + +------- Comment From <email address hidden> 2021-03-29 07:42 EDT------- +(In reply to comment #12) +> Hi @Christan B. :-) +> With "rebuild of the bios image" I guess you meant: +> /usr/share/qemu/s390-ccw.img +> /usr/share/qemu/s390-netboot.img +> Those are built from the same source, so fixing and building src:qemu fixes +> this in one go. +> +> If you had other binaries in mind let me know. + +Yes I had these 2 in mind. +I was not sure if Ubuntu always builds these files or if you use the pre-build ones. + +Hi, +I have tested this with: +$ virt-install --name testinst1 --memory 2048 --disk path=/dev/disk/by-path/ccw-0.0.151e --cdrom /var/lib/libvirt/images/ubuntu-18.04.5-server-s390x.iso + +But while the issue itself and the fix is clear, this did not trigger the issue. +In my case the reboot after install worked just fine even without the fix. +Might I ask: +- which "xxxxxx.iso" it is in your example that has issues with this? +- which disk setup did you select on install (that is then put onto the dasd by the installer) +- what should I expect in the error case, I expected a fail or hang on reboot but got: + +``` +The system is going down NOW! +Sent SIGTERM to all processes +Sent SIGKILL to all processes +Requesting system reboot + +Domain creation completed.ts; <Enter> activates buttons +Restarting guest. +Connected to domain testinst1 +Escape character is ^] + +Booting entry #0 +[ 0.450525] Linux version 4.15.0-140-generic (buildd@bos02-s390x-010) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #144-Ubuntu SMP Fri Mar 19 14:11:29 UTC 2021 (Ubuntu 4.15.0-140.144- +generic 4.15.18) +``` + +``` +The config (in regard to boot) that virtinst left (and that worked) was: + <os> + <type arch='s390x' machine='s390-ccw-virtio-focal'>hvm</type> + <boot dev='hd'/> + </os> +... + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/disk/by-path/ccw-0.0.151e' index='2'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/> + </disk> +``` + +I agree to the fix, but need a reasonable testcase that works (also to explain to the SRU team why this is a realistic issue someone would hit). + +Could I skip all the install description and just take a existing guest running on a dasd and then use a custom zipl.conf to trigger this? If so which zipl.conf would you recommend? + +------- Comment From <email address hidden> 2021-03-29 08:47 EDT------- +(In reply to comment #14) +> Hi, +> I have tested this with: +> $ virt-install --name testinst1 --memory 2048 --disk +> path=/dev/disk/by-path/ccw-0.0.151e --cdrom +> /var/lib/libvirt/images/ubuntu-18.04.5-server-s390x.iso +> +> But while the issue itself and the fix is clear, this did not trigger the +> issue. +> In my case the reboot after install worked just fine even without the fix. +> Might I ask: +> - which "xxxxxx.iso" it is in your example that has issues with this? + +This was a non Ubuntu distribution. It can happen on any distro that has the s390-tools commit/patch "zipl: Make use of __noreturn macro" and not the fix "zipl/libc: libc_stop move 'noreturn' to declaration" + +I spoke to cborntra, and it turned out that this affects only guests with zipl +with: 86856f98 "zipl: Make use of __noreturn macro" +but not yet: c367a6bb "zipl/libc: libc_stop move 'noreturn' to declaration" + +That means 2.12/2.13 and that translates to Focal. +Therefore retry this as: + +ubuntu@s1lp5:~$ virt-install --name testinst2 --memory 2048 --disk path=/dev/disk/by-path/ccw-0.0.151e --cdrom /var/lib/libvirt/images/ubuntu-20.04-legacy-server-s390x.iso +- all defaults - +- install as "entire disk - + +Then on reboot I get still what seems working: + +``` +The system is going down NOW! +Sent SIGTERM to all processes +Sent SIGKILL to all processes +Requesting system reboot + +Domain creation completed.ts; <Enter> activates buttons +Restarting guest. +Connected to domain testinst2 +Escape character is ^] + +Booting entry #0 +``` + +We talked further and it is also compiler specific. +Eventually any guest "could" fail and it definitely is wise to fix this. +Just verification gets harder. + +I'll try some other ISOs as instructed by Christian to see if one can be used as repro case. + + +This iso should do the trick "SLE-15-SP2-Full-s390x-GM-Media1.iso" to reproduce. + +------- Comment From <email address hidden> 2021-03-29 13:09 EDT------- +(In reply to comment #22) +> This iso should do the trick "SLE-15-SP2-Full-s390x-GM-Media1.iso" to +> reproduce. + +Yep exactly. Without the ISO it's harder to reproduce... Because then you have to (AFAICR): +1. patch your zipl code so the stage loader (I think it was stage2) has the right size +2. use this patched zipl for zipl'ing the DASD +3. use qemu to boot from this DASD + +FYI - uploaded to the -unapproved queue yesterday. Now on the SRU team to evaluate. + +Hello bugproxy, or anyone else affected, + +Accepted qemu into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:5.0-5ubuntu9.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-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. 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. + +Hello bugproxy, 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.15 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. + +I happen to know that Marc is verifying this - thanks in advance! + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.15) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +casper/1.445.1 (amd64, ppc64el) +systemd/245.4-4ubuntu3.6 (amd64) +ubuntu-image/1.11+20.04ubuntu1 (armhf, amd64, s390x) +livecd-rootfs/2.664.19 (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! + + +All autopkgtests for the newly accepted qemu (1:5.0-5ubuntu9.7) for groovy have finished running. +The following regressions have been reported in tests triggered by the package: + +systemd/246.6-1ubuntu1.3 (ppc64el) +cloud-utils/0.31-29-ge0792e3d-0ubuntu1 (s390x) +open-iscsi/2.1.1-1ubuntu2 (amd64) +ubuntu-image/1.11+20.10ubuntu1 (armhf) + + +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/groovy/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +FYI I'm working on the autopkgtest issues - but all of those are known flaky cases, so I expect no long term blocker. + +The other two bugs that are part of this SRU are verified by now, so it needs just this one to complete - which we know can be hard to re-create without special unlucky bootloader record sizes. + +On the good side, I've not seen regressions to the non-affected-boots + +@Marc - let us know once you've completed the testing + +FYI - autopkgtest issues resolved as well now (as assumed it was due to flaky tests) + +------- Comment From <email address hidden> 2021-04-08 08:37 EDT------- +@Christian: I've verified the fix works. + +Thanks (we have had way too much non-fun with no debug symbols on the roms, bootloader record sizes and so on). +I really appreciate that you went so deep on this Marc! + +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:5.0-5ubuntu9.7 + +--------------- +qemu (1:5.0-5ubuntu9.7) groovy; urgency=medium + + * d/p/u/lp-1921468-*: fix issues handling boot menu index on s390x + (LP: #1921468) + * d/p/u/lp-1887535-configure-replace-enable-disable-git-update-with-wit.patch, + d/rules: Backport --with-git-submodules param so building from git repo + doesn't fail (LP: #1887535) + * Fix byte aligned writes when writing to image stored on NFS + server, as they aren't required to be 4kib aligned. (LP: #1921665) + - d/p/u/lp-1921665-1-block-Require-aligned-image-size-to-avoid-assert.patch + - d/p/u/lp-1921665-2-file-posix-Allow-byte-aligned-O_DIRECT-with-NFS.patch + + -- Christian Ehrhardt <email address hidden> Fri, 26 Mar 2021 10:36:31 +0100 + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.15 + +--------------- +qemu (1:4.2-3ubuntu6.15) focal; urgency=medium + + * d/p/u/lp-1921468-*: fix issues handling boot menu index on s390x + (LP: #1921468) + * d/p/u/lp-1887535-configure-replace-enable-disable-git-update-with-wit.patch, + d/rules: Backport --with-git-submodules param so building from git repo + doesn't fail (LP: #1887535) + * Fix byte aligned writes when writing to image stored on NFS + server, as they aren't required to be 4kib aligned. (LP: #1921665) + - d/p/u/lp-1921665-1-block-Require-aligned-image-size-to-avoid-assert.patch + - d/p/u/lp-1921665-2-file-posix-Allow-byte-aligned-O_DIRECT-with-NFS.patch + + -- Christian Ehrhardt <email address hidden> Fri, 26 Mar 2021 10:38:47 +0100 + +------- Comment From <email address hidden> 2021-04-15 07:09 EDT------- +IBM bugzilla status-> closed, Fix Released with all requested distros + diff --git a/results/classifier/zero-shot/108/permissions/1922617 b/results/classifier/zero-shot/108/permissions/1922617 new file mode 100644 index 000000000..fa9ad2e50 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1922617 @@ -0,0 +1,257 @@ +permissions: 0.935 +other: 0.891 +debug: 0.877 +graphic: 0.868 +device: 0.862 +PID: 0.832 +boot: 0.829 +performance: 0.829 +socket: 0.810 +semantic: 0.809 +files: 0.795 +vnc: 0.780 +network: 0.767 +KVM: 0.625 + +qemu-aarch64-static "Illegal instruction" with debootstrap + +This is reproducible against QEMU master. I apologize for the long reproduction steps, I tried to distill it down as much as possible. + +System info: + +# qemu-aarch64-static --version +qemu-aarch64 version 5.2.91 (v6.0.0-rc1-68-gee82c086ba) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +# cat /etc/os-release +PRETTY_NAME="Debian GNU/Linux 10 (buster)" +NAME="Debian GNU/Linux" +VERSION_ID="10" +VERSION="10 (buster)" +VERSION_CODENAME=buster +ID=debian +HOME_URL="https://www.debian.org/" +SUPPORT_URL="https://www.debian.org/support" +BUG_REPORT_URL="https://bugs.debian.org/" + +# head -n 26 /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 85 +model name : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz +stepping : 7 +microcode : 0x5002f01 +cpu MHz : 1000.716 +cache size : 22528 KB +physical id : 0 +siblings : 32 +core id : 0 +cpu cores : 16 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 22 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d arch_capabilities +bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs taa itlb_multihit +bogomips : 4600.00 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual +power management: + +My reproduction steps: + +# apt-get install --no-install-recommends -y \ + build-essential \ + ca-certificates \ + debootstrap \ + git \ + libglib2.0-dev \ + libpixman-1-dev \ + ninja-build \ + pkg-config \ + python3 \ + zstd + +# git clone https://github.com/qemu/qemu + +# mkdir qemu/build + +# cd qemu/build + +# ../configure \ + --enable-debug \ + --enable-linux-user \ + --disable-bsd-user \ + --disable-werror \ + --disable-system \ + --disable-tools \ + --disable-docs \ + --disable-gtk \ + --disable-gnutls \ + --disable-nettle \ + --disable-gcrypt \ + --disable-glusterfs \ + --disable-libnfs \ + --disable-libiscsi \ + --disable-vnc \ + --disable-kvm \ + --disable-libssh \ + --disable-libxml2 \ + --disable-vde \ + --disable-sdl \ + --disable-opengl \ + --disable-xen \ + --disable-fdt \ + --disable-vhost-net \ + --disable-vhost-crypto \ + --disable-vhost-user \ + --disable-vhost-vsock \ + --disable-vhost-scsi \ + --disable-tpm \ + --disable-qom-cast-debug \ + --disable-capstone \ + --disable-zstd \ + --disable-linux-io-uring \ + --static \ + --target-list-exclude=hexagon-linux-user + +# ninja qemu-aarch64 + +# install -Dm755 qemu-aarch64 /usr/local/bin/qemu-aarch64-static + +# cat <<'EOF' >/proc/sys/fs/binfmt_misc/register +:qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-aarch64-static:CF +EOF + +# debootstrap --arch arm64 --foreign buster debian-rootfs + +# chroot debian-rootfs /debootstrap/debootstrap --second-stage +Illegal instruction + +This prevents me from building an arm64 Debian image on x86_64. If I am doing something wrong, please let me know. The binary has been uploaded for your convenience. + + + +This won't be the cause of the crash, but: don't run ninja directly. The build instructions (documented in README.rst) haven't changed: run configure, and then run make. The makefile still does some things and is not a pure does-absolutely-nothing wrapper around ninja in all cases. + + + +I'm able to reproduce a coredump o("Illegal Instruction", but of host type) during a debootstrap process. The coredump is for a grep process, I'm trying to bisect. + +Bisected to + +commit 26bab757d41b853ea84cb52a10fafc9c10069658 +Author: Richard Henderson <email address hidden> +Date: Fri Feb 12 10:48:33 2021 -0800 + + linux-user: Introduce PAGE_ANON + + Record whether the backing page is anonymous, or if it has file + backing. This will allow us to get close to the Linux AArch64 + ABI for MTE, which allows tag memory only on ram-backed VMAs. + + The real ABI allows tag memory on files, when those files are + on ram-backed filesystems, such as tmpfs. We will not be able + to implement that in QEMU linux-user. + + Thankfully, anonymous memory for malloc arenas is the primary + consumer of this feature, so this restricted version should + still be of use. + + Reviewed-by: Peter Maydell <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + + +Possible fix: +https://<email address hidden>/msg796781.html + +The fix that Phil links would only pertain if debootstrap were +actively using MTE. I think we can safely disregard that. + +I don't believe that the bisect has worked. There is nothing in +that 3 line patch that would affect *anything*, as the PAGE_ANON +value is not used at this point. + +Yes, applying the patch pointed out by Philippe doesn't fix the problem. + +But I think bisect has worked fine. + +If I revert this patch (26bab757d41), it works fine again. + +I revert: + +"target/arm: Add allocation tag storage for user mode" + "linux-user: Introduce PAGE_ANON" + +Only reverting the first patch doesn't fix the problem. + +Perhaps the reason is: + +include/exec/cpu-all.h + +#define PAGE_ANON 0x0080 +... +#define PAGE_TARGET_1 0x0080 + + +commit be5d6f4884021208ae0e73379c83e51500ad3a8d +Author: Richard Henderson <email address hidden> +Date: Wed Oct 21 10:37:39 2020 -0700 + + linux-user: Set PAGE_TARGET_1 for TARGET_PROT_BTI + + Transform the prot bit to a qemu internal page bit, and save + it in the page tables. + + Reviewed-by: Peter Maydell <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> +... + +diff --git a/target/arm/cpu.h b/target/arm/cpu.h +index 49cd5cabcf2a..c18a91676656 100644 +--- a/target/arm/cpu.h ++++ b/target/arm/cpu.h +@@ -3445,6 +3445,11 @@ static inline MemTxAttrs *typecheck_memtxattrs(MemTxAttrs *x) + #define arm_tlb_bti_gp(x) (typecheck_memtxattrs(x)->target_tlb_bit0) + #define arm_tlb_mte_tagged(x) (typecheck_memtxattrs(x)->target_tlb_bit1) + ++/* ++ * AArch64 usage of the PAGE_TARGET_* bits for linux-user. ++ */ ++#define PAGE_BTI PAGE_TARGET_1 ++ + /* + * Naming convention for isar_feature functions: + * Functions which test 32-bit ID registers should have _aa32_ in +diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c +index 71888083417d..072754fa24d4 100644 +--- a/target/arm/translate-a64.c ++++ b/target/arm/translate-a64.c +@@ -14507,10 +14507,10 @@ static void disas_data_proc_simd_fp(DisasContext *s, uint32_t insn) + */ + static bool is_guarded_page(CPUARMState *env, DisasContext *s) + { ++ uint64_t addr = s->base.pc_first; + #ifdef CONFIG_USER_ONLY +- return false; /* FIXME */ ++ return page_get_flags(addr) & PAGE_BTI; + #else +- uint64_t addr = s->base.pc_first; + int mmu_idx = arm_to_core_mmu_idx(s->mmu_idx); + unsigned int index = tlb_index(env, mmu_idx, addr); + CPUTLBEntry *entry = tlb_entry(env, mmu_idx, addr); + + + +Ouch, yes indeed. Will fix. + +Fix commit: 52c01ada8661 ("exec: Fix overlap of PAGE_ANON and PAGE_TARGET_1") + diff --git a/results/classifier/zero-shot/108/permissions/1925512 b/results/classifier/zero-shot/108/permissions/1925512 new file mode 100644 index 000000000..0db9e9333 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1925512 @@ -0,0 +1,133 @@ +permissions: 0.954 +other: 0.930 +device: 0.908 +performance: 0.881 +semantic: 0.880 +debug: 0.855 +PID: 0.847 +socket: 0.803 +files: 0.791 +network: 0.743 +boot: 0.720 +vnc: 0.719 +graphic: 0.718 +KVM: 0.711 + +UNDEFINED case for instruction BLX + +Hi + +I refer to the instruction BLX imm (T2 encoding) in ARMv7 (Thumb mode). + +11110 S imm10H 11 J1 0 J2 imm10L H + + +if H == '1' then UNDEFINED; +I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10H:imm10L:'00', 32); +targetInstrSet = InstrSet_A32; +if InITBlock() && !LastInITBlock() then UNPREDICTABLE; + +According to the manual, if H equals to 1, this instruction should be an UNDEFINED instruction. However, it seems QEMU does not check this constraint in function trans_BLX_i. Thanks + +Regards +Muhui + +It's right there in trans_BLX_i: + + if (s->thumb && (a->imm & 2)) { + return false; + } + + +Hi + +I still feel QEMU's implementation is not right. Could you please check it again. + +According to https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Instruction-Details/Alphabetical-list-of-instructions/BL--BLX--immediate-?lang=en + +The encoding T2 for BLX is below: + +15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + 1 1 1 1 0 S | imm10H | 1 1 J1 0 J2 | imm10L |H + +In the ASL of ARM, we have H == '1' then UNDEFINED; + +Symbol *H* represents the last bit of this instruction. I am not sure whether a->imm includes the symbol *H*. I double checked the file `t32.decode` and it seems so (It would be great if you can tell me what a->imm indeed represents in BLX). + +However, UNDEFINED means unallocated encoding in ARM manual. The right behavior might be something like below: + + if (s->thumb && (a->imm & 2)) { + unallocated_encoding(s); + return true; + } + +Correct me if I am wrong. I can also provide test case if you need. Many Thanks + +Regards +Muhui + + + + +The complete imm32 is computed by + +%imm24 26:s1 13:1 11:1 16:10 0:11 !function=t32_branch24 + +so that H appears at bit 1 in a->imm in trans_BLX_i. + +Returning false from any trans_* function means that the trans +function did not match. In some cases, this means that the next +possible matching pattern is tested. But in most cases, such as +this one, we return all the way to disas_thumb2_insn, where we +do in fact call unallocated_encoding. + +If you have a test case that fails, please provide it. + +Hi + +Thanks for your reply. I don't think return false is the right behavior here. H is related to decoding rather than encoding phase. The value of symbol *H* should not be used to check whether the (encoding) pattern is matched or not. In other words, whatever value H is, if the bytecode meet the pattern of BLX in Thumb T2 encoding, it should be a BLX instruction. + +During the decoding phase, QEMU should check whether H equals to 1. If so, a SIGILL signal should be raised. Please see a concrete case below: + +Below is the sample code, and 0xf279cf25 has the encoding pattern of instruction BLX. H is 1 here. + +int main() +{ + __asm__(".inst.w 0xf279cf25"); + printf("no signal\n"); +} + + +I cross compiled it in thumb mode and generate the binary named test_BLX, which is attached. I set a breakpoint at 0x102f0. The value in 0x102f0 is 0xf279cf25, which should be an UNDEFINED instruction and a SIGILL signal should be raised when executing this instruction. + +Breakpoint 1, 0x000102f0 in ?? () +gef> x/4i $pc +=> 0x102f0: ; <UNDEFINED> instruction: 0xf279cf25 + 0x102f4: ldr r3, [pc, #12] ; (0x10304) + 0x102f6: movs r0, r3 + 0x102f8: bl 0x5fe28 + +When I use si to execute the instruction at 0x102f0, it will jump to 0x102f6. No signal is raised. Finally, the program will be exit without any raised signal. + +gef> si +0x000102f6 in ?? () + +I don't think this should be the right behavior. The same binary is tested on a physical ARM device and SIGILL is triggered. Return false seems not work here. Many Thanks + +Regards +Muhui + + +Thanks for the test case. + +The problem is that we have raised the UDEF exception, +and then the qemu kernel emulation code has decided that +we should emulate the instruction as an FPE11 instruction. + +Which seems clearly incorrect, given we're in thumb mode. + +Proposed patch: +https://<email address hidden>/ + +The patches from Richard have now been merged (see https://gitlab.com/qemu-project/qemu/-/commit/c1438d6c02eae03c and the following commits). Thus marking this as "Fix committed" now. + diff --git a/results/classifier/zero-shot/108/permissions/1967248 b/results/classifier/zero-shot/108/permissions/1967248 new file mode 100644 index 000000000..6504c5c92 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1967248 @@ -0,0 +1,59 @@ +permissions: 0.966 +other: 0.954 +semantic: 0.933 +device: 0.914 +PID: 0.911 +graphic: 0.907 +debug: 0.891 +performance: 0.873 +files: 0.864 +boot: 0.837 +vnc: 0.730 +network: 0.586 +KVM: 0.499 +socket: 0.470 + +qemu: uncaught target signal 5 (Trace/breakpoint trap) + +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +$qemu-arm --version +qemu-arm version 6.2.0 +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. +But it's coredump. + +It seem to can not upload a binary? + +This bug tracker is no longer being used by the QEMU project. It looks like you found our new tracker, though: https://gitlab.com/qemu-project/qemu/-/issues/952 + + diff --git a/results/classifier/zero-shot/108/permissions/1970563 b/results/classifier/zero-shot/108/permissions/1970563 new file mode 100644 index 000000000..d29378573 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/1970563 @@ -0,0 +1,134 @@ +permissions: 0.925 +other: 0.873 +semantic: 0.870 +vnc: 0.868 +socket: 0.824 +graphic: 0.810 +PID: 0.786 +KVM: 0.757 +performance: 0.745 +network: 0.743 +device: 0.741 +files: 0.686 +debug: 0.670 +boot: 0.613 + +Qemu 1:6.2+dfsg-2ubuntu6 deadlock bug + +There is a known bug that will cause VM deadlock, the patch should be merged and released: + +https://gitlab.com/qemu-project/qemu/-/commit/1dbbe6f172810026c51dc84ed927a3cc23017949#841723aa93098d8ab3b5068795e10ae7cf2a3179 + +That's clearly a fix for a bug, but I couldn't identify an upstream issue which describes the problem. The commit message has: + + Fixes: 0bf41cab + +but that's a reference to another commit, not to an issue. Finding original description of the bug would help identifying a test case for the SRU. + +@xp are you able to point us to the upstream bug report, or to provide steps to reproduce the issue which we can use to verify the fix? + +I'm marking this as Incomplete for now because the description of the problem is too vague, but I think this will become a valid SRU case. + +This should be the upstream bug report: +https://gitlab.com/qemu-project/qemu/-/issues/807 + + +Thanks, that report also has nice steps to reproduce. I updated the bug tags/status accordingly. + +Thanks + +From the description this bug affects Jammy and Kinetic, so I added explicit tasks for each series. + +Thanks this is great pre-work and a patch on a plate. +I was pondering if I should wait until we merge qemu 7.0 for kintic, but that would delay this too much. + +I still need to find some time, but I'll prepare and upload the fix without waiting for 7.0. + +FYI - I have prepared a PPA and merge proposals for the related Ubuntu package changes: + +PPA: https://launchpad.net/~paelzer/+archive/ubuntu/lp-1970563-vnc-deadlock +Jammy: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/422947 +Kinetic: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/422946 + +Thanks for the Review Sergio. + +Uploaded the fix for Kinetic. +We can start the SRU to jammy once it is complete there. + +This bug was fixed in the package qemu - 1:6.2+dfsg-2ubuntu7 + +--------------- +qemu (1:6.2+dfsg-2ubuntu7) kinetic; urgency=medium + + * d/p/u/lp-1970563-ui-vnc.c-Fixed-a-deadlock-bug.patch: avoid deadlock + in vnc connections (LP: #1970563) + + -- Christian Ehrhardt <email address hidden> Thu, 19 May 2022 08:25:20 +0200 + +Completed in Kinetic, uploaded to Jammy now - waiting for the SRU team to have a look + +Hello xp, or anyone else affected, + +Accepted qemu into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:6.2+dfsg-2ubuntu6.1 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-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. 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:6.2+dfsg-2ubuntu6.1) for jammy have finished running. +The following regressions have been reported in tests triggered by the package: + +vagrant-mutate/1.2.0-4.1 (s390x, ppc64el) +livecd-rootfs/2.764 (arm64, ppc64el) +ubuntu-image/2.2+22.04ubuntu3 (arm64, s390x) +sbuild/0.81.2ubuntu6 (s390x, ppc64el) +edk2/2022.02-3 (armhf) +initramfs-tools/0.140ubuntu13 (amd64) +systemd/249.11-0ubuntu3.1 (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/jammy/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +FYI: Autopkgtest issues resolved, but verification of the upload for the presented problem is needed. + +@XP - it is always best to do this in the original reported environment - do you think you could do that verification? + +Sure, This my test steps: +* start a qemu wit qemu vnc + qemu-system-x86_64 -vnc 127.0.0.1:0 ... + +* Connect and disconnect and connect with VNC against it (We use novnc). + +* when qemu-system-x86 1:6.2+dfsg-2ubuntu6 + occur which deadlocks qemu - no interaction is possible anymore + +* upgrade to qemu-system-x86/jammy-proposed 1:6.2+dfsg-2ubuntu6.1 + Connect and disconnect and connect, everything is ok， no more deadlock + +The bug has been fixed, thank you. + +Perfect, thank you Xiongpeng! + +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:6.2+dfsg-2ubuntu6.1 + +--------------- +qemu (1:6.2+dfsg-2ubuntu6.1) jammy; urgency=medium + + * d/p/u/lp-1970563-ui-vnc.c-Fixed-a-deadlock-bug.patch: avoid deadlock + in vnc connections (LP: #1970563) + + -- Christian Ehrhardt <email address hidden> Thu, 19 May 2022 08:25:20 +0200 + diff --git a/results/classifier/zero-shot/108/permissions/2013 b/results/classifier/zero-shot/108/permissions/2013 new file mode 100644 index 000000000..7e7276ba9 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2013 @@ -0,0 +1,93 @@ +permissions: 0.945 +socket: 0.900 +vnc: 0.900 +debug: 0.891 +boot: 0.881 +device: 0.875 +KVM: 0.861 +semantic: 0.851 +PID: 0.848 +performance: 0.841 +graphic: 0.827 +other: 0.822 +network: 0.803 +files: 0.788 + +The avocado test replay_kernel.py:ReplayKernelNormal.test_mips64el_malta is unreliable +Description of problem: +This test keeps hanging on CI +Steps to reproduce: +Run the test on GitLab's CI infrastructure and it will hang on replay. Examples: https://gitlab.com/stsquad/qemu/-/jobs/5664260736 +Additional information: +Excerpt from log: + +``` +18:02:49 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'. +18:02:49 DEBUG| Opening console file +18:02:49 DEBUG| Opening console socket +18:02:49 DEBUG| [ 0.000000] Initializing cgroup subsys cpuset +18:02:49 DEBUG| [ 0.000000] Initializing cgroup subsys cpu +18:02:49 DEBUG| [ 0.000000] Linux version 2.6.32-5-5kc-malta (Debian 2.6.32-48) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Feb 15 21:38:11 UTC 2013 +18:02:49 DEBUG| [ 0.000000] +18:02:49 DEBUG| [ 0.000000] LINUX started... +18:02:49 DEBUG| [ 0.000000] bootconsole [early0] enabled +18:02:49 DEBUG| [ 0.000000] CPU revision is: 000182a0 (MIPS 20Kc) +18:02:49 DEBUG| [ 0.000000] FPU revision is: 000f8200 +18:02:49 DEBUG| [ 0.000000] Checking for the multiply/shift bug... no. +18:02:49 DEBUG| [ 0.000000] Checking for the daddiu bug... no. +18:02:49 DEBUG| [ 0.000000] Determined physical RAM map: +18:02:49 DEBUG| [ 0.000000] memory: 0000000000001000 @ 0000000000000000 (reserved) +18:02:49 DEBUG| [ 0.000000] memory: 00000000000ef000 @ 0000000000001000 (ROM data) +18:02:49 DEBUG| [ 0.000000] memory: 0000000000659000 @ 00000000000f0000 (reserved) +18:02:49 DEBUG| [ 0.000000] memory: 00000000078b7000 @ 0000000000749000 (usable) +18:02:49 DEBUG| [ 0.000000] Wasting 104440 bytes for tracking 1865 unused pages +18:02:49 DEBUG| [ 0.000000] Initrd not found or empty - disabling initrd +18:02:49 DEBUG| [ 0.000000] Zone PFN ranges: +18:02:49 DEBUG| [ 0.000000] DMA 0x00000000 -> 0x00001000 +18:02:49 DEBUG| [ 0.000000] Normal 0x00001000 -> 0x00008000 +18:02:49 DEBUG| [ 0.000000] Movable zone start PFN for each node +18:02:49 DEBUG| [ 0.000000] early_node_map[1] active PFN ranges +18:02:49 DEBUG| [ 0.000000] 0: 0x00000000 -> 0x00008000 +18:02:49 DEBUG| [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32320 +18:02:49 DEBUG| [ 0.000000] Kernel command line: printk.time=1 panic=-1 console=ttyS0 +18:02:49 DEBUG| Shutting down VM appliance; timeout=30 +18:02:49 DEBUG| Attempting graceful termination +18:02:49 DEBUG| Closing console file +18:02:49 DEBUG| Closing console socket +18:02:49 DEBUG| Politely asking QEMU to terminate +... + +18:02:49 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'. +18:02:49 DEBUG| Opening console file +18:02:49 DEBUG| Opening console socket +18:02:49 DEBUG| [ 0.000000] Initializing cgroup subsys cpuset +18:02:49 DEBUG| [ 0.000000] Initializing cgroup subsys cpu +18:02:49 DEBUG| [ 0.000000] Linux version 2.6.32-5-5kc-malta (Debian 2.6.32-48) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Fri Feb 15 21:38:11 UTC 2013 +18:02:49 DEBUG| [ 0.000000] +18:02:49 DEBUG| [ 0.000000] LINUX started... +18:02:49 DEBUG| [ 0.000000] bootconsole [early0] enabled +18:02:49 DEBUG| [ 0.000000] CPU revision is: 000182a0 (MIPS 20Kc) +18:02:49 DEBUG| [ 0.000000] FPU revision is: 000f8200 +18:02:49 DEBUG| [ 0.000000] Checking for the multiply/shift bug... no. +18:02:49 DEBUG| [ 0.000000] Checking for the daddiu bug... no. +18:02:49 DEBUG| [ 0.000000] Determined physical RAM map: +18:02:49 DEBUG| [ 0.000000] memory: 0000000000001000 @ 0000000000000000 (reserved) +18:02:49 DEBUG| [ 0.000000] memory: 00000000000ef000 @ 0000000000001000 (ROM data) +18:02:49 DEBUG| [ 0.000000] memory: 0000000000659000 @ 00000000000f0000 (reserved) +18:02:49 DEBUG| [ 0.000000] m +18:04:48 ERROR| +18:04:48 ERROR| Reproduced traceback from: /builds/stsquad/qemu/build/pyvenv/lib/python3.10/site-packages/avocado/core/test.py:770 +18:04:48 ERROR| Traceback (most recent call last): +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 147, in test_mips64el_malta +18:04:48 ERROR| self.run_rr(kernel_path, kernel_command_line, console_pattern, shift=5) +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 78, in run_rr +18:04:48 ERROR| t2 = self.run_vm(kernel_path, kernel_command_line, console_pattern, +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/replay_kernel.py", line 61, in run_vm +18:04:48 ERROR| self.wait_for_console_pattern(console_pattern, vm) +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/boot_linux_console.py", line 52, in wait_for_console_pattern +18:04:48 ERROR| wait_for_console_pattern(self, success_message, +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/avocado_qemu/__init__.py", line 199, in wait_for_console_pattern +18:04:48 ERROR| _console_interaction(test, success_message, failure_message, None, vm=vm) +18:04:48 ERROR| File "/builds/stsquad/qemu/build/tests/avocado/avocado_qemu/__init__.py", line 148, in _console_interaction +18:04:48 ERROR| msg = console.readline().decode().strip() +``` diff --git a/results/classifier/zero-shot/108/permissions/2157 b/results/classifier/zero-shot/108/permissions/2157 new file mode 100644 index 000000000..e93d493d3 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2157 @@ -0,0 +1,58 @@ +permissions: 0.951 +graphic: 0.889 +device: 0.855 +performance: 0.822 +PID: 0.809 +files: 0.788 +socket: 0.747 +vnc: 0.746 +network: 0.744 +other: 0.567 +debug: 0.558 +semantic: 0.524 +boot: 0.478 +KVM: 0.367 + +qemu-user fails to run 32-bit x86 binaries on hosts with a page size > 4KB +Description of problem: +`qemu-i386` refuses to run 32-bit x86 binaries on hosts with a page size > 4KB +(such as LoongArch, ppc64le, arm64 with 3 level page tables). +Steps to reproduce: +1. Compile x86 binary which makes a single exit(0) syscall: + ``` + cat > exit0.S << EOF + #include <sys/syscall.h> + .text + .global _start + _start: + movl $__NR_exit, %eax + movl $0, %ebx + int $0x80 + EOF + i586-linux-gnu-gcc -nostdlib -static -no-pie -o exit0 exit0.S + ``` + Alternatively one might compile it on a x86 host: + ``` + gcc -m32 -nostdlib -static -no-pie -o exit0 exit0.S + ``` + and transfer the `exit0` binary to ppc64/LoongArch/arm64 system + + 2. Run the `exit0` binary with `qemu-i386` + ``` + qemu-i386-static ./exit0 + ``` + + # +Additional information: +`.text` segment of (32-bit) x86 binaries is typically aligned at 4KB: +``` +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + LOAD 0x000000 0x08048000 0x08048000 0x00100 0x00100 R 0x1000 + LOAD 0x001000 0x08049000 0x08049000 0x0000c 0x0000c R E 0x1000 + NOTE 0x0000b4 0x080480b4 0x080480b4 0x0004c 0x0004c R 0x4 + GNU_PROPERTY 0x0000d8 0x080480d8 0x080480d8 0x00028 0x00028 R 0x4 +``` + +Thus on a host with a page size being 64 KB (ppc64, arm64 with 3 level page tables) or 16 KB (LoongArch) +alignment requirements in [pbg_dynamic](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c?ref_type=heads#L3020) can not be satisfied. diff --git a/results/classifier/zero-shot/108/permissions/2169 b/results/classifier/zero-shot/108/permissions/2169 new file mode 100644 index 000000000..e2605c72e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2169 @@ -0,0 +1,408 @@ +permissions: 0.952 +performance: 0.921 +other: 0.919 +device: 0.918 +semantic: 0.907 +boot: 0.901 +debug: 0.893 +network: 0.890 +files: 0.888 +graphic: 0.888 +PID: 0.885 +socket: 0.881 +KVM: 0.862 +vnc: 0.836 + +qemu-system-s390x crashes with s390_swap_bfp_rounding_mode: code should not be reached +Description of problem: +Ubuntu 23.10 was installed on a s390x emulated platform some time ago. The system was setup, an open source project was built and tested. The system rebooted several times. + +Several days later, qemu crashed while the command `apt update` was running in the guest. The error was: +``` +ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached +Bail out! ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached +Abort trap: 6 +``` + +Now, each time the virtual machine is booted, qemu immediately crashes all the time at the end of the boot with the same error. The virtual machine is no longer usable. +Steps to reproduce: +1. Run the above command. +2. It crashes at the end of the boot. +Additional information: +The disk image `disk.qcow2` is 3.7 GB large, too large to be attached here. + +Full boot log: +``` +qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -nographic \ + -drive file=disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none \ + -device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk0,bootindex=1 \ + -nic user,hostfwd=tcp::2222-:22 +LOADPARM=[ ] +Using virtio-blk. +Using SCSI scheme. +......... +KASLR disabled: CPU has no PRNG +KASLR disabled: CPU has no PRNG +[ 0.561037] Linux version 6.5.0-14-generic (buildd@bos02-s390x-003) (s390x-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.41) #14-Ubuntu SMP Tue Nov 14 14:16:58 UTC 2023 (Ubuntu 6.5.0-14.14-generic 6.5.3) +[ 0.562868] setup: Linux is running under KVM in 64-bit mode +[ 0.601125] setup: The maximum memory size is 8192MB +[ 0.601577] setup: Relocating AMODE31 section of size 0x00003000 +[ 0.603756] cpu: 8 configured CPUs, 0 standby CPUs +[ 34.401410] Write protected kernel read-only data: 22272k +[ 34.548843] Zone ranges: +[ 34.548873] DMA [mem 0x0000000000000000-0x000000007fffffff] +[ 34.549570] Normal [mem 0x0000000080000000-0x00000001ffffffff] +[ 34.549609] Movable zone start for each node +[ 34.549633] Early memory node ranges +[ 34.549664] node 0: [mem 0x0000000000000000-0x00000001ffffffff] +[ 34.549979] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff] +[ 34.619124] percpu: Embedded 31 pages/cpu s87552 r8192 d31232 u126976 +[ 34.621042] Kernel command line: root=/dev/disk/by-path/ccw-0.0.0002-part1 +[ 34.622253] random: crng init done +[ 34.624460] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) +[ 34.625511] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) +[ 34.626568] Fallback order for Node 0: 0 +[ 34.627026] Built 1 zonelists, mobility grouping on. Total pages: 2064384 +[ 34.627069] Policy zone: Normal +[ 34.627356] mem auto-init: stack:all(zero), heap alloc:on, heap free:off +[ 34.669390] Memory: 8169740K/8388608K available (14780K kernel code, 3496K rwdata, 7492K rodata, 6376K init, 1312K bss, 218868K reserved, 0K cma-reserved) +[ 34.677279] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 +[ 34.678165] ftrace: allocating 38640 entries in 151 pages +[ 34.967308] ftrace: allocated 151 pages with 5 groups +[ 34.977052] rcu: Hierarchical RCU implementation. +[ 34.977093] rcu: RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=8. +[ 34.977196] Rude variant of Tasks RCU enabled. +[ 34.977209] Tracing variant of Tasks RCU enabled. +[ 34.977329] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. +[ 34.977360] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 +[ 35.023854] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3 +[ 35.026445] rcu: srcu_init: Setting srcu_struct sizes based on contention. +[ 35.027768] clocksource: tod: mask: 0xffffffffffffffff max_cycles: 0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns +[ 35.032313] Console: colour dummy device 80x25 +[ 35.036054] printk: console [ttysclp0] enabled +[ 35.038867] pid_max: default: 32768 minimum: 301 +[ 35.044407] LSM: initializing lsm=lockdown,capability,landlock,yama,apparmor,integrity +[ 35.044879] landlock: Up and running. +[ 35.044911] Yama: becoming mindful. +[ 35.046994] AppArmor: AppArmor initialized +[ 35.048281] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 35.048366] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) +[ 35.079199] RCU Tasks Rude: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1. +[ 35.079584] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1. +[ 35.081422] rcu: Hierarchical SRCU implementation. +[ 35.081465] rcu: Max phase no-delay instances is 1000. +[ 35.087248] smp: Bringing up secondary CPUs ... +[ 35.109842] smp: Brought up 1 node, 8 CPUs +[ 35.133520] devtmpfs: initialized +[ 35.143534] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +[ 35.143848] futex hash table entries: 2048 (order: 7, 524288 bytes, linear) +[ 35.155409] NET: Registered PF_NETLINK/PF_ROUTE protocol family +[ 35.158309] audit: initializing netlink subsys (disabled) +[ 35.160126] audit: type=2000 audit(1708008415.080:1): state=initialized audit_enabled=0 res=1 +[ 35.162149] Spectre V2 mitigation: execute trampolines +[ 35.218877] iommu: Default domain type: Translated +[ 35.218963] iommu: DMA domain TLB invalidation policy: strict mode +[ 35.221010] SCSI subsystem initialized +[ 35.221925] pps_core: LinuxPPS API ver. 1 registered +[ 35.221953] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 35.233495] NetLabel: Initializing +[ 35.233538] NetLabel: domain hash size = 128 +[ 35.233569] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 35.234452] NetLabel: unlabeled traffic allowed by default +[ 35.490582] VFS: Disk quotas dquot_6.6.0 +[ 35.490828] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 35.492088] hugetlbfs: disabling because there are no supported hugepage sizes +[ 35.494605] AppArmor: AppArmor Filesystem Enabled +[ 35.537129] NET: Registered PF_INET protocol family +[ 35.538412] IP idents hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 35.553748] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes, linear) +[ 35.554033] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) +[ 35.554241] TCP established hash table entries: 65536 (order: 7, 524288 bytes, linear) +[ 35.555185] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear) +[ 35.555971] TCP: Hash tables configured (established 65536 bind 65536) +[ 35.558027] MPTCP token hash table entries: 8192 (order: 5, 196608 bytes, linear) +[ 35.558386] UDP hash table entries: 4096 (order: 5, 131072 bytes, linear) +[ 35.558715] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes, linear) +[ 35.560408] NET: Registered PF_UNIX/PF_LOCAL protocol family +[ 35.560888] NET: Registered PF_XDP protocol family +[ 35.566276] Trying to unpack rootfs image as initramfs... +[ 35.583376] kvm-s390: SIE is not available +[ 35.584037] hypfs: The hardware system does not support hypfs +[ 35.686516] Initialise system trusted keyrings +[ 35.688015] Key type blacklist registered +[ 35.689131] workingset: timestamp_bits=45 max_order=21 bucket_order=0 +[ 35.689516] zbud: loaded +[ 35.693314] squashfs: version 4.0 (2009/01/31) Phillip Lougher +[ 35.695879] fuse: init (API version 7.38) +[ 35.699171] integrity: Platform Keyring initialized +[ 35.808827] Key type asymmetric registered +[ 35.808973] Asymmetric key parser 'x509' registered +[ 35.809365] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) +[ 35.810660] io scheduler mq-deadline registered +[ 35.816790] hvc_iucv: The z/VM IUCV HVC device driver cannot be used without z/VM +[ 35.846919] loop: module loaded +[ 35.851530] tun: Universal TUN/TAP device driver, 1.6 +[ 35.853032] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log. +[ 35.853186] device-mapper: uevent: version 1.0.3 +[ 35.854080] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com +[ 35.854360] drop_monitor: Initializing network drop monitor service +[ 35.963712] NET: Registered PF_INET6 protocol family +[ 36.335556] Freeing initrd memory: 23592K +[ 36.587317] Segment Routing with IPv6 +[ 36.587633] In-situ OAM (IOAM) with IPv6 +[ 36.588291] NET: Registered PF_PACKET protocol family +[ 36.589147] Key type dns_resolver registered +[ 36.590364] cio: Channel measurement facility initialized using format extended (mode autodetected) +[ 36.592594] sclp_sd: Store Data request failed (eq=2, di=3, response=0x40f0, flags=0x00, status=0, rc=-5) +[ 36.593406] ap: The hardware system does not support AP instructions +[ 36.599059] virtio_blk virtio0: 1/0/0 default/read/poll queues +[ 36.604778] virtio_blk virtio0: [vda] 62914560 512-byte logical blocks (32.2 GB/30.0 GiB) +[ 36.621065] registered taskstats version 1 +[ 36.623865] vda: vda1 +[ 36.630114] Loading compiled-in X.509 certificates +[ 36.639995] Loaded X.509 cert 'Build time autogenerated kernel key: ffca65de79457ba2128edde155db56e4bec9b799' +[ 36.642859] Loaded X.509 cert 'Canonical Ltd. Live Patch Signing: 14df34d1a87cf37625abec039ef2bf521249b969' +[ 36.646267] Loaded X.509 cert 'Canonical Ltd. Kernel Module Signing: 88f752e560a1e0737e31163a466ad7b70a850c19' +[ 36.646336] blacklist: Loading compiled-in revocation X.509 certificates +[ 36.647551] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0' +[ 36.647791] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2017): 242ade75ac4a15e50d50c84b0d45ff3eae707a03' +[ 36.648026] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (ESM 2018): 365188c1d374d6b07c3c8f240f8ef722433d6a8b' +[ 36.648252] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2019): c0746fd6c5da3ae827864651ad66ae47fe24b3e8' +[ 36.648455] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v1): a8d54bbb3825cfb94fa13c9f8a594a195c107b8d' +[ 36.648669] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v2): 4cf046892d6fd3c9a5b03f98d845f90851dc6a8c' +[ 36.648876] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v3): 100437bb6de6e469b581e61cd66bce3ef4ed53af' +[ 36.649092] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (Ubuntu Core 2019): c1d57b8f6b743f23ee41f4f7ee292f06eecadfb9' +[ 36.679176] Key type .fscrypt registered +[ 36.679250] Key type fscrypt-provisioning registered +[ 36.788001] Key type encrypted registered +[ 36.788125] AppArmor: AppArmor sha1 policy hashing enabled +[ 36.788580] ima: No TPM chip found, activating TPM-bypass! +[ 36.788676] Loading compiled-in module X.509 certificates +[ 36.791454] Loaded X.509 cert 'Build time autogenerated kernel key: ffca65de79457ba2128edde155db56e4bec9b799' +[ 36.791525] ima: Allocated hash algorithm: sha1 +[ 36.793195] ima: No architecture policies found +[ 36.793649] evm: Initialising EVM extended attributes: +[ 36.793691] evm: security.selinux +[ 36.793729] evm: security.SMACK64 +[ 36.793751] evm: security.SMACK64EXEC +[ 36.793772] evm: security.SMACK64TRANSMUTE +[ 36.793792] evm: security.SMACK64MMAP +[ 36.793817] evm: security.apparmor +[ 36.793837] evm: security.ima +[ 36.793857] evm: security.capability +[ 36.793882] evm: HMAC attrs: 0x1 +[ 36.814426] Freeing unused kernel image (initmem) memory: 6376K +[ 36.855771] Write protected read-only-after-init data: 144k +[ 38.034069] Checked W+X mappings: passed, no unexpected W+X pages found +[ 38.034295] Run /init as init process +Loading, please wait... +Starting systemd-udevd version 253.5-1ubuntu6.1 +[ 41.012145] virtio_net virtio1 enc0: renamed from eth0 +Begin: Starting firmware auto-configuration ... done. +Begin: Loading essential drivers ... [ 48.602928] raid6: vx128x8 gen() 3084 MB/s +[ 48.603058] raid6: using algorithm vx128x8 gen() 3084 MB/s +[ 48.773302] raid6: .... xor() 1800 MB/s, rmw enabled +[ 48.773433] raid6: using s390xc recovery algorithm +[ 48.783956] xor: automatically using best checksumming function xc +done. +Begin: Running /scripts/init-premount ... done. +Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. +Begin: Running /scripts/local-premount ... [ 49.837645] Btrfs loaded, zoned=yes, fsverity=yes +Scanning for Btrfs filesystems +done. +Begin: Will now check root file system ... fsck from util-linux 2.39.1 +[/usr/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1 +/dev/vda1: recovering journal +/dev/vda1: clean, 123948/1966080 files, 1902224/7863808 blocks +done. +[ 50.624887] EXT4-fs (vda1): mounted filesystem b33ae246-95a1-494e-b967-9ab636fd714d ro with ordered data mode. Quota mode: none. +done. +Begin: Running /scripts/local-bottom ... done. +Begin: Running /scripts/init-bottom ... done. +[ 52.531666] systemd[1]: systemd 253.5-1ubuntu6.1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) +[ 52.531979] systemd[1]: Detected virtualization kvm. +[ 52.532228] systemd[1]: Detected architecture s390x. + +Welcome to Ubuntu 23.10! + +[ 52.545927] systemd[1]: Hostname set to <vms390x>. +[ 52.738383] systemd[1]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set +[ 54.251527] (sd-execu[322]: /usr/lib/systemd/system-generators/s390-cpi-vars failed with exit status 1. +[ 56.207233] systemd[1]: Queued start job for default target graphical.target. +[ 56.324910] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe. +[ OK ] Created slice system-modpr…lice - Slice /system/modprobe. +[ 56.342133] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty. +[ OK ] Created slice system-seria… - Slice /system/serial-getty. +[ 56.354987] systemd[1]: Created slice user.slice - User and Session Slice. +[ OK ] Created slice user.slice - User and Session Slice. +[ 56.359125] systemd[1]: Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch. +[ OK ] Started systemd-ask-passwo… Requests to Wall Directory Watch. +[ 56.370074] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point. +[ OK ] Set up automount proc-sys-…rmats File System Automount Point. +[ 56.373118] systemd[1]: Reached target integritysetup.target - Local Integrity Protected Volumes. +[ OK ] Reached target integrityse…Local Integrity Protected Volumes. +[ 56.374764] systemd[1]: Reached target slices.target - Slice Units. +[ OK ] Reached target slices.target - Slice Units. +[ 56.375999] systemd[1]: Reached target snapd.mounts-pre.target - Mounting snaps. +[ OK ] Reached target snapd.mounts-pre.target - Mounting snaps. +[ 56.377421] systemd[1]: Reached target veritysetup.target - Local Verity Protected Volumes. +[ OK ] Reached target veritysetup… - Local Verity Protected Volumes. +[ 56.381860] systemd[1]: Listening on dm-event.socket - Device-mapper event daemon FIFOs. +[ OK ] Listening on dm-event.sock… Device-mapper event daemon FIFOs. +[ 56.388375] systemd[1]: Listening on lvm2-lvmpolld.socket - LVM2 poll daemon socket. +[ OK ] Listening on lvm2-lvmpolld…ket - LVM2 poll daemon socket. +[ 56.394056] systemd[1]: Listening on multipathd.socket - multipathd control socket. +[ OK ] Listening on multipathd.so…t - multipathd control socket. +[ 56.399560] systemd[1]: Listening on syslog.socket - Syslog Socket. +[ OK ] Listening on syslog.socket - Syslog Socket. +[ 56.404487] systemd[1]: Listening on systemd-fsckd.socket - fsck to fsckd communication Socket. +[ OK ] Listening on systemd-fsckd…sck to fsckd communication Socket. +[ 56.407621] systemd[1]: Listening on systemd-initctl.socket - initctl Compatibility Named Pipe. +[ OK ] Listening on systemd-initc… initctl Compatibility Named Pipe. +[ 56.414642] systemd[1]: Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log). +[ OK ] Listening on systemd-journ…t - Journal Socket (/dev/log). +[ 56.421162] systemd[1]: Listening on systemd-journald.socket - Journal Socket. +[ OK ] Listening on systemd-journald.socket - Journal Socket. +[ 56.429706] systemd[1]: Listening on systemd-networkd.socket - Network Service Netlink Socket. +[ OK ] Listening on systemd-netwo… - Network Service Netlink Socket. +[ 56.436982] systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket. +[ OK ] Listening on systemd-udevd….socket - udev Control Socket. +[ 56.443136] systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket. +[ OK ] Listening on systemd-udevd…l.socket - udev Kernel Socket. +[ 56.450850] systemd[1]: dev-hugepages.mount - Huge Pages File System was skipped because of an unmet condition check (ConditionPathExists=/sys/kernel/mm/hugepages). +[ 56.516995] systemd[1]: Mounting dev-mqueue.mount - POSIX Message Queue File System... + Mounting dev-mqueue.mount…OSIX Message Queue File System... +[ 56.554312] systemd[1]: Mounting sys-kernel-debug.mount - Kernel Debug File System... + Mounting sys-kernel-debug.… - Kernel Debug File System... +[ 56.589207] systemd[1]: Mounting sys-kernel-tracing.mount - Kernel Trace File System... + Mounting sys-kernel-tracin… - Kernel Trace File System... +[ 56.651284] systemd[1]: Starting systemd-journald.service - Journal Service... + Starting systemd-journald.service - Journal Service... +[ 56.683040] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout... + Starting keyboard-setup.se…Set the console keyboard layout... +[ 56.729933] systemd[1]: Starting kmod-static-nodes.service - Create List of Static Device Nodes... + Starting kmod-static-nodes…ate List of Static Device Nodes... +[ 56.765378] systemd[1]: Starting lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... + Starting lvm2-monitor.serv…ng dmeventd or progress polling... +[ 56.768638] systemd[1]: lxd-agent.service - LXD - agent was skipped because of an unmet condition check (ConditionPathExists=/dev/virtio-ports/org.linuxcontainers.lxd). +[ 56.806941] systemd[1]: Starting modprobe@configfs.service - Load Kernel Module configfs... + Starting modprobe@configfs…m - Load Kernel Module configfs... +[ 56.852266] systemd[1]: Starting modprobe@dm_mod.service - Load Kernel Module dm_mod... + Starting modprobe@dm_mod.s…[0m - Load Kernel Module dm_mod... +[ 56.907919] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... + Starting modprobe@drm.service - Load Kernel Module drm... +[ 56.962524] systemd[1]: Starting modprobe@efi_pstore.service - Load Kernel Module efi_pstore... + Starting modprobe@efi_psto…- Load Kernel Module efi_pstore... +[ 57.014414] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse... + Starting modprobe@fuse.ser…e - Load Kernel Module fuse... +[ 57.069081] systemd-journald[352]: Collecting audit messages is disabled. +[ 57.076472] systemd[1]: Starting modprobe@loop.service - Load Kernel Module loop... + Starting modprobe@loop.ser…e - Load Kernel Module loop... +[ 57.085874] systemd[1]: netplan-ovs-cleanup.service - OpenVSwitch configuration for cleanup was skipped because of an unmet condition check (ConditionFileIsExecutable=/usr/bin/ovs-vsctl). +[ 57.095668] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root). +[ 57.168905] systemd[1]: Starting systemd-modules-load.service - Load Kernel Modules... + Starting systemd-modules-l…rvice - Load Kernel Modules... +[ 57.226498] systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems... + Starting systemd-remount-f…nt Root and Kernel File Systems... +[ 57.287754] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices... + Starting systemd-udev-trig…[0m - Coldplug All udev Devices... +[ 57.419867] systemd[1]: Mounted dev-mqueue.mount - POSIX Message Queue File System. +[ OK ] Mounted dev-mqueue.mount…OSIX Message Queue File System. +[ 57.432129] systemd[1]: Mounted sys-kernel-debug.mount - Kernel Debug File System. +[ OK ] Mounted sys-kernel-debug.m…nt - Kernel Debug File System. +[ 57.443392] systemd[1]: Mounted sys-kernel-tracing.mount - Kernel Trace File System. +[ OK ] Mounted sys-kernel-tracing…nt - Kernel Trace File System. +[ 57.455168] systemd[1]: Finished kmod-static-nodes.service - Create List of Static Device Nodes. +[ OK ] Finished kmod-static-nodes…reate List of Static Device Nodes. +[ 57.466903] systemd[1]: Started systemd-journald.service - Journal Service. +[ OK ] Started systemd-journald.service - Journal Service. +[ OK ] Finished modprobe@configfs…[0m - Load Kernel Module configfs. +[ 57.555558] EXT4-fs (vda1): re-mounted b33ae246-95a1-494e-b967-9ab636fd714d r/w. Quota mode: none. +[ OK ] Finished modprobe@dm_mod.s…e - Load Kernel Module dm_mod. +[ OK ] Finished modprobe@efi_psto…m - Load Kernel Module efi_pstore. +[ OK ] Finished modprobe@fuse.service - Load Kernel Module fuse. +[ OK ] Finished modprobe@loop.service - Load Kernel Module loop. +[ OK ] Finished systemd-modules-l…service - Load Kernel Modules. +[ OK ] Finished systemd-remount-f…ount Root and Kernel File Systems. + Activating swap swap.img.swap - /swap.img... + Mounting sys-fs-fuse-conne… - FUSE Control File System... +[ 57.885897] Adding 4085756k swap on /swap.img. Priority:-2 extents:7 across:4388860k FS + Mounting sys-kernel-config…ernel Configuration File System... + Starting multipathd.servic…per Multipath Device Controller... + Starting systemd-journal-f…h Journal to Persistent Storage... + Starting systemd-random-se… - Load/Save OS Random Seed... + Starting systemd-sysctl.se…ce - Apply Kernel Variables... + Starting systemd-sysusers.…rvice - Create System Users... +[ OK ] Activated swap swap.img.swap - /swap.img. +[ 58.206094] systemd-journald[352]: Received client request to flush runtime journal. +[ 58.228283] systemd-journald[352]: File /var/log/journal/accea1250e0f4fe291f8c3b31e7720d7/system.journal corrupted or uncleanly shut down, renaming and replacing. +[ OK ] Finished lvm2-monitor.serv…sing dmeventd or progress polling. +[ OK ] Finished modprobe@drm.service - Load Kernel Module drm. +[ OK ] Mounted sys-fs-fuse-connec…nt - FUSE Control File System. +[ OK ] Mounted sys-kernel-config.… Kernel Configuration File System. +[ OK ] Finished systemd-random-se…ce - Load/Save OS Random Seed. +[ OK ] Finished systemd-sysctl.service - Apply Kernel Variables. +[ OK ] Reached target swap.target - Swaps. +[ OK ] Finished systemd-sysusers.service - Create System Users. + Starting systemd-tmpfiles-…ate Static Device Nodes in /dev... +[ OK ] Finished systemd-journal-f…ush Journal to Persistent Storage. +[ OK ] Finished keyboard-setup.se…- Set the console keyboard layout. +[ OK ] Started multipathd.service…apper Multipath Device Controller. +[ OK ] Finished systemd-tmpfiles-…reate Static Device Nodes in /dev. +[ OK ] Reached target local-fs-pr…reparation for Local File Systems. + Mounting snap-core22-865.m…t unit for core22, revision 865... + Mounting snap-lxd-25850.mo…nt unit for lxd, revision 25850... + Mounting snap-snapd-20294.… unit for snapd, revision 20294... + Mounting snap-snapd-20676.… unit for snapd, revision 20676... + Starting systemd-udevd.ser…ger for Device Events and Files... +[ OK ] Mounted snap-core22-865.mo…unt unit for core22, revision 865. +[ OK ] Mounted snap-lxd-25850.mou…ount unit for lxd, revision 25850. +[ OK ] Mounted snap-snapd-20294.m…nt unit for snapd, revision 20294. +[ OK ] Mounted snap-snapd-20676.m…nt unit for snapd, revision 20676. +[ OK ] Reached target snapd.mounts.target - Mounted snaps. +[ OK ] Reached target local-fs.target - Local File Systems. + Starting apparmor.service - Load AppArmor profiles... + Starting console-setup.ser…m - Set console font and keymap... + Starting finalrd.service…me dir for shutdown pivot root... + Starting plymouth-read-wri…mouth To Write Out Runtime Data... + Starting systemd-binfmt.se…et Up Additional Binary Formats... + Starting systemd-tmpfiles-… Volatile Files and Directories... + Starting ufw.service - Uncomplicated firewall... +[ OK ] Finished systemd-udev-trig…e - Coldplug All udev Devices. +[ OK ] Finished console-setup.ser…[0m - Set console font and keymap. +[ OK ] Finished finalrd.service…time dir for shutdown pivot root. +[ OK ] Finished plymouth-read-wri…lymouth To Write Out Runtime Data. +[ OK ] Finished ufw.service - Uncomplicated firewall. +[ OK ] Reached target network-pre…get - Preparation for Network. + Mounting proc-sys-fs-binfm…utable File Formats File System... +[ OK ] Mounted proc-sys-fs-binfmt…ecutable File Formats File System. +[ OK ] Finished systemd-binfmt.se… Set Up Additional Binary Formats. +[ OK ] Started systemd-udevd.serv…nager for Device Events and Files. +[ OK ] Started systemd-ask-passwo…quests to Console Directory Watch. +[ OK ] Reached target cryptsetup.…get - Local Encrypted Volumes. + Starting systemd-networkd.…ice - Network Configuration... +[ OK ] Finished systemd-tmpfiles-…te Volatile Files and Directories. + Starting systemd-resolved.…e - Network Name Resolution... + Starting systemd-timesyncd… - Network Time Synchronization... + Starting systemd-update-ut…rd System Boot/Shutdown in UTMP... +[ OK ] Finished systemd-update-ut…cord System Boot/Shutdown in UTMP. +[ OK ] Found device dev-ttysclp0.device - /dev/ttysclp0. +[ OK ] Started systemd-networkd.service - Network Configuration. + Starting systemd-networkd-…it for Network to be Configured... +[ OK ] Started systemd-timesyncd.…0m - Network Time Synchronization. +[ OK ] Reached target time-set.target - System Time Set. +[ OK ] Finished systemd-networkd-…Wait for Network to be Configured. +[ OK ] Finished apparmor.service - Load AppArmor profiles. + Starting snapd.apparmor.se…les managed internally by snapd... +[ OK ] Started systemd-resolved.s…ice - Network Name Resolution. +[ OK ] Reached target network.target - Network. +[ OK ] Reached target network-online.target - Network is Online. +[ OK ] Reached target nss-lookup.…m - Host and Network Name Lookups. +[ OK ] Reached target remote-fs-p…eparation for Remote File Systems. +[ OK ] Reached target remote-fs.target - Remote File Systems. +[ OK ] Finished blk-availability.…m - Availability of block devices. +** +ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached +Bail out! ERROR:../target/s390x/tcg/fpu_helper.c:449:s390_swap_bfp_rounding_mode: code should not be reached +Abort trap: 6 +``` diff --git a/results/classifier/zero-shot/108/permissions/2290 b/results/classifier/zero-shot/108/permissions/2290 new file mode 100644 index 000000000..13d26aae4 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2290 @@ -0,0 +1,158 @@ +permissions: 0.951 +graphic: 0.950 +performance: 0.946 +other: 0.942 +semantic: 0.940 +debug: 0.929 +PID: 0.924 +device: 0.919 +KVM: 0.893 +boot: 0.887 +files: 0.869 +socket: 0.862 +vnc: 0.853 +network: 0.821 + +Wrong multiplication result of 'long double' on m68k +Description of problem: +In both x86 and m68k, 'long double' is an 80-bit format consisting of + - 1 bit sign, 15 bits exponent, + - 1 explicit 1 bit, 63 fraction bits. + +According to <https://en.wikipedia.org/wiki/Extended_precision> and +<https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf> table 1-6 (page 1-23), with two differences: + - In m68k, there are 16 zero bits as filler after the sign/exponent + word, so that the total size is 96 bits. + - In x86, the minimum exponent of normalized numbers is 1; + in m68k, the minimum exponent of normalized numbers is 0. + +The latter difference is reflected in the values of LDBL_MIN_EXP and +LDBL_MIN in gcc: + +In x86: +``` +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN_EXP_ +#define LDBL_MIN_EXP __LDBL_MIN_EXP__ +#define __LDBL_MIN_EXP__ (-16381) +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN__ +#define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L +#define LDBL_MIN __LDBL_MIN__ +``` +In m68k (I use Debian 12/Linux): +``` +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN_EXP_ +#define LDBL_MIN_EXP __LDBL_MIN_EXP__ +#define __LDBL_MIN_EXP__ (-16382) +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN__ +#define __LDBL_MIN__ 1.68105157155604675313e-4932L +#define LDBL_MIN __LDBL_MIN__ +``` +Steps to reproduce: +Take this program, foo.c: +``` +/* Show extended-precision https://en.wikipedia.org/wiki/Extended_precision + multiplication bug in QEMU. */ + +#include <stdio.h> + +static void +show (const long double *p) +{ +#ifdef __m68k__ + printf("<S,E: 0x%08X M: 0x%08X%08X>", + ((const unsigned int *) p)[0], + ((const unsigned int *) p)[1], + ((const unsigned int *) p)[2]); +#else /* x86 */ + printf("<S,E: 0x%04X M: 0x%08X%08X>", + ((const unsigned short *) p)[4], + ((const unsigned int *) p)[1], + ((const unsigned int *) p)[0]); +#endif + printf (" = %La = %Lg", *p, *p); +} + +static void +show_mult (long double a, long double b) +{ + printf ("Factors: "); + show (&a); + printf ("\n and: "); + show (&b); + long double c = a * b; + printf ("\nProduct: "); + show (&c); + printf ("\n\n"); +} + +/* Return 2^n. */ +static long double +pow2l (int n) +{ + int k = n; + volatile long double x = 1; + volatile long double y = 2; + /* Invariant: 2^n == x * y^k. */ + if (k < 0) + { + y = 0.5L; + k = - k; + } + while (k > 0) + { + if (k != 2 * (k / 2)) + { + x = x * y; + k = k - 1; + } + if (k == 0) + break; + y = y * y; + k = k / 2; + } + /* Now k == 0, hence x == 2^n. */ + return x; +} + +int main () +{ + show_mult (pow2l (-16382), 0.5L); + show_mult (pow2l (-16381), 0.25L); + return 0; +} +``` +Its output on x86: +``` +$ ./a.out +Factors: <S,E: 0x0001 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x0000 M: 0x4000000000000000> = 0x4p-16385 = 1.68105e-4932 + +Factors: <S,E: 0x0002 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x0000 M: 0x4000000000000000> = 0x4p-16385 = 1.68105e-4932 +``` +Its output on m68k: +``` +$ ./a.out +Factors: <S,E: 0x00010000 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE0000 M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x00000000 M: 0x4000000000000000> = 0x4p-16386 = 8.40526e-4933 + +Factors: <S,E: 0x00020000 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD0000 M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x00000000 M: 0x4000000000000000> = 0x4p-16386 = 8.40526e-4933 +``` +The product, computed by QEMU, is incorrect. It is only half as large as the +correct value. The expected output should be: +``` +Factors: <S,E: 0x00010000 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE0000 M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x00000000 M: 0x8000000000000000> = 0x8p-16386 = 1.68105e-4932 + +Factors: <S,E: 0x00020000 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD0000 M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x00000000 M: 0x8000000000000000> = 0x8p-16386 = 1.68105e-4932 +``` +Additional information: +In QEMU's source code, I would guess that this multiplication is performed by the `floatx80_mul` function. diff --git a/results/classifier/zero-shot/108/permissions/23300761 b/results/classifier/zero-shot/108/permissions/23300761 new file mode 100644 index 000000000..929fc4adf --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/23300761 @@ -0,0 +1,323 @@ +permissions: 0.984 +debug: 0.978 +other: 0.963 +performance: 0.952 +PID: 0.950 +semantic: 0.950 +device: 0.932 +boot: 0.929 +socket: 0.927 +vnc: 0.926 +graphic: 0.924 +files: 0.910 +KVM: 0.897 +network: 0.879 + +[Qemu-devel] [BUG] 216 Alerts reported by LGTM for QEMU (some might be release critical) + +Hi, +LGTM reports 16 errors, 81 warnings and 119 recommendations: +https://lgtm.com/projects/g/qemu/qemu/alerts/?mode=list +. +Some of them are already know (wrong format strings), others look like +real errors: +- several multiplication results which don't work as they should in +contrib/vhost-user-gpu, block/* (m->nb_clusters * s->cluster_size only +32 bit!), target/i386/translate.c and other files +- potential buffer overflows in gdbstub.c and other files +I am afraid that the overflows in the block code are release critical, +maybe that in target/i386/translate.c and other errors, too. +About half of the alerts are issues which can be fixed later. + +Regards + +Stefan + +On 13/07/19 19:46, Stefan Weil wrote: +> +> +LGTM reports 16 errors, 81 warnings and 119 recommendations: +> +https://lgtm.com/projects/g/qemu/qemu/alerts/?mode=list +. +> +> +Some of them are already know (wrong format strings), others look like +> +real errors: +> +> +- several multiplication results which don't work as they should in +> +contrib/vhost-user-gpu, block/* (m->nb_clusters * s->cluster_size only +> +32 bit!), target/i386/translate.c and other files +m->nb_clusters here is limited by s->l2_slice_size (see for example +handle_alloc) so I wouldn't be surprised if this is a false positive. I +couldn't find this particular multiplication in Coverity, but it has +about 250 issues marked as intentional or false positive so there's +probably a lot of overlap with what LGTM found. + +Paolo + +Am 13.07.2019 um 21:42 schrieb Paolo Bonzini: +> +On 13/07/19 19:46, Stefan Weil wrote: +> +> LGTM reports 16 errors, 81 warnings and 119 recommendations: +> +> +https://lgtm.com/projects/g/qemu/qemu/alerts/?mode=list +. +> +> +> +> Some of them are already known (wrong format strings), others look like +> +> real errors: +> +> +> +> - several multiplication results which don't work as they should in +> +> contrib/vhost-user-gpu, block/* (m->nb_clusters * s->cluster_size only +> +> 32 bit!), target/i386/translate.c and other files +> +m->nb_clusters here is limited by s->l2_slice_size (see for example +> +handle_alloc) so I wouldn't be surprised if this is a false positive. I +> +couldn't find this particular multiplication in Coverity, but it has +> +about 250 issues marked as intentional or false positive so there's +> +probably a lot of overlap with what LGTM found. +> +> +Paolo +> +From other projects I know that there is a certain overlap between the +results from Coverity Scan an LGTM, but it is good to have both +analyzers, and the results from LGTM are typically quite reliable. + +Even if we know that there is no multiplication overflow, the code could +be modified. Either the assigned value should use the same data type as +the factors (possible when there is never an overflow, avoids a size +extension), or the multiplication could use the larger data type by +adding a type cast to one of the factors (then an overflow cannot +happen, static code analysers and human reviewers have an easier job, +but the multiplication costs more time). + +Stefan + +Am 14.07.2019 um 15:28 hat Stefan Weil geschrieben: +> +Am 13.07.2019 um 21:42 schrieb Paolo Bonzini: +> +> On 13/07/19 19:46, Stefan Weil wrote: +> +>> LGTM reports 16 errors, 81 warnings and 119 recommendations: +> +>> +https://lgtm.com/projects/g/qemu/qemu/alerts/?mode=list +. +> +>> +> +>> Some of them are already known (wrong format strings), others look like +> +>> real errors: +> +>> +> +>> - several multiplication results which don't work as they should in +> +>> contrib/vhost-user-gpu, block/* (m->nb_clusters * s->cluster_size only +> +>> 32 bit!), target/i386/translate.c and other files +Request sizes are limited to 32 bit in the generic block layer before +they are even passed to the individual block drivers, so most if not all +of these are going to be false positives. + +> +> m->nb_clusters here is limited by s->l2_slice_size (see for example +> +> handle_alloc) so I wouldn't be surprised if this is a false positive. I +> +> couldn't find this particular multiplication in Coverity, but it has +> +> about 250 issues marked as intentional or false positive so there's +> +> probably a lot of overlap with what LGTM found. +> +> +> +> Paolo +> +> +From other projects I know that there is a certain overlap between the +> +results from Coverity Scan an LGTM, but it is good to have both +> +analyzers, and the results from LGTM are typically quite reliable. +> +> +Even if we know that there is no multiplication overflow, the code could +> +be modified. Either the assigned value should use the same data type as +> +the factors (possible when there is never an overflow, avoids a size +> +extension), or the multiplication could use the larger data type by +> +adding a type cast to one of the factors (then an overflow cannot +> +happen, static code analysers and human reviewers have an easier job, +> +but the multiplication costs more time). +But if you look at the code we're talking about, you see that it's +complaining about things where being more explicit would make things +less readable. + +For example, if complains about the multiplication in this line: + + s->file_size += n * s->header.cluster_size; + +We know that n * s->header.cluster_size fits in 32 bits, but +s->file_size is 64 bits (and has to be 64 bits). Do you really think we +should introduce another uint32_t variable to store the intermediate +result? And if we cast n to uint64_t, not only might the multiplication +cost more time, but also human readers would wonder why the result could +become larger than 32 bits. So a cast would be misleading. + + +It also complains about this line: + + ret = bdrv_truncate(bs->file, (3 + l1_clusters) * s->cluster_size, + PREALLOC_MODE_OFF, &local_err); + +Here, we don't even assign the result to a 64 bit variable, but just +pass it to a function which takes a 64 bit parameter. Again, I don't +think introducing additional variables for the intermediate result or +adding casts would be an improvement of the situation. + + +So I don't think this is a good enough tool to base our code on what it +does and doesn't understand. It would have too much of a negative impact +on our code. We'd rather need a way to mark false positives as such and +move on without changing the code in such cases. + +Kevin + +On Sat, 13 Jul 2019 at 18:46, Stefan Weil <address@hidden> wrote: +> +LGTM reports 16 errors, 81 warnings and 119 recommendations: +> +https://lgtm.com/projects/g/qemu/qemu/alerts/?mode=list +. +I had a look at some of these before, but mostly I came +to the conclusion that it wasn't worth trying to put the +effort into keeping up with the site because they didn't +seem to provide any useful way to mark things as false +positives. Coverity has its flaws but at least you can do +that kind of thing in its UI (it runs at about a 33% fp +rate, I think.) "Analyzer thinks this multiply can overflow +but in fact it's not possible" is quite a common false +positive cause... + +Anyway, if you want to fish out specific issues, analyse +whether they're false positive or real, and report them +to the mailing list as followups to the patches which +introduced the issue, that's probably the best way for +us to make use of this analyzer. (That is essentially +what I do for coverity.) + +thanks +-- PMM + +Am 14.07.2019 um 19:30 schrieb Peter Maydell: +[...] +> +"Analyzer thinks this multiply can overflow +> +but in fact it's not possible" is quite a common false +> +positive cause... +The analysers don't complain because a multiply can overflow. + +They complain because the code indicates that a larger result is +expected, for example uint64_t = uint32_t * uint32_t. They would not +complain for the same multiplication if it were assigned to a uint32_t. + +So there is a simple solution to write the code in a way which avoids +false positives... + +Stefan + +Stefan Weil <address@hidden> writes: + +> +Am 14.07.2019 um 19:30 schrieb Peter Maydell: +> +[...] +> +> "Analyzer thinks this multiply can overflow +> +> but in fact it's not possible" is quite a common false +> +> positive cause... +> +> +> +The analysers don't complain because a multiply can overflow. +> +> +They complain because the code indicates that a larger result is +> +expected, for example uint64_t = uint32_t * uint32_t. They would not +> +complain for the same multiplication if it were assigned to a uint32_t. +I agree this is an anti-pattern. + +> +So there is a simple solution to write the code in a way which avoids +> +false positives... +You wrote elsewhere in this thread: + + Either the assigned value should use the same data type as the + factors (possible when there is never an overflow, avoids a size + extension), or the multiplication could use the larger data type by + adding a type cast to one of the factors (then an overflow cannot + happen, static code analysers and human reviewers have an easier + job, but the multiplication costs more time). + +Makes sense to me. + +On 7/14/19 5:30 PM, Peter Maydell wrote: +> +I had a look at some of these before, but mostly I came +> +to the conclusion that it wasn't worth trying to put the +> +effort into keeping up with the site because they didn't +> +seem to provide any useful way to mark things as false +> +positives. Coverity has its flaws but at least you can do +> +that kind of thing in its UI (it runs at about a 33% fp +> +rate, I think.) +Yes, LGTM wants you to modify the source code with + + /* lgtm [cpp/some-warning-code] */ + +and on the same line as the reported problem. Which is mildly annoying in that +you're definitely committing to LGTM in the long term. Also for any +non-trivial bit of code, it will almost certainly run over 80 columns. + + +r~ + diff --git a/results/classifier/zero-shot/108/permissions/2390 b/results/classifier/zero-shot/108/permissions/2390 new file mode 100644 index 000000000..903a7fb57 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2390 @@ -0,0 +1,78 @@ +permissions: 0.950 +graphic: 0.869 +other: 0.867 +socket: 0.840 +debug: 0.827 +boot: 0.803 +device: 0.794 +files: 0.788 +PID: 0.784 +network: 0.766 +performance: 0.761 +vnc: 0.720 +semantic: 0.532 +KVM: 0.406 + +linux-user: Qemu handles `getsockopt` with NULL `optval` incorrectly +Description of problem: +In short call to `getsockopt(_, SOL_TCP, TCP_KEEPIDLE, NULL, _)` behaves differently on RISC-V Qemu than on x64 Linux. +On Linux syscall returns 0, but on Qemu it fails with `"Bad address"`. +Apparently Qemu `getsockopt` implementation is more conservative about NULL `optval` argument than kernel implementation. However man permits passing NULL [link](https://man7.org/linux/man-pages/man2/setsockopt.2.html): + +> For getsockopt(), optlen is a value-result argument, initially + containing the size of the buffer pointed to by optval, and + modified on return to indicate the actual size of the value + returned. **If no option value is to be supplied** or returned, + **optval may be NULL.**" + +For me it sounds like accepting NULL without error (and x64 confirms that interpretation). +Steps to reproduce: +1. Use below toy program `getsockopt.c` and compile it without optimizations like: +``` + gcc -Wall -W -std=gnu11 -pedantic getsockopt.c -o getsockopt +``` + +``` +#include <stdlib.h> +#include <unistd.h> +#include <errno.h> +#include <stdio.h> +#include <netinet/in.h> +#include <sys/socket.h> +#include <netinet/tcp.h> + +static void fail_on_error(int error, const char *msg) { + if (error < 0) { + perror(msg); + exit(errno); + } +} + +int main(int argc, char **argv) { + int socketfd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP); + fail_on_error(socketfd, "socket error"); + uint8_t *option_value = NULL; + int32_t len = 0; + int32_t *option_len = &len; + socklen_t opt_len = (socklen_t)*option_len; + int status = getsockopt(socketfd, SOL_TCP, TCP_KEEPIDLE, option_value, &opt_len); + fail_on_error(status, "getsockopt error"); + return 0; +} +``` + + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@57646f544f3a:/runtime/programs# ./getsockopt-x64 +root@57646f544f3a:/runtime/programs# ./getsockopt-riscv +getsockopt error: Bad address +``` +Additional information: +I don't think issue is platform specific assuming Qemu `getsockopt` implementation that is actually running is here: +[link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2522) + +Looking at sources, I'm not sure why Qemu can't simply forward everything to kernel space +instead doing extra sanity checks together with `optval` dereference attempt that eventually fails in one of `put_user*_` function: [link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2753) + +Anyway, I think that interpretation of man quote is rather straightforward and Qemu `getsockopt` implementation should follow it. diff --git a/results/classifier/zero-shot/108/permissions/2563 b/results/classifier/zero-shot/108/permissions/2563 new file mode 100644 index 000000000..ce15c13c8 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2563 @@ -0,0 +1,225 @@ +permissions: 0.927 +other: 0.883 +vnc: 0.881 +graphic: 0.881 +network: 0.880 +boot: 0.879 +performance: 0.863 +socket: 0.854 +PID: 0.840 +files: 0.840 +debug: 0.838 +device: 0.837 +semantic: 0.820 +KVM: 0.816 + +W64 build referenced to by https://www.qemu.org/download/#windows fails to run with GTK and 3D but cross-build for W64 works ok with GTK and 3d +Description of problem: +Qemu W64 build referenced to by https://www.qemu.org/download/#windows (https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe) crashes with aforementioned command line, leaving 0xc0000005 exception in Windows event log. But a custom cross-compiled build at least boots into default qemu BIOS. See steps below to cross-compile qemu with GTK + OpenGL +VirGL support. +Steps to reproduce: +1. `wget https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe`, install it, run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch immediate qemu crash. + 2. Prepare cross-compilation build of qemu 9.1.0 using following steps: + 3. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk. + 4. `wget https://download.qemu.org/qemu-9.1.0.tar.xz`\ + `tar xvJf qemu-9.1.0.tar.xz`\ + `cd qemu-9.1.0` + 5. Run `sudo yum install git meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-glib2 mingw64-pkg-config mingw64-pixman mingw64-gtk3 mingw64-SDL2 mingw64-libepoxy mingw64-librsvg2` in virtual Fedora. `mingw64-librsvg2` is optional, see step #14 + 6. `git clone https://gitlab.freedesktop.org/slirp/libslirp.git` (e61dbd45 as of 04 August 2024) `git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git` (3d82ed86 as of 03 September 2024) + 7. create file x86_64-w64-mingw32.txt in qemu-9.1.0 directory with the content as follows:\ + `[binaries]`\ + `c = '/usr/bin/x86_64-w64-mingw32-gcc'`\ + `cpp = '/usr/bin/x86_64-w64-mingw32-g++'`\ + `ar = '/usr/bin/x86_64-w64-mingw32-ar'`\ + `strip = '/usr/bin/x86_64-w64-mingw32-strip'`\ + `pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config'`\ + `exe_wrapper = 'wine'`\ + \ + `[host_machine]`\ + `system = 'windows'`\ + `cpu_family = 'x86_64'`\ + `cpu = 'i686'`\ + `endian = 'little'` + 8. Make a directory to which QEMU dependencies will be installed after compilation from git: `export CROSS_QEMU_DEPS="/home/cross-qemu-deps"`\ + `sudo mkdir -p $CROSS_QEMU_DEPS` + 9. Install libslirp so that future qemu binaries can have internet access via -netdev user\ + ` cd libslirp`\ + \ + ` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\ + ` meson compile -C build-mingw`\ + ` cd build-mingw`\ + ` ninja install` +10. Install virgl to have 3D hardware acceleration\ + ` cd ../../`\ + ` cd virglrenderer`\ + \ + ` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\ + ` meson compile -C build-mingw`\ + ` cd build-mingw`\ + ` ninja install` +11. Set three environment variables for cross-compilation: + + `sudo find / -type f -name '*.pc'` and make sure all mingw \*.pc files live in `/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig/` and `/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/`. Correct these paths in PKG_CONFIG_PATH if you see they were altered by mingw or package contributors.\ + \ + `export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/:$PKG_CONFIG_PATH"` + + \ + `export PKG_CONFIG_LIBDIR="${CROSS_QEMU_DEPS}/lib/pkgconfig/:$PKG_CONFIG_LIBDIR"` + + \ + `export PKG_CONFIG_SYSROOT_DIR=""` +12. <span dir="">Configure Qemu makefile:</span> + + `cd ../../` + + `./configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-opengl --enable-virglrenderer --enable-slirp --enable-debug` + + and make sure you see this in the output of configure: + + `Compilation`\ + `host CPU : x86_64`\ + `host endianness : little`\ + `C compiler : x86_64-w64-mingw32-gcc -m64`\ + `Host C compiler : cc` + + and this one: + + `Checking whether type "struct virgl_renderer_resource_info_ext" has member "d3d_tex2d" with dependency virglrenderer: YES` +13. Cross-compile qemu: `` make -j`nproc` `` +14. \[optional step to get rid of "**Gtk-WARNING \*\*: 19:22:02.461: Could not load a pixbuf**"\] + + **Copy gdk-pixbuf-query-loaders.exe** from `/usr/x86_64-w64-mingw32/sys-root/mingw/bin/`\ + to\ + `./qemu-9.1.0/build/qemu-bundle/qemu`**\ + \ + `mkdir -p ./qemu-9.1.0/build/qemu-bundle/qemu/lib`\ + \ + copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/lib/gdk-pixbuf-2.0** to `./qemu-9.1.0/build/qemu-bundle/qemu/lib` + + **`mkdir -p ./qemu-9.1.0/build/qemu-bundle/qemu/share`**\ + \ + **copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/share/icons** to `./qemu-9.1.0/build/qemu-bundle/qemu/share` + + **copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/share/themes** to `./qemu-9.1.0/build/qemu-bundle/qemu/share` + + Run `gdk-pixbuf-query-loaders.exe --update-cache` on host right before step 17. +15. Copy all dll files from + + `/usr/x86_64-w64-mingw32/sys-root/mingw/bin/`\ + to\ + `./qemu-9.1.0/build/qemu-bundle/`**`qemu`** + + Copy libvirglrenderer-1.dll and libslirp-0.dll from `$CROSS_QEMU_DEPS` directory exported above to + + `./qemu-9.1.0/build/qemu-bundle/`**`qemu`** +16. Copy this **`qemu`** folder from the previous step to Windows machine using ssh or whatever else\ + E.g. by doing\ + ` sudo yum install openssh-server`\ + ` sudo systemctl start sshd`\ + ` sudo systemctl status sshd`\ + on guest OS (provided you have launched guest Fedora qemu with `-nic user,hostfwd=tcp::8888-:22` command line parameter for ssh) + + and then + + `scp.exe -P 8888 -r virtual_machine_user@127.0.0.1:/home/virtual_machine_user/qemu-9.1.0/build/qemu-bundle/qemu C:\downloads\qemu`\ + on host OS +17. `cd` to that `qemu` folder and run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch qemu booting into BIOS. + +<details> +<summary>Previous version</summary> + +1\. \`wget https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe\\\\\\\\\\\\\\\`, install it, run \`qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl\` and watch immediate qemu crash. 2. Prepare cross-compilation build of qemu 9.1.0 using following steps: 3. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk. 4. Run \`sudo yum install meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-glib2 mingw64-pkg-config mingw64-pixman mingw64-gtk3 mingw64-SDL2 mingw64-libepoxy\` in virtual Fedora. 5. \`wget https://download.qemu.org/qemu-9.1.0.tar.xz\\\\\\\\\\\\\\\\\\\\\\\` + +``` +`tar xvJf qemu-9.1.0.tar.xz`\ +`cd qemu-9.1.0` +``` + + 6. `git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git` (3d82ed86 as of 03 September 2024)\ + `cd virglrenderer` + 7. create file x86_64-w64-mingw32.txt in virglrenderer directory with the content as follows:\ + `[binaries]`\ + `c = '/usr/bin/x86_64-w64-mingw32-gcc'`\ + `cpp = '/usr/bin/x86_64-w64-mingw32-g++'`\ + `ar = '/usr/bin/x86_64-w64-mingw32-ar'`\ + `strip = '/usr/bin/x86_64-w64-mingw32-strip'`\ + `pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config'`\ + `exe_wrapper = 'wine'`\ + \ + `[host_machine]`\ + `system = 'windows'`\ + `cpu_family = 'x86_64'`\ + `cpu = 'i686'`\ + `endian = 'little'` + 8. Run `meson setup --cross-file x86_64-w64-mingw32.txt build-mingw`\ + `meson compile -C build-mingw`\ + `cd build-mingw`\ + `ninja install` + 9. Set pkgconfig for virglrenderer: `export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/home/your_user/virglrenderer/build-mingw/meson-private`\ + (replace /home/your_user/virglrenderer/build-mingw/meson-private with path containing virglrenderer.pc file from output of `sudo find / -type f -name 'virglrenderer.pc'` command) +10. Run confugure: \ + `cd ../../`\ + `./configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-opengl --enable-virglrenderer --enable-debug`\ + \ + and make sure you see this in the output of configure:\ + `Compilation`\ + `host CPU : x86_64`\ + `host endianness : little`\ + `C compiler : x86_64-w64-mingw32-gcc -m64`\ + `Host C compiler : cc`\ + \ + run\ + `export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"` +11. Run this command to see where x86_64-w64-mingw32-pkg-config will look for virglrenderer.h: + + `/usr/bin/x86_64-w64-mingw32-pkg-config --cflags virglrenderer`\ + \> -I/usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/virgl (possible result) +12. Copy folder containing virglrenderer.h to that one to satisfy mingw expectations: + + `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/`\ + `sudo cp -r /usr/local/include/virgl /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/` +13. Run search `sudo find / -type f -name 'libvirglrenderer.dll.a'` and satisfy mingw's expectation for libvirglrenderer.dll.a:\ + `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/`\ + `sudo ln -s /usr/local/lib/libvirglrenderer.dll.a /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a` +14. Cross-compile qemu: \ + `make -j4`\ + \* if you see "/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lvirglrenderer: No such file or directory" then most likely Qemu's makefile was confused by libvirglrenderer.dll.a path; check `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` output to find out path of libvirglrenderer.dll.a file it cannot find +15. copy all dll files from \ + /usr/x86_64-w64-mingw32/sys-root/mingw/bin/\ + to\ + ./qemu-9.1.0-rc4/**build** +16. copy libvirglrenderer-1.dll from /usr/local/bin to\ + ./qemu-9.1.0-rc4/**build** +17. copy this **build** folder to Windows machine using ssh or whatever else +18. `cd` to that **build** folder and run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch qemu booting into BIOS. + +</details> +Additional information: +P.S. Cross-compilation on Fedora build machine for Windows target usually requires installing pre-compiled binary packages along with libslirp and libvirglrenderer from git. Almost all of them include \*.pc files (pkg-config files) needed by mingw to find .h headers and .dll.a library files. Normally, it's not necessarry to add extra include paths using something like CFLAGS="-I/include_headers_path" or LDFLAGS="-L/path_to_dll_a_lib". The commands from above must produce a fully working windows build. But, just in case someone damages packages in Fedora repository or libslirp or virglrenderer in their git, here are some ideas how to fix broken links between files: + +- First, make sure you have enumerated all .pc folders from Fedora repository packages in PKG_CONFIG_PATH= and all .pc folders built from source in PKG_CONFIG_LIBDIR=, as it was shown at Step 11. If you see a message saying something like "virglrenderer.h not found", run this command to see where x86_64-w64-mingw32-pkg-config will look for virglrenderer.h: `/usr/bin/x86_64-w64-mingw32-pkg-config --cflags virglrenderer` + +> \-I/usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/virgl (possible result) + +- Then copy folder containing virglrenderer.h (for example, /usr/local/include/virgl) to that one to satisfy mingw expectations: + + `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/` `sudo cp -r /usr/local/include/virgl /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/` +- If you see "/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lvirglrenderer: No such file or directory" then most likely Qemu's makefile was confused by libvirglrenderer.dll.a path; check `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` output to find out path of libvirglrenderer.dll.a file it cannot find +- For example, `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` shows that build script tries to find .dll.a file under /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a and `find / -type f -name 'libvirglrenderer.dll.a'` shows that file is in /usr/local/lib/libvirglrenderer.dll.a +- Then satisfy mingw's expectation for libvirglrenderer.dll.a: `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/`\ + `sudo ln -s /usr/local/lib/libvirglrenderer.dll.a /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a` + +Upd: I was able to refine instructions on how to cross-compile Qemu's dependencies thanks to these references: + +https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/52: + +> PKG_CONFIG_SYSROOT_DIR blindly prepend the sysroot to all paths. I made a MR that add PKG_CONFIG_SYSROOT_MAP to get smarter mapping from pcfiledir-\>sysroot. !7. I generally discontinued the use of PKG_CONFIG_SYSROOT_DIR and switched to merely using PKG_CONFIG_LIBDIR. That way I got absolute paths everyehere which at least was consistent and could be postprocessed if needed. + +https://forum.qt.io/topic/88946/qt5-10-1-cross-compile-configure-errors/9: + +> WARNING: Disabling pkg-config since PKG_CONFIG_LIBDIR is not set and the host's .pc files would be used (even if you set PKG_CONFIG_PATH). Set this variable to the directory that contains target .pc files for pkg-config to function correctly when cross-compiling or use -pkg-config to override this test. + +https://cmake.org/pipermail/cmake/2008-November/025050.html: + +> The situation is as follows: PKG_CONFIG_PATH is searched before PKG_CONFIG_LIBDIR for the desired \*.pc file. (The man page doesn't say which is searched first, but my tests reveal that is the order at least for the present version of pkg-config.) Cross-compiling users should avoid using native paths in PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR. Furthermore, cross-compiling users should always specify PKG_CONFIG_LIBDIR (with or without PKG_CONFIG_PATH) since use of PKG_CONFIG_LIBDIR supresses appending default native paths to whatever is specified in PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR. +> +> In sum, for cross-compilation purposes you should always use PKG_CONFIG_LIBDIR (with or without PKG_CONFIG_PATH) and make sure there are no native paths in it (or in PKG_CONFIG_PATH). If you follow those rules you should get a good cross-compilation result, otherwise not. diff --git a/results/classifier/zero-shot/108/permissions/2596 b/results/classifier/zero-shot/108/permissions/2596 new file mode 100644 index 000000000..968126425 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2596 @@ -0,0 +1,16 @@ +permissions: 0.942 +debug: 0.715 +device: 0.627 +network: 0.474 +boot: 0.332 +graphic: 0.174 +performance: 0.173 +semantic: 0.169 +files: 0.128 +vnc: 0.071 +other: 0.052 +socket: 0.034 +PID: 0.032 +KVM: 0.002 + +linux-user elf parsing endianness issue (Invalid note in PT_GNU_PROPERTY) diff --git a/results/classifier/zero-shot/108/permissions/26095107 b/results/classifier/zero-shot/108/permissions/26095107 new file mode 100644 index 000000000..d5075496a --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/26095107 @@ -0,0 +1,168 @@ +permissions: 0.993 +debug: 0.993 +files: 0.989 +PID: 0.988 +device: 0.988 +performance: 0.987 +socket: 0.987 +boot: 0.987 +KVM: 0.985 +other: 0.979 +semantic: 0.974 +vnc: 0.972 +graphic: 0.955 +network: 0.879 + +[Qemu-devel] [Bug Report] vm paused after succeeding to migrate + +Hi, all +I encounterd a bug when I try to migrate a windows vm. + +Enviroment information: +host A: cpu E5620(model WestmereEP without flag xsave) +host B: cpu E5-2643(model SandyBridgeEP with xsave) + +The reproduce steps is : +1. Start a windows 2008 vm with -cpu host(which means host-passthrough). +2. Migrate the vm to host B when cr4.OSXSAVE=0 (successfully). +3. Vm runs on host B for a while so that cr4.OSXSAVE changes to 1. +4. Then migrate the vm to host A (successfully), but vm was paused, and qemu +printed log as followed: + +KVM: entry failed, hardware error 0x80000021 + +If you're running a guest on an Intel machine without unrestricted mode +support, the failure can be most likely due to the guest entering an invalid +state for Intel VT. For example, the guest maybe running in big real mode +which is not supported on less recent Intel processors. + +EAX=019b3bb0 EBX=01a3ae80 ECX=01a61ce8 EDX=00000000 +ESI=01a62000 EDI=00000000 EBP=00000000 ESP=01718b20 +EIP=0185d982 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 +DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 +00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +I have found that problem happened when kvm_put_sregs returns err -22(called by +kvm_arch_put_registers(qemu)). +Because kvm_arch_vcpu_ioctl_set_sregs(kvm-mod) checked that guest_cpuid_has no +X86_FEATURE_XSAVE but cr4.OSXSAVE=1. +So should we cancel migration when kvm_arch_put_registers returns error? + +* linzhecheng (address@hidden) wrote: +> +Hi, all +> +I encounterd a bug when I try to migrate a windows vm. +> +> +Enviroment information: +> +host A: cpu E5620(model WestmereEP without flag xsave) +> +host B: cpu E5-2643(model SandyBridgeEP with xsave) +> +> +The reproduce steps is : +> +1. Start a windows 2008 vm with -cpu host(which means host-passthrough). +> +2. Migrate the vm to host B when cr4.OSXSAVE=0 (successfully). +> +3. Vm runs on host B for a while so that cr4.OSXSAVE changes to 1. +> +4. Then migrate the vm to host A (successfully), but vm was paused, and qemu +> +printed log as followed: +Remember that migrating using -cpu host across different CPU models is NOT +expected to work. + +> +KVM: entry failed, hardware error 0x80000021 +> +> +If you're running a guest on an Intel machine without unrestricted mode +> +support, the failure can be most likely due to the guest entering an invalid +> +state for Intel VT. For example, the guest maybe running in big real mode +> +which is not supported on less recent Intel processors. +> +> +EAX=019b3bb0 EBX=01a3ae80 ECX=01a61ce8 EDX=00000000 +> +ESI=01a62000 EDI=00000000 EBP=00000000 ESP=01718b20 +> +EIP=0185d982 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +> +ES =0000 00000000 0000ffff 00009300 +> +CS =f000 ffff0000 0000ffff 00009b00 +> +SS =0000 00000000 0000ffff 00009300 +> +DS =0000 00000000 0000ffff 00009300 +> +FS =0000 00000000 0000ffff 00009300 +> +GS =0000 00000000 0000ffff 00009300 +> +LDT=0000 00000000 0000ffff 00008200 +> +TR =0000 00000000 0000ffff 00008b00 +> +GDT= 00000000 0000ffff +> +IDT= 00000000 0000ffff +> +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +> +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 +> +DR3=0000000000000000 +> +DR6=00000000ffff0ff0 DR7=0000000000000400 +> +EFER=0000000000000000 +> +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 +> +00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> +00 +> +> +I have found that problem happened when kvm_put_sregs returns err -22(called +> +by kvm_arch_put_registers(qemu)). +> +Because kvm_arch_vcpu_ioctl_set_sregs(kvm-mod) checked that guest_cpuid_has +> +no X86_FEATURE_XSAVE but cr4.OSXSAVE=1. +> +So should we cancel migration when kvm_arch_put_registers returns error? +It would seem good if we can make the migration fail there rather than +hitting that KVM error. +It looks like we need to do a bit of plumbing to convert the places that +call it to return a bool rather than void. + +Dave + +-- +Dr. David Alan Gilbert / address@hidden / Manchester, UK + diff --git a/results/classifier/zero-shot/108/permissions/26430026 b/results/classifier/zero-shot/108/permissions/26430026 new file mode 100644 index 000000000..d081ea9ab --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/26430026 @@ -0,0 +1,175 @@ +permissions: 0.937 +debug: 0.925 +KVM: 0.919 +semantic: 0.904 +device: 0.904 +performance: 0.898 +PID: 0.894 +vnc: 0.893 +files: 0.879 +graphic: 0.862 +boot: 0.841 +socket: 0.817 +other: 0.813 +network: 0.758 + +[BUG] cxl,i386: e820 mappings may not be correct for cxl + +Context included below from prior discussion + - `cxl create-region` would fail on inability to allocate memory + - traced this down to the memory region being marked RESERVED + - E820 map marks the CXL fixed memory window as RESERVED + + +Re: x86 errors, I found that region worked with this patch. (I also +added the SRAT patches the Davidlohr posted, but I do not think they are +relevant). + +I don't think this is correct, and setting this to E820_RAM causes the +system to fail to boot at all, but with this change `cxl create-region` +succeeds, which suggests our e820 mappings in the i386 machine are +incorrect. + +Anyone who can help or have an idea as to what e820 should actually be +doing with this region, or if this is correct and something else is +failing, please help! + + +diff --git a/hw/i386/pc.c b/hw/i386/pc.c +index 566accf7e6..a5e688a742 100644 +--- a/hw/i386/pc.c ++++ b/hw/i386/pc.c +@@ -1077,7 +1077,7 @@ void pc_memory_init(PCMachineState *pcms, + memory_region_init_io(&fw->mr, OBJECT(machine), &cfmws_ops, fw, + "cxl-fixed-memory-region", fw->size); + memory_region_add_subregion(system_memory, fw->base, &fw->mr); +- e820_add_entry(fw->base, fw->size, E820_RESERVED); ++ e820_add_entry(fw->base, fw->size, E820_NVS); + cxl_fmw_base += fw->size; + cxl_resv_end = cxl_fmw_base; + } + + +On Mon, Oct 10, 2022 at 05:32:42PM +0100, Jonathan Cameron wrote: +> +> +> > but i'm not sure of what to do with this info. We have some proof +> +> > that real hardware works with this no problem, and the only difference +> +> > is that the EFI/bios/firmware is setting the memory regions as `usable` +> +> > or `soft reserved`, which would imply the EDK2 is the blocker here +> +> > regardless of the OS driver status. +> +> > +> +> > But I'd seen elsewhere you had gotten some of this working, and I'm +> +> > failing to get anything working at the moment. If you have any input i +> +> > would greatly appreciate the help. +> +> > +> +> > QEMU config: +> +> > +> +> > /opt/qemu-cxl2/bin/qemu-system-x86_64 \ +> +> > -drive +> +> > file=/var/lib/libvirt/images/cxl.qcow2,format=qcow2,index=0,media=d\ +> +> > -m 2G,slots=4,maxmem=4G \ +> +> > -smp 4 \ +> +> > -machine type=q35,accel=kvm,cxl=on \ +> +> > -enable-kvm \ +> +> > -nographic \ +> +> > -device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52 \ +> +> > -device cxl-rp,id=rp0,bus=cxl.0,chassis=0,slot=0 \ +> +> > -object memory-backend-file,id=cxl-mem0,mem-path=/tmp/cxl-mem0,size=256M \ +> +> > -object memory-backend-file,id=lsa0,mem-path=/tmp/cxl-lsa0,size=256M \ +> +> > -device cxl-type3,bus=rp0,pmem=true,memdev=cxl-mem0,lsa=lsa0,id=cxl-pmem0 +> +> > \ +> +> > -M cxl-fmw.0.targets.0=cxl.0,cxl-fmw.0.size=256M +> +> > +> +> > I'd seen on the lists that you had seen issues with single-rp setups, +> +> > but no combination of configuration I've tried (including all the ones +> +> > in the docs and tests) lead to a successful region creation with +> +> > `cxl create-region` +> +> +> +> Hmm. Let me have a play. I've not run x86 tests for a while so +> +> perhaps something is missing there. +> +> +> +> I'm carrying a patch to override check_last_peer() in +> +> cxl_port_setup_targets() as that is wrong for some combinations, +> +> but that doesn't look like it's related to what you are seeing. +> +> +I'm not sure if it's relevant, but turned out I'd forgotten I'm carrying 3 +> +patches that aren't upstream (and one is a horrible hack). +> +> +Hack: +https://lore.kernel.org/linux-cxl/20220819094655.000005ed@huawei.com/ +> +Shouldn't affect a simple case like this... +> +> +https://lore.kernel.org/linux-cxl/20220819093133.00006c22@huawei.com/T/#t +> +(Dan's version) +> +> +https://lore.kernel.org/linux-cxl/20220815154044.24733-1-Jonathan.Cameron@huawei.com/T/#t +> +> +For writes to work you will currently need two rps (nothing on the second is +> +fine) +> +as we still haven't resolved if the kernel should support an HDM decoder on +> +a host bridge with one port. I think it should (Spec allows it), others +> +unconvinced. +> +> +Note I haven't shifted over to x86 yet so may still be something different +> +from +> +arm64. +> +> +Jonathan +> +> + diff --git a/results/classifier/zero-shot/108/permissions/2704 b/results/classifier/zero-shot/108/permissions/2704 new file mode 100644 index 000000000..a657b6dec --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2704 @@ -0,0 +1,317 @@ +semantic: 0.940 +permissions: 0.936 +performance: 0.929 +debug: 0.927 +network: 0.917 +graphic: 0.905 +boot: 0.901 +device: 0.881 +KVM: 0.877 +files: 0.876 +other: 0.870 +PID: 0.817 +socket: 0.784 +vnc: 0.740 + +Error when migrating s390x VM from QEMU 9.0 to 9.1: Unknown savevm section or instance 's390_css' +Description of problem: +I have been working on merging QEMU 9.1.1 (directly from Debian unstable), and I'm seeing this problem when trying to migrate an s390x VM from an Oracular host (which runs QEMU 9.0.2) to a Plucky host (which runs QEMU 9.1.1). + +The problem only happens on s390x (host and guest), and only when attempting to migrate from Oracular to Plucky. Migrations between Oracular guests work fine, as well as migrations between Plucky guests. + +This is the error I see after invoking `virsh migrate`: + +``` +error: internal error: QEMU unexpectedly closed the monitor (vm='kvmguest-jammy-normal'): +2024-11-27T21:13:43.745625Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices +2024-11-27T21:13:43.746914Z qemu-system-s390x: load of migration failed: Invalid argument +``` +Steps to reproduce: +I only have one s390x machine available, so I am resorting to creating two LXD containers that are KVM-capable. One of the containers runs Oracular, the other runs Plucky. Please let me know if you would instructions on how to create such containers. + +Inside the Oracular container, using `uvt-kvm` to simplify the process of creating the VM: + +``` +# uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=s390x label=daily release=oracular +# cat > guesttemplate.xml << _EOF_ +<domain type='kvm'> + <os> + <type>hvm</type> + <boot dev='hd'/> + </os> + <devices> + <interface type='network'> + <source network='default'/> + <model type='virtio'/> + </interface> + <console type='pty' tty='/dev/pts/3'> + <source path='/dev/pts/3'/> + <target type='sclp' port='0'/> + <alias name='console0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + </channel> + </devices> +</domain> +_EOF_ +# uvt-kvm create --template /root/guesttemplate.xml --machine-type s390-ccw-virtio-9.0 --password=ubuntu --ssh-public-key-file /home/ubuntu/.ssh/authorized_keys kvmguest-oracular-upstream-cpu release=oracular arch=s390x label=daily +``` + +Wait a moment for the VM to boot, use `virsh list` to make sure it's running. Note that we force the machine type to be `s390-ccw-virtio-9.0`; this is necessary because Ubuntu overrides the default machine type with its own definition, and we want to make sure to use upstream's type here. + +Make sure you're running QEMU 9.1.1 at least on the Plucky container. Plucky currently ships with QEMU 9.0.2, which doesn't have the problem. If needed, my QEMU 9.1.1 build can be found at https://launchpad.net/~sergiodj/+archive/ubuntu/qemu. + +After everything is in place, try to migrate the machine: + +``` +# virsh migrate --unsafe --live kvmguest-oracular-upstream-cpu qemu+ssh://plucky-container-IP-here/system +error: internal error: QEMU unexpectedly closed the monitor (vm='kvmguest-oracular-upstream-cpu'): 2024-11-29T22:28:21.417201Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices +2024-11-29T22:28:21.417496Z qemu-system-s390x: load of migration failed: Invalid argument +``` +Additional information: +libvirt log from Oracular (QEMU 9.0.2): + +``` +LC_ALL=C \ [2/1817] +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin \ +USER=root \ +HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/.config \ +/usr/bin/qemu-system-s390x \ +-name guest=kvmguest-oracular-upstream-cpu,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-3-kvmguest-oracular-up/master-key.aes"}' \ +-machine s390-ccw-virtio-9.0,usb=off,dump-guest-core=off,memory-backend=s390.ram \ +-accel kvm \ +-cpu z13.2-base,aen=on,aefsi=on,diag318=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,cei=on,ap=on,gpereh=on,esop=on,ib=on,siif=on,ibs=on,apqi=on,apft=on,els=on,sief2=on,apqci=on,cte=on,ais=on,bpb=on,64bscao=on,ctop=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on,gsls=on \ +-m size=524288k \ +-object '{"qom-type":"memory-backend-ram","id":"s390.ram","size":536870912}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid fa8bcf1a-8982-47ab-9766-ebbb695008e3 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=38,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device '{"driver":"virtio-serial-ccw","id":"virtio-serial0","devno":"fe.0.0003"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY=","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":true,"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"}' \ +-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-2-format","id":"virtio-disk0","bootindex":1}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0001","drive":"libvirt-1-format","id":"virtio-disk1"}' \ +-netdev '{"type":"tap","fd":"39","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-ccw","netdev":"hostnet0","id":"net0","mac":"52:54:00:d8:f0:5c","devno":"fe.0.0002"}' \ +-chardev socket,id=charchannel0,fd=36,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev pty,id=charconsole0 \ +-device '{"driver":"sclpconsole","chardev":"charconsole0","id":"console0"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-device '{"driver":"virtio-balloon-ccw","id":"balloon0","devno":"fe.0.0004"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/3 (label charconsole0) +2024-11-28 20:56:00.522+0000: initiating migration +2024-11-28T20:56:01.114894Z qemu-system-s390x: Sibling indicated error 1 +warning: old compression is deprecated; use multifd compression methods instead +warning: old compression is deprecated; use multifd compression methods instead +warning: old compression is deprecated; use multifd compression methods instead +warning: block migration is deprecated; use blockdev-mirror with NBD instead +``` + +libvirt log from Plucky (QEMU 9.1.1): + +``` +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin \ +USER=root \ +HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/.config \ +/usr/bin/qemu-system-s390x \ +-name guest=kvmguest-oracular-upstream-cpu,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-4-kvmguest-oracular-up/master-key.aes"}' \ +-machine s390-ccw-virtio-9.0,usb=off,dump-guest-core=off,memory-backend=s390.ram \ +-accel kvm \ +-cpu z13.2-base,aen=on,aefsi=on,diag318=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,cei=on,ap=on,gpereh=on,esop=on,ib=on,siif=on,ibs=on,apqi=on,apft=on,els=on,sief2=on,apqci=on,cte=on,ais=on,bpb=on,64bscao=on,ctop=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on,gsls=on \ +-m size=524288k \ +-object '{"qom-type":"memory-backend-ram","id":"s390.ram","size":536870912}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid fa8bcf1a-8982-47ab-9766-ebbb695008e3 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=35,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device '{"driver":"virtio-serial-ccw","id":"virtio-serial0","devno":"fe.0.0003"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY=","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":true,"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"}' \ +-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-2-format","id":"virtio-disk0","bootindex":1}' \ +-blockdev '{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"virtio-blk-ccw","devno":"fe.0.0001","drive":"libvirt-1-format","id":"virtio-disk1"}' \ +-netdev '{"type":"tap","fd":"36","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-ccw","netdev":"hostnet0","id":"net0","mac":"52:54:00:d8:f0:5c","devno":"fe.0.0002"}' \ +-chardev socket,id=charchannel0,fd=34,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev pty,id=charconsole0 \ +-device '{"driver":"sclpconsole","chardev":"charconsole0","id":"console0"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-incoming defer \ +-device '{"driver":"virtio-balloon-ccw","id":"balloon0","devno":"fe.0.0004"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/3 (label charconsole0) +2024-11-29T22:28:21.417201Z qemu-system-s390x: Unknown savevm section or instance 's390_css' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices +2024-11-29T22:28:21.417496Z qemu-system-s390x: load of migration failed: Invalid argument +``` + +Domain XML: + +```xml +<domain type='kvm' id='3'> + <name>kvmguest-oracular-upstream-cpu</name> + <uuid>fa8bcf1a-8982-47ab-9766-ebbb695008e3</uuid> + <metadata> + <uvt:ssh_known_hosts xmlns:uvt="https://launchpad.net/uvtool/libvirt/1">ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDhWPh2Wfm2Ouh/W+H9IXJGFHfH4UVCB6+EBI0PwuDXR2Ocl4hTTSNPSX2LVS4MfVn9pgl5BK9MUVsMPfFjhmEhpNNt+rmaCelrDT8A7v/RoBY4IGEBFMhAkiwlI7pk3BrFoHEKtiijNLEWczdjMigZvhTs2amn8cUotFIsQSTpM7+7IX+m7clxfe6p59mVPjfMzBhwDG0GyV7CXdMpvsGlE2mPSacWWZ/baWIoFjKcmyQtTjSQleH1qSthI8rD5F7EyYd1Oa8Bo7vZ9j1/DPeGQRJPkebO81hPjm/1x1H5pTITIzARdNuBkM0yuDyqMQLP/u65WGinvXJYm20gEvMbiHGaT3il1QKKNEGmNGtY/SedRE8XQ58n090IBLz/3WJtjgQCY/SRgHUv7nMYYenmshvBfdue9kExJTjwWTRtT2R2UdkxS5UVye4vvDAY0DFuqX13wyvIeCU28MU+HpmnE31m9uXlVXXZxDuqGUBJ1PrDc4a40bvj9yTZTn9NEOs= root@localhost +ssh-dss AAAAB3NzaC1kc3MAAACBAKqzgDKUGk6P/h6N5X4nJoHPr+MQzzXkotN8XEihvtWwvV1KYK+ioT69nA7ThEAZ6rPEjWPt7X4Sy6BcNd4j3kzlaXYLkrMJm3nohqbqQBDxCv8bhozy6HS/VDu95vrpnNFSiMRCfbBye0zyKfZsuRaPaKfHQ+8MnsBqSPxKajFrAAAAFQDuG3ZoanC+oZwMRYZ/am0vhfD+EwAAAIEAixSzoZr03kYZE+LcusyrasvZIqKF3P4M2vtzvFBPpPccFB5XoaqhWI4PvSxGYxZxlj9vRmSc8Yv56jdn8oDPIhFfgZVbDIkvpB2jQdb5VaRVWj7XwUcHB7B117Dr9qA6+6HJtBLRTDdTXzMQ+NhdFp42XCF+1qRefH9VPL9FoxwAAACAJa+u/YvaiGwT0DXBtTz4PgyFYmNHPvXBOVhDAw0likajBiuOdn8oL4KuWTafCq5ReDxXFaMML0OuT86+lSVt2naX0idyHjuSPkgmatozlpcz0kWYhuBl1B1sa3kr8xjDOUJlxkybqpdGJ5aoW+kRO+bpJLEzuXtu6Xshw5fOBZw= root@localhost +ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHI8u/wAvZLJqIpAd5YSpu9VEaRQOxy0FKzyryeb3kjahkryKPhSX65miZ9Lx7oz5nORFsdeS2xR56ZQj+8HpqM= root@localhost +ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDXY+MW1SikusLdkhPrni76LlaZB042p/DVItVeHRCCa root@localhost +</uvt:ssh_known_hosts> + </metadata> + <memory unit='KiB'>524288</memory> + <currentMemory unit='KiB'>524288</currentMemory> + <vcpu placement='static'>1</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='s390x' machine='s390-ccw-virtio-9.0'>hvm</type> + <boot dev='hd'/> + </os> + <cpu mode='custom' match='exact' check='partial'> + <model fallback='forbid'>z13.2-base</model> + <feature policy='require' name='aen'/> + <feature policy='require' name='aefsi'/> + <feature policy='require' name='diag318'/> + <feature policy='require' name='msa5'/> + <feature policy='require' name='msa4'/> + <feature policy='require' name='msa3'/> + <feature policy='require' name='msa2'/> + <feature policy='require' name='msa1'/> + <feature policy='require' name='sthyi'/> + <feature policy='require' name='edat'/> + <feature policy='require' name='ri'/> + <feature policy='require' name='edat2'/> + <feature policy='require' name='vx'/> + <feature policy='require' name='ipter'/> + <feature policy='require' name='cei'/> + <feature policy='require' name='ap'/> + <feature policy='require' name='gpereh'/> + <feature policy='require' name='esop'/> + <feature policy='require' name='ib'/> + <feature policy='require' name='siif'/> + <feature policy='require' name='ibs'/> + <feature policy='require' name='apqi'/> + <feature policy='require' name='apft'/> + <feature policy='require' name='els'/> + <feature policy='require' name='sief2'/> + <feature policy='require' name='apqci'/> + <feature policy='require' name='cte'/> + <feature policy='require' name='ais'/> + <feature policy='require' name='bpb'/> + <feature policy='require' name='64bscao'/> + <feature policy='require' name='ctop'/> + <feature policy='require' name='ppa15'/> + <feature policy='require' name='zpci'/> + <feature policy='require' name='sea_esop2'/> + <feature policy='require' name='te'/> + <feature policy='require' name='cmm'/> + <feature policy='require' name='gsls'/> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-s390x</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu.qcow' index='2'/> + <backingStore type='file' index='3'> + <format type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MjQuMTA6czM5MHggMjAyNDExMjY='/> + <backingStore/> + </backingStore> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/kvmguest-oracular-upstream-cpu-ds.qcow' index='1'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/> + </disk> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0003'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d8:f0:5c'/> + <source network='default' portid='8b9c05f0-9534-4e05-afff-ec73e4a55b9c' bridge='virbr0'/> + <target dev='vnet1'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0002'/> + </interface> + <console type='pty' tty='/dev/pts/3'> + <source path='/dev/pts/3'/> + <target type='sclp' port='0'/> + <alias name='console0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/run/libvirt/qemu/channel/3-kvmguest-oracular-up/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <audio id='1' type='none'/> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/> + </memballoon> + <panic model='s390'/> + </devices> + <seclabel type='dynamic' model='apparmor' relabel='yes'> + <label>libvirt-fa8bcf1a-8982-47ab-9766-ebbb695008e3</label> + <imagelabel>libvirt-fa8bcf1a-8982-47ab-9766-ebbb695008e3</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+64055:+993</label> + <imagelabel>+64055:+993</imagelabel> + </seclabel> +</domain> +``` diff --git a/results/classifier/zero-shot/108/permissions/2832 b/results/classifier/zero-shot/108/permissions/2832 new file mode 100644 index 000000000..6d525badc --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2832 @@ -0,0 +1,114 @@ +permissions: 0.937 +performance: 0.925 +other: 0.916 +semantic: 0.915 +PID: 0.911 +device: 0.909 +graphic: 0.899 +debug: 0.867 +files: 0.846 +boot: 0.830 +socket: 0.815 +KVM: 0.808 +network: 0.768 +vnc: 0.676 + +Random kernel panic (2/3) in github macOS runner: IO-APIC + timer doesn't work! +Description of problem: +Random kernel panic (2/3 runs average) with this traceback: + +``` +[ 0.020000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. +[ 0.020000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-14-generic #15-Ubuntu +[ 0.020000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024 +[ 0.020000] Call Trace: +[ 0.020000] <TASK> +[ 0.020000] show_stack+0x49/0x60 +[ 0.020000] dump_stack_lvl+0x5f/0x90 +[ 0.020000] dump_stack+0x10/0x18 +[ 0.020000] panic+0x16a/0x328 +[ 0.020000] check_timer+0x4d1/0x570 +[ 0.020000] setup_IO_APIC+0x1e5/0x210 +[ 0.020000] apic_intr_mode_init+0xd0/0xf0 +[ 0.020000] x86_late_time_init+0x24/0x40 +[ 0.020000] start_kernel+0x3f9/0x4a0 +[ 0.020000] x86_64_start_reservations+0x24/0x30 +[ 0.020000] x86_64_start_kernel+0xf2/0x100 +[ 0.020000] common_startup_64+0x13e/0x141 +[ 0.020000] </TASK> +[ 0.020000] ---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. ]--- +``` +Steps to reproduce: +1. Start qemu in macos-13 github runner +Additional information: +Example failed build: +https://github.com/nirs/vmnet-helper/actions/runs/13477646025/job/37658748139 + +serial.log: +``` +3h3hBdsDxe: failed to load Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x1,0x0)/Scsi(0x0,0x0): Not Found +BdsDxe: loading Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0) +BdsDxe: starting Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0) +EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path +[ 0.000000] Linux version 6.11.0-14-generic (buildd@lcy02-amd64-032) (x86_64-linux-gnu-gcc-14 (Ubuntu 14.2.0-4ubuntu2) 14.2.0, GNU ld (GNU Binutils for Ubuntu) 2.43.1) #15-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 10 23:48:25 UTC 2025 (Ubuntu 6.11.0-14.15-generic 6.11.0) +[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.11.0-14-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 +[ 0.000000] KERNEL supported cpus: +[ 0.000000] Intel GenuineIntel +[ 0.000000] AMD AuthenticAMD +[ 0.000000] Hygon HygonGenuine +[ 0.000000] Centaur CentaurHauls +[ 0.000000] zhaoxin Shanghai +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080afff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000080b000-0x000000000080bfff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000000080c000-0x0000000000810fff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000811000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000003ee41fff] usable +[ 0.000000] BIOS-e820: [mem 0x000000003ee42000-0x000000003ef02fff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000003ef03000-0x000000003f8ecfff] usable +[ 0.000000] RCU Tasks: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. +[ 0.000000] RCU Tasks Rude: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. +[ 0.000000] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. +[ 0.000000] NR_IRQS: 524544, nr_irqs: 256, preallocated irqs: 16 +[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. +[ 0.000000] Console: colour dummy device 80x25 +[ 0.000000] printk: legacy console [tty1] enabled +[ 0.000000] printk: legacy console [ttyS0] enabled +[ 0.000000] ACPI: Core revision 20240322 +[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.001000] APIC: Switch to symmetric I/O mode setup +[ 0.003000] x2apic: IRQ remapping doesn't support X2APIC mode +[ 0.011000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.013000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC +[ 0.013000] ...trying to set up timer (IRQ0) through the 8259A ... +[ 0.013000] ..... (found apic 0 pin 2) ... +[ 0.014000] ....... failed. +[ 0.014000] ...trying to set up timer as Virtual Wire IRQ... +[ 0.018000] ..... failed. +[ 0.018000] ...trying to set up timer as ExtINT IRQ... +[ 0.020000] ..... failed :(. +[ 0.020000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. +[ 0.020000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-14-generic #15-Ubuntu +[ 0.020000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024 +[ 0.020000] Call Trace: +[ 0.020000] <TASK> +[ 0.020000] show_stack+0x49/0x60 +[ 0.020000] dump_stack_lvl+0x5f/0x90 +[ 0.020000] dump_stack+0x10/0x18 +[ 0.020000] panic+0x16a/0x328 +[ 0.020000] check_timer+0x4d1/0x570 +[ 0.020000] setup_IO_APIC+0x1e5/0x210 +[ 0.020000] apic_intr_mode_init+0xd0/0xf0 +[ 0.020000] x86_late_time_init+0x24/0x40 +[ 0.020000] start_kernel+0x3f9/0x4a0 +[ 0.020000] x86_64_start_reservations+0x24/0x30 +[ 0.020000] x86_64_start_kernel+0xf2/0x100 +[ 0.020000] common_startup_64+0x13e/0x141 +[ 0.020000] </TASK> +[ 0.020000] ---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. ]--- +``` + +Same Ubuntu image never fail with vfkit vm on the same macos-13 github runners. diff --git a/results/classifier/zero-shot/108/permissions/2835 b/results/classifier/zero-shot/108/permissions/2835 new file mode 100644 index 000000000..b0de964a8 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2835 @@ -0,0 +1,137 @@ +permissions: 0.974 +graphic: 0.959 +performance: 0.955 +debug: 0.954 +network: 0.947 +semantic: 0.943 +other: 0.935 +socket: 0.929 +device: 0.922 +vnc: 0.915 +PID: 0.914 +boot: 0.914 +files: 0.905 +KVM: 0.818 + +qtest-x86_64/migration-test times out (hangs?) +Description of problem: +The `qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test` always times out, after updating QEMU from 8.2.2 to 9.1.3 on GNU Guix. Here's an excerpt from testlog.txt, attached in full below: +``` +test: qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test +start time: 15:24:17 +duration: 480.01s +result: killed by signal 15 SIGTERM +command: QTEST_QEMU_BINARY=./qemu-system-x86_64 MESON_TEST_ITERATION=1 MALLOC_PERTURB_=66 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 PYTHON=/tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/b/qemu/pyvenv/bin/python3 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 G_TEST_DBUS_DAEMON=/tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/tests/dbus-vmstate-daemon.sh UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 /tmp/guix-build-qemu-9.1.3.drv-0/qemu-9.1.3/b/qemu/tests/qtest/migration-test --tap -k +----------------------------------- stdout ----------------------------------- +TAP version 13 +# random seed: R02S840f7fe2af5c1c1e5b9ead2a7f451731 +# Skipping test: userfaultfd not available +1..56 +# Start of x86_64 tests +# Start of migration tests +# Running /x86_64/migration/bad_dest +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming tcp:127.0.0.1:0 -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +ok 1 /x86_64/migration/bad_dest +# slow test /x86_64/migration/bad_dest executed in 0.60 secs +# Running /x86_64/migration/analyze-script +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming tcp:127.0.0.1:0 -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 2 /x86_64/migration/analyze-script +# slow test /x86_64/migration/analyze-script executed in 0.88 secs +# Running /x86_64/migration/vmstate-checker-script +ok 3 /x86_64/migration/vmstate-checker-script # SKIP Test needs two different QEMU versions +# Running /x86_64/migration/validate_uuid +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 -accel qtest +ok 4 /x86_64/migration/validate_uuid +# slow test /x86_64/migration/validate_uuid executed in 32.74 secs +# Running /x86_64/migration/validate_uuid_error +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 22222222-2222-2222-2222-222222222222 2>/dev/null -accel qtest +ok 5 /x86_64/migration/validate_uuid_error +# slow test /x86_64/migration/validate_uuid_error executed in 32.62 secs +# Running /x86_64/migration/validate_uuid_src_not_set +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 22222222-2222-2222-2222-222222222222 2>/dev/null -accel qtest +ok 6 /x86_64/migration/validate_uuid_src_not_set +# slow test /x86_64/migration/validate_uuid_src_not_set executed in 32.73 secs +# Running /x86_64/migration/validate_uuid_dst_not_set +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -uuid 11111111-1111-1111-1111-111111111111 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +ok 7 /x86_64/migration/validate_uuid_dst_not_set +# slow test /x86_64/migration/validate_uuid_dst_not_set executed in 32.74 secs +# Running /x86_64/migration/dirty_ring +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 8 /x86_64/migration/dirty_ring +# slow test /x86_64/migration/dirty_ring executed in 33.89 secs +# Running /x86_64/migration/vcpu_dirty_limit +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm,dirty-ring-size=4096 -name dirtylimit-test,debug-threads=on -m 150M -smp 1 -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/vm_serial -drive file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -accel qtest +ok 9 /x86_64/migration/vcpu_dirty_limit +# slow test /x86_64/migration/vcpu_dirty_limit executed in 13.17 secs +# Start of precopy tests +# Running /x86_64/migration/precopy/file +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 10 /x86_64/migration/precopy/file +# slow test /x86_64/migration/precopy/file executed in 33.10 secs +# Start of unix tests +# Running /x86_64/migration/precopy/unix/plain +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 11 /x86_64/migration/precopy/unix/plain +# slow test /x86_64/migration/precopy/unix/plain executed in 33.89 secs +# Running /x86_64/migration/precopy/unix/xbzrle +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 12 /x86_64/migration/precopy/unix/xbzrle +# slow test /x86_64/migration/precopy/unix/xbzrle executed in 59.80 secs +# Start of suspend tests +# Running /x86_64/migration/precopy/unix/suspend/live +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 13 /x86_64/migration/precopy/unix/suspend/live +# slow test /x86_64/migration/precopy/unix/suspend/live executed in 65.90 secs +# Running /x86_64/migration/precopy/unix/suspend/notlive +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 14 /x86_64/migration/precopy/unix/suspend/notlive +# slow test /x86_64/migration/precopy/unix/suspend/notlive executed in 65.09 secs +# End of suspend tests +# Start of tls tests +# Running /x86_64/migration/precopy/unix/tls/psk +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +ok 15 /x86_64/migration/precopy/unix/tls/psk +# slow test /x86_64/migration/precopy/unix/tls/psk executed in 33.28 secs +# Start of x509 tests +# Running /x86_64/migration/precopy/unix/tls/x509/default-host +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +ok 16 /x86_64/migration/precopy/unix/tls/x509/default-host +# slow test /x86_64/migration/precopy/unix/tls/x509/default-host executed in 0.78 secs +# Running /x86_64/migration/precopy/unix/tls/x509/override-host +# Using machine type: pc-q35-9.1 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name source,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/src_serial -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.sock -qtest-log /dev/null -chardev socket,path=/tmp/guix-build-qemu-9.1.3.drv-0/qtest-25307.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.1, -name target,debug-threads=on -m 150M -serial file:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/dest_serial -incoming unix:/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/migsocket -drive if=none,id=d0,file=/tmp/guix-build-qemu-9.1.3.drv-0/migration-test-N4XC22/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +============================================================================== +``` +Steps to reproduce: +1. Run `make check` +Additional information: +[testlog.txt.gz](/uploads/29c9c4f259b255297a6418e8f7493397/testlog.txt.gz) diff --git a/results/classifier/zero-shot/108/permissions/2875 b/results/classifier/zero-shot/108/permissions/2875 new file mode 100644 index 000000000..8249575a4 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2875 @@ -0,0 +1,44 @@ +permissions: 0.960 +other: 0.959 +graphic: 0.932 +device: 0.930 +network: 0.926 +debug: 0.924 +semantic: 0.918 +files: 0.916 +performance: 0.906 +PID: 0.905 +socket: 0.898 +vnc: 0.891 +boot: 0.863 +KVM: 0.852 + +[Virtio-GPU Venus] QEMU Virtio-GPU Venus with Lavapipe ICD shows corrupted graphical output along with error prints +Description of problem: +QEMU Virtio-GPU Venus with Lavapipe ICD shows corrupted graphical output (screenshots attached ahead) along with the following error prints, as guest_errors are enabled in QEMU command line `-d guest_errors`: +``` +VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json ./qemu-system-x86_64 -enable-kvm -M q35 -smp 4 -m 4G -cpu host -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 -d guest_errors -device virtio-vga-gl,hostmem=4G,blob=true,venus=true -vga none -display gtk,gl=on,show-cursor=on -usb -device usb-tablet -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1 -hda ubuntu-2504.qcow2 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +virtio_gpu_virgl_unmap_resource_blob: failed to unmap virgl resource: Invalid argument +virtio_gpu_virgl_process_cmd: ctrl 0x209, error 0x1200 +``` +Steps to reproduce: +1. Used steps mentioned here: https://gist.github.com/peppergrayxyz/fdc9042760273d137dddd3e97034385f, to build virglrenderer-1.1.0 with Venus support, and to build QEMU (latest: v10.0.0-rc1) with virglrenderer support. +2. Run QEMU with Lavapipe ICD using the command shared above. +3. When the QEMU guest is up, install required packages such as `sudo apt-get install -y mesa* vulkan* libvulkan* vkmark` and run vkcube / vkmark with VirtIO ICD: +``` +VK_DRIVER_FILES=/usr/share/vulkan/icd.d/virtio_icd.x86_64.json vkcube --wsi wayland +``` +Additional information: +Attaching screenshots for the error observed on guest side: +,  +Collected logs with tracing enabled (`meson setup -Dvenus=true -Dvenus-validate=true -Dvideo=true -Dtracing=stderr build`) in virglrenderer as well: [virgl-tracing-stderr.log](/uploads/202c698b7c265cde7c83b441a6a7abdb/virgl-tracing-stderr.log). Search for error in the log file. diff --git a/results/classifier/zero-shot/108/permissions/2983 b/results/classifier/zero-shot/108/permissions/2983 new file mode 100644 index 000000000..d7dac4d93 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/2983 @@ -0,0 +1,130 @@ +permissions: 0.952 +files: 0.938 +debug: 0.936 +device: 0.925 +performance: 0.924 +vnc: 0.913 +other: 0.910 +PID: 0.891 +semantic: 0.887 +KVM: 0.884 +network: 0.882 +socket: 0.878 +graphic: 0.869 +boot: 0.851 + +qemu-system-riscv64 randomly turns MPP bits to 0 in the mstatus word. +Description of problem: +ToyOs runs the kernel in machine mode and user programs in user mode. This is specific choice on my part to make sure the kernel code runs with machine address and user code runs with virtual addresses. This is different than Linux, NetBSD or other OSes I know that run the kernel in supervisor mode. When running in machine mode and running kernel code, I get a a trap. My error message looks like this: + +PANIC: Unexpected trap from machine mode! + mepc = 0x800002a8, mcause = 2, mtval=0xe78023 mstatus=0xa00000080 + +Notice, the mstatus bits show the trap was due to a privileged instruction being run by a "user" mode instruction. In the "assignment version" used for the above, no user code was run. It was just multiple threads running in machine mode. Also, the trap function is run with the MPP bits of 0, so even trying to recover from this trap can't be done as trying to manipulate the mstatus will generate yet again another trap to the same place and still running in "user" mode. + +This change does not happen on every run. It happens more consistently recently when trying to debug the kernel with gdb. This must be a race condition somewhere. + +The kernel is written in C++ with C libraries. +Steps to reproduce: +1. You will need to have access to my kernel and possibly my code base. This is a code base that I want to stay at WWU (Western Washington University). +2. Give the command "bmake run". It often completes with no problems, but if you run it often enough it will generate this trap from "machine mode". The example above had four good runs with no errors and on the fifth run it blew up. There is not guaranteed way to get this to have a problem. (This is why I haven't reported it before, I kept trying to get a minimal code set that had the problem, but I couldn't do it.) +Additional information: +This is a bug has been a problem for several years. It didn't strike very often on some versions of qemu. I think one of the 7.x.x versions happened not too often. But with newer, faster machines and a different version of Linux, this bug has become a big problem for me and my students. + +Here is a sample bad run: (All compilation has been done before so this just makes sure everything is up-to-date and then runs qemu-system-riscv64. In this assignment, no user mode code is being run. Threads are all running in machine mode for the entire time. I am getting clock interrupts on the CPU, but that does not appear to be the problem.) + +$ bmake run +if ! [ -e toolbin ] ; then mkdir toolbin ; fi; +(cd tools; bmake install) +(cd toy_fs; bmake) +`toyfs' is up to date. +(cd mkdep; bmake) +`mkdep' is up to date. +(cd toy_fs; bmake install) +(cd mkdep; bmake install) +Making in /home/phil/447/csci447_s25/lib +Making in /home/phil/447/csci447_s25/kernel +`DISK' is up to date. +qemu-system-riscv64 -machine virt -bios none -m 1G -smp 1 -nographic -global virtio-mmio.force-legacy=false -drive file=DISK,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -kernel kernel/kernel -gdb tcp::27277 +Initializing scheduler ... +Initializing frame set... +Initializing thread set ... +Initializing process set ... +Initializing fcb set ... +Initializing OpenFile set ... +Initializing pipe set ... +Initializing vertio ... +Initializing filesystem ... +Starting os_main ... +PANIC: Unexpected trap from machine mode! + mepc = 0x800002a8, mcause = 2, mtval=0xe78023 mstatus=0xa00000080 +attach with gdb! +QEMU: Terminated + +$ riscv64-unknown-elf-addr2line -e kernel/kernel 0x800002a8 +/home/phil/447/csci447_s25/kernel/runtime.S:350 + +And that instruction turns out to be "mret", the return from the clock interrupt. + +The following is a error free run of this. + +$ bmake run +if ! [ -e toolbin ] ; then mkdir toolbin ; fi; +(cd tools; bmake install) +(cd toy_fs; bmake) +`toyfs' is up to date. +(cd mkdep; bmake) +`mkdep' is up to date. +(cd toy_fs; bmake install) +(cd mkdep; bmake install) +Making in /home/phil/447/csci447_s25/lib +Making in /home/phil/447/csci447_s25/kernel +`DISK' is up to date. +qemu-system-riscv64 -machine virt -bios none -m 1G -smp 1 -nographic -global virtio-mmio.force-legacy=false -drive file=DISK,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -kernel kernel/kernel -gdb tcp::27277 +Initializing scheduler ... +Initializing frame set... +Initializing thread set ... +Initializing process set ... +Initializing fcb set ... +Initializing OpenFile set ... +Initializing pipe set ... +Initializing vertio ... +Initializing filesystem ... +Starting os_main ... + +Welcome to Toy OS, hartid = 0 +Assignment 3 ... + +********** Frame Tester ********** +1.3.2.4.5.6.7.8.9.10.12.11.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.85.84.87.86.88.89.91.92.90.93.94.95.96.97.98.99.100.101.102.103.104.105.106.107.108.109.110.111.113.112.114.115.116.117.119.118.120.121.122.123.124.125.126.127.128.129.130.131.132.133.134.135.136.137.138.139.140.161.162.163.164.166.165.167.168.169.170.171.172.173.174.175.177.178.176.179.180.181.182.183.184.185.186.187.188.189.190.191.194.193.192.195.197.196.198.200.199.201.202.203.204.206.205.207.209.208.210.211.212.214.213.215.216.217.218.219.220.221.222.223.224.225.226.227.228.230.231.229.232.233.234.235.236.237.238.239.240.241.242.243.244.245.246.247.248.249.250.252.253.251.254.255.256.257.258.259.260.261.262.263.264.265.266.267.268.269.270.271.273.272.274.275.276.277.278.279.280.281.282.283.284.285.286.287.288.289.290.291.292.293.294.295.296.297.298.299.300.301.302.303.304.305.306.308.307.309.310.311.312.313.314.315.316.317.318.319.320.341.342.343.344.345.346.347.348.349.350.351.353.352.354.356.355.357.358.359.360.361.362.363.364.365.366.367.368.369.370.371.372.373.374.375.376.377.378.379.380.382.381.383.384.385.386.387.388.389.390.391.392.394.395.393.396.397.398.399.400.401.402.403.404.405.406.407.409.408.410.411.412.413.414.415.416.417.418.420.419.421.422.423.425.426.424.427.428.429.430.432.431.433.434.435.436.437.438.439.440.441.442.443.444.445.446.447.448.449.450.451.452.453.455.454.457.456.458.459.460.461.462.463.464.465.466.467.468.469.470.471.472.473.474.475.476.477.478.479.480.481.482.483.484.485.486.487.488.489.490.491.492.493.494.495.496.497.498.499.500.521.523.522.524.525.526.528.527.529.530.531.532.533.534.535.536.537.538.539.540.542.544.543.541.545.546.548.547.549.551.550.553.552.555.554.557.556.559.558.560.561.562.563.564.565.566.567.568.569.570.571.572.573.574.575.576.577.578.579.580.581.582.583.584.585.586.587.588.589.590.591.592.593.594.595.596.597.598.599.600.601.602.603.604.605.606.607.608.609.610.611.612.613.614.615.616.617.618.619.620.621.622.623.624.625.626.627.628.629.630.631.632.633.634.635.636.637.638.639.640.641.642.643.644.645.646.647.648.649.650.651.652.653.654.655.656.657.658.659.660.661.662.663.664.665.666.667.668.669.670.671.672.673.675.674.676.677.678.679.680.701.702.704.703.705.706.707.708.709.711.710.712.713.714.715.716.717.718.719.720.723.722.721.724.725.727.726.728.729.730.731.732.733.734.735.737.736.738.739.741.740.742.744.743.746.747.745.748.749.750.751.752.753.754.756.755.757.758.759.761.760.762.763.764.765.766.767.768.769.770.771.772.773.774.775.776.777.778.780.779.781.782.783.784.785.786.787.788.789.790.791.792.793.794.795.797.796.798.799.800.801.802.803.804.805.806.807.808.809.810.811.812.813.814.815.816.817.818.819.820.821.822.823.825.824.826.827.828.829.830.831.832.833.834.835.836.837.838.839.840.841.842.843.844.845.846.847.848.849.850.851.852.853.854.855.856.857.858.859.860.882.881.884.883.885.886.888.887.890.889.891.892.893.894.895.896.897.898.899.901.900.902.903.904.905.906.907.908.909.910.911.913.912.914.915.916.917.918.919.920.921.922.923.924.925.926.928.927.929.930.931.932.933.934.935.936.937.939.938.940.941.942.943.944.945.946.947.948.949.950.951.952.953.954.955.956.957.958.959.961.960.962.963.964.965.966.967.968.969.970.971.972.973.974.975.976.977.978.979.980.981.982.983.984.985.986.987.988.989.990.991.992.993.994.995.996.997.998.999.1000.1001.1002.1003.1004.1005.1006.1008.1007.1009.1010.1011.1012.1014.1013.1015.1016.1017.1018.1019.1020.1021.1022.1023.1024.1025.1026.1027.1028.1029.1030.1031.1032.1033.1034.1035.1036.1037.1038.1039.1040.1061.1062.1063.1065.1064.1066.1069.1067.1068.1070.1071.1072.1073.1074.1075.1076.1077.1078.1079.1080.1082.1081.1084.1083.1085.1086.1087.1088.1089.1090.1091.1093.1092.1094.1095.1097.1096.1098.1099.1100.1101.1102.1103.1104.1105.1106.1107.1109.1108.1110.1111.1112.1113.1114.1115.1117.1116.1118.1119.1120.1121.1122.1123.1124.1125.1126.1127.1128.1129.1130.1131.1132.1133.1134.1135.1136.1137.1138.1139.1140.1141.1142.1143.1144.1145.1146.1147.1148.1149.1150.1151.1152.1153.1154.1155.1156.1157.1158.1159.1160.1161.1162.1163.1164.1165.1166.1167.1168.1169.1170.1172.1171.1173.1174.1175.1176.1177.1178.1179.1180.1181.1182.1183.1184.1185.1186.1187.1188.1189.1190.1191.1192.1193.1194.1195.1196.1197.1198.1199.1201.1200.1202.1203.1204.1205.1207.1206.1208.1209.1210.1211.1212.1213.1214.1215.1216.1217.1218.1219.1220.1241.1242.1244.1243.1245.1246.1247.1248.1249.1251.1250.1252.1253.1254.1255.1256.1257.1258.1259.1260.1261.1262.1263.1264.1265.1266.1267.1269.1268.1270.1272.1271.1274.1273.1275.1276.1277.1278.1279.1280.1281.1283.1282.1284.1285.1287.1286.1288.1290.1289.1291.1292.1293.1294.1295.1296.1297.1299.1298.1300.1301.1302.1303.1304.1305.1306.1307.1308.1309.1310.1311.1312.1313.1315.1314.1316.1317.1318.1319.1320.1321.1322.1323.1324.1325.1326.1327.1328.1329.1330.1331.1332.1333.1335.1334.1336.1337.1338.1339.1340.1341.1342.1343.1344.1345.1346.1347.1348.1349.1350.1351.1352.1353.1354.1355.1356.1357.1358.1360.1361.1359.1362.1364.1363.1365.1366.1367.1370.1369.1368.1371.1372.1373.1375.1374.1376.1377.1378.1379.1380.1381.1382.1383.1384.1385.1386.1387.1388.1389.1390.1391.1392.1393.1394.1395.1396.1397.1398.1400.1401.1419.1422.1423.1424.1426.1425.1427.1428.1429.1431.1430.1432.1434.1435.1433.1437.1436.1438.1440.1439.1441.1447.1442.1443.1444.1445.1446.1448.1449.1450.1452.1453.1451.1454.1455.1456.1457.1459.1458.1461.1460.1462.1463.1464.1465.1466.1467.1468.1469.1470.1471.1472.1473.1474.1475.1476.1477.1478.1479.1480.1481.1482.1483.1484.1486.1485.1487.1488.1489.1490.1491.1492.1493.1494.1495.1496.1498.1497.1499.1500.1501.1502.1503.1504.1505.1506.1507.1508.1509.1510.1511.1512.1513.1514.1515.1516.1517.1519.1518.1520.1521.1522.1523.1524.1525.1526.1527.1528.1529.1530.1531.1532.1533.1534.1535.1536.1537.1538.1539.1540.1541.1542.1543.1544.1545.1547.1546.1548.1549.1550.1551.1553.1552.1554.1555.1556.1557.1558.1559.1560.1561.1562.1563.1564.1565.1566.1567.1568.1569.1570.1571.1572.1573.1574.1575.1576.1577.1578.1579.1581.1600.1602.1603.1604.1605.1607.1606.1608.1609.1610.1612.1611.1613.1614.1616.1615.1617.1618.1619.1622.1621.1620.1623.1624.1625.1626.1627.1628.1629.1630.1631.1632.1633.1635.1634.1636.1637.1638.1639.1640.1641.1642.1643.1644.1646.1645.1647.1648.1650.1649.1652.1651.1653.1654.1655.1656.1657.1658.1659.1660.1661.1663.1662.1664.1665.1666.1667.1668.1669.1670.1671.1672.1673.1674.1675.1676.1677.1678.1679.1680.1681.1682.1683.1685.1684.1686.1687.1688.1689.1691.1690.1692.1693.1694.1695.1696.1698.1697.1699.1700.1701.1702.1703.1704.1705.1706.1707.1708.1709.1710.1711.1713.1712.1714.1715.1717.1716.1718.1719.1720.1721.1722.1723.1724.1725.1726.1727.1728.1729.1730.1731.1732.1733.1734.1735.1736.1737.1738.1739.1740.1741.1742.1743.1744.1745.1746.1747.1748.1749.1751.1750.1752.1753.1754.1755.1756.1757.1758.1759.1762.1780.1781.1784.1785.1783.1787.1788.1786.1789.1790.1791.1792.1794.1793.1795.1796.1799.1797.1800.1798. +Frame 0, used 0x Frame 1, used 0x Frame 2, used 0x +Frame 3, used 438x Frame 4, used 435x Frame 5, used 429x +Frame 6, used 420x Frame 7, used 414x Frame 8, used 407x +Frame 9, used 396x Frame 10, used 391x Frame 11, used 386x +Frame 12, used 374x Frame 13, used 372x Frame 14, used 367x +Frame 15, used 361x Frame 16, used 353x Frame 17, used 345x +Frame 18, used 342x Frame 19, used 335x Frame 20, used 330x +Frame 21, used 329x Frame 22, used 325x Frame 23, used 319x +Frame 24, used 271x Frame 25, used 262x Frame 26, used 255x +Frame 27, used 141x Frame 28, used 108x Frame 29, used 95x +********** Test Done ********** + +********** Thread Tester ********** +3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.2.22.20.30.31.24.21.23.25.26.32.27.33.39.40.41.28.29.35.34.36.42.44.48.49.50.37.51.38.45.46.52.55.57.43.58.60.53.61.62.56.63.65.67.68.47.70.71.64.72.73.74.69.54.77.78.59.81.82.75.83.76.85.79.86.89.91.92.84.93.66.87.80.94.96.98.101.102.103.95.88.104.97.99.105.108.110.111.112.113.100.114.107.115.109.117.119.120.122.106.116.124.125.90.126.129.130.131.132.133.127.134.135.128.136.138.139.141.142.143.144.123.145.140.146.148.149.151.153.152.154.118.147.156.121.159.160.161.162.163.157.164.150.137.166.169.170.171.172.158.174.167.175.155.176.178.173.181.182.168.183.184.179.185.165.187.177.188.189.186.180.190.192.191.193.195.196.197.194.198.199.200.201. +********** Test Done ********** + +********** Process Tester ********** +5.6.7.8.9.10.2.3.11.4.23.22.24.19.21.12.13.14.25.26.29.28.15.16.17.30.18.20.34.35.38.39.32.40.31.27.41.33.43.44.48.49.50.42.36.51.37.45.52.54.56.58.59.60.61.46.47.53.62.57.67.68.69.70.71.55.63.64.65.73.76.78.79.72.81.66.74.82.75.83.86.88.90.91.77.84.92.85.93.80.95.97.99.101.87.102.94.89.103.96.98.100.108.112.104.113.105.114.106.107.109.115.110.122.123.124.116.111.117.118.119.125.120.132.134.121.126.127.135.130.128.136.129.139.133.131.145.138.137.142.140.143.146.141.155.147.148.144.149.152.150.151.153.156.157.158.154.162.159.160.161.163.166.164.167.165.168.172.170.169.180.173.176.171.174.181.175.177.178.179.188.189.182.185.183.190.186.184.187.191.193.194.192.195.196.197.198.199.200.201. +********** Test Done ********** + +********** OpenFile Tester ********** +3.4.5.2.8.6.9.7.11.10.13.12.14.16.15.17.18.19.21.20.22.23.24.26.25.27.28.29.31.30.32.33.34.36.35.37.39.38.40.41.42.43.45.44.47.46.49.48.50.52.51.53.55.54.56.58.57.59.60.62.61.63.65.66.64.67.69.68.70.71.72.74.73.76.77.75.78.80.79.81.82.83.85.84.86.87.88.90.89.91.92.94.95.93.97.96.98.99.100.102.101.103.105.104.106.108.107.109.111.110.113.112.115.114.116.117.118.119.120.121.122.123.124.125.126.127.128.129.130.131.132.133.134.135.136.138.137.139.140.141.142.143.144.145.146.147.148.149.150.152.151.153.154.155.156.157.158.159.160.161.162.163.164.166.165.167.168.169.170.172.171.173.174.176.175.177.178.180.179.181.183.182.185.184.186.187.188.189.190.191.192.194.193.195.197.196.198.199.200.201. +********** Test Done ********** + +********** FileControlBlock Tester ********** +2.3.4.5.6.7.8.9.10.2!W1.3!W2.5!W3.4!W4.6!W5.7!W6.8!W7.9!W8.10!F12.2!12.3!W1.12.5!W2.12.W3.12.12.12.12.12.10!4!W4.6!W5.7!9!W6.W7.8!W8.F12.12.12.20.12.12.12.20.12.12.12.20.20.20.20.20.20.20. +********** Test Done ********** + +All Assignment 3 tests done. + +I call this a "heisenbug" as I never know when it will strike and stop ToyOS from running. diff --git a/results/classifier/zero-shot/108/permissions/342 b/results/classifier/zero-shot/108/permissions/342 new file mode 100644 index 000000000..be0048fa9 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/342 @@ -0,0 +1,16 @@ +permissions: 0.971 +performance: 0.881 +device: 0.709 +debug: 0.648 +graphic: 0.596 +network: 0.581 +semantic: 0.483 +vnc: 0.244 +boot: 0.231 +KVM: 0.168 +socket: 0.163 +files: 0.104 +PID: 0.089 +other: 0.056 + +Assertion `child->perm & BLK_PERM_WRITE' failed in bdrv_co_write_req_prepare through atapi diff --git a/results/classifier/zero-shot/108/permissions/401 b/results/classifier/zero-shot/108/permissions/401 new file mode 100644 index 000000000..3a6bd8e5a --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/401 @@ -0,0 +1,16 @@ +permissions: 0.929 +network: 0.863 +semantic: 0.824 +device: 0.814 +performance: 0.620 +graphic: 0.447 +vnc: 0.256 +files: 0.188 +boot: 0.093 +KVM: 0.048 +socket: 0.046 +debug: 0.040 +PID: 0.035 +other: 0.021 + +Wishlist: nvme-ns: allow specifying eui-64 diff --git a/results/classifier/zero-shot/108/permissions/470 b/results/classifier/zero-shot/108/permissions/470 new file mode 100644 index 000000000..b6ae94095 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/470 @@ -0,0 +1,16 @@ +permissions: 0.950 +device: 0.771 +performance: 0.647 +semantic: 0.442 +network: 0.403 +graphic: 0.357 +boot: 0.335 +other: 0.264 +PID: 0.216 +debug: 0.196 +files: 0.165 +socket: 0.149 +vnc: 0.090 +KVM: 0.003 + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access diff --git a/results/classifier/zero-shot/108/permissions/48245039 b/results/classifier/zero-shot/108/permissions/48245039 new file mode 100644 index 000000000..18cdaa24d --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/48245039 @@ -0,0 +1,540 @@ +permissions: 0.966 +debug: 0.961 +PID: 0.954 +device: 0.953 +other: 0.953 +semantic: 0.939 +graphic: 0.935 +socket: 0.932 +boot: 0.932 +vnc: 0.926 +files: 0.924 +performance: 0.890 +KVM: 0.855 +network: 0.818 + +[Qemu-devel] [BUG] gcov support appears to be broken + +Hello, according to out docs, here is the procedure that should produce +coverage report for execution of the complete "make check": + +#./configure --enable-gcov +#make +#make check +#make coverage-report + +It seems that first three commands execute as expected. (For example, there are +plenty of files generated by "make check" that would've not been generated if +"enable-gcov" hadn't been chosen.) However, the last command complains about +some missing files related to FP support. If those files are added (for +example, artificially, using "touch <missing-file"), that it starts complaining +about missing some decodetree-generated files. Other kinds of files are +involved too. + +It would be nice to have coverage support working. Please somebody take a look, +or explain if I make a mistake or misunderstood our gcov support. + +Yours, +Aleksandar + +On Mon, 5 Aug 2019 at 11:39, Aleksandar Markovic <address@hidden> wrote: +> +> +Hello, according to out docs, here is the procedure that should produce +> +coverage report for execution of the complete "make check": +> +> +#./configure --enable-gcov +> +#make +> +#make check +> +#make coverage-report +> +> +It seems that first three commands execute as expected. (For example, there +> +are plenty of files generated by "make check" that would've not been +> +generated if "enable-gcov" hadn't been chosen.) However, the last command +> +complains about some missing files related to FP support. If those files are +> +added (for example, artificially, using "touch <missing-file"), that it +> +starts complaining about missing some decodetree-generated files. Other kinds +> +of files are involved too. +> +> +It would be nice to have coverage support working. Please somebody take a +> +look, or explain if I make a mistake or misunderstood our gcov support. +Cc'ing Alex who's probably the closest we have to a gcov expert. + +(make/make check of a --enable-gcov build is in the set of things our +Travis CI setup runs, so we do defend that part against regressions.) + +thanks +-- PMM + +Peter Maydell <address@hidden> writes: + +> +On Mon, 5 Aug 2019 at 11:39, Aleksandar Markovic <address@hidden> wrote: +> +> +> +> Hello, according to out docs, here is the procedure that should produce +> +> coverage report for execution of the complete "make check": +> +> +> +> #./configure --enable-gcov +> +> #make +> +> #make check +> +> #make coverage-report +> +> +> +> It seems that first three commands execute as expected. (For example, +> +> there are plenty of files generated by "make check" that would've not +> +> been generated if "enable-gcov" hadn't been chosen.) However, the +> +> last command complains about some missing files related to FP +> +> support. If those files are added (for example, artificially, using +> +> "touch <missing-file"), that it starts complaining about missing some +> +> decodetree-generated files. Other kinds of files are involved too. +The gcov tool is fairly noisy about missing files but that just +indicates the tests haven't exercised those code paths. "make check" +especially doesn't touch much of the TCG code and a chunk of floating +point. + +> +> +> +> It would be nice to have coverage support working. Please somebody +> +> take a look, or explain if I make a mistake or misunderstood our gcov +> +> support. +So your failure mode is no report is generated at all? It's working for +me here. + +> +> +Cc'ing Alex who's probably the closest we have to a gcov expert. +> +> +(make/make check of a --enable-gcov build is in the set of things our +> +Travis CI setup runs, so we do defend that part against regressions.) +We defend the build but I have just checked and it seems our +check_coverage script is currently failing: +https://travis-ci.org/stsquad/qemu/jobs/567809808#L10328 +But as it's an after_success script it doesn't fail the build. + +> +> +thanks +> +-- PMM +-- +Alex Bennée + +> +> #./configure --enable-gcov +> +> #make +> +> #make check +> +> #make coverage-report +> +> +> +> It seems that first three commands execute as expected. (For example, +> +> there are plenty of files generated by "make check" that would've not +> +> been generated if "enable-gcov" hadn't been chosen.) However, the +> +> last command complains about some missing files related to FP +> +So your failure mode is no report is generated at all? It's working for +> +me here. +Alex, no report is generated for my test setups - in fact, "make +coverage-report" even says that it explicitly deletes what appears to be the +main coverage report html file). + +This is the terminal output of an unsuccessful executions of "make +coverage-report" for recent ToT: + +~/Build/qemu-TOT-TEST$ make coverage-report +make[1]: Entering directory '/home/user/Build/qemu-TOT-TEST/slirp' +make[1]: Nothing to be done for 'all'. +make[1]: Leaving directory '/home/user/Build/qemu-TOT-TEST/slirp' + CHK version_gen.h + GEN coverage-report.html +Traceback (most recent call last): + File "/usr/bin/gcovr", line 1970, in <module> + print_html_report(covdata, options.html_details) + File "/usr/bin/gcovr", line 1473, in print_html_report + INPUT = open(data['FILENAME'], 'r') +IOError: [Errno 2] No such file or directory: 'wrap.inc.c' +Makefile:1048: recipe for target +'/home/user/Build/qemu-TOT-TEST/reports/coverage/coverage-report.html' failed +make: *** +[/home/user/Build/qemu-TOT-TEST/reports/coverage/coverage-report.html] Error 1 +make: *** Deleting file +'/home/user/Build/qemu-TOT-TEST/reports/coverage/coverage-report.html' + +This instance is executed in QEMU 3.0 source tree: (so, it looks the problem +existed for quite some time) + +~/Build/qemu-3.0$ make coverage-report + CHK version_gen.h + GEN coverage-report.html +Traceback (most recent call last): + File "/usr/bin/gcovr", line 1970, in <module> + print_html_report(covdata, options.html_details) + File "/usr/bin/gcovr", line 1473, in print_html_report + INPUT = open(data['FILENAME'], 'r') +IOError: [Errno 2] No such file or directory: +'/home/user/Build/qemu-3.0/target/openrisc/decode.inc.c' +Makefile:992: recipe for target +'/home/user/Build/qemu-3.0/reports/coverage/coverage-report.html' failed +make: *** [/home/user/Build/qemu-3.0/reports/coverage/coverage-report.html] +Error 1 +make: *** Deleting file +'/home/user/Build/qemu-3.0/reports/coverage/coverage-report.html' + +Fond regards, +Aleksandar + + +> +Alex Bennée + +> +> #./configure --enable-gcov +> +> #make +> +> #make check +> +> #make coverage-report +> +> +> +> It seems that first three commands execute as expected. (For example, +> +> there are plenty of files generated by "make check" that would've not +> +> been generated if "enable-gcov" hadn't been chosen.) However, the +> +> last command complains about some missing files related to FP +> +So your failure mode is no report is generated at all? It's working for +> +me here. +Another piece of info: + +~/Build/qemu-TOT-TEST$ gcov --version +gcov (Ubuntu 5.5.0-12ubuntu1~16.04) 5.5.0 20171010 +Copyright (C) 2015 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. +There is NO warranty; not even for MERCHANTABILITY or +FITNESS FOR A PARTICULAR PURPOSE. + +:~/Build/qemu-TOT-TEST$ gcc --version +gcc (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0 +Copyright (C) 2017 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + + + +Alex, no report is generated for my test setups - in fact, "make +coverage-report" even says that it explicitly deletes what appears to be the +main coverage report html file). + +This is the terminal output of an unsuccessful executions of "make +coverage-report" for recent ToT: + +~/Build/qemu-TOT-TEST$ make coverage-report +make[1]: Entering directory '/home/user/Build/qemu-TOT-TEST/slirp' +make[1]: Nothing to be done for 'all'. +make[1]: Leaving directory '/home/user/Build/qemu-TOT-TEST/slirp' + CHK version_gen.h + GEN coverage-report.html +Traceback (most recent call last): + File "/usr/bin/gcovr", line 1970, in <module> + print_html_report(covdata, options.html_details) + File "/usr/bin/gcovr", line 1473, in print_html_report + INPUT = open(data['FILENAME'], 'r') +IOError: [Errno 2] No such file or directory: 'wrap.inc.c' +Makefile:1048: recipe for target +'/home/user/Build/qemu-TOT-TEST/reports/coverage/coverage-report.html' failed +make: *** +[/home/user/Build/qemu-TOT-TEST/reports/coverage/coverage-report.html] Error 1 +make: *** Deleting file +'/home/user/Build/qemu-TOT-TEST/reports/coverage/coverage-report.html' + +This instance is executed in QEMU 3.0 source tree: (so, it looks the problem +existed for quite some time) + +~/Build/qemu-3.0$ make coverage-report + CHK version_gen.h + GEN coverage-report.html +Traceback (most recent call last): + File "/usr/bin/gcovr", line 1970, in <module> + print_html_report(covdata, options.html_details) + File "/usr/bin/gcovr", line 1473, in print_html_report + INPUT = open(data['FILENAME'], 'r') +IOError: [Errno 2] No such file or directory: +'/home/user/Build/qemu-3.0/target/openrisc/decode.inc.c' +Makefile:992: recipe for target +'/home/user/Build/qemu-3.0/reports/coverage/coverage-report.html' failed +make: *** [/home/user/Build/qemu-3.0/reports/coverage/coverage-report.html] +Error 1 +make: *** Deleting file +'/home/user/Build/qemu-3.0/reports/coverage/coverage-report.html' + +Fond regards, +Aleksandar + + +> +Alex Bennée + +> +> #./configure --enable-gcov +> +> #make +> +> #make check +> +> #make coverage-report +> +> +> +> It seems that first three commands execute as expected. (For example, +> +> there are plenty of files generated by "make check" that would've not +> +> been generated if "enable-gcov" hadn't been chosen.) However, the +> +> last command complains about some missing files related to FP +> +So your failure mode is no report is generated at all? It's working for +> +me here. +Alex, here is the thing: + +Seeing that my gcovr is relatively old (2014) 3.2 version, I upgraded it from +git repo to the most recent 4.1 (actually, to a dev version, from the very tip +of the tree), and "make coverage-report" started generating coverage reports. +It did emit some error messages (totally different than previous), but still it +did not stop like it used to do with gcovr 3.2. + +Perhaps you would want to add some gcov/gcovr minimal version info in our docs. +(or at least a statement "this was tested with such and such gcc, gcov and +gcovr", etc.?) + +Coverage report looked fine at first glance, but it a kind of disappointed me +when I digged deeper into its content - for example, it shows very low coverage +for our FP code (softfloat), while, in fact, we know that "make check" contains +detailed tests on FP functionalities. But this is most likely a separate +problem of a very different nature, perhaps the issue of separate git repo for +FP tests (testfloat) that our FP tests use as a mid-layer. + +I'll try how everything works with my test examples, and will let you know. + +Your help is greatly appreciated, +Aleksandar + +Fond regards, +Aleksandar + + +> +Alex Bennée + +Aleksandar Markovic <address@hidden> writes: + +> +>> #./configure --enable-gcov +> +>> #make +> +>> #make check +> +>> #make coverage-report +> +>> +> +>> It seems that first three commands execute as expected. (For example, +> +>> there are plenty of files generated by "make check" that would've not +> +>> been generated if "enable-gcov" hadn't been chosen.) However, the +> +>> last command complains about some missing files related to FP +> +> +> So your failure mode is no report is generated at all? It's working for +> +> me here. +> +> +Alex, here is the thing: +> +> +Seeing that my gcovr is relatively old (2014) 3.2 version, I upgraded it from +> +git repo to the most recent 4.1 (actually, to a dev version, from the very +> +tip of the tree), and "make coverage-report" started generating coverage +> +reports. It did emit some error messages (totally different than previous), +> +but still it did not stop like it used to do with gcovr 3.2. +> +> +Perhaps you would want to add some gcov/gcovr minimal version info in our +> +docs. (or at least a statement "this was tested with such and such gcc, gcov +> +and gcovr", etc.?) +> +> +Coverage report looked fine at first glance, but it a kind of +> +disappointed me when I digged deeper into its content - for example, +> +it shows very low coverage for our FP code (softfloat), while, in +> +fact, we know that "make check" contains detailed tests on FP +> +functionalities. But this is most likely a separate problem of a very +> +different nature, perhaps the issue of separate git repo for FP tests +> +(testfloat) that our FP tests use as a mid-layer. +I get: + +68.6 % 2593 / 3782 62.2 % 1690 / 2718 + +Which is not bad considering we don't exercise the 80 and 128 bit +softfloat code at all (which is not shared by the re-factored 16/32/64 +bit code). + +> +> +I'll try how everything works with my test examples, and will let you know. +> +> +Your help is greatly appreciated, +> +Aleksandar +> +> +Fond regards, +> +Aleksandar +> +> +> +> Alex Bennée +-- +Alex Bennée + +> +> it shows very low coverage for our FP code (softfloat), while, in +> +> fact, we know that "make check" contains detailed tests on FP +> +> functionalities. But this is most likely a separate problem of a very +> +> different nature, perhaps the issue of separate git repo for FP tests +> +> (testfloat) that our FP tests use as a mid-layer. +> +> +I get: +> +> +68.6 % 2593 / 3782 62.2 % 1690 / 2718 +> +I would expect that kind of result too. + +However, I get: + +File: fpu/softfloat.c Lines: 8 3334 0.2 % +Date: 2019-08-05 19:56:58 Branches: 3 2376 0.1 % + +:( + +OK, I'll try to figure that out, and most likely I could live with it if it is +an isolated problem. + +Thank you for your assistance in this matter, +Aleksandar + +> +Which is not bad considering we don't exercise the 80 and 128 bit +> +softfloat code at all (which is not shared by the re-factored 16/32/64 +> +bit code). +> +> +Alex Bennée + +> +> it shows very low coverage for our FP code (softfloat), while, in +> +> fact, we know that "make check" contains detailed tests on FP +> +> functionalities. But this is most likely a separate problem of a very +> +> different nature, perhaps the issue of separate git repo for FP tests +> +> (testfloat) that our FP tests use as a mid-layer. +> +> +I get: +> +> +68.6 % 2593 / 3782 62.2 % 1690 / 2718 +> +This problem is solved too. (and it is my fault) + +I worked with multiple versions of QEMU, and my previous low-coverage results +were for QEMU 3.0, and for that version the directory tests/fp did not even +exist. :D (<blush>) + +For QEMU ToT, I get now: + +fpu/softfloat.c + 68.8 % 2592 / 3770 62.3 % 1693 / 2718 + +which is identical for all intents and purposes to your result. + +Yours cordially, +Aleksandar + diff --git a/results/classifier/zero-shot/108/permissions/497273 b/results/classifier/zero-shot/108/permissions/497273 new file mode 100644 index 000000000..35987f4e1 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/497273 @@ -0,0 +1,90 @@ +permissions: 0.963 +other: 0.958 +files: 0.945 +device: 0.940 +graphic: 0.935 +performance: 0.930 +PID: 0.927 +semantic: 0.926 +debug: 0.919 +network: 0.909 +socket: 0.908 +boot: 0.906 +vnc: 0.898 +KVM: 0.881 + +winxp.64 fails to install in -rc2 with kvm + +Host: Fedora11, 64-bit +Kernel: 2.6.30.9-96.fc11.x86_64 +KVM modules: + +# modinfo kvm +filename: /lib/modules/2.6.30.9-96.fc11.x86_64/kernel/arch/x86/kvm/kvm.ko +license: GPL +author: Qumranet +srcversion: 23A53503602E48217AC12F1 +depends: +vermagic: 2.6.30.9-96.fc11.x86_64 SMP mod_unload +parm: oos_shadow:bool +parm: msi2intx:bool + +]# modinfo kvm-intel +filename: /lib/modules/2.6.30.9-96.fc11.x86_64/kernel/arch/x86/kvm/kvm-intel.ko +license: GPL +author: Qumranet +srcversion: 5DD68E0B8497DC4518A8797 +depends: kvm +vermagic: 2.6.30.9-96.fc11.x86_64 SMP mod_unload +parm: bypass_guest_pf:bool +parm: enable_vpid:bool +parm: flexpriority_enabled:bool +parm: enable_ept:bool +parm: emulate_invalid_guest_state:bool + +Host CPU: Intel(R) Xeon(R) CPU X5550 @ 2.67GHz + +Guest commandline: +sudo ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios -name 'vm1' -monitor stdio -drive file=~/work/images/winXP-64.qcow2,if=ide,cache=writeback -net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:56 -net user,vlan=0 -m 512 -cdrom ~/work/isos/en_windows_xp_professional_x64.iso -enable-kvm -redir tcp:5000::22 + +Steps to reproduce: + +1. git checkout -b 12rc2 v0.12.0-rc2 +2. ./configure --target-list=x86_64-softmmu +3. make +4. qemu-img create -f qcow2 ~/work/images/winXP-64.qcow2 20G +5. sudo ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios -name 'vm1' -monitor stdio -drive file=~/work/images/winXP-64.qcow2,if=ide,cache=writeback -net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:56 -net user,vlan=0 -m 512 -cdrom ~/work/isos/en_windows_xp_professional_x64.iso -enable-kvm -redir tcp:5000::22 + +Guest boots XP.64 installer, loads some files and then hangs at "Starting Windows XP" + +Reverting to -rc1 and XP installs just fine. Git bisect points to: + +commit 066263f37701687c64af9d8825e3376d069ebfd4 +Author: Andre Przywara <email address hidden> +Date: Mon Dec 7 11:58:02 2009 +0100 + +cpuid: Fix multicore setup on Intel + + +Reverting this fixes the problem. + +Different kvm modules seem to affect this install as well. Switching +to different kvm-kmod packages: + +2.6.32 modules work fine with 0.12.0-rc2, no issues at all + +2.6.30 modules fail, reverting the above commit doesn't help, seems to +be in the same boat as 2.6.28 modules + +2.6.31.5 (roughly equivalent to Fedora11 modules) work on -rc1, fail on +rc2, reverting above commit fixes -rc2. + +Ryan, +can you still reproduce this with the stable versions (0.12.4)? + + +Yeah, I can still reproduce with 0.12.4 on a fedora11 host. Also broken with qemu.git HEAD as of today as well. On the f11 host kvm modules, reverting the referenced commit doesn't help. + + +Fedora 11, QEMU 0.12 and Windows XP are pretty much outdated nowadays, so I guess nobody will take care of this ticket anymore - sorry! So I'm closing this as "Won't fix" now. (Anyway, if you still can reproduce this problem with the latest version of QEMU, feel free to open the bug again) + diff --git a/results/classifier/zero-shot/108/permissions/498035 b/results/classifier/zero-shot/108/permissions/498035 new file mode 100644 index 000000000..c605a19e6 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/498035 @@ -0,0 +1,101 @@ +permissions: 0.943 +other: 0.924 +network: 0.910 +debug: 0.910 +semantic: 0.904 +graphic: 0.896 +device: 0.893 +performance: 0.892 +socket: 0.890 +vnc: 0.881 +boot: 0.866 +PID: 0.849 +files: 0.792 +KVM: 0.739 + +qemu hangs on shutdown or reboot (XP guest) + +When I shut down or reboot my Windows XP guest, about half the time, it hangs at the point where it says "Windows is shutting down...". At that point qemu is using 100% of one host CPU, about 85% user, 15% system. (Core 2 Quad 2.66GHz) + +This is the command line I use to start qemu: + +qemu-system-x86_64 -hda winxp.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -boot c -enable-kvm & + +What version of qemu is this? Please try with 0.12.0-rc2 + +I'm using version 0.11.1. Since Gentoo doesn't have an ebuild for 0.12.0, I'm filing a bug report with them so that they'll get up to date on this. (Also, I honestly don't know how to build an out-of-portage package for Gentoo without clobbering something or causing conflicts.) + +Thanks. + +This bug is apparently not fixed. I'm using the Gentoo package "app-emulation/qemu-kvm-0.12.1.1", and it too sometimes hangs up on reboot or shutdown. + +I asked on IRC, but I'm not getting much help there trying to diagnose this. Here's what I know: + +- When Windows doesn't use ACPI to power off, you get a screen that tells you that you can power down now. I'm not getting that screen. It's still saying "Windows is shutting down..." +- The QEMU monitor responds, so it's not completely frozen up. Something's going wrong inside the VM. +- It doesn't usually hang up. This seems to happen mostly when I reboot after I install software or do something that requires heavy disk or network activity. I understand that this bug has in the past been associated with the audio driver, but I can't tell if any audio happened, because I'm using VNC. +- I haven't done anything to prevent Windows from using ACPI. + +The Gentoo devs have created an overlay I can use to install the git version of QEMU. + +BTW, I've found a way to get the hang condition to occur very reliably. In the Windows XP guest, install the .Net framework and all the updates. Reboot. When the desktop comes up but before everything is 100% loaded, reboot. It's very likely to hang up at the end. Also, I don't observe it hanging on shutdown anymore. Just reboot. + +Ok, will see if we can reproduce this. + +Also happens in Ubunto 10.04LTS Linux bnesbitt-desktop 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux + + +I've seen windows XP hanging on reboot/shutdown like this so many countless times I'd not bother with this at all. At least, does clean install of winXP shows the same behavour? + +Did a clean XP install and could not reproduce with current git qemu-kvm. + +Confirming under Fedora 15, qemu 14.0 + +Very frustrating for clients using Microsoft RDP who just get a blank blue screen when it is stuck like this. + +Confirming what? 0.14 version of qemu (there was no 14.0 version) is very old. Very frustrating that people just "confirm" bugs using old versions without trying current version which has a lot of changes within. I can confirm that this prob - winXP (or win7 for that matter) getting stuck on reboot/shutdown - which I faced too on a "semi-regular" basis has now gone, either because of some change in qemu, in configuration, or due to some patch on the windows side - I don't know, and will unlikely to know. I'm using 1.0.1 version currently. + +"Forgive me, El Guapo. I know that I, Jefe, do not have your superior intellect and education. But could it be that once again, you are angry at something else, and are looking to take it out on me?" + +Eh, Tokarev, calm down. So I misplaced a period and a zero. So I haven't been compiling my own binaries to stay on top of the latest repo build. I also didn't see this bug report listed as "fixed" yet, which is reasonable to believe if it had been addressed in the current version. + +I upgrade to F17 next Saturday and will have access to the 1.0.x RPMs w/o causing a compatibility nightmare under F15. I'll let you know if that fixes it. + +So, is this issue still relevant with current qemu (which happens to be 2.1.0? I remember seeing hangs on reboot/halt like this before too, but on my side they're long gone, I don't observe these hangs anymore. Maybe this bugreport can be closed finally? + +Hi, + +I have the same problem, or at least seems related. I just opened an issue on https://sourceforge.net/p/kvm/bugs/555, if needed I can post here all the details too. + + + +My Two Cents. + +I am using Xubuntu 14.04 recent install -- all updates. + +I created a WIN7 x64 VM (fresh clean install) with most Windows updates -- nothing else. + +Note: I use a script (command line startup) of "qemu-system-x86_64" + +Inside Windows 7, I shutdown a few services that I thought I did not need (incl. POWER Service) + +I had an occasional BSOD when shutting down. very quick, minor annoyance. Was able to slect start normally in Windows next boot -- only happened once every 10 or so times. + +BUT I was able to shutdown quickly every time. + +I discovered that I had to enable the POWER service to activate the virtual soundcard HW hda (to play audio). + +since I have enabled the POWER service, I cannot shutdown normally. The "Shutting Down..." appears forever (or until occasional BSOD). + +This does not cause any undue processor load and I am able to do a normal "quit" of the VM using telnet into the monitor. (issuing "quit" from the monitor is like yanking out the power-cord of the VM) I see no problems from doing this. Windows thinks it is shut-down clean enough. + +It is possible that when I issue the "quit" in the monitor after about 10 seconds of shutdown, I may not get any more BSOD at all. + +I have tried playing with the Windows Power configuration settings and have found nothing to solve the issue. + +Other than this minor annoyance, everything is working great! (because it is running so well, I probably won't be running a trace or debugging the dump file in Windows. If anybody wants, I can share my startup script that launches the VM. I am not going to use any virt manager from the GUI. + +Fresh install of XP and this doesn't happen.... + +Closing since it seems to be fixed in latest release. + diff --git a/results/classifier/zero-shot/108/permissions/551545 b/results/classifier/zero-shot/108/permissions/551545 new file mode 100644 index 000000000..63d293b8e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/551545 @@ -0,0 +1,502 @@ +permissions: 0.955 +network: 0.920 +device: 0.912 +debug: 0.908 +performance: 0.887 +graphic: 0.881 +PID: 0.876 +files: 0.874 +boot: 0.853 +socket: 0.845 +KVM: 0.835 +vnc: 0.821 +other: 0.803 +semantic: 0.701 + +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/zero-shot/108/permissions/55247116 b/results/classifier/zero-shot/108/permissions/55247116 new file mode 100644 index 000000000..cbe7dfafd --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/55247116 @@ -0,0 +1,1320 @@ +permissions: 0.946 +other: 0.945 +debug: 0.941 +performance: 0.938 +graphic: 0.933 +PID: 0.929 +socket: 0.929 +semantic: 0.928 +device: 0.919 +boot: 0.918 +network: 0.916 +vnc: 0.916 +files: 0.912 +KVM: 0.894 + +[Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache? + +Hi, + +In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +instead of first level entry (if map to rom other than guest memory +comes first), while in xen_invalidate_map_cache(), when VM ballooned +out memory, qemu did not invalidate cache entries in linked +list(entry->next), so when VM balloon back in memory, gfns probably +mapped to different mfns, thus if guest asks device to DMA to these +GPA, qemu may DMA to stale MFNs. + +So I think in xen_invalidate_map_cache() linked lists should also be +checked and invalidated. + +Whatâs your opinion? Is this a bug? Is my analyze correct? + +On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +Hi, +> +> +In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +> +instead of first level entry (if map to rom other than guest memory +> +comes first), while in xen_invalidate_map_cache(), when VM ballooned +> +out memory, qemu did not invalidate cache entries in linked +> +list(entry->next), so when VM balloon back in memory, gfns probably +> +mapped to different mfns, thus if guest asks device to DMA to these +> +GPA, qemu may DMA to stale MFNs. +> +> +So I think in xen_invalidate_map_cache() linked lists should also be +> +checked and invalidated. +> +> +Whatâs your opinion? Is this a bug? Is my analyze correct? +Added Jun Nakajima and Alexander Graf + +On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +> Hi, +> +> +> +> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +> +> instead of first level entry (if map to rom other than guest memory +> +> comes first), while in xen_invalidate_map_cache(), when VM ballooned +> +> out memory, qemu did not invalidate cache entries in linked +> +> list(entry->next), so when VM balloon back in memory, gfns probably +> +> mapped to different mfns, thus if guest asks device to DMA to these +> +> GPA, qemu may DMA to stale MFNs. +> +> +> +> So I think in xen_invalidate_map_cache() linked lists should also be +> +> checked and invalidated. +> +> +> +> Whatâs your opinion? Is this a bug? Is my analyze correct? +> +> +Added Jun Nakajima and Alexander Graf +And correct Stefano Stabellini's email address. + +On Mon, 10 Apr 2017 00:36:02 +0800 +hrg <address@hidden> wrote: + +Hi, + +> +On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +> On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +>> Hi, +> +>> +> +>> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +> +>> instead of first level entry (if map to rom other than guest memory +> +>> comes first), while in xen_invalidate_map_cache(), when VM ballooned +> +>> out memory, qemu did not invalidate cache entries in linked +> +>> list(entry->next), so when VM balloon back in memory, gfns probably +> +>> mapped to different mfns, thus if guest asks device to DMA to these +> +>> GPA, qemu may DMA to stale MFNs. +> +>> +> +>> So I think in xen_invalidate_map_cache() linked lists should also be +> +>> checked and invalidated. +> +>> +> +>> Whatâs your opinion? Is this a bug? Is my analyze correct? +> +> +> +> Added Jun Nakajima and Alexander Graf +> +And correct Stefano Stabellini's email address. +There is a real issue with the xen-mapcache corruption in fact. I encountered +it a few months ago while experimenting with Q35 support on Xen. Q35 emulation +uses an AHCI controller by default, along with NCQ mode enabled. The issue can +be (somewhat) easily reproduced there, though using a normal i440 emulation +might possibly allow to reproduce the issue as well, using a dedicated test +code from a guest side. In case of Q35+NCQ the issue can be reproduced "as is". + +The issue occurs when a guest domain performs an intensive disk I/O, ex. while +guest OS booting. QEMU crashes with "Bad ram offset 980aa000" +message logged, where the address is different each time. The hard thing with +this issue is that it has a very low reproducibility rate. + +The corruption happens when there are multiple I/O commands in the NCQ queue. +So there are overlapping emulated DMA operations in flight and QEMU uses a +sequence of mapcache actions which can be executed in the "wrong" order thus +leading to an inconsistent xen-mapcache - so a bad address from the wrong +entry is returned. + +The bad thing with this issue is that QEMU crash due to "Bad ram offset" +appearance is a relatively good situation in the sense that this is a caught +error. But there might be a much worse (artificial) situation where the returned +address looks valid but points to a different mapped memory. + +The fix itself is not hard (ex. an additional checked field in MapCacheEntry), +but there is a need of some reliable way to test it considering the low +reproducibility rate. + +Regards, +Alex + +On Mon, 10 Apr 2017, hrg wrote: +> +On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +> On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +>> Hi, +> +>> +> +>> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +> +>> instead of first level entry (if map to rom other than guest memory +> +>> comes first), while in xen_invalidate_map_cache(), when VM ballooned +> +>> out memory, qemu did not invalidate cache entries in linked +> +>> list(entry->next), so when VM balloon back in memory, gfns probably +> +>> mapped to different mfns, thus if guest asks device to DMA to these +> +>> GPA, qemu may DMA to stale MFNs. +> +>> +> +>> So I think in xen_invalidate_map_cache() linked lists should also be +> +>> checked and invalidated. +> +>> +> +>> Whatâs your opinion? Is this a bug? Is my analyze correct? +Yes, you are right. We need to go through the list for each element of +the array in xen_invalidate_map_cache. Can you come up with a patch? + +On Mon, 10 Apr 2017, Stefano Stabellini wrote: +> +On Mon, 10 Apr 2017, hrg wrote: +> +> On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +> > On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +> >> Hi, +> +> >> +> +> >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +> +> >> instead of first level entry (if map to rom other than guest memory +> +> >> comes first), while in xen_invalidate_map_cache(), when VM ballooned +> +> >> out memory, qemu did not invalidate cache entries in linked +> +> >> list(entry->next), so when VM balloon back in memory, gfns probably +> +> >> mapped to different mfns, thus if guest asks device to DMA to these +> +> >> GPA, qemu may DMA to stale MFNs. +> +> >> +> +> >> So I think in xen_invalidate_map_cache() linked lists should also be +> +> >> checked and invalidated. +> +> >> +> +> >> Whatâs your opinion? Is this a bug? Is my analyze correct? +> +> +Yes, you are right. We need to go through the list for each element of +> +the array in xen_invalidate_map_cache. Can you come up with a patch? +I spoke too soon. In the regular case there should be no locked mappings +when xen_invalidate_map_cache is called (see the DPRINTF warning at the +beginning of the functions). Without locked mappings, there should never +be more than one element in each list (see xen_map_cache_unlocked: +entry->lock == true is a necessary condition to append a new entry to +the list, otherwise it is just remapped). + +Can you confirm that what you are seeing are locked mappings +when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +by turning it into a printf or by defininig MAPCACHE_DEBUG. + +On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +<address@hidden> wrote: +> +On Mon, 10 Apr 2017, Stefano Stabellini wrote: +> +> On Mon, 10 Apr 2017, hrg wrote: +> +> > On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +> > > On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +> > >> Hi, +> +> > >> +> +> > >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +> +> > >> instead of first level entry (if map to rom other than guest memory +> +> > >> comes first), while in xen_invalidate_map_cache(), when VM ballooned +> +> > >> out memory, qemu did not invalidate cache entries in linked +> +> > >> list(entry->next), so when VM balloon back in memory, gfns probably +> +> > >> mapped to different mfns, thus if guest asks device to DMA to these +> +> > >> GPA, qemu may DMA to stale MFNs. +> +> > >> +> +> > >> So I think in xen_invalidate_map_cache() linked lists should also be +> +> > >> checked and invalidated. +> +> > >> +> +> > >> Whatâs your opinion? Is this a bug? Is my analyze correct? +> +> +> +> Yes, you are right. We need to go through the list for each element of +> +> the array in xen_invalidate_map_cache. Can you come up with a patch? +> +> +I spoke too soon. In the regular case there should be no locked mappings +> +when xen_invalidate_map_cache is called (see the DPRINTF warning at the +> +beginning of the functions). Without locked mappings, there should never +> +be more than one element in each list (see xen_map_cache_unlocked: +> +entry->lock == true is a necessary condition to append a new entry to +> +the list, otherwise it is just remapped). +> +> +Can you confirm that what you are seeing are locked mappings +> +when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +> +by turning it into a printf or by defininig MAPCACHE_DEBUG. +In fact, I think the DPRINTF above is incorrect too. In +pci_add_option_rom(), rtl8139 rom is locked mapped in +pci_add_option_rom->memory_region_get_ram_ptr (after +memory_region_init_ram). So actually I think we should remove the +DPRINTF warning as it is normal. + +On Tue, 11 Apr 2017, hrg wrote: +> +On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +> +<address@hidden> wrote: +> +> On Mon, 10 Apr 2017, Stefano Stabellini wrote: +> +>> On Mon, 10 Apr 2017, hrg wrote: +> +>> > On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +>> > > On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +>> > >> Hi, +> +>> > >> +> +>> > >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +> +>> > >> instead of first level entry (if map to rom other than guest memory +> +>> > >> comes first), while in xen_invalidate_map_cache(), when VM ballooned +> +>> > >> out memory, qemu did not invalidate cache entries in linked +> +>> > >> list(entry->next), so when VM balloon back in memory, gfns probably +> +>> > >> mapped to different mfns, thus if guest asks device to DMA to these +> +>> > >> GPA, qemu may DMA to stale MFNs. +> +>> > >> +> +>> > >> So I think in xen_invalidate_map_cache() linked lists should also be +> +>> > >> checked and invalidated. +> +>> > >> +> +>> > >> Whatâs your opinion? Is this a bug? Is my analyze correct? +> +>> +> +>> Yes, you are right. We need to go through the list for each element of +> +>> the array in xen_invalidate_map_cache. Can you come up with a patch? +> +> +> +> I spoke too soon. In the regular case there should be no locked mappings +> +> when xen_invalidate_map_cache is called (see the DPRINTF warning at the +> +> beginning of the functions). Without locked mappings, there should never +> +> be more than one element in each list (see xen_map_cache_unlocked: +> +> entry->lock == true is a necessary condition to append a new entry to +> +> the list, otherwise it is just remapped). +> +> +> +> Can you confirm that what you are seeing are locked mappings +> +> when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +> +> by turning it into a printf or by defininig MAPCACHE_DEBUG. +> +> +In fact, I think the DPRINTF above is incorrect too. In +> +pci_add_option_rom(), rtl8139 rom is locked mapped in +> +pci_add_option_rom->memory_region_get_ram_ptr (after +> +memory_region_init_ram). So actually I think we should remove the +> +DPRINTF warning as it is normal. +Let me explain why the DPRINTF warning is there: emulated dma operations +can involve locked mappings. Once a dma operation completes, the related +mapping is unlocked and can be safely destroyed. But if we destroy a +locked mapping in xen_invalidate_map_cache, while a dma is still +ongoing, QEMU will crash. We cannot handle that case. + +However, the scenario you described is different. It has nothing to do +with DMA. It looks like pci_add_option_rom calls +memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a +locked mapping and it is never unlocked or destroyed. + +It looks like "ptr" is not used after pci_add_option_rom returns. Does +the append patch fix the problem you are seeing? For the proper fix, I +think we probably need some sort of memory_region_unmap wrapper or maybe +a call to address_space_unmap. + + +diff --git a/hw/pci/pci.c b/hw/pci/pci.c +index e6b08e1..04f98b7 100644 +--- a/hw/pci/pci.c ++++ b/hw/pci/pci.c +@@ -2242,6 +2242,7 @@ static void pci_add_option_rom(PCIDevice *pdev, bool +is_default_rom, + } + + pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom); ++ xen_invalidate_map_cache_entry(ptr); + } + + static void pci_del_option_rom(PCIDevice *pdev) + +On Tue, 11 Apr 2017 15:32:09 -0700 (PDT) +Stefano Stabellini <address@hidden> wrote: + +> +On Tue, 11 Apr 2017, hrg wrote: +> +> On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +> +> <address@hidden> wrote: +> +> > On Mon, 10 Apr 2017, Stefano Stabellini wrote: +> +> >> On Mon, 10 Apr 2017, hrg wrote: +> +> >> > On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +> >> > > On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +> >> > >> Hi, +> +> >> > >> +> +> >> > >> In xen_map_cache_unlocked(), map to guest memory maybe in +> +> >> > >> entry->next instead of first level entry (if map to rom other than +> +> >> > >> guest memory comes first), while in xen_invalidate_map_cache(), +> +> >> > >> when VM ballooned out memory, qemu did not invalidate cache entries +> +> >> > >> in linked list(entry->next), so when VM balloon back in memory, +> +> >> > >> gfns probably mapped to different mfns, thus if guest asks device +> +> >> > >> to DMA to these GPA, qemu may DMA to stale MFNs. +> +> >> > >> +> +> >> > >> So I think in xen_invalidate_map_cache() linked lists should also be +> +> >> > >> checked and invalidated. +> +> >> > >> +> +> >> > >> Whatâs your opinion? Is this a bug? Is my analyze correct? +> +> >> +> +> >> Yes, you are right. We need to go through the list for each element of +> +> >> the array in xen_invalidate_map_cache. Can you come up with a patch? +> +> > +> +> > I spoke too soon. In the regular case there should be no locked mappings +> +> > when xen_invalidate_map_cache is called (see the DPRINTF warning at the +> +> > beginning of the functions). Without locked mappings, there should never +> +> > be more than one element in each list (see xen_map_cache_unlocked: +> +> > entry->lock == true is a necessary condition to append a new entry to +> +> > the list, otherwise it is just remapped). +> +> > +> +> > Can you confirm that what you are seeing are locked mappings +> +> > when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +> +> > by turning it into a printf or by defininig MAPCACHE_DEBUG. +> +> +> +> In fact, I think the DPRINTF above is incorrect too. In +> +> pci_add_option_rom(), rtl8139 rom is locked mapped in +> +> pci_add_option_rom->memory_region_get_ram_ptr (after +> +> memory_region_init_ram). So actually I think we should remove the +> +> DPRINTF warning as it is normal. +> +> +Let me explain why the DPRINTF warning is there: emulated dma operations +> +can involve locked mappings. Once a dma operation completes, the related +> +mapping is unlocked and can be safely destroyed. But if we destroy a +> +locked mapping in xen_invalidate_map_cache, while a dma is still +> +ongoing, QEMU will crash. We cannot handle that case. +> +> +However, the scenario you described is different. It has nothing to do +> +with DMA. It looks like pci_add_option_rom calls +> +memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a +> +locked mapping and it is never unlocked or destroyed. +> +> +It looks like "ptr" is not used after pci_add_option_rom returns. Does +> +the append patch fix the problem you are seeing? For the proper fix, I +> +think we probably need some sort of memory_region_unmap wrapper or maybe +> +a call to address_space_unmap. +Hmm, for some reason my message to the Xen-devel list got rejected but was sent +to Qemu-devel instead, without any notice. Sorry if I'm missing something +obvious as a list newbie. + +Stefano, hrg, + +There is an issue with inconsistency between the list of normal MapCacheEntry's +and their 'reverse' counterparts - MapCacheRev's in locked_entries. +When bad situation happens, there are multiple (locked) MapCacheEntry +entries in the bucket's linked list along with a number of MapCacheRev's. And +when it comes to a reverse lookup, xen-mapcache picks the wrong entry from the +first list and calculates a wrong pointer from it which may then be caught with +the "Bad RAM offset" check (or not). Mapcache invalidation might be related to +this issue as well I think. + +I'll try to provide a test code which can reproduce the issue from the +guest side using an emulated IDE controller, though it's much simpler to achieve +this result with an AHCI controller using multiple NCQ I/O commands. So far I've +seen this issue only with Windows 7 (and above) guest on AHCI, but any block I/O +DMA should be enough I think. + +On 2017/4/12 14:17, Alexey G wrote: +On Tue, 11 Apr 2017 15:32:09 -0700 (PDT) +Stefano Stabellini <address@hidden> wrote: +On Tue, 11 Apr 2017, hrg wrote: +On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +<address@hidden> wrote: +On Mon, 10 Apr 2017, Stefano Stabellini wrote: +On Mon, 10 Apr 2017, hrg wrote: +On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +Hi, + +In xen_map_cache_unlocked(), map to guest memory maybe in +entry->next instead of first level entry (if map to rom other than +guest memory comes first), while in xen_invalidate_map_cache(), +when VM ballooned out memory, qemu did not invalidate cache entries +in linked list(entry->next), so when VM balloon back in memory, +gfns probably mapped to different mfns, thus if guest asks device +to DMA to these GPA, qemu may DMA to stale MFNs. + +So I think in xen_invalidate_map_cache() linked lists should also be +checked and invalidated. + +Whatâs your opinion? Is this a bug? Is my analyze correct? +Yes, you are right. We need to go through the list for each element of +the array in xen_invalidate_map_cache. Can you come up with a patch? +I spoke too soon. In the regular case there should be no locked mappings +when xen_invalidate_map_cache is called (see the DPRINTF warning at the +beginning of the functions). Without locked mappings, there should never +be more than one element in each list (see xen_map_cache_unlocked: +entry->lock == true is a necessary condition to append a new entry to +the list, otherwise it is just remapped). + +Can you confirm that what you are seeing are locked mappings +when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +by turning it into a printf or by defininig MAPCACHE_DEBUG. +In fact, I think the DPRINTF above is incorrect too. In +pci_add_option_rom(), rtl8139 rom is locked mapped in +pci_add_option_rom->memory_region_get_ram_ptr (after +memory_region_init_ram). So actually I think we should remove the +DPRINTF warning as it is normal. +Let me explain why the DPRINTF warning is there: emulated dma operations +can involve locked mappings. Once a dma operation completes, the related +mapping is unlocked and can be safely destroyed. But if we destroy a +locked mapping in xen_invalidate_map_cache, while a dma is still +ongoing, QEMU will crash. We cannot handle that case. + +However, the scenario you described is different. It has nothing to do +with DMA. It looks like pci_add_option_rom calls +memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a +locked mapping and it is never unlocked or destroyed. + +It looks like "ptr" is not used after pci_add_option_rom returns. Does +the append patch fix the problem you are seeing? For the proper fix, I +think we probably need some sort of memory_region_unmap wrapper or maybe +a call to address_space_unmap. +Hmm, for some reason my message to the Xen-devel list got rejected but was sent +to Qemu-devel instead, without any notice. Sorry if I'm missing something +obvious as a list newbie. + +Stefano, hrg, + +There is an issue with inconsistency between the list of normal MapCacheEntry's +and their 'reverse' counterparts - MapCacheRev's in locked_entries. +When bad situation happens, there are multiple (locked) MapCacheEntry +entries in the bucket's linked list along with a number of MapCacheRev's. And +when it comes to a reverse lookup, xen-mapcache picks the wrong entry from the +first list and calculates a wrong pointer from it which may then be caught with +the "Bad RAM offset" check (or not). Mapcache invalidation might be related to +this issue as well I think. + +I'll try to provide a test code which can reproduce the issue from the +guest side using an emulated IDE controller, though it's much simpler to achieve +this result with an AHCI controller using multiple NCQ I/O commands. So far I've +seen this issue only with Windows 7 (and above) guest on AHCI, but any block I/O +DMA should be enough I think. +Yes, I think there may be other bugs lurking, considering the complexity, +though we need to reproduce it if we want to delve into it. + +On Wed, 12 Apr 2017, Alexey G wrote: +> +On Tue, 11 Apr 2017 15:32:09 -0700 (PDT) +> +Stefano Stabellini <address@hidden> wrote: +> +> +> On Tue, 11 Apr 2017, hrg wrote: +> +> > On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +> +> > <address@hidden> wrote: +> +> > > On Mon, 10 Apr 2017, Stefano Stabellini wrote: +> +> > >> On Mon, 10 Apr 2017, hrg wrote: +> +> > >> > On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +> > >> > > On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +> > >> > >> Hi, +> +> > >> > >> +> +> > >> > >> In xen_map_cache_unlocked(), map to guest memory maybe in +> +> > >> > >> entry->next instead of first level entry (if map to rom other than +> +> > >> > >> guest memory comes first), while in xen_invalidate_map_cache(), +> +> > >> > >> when VM ballooned out memory, qemu did not invalidate cache +> +> > >> > >> entries +> +> > >> > >> in linked list(entry->next), so when VM balloon back in memory, +> +> > >> > >> gfns probably mapped to different mfns, thus if guest asks device +> +> > >> > >> to DMA to these GPA, qemu may DMA to stale MFNs. +> +> > >> > >> +> +> > >> > >> So I think in xen_invalidate_map_cache() linked lists should also +> +> > >> > >> be +> +> > >> > >> checked and invalidated. +> +> > >> > >> +> +> > >> > >> Whatâs your opinion? Is this a bug? Is my analyze correct? +> +> > >> +> +> > >> Yes, you are right. We need to go through the list for each element of +> +> > >> the array in xen_invalidate_map_cache. Can you come up with a patch? +> +> > > +> +> > > I spoke too soon. In the regular case there should be no locked mappings +> +> > > when xen_invalidate_map_cache is called (see the DPRINTF warning at the +> +> > > beginning of the functions). Without locked mappings, there should never +> +> > > be more than one element in each list (see xen_map_cache_unlocked: +> +> > > entry->lock == true is a necessary condition to append a new entry to +> +> > > the list, otherwise it is just remapped). +> +> > > +> +> > > Can you confirm that what you are seeing are locked mappings +> +> > > when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +> +> > > by turning it into a printf or by defininig MAPCACHE_DEBUG. +> +> > +> +> > In fact, I think the DPRINTF above is incorrect too. In +> +> > pci_add_option_rom(), rtl8139 rom is locked mapped in +> +> > pci_add_option_rom->memory_region_get_ram_ptr (after +> +> > memory_region_init_ram). So actually I think we should remove the +> +> > DPRINTF warning as it is normal. +> +> +> +> Let me explain why the DPRINTF warning is there: emulated dma operations +> +> can involve locked mappings. Once a dma operation completes, the related +> +> mapping is unlocked and can be safely destroyed. But if we destroy a +> +> locked mapping in xen_invalidate_map_cache, while a dma is still +> +> ongoing, QEMU will crash. We cannot handle that case. +> +> +> +> However, the scenario you described is different. It has nothing to do +> +> with DMA. It looks like pci_add_option_rom calls +> +> memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a +> +> locked mapping and it is never unlocked or destroyed. +> +> +> +> It looks like "ptr" is not used after pci_add_option_rom returns. Does +> +> the append patch fix the problem you are seeing? For the proper fix, I +> +> think we probably need some sort of memory_region_unmap wrapper or maybe +> +> a call to address_space_unmap. +> +> +Hmm, for some reason my message to the Xen-devel list got rejected but was +> +sent +> +to Qemu-devel instead, without any notice. Sorry if I'm missing something +> +obvious as a list newbie. +> +> +Stefano, hrg, +> +> +There is an issue with inconsistency between the list of normal +> +MapCacheEntry's +> +and their 'reverse' counterparts - MapCacheRev's in locked_entries. +> +When bad situation happens, there are multiple (locked) MapCacheEntry +> +entries in the bucket's linked list along with a number of MapCacheRev's. And +> +when it comes to a reverse lookup, xen-mapcache picks the wrong entry from the +> +first list and calculates a wrong pointer from it which may then be caught +> +with +> +the "Bad RAM offset" check (or not). Mapcache invalidation might be related to +> +this issue as well I think. +> +> +I'll try to provide a test code which can reproduce the issue from the +> +guest side using an emulated IDE controller, though it's much simpler to +> +achieve +> +this result with an AHCI controller using multiple NCQ I/O commands. So far +> +I've +> +seen this issue only with Windows 7 (and above) guest on AHCI, but any block +> +I/O +> +DMA should be enough I think. +That would be helpful. Please see if you can reproduce it after fixing +the other issue ( +http://marc.info/?l=qemu-devel&m=149195042500707&w=2 +). + +On 2017/4/12 6:32, Stefano Stabellini wrote: +On Tue, 11 Apr 2017, hrg wrote: +On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +<address@hidden> wrote: +On Mon, 10 Apr 2017, Stefano Stabellini wrote: +On Mon, 10 Apr 2017, hrg wrote: +On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +Hi, + +In xen_map_cache_unlocked(), map to guest memory maybe in entry->next +instead of first level entry (if map to rom other than guest memory +comes first), while in xen_invalidate_map_cache(), when VM ballooned +out memory, qemu did not invalidate cache entries in linked +list(entry->next), so when VM balloon back in memory, gfns probably +mapped to different mfns, thus if guest asks device to DMA to these +GPA, qemu may DMA to stale MFNs. + +So I think in xen_invalidate_map_cache() linked lists should also be +checked and invalidated. + +Whatâs your opinion? Is this a bug? Is my analyze correct? +Yes, you are right. We need to go through the list for each element of +the array in xen_invalidate_map_cache. Can you come up with a patch? +I spoke too soon. In the regular case there should be no locked mappings +when xen_invalidate_map_cache is called (see the DPRINTF warning at the +beginning of the functions). Without locked mappings, there should never +be more than one element in each list (see xen_map_cache_unlocked: +entry->lock == true is a necessary condition to append a new entry to +the list, otherwise it is just remapped). + +Can you confirm that what you are seeing are locked mappings +when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +by turning it into a printf or by defininig MAPCACHE_DEBUG. +In fact, I think the DPRINTF above is incorrect too. In +pci_add_option_rom(), rtl8139 rom is locked mapped in +pci_add_option_rom->memory_region_get_ram_ptr (after +memory_region_init_ram). So actually I think we should remove the +DPRINTF warning as it is normal. +Let me explain why the DPRINTF warning is there: emulated dma operations +can involve locked mappings. Once a dma operation completes, the related +mapping is unlocked and can be safely destroyed. But if we destroy a +locked mapping in xen_invalidate_map_cache, while a dma is still +ongoing, QEMU will crash. We cannot handle that case. + +However, the scenario you described is different. It has nothing to do +with DMA. It looks like pci_add_option_rom calls +memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a +locked mapping and it is never unlocked or destroyed. + +It looks like "ptr" is not used after pci_add_option_rom returns. Does +the append patch fix the problem you are seeing? For the proper fix, I +think we probably need some sort of memory_region_unmap wrapper or maybe +a call to address_space_unmap. +Yes, I think so, maybe this is the proper way to fix this. +diff --git a/hw/pci/pci.c b/hw/pci/pci.c +index e6b08e1..04f98b7 100644 +--- a/hw/pci/pci.c ++++ b/hw/pci/pci.c +@@ -2242,6 +2242,7 @@ static void pci_add_option_rom(PCIDevice *pdev, bool +is_default_rom, + } +pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom); ++ xen_invalidate_map_cache_entry(ptr); + } +static void pci_del_option_rom(PCIDevice *pdev) + +On Wed, 12 Apr 2017, Herongguang (Stephen) wrote: +> +On 2017/4/12 6:32, Stefano Stabellini wrote: +> +> On Tue, 11 Apr 2017, hrg wrote: +> +> > On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +> +> > <address@hidden> wrote: +> +> > > On Mon, 10 Apr 2017, Stefano Stabellini wrote: +> +> > > > On Mon, 10 Apr 2017, hrg wrote: +> +> > > > > On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +> +> > > > > > On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +> +> > > > > > > Hi, +> +> > > > > > > +> +> > > > > > > In xen_map_cache_unlocked(), map to guest memory maybe in +> +> > > > > > > entry->next +> +> > > > > > > instead of first level entry (if map to rom other than guest +> +> > > > > > > memory +> +> > > > > > > comes first), while in xen_invalidate_map_cache(), when VM +> +> > > > > > > ballooned +> +> > > > > > > out memory, qemu did not invalidate cache entries in linked +> +> > > > > > > list(entry->next), so when VM balloon back in memory, gfns +> +> > > > > > > probably +> +> > > > > > > mapped to different mfns, thus if guest asks device to DMA to +> +> > > > > > > these +> +> > > > > > > GPA, qemu may DMA to stale MFNs. +> +> > > > > > > +> +> > > > > > > So I think in xen_invalidate_map_cache() linked lists should +> +> > > > > > > also be +> +> > > > > > > checked and invalidated. +> +> > > > > > > +> +> > > > > > > Whatâs your opinion? Is this a bug? Is my analyze correct? +> +> > > > Yes, you are right. We need to go through the list for each element of +> +> > > > the array in xen_invalidate_map_cache. Can you come up with a patch? +> +> > > I spoke too soon. In the regular case there should be no locked mappings +> +> > > when xen_invalidate_map_cache is called (see the DPRINTF warning at the +> +> > > beginning of the functions). Without locked mappings, there should never +> +> > > be more than one element in each list (see xen_map_cache_unlocked: +> +> > > entry->lock == true is a necessary condition to append a new entry to +> +> > > the list, otherwise it is just remapped). +> +> > > +> +> > > Can you confirm that what you are seeing are locked mappings +> +> > > when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +> +> > > by turning it into a printf or by defininig MAPCACHE_DEBUG. +> +> > In fact, I think the DPRINTF above is incorrect too. In +> +> > pci_add_option_rom(), rtl8139 rom is locked mapped in +> +> > pci_add_option_rom->memory_region_get_ram_ptr (after +> +> > memory_region_init_ram). So actually I think we should remove the +> +> > DPRINTF warning as it is normal. +> +> Let me explain why the DPRINTF warning is there: emulated dma operations +> +> can involve locked mappings. Once a dma operation completes, the related +> +> mapping is unlocked and can be safely destroyed. But if we destroy a +> +> locked mapping in xen_invalidate_map_cache, while a dma is still +> +> ongoing, QEMU will crash. We cannot handle that case. +> +> +> +> However, the scenario you described is different. It has nothing to do +> +> with DMA. It looks like pci_add_option_rom calls +> +> memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a +> +> locked mapping and it is never unlocked or destroyed. +> +> +> +> It looks like "ptr" is not used after pci_add_option_rom returns. Does +> +> the append patch fix the problem you are seeing? For the proper fix, I +> +> think we probably need some sort of memory_region_unmap wrapper or maybe +> +> a call to address_space_unmap. +> +> +Yes, I think so, maybe this is the proper way to fix this. +Would you be up for sending a proper patch and testing it? We cannot call +xen_invalidate_map_cache_entry directly from pci.c though, it would need +to be one of the other functions like address_space_unmap for example. + + +> +> diff --git a/hw/pci/pci.c b/hw/pci/pci.c +> +> index e6b08e1..04f98b7 100644 +> +> --- a/hw/pci/pci.c +> +> +++ b/hw/pci/pci.c +> +> @@ -2242,6 +2242,7 @@ static void pci_add_option_rom(PCIDevice *pdev, bool +> +> is_default_rom, +> +> } +> +> pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom); +> +> + xen_invalidate_map_cache_entry(ptr); +> +> } +> +> static void pci_del_option_rom(PCIDevice *pdev) + +On 2017/4/13 7:51, Stefano Stabellini wrote: +On Wed, 12 Apr 2017, Herongguang (Stephen) wrote: +On 2017/4/12 6:32, Stefano Stabellini wrote: +On Tue, 11 Apr 2017, hrg wrote: +On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +<address@hidden> wrote: +On Mon, 10 Apr 2017, Stefano Stabellini wrote: +On Mon, 10 Apr 2017, hrg wrote: +On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> wrote: +On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> wrote: +Hi, + +In xen_map_cache_unlocked(), map to guest memory maybe in +entry->next +instead of first level entry (if map to rom other than guest +memory +comes first), while in xen_invalidate_map_cache(), when VM +ballooned +out memory, qemu did not invalidate cache entries in linked +list(entry->next), so when VM balloon back in memory, gfns +probably +mapped to different mfns, thus if guest asks device to DMA to +these +GPA, qemu may DMA to stale MFNs. + +So I think in xen_invalidate_map_cache() linked lists should +also be +checked and invalidated. + +Whatâs your opinion? Is this a bug? Is my analyze correct? +Yes, you are right. We need to go through the list for each element of +the array in xen_invalidate_map_cache. Can you come up with a patch? +I spoke too soon. In the regular case there should be no locked mappings +when xen_invalidate_map_cache is called (see the DPRINTF warning at the +beginning of the functions). Without locked mappings, there should never +be more than one element in each list (see xen_map_cache_unlocked: +entry->lock == true is a necessary condition to append a new entry to +the list, otherwise it is just remapped). + +Can you confirm that what you are seeing are locked mappings +when xen_invalidate_map_cache is called? To find out, enable the DPRINTK +by turning it into a printf or by defininig MAPCACHE_DEBUG. +In fact, I think the DPRINTF above is incorrect too. In +pci_add_option_rom(), rtl8139 rom is locked mapped in +pci_add_option_rom->memory_region_get_ram_ptr (after +memory_region_init_ram). So actually I think we should remove the +DPRINTF warning as it is normal. +Let me explain why the DPRINTF warning is there: emulated dma operations +can involve locked mappings. Once a dma operation completes, the related +mapping is unlocked and can be safely destroyed. But if we destroy a +locked mapping in xen_invalidate_map_cache, while a dma is still +ongoing, QEMU will crash. We cannot handle that case. + +However, the scenario you described is different. It has nothing to do +with DMA. It looks like pci_add_option_rom calls +memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a +locked mapping and it is never unlocked or destroyed. + +It looks like "ptr" is not used after pci_add_option_rom returns. Does +the append patch fix the problem you are seeing? For the proper fix, I +think we probably need some sort of memory_region_unmap wrapper or maybe +a call to address_space_unmap. +Yes, I think so, maybe this is the proper way to fix this. +Would you be up for sending a proper patch and testing it? We cannot call +xen_invalidate_map_cache_entry directly from pci.c though, it would need +to be one of the other functions like address_space_unmap for example. +Yes, I will look into this. +diff --git a/hw/pci/pci.c b/hw/pci/pci.c +index e6b08e1..04f98b7 100644 +--- a/hw/pci/pci.c ++++ b/hw/pci/pci.c +@@ -2242,6 +2242,7 @@ static void pci_add_option_rom(PCIDevice *pdev, bool +is_default_rom, + } + pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom); ++ xen_invalidate_map_cache_entry(ptr); + } + static void pci_del_option_rom(PCIDevice *pdev) + +On Thu, 13 Apr 2017, Herongguang (Stephen) wrote: +> +On 2017/4/13 7:51, Stefano Stabellini wrote: +> +> On Wed, 12 Apr 2017, Herongguang (Stephen) wrote: +> +> > On 2017/4/12 6:32, Stefano Stabellini wrote: +> +> > > On Tue, 11 Apr 2017, hrg wrote: +> +> > > > On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini +> +> > > > <address@hidden> wrote: +> +> > > > > On Mon, 10 Apr 2017, Stefano Stabellini wrote: +> +> > > > > > On Mon, 10 Apr 2017, hrg wrote: +> +> > > > > > > On Sun, Apr 9, 2017 at 11:55 PM, hrg <address@hidden> +> +> > > > > > > wrote: +> +> > > > > > > > On Sun, Apr 9, 2017 at 11:52 PM, hrg <address@hidden> +> +> > > > > > > > wrote: +> +> > > > > > > > > Hi, +> +> > > > > > > > > +> +> > > > > > > > > In xen_map_cache_unlocked(), map to guest memory maybe in +> +> > > > > > > > > entry->next +> +> > > > > > > > > instead of first level entry (if map to rom other than guest +> +> > > > > > > > > memory +> +> > > > > > > > > comes first), while in xen_invalidate_map_cache(), when VM +> +> > > > > > > > > ballooned +> +> > > > > > > > > out memory, qemu did not invalidate cache entries in linked +> +> > > > > > > > > list(entry->next), so when VM balloon back in memory, gfns +> +> > > > > > > > > probably +> +> > > > > > > > > mapped to different mfns, thus if guest asks device to DMA +> +> > > > > > > > > to +> +> > > > > > > > > these +> +> > > > > > > > > GPA, qemu may DMA to stale MFNs. +> +> > > > > > > > > +> +> > > > > > > > > So I think in xen_invalidate_map_cache() linked lists should +> +> > > > > > > > > also be +> +> > > > > > > > > checked and invalidated. +> +> > > > > > > > > +> +> > > > > > > > > Whatâs your opinion? Is this a bug? Is my analyze correct? +> +> > > > > > Yes, you are right. We need to go through the list for each +> +> > > > > > element of +> +> > > > > > the array in xen_invalidate_map_cache. Can you come up with a +> +> > > > > > patch? +> +> > > > > I spoke too soon. In the regular case there should be no locked +> +> > > > > mappings +> +> > > > > when xen_invalidate_map_cache is called (see the DPRINTF warning at +> +> > > > > the +> +> > > > > beginning of the functions). Without locked mappings, there should +> +> > > > > never +> +> > > > > be more than one element in each list (see xen_map_cache_unlocked: +> +> > > > > entry->lock == true is a necessary condition to append a new entry +> +> > > > > to +> +> > > > > the list, otherwise it is just remapped). +> +> > > > > +> +> > > > > Can you confirm that what you are seeing are locked mappings +> +> > > > > when xen_invalidate_map_cache is called? To find out, enable the +> +> > > > > DPRINTK +> +> > > > > by turning it into a printf or by defininig MAPCACHE_DEBUG. +> +> > > > In fact, I think the DPRINTF above is incorrect too. In +> +> > > > pci_add_option_rom(), rtl8139 rom is locked mapped in +> +> > > > pci_add_option_rom->memory_region_get_ram_ptr (after +> +> > > > memory_region_init_ram). So actually I think we should remove the +> +> > > > DPRINTF warning as it is normal. +> +> > > Let me explain why the DPRINTF warning is there: emulated dma operations +> +> > > can involve locked mappings. Once a dma operation completes, the related +> +> > > mapping is unlocked and can be safely destroyed. But if we destroy a +> +> > > locked mapping in xen_invalidate_map_cache, while a dma is still +> +> > > ongoing, QEMU will crash. We cannot handle that case. +> +> > > +> +> > > However, the scenario you described is different. It has nothing to do +> +> > > with DMA. It looks like pci_add_option_rom calls +> +> > > memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a +> +> > > locked mapping and it is never unlocked or destroyed. +> +> > > +> +> > > It looks like "ptr" is not used after pci_add_option_rom returns. Does +> +> > > the append patch fix the problem you are seeing? For the proper fix, I +> +> > > think we probably need some sort of memory_region_unmap wrapper or maybe +> +> > > a call to address_space_unmap. +> +> > +> +> > Yes, I think so, maybe this is the proper way to fix this. +> +> +> +> Would you be up for sending a proper patch and testing it? We cannot call +> +> xen_invalidate_map_cache_entry directly from pci.c though, it would need +> +> to be one of the other functions like address_space_unmap for example. +> +> +> +> +> +Yes, I will look into this. +Any updates? + + +> +> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c +> +> > > index e6b08e1..04f98b7 100644 +> +> > > --- a/hw/pci/pci.c +> +> > > +++ b/hw/pci/pci.c +> +> > > @@ -2242,6 +2242,7 @@ static void pci_add_option_rom(PCIDevice *pdev, +> +> > > bool +> +> > > is_default_rom, +> +> > > } +> +> > > pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom); +> +> > > + xen_invalidate_map_cache_entry(ptr); +> +> > > } +> +> > > static void pci_del_option_rom(PCIDevice *pdev) +> + diff --git a/results/classifier/zero-shot/108/permissions/568228 b/results/classifier/zero-shot/108/permissions/568228 new file mode 100644 index 000000000..7f113fd2e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/568228 @@ -0,0 +1,1408 @@ +permissions: 0.927 +device: 0.855 +socket: 0.838 +boot: 0.823 +PID: 0.819 +semantic: 0.813 +performance: 0.809 +network: 0.808 +other: 0.717 +graphic: 0.707 +files: 0.668 +debug: 0.655 +KVM: 0.612 +vnc: 0.486 + +/home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error + +I get the following error each time I start emulation in QEMU 0.12.3 on a Sun SunFire 280R running Debian Lenny 5.03 for Sparc64: + +/home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error + +I had the same problem in Qemu 0.11.1. + +Here are informations about my system, I am not a programmer so I don't know what information to give, if you need more info just ask me: + +sunfire:/home# uname -a +Linux sunfire 2.6.26 #1 Thu Apr 8 17:09:17 EDT 2010 sparc64 GNU/Linux +sunfire:/home# dmesg +nges: +[ 0.000000] Normal 0 -> 130933 +[ 0.000000] Movable zone start PFN for each node +[ 0.000000] early_node_map[7] active PFN ranges +[ 0.000000] 0: 0 -> 129023 +[ 0.000000] 0: 129024 -> 130666 +[ 0.000000] 0: 130796 -> 130803 +[ 0.000000] 0: 130805 -> 130815 +[ 0.000000] 0: 130818 -> 130826 +[ 0.000000] 0: 130828 -> 130916 +[ 0.000000] 0: 130919 -> 130933 +[ 0.000000] On node 0 totalpages: 130792 +[ 0.000000] Normal zone: 896 pages used for memmap +[ 0.000000] Normal zone: 0 pages reserved +[ 0.000000] Normal zone: 129896 pages, LIFO batch:15 +[ 0.000000] Movable zone: 0 pages used for memmap +[ 0.000000] Booting Linux... +[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129896 +[ 0.000000] Kernel command line: root=/dev/sdb2 ro +[ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes) +[ 0.000000] clocksource: mult[c80000] shift[16] +[ 0.000000] clockevent: mult[147ae14] shift[32] +[ 380.165881] Console: colour dummy device 80x25 +[ 380.183520] console handover: boot [earlyprom0] -> real [tty0] +[ 380.208131] Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes) +[ 380.210503] Inode-cache hash table entries: 65536 (order: 6, 524288 bytes) +[ 380.235415] Memory: 1022064k available (4952k kernel code, 2064k data, 192k init) [fffff80000000000,000000003feea000] +[ 380.312667] Calibrating delay using timer specific routine.. 9.99 BogoMIPS (lpj=19990) +[ 380.312839] Security Framework initialized +[ 380.312870] SELinux: Disabled at boot. +[ 380.312889] Capability LSM initialized +[ 380.312935] Mount-cache hash table entries: 512 +[ 380.313505] Initializing cgroup subsys ns +[ 380.313524] Initializing cgroup subsys cpuacct +[ 380.313536] Initializing cgroup subsys devices +[ 380.314346] net_namespace: 1208 bytes +[ 380.314892] NET: Registered protocol family 16 +[ 380.325288] PCI: Probing for controllers. +[ 380.325332] /pci@8,700000: SCHIZO PCI Bus Module ver[4:0] +[ 380.325349] /pci@8,700000: PCI IO[7ffef000000] MEM[7fe00000000] +[ 380.329864] /pci@8,600000: SCHIZO PCI Bus Module ver[4:0] +[ 380.329881] /pci@8,600000: PCI IO[7ffed000000] MEM[7fd00000000] +[ 380.334466] PCI: Scanning PBM /pci@8,600000 +[ 380.334976] PCI: Scanning PBM /pci@8,700000 +[ 380.336347] ebus0: [flashprom] [bbc] [ppm] [i2c -> (dimm-fru) (dimm-fru) (dimm-fru) (dimm-fru) (nvram) (idprom)] [i2c -> (cpu-fru) (temperature) (fan-control) (motherboard-fru) (i2c-bridge)] [beep] [rtc] [gpio] [pmc] [floppy] [parallel] [serial] +[ 380.349031] usbcore: registered new interface driver usbfs +[ 380.349274] usbcore: registered new interface driver hub +[ 380.349452] usbcore: registered new device driver usb +[ 380.353275] /pci@8,700000/ebus@5/rtc@1,300070: Clock regs at 000007fe7e300070 +[ 380.354631] NET: Registered protocol family 2 +[ 380.356677] Switched to high resolution mode on CPU 0 +[ 380.388803] IP route cache hash table entries: 8192 (order: 3, 65536 bytes) +[ 380.389510] TCP established hash table entries: 32768 (order: 6, 524288 bytes) +[ 380.391238] TCP bind hash table entries: 32768 (order: 5, 262144 bytes) +[ 380.392036] TCP: Hash tables configured (established 32768 bind 32768) +[ 380.392052] TCP reno registered +[ 380.400796] NET: Registered protocol family 1 +[ 380.401078] checking if image is initramfs... it is +[ 381.658428] Freeing initrd memory: 5829k freed +[ 381.659077] Mini RTC Driver +[ 381.659365] /memory-controller@0,400000: US3 memory controller at 0000040000400000 [ACTIVE] +[ 381.660085] audit: initializing netlink socket (disabled) +[ 381.660134] type=2000 audit(1271905721.644:1): initialized +[ 381.660454] Total HugeTLB memory allocated, 0 +[ 381.660756] VFS: Disk quotas dquot_6.5.1 +[ 381.660865] Dquot-cache hash table entries: 1024 (order 0, 8192 bytes) +[ 381.661363] Installing knfsd (copyright (C) 1996 <email address hidden>). +[ 381.662280] NTFS driver 2.1.29 [Flags: R/W]. +[ 381.662397] msgmni has been set to 2009 +[ 381.662746] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) +[ 381.662775] io scheduler noop registered +[ 381.662788] io scheduler anticipatory registered +[ 381.662801] io scheduler deadline registered +[ 381.662844] io scheduler cfq registered (default) +[ 381.668602] Console: switching to colour frame buffer device 80x30 +[ 381.672374] fb0: TVP4020 frame buffer device, memory = 8192K. +[ 381.681745] [drm] Initialized drm 1.1.0 20060810 +[ 381.683020] f0086398: ttyS0 at MMIO 0x7fe7e400000 (irq = 10) is a SAB82532 V3.2 +[ 381.686005] f0086398: ttyS1 at MMIO 0x7fe7e400040 (irq = 10) is a SAB82532 V3.2 +[ 381.694246] brd: module loaded +[ 381.698234] loop: module loaded +[ 381.700507] sungem.c:v0.98 8/24/03 David S. Miller (<email address hidden>) +[ 381.703764] PHY ID: 18074c1, addr: 0 +[ 381.704753] eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:ba:12:bb:58 +[ 381.707196] eth0: Found Generic MII PHY +[ 381.709903] Uniform Multi-Platform E-IDE driver +[ 381.712557] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx +[ 381.719917] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver +[ 381.719963] ohci_hcd 0000:00:05.3: OHCI Host Controller +[ 381.723674] ohci_hcd 0000:00:05.3: new USB bus registered, assigned bus number 1 +[ 381.731670] ohci_hcd 0000:00:05.3: irq 13, io mem 0x7fe01000000 +[ 381.792942] usb usb1: configuration #1 chosen from 1 choice +[ 381.797235] hub 1-0:1.0: USB hub found +[ 381.801563] hub 1-0:1.0: 4 ports detected +[ 381.909230] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 +[ 381.913796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 381.923701] usb usb1: Product: OHCI Host Controller +[ 381.928419] usb usb1: Manufacturer: Linux 2.6.26 ohci_hcd +[ 381.933108] usb usb1: SerialNumber: 0000:00:05.3 +[ 381.937761] USB Universal Host Controller Interface driver v3.0 +[ 381.942637] mice: PS/2 mouse device common for all mice +[ 382.164665] usb 1-2: new low speed USB device using ohci_hcd and address 2 +[ 382.331310] usb 1-2: configuration #1 chosen from 1 choice +[ 382.336918] usb 1-2: New USB device found, idVendor=049f, idProduct=000e +[ 382.341070] usb 1-2: New USB device strings: Mfr=4, Product=20, SerialNumber=0 +[ 382.349921] usb 1-2: Product: Compaq Internet Keyboard +[ 382.354146] usb 1-2: Manufacturer: Chicony +[ 382.612663] usb 1-3: new full speed USB device using ohci_hcd and address 3 +[ 382.777825] usb 1-3: configuration #1 chosen from 1 choice +[ 382.783275] usb 1-3: New USB device found, idVendor=058f, idProduct=6387 +[ 382.787329] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[ 382.791996] usb 1-3: Product: Mass Storage +[ 382.795814] usb 1-3: Manufacturer: Generic +[ 382.799482] usb 1-3: SerialNumber: 0AC899D6 +[ 383.056664] usb 1-4: new low speed USB device using ohci_hcd and address 4 +[ 383.221349] usb 1-4: configuration #1 chosen from 1 choice +[ 383.226691] usb 1-4: New USB device found, idVendor=045e, idProduct=0039 +[ 383.230537] usb 1-4: New USB device strings: Mfr=1, Product=3, SerialNumber=0 +[ 383.235076] usb 1-4: Product: Microsoft 5-Button Mouse with IntelliEye(TM) +[ 383.238730] usb 1-4: Manufacturer: Microsoft +[ 383.248269] input: Chicony Compaq Internet Keyboard as /class/input/input0 +[ 383.264794] input,hidraw0: USB HID v1.10 Keyboard [Chicony Compaq Internet Keyboard] on usb-0000:00:05.3-2 +[ 383.286678] input: Chicony Compaq Internet Keyboard as /class/input/input1 +[ 383.304765] input,hidraw1: USB HID v1.10 Device [Chicony Compaq Internet Keyboard] on usb-0000:00:05.3-2 +[ 383.317738] input: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) as /class/input/input2 +[ 383.340859] input,hidraw2: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:05.3-4 +[ 383.349107] usbcore: registered new interface driver usbhid +[ 383.353153] usbhid: v2.6:USB HID core driver +[ 383.357245] Advanced Linux Sound Architecture Driver Version 1.0.16. +[ 383.402450] PCI: Enabling device: (0000:00:03.0), cmd 1 +[ 384.100863] eth0: Link is up at 100 Mbps, full-duplex. +[ 384.846600] usbcore: registered new interface driver snd-usb-audio +[ 384.851077] ALSA device list: +[ 384.855394] #0: Ensoniq AudioPCI ENS1371 at 0x7ffef000500, irq 17 +[ 384.861036] TCP cubic registered +[ 384.865480] NET: Registered protocol family 17 +[ 384.870147] RPC: Registered udp transport module. +[ 384.874530] RPC: Registered tcp transport module. +[ 384.879100] registered taskstats version 1 +[ 384.883476] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) +[ 386.429586] SCSI subsystem initialized +[ 386.509039] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[12] MMIO=[7fe00120000-7fe001207ff] Max Packet=[2048] IR/IT contexts=[4/4] +[ 386.596175] QLogic Fibre Channel HBA Driver: 8.02.01-k4 +[ 386.600382] PCI: Enabling device: (0001:00:04.0), cmd 3 +[ 386.602464] qla2xxx 0001:00:04.0: Found an ISP2200, irq 20, iobase 0x000007fd00100000 +[ 386.612339] qla2xxx 0001:00:04.0: Configuring PCI space... +[ 386.616586] qla2xxx 0001:00:04.0: Configure NVRAM parameters... +[ 386.714919] qla2xxx 0001:00:04.0: Inconsistent NVRAM detected: checksum=0x0 id=<4>qla2xxx 0001:00:04.0: Falling back to functioning (yet invalid -- WWPN) defaults. +[ 386.728340] qla2xxx 0001:00:04.0: Verifying loaded RISC code... +[ 386.734153] PCI: Enabling device: (0000:00:06.0), cmd 147 +[ 386.735307] sym0: <875> rev 0x37 at pci 0000:00:06.0 irq 14 +[ 386.826112] sym0: No NVRAM, ID 7, Fast-20, SE, parity checking +[ 386.837235] sym0: SCSI BUS has been reset. +[ 386.841214] scsi1 : sym-2.2.3 +[ 386.847653] PCI: Enabling device: (0000:00:06.1), cmd 147 +[ 386.848824] sym1: <875> rev 0x37 at pci 0000:00:06.1 irq 15 +[ 386.939517] sym1: No NVRAM, ID 7, Fast-20, SE, parity checking +[ 386.950672] sym1: SCSI BUS has been reset. +[ 386.954818] scsi2 : sym-2.2.3 +[ 386.965219] firmware: requesting ql2200_fw.bin +[ 387.039293] Initializing USB Mass Storage driver... +[ 387.043558] scsi3 : SCSI emulation for USB Mass Storage devices +[ 387.050004] usbcore: registered new interface driver usb-storage +[ 387.054012] USB Mass Storage support registered. +[ 387.057924] usb-storage: device found at 3 +[ 387.057930] usb-storage: waiting for device to settle before scanning +[ 388.004887] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0003bafffe12bb58] +[ 391.590521] scsi 1:0:6:0: CD-ROM TOSHIBA DVD-ROM SD-M1401 1009 PQ: 0 ANSI: 2 +[ 391.599122] target1:0:6: Beginning Domain Validation +[ 391.603264] target1:0:6: asynchronous +[ 391.608968] target1:0:6: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16) +[ 391.614104] target1:0:6: Domain Validation skipping write tests +[ 391.618025] target1:0:6: Ending Domain Validation +[ 392.057675] usb-storage: device scan complete +[ 392.063643] scsi 3:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 2 +[ 394.008952] Driver 'sr' needs updating - please use bus_type methods +[ 394.017708] sr0: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray +[ 394.021916] Uniform CD-ROM driver Revision: 3.20 +[ 394.026310] sr 1:0:6:0: Attached scsi CD-ROM sr0 +[ 394.056732] sr 1:0:6:0: Attached scsi generic sg0 type 5 +[ 394.357542] scsi 3:0:0:0: Attached scsi generic sg1 type 0 +[ 394.413753] Driver 'sd' needs updating - please use bus_type methods +[ 394.437062] sd 3:0:0:0: [sda] 4103936 512-byte hardware sectors (2101 MB) +[ 394.450042] sd 3:0:0:0: [sda] Write Protect is off +[ 394.454315] sd 3:0:0:0: [sda] Mode Sense: 03 00 00 00 +[ 394.454322] sd 3:0:0:0: [sda] Assuming drive cache: write through +[ 394.481010] sd 3:0:0:0: [sda] 4103936 512-byte hardware sectors (2101 MB) +[ 394.493994] sd 3:0:0:0: [sda] Write Protect is off +[ 394.498261] sd 3:0:0:0: [sda] Mode Sense: 03 00 00 00 +[ 394.498268] sd 3:0:0:0: [sda] Assuming drive cache: write through +[ 394.502483] sda: +[ 394.548320] sd 3:0:0:0: [sda] Attached SCSI removable disk +[ 397.912726] qla2xxx 0001:00:04.0: Allocated (252 KB) for firmware dump... +[ 398.044667] qla2xxx 0001:00:04.0: LIP reset occured (f8ef). +[ 398.049170] scsi0 : qla2xxx +[ 398.054582] qla2xxx 0001:00:04.0: +[ 398.054586] QLogic Fibre Channel HBA Driver: 8.02.01-k4 +[ 398.054590] QLogic QLA22xx - +[ 398.054592] ISP2200: PCI (66 MHz) @ 0001:00:04.0 hdma-, host#=0, fw=2.02.08 TP +[ 398.091669] qla2xxx 0001:00:04.0: LIP occured (f8ef). +[ 398.097133] qla2xxx 0001:00:04.0: LOOP UP detected (1 Gbps). +[ 398.110704] scsi 0:0:0:0: Direct-Access SEAGATE ST336605FSUN36G 0638 PQ: 0 ANSI: 3 +[ 398.126430] scsi 0:0:1:0: Direct-Access SEAGATE ST336605FSUN36G 0638 PQ: 0 ANSI: 3 +[ 398.144907] scsi: waiting for bus probes to complete ... +[ 398.153043] sd 0:0:0:0: [sdb] 71132959 512-byte hardware sectors (36420 MB) +[ 398.159977] sd 0:0:0:0: [sdb] Write Protect is off +[ 398.164380] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08 +[ 398.168750] sd 0:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA +[ 398.181593] sd 0:0:0:0: [sdb] 71132959 512-byte hardware sectors (36420 MB) +[ 398.188754] sd 0:0:0:0: [sdb] Write Protect is off +[ 398.193390] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08 +[ 398.197775] sd 0:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA +[ 398.207949] sdb: sdb1 sdb2 sdb3 sdb4 +[ 398.219180] sd 0:0:0:0: [sdb] Attached SCSI disk +[ 398.223902] sd 0:0:0:0: Attached scsi generic sg2 type 0 +[ 398.232492] sd 0:0:1:0: [sdc] 71132959 512-byte hardware sectors (36420 MB) +[ 398.239757] sd 0:0:1:0: [sdc] Write Protect is off +[ 398.244397] sd 0:0:1:0: [sdc] Mode Sense: db 00 10 08 +[ 398.249021] sd 0:0:1:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA +[ 398.262681] sd 0:0:1:0: [sdc] 71132959 512-byte hardware sectors (36420 MB) +[ 398.270173] sd 0:0:1:0: [sdc] Write Protect is off +[ 398.274917] sd 0:0:1:0: [sdc] Mode Sense: db 00 10 08 +[ 398.279543] sd 0:0:1:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA +[ 398.289888] sdc: sdc1 sdc3 +[ 398.304581] sd 0:0:1:0: [sdc] Attached SCSI disk +[ 398.309417] sd 0:0:1:0: Attached scsi generic sg3 type 0 +[ 398.768132] kjournald starting. Commit interval 5 seconds +[ 398.772864] EXT3-fs: mounted filesystem with ordered data mode. +[ 401.026534] udevd version 125 started +[ 405.141436] Adding 1566320k swap on /dev/sdb4. Priority:-1 extents:1 across:1566320k +[ 405.604286] EXT3 FS on sdb2, internal journal +[ 408.242503] eth0: Link is up at 100 Mbps, full-duplex. +[ 408.249685] eth0: Pause is disabled +[ 410.325778] NET: Registered protocol family 10 +[ 410.330075] lo: Disabled Privacy Extensions +[ 414.287849] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory +[ 414.307535] NFSD: starting 90-second grace period +[ 418.763886] NET: Registered protocol family 5 +[ 420.772658] eth0: no IPv6 routers present +[ 550.132380] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a380) on /dev/pts/0 +[ 550.132405] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a388) on /dev/pts/0 +[ 550.132420] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a390) on /dev/pts/0 +[ 2388.411343] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a380) on /dev/pts/1 +[ 2388.411368] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a388) on /dev/pts/1 +[ 2388.411383] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a390) on /dev/pts/1 + +I can also say that I had this bug while trying to emulate PC (32-bit), Sparc 32 and PowerPC; I didn`t try other machine type. I tried many different source (Floppy image, CD-Rom image, HD image) and I always had that error message. + + I have compiled the qemu 0.12.4 src on Debian 5.0.3 and I have the same problem on my Sun Ultra45. + +$ uname -a +Linux workstation 2.6.26-2-sparc64 #1 Wed May 12 20:39:46 UTC 2010 sparc64 GNU/Linux + + +$ qemu --version +QEMU PC emulator version 0.12.4, Copyright (c) 2003-2008 Fabrice Bellard + + +$ qemu +VNC server running on `127.0.0.1:5900' +/usr/src/qemu-0.12.4/tcg/tcg.c:1367: tcg fatal error +Abandon + + +$ strace qemu +execve("/usr/local/bin/qemu", ["qemu"], [/* 18 vars */]) = 0 +brk(0) = 0x418000 +uname({sys="Linux", node="AdminWS", ...}) = 0 +access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f1c000 +access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) +open("/etc/ld.so.cache", O_RDONLY) = 3 +fstat64(3, {st_mode=S_IFREG|0644, st_size=27892, ...}) = 0 +mmap(NULL, 27892, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f10000 +close(3) = 0 +access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +open("/lib/ultra3/librt.so.1", O_RDONLY) = 3 +read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\35 \0\0\0004\0"..., 512) = 512 +fstat64(3, {st_mode=S_IFREG|0644, st_size=43864, ...}) = 0 +mmap(NULL, 108040, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7ecc000 +mprotect(0xf7ed6000, 57344, PROT_NONE) = 0 +mmap(0xf7ee4000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0xf7ee4000 +close(3) = 0 +access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +open("/lib/ultra3/libpthread.so.0", O_RDONLY) = 3 +read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0M`\0\0\0004\0"..., 512) = 512 +fstat64(3, {st_mode=S_IFREG|0755, st_size=118477, ...}) = 0 +mmap(NULL, 165432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7ea0000 +mprotect(0xf7eb6000, 57344, PROT_NONE) = 0 +mmap(0xf7ec4000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0xf7ec4000 +mmap(0xf7ec8000, 1592, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7ec8000 +close(3) = 0 +access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +open("/lib/ultra3/libutil.so.1", O_RDONLY) = 3 +read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\t\340\0\0\0004\0"..., 512) = 512 +fstat64(3, {st_mode=S_IFREG|0644, st_size=10040, ...}) = 0 +mmap(NULL, 74264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7e8c000 +mprotect(0xf7e8e000, 57344, PROT_NONE) = 0 +mmap(0xf7e9c000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xf7e9c000 +close(3) = 0 +access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +open("/lib/ultra3/libm.so.6", O_RDONLY) = 3 +read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0010\300\0\0\0004\0"..., 512) = 512 +fstat64(3, {st_mode=S_IFREG|0644, st_size=1104248, ...}) = 0 +mmap(NULL, 1168288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7d6c000 +mprotect(0xf7e74000, 57344, PROT_NONE) = 0 +mmap(0xf7e82000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x106000) = 0xf7e82000 +close(3) = 0 +access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +open("/usr/lib/libz.so.1", O_RDONLY) = 3 +read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\32\230\0\0\0004\0"..., 512) = 512 +fstat64(3, {st_mode=S_IFREG|0644, st_size=81184, ...}) = 0 +mmap(NULL, 145408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7d48000 +mprotect(0xf7d5c000, 57344, PROT_NONE) = 0 +mmap(0xf7d6a000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12000) = 0xf7d6a000 +close(3) = 0 +access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +open("/lib/ultra3/libc.so.6", O_RDONLY) = 3 +read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\1\371\300\0\0\0004\0"..., 512) = 512 +fstat64(3, {st_mode=S_IFREG|0755, st_size=1566796, ...}) = 0 +mmap(NULL, 1636704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7bb8000 +mprotect(0xf7d30000, 65536, PROT_NONE) = 0 +mmap(0xf7d40000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178000) = 0xf7d40000 +mmap(0xf7d46000, 6496, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7d46000 +close(3) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f0e000 +mprotect(0xf7e82000, 8192, PROT_READ) = 0 +mprotect(0xf7e9c000, 8192, PROT_READ) = 0 +mprotect(0xf7ec4000, 8192, PROT_READ) = 0 +mprotect(0xf7ee4000, 8192, PROT_READ) = 0 +munmap(0xf7f10000, 27892) = 0 +set_tid_address(0xf7f0e6f8) = 14167 +set_robust_list(0xf7f0e700, 0xc) = 0 +futex(0xffffd7a4, FUTEX_WAKE_PRIVATE, 1) = 0 +rt_sigaction(SIGRT_0, {0xf7ea4c40, [], SA_SIGINFO}, NULL, 0xf7eb1338, 648819) = 0 +rt_sigaction(SIGRT_1, {0xf7ea4740, [], SA_RESTART|SA_SIGINFO}, NULL, 0xf7eb1338, 648819) = 0 +rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 8) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 +brk(0) = 0x418000 +brk(0x43a000) = 0x43a000 +clock_gettime(CLOCK_MONOTONIC, {1741574, 138470700}) = 0 +rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 0xf7eb1358, 648819) = 0 +readlink("/proc/self/exe", "/usr/local/bin/qemu"..., 4095) = 19 +access("/usr/local/share/qemu", R_OK) = 0 +pipe([3, 4]) = 3 +fcntl64(3, F_GETFD) = 0 +fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 +fcntl64(4, F_GETFD) = 0 +fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 +fcntl64(3, F_GETFL) = 0 (flags O_RDONLY) +fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 +fcntl64(4, F_GETFL) = 0x1 (flags O_WRONLY) +fcntl64(4, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 +rt_sigaction(SIGALRM, {0x159a0, ~[RT_0 RT_1], 0}, NULL, 0xf7eb1358, 648819) = 0 +timer_create(CLOCK_REALTIME, {0, SIGALRM, SIGEV_SIGNAL, {...}}, {(nil)}) = 0 +futex(0xf7d46e78, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +mmap2(0x60000000, 33554432, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x60000000 +mprotect(0x220000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 +mmap(NULL, 18882560, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf69b6000 +mmap(NULL, 671744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6912000 +mmap(NULL, 409600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf68ae000 +mmap(NULL, 133185536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee9aa000 +brk(0x45c000) = 0x45c000 +brk(0x480000) = 0x480000 +brk(0x4a4000) = 0x4a4000 +brk(0x4c8000) = 0x4c8000 +access("/usr/local/share/qemu/bios.bin", R_OK) = 0 +open("/usr/local/share/qemu/bios.bin", O_RDONLY|O_LARGEFILE) = 5 +_llseek(5, 0, [131072], SEEK_END) = 0 +close(5) = 0 +mmap(NULL, 147456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee986000 +access("/usr/local/share/qemu/bios.bin", R_OK) = 0 +open("/usr/local/share/qemu/bios.bin", O_RDONLY|O_LARGEFILE) = 5 +_llseek(5, 0, [131072], SEEK_END) = 0 +mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee964000 +_llseek(5, 0, [0], SEEK_SET) = 0 +read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 +close(5) = 0 +mmap(NULL, 147456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee940000 +brk(0x4ea000) = 0x4ea000 +mmap(NULL, 8404992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee13c000 +mmap(NULL, 1236992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee00e000 +access("/usr/local/share/qemu/vgabios-cirrus.bin", R_OK) = 0 +open("/usr/local/share/qemu/vgabios-cirrus.bin", O_RDONLY|O_LARGEFILE) = 5 +_llseek(5, 0, [35840], SEEK_END) = 0 +close(5) = 0 +open("/usr/local/share/qemu/vgabios-cirrus.bin", O_RDONLY|O_LARGEFILE) = 5 +_llseek(5, 0, [35840], SEEK_END) = 0 +_llseek(5, 0, [0], SEEK_SET) = 0 +read(5, "U\252F\351!\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\17\1\0\0\0\0IBM"..., 35840) = 35840 +close(5) = 0 +time(NULL) = 1276600473 +open("/etc/localtime", O_RDONLY) = 5 +fstat64(5, {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0 +fstat64(5, {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee00c000 +read(5, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0\0\0\0\0"..., 4096) = 2945 +_llseek(5, -28, [2917], SEEK_CUR) = 0 +read(5, "\nCET-1CEST,M3.5.0,M10.5.0/3\n"..., 4096) = 28 +close(5) = 0 +munmap(0xee00c000, 8192) = 0 +gettimeofday({1276600473, 351385}, NULL) = 0 +gettimeofday({1276600473, 351727}, NULL) = 0 +timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 989658000}}, NULL) = 0 +mmap(NULL, 401408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedfac000 +mmap(NULL, 204800, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedf7a000 +access("/usr/local/share/qemu/pxe-e1000.bin", R_OK) = 0 +open("/usr/local/share/qemu/pxe-e1000.bin", O_RDONLY|O_LARGEFILE) = 5 +_llseek(5, 0, [72192], SEEK_END) = 0 +close(5) = 0 +mmap(NULL, 147456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedf56000 +brk(0x50c000) = 0x50c000 +open("/usr/local/share/qemu/pxe-e1000.bin", O_RDONLY|O_LARGEFILE) = 5 +_llseek(5, 0, [72192], SEEK_END) = 0 +_llseek(5, 0, [0], SEEK_SET) = 0 +read(5, "U\252\215\351\220\0R\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\200\0\34\0008\0PCIR\206"..., 72192) = 72192 +close(5) = 0 +mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedf34000 +mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedf12000 +mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedef0000 +rt_sigaction(SIGINT, {0x14c00, [], 0}, NULL, 0xf7eb1358, 4294967295) = 0 +rt_sigaction(SIGHUP, {0x14c00, [], 0}, NULL, 0xf7eb1358, 4294967295) = 0 +rt_sigaction(SIGTERM, {0x14c00, [], 0}, NULL, 0xf7eb1358, 4294967295) = 0 +rt_sigaction(SIGCHLD, {0x16260, [], SA_NOCLDSTOP}, NULL, 0xf7eb1358, 4294967295) = 0 +access("/usr/local/share/qemu/keymaps/en-us", R_OK) = 0 +open("/usr/local/share/qemu/keymaps/en-us", O_RDONLY|O_LARGEFILE) = 5 +fstat64(5, {st_mode=S_IFREG|0644, st_size=609, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +read(5, "# generated from XKB map us\ninclu"..., 4096) = 609 +access("/usr/local/share/qemu/keymaps/common", R_OK) = 0 +open("/usr/local/share/qemu/keymaps/common", O_RDONLY|O_LARGEFILE) = 6 +fstat64(6, {st_mode=S_IFREG|0644, st_size=2077, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeec000 +read(6, "include modifiers\n\n#\n# Top row\n#\n"..., 4096) = 2077 +access("/usr/local/share/qemu/keymaps/modifiers", R_OK) = 0 +open("/usr/local/share/qemu/keymaps/modifiers", O_RDONLY|O_LARGEFILE) = 7 +fstat64(7, {st_mode=S_IFREG|0644, st_size=293, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeea000 +read(7, "Shift_R 0x36\nShift_L 0x2a\n\nAlt_R "..., 4096) = 293 +read(7, ""..., 4096) = 0 +close(7) = 0 +munmap(0xedeea000, 8192) = 0 +read(6, ""..., 4096) = 0 +close(6) = 0 +munmap(0xedeec000, 8192) = 0 +read(5, ""..., 4096) = 0 +close(5) = 0 +munmap(0xedeee000, 8192) = 0 +socket(PF_NETLINK, SOCK_RAW, 0) = 5 +bind(5, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 +getsockname(5, {sa_family=AF_NETLINK, pid=14167, groups=00000000}, [12]) = 0 +time(NULL) = 1276600473 +sendto(5, "\0\0\0\24\0\26\3\1L\27`\231\0\0\0\0\0\0\0\0"..., 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 +recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\0\0\0000\0\24\0\2L\27`\231\0\0007W\2\10\200\376\0\0\0\1\0\10\0\1\177\0\0\1\0"..., 8192}], msg_controllen=0, msg_flags=0}, 0) = 108 +recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\0\0\0@\0\24\0\2L\27`\231\0\0007W\n\200\200\376\0\0\0\1\0\24\0\1\0\0\0\0\0"..., 8192}], msg_controllen=0, msg_flags=0}, 0) = 128 +recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\0\0\0\24\0\3\0\2L\27`\231\0\0007W\0\0\0\0\0\0\0\1\0\24\0\1\0\0\0\0\0"..., 8192}], msg_controllen=0, msg_flags=0}, 0) = 20 +close(5) = 0 +socket(PF_FILE, SOCK_STREAM, 0) = 5 +fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"...}, 110) = -1 ENOENT (No such file or directory) +close(5) = 0 +socket(PF_FILE, SOCK_STREAM, 0) = 5 +fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"...}, 110) = -1 ENOENT (No such file or directory) +close(5) = 0 +open("/etc/nsswitch.conf", O_RDONLY) = 5 +fstat64(5, {st_mode=S_IFREG|0644, st_size=475, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +read(5, "# /etc/nsswitch.conf\n#\n# Example "..., 4096) = 475 +read(5, ""..., 4096) = 0 +close(5) = 0 +munmap(0xedeee000, 8192) = 0 +open("/etc/host.conf", O_RDONLY) = 5 +fstat64(5, {st_mode=S_IFREG|0644, st_size=9, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +read(5, "multi on\n"..., 4096) = 9 +read(5, ""..., 4096) = 0 +close(5) = 0 +munmap(0xedeee000, 8192) = 0 +futex(0xf7d46c48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +open("/etc/resolv.conf", O_RDONLY) = 5 +fstat64(5, {st_mode=S_IFREG|0644, st_size=50, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +read(5, "nameserver 172.24.25.130\nnameserv"..., 4096) = 50 +read(5, ""..., 4096) = 0 +close(5) = 0 +munmap(0xedeee000, 8192) = 0 +uname({sys="Linux", node="AdminWS", ...}) = 0 +open("/etc/ld.so.cache", O_RDONLY) = 5 +fstat64(5, {st_mode=S_IFREG|0644, st_size=27892, ...}) = 0 +mmap(NULL, 27892, PROT_READ, MAP_PRIVATE, 5, 0) = 0xedee8000 +close(5) = 0 +access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +open("/lib/ultra3/libnss_files.so.2", O_RDONLY) = 5 +read(5, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\33\200\0\0\0004\0"..., 512) = 512 +fstat64(5, {st_mode=S_IFREG|0644, st_size=51436, ...}) = 0 +mmap(NULL, 116136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0xedec8000 +mprotect(0xeded4000, 57344, PROT_NONE) = 0 +mmap(0xedee2000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0xa000) = 0xedee2000 +close(5) = 0 +mprotect(0xedee2000, 8192, PROT_READ) = 0 +munmap(0xedee8000, 27892) = 0 +open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 5 +fcntl64(5, F_GETFD) = 0x1 (flags FD_CLOEXEC) +fstat64(5, {st_mode=S_IFREG|0644, st_size=258, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +read(5, "127.0.0.1\tlocalhost\n192.168.253.9"..., 4096) = 258 +read(5, ""..., 4096) = 0 +close(5) = 0 +munmap(0xedeee000, 8192) = 0 +open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 5 +fstat64(5, {st_mode=S_IFREG|0644, st_size=258, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +read(5, "127.0.0.1\tlocalhost\n192.168.253.9"..., 4096) = 258 +read(5, ""..., 4096) = 0 +close(5) = 0 +munmap(0xedeee000, 8192) = 0 +open("/etc/gai.conf", O_RDONLY) = 5 +fstat64(5, {st_mode=S_IFREG|0644, st_size=2689, ...}) = 0 +fstat64(5, {st_mode=S_IFREG|0644, st_size=2689, ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +read(5, "# Configuration for getaddrinfo(3"..., 4096) = 2689 +read(5, ""..., 4096) = 0 +close(5) = 0 +munmap(0xedeee000, 8192) = 0 +futex(0xf7d45fcc, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 5 +connect(5, {sa_family=AF_INET6, sin6_port=htons(5900), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 +getsockname(5, {sa_family=AF_INET6, sin6_port=htons(56298), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 +connect(5, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...}, 16) = 0 +connect(5, {sa_family=AF_INET, sin_port=htons(5900), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 +getsockname(5, {sa_family=AF_INET6, sin6_port=htons(45955), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 +close(5) = 0 +socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5 +fcntl64(5, F_GETFD) = 0 +fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 +setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +bind(5, {sa_family=AF_INET, sin_port=htons(5900), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 +listen(5, 1) = 0 +getsockname(5, {sa_family=AF_INET, sin_port=htons(5900), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 +fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +write(1, "VNC server running on `127.0.0.1:"..., 39VNC server running on `127.0.0.1:5900' +) = 39 +mmap(NULL, 1236992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedd9a000 +clock_gettime(CLOCK_MONOTONIC, {1741574, 226308600}) = 0 +gettimeofday({1276600473, 406623}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 226990500}) = 0 +timer_gettime(0, {it_interval={0, 0}, it_value={0, 934714800}}) = 0 +timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 +brk(0x54a000) = 0x54a000 +--- SIGALRM (Alarm clock) @ 0 (0) --- +write(4, "\0"..., 1) = 1 +sigreturn() = ? (mask now [TRAP ABRT EMT KILL SEGV SYS PIPE ALRM URG TSTP CHLD IO XCPU XFSZ VTALRM PROF LOST USR1 USR2]) +brk(0x586000) = 0x586000 +munmap(0xee964000, 139264) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 235112000}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 235450700}) = 0 +gettimeofday({1276600473, 415744}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 236098450}) = 0 +timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 +select(6, [3 5], [], [], {0, 0}) = 1 (in [3], left {0, 0}) +--- SIGALRM (Alarm clock) @ 0 (0) --- +write(4, "\0"..., 1) = 1 +sigreturn() = ? (mask now [QUIT TRAP ABRT FPE KILL BUS SEGV PIPE ALRM TERM STOP]) +read(3, "\0\0"..., 512) = 2 +read(3, 0xffffd1f8, 512) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_MONOTONIC, {1741574, 237994250}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 238092800}) = 0 +gettimeofday({1276600473, 418255}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 238459700}) = 0 +timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 239038600}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 239185100}) = 0 +--- SIGALRM (Alarm clock) @ 0 (0) --- +write(4, "\0"..., 1) = 1 +sigreturn() = ? (mask now [ILL BUS PIPE STOP CONT CHLD TTOU IO XCPU XFSZ VTALRM PROF LOST USR1 USR2]) +clock_gettime(CLOCK_MONOTONIC, {1741574, 239897400}) = 0 +gettimeofday({1276600473, 420135}, NULL) = 0 +select(6, [3 5], [], [], {0, 0}) = 1 (in [3], left {0, 0}) +read(3, "\0"..., 512) = 1 +read(3, 0xffffd1f8, 512) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_MONOTONIC, {1741574, 240829200}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 240960750}) = 0 +gettimeofday({1276600473, 421072}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 241221500}) = 0 +timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 21614000}}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 241752650}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 241870200}) = 0 +gettimeofday({1276600473, 421985}, NULL) = 0 +select(6, [3 5], [], [], {0, 0}) = 0 (Timeout) +clock_gettime(CLOCK_MONOTONIC, {1741574, 242444300}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 242622500}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 242730900}) = 0 +gettimeofday({1276600473, 422906}, NULL) = 0 +--- SIGALRM (Alarm clock) @ 0 (0) --- +write(4, "\0"..., 1) = 1 +sigreturn() = ? (mask now [QUIT TRAP ABRT EMT KILL BUS SYS PIPE ALRM URG STOP TSTP CONT CHLD]) +select(6, [3 5], [], [], {0, 0}) = 1 (in [3], left {0, 0}) +read(3, "\0"..., 512) = 1 +read(3, 0xffffd1f8, 512) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_MONOTONIC, {1741574, 264573100}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 264646150}) = 0 +gettimeofday({1276600473, 444669}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 264930200}) = 0 +timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 265311300}) = 0 +--- SIGALRM (Alarm clock) @ 0 (0) --- +write(4, "\0"..., 1) = 1 +sigreturn() = ? (mask now [ILL BUS PIPE STOP CONT CHLD TTOU IO XCPU XFSZ VTALRM PROF LOST USR1 USR2]) +clock_gettime(CLOCK_MONOTONIC, {1741574, 265801000}) = 0 +gettimeofday({1276600473, 445973}, NULL) = 0 +select(6, [3 5], [], [], {0, 0}) = 1 (in [3], left {0, 0}) +read(3, "\0"..., 512) = 1 +read(3, 0xffffd1f8, 512) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_MONOTONIC, {1741574, 266336900}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 266394350}) = 0 +gettimeofday({1276600473, 446415}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 266503850}) = 0 +timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 3000000}}, NULL) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 266696100}) = 0 +clock_gettime(CLOCK_MONOTONIC, {1741574, 266751700}) = 0 +gettimeofday({1276600473, 446771}, NULL) = 0 +write(2, "/usr/src/qemu-0.12.4/tcg/tcg.c:13"..., 53/usr/src/qemu-0.12.4/tcg/tcg.c:1367: tcg fatal error +) = 53 +rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 +tgkill(14167, 14167, SIGABRT) = 0 +--- SIGABRT (Aborted) @ 0 (0) --- ++++ killed by SIGABRT +++ + +--------------------------------------------------------------------------------------------------------------------------------------------------------------- + +$ gdb qemu +GNU gdb 6.8-debian +Copyright (C) 2008 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "sparc-linux-gnu"... +(no debugging symbols found) +(gdb) run +Starting program: /usr/local/bin/qemu +(no debugging symbols found) +(no debugging symbols found) +(no debugging symbols found) +[Thread debugging using libthread_db enabled] +(no debugging symbols found) +(no debugging symbols found) +(no debugging symbols found) +(no debugging symbols found) +[New Thread 0xf7fa66b0 (LWP 14173)] +(no debugging symbols found) +VNC server running on `127.0.0.1:5900' +/usr/src/qemu-0.12.4/tcg/tcg.c:1367: tcg fatal error + +Program received signal SIGABRT, Aborted. +[Switching to Thread 0xf7fa66b0 (LWP 14173)] +0xf7c893ac in raise () from /lib/ultra3/libc.so.6 +(gdb) bt +#0 0xf7c893ac in raise () from /lib/ultra3/libc.so.6 +#1 0xf7c8b198 in abort () from /lib/ultra3/libc.so.6 +#2 0x0015073c in ?? () +#3 0x0015073c in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) + + + + +On Tue, Jun 15, 2010 at 11:21 AM, Deckhartz <email address hidden> wrote: +> I have compiled the qemu 0.12.4 src on Debian 5.0.3 and I have the same +> problem on my Sun Ultra45. +> +> $ uname -a +> Linux workstation 2.6.26-2-sparc64 #1 Wed May 12 20:39:46 UTC 2010 sparc64 GNU/Linux +> +> +> $ qemu --version +> QEMU PC emulator version 0.12.4, Copyright (c) 2003-2008 Fabrice Bellard +> +> +> $ qemu +> VNC server running on `127.0.0.1:5900' +> /usr/src/qemu-0.12.4/tcg/tcg.c:1367: tcg fatal error +> Abandon + +This does not happen on OpenBSD/Sparc64 host, I get the BIOS screen +complaining about missing boot device. On Linux it happens because +glibc or other system libraries mangle global registers which should +be reserved for applications according to ABI. We even have some +workarounds in QEMU for this, but they are not enough. + +> +> +> $ strace qemu +> execve("/usr/local/bin/qemu", ["qemu"], [/* 18 vars */]) = 0 +> brk(0) = 0x418000 +> uname({sys="Linux", node="AdminWS", ...}) = 0 +> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f1c000 +> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) +> open("/etc/ld.so.cache", O_RDONLY) = 3 +> fstat64(3, {st_mode=S_IFREG|0644, st_size=27892, ...}) = 0 +> mmap(NULL, 27892, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f10000 +> close(3) = 0 +> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +> open("/lib/ultra3/librt.so.1", O_RDONLY) = 3 +> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\35 \0\0\0004\0"..., 512) = 512 +> fstat64(3, {st_mode=S_IFREG|0644, st_size=43864, ...}) = 0 +> mmap(NULL, 108040, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7ecc000 +> mprotect(0xf7ed6000, 57344, PROT_NONE) = 0 +> mmap(0xf7ee4000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0xf7ee4000 +> close(3) = 0 +> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +> open("/lib/ultra3/libpthread.so.0", O_RDONLY) = 3 +> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0M`\0\0\0004\0"..., 512) = 512 +> fstat64(3, {st_mode=S_IFREG|0755, st_size=118477, ...}) = 0 +> mmap(NULL, 165432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7ea0000 +> mprotect(0xf7eb6000, 57344, PROT_NONE) = 0 +> mmap(0xf7ec4000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0xf7ec4000 +> mmap(0xf7ec8000, 1592, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7ec8000 +> close(3) = 0 +> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +> open("/lib/ultra3/libutil.so.1", O_RDONLY) = 3 +> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\t\340\0\0\0004\0"..., 512) = 512 +> fstat64(3, {st_mode=S_IFREG|0644, st_size=10040, ...}) = 0 +> mmap(NULL, 74264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7e8c000 +> mprotect(0xf7e8e000, 57344, PROT_NONE) = 0 +> mmap(0xf7e9c000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xf7e9c000 +> close(3) = 0 +> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +> open("/lib/ultra3/libm.so.6", O_RDONLY) = 3 +> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0010\300\0\0\0004\0"..., 512) = 512 +> fstat64(3, {st_mode=S_IFREG|0644, st_size=1104248, ...}) = 0 +> mmap(NULL, 1168288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7d6c000 +> mprotect(0xf7e74000, 57344, PROT_NONE) = 0 +> mmap(0xf7e82000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x106000) = 0xf7e82000 +> close(3) = 0 +> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +> open("/usr/lib/libz.so.1", O_RDONLY) = 3 +> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\32\230\0\0\0004\0"..., 512) = 512 +> fstat64(3, {st_mode=S_IFREG|0644, st_size=81184, ...}) = 0 +> mmap(NULL, 145408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7d48000 +> mprotect(0xf7d5c000, 57344, PROT_NONE) = 0 +> mmap(0xf7d6a000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12000) = 0xf7d6a000 +> close(3) = 0 +> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +> open("/lib/ultra3/libc.so.6", O_RDONLY) = 3 +> read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\1\371\300\0\0\0004\0"..., 512) = 512 +> fstat64(3, {st_mode=S_IFREG|0755, st_size=1566796, ...}) = 0 +> mmap(NULL, 1636704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7bb8000 +> mprotect(0xf7d30000, 65536, PROT_NONE) = 0 +> mmap(0xf7d40000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178000) = 0xf7d40000 +> mmap(0xf7d46000, 6496, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7d46000 +> close(3) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f0e000 +> mprotect(0xf7e82000, 8192, PROT_READ) = 0 +> mprotect(0xf7e9c000, 8192, PROT_READ) = 0 +> mprotect(0xf7ec4000, 8192, PROT_READ) = 0 +> mprotect(0xf7ee4000, 8192, PROT_READ) = 0 +> munmap(0xf7f10000, 27892) = 0 +> set_tid_address(0xf7f0e6f8) = 14167 +> set_robust_list(0xf7f0e700, 0xc) = 0 +> futex(0xffffd7a4, FUTEX_WAKE_PRIVATE, 1) = 0 +> rt_sigaction(SIGRT_0, {0xf7ea4c40, [], SA_SIGINFO}, NULL, 0xf7eb1338, 648819) = 0 +> rt_sigaction(SIGRT_1, {0xf7ea4740, [], SA_RESTART|SA_SIGINFO}, NULL, 0xf7eb1338, 648819) = 0 +> rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 8) = 0 +> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 +> brk(0) = 0x418000 +> brk(0x43a000) = 0x43a000 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 138470700}) = 0 +> rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 0xf7eb1358, 648819) = 0 +> readlink("/proc/self/exe", "/usr/local/bin/qemu"..., 4095) = 19 +> access("/usr/local/share/qemu", R_OK) = 0 +> pipe([3, 4]) = 3 +> fcntl64(3, F_GETFD) = 0 +> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 +> fcntl64(4, F_GETFD) = 0 +> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 +> fcntl64(3, F_GETFL) = 0 (flags O_RDONLY) +> fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 +> fcntl64(4, F_GETFL) = 0x1 (flags O_WRONLY) +> fcntl64(4, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 +> rt_sigaction(SIGALRM, {0x159a0, ~[RT_0 RT_1], 0}, NULL, 0xf7eb1358, 648819) = 0 +> timer_create(CLOCK_REALTIME, {0, SIGALRM, SIGEV_SIGNAL, {...}}, {(nil)}) = 0 +> futex(0xf7d46e78, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +> mmap2(0x60000000, 33554432, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x60000000 +> mprotect(0x220000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 +> mmap(NULL, 18882560, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf69b6000 +> mmap(NULL, 671744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6912000 +> mmap(NULL, 409600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf68ae000 +> mmap(NULL, 133185536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee9aa000 +> brk(0x45c000) = 0x45c000 +> brk(0x480000) = 0x480000 +> brk(0x4a4000) = 0x4a4000 +> brk(0x4c8000) = 0x4c8000 +> access("/usr/local/share/qemu/bios.bin", R_OK) = 0 +> open("/usr/local/share/qemu/bios.bin", O_RDONLY|O_LARGEFILE) = 5 +> _llseek(5, 0, [131072], SEEK_END) = 0 +> close(5) = 0 +> mmap(NULL, 147456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee986000 +> access("/usr/local/share/qemu/bios.bin", R_OK) = 0 +> open("/usr/local/share/qemu/bios.bin", O_RDONLY|O_LARGEFILE) = 5 +> _llseek(5, 0, [131072], SEEK_END) = 0 +> mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee964000 +> _llseek(5, 0, [0], SEEK_SET) = 0 +> read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 +> close(5) = 0 +> mmap(NULL, 147456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee940000 +> brk(0x4ea000) = 0x4ea000 +> mmap(NULL, 8404992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee13c000 +> mmap(NULL, 1236992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee00e000 +> access("/usr/local/share/qemu/vgabios-cirrus.bin", R_OK) = 0 +> open("/usr/local/share/qemu/vgabios-cirrus.bin", O_RDONLY|O_LARGEFILE) = 5 +> _llseek(5, 0, [35840], SEEK_END) = 0 +> close(5) = 0 +> open("/usr/local/share/qemu/vgabios-cirrus.bin", O_RDONLY|O_LARGEFILE) = 5 +> _llseek(5, 0, [35840], SEEK_END) = 0 +> _llseek(5, 0, [0], SEEK_SET) = 0 +> read(5, "U\252F\351!\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\17\1\0\0\0\0IBM"..., 35840) = 35840 +> close(5) = 0 +> time(NULL) = 1276600473 +> open("/etc/localtime", O_RDONLY) = 5 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=2945, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xee00c000 +> read(5, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0\0\0\0\0"..., 4096) = 2945 +> _llseek(5, -28, [2917], SEEK_CUR) = 0 +> read(5, "\nCET-1CEST,M3.5.0,M10.5.0/3\n"..., 4096) = 28 +> close(5) = 0 +> munmap(0xee00c000, 8192) = 0 +> gettimeofday({1276600473, 351385}, NULL) = 0 +> gettimeofday({1276600473, 351727}, NULL) = 0 +> timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +> timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 989658000}}, NULL) = 0 +> mmap(NULL, 401408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedfac000 +> mmap(NULL, 204800, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedf7a000 +> access("/usr/local/share/qemu/pxe-e1000.bin", R_OK) = 0 +> open("/usr/local/share/qemu/pxe-e1000.bin", O_RDONLY|O_LARGEFILE) = 5 +> _llseek(5, 0, [72192], SEEK_END) = 0 +> close(5) = 0 +> mmap(NULL, 147456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedf56000 +> brk(0x50c000) = 0x50c000 +> open("/usr/local/share/qemu/pxe-e1000.bin", O_RDONLY|O_LARGEFILE) = 5 +> _llseek(5, 0, [72192], SEEK_END) = 0 +> _llseek(5, 0, [0], SEEK_SET) = 0 +> read(5, "U\252\215\351\220\0R\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\200\0\34\0008\0PCIR\206"..., 72192) = 72192 +> close(5) = 0 +> mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedf34000 +> mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedf12000 +> mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedef0000 +> rt_sigaction(SIGINT, {0x14c00, [], 0}, NULL, 0xf7eb1358, 4294967295) = 0 +> rt_sigaction(SIGHUP, {0x14c00, [], 0}, NULL, 0xf7eb1358, 4294967295) = 0 +> rt_sigaction(SIGTERM, {0x14c00, [], 0}, NULL, 0xf7eb1358, 4294967295) = 0 +> rt_sigaction(SIGCHLD, {0x16260, [], SA_NOCLDSTOP}, NULL, 0xf7eb1358, 4294967295) = 0 +> access("/usr/local/share/qemu/keymaps/en-us", R_OK) = 0 +> open("/usr/local/share/qemu/keymaps/en-us", O_RDONLY|O_LARGEFILE) = 5 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=609, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +> read(5, "# generated from XKB map us\ninclu"..., 4096) = 609 +> access("/usr/local/share/qemu/keymaps/common", R_OK) = 0 +> open("/usr/local/share/qemu/keymaps/common", O_RDONLY|O_LARGEFILE) = 6 +> fstat64(6, {st_mode=S_IFREG|0644, st_size=2077, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeec000 +> read(6, "include modifiers\n\n#\n# Top row\n#\n"..., 4096) = 2077 +> access("/usr/local/share/qemu/keymaps/modifiers", R_OK) = 0 +> open("/usr/local/share/qemu/keymaps/modifiers", O_RDONLY|O_LARGEFILE) = 7 +> fstat64(7, {st_mode=S_IFREG|0644, st_size=293, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeea000 +> read(7, "Shift_R 0x36\nShift_L 0x2a\n\nAlt_R "..., 4096) = 293 +> read(7, ""..., 4096) = 0 +> close(7) = 0 +> munmap(0xedeea000, 8192) = 0 +> read(6, ""..., 4096) = 0 +> close(6) = 0 +> munmap(0xedeec000, 8192) = 0 +> read(5, ""..., 4096) = 0 +> close(5) = 0 +> munmap(0xedeee000, 8192) = 0 +> socket(PF_NETLINK, SOCK_RAW, 0) = 5 +> bind(5, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 +> getsockname(5, {sa_family=AF_NETLINK, pid=14167, groups=00000000}, [12]) = 0 +> time(NULL) = 1276600473 +> sendto(5, "\0\0\0\24\0\26\3\1L\27`\231\0\0\0\0\0\0\0\0"..., 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 +> recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\0\0\0000\0\24\0\2L\27`\231\0\0007W\2\10\200\376\0\0\0\1\0\10\0\1\177\0\0\1\0"..., 8192}], msg_controllen=0, msg_flags=0}, 0) = 108 +> recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\0\0\0@\0\24\0\2L\27`\231\0\0007W\n\200\200\376\0\0\0\1\0\24\0\1\0\0\0\0\0"..., 8192}], msg_controllen=0, msg_flags=0}, 0) = 128 +> recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\0\0\0\24\0\3\0\2L\27`\231\0\0007W\0\0\0\0\0\0\0\1\0\24\0\1\0\0\0\0\0"..., 8192}], msg_controllen=0, msg_flags=0}, 0) = 20 +> close(5) = 0 +> socket(PF_FILE, SOCK_STREAM, 0) = 5 +> fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +> connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"...}, 110) = -1 ENOENT (No such file or directory) +> close(5) = 0 +> socket(PF_FILE, SOCK_STREAM, 0) = 5 +> fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +> connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"...}, 110) = -1 ENOENT (No such file or directory) +> close(5) = 0 +> open("/etc/nsswitch.conf", O_RDONLY) = 5 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=475, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +> read(5, "# /etc/nsswitch.conf\n#\n# Example "..., 4096) = 475 +> read(5, ""..., 4096) = 0 +> close(5) = 0 +> munmap(0xedeee000, 8192) = 0 +> open("/etc/host.conf", O_RDONLY) = 5 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=9, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +> read(5, "multi on\n"..., 4096) = 9 +> read(5, ""..., 4096) = 0 +> close(5) = 0 +> munmap(0xedeee000, 8192) = 0 +> futex(0xf7d46c48, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +> open("/etc/resolv.conf", O_RDONLY) = 5 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=50, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +> read(5, "nameserver 172.24.25.130\nnameserv"..., 4096) = 50 +> read(5, ""..., 4096) = 0 +> close(5) = 0 +> munmap(0xedeee000, 8192) = 0 +> uname({sys="Linux", node="AdminWS", ...}) = 0 +> open("/etc/ld.so.cache", O_RDONLY) = 5 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=27892, ...}) = 0 +> mmap(NULL, 27892, PROT_READ, MAP_PRIVATE, 5, 0) = 0xedee8000 +> close(5) = 0 +> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) +> open("/lib/ultra3/libnss_files.so.2", O_RDONLY) = 5 +> read(5, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\33\200\0\0\0004\0"..., 512) = 512 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=51436, ...}) = 0 +> mmap(NULL, 116136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0xedec8000 +> mprotect(0xeded4000, 57344, PROT_NONE) = 0 +> mmap(0xedee2000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0xa000) = 0xedee2000 +> close(5) = 0 +> mprotect(0xedee2000, 8192, PROT_READ) = 0 +> munmap(0xedee8000, 27892) = 0 +> open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 5 +> fcntl64(5, F_GETFD) = 0x1 (flags FD_CLOEXEC) +> fstat64(5, {st_mode=S_IFREG|0644, st_size=258, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +> read(5, "127.0.0.1\tlocalhost\n192.168.253.9"..., 4096) = 258 +> read(5, ""..., 4096) = 0 +> close(5) = 0 +> munmap(0xedeee000, 8192) = 0 +> open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 5 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=258, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +> read(5, "127.0.0.1\tlocalhost\n192.168.253.9"..., 4096) = 258 +> read(5, ""..., 4096) = 0 +> close(5) = 0 +> munmap(0xedeee000, 8192) = 0 +> open("/etc/gai.conf", O_RDONLY) = 5 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=2689, ...}) = 0 +> fstat64(5, {st_mode=S_IFREG|0644, st_size=2689, ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +> read(5, "# Configuration for getaddrinfo(3"..., 4096) = 2689 +> read(5, ""..., 4096) = 0 +> close(5) = 0 +> munmap(0xedeee000, 8192) = 0 +> futex(0xf7d45fcc, FUTEX_WAKE_PRIVATE, 2147483647) = 0 +> socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 5 +> connect(5, {sa_family=AF_INET6, sin6_port=htons(5900), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 +> getsockname(5, {sa_family=AF_INET6, sin6_port=htons(56298), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 +> connect(5, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...}, 16) = 0 +> connect(5, {sa_family=AF_INET, sin_port=htons(5900), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 +> getsockname(5, {sa_family=AF_INET6, sin6_port=htons(45955), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 +> close(5) = 0 +> socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5 +> fcntl64(5, F_GETFD) = 0 +> fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 +> setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +> bind(5, {sa_family=AF_INET, sin_port=htons(5900), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 +> listen(5, 1) = 0 +> getsockname(5, {sa_family=AF_INET, sin_port=htons(5900), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 +> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 +> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedeee000 +> write(1, "VNC server running on `127.0.0.1:"..., 39VNC server running on `127.0.0.1:5900' +> ) = 39 +> mmap(NULL, 1236992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xedd9a000 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 226308600}) = 0 +> gettimeofday({1276600473, 406623}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 226990500}) = 0 +> timer_gettime(0, {it_interval={0, 0}, it_value={0, 934714800}}) = 0 +> timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 +> brk(0x54a000) = 0x54a000 +> --- SIGALRM (Alarm clock) @ 0 (0) --- +> write(4, "\0"..., 1) = 1 +> sigreturn() = ? (mask now [TRAP ABRT EMT KILL SEGV SYS PIPE ALRM URG TSTP CHLD IO XCPU XFSZ VTALRM PROF LOST USR1 USR2]) +> brk(0x586000) = 0x586000 +> munmap(0xee964000, 139264) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 235112000}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 235450700}) = 0 +> gettimeofday({1276600473, 415744}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 236098450}) = 0 +> timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +> timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 +> select(6, [3 5], [], [], {0, 0}) = 1 (in [3], left {0, 0}) +> --- SIGALRM (Alarm clock) @ 0 (0) --- +> write(4, "\0"..., 1) = 1 +> sigreturn() = ? (mask now [QUIT TRAP ABRT FPE KILL BUS SEGV PIPE ALRM TERM STOP]) +> read(3, "\0\0"..., 512) = 2 +> read(3, 0xffffd1f8, 512) = -1 EAGAIN (Resource temporarily unavailable) +> clock_gettime(CLOCK_MONOTONIC, {1741574, 237994250}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 238092800}) = 0 +> gettimeofday({1276600473, 418255}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 238459700}) = 0 +> timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +> timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 239038600}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 239185100}) = 0 +> --- SIGALRM (Alarm clock) @ 0 (0) --- +> write(4, "\0"..., 1) = 1 +> sigreturn() = ? (mask now [ILL BUS PIPE STOP CONT CHLD TTOU IO XCPU XFSZ VTALRM PROF LOST USR1 USR2]) +> clock_gettime(CLOCK_MONOTONIC, {1741574, 239897400}) = 0 +> gettimeofday({1276600473, 420135}, NULL) = 0 +> select(6, [3 5], [], [], {0, 0}) = 1 (in [3], left {0, 0}) +> read(3, "\0"..., 512) = 1 +> read(3, 0xffffd1f8, 512) = -1 EAGAIN (Resource temporarily unavailable) +> clock_gettime(CLOCK_MONOTONIC, {1741574, 240829200}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 240960750}) = 0 +> gettimeofday({1276600473, 421072}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 241221500}) = 0 +> timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +> timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 21614000}}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 241752650}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 241870200}) = 0 +> gettimeofday({1276600473, 421985}, NULL) = 0 +> select(6, [3 5], [], [], {0, 0}) = 0 (Timeout) +> clock_gettime(CLOCK_MONOTONIC, {1741574, 242444300}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 242622500}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 242730900}) = 0 +> gettimeofday({1276600473, 422906}, NULL) = 0 +> --- SIGALRM (Alarm clock) @ 0 (0) --- +> write(4, "\0"..., 1) = 1 +> sigreturn() = ? (mask now [QUIT TRAP ABRT EMT KILL BUS SYS PIPE ALRM URG STOP TSTP CONT CHLD]) +> select(6, [3 5], [], [], {0, 0}) = 1 (in [3], left {0, 0}) +> read(3, "\0"..., 512) = 1 +> read(3, 0xffffd1f8, 512) = -1 EAGAIN (Resource temporarily unavailable) +> clock_gettime(CLOCK_MONOTONIC, {1741574, 264573100}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 264646150}) = 0 +> gettimeofday({1276600473, 444669}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 264930200}) = 0 +> timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +> timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 265311300}) = 0 +> --- SIGALRM (Alarm clock) @ 0 (0) --- +> write(4, "\0"..., 1) = 1 +> sigreturn() = ? (mask now [ILL BUS PIPE STOP CONT CHLD TTOU IO XCPU XFSZ VTALRM PROF LOST USR1 USR2]) +> clock_gettime(CLOCK_MONOTONIC, {1741574, 265801000}) = 0 +> gettimeofday({1276600473, 445973}, NULL) = 0 +> select(6, [3 5], [], [], {0, 0}) = 1 (in [3], left {0, 0}) +> read(3, "\0"..., 512) = 1 +> read(3, 0xffffd1f8, 512) = -1 EAGAIN (Resource temporarily unavailable) +> clock_gettime(CLOCK_MONOTONIC, {1741574, 266336900}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 266394350}) = 0 +> gettimeofday({1276600473, 446415}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 266503850}) = 0 +> timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0 +> timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 3000000}}, NULL) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 266696100}) = 0 +> clock_gettime(CLOCK_MONOTONIC, {1741574, 266751700}) = 0 +> gettimeofday({1276600473, 446771}, NULL) = 0 +> write(2, "/usr/src/qemu-0.12.4/tcg/tcg.c:13"..., 53/usr/src/qemu-0.12.4/tcg/tcg.c:1367: tcg fatal error +> ) = 53 +> rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 +> tgkill(14167, 14167, SIGABRT) = 0 +> --- SIGABRT (Aborted) @ 0 (0) --- +> +++ killed by SIGABRT +++ +> +> --------------------------------------------------------------------------------------------------------------------------------------------------------------- +> +> $ gdb qemu +> GNU gdb 6.8-debian +> Copyright (C) 2008 Free Software Foundation, Inc. +> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +> This is free software: you are free to change and redistribute it. +> There is NO WARRANTY, to the extent permitted by law. Type "show copying" +> and "show warranty" for details. +> This GDB was configured as "sparc-linux-gnu"... +> (no debugging symbols found) +> (gdb) run +> Starting program: /usr/local/bin/qemu +> (no debugging symbols found) +> (no debugging symbols found) +> (no debugging symbols found) +> [Thread debugging using libthread_db enabled] +> (no debugging symbols found) +> (no debugging symbols found) +> (no debugging symbols found) +> (no debugging symbols found) +> [New Thread 0xf7fa66b0 (LWP 14173)] +> (no debugging symbols found) +> VNC server running on `127.0.0.1:5900' +> /usr/src/qemu-0.12.4/tcg/tcg.c:1367: tcg fatal error +> +> Program received signal SIGABRT, Aborted. +> [Switching to Thread 0xf7fa66b0 (LWP 14173)] +> 0xf7c893ac in raise () from /lib/ultra3/libc.so.6 +> (gdb) bt +> #0 0xf7c893ac in raise () from /lib/ultra3/libc.so.6 +> #1 0xf7c8b198 in abort () from /lib/ultra3/libc.so.6 +> #2 0x0015073c in ?? () +> #3 0x0015073c in ?? () +> Backtrace stopped: previous frame identical to this frame (corrupt stack?) +> (gdb) +> +> -- +> /home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error +> https://bugs.launchpad.net/bugs/568228 +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> +> Status in QEMU: New +> +> Bug description: +> I get the following error each time I start emulation in QEMU 0.12.3 on a Sun SunFire 280R running Debian Lenny 5.03 for Sparc64: +> +> /home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error +> +> I had the same problem in Qemu 0.11.1. +> +> Here are informations about my system, I am not a programmer so I don't know what information to give, if you need more info just ask me: +> +> sunfire:/home# uname -a +> Linux sunfire 2.6.26 #1 Thu Apr 8 17:09:17 EDT 2010 sparc64 GNU/Linux +> sunfire:/home# dmesg +> nges: +> [ 0.000000] Normal 0 -> 130933 +> [ 0.000000] Movable zone start PFN for each node +> [ 0.000000] early_node_map[7] active PFN ranges +> [ 0.000000] 0: 0 -> 129023 +> [ 0.000000] 0: 129024 -> 130666 +> [ 0.000000] 0: 130796 -> 130803 +> [ 0.000000] 0: 130805 -> 130815 +> [ 0.000000] 0: 130818 -> 130826 +> [ 0.000000] 0: 130828 -> 130916 +> [ 0.000000] 0: 130919 -> 130933 +> [ 0.000000] On node 0 totalpages: 130792 +> [ 0.000000] Normal zone: 896 pages used for memmap +> [ 0.000000] Normal zone: 0 pages reserved +> [ 0.000000] Normal zone: 129896 pages, LIFO batch:15 +> [ 0.000000] Movable zone: 0 pages used for memmap +> [ 0.000000] Booting Linux... +> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129896 +> [ 0.000000] Kernel command line: root=/dev/sdb2 ro +> [ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes) +> [ 0.000000] clocksource: mult[c80000] shift[16] +> [ 0.000000] clockevent: mult[147ae14] shift[32] +> [ 380.165881] Console: colour dummy device 80x25 +> [ 380.183520] console handover: boot [earlyprom0] -> real [tty0] +> [ 380.208131] Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes) +> [ 380.210503] Inode-cache hash table entries: 65536 (order: 6, 524288 bytes) +> [ 380.235415] Memory: 1022064k available (4952k kernel code, 2064k data, 192k init) [fffff80000000000,000000003feea000] +> [ 380.312667] Calibrating delay using timer specific routine.. 9.99 BogoMIPS (lpj=19990) +> [ 380.312839] Security Framework initialized +> [ 380.312870] SELinux: Disabled at boot. +> [ 380.312889] Capability LSM initialized +> [ 380.312935] Mount-cache hash table entries: 512 +> [ 380.313505] Initializing cgroup subsys ns +> [ 380.313524] Initializing cgroup subsys cpuacct +> [ 380.313536] Initializing cgroup subsys devices +> [ 380.314346] net_namespace: 1208 bytes +> [ 380.314892] NET: Registered protocol family 16 +> [ 380.325288] PCI: Probing for controllers. +> [ 380.325332] /pci@8,700000: SCHIZO PCI Bus Module ver[4:0] +> [ 380.325349] /pci@8,700000: PCI IO[7ffef000000] MEM[7fe00000000] +> [ 380.329864] /pci@8,600000: SCHIZO PCI Bus Module ver[4:0] +> [ 380.329881] /pci@8,600000: PCI IO[7ffed000000] MEM[7fd00000000] +> [ 380.334466] PCI: Scanning PBM /pci@8,600000 +> [ 380.334976] PCI: Scanning PBM /pci@8,700000 +> [ 380.336347] ebus0: [flashprom] [bbc] [ppm] [i2c -> (dimm-fru) (dimm-fru) (dimm-fru) (dimm-fru) (nvram) (idprom)] [i2c -> (cpu-fru) (temperature) (fan-control) (motherboard-fru) (i2c-bridge)] [beep] [rtc] [gpio] [pmc] [floppy] [parallel] [serial] +> [ 380.349031] usbcore: registered new interface driver usbfs +> [ 380.349274] usbcore: registered new interface driver hub +> [ 380.349452] usbcore: registered new device driver usb +> [ 380.353275] /pci@8,700000/ebus@5/rtc@1,300070: Clock regs at 000007fe7e300070 +> [ 380.354631] NET: Registered protocol family 2 +> [ 380.356677] Switched to high resolution mode on CPU 0 +> [ 380.388803] IP route cache hash table entries: 8192 (order: 3, 65536 bytes) +> [ 380.389510] TCP established hash table entries: 32768 (order: 6, 524288 bytes) +> [ 380.391238] TCP bind hash table entries: 32768 (order: 5, 262144 bytes) +> [ 380.392036] TCP: Hash tables configured (established 32768 bind 32768) +> [ 380.392052] TCP reno registered +> [ 380.400796] NET: Registered protocol family 1 +> [ 380.401078] checking if image is initramfs... it is +> [ 381.658428] Freeing initrd memory: 5829k freed +> [ 381.659077] Mini RTC Driver +> [ 381.659365] /memory-controller@0,400000: US3 memory controller at 0000040000400000 [ACTIVE] +> [ 381.660085] audit: initializing netlink socket (disabled) +> [ 381.660134] type=2000 audit(1271905721.644:1): initialized +> [ 381.660454] Total HugeTLB memory allocated, 0 +> [ 381.660756] VFS: Disk quotas dquot_6.5.1 +> [ 381.660865] Dquot-cache hash table entries: 1024 (order 0, 8192 bytes) +> [ 381.661363] Installing knfsd (copyright (C) 1996 <email address hidden>). +> [ 381.662280] NTFS driver 2.1.29 [Flags: R/W]. +> [ 381.662397] msgmni has been set to 2009 +> [ 381.662746] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) +> [ 381.662775] io scheduler noop registered +> [ 381.662788] io scheduler anticipatory registered +> [ 381.662801] io scheduler deadline registered +> [ 381.662844] io scheduler cfq registered (default) +> [ 381.668602] Console: switching to colour frame buffer device 80x30 +> [ 381.672374] fb0: TVP4020 frame buffer device, memory = 8192K. +> [ 381.681745] [drm] Initialized drm 1.1.0 20060810 +> [ 381.683020] f0086398: ttyS0 at MMIO 0x7fe7e400000 (irq = 10) is a SAB82532 V3.2 +> [ 381.686005] f0086398: ttyS1 at MMIO 0x7fe7e400040 (irq = 10) is a SAB82532 V3.2 +> [ 381.694246] brd: module loaded +> [ 381.698234] loop: module loaded +> [ 381.700507] sungem.c:v0.98 8/24/03 David S. Miller (<email address hidden>) +> [ 381.703764] PHY ID: 18074c1, addr: 0 +> [ 381.704753] eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:ba:12:bb:58 +> [ 381.707196] eth0: Found Generic MII PHY +> [ 381.709903] Uniform Multi-Platform E-IDE driver +> [ 381.712557] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx +> [ 381.719917] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver +> [ 381.719963] ohci_hcd 0000:00:05.3: OHCI Host Controller +> [ 381.723674] ohci_hcd 0000:00:05.3: new USB bus registered, assigned bus number 1 +> [ 381.731670] ohci_hcd 0000:00:05.3: irq 13, io mem 0x7fe01000000 +> [ 381.792942] usb usb1: configuration #1 chosen from 1 choice +> [ 381.797235] hub 1-0:1.0: USB hub found +> [ 381.801563] hub 1-0:1.0: 4 ports detected +> [ 381.909230] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 +> [ 381.913796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +> [ 381.923701] usb usb1: Product: OHCI Host Controller +> [ 381.928419] usb usb1: Manufacturer: Linux 2.6.26 ohci_hcd +> [ 381.933108] usb usb1: SerialNumber: 0000:00:05.3 +> [ 381.937761] USB Universal Host Controller Interface driver v3.0 +> [ 381.942637] mice: PS/2 mouse device common for all mice +> [ 382.164665] usb 1-2: new low speed USB device using ohci_hcd and address 2 +> [ 382.331310] usb 1-2: configuration #1 chosen from 1 choice +> [ 382.336918] usb 1-2: New USB device found, idVendor=049f, idProduct=000e +> [ 382.341070] usb 1-2: New USB device strings: Mfr=4, Product=20, SerialNumber=0 +> [ 382.349921] usb 1-2: Product: Compaq Internet Keyboard +> [ 382.354146] usb 1-2: Manufacturer: Chicony +> [ 382.612663] usb 1-3: new full speed USB device using ohci_hcd and address 3 +> [ 382.777825] usb 1-3: configuration #1 chosen from 1 choice +> [ 382.783275] usb 1-3: New USB device found, idVendor=058f, idProduct=6387 +> [ 382.787329] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +> [ 382.791996] usb 1-3: Product: Mass Storage +> [ 382.795814] usb 1-3: Manufacturer: Generic +> [ 382.799482] usb 1-3: SerialNumber: 0AC899D6 +> [ 383.056664] usb 1-4: new low speed USB device using ohci_hcd and address 4 +> [ 383.221349] usb 1-4: configuration #1 chosen from 1 choice +> [ 383.226691] usb 1-4: New USB device found, idVendor=045e, idProduct=0039 +> [ 383.230537] usb 1-4: New USB device strings: Mfr=1, Product=3, SerialNumber=0 +> [ 383.235076] usb 1-4: Product: Microsoft 5-Button Mouse with IntelliEye(TM) +> [ 383.238730] usb 1-4: Manufacturer: Microsoft +> [ 383.248269] input: Chicony Compaq Internet Keyboard as /class/input/input0 +> [ 383.264794] input,hidraw0: USB HID v1.10 Keyboard [Chicony Compaq Internet Keyboard] on usb-0000:00:05.3-2 +> [ 383.286678] input: Chicony Compaq Internet Keyboard as /class/input/input1 +> [ 383.304765] input,hidraw1: USB HID v1.10 Device [Chicony Compaq Internet Keyboard] on usb-0000:00:05.3-2 +> [ 383.317738] input: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) as /class/input/input2 +> [ 383.340859] input,hidraw2: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:05.3-4 +> [ 383.349107] usbcore: registered new interface driver usbhid +> [ 383.353153] usbhid: v2.6:USB HID core driver +> [ 383.357245] Advanced Linux Sound Architecture Driver Version 1.0.16. +> [ 383.402450] PCI: Enabling device: (0000:00:03.0), cmd 1 +> [ 384.100863] eth0: Link is up at 100 Mbps, full-duplex. +> [ 384.846600] usbcore: registered new interface driver snd-usb-audio +> [ 384.851077] ALSA device list: +> [ 384.855394] #0: Ensoniq AudioPCI ENS1371 at 0x7ffef000500, irq 17 +> [ 384.861036] TCP cubic registered +> [ 384.865480] NET: Registered protocol family 17 +> [ 384.870147] RPC: Registered udp transport module. +> [ 384.874530] RPC: Registered tcp transport module. +> [ 384.879100] registered taskstats version 1 +> [ 384.883476] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) +> [ 386.429586] SCSI subsystem initialized +> [ 386.509039] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[12] MMIO=[7fe00120000-7fe001207ff] Max Packet=[2048] IR/IT contexts=[4/4] +> [ 386.596175] QLogic Fibre Channel HBA Driver: 8.02.01-k4 +> [ 386.600382] PCI: Enabling device: (0001:00:04.0), cmd 3 +> [ 386.602464] qla2xxx 0001:00:04.0: Found an ISP2200, irq 20, iobase 0x000007fd00100000 +> [ 386.612339] qla2xxx 0001:00:04.0: Configuring PCI space... +> [ 386.616586] qla2xxx 0001:00:04.0: Configure NVRAM parameters... +> [ 386.714919] qla2xxx 0001:00:04.0: Inconsistent NVRAM detected: checksum=0x0 id=<4>qla2xxx 0001:00:04.0: Falling back to functioning (yet invalid -- WWPN) defaults. +> [ 386.728340] qla2xxx 0001:00:04.0: Verifying loaded RISC code... +> [ 386.734153] PCI: Enabling device: (0000:00:06.0), cmd 147 +> [ 386.735307] sym0: <875> rev 0x37 at pci 0000:00:06.0 irq 14 +> [ 386.826112] sym0: No NVRAM, ID 7, Fast-20, SE, parity checking +> [ 386.837235] sym0: SCSI BUS has been reset. +> [ 386.841214] scsi1 : sym-2.2.3 +> [ 386.847653] PCI: Enabling device: (0000:00:06.1), cmd 147 +> [ 386.848824] sym1: <875> rev 0x37 at pci 0000:00:06.1 irq 15 +> [ 386.939517] sym1: No NVRAM, ID 7, Fast-20, SE, parity checking +> [ 386.950672] sym1: SCSI BUS has been reset. +> [ 386.954818] scsi2 : sym-2.2.3 +> [ 386.965219] firmware: requesting ql2200_fw.bin +> [ 387.039293] Initializing USB Mass Storage driver... +> [ 387.043558] scsi3 : SCSI emulation for USB Mass Storage devices +> [ 387.050004] usbcore: registered new interface driver usb-storage +> [ 387.054012] USB Mass Storage support registered. +> [ 387.057924] usb-storage: device found at 3 +> [ 387.057930] usb-storage: waiting for device to settle before scanning +> [ 388.004887] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0003bafffe12bb58] +> [ 391.590521] scsi 1:0:6:0: CD-ROM TOSHIBA DVD-ROM SD-M1401 1009 PQ: 0 ANSI: 2 +> [ 391.599122] target1:0:6: Beginning Domain Validation +> [ 391.603264] target1:0:6: asynchronous +> [ 391.608968] target1:0:6: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16) +> [ 391.614104] target1:0:6: Domain Validation skipping write tests +> [ 391.618025] target1:0:6: Ending Domain Validation +> [ 392.057675] usb-storage: device scan complete +> [ 392.063643] scsi 3:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 2 +> [ 394.008952] Driver 'sr' needs updating - please use bus_type methods +> [ 394.017708] sr0: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray +> [ 394.021916] Uniform CD-ROM driver Revision: 3.20 +> [ 394.026310] sr 1:0:6:0: Attached scsi CD-ROM sr0 +> [ 394.056732] sr 1:0:6:0: Attached scsi generic sg0 type 5 +> [ 394.357542] scsi 3:0:0:0: Attached scsi generic sg1 type 0 +> [ 394.413753] Driver 'sd' needs updating - please use bus_type methods +> [ 394.437062] sd 3:0:0:0: [sda] 4103936 512-byte hardware sectors (2101 MB) +> [ 394.450042] sd 3:0:0:0: [sda] Write Protect is off +> [ 394.454315] sd 3:0:0:0: [sda] Mode Sense: 03 00 00 00 +> [ 394.454322] sd 3:0:0:0: [sda] Assuming drive cache: write through +> [ 394.481010] sd 3:0:0:0: [sda] 4103936 512-byte hardware sectors (2101 MB) +> [ 394.493994] sd 3:0:0:0: [sda] Write Protect is off +> [ 394.498261] sd 3:0:0:0: [sda] Mode Sense: 03 00 00 00 +> [ 394.498268] sd 3:0:0:0: [sda] Assuming drive cache: write through +> [ 394.502483] sda: +> [ 394.548320] sd 3:0:0:0: [sda] Attached SCSI removable disk +> [ 397.912726] qla2xxx 0001:00:04.0: Allocated (252 KB) for firmware dump... +> [ 398.044667] qla2xxx 0001:00:04.0: LIP reset occured (f8ef). +> [ 398.049170] scsi0 : qla2xxx +> [ 398.054582] qla2xxx 0001:00:04.0: +> [ 398.054586] QLogic Fibre Channel HBA Driver: 8.02.01-k4 +> [ 398.054590] QLogic QLA22xx - +> [ 398.054592] ISP2200: PCI (66 MHz) @ 0001:00:04.0 hdma-, host#=0, fw=2.02.08 TP +> [ 398.091669] qla2xxx 0001:00:04.0: LIP occured (f8ef). +> [ 398.097133] qla2xxx 0001:00:04.0: LOOP UP detected (1 Gbps). +> [ 398.110704] scsi 0:0:0:0: Direct-Access SEAGATE ST336605FSUN36G 0638 PQ: 0 ANSI: 3 +> [ 398.126430] scsi 0:0:1:0: Direct-Access SEAGATE ST336605FSUN36G 0638 PQ: 0 ANSI: 3 +> [ 398.144907] scsi: waiting for bus probes to complete ... +> [ 398.153043] sd 0:0:0:0: [sdb] 71132959 512-byte hardware sectors (36420 MB) +> [ 398.159977] sd 0:0:0:0: [sdb] Write Protect is off +> [ 398.164380] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08 +> [ 398.168750] sd 0:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA +> [ 398.181593] sd 0:0:0:0: [sdb] 71132959 512-byte hardware sectors (36420 MB) +> [ 398.188754] sd 0:0:0:0: [sdb] Write Protect is off +> [ 398.193390] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08 +> [ 398.197775] sd 0:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA +> [ 398.207949] sdb: sdb1 sdb2 sdb3 sdb4 +> [ 398.219180] sd 0:0:0:0: [sdb] Attached SCSI disk +> [ 398.223902] sd 0:0:0:0: Attached scsi generic sg2 type 0 +> [ 398.232492] sd 0:0:1:0: [sdc] 71132959 512-byte hardware sectors (36420 MB) +> [ 398.239757] sd 0:0:1:0: [sdc] Write Protect is off +> [ 398.244397] sd 0:0:1:0: [sdc] Mode Sense: db 00 10 08 +> [ 398.249021] sd 0:0:1:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA +> [ 398.262681] sd 0:0:1:0: [sdc] 71132959 512-byte hardware sectors (36420 MB) +> [ 398.270173] sd 0:0:1:0: [sdc] Write Protect is off +> [ 398.274917] sd 0:0:1:0: [sdc] Mode Sense: db 00 10 08 +> [ 398.279543] sd 0:0:1:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA +> [ 398.289888] sdc: sdc1 sdc3 +> [ 398.304581] sd 0:0:1:0: [sdc] Attached SCSI disk +> [ 398.309417] sd 0:0:1:0: Attached scsi generic sg3 type 0 +> [ 398.768132] kjournald starting. Commit interval 5 seconds +> [ 398.772864] EXT3-fs: mounted filesystem with ordered data mode. +> [ 401.026534] udevd version 125 started +> [ 405.141436] Adding 1566320k swap on /dev/sdb4. Priority:-1 extents:1 across:1566320k +> [ 405.604286] EXT3 FS on sdb2, internal journal +> [ 408.242503] eth0: Link is up at 100 Mbps, full-duplex. +> [ 408.249685] eth0: Pause is disabled +> [ 410.325778] NET: Registered protocol family 10 +> [ 410.330075] lo: Disabled Privacy Extensions +> [ 414.287849] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory +> [ 414.307535] NFSD: starting 90-second grace period +> [ 418.763886] NET: Registered protocol family 5 +> [ 420.772658] eth0: no IPv6 routers present +> [ 550.132380] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a380) on /dev/pts/0 +> [ 550.132405] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a388) on /dev/pts/0 +> [ 550.132420] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a390) on /dev/pts/0 +> [ 2388.411343] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a380) on /dev/pts/1 +> [ 2388.411368] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a388) on /dev/pts/1 +> [ 2388.411383] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a390) on /dev/pts/1 +> +> +> +> + diff --git a/results/classifier/zero-shot/108/permissions/568445 b/results/classifier/zero-shot/108/permissions/568445 new file mode 100644 index 000000000..6a404c831 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/568445 @@ -0,0 +1,145 @@ +permissions: 0.963 +performance: 0.951 +other: 0.946 +debug: 0.946 +semantic: 0.944 +device: 0.922 +graphic: 0.917 +PID: 0.914 +KVM: 0.912 +vnc: 0.904 +network: 0.904 +boot: 0.872 +files: 0.866 +socket: 0.789 + +LVM backed drives should default to cache='none' + +Binary package hint: virt-manager + +KVM guests using LVM backed drives appear to experience fairly high iowait times on the host system if the guest has even a moderate amount of disk I/O. This translates to poor performance for the host and all guests running on the host, and appears to be due to caching as KVM defaults to using writethrough caching when nothing is specified. Explicitly disabling KVM's caching appears to result in significantly better host and guest performance. + +This is recommended in at least a few places: +http://<email address hidden>/msg17492.html +http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/48471 +http://<email address hidden>/msg30425.html +http://virt.kernelnewbies.org/XenVsKVM + +The default is cache=writethrough in the interest of data integrity. +I don't think we want to differ from what upstream KVM provides, on +this point. + +Note that the manpage says: + + Some block drivers perform badly with cache=writethrough, most + notably, qcow2. If performance is more important than correctness, + cache=writeback should be used with qcow2. + +If you believe that this default should be changed, please have that +discussion on the upstream kvm and qemu mailing lists. I believe that +upstream has discussed this and has chosen data integrity over +performance as the default. + +Thanks, +:-Dustin + +I fail to see how not using a cache provides any less data integrity than using one. The default caching method, as you quote, is writethrough which according to the manpage states: + + By default, writethrough caching is used for all block device. + This means that the host page cache will be used to read and write + data but write notification will be sent to the guest only when the + data has been reported as written by the storage subsystem. + +The same should be true with no caching, correct? + +The fact that the default writethrough caching results in slower VM disk I/O and a subsequently higher host load is fairly obvious. The links provided in the original report show that LVM backed stores using cache='none' perform significantly better than the default. + +Looks like even upstream suggests disabling cache for best performance when using raw volumes: +http://www.linux-kvm.org/page/Tuning_KVM + +From the above page: + +QEMU also supports a wide variety of caching modes. Writeback is useful for testing but does not offer storage guarantees. Writethrough (the default) is safer, and relies on the host cache. If you're using raw volumes or partitions, it is best to avoid the cache completely, which reduces data copies and bus traffic: + + qemu -drive file=/dev/mapper/ImagesVolumeGroup-Guest1,cache=none,if=virtio + +Copying bug upstream, refiling against qemu-kvm, marking incomplete/wishlist. + +Anthony- + +Can you share the reasoning for the default disk caching method with upstream QEMU? Would it be a good or bad idea to change that in Ubuntu? + +@Jamin- + +Okay, thanks for that last bit. + +So given that information, I think this bug is triaged/wishlist against virt-manager. If virt-manager can detect that you've selected a LVM volume for the backing disk, then it could perhaps force cache=none. + +I doubt, however, that we'll have time to work on this. Feel free to submit a patch, or propose this to the upstream virt-manager community. + +The use-case of virt-manager is casual desktop virtualization. Usually, a user of desktop virtualization benefits from using the host page cache because subsequent launches of a VM are considerably faster since the IO is kept in memory. + +You can manipulate the cache settings via libvirt XML if you so desire. + + + + + + + + + +I noticed the high iowait times a few weeks back when my guest backups were taking a long time to complete. I believe this was sometime after I added a VM to serve as a transparent proxy for my network, but can't be entirely certain. Looking at the e-mail'd cron output, it was fairly obvious that the disk I/O was the problem as several of the guest backups were dropping to 2-3MB/sec reported throughput. These backups are started during the night when there is little to no actual activity on the machines. Checking the host's load and cpu usage confirmed that the problem appeared to be disk I/O related. Searching online seemed to indicate similar problems, but they seemed to be with the disk scheduler being cfq and the recommendation was to move to the deadline scheduler, which the system was already using as its default scheduler. + +After changing each of the guest's LVM backed drive to cache='none' the backups are completing in much more reasonable time. Average throughput for the backups remained at 10MB/sec or better, host load remained low even during more intensive operations. + +@Anthony, + +I'm aware that I can manipulate the cache settings via libvirt's XML. That's currently what I've been doing, manually after every VM creation. However, my point is that qemu clearly recommends that caching not be used with disks stored on raw volumes. Additionally, virt-manager does not provide any means of disabling caching during or after VM creation. I disagree with your assertion regarding cached IO being faster with KVM. All of my tests indicate a multiple fold increase in performance with caching disabled. + +I fail to see how caching provides and more data integrity than no caching. Unless I'm mistaken, no caching provides more integrity by definition. Now, if no caching also provides a mutli-fold performance increase (which it does, as qemu's pages even indicate) why so much resistance to making it the default? + +cache=writethrough and cache=none have equivalent data integrity. + +FWIW, I believe most recent versions of virt-manager default to cache=none for physical devices. + +Can't seem to find anything in the upstream changelogs or source to indicate that such a change was made. + +Anthony, upstream virt-manager doesn't change the cache default, though we do in RHEL. + +Wasn't the idea of having an adaptive cache default for qemu given the okay on qemu-devel, particularly for cache=none for block devs? or am I imagining things (could be the case since I can't seem to find the thread now). + +Description of problem: +Defaults to using cache with an LVM backed storage. The use of caching with raw partitions (LVM) results in significantly lower performance than no cache at all. + +How reproducible: +Always + +Steps to Reproduce: +1. Create a new VM using LVM backed storage + +Actual results: +Cache is enabled for the VM's disks residing within LVM. + +Expected results: +Cache should be disabled for disks residing within LVM. + +Additional info: +http://www.linux-kvm.org/page/Tuning_KVM + +Specifically: + +QEMU also supports a wide variety of caching modes. Writeback is useful for testing but does not offer storage guarantees. Writethrough (the default) is safer, and relies on the host cache. If you're using raw volumes or partitions, it is best to avoid the cache completely, which reduces data copies and bus traffic: + + qemu -drive file=/dev/mapper/ImagesVolumeGroup-Guest1,cache=none,if=virtio + +This has also been reported with Ubuntu at: https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/568445 + +Choice of caching mode is a policy decision. These belong in virt-manager or other apps using libvirt. + +AFAIK, this is the place to post feature requests for virt-manager, at least this is where their website directed me. Intentionally selecting a default mode that results in very poor performance (about 1/5 less) when the upstream for the virtualization engine (qemu/kvm) clearly indicates that another mode is preferable is (IMHO) a bad choice. Furthermore, from what I can tell, virt-manager doesn't appear to provide any means of changing or overriding the default. A user must instead manually edit the server's XML definition of the VM in question. + +Reopening against virt-manager as recommended on mailing list. + +Fixed upstream now + diff --git a/results/classifier/zero-shot/108/permissions/614958 b/results/classifier/zero-shot/108/permissions/614958 new file mode 100644 index 000000000..7551f65ff --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/614958 @@ -0,0 +1,122 @@ +permissions: 0.935 +graphic: 0.908 +PID: 0.882 +semantic: 0.877 +device: 0.869 +other: 0.865 +socket: 0.833 +files: 0.830 +KVM: 0.803 +network: 0.800 +boot: 0.793 +vnc: 0.773 +performance: 0.768 +debug: 0.656 + +copy-paste between client and host + +Hi, + +I propose that copy/paste between VMs be implemented somehow directly in QEMU. +This has been discussed repeatedly elsewhere; various solutions are proposed. See below. + +As it is, each user has to do their own research and testing if they are to find a solution. This makes the product frustratingly unattractive for many. + +Most solutions involve either running vnc and using a vnc client that supports copy/paste (this can be tricky to find itself), or running some other tcp-based copy-paste application. + +For many users, the networking in a client VM is unimportant--they just want to run some application there, and setting up netoworking in a VM itself can be an issue. Most of these solutions rely on un-maintained software, and some require that other software be installed to make them work (Basic interpreter, Java, etc). Any of these solutions take some work to set up. + +I can tell you, the absence of a copy/paste mechanism makes the project an immediate no-go for many users. I work with a guy who spent a lot of time trying, gave up, and switched to VirtualBox for this exact reason. + +It would be much better if copy/paste worked out of the box. Ideally, it should work independently of networking. + +Cheers! + +Some discussions and proposed solutions: +----------------------------------------------------- +http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=161 + Somebody suggests VNC into the virtual host, and use vncviewer + Somebody else suggests TCP/IP Clipboard (text editor with tcp/ip) + +http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=2626 + primitive app for sharing text across machines (in Basic) + http://homepage.mac.com/bnej/shareclip/ + +http://borderworlds.dk/blog/20070217-00.html + Says doesn't know a good solution but points to unmaintained package + Qemu Guest Tools + http://wolfpackally.wo.funpic.de/qemu/qgt/ + +http://bonzoli.com/docs/How_to_setup_Qemu_on_Fedora_8.html + proposes Java remoteclip running on client and server + http://www.cs.cmu.edu/afs/cs/user/rcm/WWW/RemoteClip/ + + + +--- On Sun, 8/8/10, Steve White <email address hidden> wrote: + +> From: Steve White <email address hidden> +> Subject: [Qemu-devel] [Bug 614958] [NEW] copy-paste between client and host +> To: <email address hidden> +> Date: Sunday, August 8, 2010, 3:19 AM + + +> I can tell you, the absence of a copy/paste mechanism makes +> the project +> an immediate no-go for many users. I work with a guy +> who spent a lot of +> time trying, gave up, and switched to VirtualBox for this +> exact reason. + ++1e9. + +_Exactly_, _absolutely_. + +Been there, done that, and even though I write code professionally, I +prefer VirtualBox just because many things in it simply work. + + +Regards, + Sergei. + + + + + +SPICE is supposed to address this kind of issue. Hopefully it will be merged in 0.14. + +Anyway, after SPICE support is merged this feature would belong in SPICE, not in QEMU. See http://spice-space.org/page/Features/SharedClipboard for more information. + +We might keep this open until SPICE is merged, but I'm not sure this bug really belongs in QEMU's bug tracker. + +Hi Paolo, + +Thanks for your acknowledgement! if a solution is on the way, I'm glad to hear it! + +I agree that it would be best to keep this report open until *after* the solution arrives and this particular feature has been tested and it has been released to the public. If this SPICE doesn't completely satisfy the cut and paste requirement, then the bug report should be moved to the SPICE bug report system. + +We are eagerly awaiting the new features! + +Cheers! + +I use serial console to cut&paste between host and guest without networking. + +It's nice SPICE is addressing this but I agree this is not really something qemu itself should do. There is no hardware cut&paste device qemu can emulate, the video hardware has not notion of cut&paste. + +At the very least qemu could support paste but since the SDL interface has no controls and is direct input to the virtual machine there would be need for different interface with more features. + +You can copy screenshots. To support true clipboard copy you need in-client software for every OS you run. While a nice project, and nice thing to point people to in qemu docs (if it exists) it is definitely out of the scope of qemu - a hardware emulator. Note that for SPICE cut&paste to work you will surely need some SPICE driver installed in the guest, and few platforms are supported. + +Hi Michel, + +It may be out of scope for qemu -- the scope is for the developers to decide. + +My point remains though: If this functionality isn't there when the user installs qemu, they will find another solution. It won't be hard to find. I have watched this happen. + +Perhaps there's some synthesis, for example, a preferred packaging of qemu with software that provides this functionality. + + +I think we can close this nowadays, according to comment #2. + +Having to launch a separate `remote-viewer` command to view the desktop is not very satisfactory for me, as you then have to think about two processes instead of one. + diff --git a/results/classifier/zero-shot/108/permissions/636315 b/results/classifier/zero-shot/108/permissions/636315 new file mode 100644 index 000000000..181e814c0 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/636315 @@ -0,0 +1,447 @@ +semantic: 0.971 +permissions: 0.964 +other: 0.963 +PID: 0.950 +device: 0.948 +graphic: 0.947 +debug: 0.939 +performance: 0.930 +socket: 0.913 +boot: 0.903 +vnc: 0.888 +network: 0.884 +files: 0.880 +KVM: 0.877 + +configure and build errors on Solaris 10 due to /bin/sh usage + +Running `LANG=C LC_ALL=C ./configure --prefix=... --install=/usr/ucb/install` on Solaris 10 amd64 results in the following errors: + +./configure: bad substitution +./configure: !: not found +./configure: curl-config: not found +./configure: curl-config: not found + +Error: invalid trace backend +Please choose a supported trace backend. + + +Unfortunately it doesn't print the line numbers of the errors. It must be somewhere after the check for `install`. + +The first few can be resolved by running `bash ./configure ...` instead. + +The "check if trace backend exists" hardcodes `sh "$source_path/tracetool" ...` in configure. Replacing sh with bash makes it work. + +`gmake` complains "Makefile:331: no file name for -include", which is a filter for *.d files. +`create_config` gets the 'bad substitution' error as well. Replacing sh with bash in rules.mak works. +etc. + +To sum it up, +a) there are shell script incompatibilities with Solaris 10's /bin/sh shell, and +b) hardcoding 'sh' in configure or Makefiles seems like a bad idea. + +QEMU Git 73d7434279e3905164afd02360eebe4b43c7fa (ESP: fix ESP DMA access...) + +$ uname -a +SunOS sonnengoettin 5.10 Generic_142901-03 i86pc i386 i86pc + +# No banner output for /bin/sh + +$ bash --version +GNU bash, version 3.00.16(1)-release (i386-pc-solaris2.10) +Copyright (C) 2004 Free Software Foundation, Inc. + +On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber +<email address hidden> wrote: +> Public bug reported: +> +> Running `LANG=C LC_ALL=C ./configure --prefix=... +> --install=/usr/ucb/install` on Solaris 10 amd64 results in the following +> errors: +> +> ./configure: bad substitution +> ./configure: !: not found +> ./configure: curl-config: not found +> ./configure: curl-config: not found +> +> Error: invalid trace backend +> Please choose a supported trace backend. + +What is the output of "sh ./tracetool --nop --check-backend"? + +> +> +> Unfortunately it doesn't print the line numbers of the errors. It must be somewhere after the check for `install`. +> +> The first few can be resolved by running `bash ./configure ...` instead. +> +> The "check if trace backend exists" hardcodes `sh +> "$source_path/tracetool" ...` in configure. Replacing sh with bash makes +> it work. +> +> `gmake` complains "Makefile:331: no file name for -include", which is a filter for *.d files. +> `create_config` gets the 'bad substitution' error as well. Replacing sh with bash in rules.mak works. +> etc. +> +> To sum it up, +> a) there are shell script incompatibilities with Solaris 10's /bin/sh shell, and + +I fixed one in 2184d75b4a6a253e8b1e002b3dbcc85c20ba6041 and now +Milax's /bin/sh is happy. + +Am 12.09.2010 um 19:22 schrieb Blue Swirl: + +> On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber +> <email address hidden> wrote: +>> Error: invalid trace backend +>> Please choose a supported trace backend. +> +> What is the output of "sh ./tracetool --nop --check-backend"? + +./tracetool: syntax error at line 51: `$' unexpected + +On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden> wrote: +> Am 12.09.2010 um 19:22 schrieb Blue Swirl: +> +>> On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber +>> <email address hidden> wrote: +>>> +>>> Error: invalid trace backend +>>> Please choose a supported trace backend. +>> +>> What is the output of "sh ./tracetool --nop --check-backend"? +> +> ./tracetool: syntax error at line 51: `$' unexpected + +Does this patch fix the problem? + +diff --git a/tracetool b/tracetool +index 534cc70..c7582bf 100755 +--- a/tracetool ++++ b/tracetool +@@ -48,7 +48,8 @@ get_argnames() + { + local nfields field name + nfields=0 +- for field in $(get_args "$1"); do ++ args=get_args "$1" ++ for field in "$args"; do + nfields=$((nfields + 1)) + + # Drop pointer star + +Am 12.09.2010 um 19:47 schrieb Blue Swirl: + +> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <<email address hidden> +> > wrote: +>> Am 12.09.2010 um 19:22 schrieb Blue Swirl: +>> +>>> What is the output of "sh ./tracetool --nop --check-backend"? +>> +>> ./tracetool: syntax error at line 51: `$' unexpected +> +> Does this patch fix the problem? +> +> diff --git a/tracetool b/tracetool +> index 534cc70..c7582bf 100755 +> --- a/tracetool +> +++ b/tracetool +> @@ -48,7 +48,8 @@ get_argnames() +> { +> local nfields field name +> nfields=0 +> - for field in $(get_args "$1"); do +> + args=get_args "$1" +> + for field in "$args"; do + +This part yes. (I took the liberty of adding args to the local line +above) + +> nfields=$((nfields + 1)) + +Next error is here: +./tracetool: syntax error at line 53: `nfields=$' unexpected + +On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> wrote: +> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +> +>> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden> +>> wrote: +>>> +>>> Am 12.09.2010 um 19:22 schrieb Blue Swirl: +>>> +>>>> What is the output of "sh ./tracetool --nop --check-backend"? +>>> +>>> ./tracetool: syntax error at line 51: `$' unexpected +>> +>> Does this patch fix the problem? +>> +>> diff --git a/tracetool b/tracetool +>> index 534cc70..c7582bf 100755 +>> --- a/tracetool +>> +++ b/tracetool +>> @@ -48,7 +48,8 @@ get_argnames() +>> { +>> local nfields field name +>> nfields=0 +>> - for field in $(get_args "$1"); do +>> + args=get_args "$1" +>> + for field in "$args"; do +> +> This part yes. (I took the liberty of adding args to the local line above) +> +>> nfields=$((nfields + 1)) +> +> Next error is here: +> ./tracetool: syntax error at line 53: `nfields=$' unexpected + +That looks like fully standards compliant, so Solaris' /bin/sh is not. +Can you try what happens with /usr/xpg4/bin/sh? + +Am 12.09.2010 um 23:05 schrieb Blue Swirl: + +> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> +> > wrote: +>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>> nfields=$((nfields + 1)) +>> +>> ./tracetool: syntax error at line 53: `nfields=$' unexpected +> +> That looks like fully standards compliant, so Solaris' /bin/sh is not. +> Can you try what happens with /usr/xpg4/bin/sh? + +Works fine! Must've done something wrong when testing that earlier +today. + +configure, create_config and tracetool with your fix are silent when / +usr/xpg4/bin is in the $PATH. +If you commit it, we can close this ticket. Thanks for your help, Blue. + +Build still fails, in qemu-nbd.c due to err.h, but that's unrelated +to /bin/sh. +After disabling the tools in configure, sparc-softmmu builds fine again. + +Am 13.09.2010 um 10:49 schrieb Michael Tokarev: + +> 13.09.2010 01:05, Blue Swirl wrote: +>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> +>> > wrote: +>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>> +>>>> diff --git a/tracetool b/tracetool +>>>> index 534cc70..c7582bf 100755 +>>>> --- a/tracetool +>>>> +++ b/tracetool +>>>> @@ -48,7 +48,8 @@ get_argnames() +>>>> { +>>>> local nfields field name +>>>> nfields=0 +>>>> - for field in $(get_args "$1"); do +>>>> + args=get_args "$1" +>>>> + for field in "$args"; do +>>> +>>> This part yes. (I took the liberty of adding args to the local +>>> line above) +> +> Um. Are you sure it works as expected? + +No, I'm not sure. It's Dark Magic to me and happened to unbreak +configure; I'll try out your suggestions the next days. + +Thanks, +Andreas + +> I'm not at all shure. +> There are 2 errors in the above patch: +> +> + args=get_args "$1" +> +> After this line, variable $args will contain one word: "get_args". +> Shell will try to execute a command or call a shell function which +> name is stored in $1, if it is assigned. If it is not, at least +> bash will complain that it can't execute command "". +> +> The proper way is to add backticks: +> +> + args=`get_args "$1"` +> +> In the second line: +> +> + for field in "$args"; do +> +> the double quotes ensure that all words in $args are +> processed as single word, all at once. So the for loop +> will be executed exactly one time, no matter how many +> arguments are given (even if there's none). +> +> So the right solution is to drop double quotes. +> +> JFYI. +> +> /mjt +> + + +On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <email address hidden> wrote: +> Am 12.09.2010 um 23:05 schrieb Blue Swirl: +> +>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> +>> wrote: +>>> +>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>>> +>>>> nfields=$((nfields + 1)) +>>> +>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected +>> +>> That looks like fully standards compliant, so Solaris' /bin/sh is not. +>> Can you try what happens with /usr/xpg4/bin/sh? +> +> Works fine! Must've done something wrong when testing that earlier today. +> +> configure, create_config and tracetool with your fix are silent when +> /usr/xpg4/bin is in the $PATH. +> If you commit it, we can close this ticket. Thanks for your help, Blue. + +Does /usr/xpg4/bin/sh work without the patch? + +On Mon, Sep 13, 2010 at 8:49 AM, Michael Tokarev <email address hidden> wrote: +> 13.09.2010 01:05, Blue Swirl wrote: +>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> wrote: +>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>> +>>>> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden> +>>>> wrote: +>>>>> +>>>>> Am 12.09.2010 um 19:22 schrieb Blue Swirl: +>>>>> +>>>>>> What is the output of "sh ./tracetool --nop --check-backend"? +>>>>> +>>>>> ./tracetool: syntax error at line 51: `$' unexpected +>>>> +>>>> Does this patch fix the problem? +>>>> +>>>> diff --git a/tracetool b/tracetool +>>>> index 534cc70..c7582bf 100755 +>>>> --- a/tracetool +>>>> +++ b/tracetool +>>>> @@ -48,7 +48,8 @@ get_argnames() +>>>> { +>>>> local nfields field name +>>>> nfields=0 +>>>> - for field in $(get_args "$1"); do +>>>> + args=get_args "$1" +>>>> + for field in "$args"; do +>>> +>>> This part yes. (I took the liberty of adding args to the local line above) +> +> Um. Are you sure it works as expected? I'm not at all shure. +> There are 2 errors in the above patch: +> +> + args=get_args "$1" +> +> After this line, variable $args will contain one word: "get_args". +> Shell will try to execute a command or call a shell function which +> name is stored in $1, if it is assigned. If it is not, at least +> bash will complain that it can't execute command "". +> +> The proper way is to add backticks: +> +> + args=`get_args "$1"` +> +> In the second line: +> +> + for field in "$args"; do +> +> the double quotes ensure that all words in $args are +> processed as single word, all at once. So the for loop +> will be executed exactly one time, no matter how many +> arguments are given (even if there's none). +> +> So the right solution is to drop double quotes. + +Do you see any bug with the original? + +If the problem is in fact that Solaris' /bin/sh is not standards +compliant, we shouldn't fix the script but instead make sure that the +shell used to run tracetool is the compliant one. + +Am 14.09.2010 um 18:34 schrieb Blue Swirl: + +> On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <<email address hidden> +> > wrote: +>> Am 12.09.2010 um 23:05 schrieb Blue Swirl: +>> +>>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> +>>> > +>>> wrote: +>>>> +>>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>>>> +>>>>> nfields=$((nfields + 1)) +>>>> +>>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected +>>> +>>> That looks like fully standards compliant, so Solaris' /bin/sh is +>>> not. +>>> Can you try what happens with /usr/xpg4/bin/sh? +>> +>> Works fine! Must've done something wrong when testing that earlier +>> today. +>> +>> configure, create_config and tracetool with your fix are silent when +>> /usr/xpg4/bin is in the $PATH. +>> If you commit it, we can close this ticket. Thanks for your help, +>> Blue. +> +> Does /usr/xpg4/bin/sh work without the patch? + +No. + +On Tue, Sep 14, 2010 at 8:37 PM, Andreas Färber <email address hidden> wrote: +> Am 14.09.2010 um 18:34 schrieb Blue Swirl: +> +>> On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <email address hidden> +>> wrote: +>>> +>>> Am 12.09.2010 um 23:05 schrieb Blue Swirl: +>>> +>>>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> +>>>> wrote: +>>>>> +>>>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>>>>> +>>>>>> nfields=$((nfields + 1)) +>>>>> +>>>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected +>>>> +>>>> That looks like fully standards compliant, so Solaris' /bin/sh is not. +>>>> Can you try what happens with /usr/xpg4/bin/sh? +>>> +>>> Works fine! Must've done something wrong when testing that earlier today. +>>> +>>> configure, create_config and tracetool with your fix are silent when +>>> /usr/xpg4/bin is in the $PATH. +>>> If you commit it, we can close this ticket. Thanks for your help, Blue. +>> +>> Does /usr/xpg4/bin/sh work without the patch? +> +> No. + +How about with the attached patch? If yes, does it work even with /bin/sh? + + +Am 14.09.2010 um 22:53 schrieb Blue Swirl: + +> How about with the attached patch? If yes, does it work even with / +> bin/sh? + +LC_ALL=C /usr/xpg4/bin/sh ./tracetool --nop --check-backend + +works fine, + +LC_ALL=C sh ./tracetool --nop --check-backend +./tracetool: bad substitution + +The shell-based tracetool has been replace in commit 650ab98d1d9551f0ca21 with a script that has been implemented in Python, so I think we can close this bug nowadays. + diff --git a/results/classifier/zero-shot/108/permissions/638955 b/results/classifier/zero-shot/108/permissions/638955 new file mode 100644 index 000000000..092f86379 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/638955 @@ -0,0 +1,1119 @@ +permissions: 0.946 +device: 0.939 +other: 0.928 +performance: 0.919 +network: 0.919 +debug: 0.916 +KVM: 0.913 +socket: 0.898 +semantic: 0.896 +vnc: 0.887 +files: 0.886 +PID: 0.882 +boot: 0.880 +graphic: 0.874 + +emulated netcards don't work with recent sunos kernel + +hi there, + +i'm using qemu-kvm backend in version: # qemu-kvm -version +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard + +and there are just *not working any of model=$type with combinations of recent sunos (solaris, openindiana, opensolaris, ..) .. + +you can download for testing purposes iso from here: http://dlc-origin.openindiana.org/isos/147/ or from here: http://genunix.org/distributions/indiana/ << osol and oi are also bubuntu-like *live cds, so no need to bother with installing + +behaviour is as follows: +e1000 - receiving doesn't work, transmitting works .. dladm (tool for handle ethers) shows that is all ok, correct mode is loaded up, it just seems like this driver works at 100% but .. + +rtl8169|pcnet - works in 10Mbit mode with several other issues like high cpu utilization and so .. dladm is unable to recognize options for this kind of -nic + +others - just don't work + +.. i experienced this issue several times in past .. woraround was, that rtl8169 worked so-so .. with recent sunos kernel it doesn't. + +it's easy to reproduce, this is why i'm not putting here more then launching script for my virtual machine: + +# cat openindiana.sh +qemu-kvm -hda /home/kvm/openindiana/openindiana.img -m 2048 -localtime -cdrom /home/kvm/+images/oi-dev-147-x86.iso -boot d \ +-vga std -vnc :9 -k en-us -monitor unix:/home/kvm/openindiana/instance,server,nowait \ +-net nic,model=e1000,vlan=1 -net tap,ifname=oi0,script=no,vlan=1 & + +sleep 2; +ip l set oi0 up; +ip a a 192.168.99.9/24 dev oi0; + +regards by daniel + +reproduced with latest vanilla qemu-kvm .. + +i've just build it without any optimalizations like this: `./configure --prefix=$HOME/chroot/opt/qemu-kvm-0.13rc1; make` + + +(qemu) info version +info version +0.12.91 (qemu-kvm-0.13.0-rc1) + +it acts just same .. i'm trying at first to hunt down what has happend in sunos kernel .. well, i hope that we'll be able to fix it as soon as possible because it's just very miserable that we're unable to use the best (in my opinion) virtualization platform .. + +regards, daniel + +added a output from `kstat -p e1000*` .. + +call for more info if needed .. +regards by daniel + +ps. summary: everything seems fine (link statistics and so) but receiving just doesn't work .. transmitting works + +On Sat, Sep 18, 2010 at 09:43:45PM +0100, Stefan Hajnoczi wrote: +> The OpenIndiana (Solaris) e1000g driver drops frames that are too long +> or too short. It expects to receive frames of at least the Ethernet +> minimum size. ARP requests in particular are small and will be dropped +> if they are not padded appropriately, preventing a Solaris VM from +> becoming visible on the network. +> +> Signed-off-by: Stefan Hajnoczi <email address hidden> +> --- +> hw/e1000.c | 10 ++++++++++ +> 1 files changed, 10 insertions(+), 0 deletions(-) +> +> diff --git a/hw/e1000.c b/hw/e1000.c +> index 7d7d140..bc983f9 100644 +> --- a/hw/e1000.c +> +++ b/hw/e1000.c +> @@ -55,6 +55,7 @@ static int debugflags = DBGBIT(TXERR) | DBGBIT(GENERAL); +> +> #define IOPORT_SIZE 0x40 +> #define PNPMMIO_SIZE 0x20000 +> +#define MIN_BUF_SIZE 60 +> +> /* +> * HW models: +> @@ -635,10 +636,19 @@ e1000_receive(VLANClientState *nc, const uint8_t *buf, size_t size) +> uint32_t rdh_start; +> uint16_t vlan_special = 0; +> uint8_t vlan_status = 0, vlan_offset = 0; +> + uint8_t min_buf[MIN_BUF_SIZE]; +> +> if (!(s->mac_reg[RCTL] & E1000_RCTL_EN)) +> return -1; +> +> + /* Pad to minimum Ethernet frame length */ +> + if (size < sizeof(min_buf)) { +> + memcpy(min_buf, buf, size); +> + memset(&min_buf[size], 0, sizeof(min_buf) - size); +> + buf = min_buf; +> + size = sizeof(min_buf); +> + } +> + + +Hi, + +This doesn't look right. AFAIK, MAC's dont pad on receive. + +IMO this kind of padding should somehow be done by the bridge that forwards +packets into the qemu vlan (e.g slirp or the generic tap bridge). + +Cheers + +On Sun, Sep 19, 2010 at 01:18:01PM +0200, Michael S. Tsirkin wrote: +> On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: +> > On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias +> > <email address hidden> wrote: +> > > This doesn't look right. AFAIK, MAC's dont pad on receive. +> > +> > I agree. NICs that do padding will do it on transmit, not receive. +> > Anything coming in on the wire should already have the minimum length. +> > +> > In QEMU that isn't true today and that's why rtl8139, pcnet, and +> > ne2000 already do this same padding. This patch is the smallest +> > change to cover e1000. +> > +> > > IMO this kind of padding should somehow be done by the bridge that forwards +> > > packets into the qemu vlan (e.g slirp or the generic tap bridge). +> > +> > That should work and we can then drop the padding code from existing +> > NICs. I'll take a look. +> > +> > Stefan +> +> Not all nic devices have to be emulate ethernet, so not all devices want +> the padding, e.g. virtio does not. + +Right, ethernet behaviour should obviously not be applied unconditionally for +all net devices. + + +> It's also easy to imagine an +> ethernet device that strips the padding: would be silly to add it +> just to have it stripped. + +I dont beleive that is possible. The FCS comes last, so an ethernet MAC +would have to do really silly things to differentiate between padding and +real payload. + + +> If we really want to do this generically, we could implement a function dealing +> with the padding, and call it from relevant devices. + +Another way is to have network devices register their link types so that the +generic bridge can apply whatever link specific fixups that may be needed. + +I would prefer to have the padding of bridged frames decoupled from the +device models, but I cant say I feel very strongly about this. + +Cheers + +well, feel free to request whichever information you could need or consider as a helpful .. + +just for your information after ping via e1000 adapter i can see `arp -n` entry in target system and icmp packets are delivered ok. i'd like to presume that there is some little issue because e1000 driver is really just one taken from sunos kernel the best (althought that we've issue with receiving) .. all others work like trash (no statistic, no available modes, ..) + +but as i said, i have *nothing indicating a problem in logs, i already put here a kernel statistic for this driver in attachment .. + +regards, daniel + +On Mon, Sep 20, 2010 at 10:42:31AM +0200, Kevin Wolf wrote: +> Am 18.09.2010 23:12, schrieb Stefan Hajnoczi: +> > On Sat, Sep 18, 2010 at 9:57 PM, Hervé Poussineau <email address hidden> wrote: +> >> Another patch creating ARP replies at least 64 bytes long has been +> >> committed: +> >> http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=dbf3c4b4baceb91eb64d09f787cbe92d65188813 +> >> +> >> Does it fix your issue? +> > +> > No I don't think so. This is an e1000 issue, it will happen if you +> > use tap networking too. The commit you linked to only affects slirp +> > and pads its ARP code. +> > +> > I think there are two places where the minimum frame length can be enforced: +> > 1. The NIC emulation code. This is currently how rtl8139, pcnet, and +> > ne2000 do it. My patch adds the same for e1000. +> > 2. The net layer. If we're emulating Ethernet then it would be +> > possible to pad to minimum frame length in common networking code +> > (net.c). +> +> 3. The sender. I think it should be the sender's decision which packet +> he sends and there's no reason to manipulate it on its way to the guest. +> If the sender sends too short packets, this is where the bug is. + +Yes, but when using tap, the ethernet sender is QEMU itself. Tap doesn't +have the same requirements as ethernet so the original sender has no +reason to pad. + +Internally in QEMU, there is code that picks up tap packets and +forwards them to the emulated ethernet links, this is were padding +should be done IMO. Not in the device models receive path. + +The bridge that forwards frames from tap into emulated links must +also handle different kinds of link types, as all emulated network +devices are not necessarily ethernet. + +Cheers + +On Mon, Sep 20, 2010 at 10:50:40AM +0200, Kevin Wolf wrote: +> Am 19.09.2010 08:36, schrieb Stefan Hajnoczi: +> > On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias +> > <email address hidden> wrote: +> >> This doesn't look right. AFAIK, MAC's dont pad on receive. +> > +> > I agree. NICs that do padding will do it on transmit, not receive. +> > Anything coming in on the wire should already have the minimum length. +> > +> > In QEMU that isn't true today and that's why rtl8139, pcnet, and +> > ne2000 already do this same padding. This patch is the smallest +> > change to cover e1000. +> +> What's the reason that it isn't true in QEMU today? Shouldn't we fix +> these problems rather than making device emulations incorrect to +> compensate for it? + +Yes we should, I agree. + +Cheers + +Daniel, +Does the following qemu.git patch solve the problem? +http://patchwork.ozlabs.org/patch/65137/raw/ + +Sorry about the partially mirrored mailing list thread. I expected Launchpad to show the entire discussion but it seems to whitelist only registered users' emails. + +Stefan + +On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote: +> On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: +> +>> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias +>> <email address hidden> wrote: +>> +>>> This doesn't look right. AFAIK, MAC's dont pad on receive. +>>> +>> I agree. NICs that do padding will do it on transmit, not receive. +>> Anything coming in on the wire should already have the minimum length. +>> +> QEMU never gets access to the wire. +> Our APIs do not really pass complete ethernet packets: +> we forward packets without checksum and padding. +> +> I think it makes complete sense to keep this and +> handle padding in devices because we +> have devices that pass the frame to guest without padding and checksum. +> It should be easy to replace padding code in devices that +> need it with some kind of macro. +> + +Would this not also address the problem? It sounds like the root cause +is the tap code, not the devices.. + +Regards, + +Anthony Liguori + +> +>> In QEMU that isn't true today and that's why rtl8139, pcnet, and +>> ne2000 already do this same padding. This patch is the smallest +>> change to cover e1000. +>> +>> +>>> IMO this kind of padding should somehow be done by the bridge that forwards +>>> packets into the qemu vlan (e.g slirp or the generic tap bridge). +>>> +>> That should work and we can then drop the padding code from existing +>> NICs. I'll take a look. +>> +>> Stefan +>> +> + + + +On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote: +> On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote: +> > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: +> > +> >> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias +> >> <email address hidden> wrote: +> >> +> >>> This doesn't look right. AFAIK, MAC's dont pad on receive. +> >>> +> >> I agree. NICs that do padding will do it on transmit, not receive. +> >> Anything coming in on the wire should already have the minimum length. +> >> +> > QEMU never gets access to the wire. +> > Our APIs do not really pass complete ethernet packets: +> > we forward packets without checksum and padding. +> > +> > I think it makes complete sense to keep this and +> > handle padding in devices because we +> > have devices that pass the frame to guest without padding and checksum. +> > It should be easy to replace padding code in devices that +> > need it with some kind of macro. +> > +> +> Would this not also address the problem? It sounds like the root cause +> is the tap code, not the devices.. +> +> Regards, +> +> Anthony Liguori +> +> > +> >> In QEMU that isn't true today and that's why rtl8139, pcnet, and +> >> ne2000 already do this same padding. This patch is the smallest +> >> change to cover e1000. +> >> +> >> +> >>> IMO this kind of padding should somehow be done by the bridge that forwards +> >>> packets into the qemu vlan (e.g slirp or the generic tap bridge). +> >>> +> >> That should work and we can then drop the padding code from existing +> >> NICs. I'll take a look. +> >> +> >> Stefan +> >> +> > +> + +> From f77c3143f3fbefdfa2f0cc873c2665b5aa78e8c9 Mon Sep 17 00:00:00 2001 +> From: Anthony Liguori <email address hidden> +> Date: Mon, 20 Sep 2010 15:29:31 -0500 +> Subject: [PATCH] tap: make sure packets are at least 40 bytes long +> +> This is required by ethernet drivers but not enforced in the Linux tap code so +> we need to fix it up ourselves. + + +This enforces ethernet semantics on the internal links (which is probably +not good), but it's IMO much better than changing the devices. It also +moves the workaround closer to the root of the problem. IMO, it's a step +in the right direction. + +Acked-by: Edgar E. Iglesias <email address hidden> + + +> Signed-off-by: Anthony Liguori <email address hidden> +> +> diff --git a/net/tap.c b/net/tap.c +> index 4afb314..822241a 100644 +> --- a/net/tap.c +> +++ b/net/tap.c +> @@ -179,7 +179,13 @@ static int tap_can_send(void *opaque) +> #ifndef __sun__ +> ssize_t tap_read_packet(int tapfd, uint8_t *buf, int maxlen) +> { +> - return read(tapfd, buf, maxlen); +> + ssize_t len; +> + +> + len = read(tapfd, buf, maxlen); +> + if (len > 0) { +> + len = MAX(MIN(maxlen, 40), len); +> + } +> + return len; +> } +> #endif +> +> -- +> 1.7.0.4 +> + + +On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote: +> On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote: +> > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: +> > +> >> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias +> >> <email address hidden> wrote: +> >> +> >>> This doesn't look right. AFAIK, MAC's dont pad on receive. +> >>> +> >> I agree. NICs that do padding will do it on transmit, not receive. +> >> Anything coming in on the wire should already have the minimum length. +> >> +> > QEMU never gets access to the wire. +> > Our APIs do not really pass complete ethernet packets: +> > we forward packets without checksum and padding. +> > +> > I think it makes complete sense to keep this and +> > handle padding in devices because we +> > have devices that pass the frame to guest without padding and checksum. +> > It should be easy to replace padding code in devices that +> > need it with some kind of macro. +> > +> +> Would this not also address the problem? It sounds like the root cause +> is the tap code, not the devices.. +> +> Regards, +> +> Anthony Liguori +> +> > +> >> In QEMU that isn't true today and that's why rtl8139, pcnet, and +> >> ne2000 already do this same padding. This patch is the smallest +> >> change to cover e1000. +> >> +> >> +> >>> IMO this kind of padding should somehow be done by the bridge that forwards +> >>> packets into the qemu vlan (e.g slirp or the generic tap bridge). +> >>> +> >> That should work and we can then drop the padding code from existing +> >> NICs. I'll take a look. +> >> +> >> Stefan +> >> +> > +> + +> From f77c3143f3fbefdfa2f0cc873c2665b5aa78e8c9 Mon Sep 17 00:00:00 2001 +> From: Anthony Liguori <email address hidden> +> Date: Mon, 20 Sep 2010 15:29:31 -0500 +> Subject: [PATCH] tap: make sure packets are at least 40 bytes long +> +> This is required by ethernet drivers but not enforced in the Linux tap code so +> we need to fix it up ourselves. +> +> Signed-off-by: Anthony Liguori <email address hidden> +> +> diff --git a/net/tap.c b/net/tap.c +> index 4afb314..822241a 100644 +> --- a/net/tap.c +> +++ b/net/tap.c +> @@ -179,7 +179,13 @@ static int tap_can_send(void *opaque) +> #ifndef __sun__ +> ssize_t tap_read_packet(int tapfd, uint8_t *buf, int maxlen) +> { +> - return read(tapfd, buf, maxlen); +> + ssize_t len; +> + +> + len = read(tapfd, buf, maxlen); +> + if (len > 0) { +> + len = MAX(MIN(maxlen, 40), len); + + +A small detail :) +40 -> 64 (including a dummy FCS). + + +> + } +> + return len; +> } +> #endif +> +> -- +> 1.7.0.4 +> + + +On 09/20/2010 03:44 PM, Michael S. Tsirkin wrote: +>>> From f77c3143f3fbefdfa2f0cc873c2665b5aa78e8c9 Mon Sep 17 00:00:00 2001 +>>> From: Anthony Liguori<email address hidden> +>>> Date: Mon, 20 Sep 2010 15:29:31 -0500 +>>> Subject: [PATCH] tap: make sure packets are at least 40 bytes long +>>> +>>> This is required by ethernet drivers but not enforced in the Linux tap code so +>>> we need to fix it up ourselves. +>>> +>> +>> This enforces ethernet semantics on the internal links (which is probably +>> not good), +>> +> Plus plus ungood. +> When we do add e.g. ipoib support, we'll have to go and hunt these bugs down again. +> Also will make it impossible to implement any devices that pass in guest buffers +> without FCS and padding. +> + +That's actually a good point which strongly is in favor of making the +devices do the padding themselves. + +Regards, + +Anthony Liguori + + +On Mon, Sep 20, 2010 at 10:44:34PM +0200, Michael S. Tsirkin wrote: +> On Mon, Sep 20, 2010 at 10:40:35PM +0200, Edgar E. Iglesias wrote: +> > On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote: +> > > On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote: +> > > > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: +> > > > +> > > >> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias +> > > >> <email address hidden> wrote: +> > > >> +> > > >>> This doesn't look right. AFAIK, MAC's dont pad on receive. +> > > >>> +> > > >> I agree. NICs that do padding will do it on transmit, not receive. +> > > >> Anything coming in on the wire should already have the minimum length. +> > > >> +> > > > QEMU never gets access to the wire. +> > > > Our APIs do not really pass complete ethernet packets: +> > > > we forward packets without checksum and padding. +> > > > +> > > > I think it makes complete sense to keep this and +> > > > handle padding in devices because we +> > > > have devices that pass the frame to guest without padding and checksum. +> > > > It should be easy to replace padding code in devices that +> > > > need it with some kind of macro. +> > > > +> > > +> > > Would this not also address the problem? It sounds like the root cause +> > > is the tap code, not the devices.. +> > > +> > > Regards, +> > > +> > > Anthony Liguori +> > > +> > > > +> > > >> In QEMU that isn't true today and that's why rtl8139, pcnet, and +> > > >> ne2000 already do this same padding. This patch is the smallest +> > > >> change to cover e1000. +> > > >> +> > > >> +> > > >>> IMO this kind of padding should somehow be done by the bridge that forwards +> > > >>> packets into the qemu vlan (e.g slirp or the generic tap bridge). +> > > >>> +> > > >> That should work and we can then drop the padding code from existing +> > > >> NICs. I'll take a look. +> > > >> +> > > >> Stefan +> > > >> +> > > > +> > > +> > +> > > From f77c3143f3fbefdfa2f0cc873c2665b5aa78e8c9 Mon Sep 17 00:00:00 2001 +> > > From: Anthony Liguori <email address hidden> +> > > Date: Mon, 20 Sep 2010 15:29:31 -0500 +> > > Subject: [PATCH] tap: make sure packets are at least 40 bytes long +> > > +> > > This is required by ethernet drivers but not enforced in the Linux tap code so +> > > we need to fix it up ourselves. +> > +> > +> > This enforces ethernet semantics on the internal links (which is probably +> > not good), +> +> Plus plus ungood. +> When we do add e.g. ipoib support, we'll have to go and hunt these bugs down again. +> Also will make it impossible to implement any devices that pass in guest buffers +> without FCS and padding. + +If we dont remove the padding from the device models rx paths, we +will continue with code that relies on it and it is IMO wrong. +Ethernet MAC's don't padd nor append checksum on receive. + +I agree with you that it's not great that the internal link +protocol has to be strictly ethernet but it seems to me like +if that is reality today, with or without Anthonys patch. +slirp and tap both require ethernet semantics (except possibly +padding and FCS). The addressing and packet headers are ethernet. + +In the long run, I'd rather see a more flexible internal interconnect +that supports mutiple heterogenous link types. In the meantime, I +think Anthonys patch is a better workaround than patching the +device models. + +> > but it's IMO much better than changing the devices. +> +> How much better? + +OK, s/much better/better/ :) + +> +> > It also +> > moves the workaround closer to the root of the problem. +> > IMO, it's a step in the right direction. +> > +> > Acked-by: Edgar E. Iglesias <email address hidden> +> > +> > +> > > Signed-off-by: Anthony Liguori <email address hidden> +> > > +> > > diff --git a/net/tap.c b/net/tap.c +> > > index 4afb314..822241a 100644 +> > > --- a/net/tap.c +> > > +++ b/net/tap.c +> > > @@ -179,7 +179,13 @@ static int tap_can_send(void *opaque) +> > > #ifndef __sun__ +> > > ssize_t tap_read_packet(int tapfd, uint8_t *buf, int maxlen) +> > > { +> > > - return read(tapfd, buf, maxlen); +> > > + ssize_t len; +> > > + +> > > + len = read(tapfd, buf, maxlen); +> > > + if (len > 0) { +> > > + len = MAX(MIN(maxlen, 40), len); +> > > + } +> +> Let's at least add a comment explaining what does this do? +> Also - does tcp backend need this as well? Other backends? + +A comment sounds good. + +Cheers, +Edgar + + +http://patchwork.ozlabs.org/patch/65137/raw/ + +well, this *fixed a issue .. it's very good that we (sunos guys) can now use the best virt platform (kvm - IMO) .. + +regards and thanks folks +ave, daniel + +On Mon, Sep 20, 2010 at 9:31 PM, Anthony Liguori <email address hidden> wrote: +> On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote: +>> +>> On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: +>> +>>> +>>> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias +>>> <email address hidden> wrote: +>>> +>>>> +>>>> This doesn't look right. AFAIK, MAC's dont pad on receive. +>>>> +>>> +>>> I agree. NICs that do padding will do it on transmit, not receive. +>>> Anything coming in on the wire should already have the minimum length. +>>> +>> +>> QEMU never gets access to the wire. +>> Our APIs do not really pass complete ethernet packets: +>> we forward packets without checksum and padding. +>> +>> I think it makes complete sense to keep this and +>> handle padding in devices because we +>> have devices that pass the frame to guest without padding and checksum. +>> It should be easy to replace padding code in devices that +>> need it with some kind of macro. +>> +> +> Would this not also address the problem? It sounds like the root cause is +> the tap code, not the devices.. + +This won't work when s->has_vnet_hdr is 1 because the virtio-net +header consumes buffer space and reduces the amount we pad. The +padding size should be 60 + (s->has_vnet_hdr ? sizeof(struct +virtio_net_hdr) : 0). + +Adjusting the length without clearing the untouched buffer space is +probably fine. I'm trying to think of a scenario where this becomes +an information leak (security issue). Perhaps if the guest has vlans +enabled and allows different users to sniff traffic only on their +vlans? Then you may be able to read part of another vlan's traffic by +sending short packets to your vlan and gathering the padding data. +This is pretty contrived but doing a <60 byte memset would prevent the +issue for sure. + +Stefan + +On Tue, Sep 21, 2010 at 11:17:07AM +0200, Michael S. Tsirkin wrote: +> On Mon, Sep 20, 2010 at 10:51:36PM +0200, Edgar E. Iglesias wrote: +> > On Mon, Sep 20, 2010 at 03:31:32PM -0500, Anthony Liguori wrote: +> > > On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote: +> > > > On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: +> > > > +> > > >> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias +> > > >> <email address hidden> wrote: +> > > >> +> > > >>> This doesn't look right. AFAIK, MAC's dont pad on receive. +> > > >>> +> > > >> I agree. NICs that do padding will do it on transmit, not receive. +> > > >> Anything coming in on the wire should already have the minimum length. +> > > >> +> > > > QEMU never gets access to the wire. +> > > > Our APIs do not really pass complete ethernet packets: +> > > > we forward packets without checksum and padding. +> > > > +> > > > I think it makes complete sense to keep this and +> > > > handle padding in devices because we +> > > > have devices that pass the frame to guest without padding and checksum. +> > > > It should be easy to replace padding code in devices that +> > > > need it with some kind of macro. +> > > > +> > > +> > > Would this not also address the problem? It sounds like the root cause +> > > is the tap code, not the devices.. +> > > +> > > Regards, +> > > +> > > Anthony Liguori +> > > +> > > > +> > > >> In QEMU that isn't true today and that's why rtl8139, pcnet, and +> > > >> ne2000 already do this same padding. This patch is the smallest +> > > >> change to cover e1000. +> > > >> +> > > >> +> > > >>> IMO this kind of padding should somehow be done by the bridge that forwards +> > > >>> packets into the qemu vlan (e.g slirp or the generic tap bridge). +> > > >>> +> > > >> That should work and we can then drop the padding code from existing +> > > >> NICs. I'll take a look. +> > > >> +> > > >> Stefan +> > > >> +> > > > +> > > +> > +> > > From f77c3143f3fbefdfa2f0cc873c2665b5aa78e8c9 Mon Sep 17 00:00:00 2001 +> > > From: Anthony Liguori <email address hidden> +> > > Date: Mon, 20 Sep 2010 15:29:31 -0500 +> > > Subject: [PATCH] tap: make sure packets are at least 40 bytes long +> > > +> > > This is required by ethernet drivers but not enforced in the Linux tap code so +> > > we need to fix it up ourselves. +> > > +> > > Signed-off-by: Anthony Liguori <email address hidden> +> > > +> > > diff --git a/net/tap.c b/net/tap.c +> > > index 4afb314..822241a 100644 +> > > --- a/net/tap.c +> > > +++ b/net/tap.c +> > > @@ -179,7 +179,13 @@ static int tap_can_send(void *opaque) +> > > #ifndef __sun__ +> > > ssize_t tap_read_packet(int tapfd, uint8_t *buf, int maxlen) +> > > { +> > > - return read(tapfd, buf, maxlen); +> > > + ssize_t len; +> > > + +> > > + len = read(tapfd, buf, maxlen); +> > > + if (len > 0) { +> > > + len = MAX(MIN(maxlen, 40), len); +> > +> > +> > A small detail :) +> > 40 -> 64 (including a dummy FCS). +> +> I don't think so: e1000 at least has code to tack the FCS on, +> so we'll end up with a 68 bytes. + +And at the moment e1000 also has padding, both padding +and FCS appending should go away from ethernet models before +this goes in. + +Anyway, if you guys maintaining the networking parts are in +agreement that padding and FCS appending should be done in +the device models (at least for the moment), I'll accept +that and back-off. In that case, I think your suggestion +of hiding things behind some kind of generic macro or +function would be good. At least it will clarify things. + +Cheers + +well, i did some more investigations and here come a results .. + +this patch http://patchwork.ozlabs.org/patch/65137/raw/ solves problem partially .. NICs are working with that but after a deeper look, connection is lost when the netstack is flooded with higher traffic .. + +i can connect with ssh|telnet from qemu-kvm host to sunos machines, but when i type dmesg for example (or anything else which does for a moment a higher traffic), the connection freezes .. + +when i bind both tap ifaces under one bridge, access each machine via theirs /dev/console, conection to neighboring guest seems like works as expected, so this issue only affects connection between kvm host and guests .. + +sorry for my very plain description of problem, but it's again easy to reproduce .. + +so once more in short: + +two machines with following settings: +-net nic,model=e1000,macaddr="00:50:56:ba:5e:74",vlan=1 \ +-net tap,ifname=oi0,script=no,vlan=1 & ## openindiana + +-net nic,model=e1000,macaddr="00:50:56:ba:6e:74",vlan=1 \ +-net tap,ifname=solaris0,script=no,vlan=1 & ## solaris + +1) ping over directly assigned address on oi0|solaris0 works, connection is lost when invoked higher trafic aka - ssh|telnet in there and then typed dmesg command or whatever else which floods /dev/stdin and invokes due to the that higher traffic + +2) when created bridge (brctl addbr br0; brctl addif br0 oi0 solaris0) and assigned address it behaves same way with exception, that when used /dev/console on each of them for connection to second machine, netstack seems like working there okay .. + +regards, daniel + +On Sat, Oct 2, 2010 at 8:23 PM, daniel pecka <email address hidden> wrote: +> well, i did some more investigations and here come a results .. +> +> this patch http://patchwork.ozlabs.org/patch/65137/raw/ solves problem +> partially .. NICs are working with that but after a deeper look, +> connection is lost when the netstack is flooded with higher traffic .. + +I haven't looked more into this but noticed an e1000 patch from +Anthony Perard which may improve the Solaris experience: +http://patchwork.ozlabs.org/patch/67594/ + +Stefan + +is this issue dead ?? can i do something for help to fix it? + +regards, daniel + +On Mon, Jan 3, 2011 at 1:40 PM, daniel pecka <email address hidden> wrote: +> is this issue dead ?? can i do something for help to fix it? + +I believe no one has investigated this issue since my last comment. +Someone with time and interest in Solaris needs to step up to debug +this problem. + +DTrace inside the guest and QEMU tracing (see docs/tracing.txt) are +good tools for figuring out what is going on in the Solaris device +driver and QEMU's hardware emulation, respectively. + +If you know a previous QEMU version where a network device works under +Solaris you could use git-bisect(1) to find the commit that broke +Solaris. From what you've said though, it seems the issue is with new +Solaris kernels rather than changes in QEMU. + +Stefan + +okay Stefan .. + +thanks, i poked several people and trying to learn up how netstack works .. i have no experience with programming drivers .. i hope that we'll fix it soon cuz it's very bad that we're unable to use kvm|qemu + +regards, daniel + +Hi Daniel, + +I just tried a newer version of the indiana iso image +(http://dlc-origin.openindiana.org/isos/148/oi-dev-148-x86.iso) with +latest qemu (not qemu-kvm) on a debian amd64 linux host, and I had no problems +with networking (ssh from qemu's emulated indiana host to physical linux host). + +Tested with e1000 and i82559c, both work. + +Does the error only occur with the older iso image? +Or is it caused by qemu-kvm? + +Regards, +Stefan + +I can confirm this. Just spent hours studying my network configuration in OpenIndiana b148 running in Qemu KVM and figuring out what's wrong... Everything's OK, network is up but I won't even ping the gateway. +Please fix this soon! + + +Hi all, +I can confirm this bug, +on latest openindiana-148 and qemu-kvm 0.13.0 you cannot even ping the virtualization host. +With qemu-kvm-0.14.0 (just released!) you CAN ping the host: this is already an improvement. +HOWEVER +biggest bug is still there: if you log in to the openindiana machine via ssh and do "dmesg" or "netstat" or some other command which ouptuts a lot of text, the tcp socket will hang (well say it hangs once every 3 attempts) forever. + +Going with tcpdump -e from within the guest, I have identified that the problem is when a big enough packet is outputed. +I tried a few times with dmesg, and as soon as the tcp packet reaches the following length: + +18:38:28.340097 52:54:69:b5:89:11 (oui Unknown) > 00:19:b9:81:2c:52 (oui Unknown), ethertype IPv4 (0x0800), length 1514: 192.168.7.38.ssh > 192.168.7.52.59008: Flags [.], ack 2824, win 64436, options [nop,nop,TS val 27488132 ecr 6063255], length 1448 + +it cannot get through. Then the IP stack tries and retries to send the same identical packet, but there will never be any reply from the other side. Finally the socket is torn down. + +I have bridged networking for the VM. My bridge is a normal linux bridge br0 with MTU 1500. +Has MTU anything to do with all this? +Is it a linux-bridge bug or a qemu-kvm bug? + +Please fix this, solaris is important for its ZFS. +Thank you + +On Mon, Feb 28, 2011 at 7:06 PM, geppz <email address hidden> wrote: +> Going with tcpdump -e from within the guest, I have identified that the problem is when a big enough packet is outputed. +> I tried a few times with dmesg, and as soon as the tcp packet reaches the following length: +> +> 18:38:28.340097 52:54:69:b5:89:11 (oui Unknown) > 00:19:b9:81:2c:52 (oui +> Unknown), ethertype IPv4 (0x0800), length 1514: 192.168.7.38.ssh > +> 192.168.7.52.59008: Flags [.], ack 2824, win 64436, options [nop,nop,TS +> val 27488132 ecr 6063255], length 1448 +> +> it cannot get through. Then the IP stack tries and retries to send the +> same identical packet, but there will never be any reply from the other +> side. Finally the socket is torn down. +> +> I have bridged networking for the VM. My bridge is a normal linux bridge br0 with MTU 1500. +> Has MTU anything to do with all this? +> Is it a linux-bridge bug or a qemu-kvm bug? + +Excellent, thanks for posting these details. The bug is probably in +the NIC hardware emulation and I think we can track this one down +fairly easily. + +Can you please post your qemu-kvm command-line including the NIC model +that you are using? + +Stefan + + +Emulated NIC is e1000. + +I found out that if one reduces the MTU on the client like "ifconfig eth0 mtu 300" it seems ssh hangs much more rarely (but still hangs, at 300). +Reducing it on the virtualization host bridge is not enough though (unless you are initiating ssh from the virtualization host itself) +To trigger the hang, do: +while true ; do dmesg ; done +The higher the allowed MTU, the quicker the hang, e.g. MTU 500 hangs within one minute. 1500 hangs instantly. + + +Command line is the following. Excuse the length... it's a libvirt + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/local/qemu-kvm-0.14.0/bin/qemu-system-x86_64 -S -M pc-0.14 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name openindiana1 -uuid ed0b8483-d186-1f39-39ef-97194a1f02bf -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/openindiana1.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -no-acpi -boot c -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/mapper/datavg1-openindiana1,if=none,id=drive-ide0-0-0,boot=on,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=54,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:69:b5:89:11,bus=pci.0,addr=0x3 -usb -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 + +I'm available to try patches for a while if somebody can spot the problem... the host is still not in production. + +Thanks for your work + +I was able to reproduce this problem with qemu.git running OpenIndiana 148 with tap and bridge on the host. I did not see an issue with the userspace network stack - seems to manifest itself as a checksum error in transmitted packets. + +Here is the host tcpdump during a TCP stall with mtu 1500: + +19:47:54.601950 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [P.], seq 6949:7509, ack 3545, win 64436, options [nop,nop,TS val 24455 ecr 111832709], length 560 +19:47:54.601966 IP 192.168.122.1.40611 > 192.168.122.33.22: Flags [.], ack 7509, win 163, options [nop,nop,TS val 111832710 ecr 24455], length 0 +19:47:54.602312 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [P.], seq 7509:8069, ack 3545, win 64436, options [nop,nop,TS val 24455 ecr 111832709], length 560 +19:47:54.602325 IP 192.168.122.1.40611 > 192.168.122.33.22: Flags [.], ack 8069, win 171, options [nop,nop,TS val 111832710 ecr 24455], length 0 + +Everything went fine up to here but now the stall shows up... + +19:47:54.602594 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [P.], seq 8069:8629, ack 3545, win 64436, options [nop,nop,TS val 24455 ecr 111832709], length 560 +19:47:54.602831 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [P.], seq 8629:9189, ack 3545, win 64436, options [nop,nop,TS val 24455 ecr 111832709], length 560 +19:47:54.602847 IP 192.168.122.1.40611 > 192.168.122.33.22: Flags [.], ack 8069, win 171, options [nop,nop,TS val 111832710 ecr 24455,nop,nop,sack 1 {8629:9189}], length 0 + +Notice that only seq up to 8069 was acked by the host and this is a duplicate ack. I think it's prodding the guest to transmit from 8069 again. + +19:47:54.603447 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [P.], seq 9189:9749, ack 3545, win 64436, options [nop,nop,TS val 24456 ecr 111832710], length 560 +19:47:54.603459 IP 192.168.122.1.40611 > 192.168.122.33.22: Flags [.], ack 8069, win 171, options [nop,nop,TS val 111832710 ecr 24455,nop,nop,sack 1 {8629:9749}], length 0 +19:47:54.603734 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [P.], seq 9749:10309, ack 3545, win 64436, options [nop,nop,TS val 24456 ecr 111832710], length 560 +19:47:54.603751 IP 192.168.122.1.40611 > 192.168.122.33.22: Flags [.], ack 8069, win 171, options [nop,nop,TS val 111832710 ecr 24455,nop,nop,sack 1 {8629:10309}], length 0 +19:47:54.603882 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [P.], seq 8069:8629, ack 3545, win 64436, options [nop,nop,TS val 24456 ecr 111832710], length 560 +19:47:55.021608 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [.], seq 8069:9517, ack 3545, win 64436, options [nop,nop,TS val 24498 ecr 111832710], length 1448 +19:47:55.578667 STP 802.1d, Config, Flags [none], bridge-id 8000.da:7b:46:27:8c:aa.8001, length 35 +19:47:55.851350 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [.], seq 8069:9517, ack 3545, win 64436, options [nop,nop,TS val 24581 ecr 111832710], length 1448 +19:47:57.577496 STP 802.1d, Config, Flags [none], bridge-id 8000.da:7b:46:27:8c:aa.8001, length 35 +19:47:57.625504 IP 192.168.122.33.22 > 192.168.122.1.40611: Flags [.], seq 8069:9517, ack 3545, win 64436, options [nop,nop,TS val 24745 ecr 111832710], length 1448 + +Resends and more duplicate acks up to 8069. The host is not responding to the guest transmitted packets. Wireshark shows checksum errors for guest transmitted frames when the stall occurs. + +I added instrumentation to hw/e1000.c and get the following information about transmitted frames: + +tp 0x7fd6a8eef3a0 frames 0 size 626 vlan_needed 0 sum_needed 0x3 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0xdcf7 +tp 0x7fd6a8eef3a0 frames 0 size 626 vlan_needed 0 sum_needed 0x3 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0xde66 +tp 0x7fd6a8eef3a0 frames 0 size 626 vlan_needed 0 sum_needed 0 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0x77ca +tp 0x7fd6a8eef3a0 frames 0 size 626 vlan_needed 0 sum_needed 0x3 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0xf7a1 +tp 0x7fd6a8eef3a0 frames 0 size 626 vlan_needed 0 sum_needed 0x3 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0xfe9d +tp 0x7fd6a8eef3a0 frames 0 size 626 vlan_needed 0 sum_needed 0x3 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0x50b9 +tp 0x7fd6a8eef3a0 frames 0 size 626 vlan_needed 0 sum_needed 0 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0x77ca +tp 0x7fd6a8eef3a0 frames 0 size 1514 vlan_needed 0 sum_needed 0 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0x7b42 +tp 0x7fd6a8eef3a0 frames 0 size 1514 vlan_needed 0 sum_needed 0 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0x7b42 +tp 0x7fd6a8eef3a0 frames 0 size 1514 vlan_needed 0 sum_needed 0 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0x7b42 +tp 0x7fd6a8eef3a0 frames 0 size 1514 vlan_needed 0 sum_needed 0 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0x7b42 +tp 0x7fd6a8eef3a0 frames 0 size 1514 vlan_needed 0 sum_needed 0 ip 0 tcp 0 +tucso 0x32 tcp/udp checksum 0x7b42 + +Perhaps there is a e1000 emulation bug here that causes us to miss the sum_needed bits and an invalid checksum ends up being transmitted. Need to investigate this more. + +Here is the patch in case you want to confirm my results so far: +http://repo.or.cz/w/qemu/stefanha.git/commitdiff/fa963c73b254af2e43a9a45ff5cceb2c42519f55 + +Please test this patch: +http://repo.or.cz/w/qemu/stefanha.git/commitdiff/c405d1b66e045bce1c53a30f9ad840c6f19eca57 + +QEMU loads checksum offload flags from every tx data descriptor. When a +multi-descriptor packet is sent, Solaris will only mark the first +descriptor with checksum offload flags. Therefore QEMU fails to perform +checksum offload resulting in corrupted packets that will be discarded +by the receiver. + +I'll try to come up with a proper fix that can be submitted to QEMU. + +The PCI/PCI-X Family of Gigabit Ethernet Controllers Software +Developer’s Manual states the following about the POPTS field: + + Provides a number of options which control the handling of this + packet. This field is ignored except on the first data descriptor of + a packet. + +The current implementation always loads the field and its checksum +offload flags. This patch uses only the first descriptor's POPTS field +in order to comply with the specification. + +When Solaris sends multi-descriptor packets it fills in POPTS for the +first descriptor only. Therefore this patch is necessary in order to +perform checksum offload correctly for multi-descriptor packets. + +Reported-by: Daniel Pecka <email address hidden> +Reported-by: geppz <email address hidden> +Signed-off-by: Stefan Hajnoczi <email address hidden> +--- + hw/e1000.c | 4 +++- + 1 files changed, 3 insertions(+), 1 deletions(-) + +diff --git a/hw/e1000.c b/hw/e1000.c +index 0a4574c..2a4d5c7 100644 +--- a/hw/e1000.c ++++ b/hw/e1000.c +@@ -446,7 +446,9 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp) + return; + } else if (dtype == (E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D)) { + // data descriptor +- tp->sum_needed = le32_to_cpu(dp->upper.data) >> 8; ++ if (tp->size == 0) { ++ tp->sum_needed = le32_to_cpu(dp->upper.data) >> 8; ++ } + tp->cptse = ( txd_lower & E1000_TXD_CMD_TSE ) ? 1 : 0; + } else { + // legacy descriptor +-- +1.7.2.3 + + + +Stefan, thanks for your work. + +I tested your patch in comment #29 and it does seem to solve the problem for me for latest openindiana and also for latest nexenta core. + +Also I checked vanilla rtl8139 and it seems to work for openindiana on qemu-kvm-0.14.0 (with 0.13.0 I think I had problems). + +Thanks for putting me as reported-by on the patch, but that's not my real name or address I'd like to be on the patch... actually I thought I had set launchpad to keep me anonymous and keep email address hidden (where's that option now...) + +I have just sent an email at your linux.vnet address with real data. If you can, please use that during official submission of the patch. Thank you. + +The PCI/PCI-X Family of Gigabit Ethernet Controllers Software +Developer’s Manual states the following about the POPTS field: + + Provides a number of options which control the handling of this + packet. This field is ignored except on the first data descriptor of + a packet. + +The current implementation always loads the field and its checksum +offload flags. This patch uses only the first descriptor's POPTS field +in order to comply with the specification. + +When Solaris sends multi-descriptor packets it fills in POPTS for the +first descriptor only. Therefore this patch is necessary in order to +perform checksum offload correctly for multi-descriptor packets. + +Reported-by: Daniel Pecka <email address hidden> +Reported-by: Gabriele A. Trombetti <email address hidden> +Signed-off-by: Stefan Hajnoczi <email address hidden> +--- +v2: + * Fix Reported-by: details + + hw/e1000.c | 4 +++- + 1 files changed, 3 insertions(+), 1 deletions(-) + +diff --git a/hw/e1000.c b/hw/e1000.c +index 0a4574c..2a4d5c7 100644 +--- a/hw/e1000.c ++++ b/hw/e1000.c +@@ -446,7 +446,9 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp) + return; + } else if (dtype == (E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D)) { + // data descriptor +- tp->sum_needed = le32_to_cpu(dp->upper.data) >> 8; ++ if (tp->size == 0) { ++ tp->sum_needed = le32_to_cpu(dp->upper.data) >> 8; ++ } + tp->cptse = ( txd_lower & E1000_TXD_CMD_TSE ) ? 1 : 0; + } else { + // legacy descriptor +-- +1.7.2.3 + + + +I have this problem (as describe in OP) on a Solaris 11.2 install using the text iso. Archlinux Qemu 2.1.0. It appears that the above patch has been applied to qemu for some time now (its also in my version). + +Are there any new workarounds? + +On Sun, Oct 5, 2014 at 9:57 PM, dblade <email address hidden> wrote: +> I have this problem (as describe in OP) on a Solaris 11.2 install using +> the text iso. Archlinux Qemu 2.1.0. It appears that the above patch +> has been applied to qemu for some time now (its also in my version). +> +> Are there any new workarounds? + +Hi, +It's been a long time since that fix was developed. + +At this point it would be necessary to debug the problem from scratch. +I don't have time to work on this in the near future, sorry. + +Maybe someone else wants to figure out what is wrong. + +Stefan + + +apparently it has something to do with x2apic. simply refining my cpu line to be -cpu kvm64,-x2apic leads to a working network. + +source of inspiration: http://forum.proxmox.com/threads/15850-Solaris-10-Guest-no-network-traffic-after-upgrade-to-proxmox-3-1 + + + + +See also bug #1395217 + +See the following bug report for a working Solaris 10 KVM guest configuration: +https://bugzilla.redhat.com/show_bug.cgi?id=1262093 + +Based on comment #30, it sounds like the original problem of this bug has been fixed, and since the remaining apic-related problem is tracked in ticket #1395217 already, I think we can close this bug now (if you don't agree, feel free to open this ticket again). + diff --git a/results/classifier/zero-shot/108/permissions/648128 b/results/classifier/zero-shot/108/permissions/648128 new file mode 100644 index 000000000..b0af3a15e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/648128 @@ -0,0 +1,240 @@ +permissions: 0.963 +debug: 0.962 +graphic: 0.960 +other: 0.960 +semantic: 0.949 +socket: 0.945 +files: 0.943 +device: 0.942 +boot: 0.941 +performance: 0.940 +PID: 0.937 +network: 0.929 +vnc: 0.926 +KVM: 0.891 + +VirtFS: Cannot mount 9p during boot + +I use as client Debian squeeze i386 with a custom kernel: +Linux (none) 2.6.35.5 #3 Thu Sep 23 18:36:02 UTC 2010 i686 GNU/Linux + +And as host Debian squeeze amd64 +Linux asd 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux + +kvm version is: +kvm-88-5908-gdd67374 + +Started the client using: +sudo /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -kernel linux-2.6.35.5.qemu -drive file=root.img,if=virtio -net nic,macaddr=02:ca:ff:ee:ba:be,model=virtio,vlan=1 -net tap,ifname=tap1,vlan=1,script=no -virtfs local,path=/host,security_model=passthrough,mount_tag=host -nographic + +I noticed that I cannot mount it (mapped or passthrough) using /etc/rc.local or /etc/fstab, but after login as root using + +mount /mnt + +or + +mount -t 9p -o trans=virtio host /mnt + +(the same stuff i tried inside /etc/rc.local) + +The only output on a failed mount in rc.local/fstab I get is + +[ 15.035920] device: '9p-1': device_add +[ 15.038180] 9p: no channels available +[ 15.038937] device: '9p-1': device_unregister +[ 15.049123] device: '9p-1': device_create_release + +The stuff in /etc/fstab is: +host /mnt 9p trans=virtio 0 0 + + + +I intercepted the boot by adding `set -v; set +e; mount -t 9p -o trans=virtio host_share /mnt; /bin/sh` on top of my /etc/rc.local: +... but than it works quite well... well that is not what I expected. So I changed it to `set -v; mount /mnt || true; /bin/sh`.. and then it doesn't work anymore... mysterios but hey, did you notice that the share is actually called host and not host_share as I wrote inside the rc.local. So why does it work at all? Let me change it to `set -v; set +e; mount -t 9p -o trans=virtio host /mnt; /bin/sh` and reboot again. + +What should i say: it says: +[ 8.004754] device: '9p-1': device_add +[ 8.006446] 9p: no channels available +[ 8.007156] device: '9p-1': device_unregister +[ 8.008650] device: '9p-1': device_create_release +mount: No such file or directory + +But i have a shell now and can type the mount stuff inside it: +$ mount -v -t 9p -o trans=virtio host /mnt +mount -v -t 9p -o trans=virtio host /mnt +[ 70.982688] device: '9p-2': device_add +[ 70.986508] 9p: no channels available +[ 70.987969] device: '9p-2': device_unregister +[ 70.992937] device: '9p-2': device_create_release +mount: No such file or directory +$ ls -l /sys/bus/virtio/drivers/9pnet_virtio +total 0 +--w------- 1 root root 4096 Sep 26 12:58 bind +--w------- 1 root root 4096 Sep 26 12:58 uevent +--w------- 1 root root 4096 Sep 26 12:58 unbind +lrwxrwxrwx 1 root root 0 Sep 26 12:58 virtio1 -> ../../../../devices/virtio-pci/virtio1 +$ ls -l /sys/devices/virtio-pci/virtio1 +total 0 +lrwxrwxrwx 1 root root 0 Sep 26 13:00 bus -> ../../../bus/virtio +-r--r--r-- 1 root root 4096 Sep 26 13:00 device +lrwxrwxrwx 1 root root 0 Sep 26 13:00 driver -> ../../../bus/virtio/drivers/9pnet_virtio +-r--r--r-- 1 root root 4096 Sep 26 13:00 features +-r--r--r-- 1 root root 4096 Sep 26 13:00 modalias +-r--r--r-- 1 root root 4096 Sep 26 13:00 mount_tag +drwxr-xr-x 2 root root 0 Sep 26 12:58 power +-r--r--r-- 1 root root 4096 Sep 26 13:00 status +lrwxrwxrwx 1 root root 0 Sep 26 13:00 subsystem -> ../../../bus/virtio +-rw-r--r-- 1 root root 4096 Sep 26 13:00 uevent +-r--r--r-- 1 root root 4096 Sep 26 13:00 vendor +$ cat /sys/devices/virtio-pci/virtio1/mount_tag +host$ mount -v -t 9p -o trans=virtio host /mnt +[ 340.559853] device: '9p-3': device_add +[ 340.563699] 9p: no channels available +[ 340.565602] device: '9p-3': device_unregister +[ 340.569201] device: '9p-3': device_create_release +mount: No such file or director +$ mount -v -t 9p -o trans=virtio hostA /mnt +[ 406.218462] device: '9p-4': device_add +hostA on /mnt type 9p (rw,trans=virtio) +$ env +CONSOLE=/dev/console +HOME=/ +runlevel=2 +INIT_VERSION=sysvinit-2.88 +COLUMNS=80 +TERM=linux +PATH=/sbin:/usr/sbin:/bin:/usr/bin +RUNLEVEL=2 +PREVLEVEL=N +SHELL=/bin/sh +PWD=/ +previous=N +LINES=24 +VERBOSE=no +$ id +uid=0(root) gid=0(root) groups=0(root) +$ hexdump asd +0000000 6f68 7473 0000 0000 0000 0000 0000 0000 +0000010 0000 0000 +0000014 + +I rebooted again and now just ctrl+d in my rc.local shell to get to my real root login with zsh: +$ cat /sys/devices/virtio-pci/virtio1/mount_tag > asd +$ hexdump asd +0000000 6f68 7473 0000 0000 0000 0000 0000 0000 +0000010 0000 0000 +0000014 +$ id +uid=0(root) gid=0(root) groups=0(root) +$ env +TERM=linux +HOME=/root +SHELL=/bin/zsh +USER=root +LOGNAME=root +PATH=/host/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +MAIL=/var/mail/root +HUSHLOGIN=FALSE +SHLVL=1 +PWD=/root +OLDPWD=/root +COLORTERM=yes +LINKS_XTERM=screen +EDITOR=vim +PAGER=less -r +BROWSER=iceweasel +LESS=-RIM +LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: +HISTFILE=/root/.zsh_history +HISTSIZE=10000 +SAVEHIST=10000 +_=/usr/bin/env +$ mount -v -t 9p -o trans=virtio host /mnt +[ 224.087952] device: '9p-2': device_add +host on /mnt type 9p (rw,trans=virtio) + +So the next step was to change my login shell to /bin/sh (dash) and reboot: +$ id +uid=0(root) gid=0(root) groups=0(root) +$ env +USER=root +MAIL=/var/mail/root +OLDPWD=/root +HOME=/root +HUSHLOGIN=FALSE +PS1=\h:\w\$ +LOGNAME=root +TERM=linux +PATH=/host/usr/bin:/host/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +SHELL=/bin/sh +PWD=/host +$ mount -v -t 9p -o trans=virtio host /mnt +[ 15.330643] device: '9p-2': device_add +host on /mnt type 9p (rw,trans=virtio) + +Next step was to boot up, change my env and then use the correct mount: +$ for i in USER MAIL OLDPWD HOME HUSHLOGIN PS1 LOGNAME TERM PATH SHELL PWD; do unset $i; done +$ env +$ /bin/mount -v -t 9p -o trans=virtio host /mnt +[ 431.742839] device: '9p-2': device_add +host on /mnt type 9p (rw,trans=virtio) + +Next steps were to use the old envs: + +$ for i in USER MAIL OLDPWD HOME HUSHLOGIN PS1 LOGNAME TERM PATH SHELL PWD; do unset $i; done +$ export CONSOLE=/dev/console +$ export HOME=/ +$ export runlevel=2 +$ export INIT_VERSION=sysvinit-2.88 +$ export COLUMNS=80 +$ export TERM=linux +$ export PATH=/sbin:/usr/sbin:/bin:/usr/bin +$ export RUNLEVEL=2 +$ export PREVLEVEL=N +$ export SHELL=/bin/sh +$ export PWD=/ +$ export previous=N +$ export LINES=24 +$ export VERBOSE=no +$ /bin/sh +$ env +CONSOLE=/dev/console +HOME=/ +runlevel=2 +INIT_VERSION=sysvinit-2.88 +COLUMNS=80 +TERM=linux +PATH=/sbin:/usr/sbin:/bin:/usr/bin +RUNLEVEL=2 +PREVLEVEL=N +SHELL=/bin/sh +PWD=/host +previous=N +LINES=24 +VERBOSE=no +$ mount -v -t 9p -o trans=virtio host /mnt +[ 44.554805] device: '9p-2': device_add +host on /mnt type 9p (rw,trans=virtio) + +Next step was to strace on rc.local sh: +/bin/sh: can't access tty; job control turned off +$ strace -o /mount1 mount -v -t 9p -o trans=virtio host /mnt +[ 131.002908] device: '9p-2': device_add +[ 131.006914] 9p: no channels available +[ 131.009720] device: '9p-2': device_unregister +[ 131.013135] device: '9p-2': device_create_release +mount: No such file or directory + +And then inside the normal root shell +$ strace -o /mount2 mount -v -t 9p -o trans=virtio host /mnt + +Important information: There exists a folder /host in the guest filesystem + +So it is a problem that pwd inside the root shell is / and thus it finds /host and informs the kernel that it should mount /host using 9p to /mnt (which is of course bogus). I am quite unsure how to work around that problem without a stupid hack in rc.local instead of /etc/fstab + +So there is still the problem that it mounts host_share even if that does not exists + +Fixed for me by http://article.gmane.org/gmane.linux.utilities.util-linux-ng/3500/raw and http://article.gmane.org/gmane.linux.kernel/1041020/raw + +If I've got the previous comments right, this was not a QEMU bug, but a bug in "mount" and the guest kernel ... so closing this QEMU ticket here now. + diff --git a/results/classifier/zero-shot/108/permissions/67821138 b/results/classifier/zero-shot/108/permissions/67821138 new file mode 100644 index 000000000..37755ea48 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/67821138 @@ -0,0 +1,209 @@ +permissions: 0.935 +device: 0.916 +PID: 0.909 +boot: 0.881 +debug: 0.870 +other: 0.853 +performance: 0.845 +semantic: 0.843 +graphic: 0.826 +files: 0.824 +KVM: 0.822 +vnc: 0.734 +network: 0.718 +socket: 0.699 + +[BUG, RFC] Base node is in RW after making external snapshot + +Hi everyone, + +When making an external snapshot, we end up in a situation when 2 block +graph nodes related to the same image file (format and storage nodes) +have different RO flags set on them. + +E.g. + +# ls -la /proc/PID/fd +lrwx------ 1 root qemu 64 Apr 24 20:14 12 -> /path/to/harddisk.hdd + +# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}' +--pretty | egrep '"node-name"|"ro"' + "ro": false, + "node-name": "libvirt-1-format", + "ro": false, + "node-name": "libvirt-1-storage", + +# virsh snapshot-create-as VM --name snap --disk-only +Domain snapshot snap created + +# ls -la /proc/PID/fd +lr-x------ 1 root qemu 64 Apr 24 20:14 134 -> /path/to/harddisk.hdd +lrwx------ 1 root qemu 64 Apr 24 20:14 135 -> /path/to/harddisk.snap + +# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}' +--pretty | egrep '"node-name"|"ro"' + "ro": false, + "node-name": "libvirt-2-format", + "ro": false, + "node-name": "libvirt-2-storage", + "ro": true, + "node-name": "libvirt-1-format", + "ro": false, <-------------- + "node-name": "libvirt-1-storage", + +File descriptor has been reopened in RO, but "libvirt-1-storage" node +still has RW permissions set. + +I'm wondering it this a bug or this is intended? Looks like a bug to +me, although I see that some iotests (e.g. 273) expect 2 nodes related +to the same image file to have different RO flags. + +bdrv_reopen_set_read_only() + bdrv_reopen() + bdrv_reopen_queue() + bdrv_reopen_queue_child() + bdrv_reopen_multiple() + bdrv_list_refresh_perms() + bdrv_topological_dfs() + bdrv_do_refresh_perms() + bdrv_reopen_commit() + +In the stack above bdrv_reopen_set_read_only() is only being called for +the parent (libvirt-1-format) node. There're 2 lists: BDSs from +refresh_list are used by bdrv_drv_set_perm and this leads to actual +reopen with RO of the file descriptor. And then there's reopen queue +bs_queue -- BDSs from this queue get their parameters updated. While +refresh_list ends up having the whole subtree (including children, this +is done in bdrv_topological_dfs()) bs_queue only has the parent. And +that is because storage (child) node's (bs->inherits_from == NULL), so +bdrv_reopen_queue_child() never adds it to the queue. Could it be the +source of this bug? + +Anyway, would greatly appreciate a clarification. + +Andrey + +On 4/24/24 21:00, Andrey Drobyshev wrote: +> +Hi everyone, +> +> +When making an external snapshot, we end up in a situation when 2 block +> +graph nodes related to the same image file (format and storage nodes) +> +have different RO flags set on them. +> +> +E.g. +> +> +# ls -la /proc/PID/fd +> +lrwx------ 1 root qemu 64 Apr 24 20:14 12 -> /path/to/harddisk.hdd +> +> +# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}' +> +--pretty | egrep '"node-name"|"ro"' +> +"ro": false, +> +"node-name": "libvirt-1-format", +> +"ro": false, +> +"node-name": "libvirt-1-storage", +> +> +# virsh snapshot-create-as VM --name snap --disk-only +> +Domain snapshot snap created +> +> +# ls -la /proc/PID/fd +> +lr-x------ 1 root qemu 64 Apr 24 20:14 134 -> /path/to/harddisk.hdd +> +lrwx------ 1 root qemu 64 Apr 24 20:14 135 -> /path/to/harddisk.snap +> +> +# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}' +> +--pretty | egrep '"node-name"|"ro"' +> +"ro": false, +> +"node-name": "libvirt-2-format", +> +"ro": false, +> +"node-name": "libvirt-2-storage", +> +"ro": true, +> +"node-name": "libvirt-1-format", +> +"ro": false, <-------------- +> +"node-name": "libvirt-1-storage", +> +> +File descriptor has been reopened in RO, but "libvirt-1-storage" node +> +still has RW permissions set. +> +> +I'm wondering it this a bug or this is intended? Looks like a bug to +> +me, although I see that some iotests (e.g. 273) expect 2 nodes related +> +to the same image file to have different RO flags. +> +> +bdrv_reopen_set_read_only() +> +bdrv_reopen() +> +bdrv_reopen_queue() +> +bdrv_reopen_queue_child() +> +bdrv_reopen_multiple() +> +bdrv_list_refresh_perms() +> +bdrv_topological_dfs() +> +bdrv_do_refresh_perms() +> +bdrv_reopen_commit() +> +> +In the stack above bdrv_reopen_set_read_only() is only being called for +> +the parent (libvirt-1-format) node. There're 2 lists: BDSs from +> +refresh_list are used by bdrv_drv_set_perm and this leads to actual +> +reopen with RO of the file descriptor. And then there's reopen queue +> +bs_queue -- BDSs from this queue get their parameters updated. While +> +refresh_list ends up having the whole subtree (including children, this +> +is done in bdrv_topological_dfs()) bs_queue only has the parent. And +> +that is because storage (child) node's (bs->inherits_from == NULL), so +> +bdrv_reopen_queue_child() never adds it to the queue. Could it be the +> +source of this bug? +> +> +Anyway, would greatly appreciate a clarification. +> +> +Andrey +Friendly ping. Could somebody confirm that it is a bug indeed? + diff --git a/results/classifier/zero-shot/108/permissions/696834 b/results/classifier/zero-shot/108/permissions/696834 new file mode 100644 index 000000000..580bf1c39 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/696834 @@ -0,0 +1,390 @@ +permissions: 0.951 +graphic: 0.950 +semantic: 0.945 +debug: 0.940 +other: 0.939 +performance: 0.932 +PID: 0.931 +socket: 0.918 +device: 0.916 +files: 0.896 +vnc: 0.884 +network: 0.880 +boot: 0.868 +KVM: 0.723 + +FP exception reporting not working on NetBSD host + +I recognize that NetBSD is not one of the officially supported host OS. However, qemu 0.13.0 is available in the NetBSD pkgsrc collection, and works quite well. Well, with one exception (pun intended): It seems that Floating Point exceptions don't get reported properly. + +The following code-snippet demonstrates the problem: + + +volatile int flt_signal = 0; + +static sigjmp_buf sigfpe_flt_env; +static void +sigfpe_flt_action(int signo, siginfo_t *info, void *ptr) +{ + flt_signal++; +} + +void trigger(void) +{ + struct sigaction sa; + double d = strtod("0", NULL); + + if (sigsetjmp(sigfpe_flt_env, 0) == 0) { + sa.sa_flags = SA_SIGINFO; + sa.sa_sigaction = sigfpe_flt_action; + sigemptyset(&sa.sa_mask); + sigaction(SIGFPE, &sa, NULL); + fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP); + printf("%g\n", 1 / d); + } + printf("FPE signal handler invoked %d times.\n"); +} + +On Mon, Jan 3, 2011 at 12:14 PM, Paul Goyette <email address hidden>wrote: + +> Public bug reported: +> +> I recognize that NetBSD is not one of the officially supported host OS. +> However, qemu 0.13.0 is available in the NetBSD pkgsrc collection, and +> works quite well. Well, with one exception (pun intended): It seems +> that Floating Point exceptions don't get reported properly. +> +> The following code-snippet demonstrates the problem: +> +> +> volatile int flt_signal = 0; +> +> static sigjmp_buf sigfpe_flt_env; +> static void +> sigfpe_flt_action(int signo, siginfo_t *info, void *ptr) +> { +> flt_signal++; +> } +> +> void trigger(void) +> { +> struct sigaction sa; +> double d = strtod("0", NULL); +> +> if (sigsetjmp(sigfpe_flt_env, 0) == 0) { +> sa.sa_flags = SA_SIGINFO; +> sa.sa_sigaction = sigfpe_flt_action; +> sigemptyset(&sa.sa_mask); +> sigaction(SIGFPE, &sa, NULL); +> fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP); +> printf("%g\n", 1 / d); +> } +> printf("FPE signal handler invoked %d times.\n"); +> + +this printf() does miss an argument :-) + + +> } +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/696834 +> +> Title: +> FP exception reporting not working on NetBSD host +> +> Status in QEMU: +> New +> +> Bug description: +> I recognize that NetBSD is not one of the officially supported host OS. +> However, qemu 0.13.0 is available in the NetBSD pkgsrc collection, and +> works quite well. Well, with one exception (pun intended): It seems that +> Floating Point exceptions don't get reported properly. +> +> The following code-snippet demonstrates the problem: +> +> +> volatile int flt_signal = 0; +> +> static sigjmp_buf sigfpe_flt_env; +> static void +> sigfpe_flt_action(int signo, siginfo_t *info, void *ptr) +> { +> flt_signal++; +> } +> +> void trigger(void) +> { +> struct sigaction sa; +> double d = strtod("0", NULL); +> +> if (sigsetjmp(sigfpe_flt_env, 0) == 0) { +> sa.sa_flags = SA_SIGINFO; +> sa.sa_sigaction = sigfpe_flt_action; +> sigemptyset(&sa.sa_mask); +> sigaction(SIGFPE, &sa, NULL); +> fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP); +> printf("%g\n", 1 / d); +> } +> printf("FPE signal handler invoked %d times.\n"); +> + +this printf() does miss an argument :-) + + +> } +> +> +> +> + + +On Mon, 3 Jan 2011, Paulo Cezar A Junior wrote: + +<snip> + +>> printf("FPE signal handler invoked %d times.\n"); +> +> this printf() does miss an argument :-) + +Yes, it does. The signal handler is also missing a line: + + siglongjmp(sigfpe_flt_env, 1); + +That's what I get for extracting bits&pieces of the larger test program. +:) + + +The following is a complete, standalone test program: + + #include <ieeefp.h> + #include <setjmp.h> + #include <signal.h> + #include <stdio.h> + + volatile int flt_signal = 0; + + static sigjmp_buf sigfpe_flt_env; + static void + sigfpe_flt_action(int signo, siginfo_t *info, void *ptr) + { + + flt_signal++; + siglongjmp(sigfpe_flt_env, 1); + } + int main(int argc, void *argv[]) + { + struct sigaction sa; + double d; + + printf("Start\n"); + if (sigsetjmp(sigfpe_flt_env, 0) == 0) { + sa.sa_flags = SA_SIGINFO; + sa.sa_sigaction = sigfpe_flt_action; + sigemptyset(&sa.sa_mask); + sigaction(SIGFPE, &sa, NULL); + fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP); + d = 1.0 / strtod("0", NULL); + } + printf("FPE signal handler invoked %d times.\n"); + } + +Executing the program gives the following results: + + # cc -o test test.c + # ./test + Start + FPE signal handler invoked 0 times. + # + +On "real" hardware, + + {225} cc -o test test.c + {226} ./test + Start + FPE signal handler invoked 1 times. + {227} + + +------------------------------------------------------------------------- +| Paul Goyette | PGP Key fingerprint: | E-mail addresses: | +| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | +| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | +| Kernel Developer | | pgoyette at netbsd.org | +------------------------------------------------------------------------- + +On Mon, 3 Jan 2011, Paul Goyette wrote: + +> The following is a complete, standalone test program: +> +> #include <ieeefp.h> +> #include <setjmp.h> +> #include <signal.h> +> #include <stdio.h> +> +> volatile int flt_signal = 0; +> +> static sigjmp_buf sigfpe_flt_env; +> static void +> sigfpe_flt_action(int signo, siginfo_t *info, void *ptr) +> { +> +> flt_signal++; +> siglongjmp(sigfpe_flt_env, 1); +> } +> int main(int argc, void *argv[]) +> { +> struct sigaction sa; +> double d; +> +> printf("Start\n"); +> if (sigsetjmp(sigfpe_flt_env, 0) == 0) { +> sa.sa_flags = SA_SIGINFO; +> sa.sa_sigaction = sigfpe_flt_action; +> sigemptyset(&sa.sa_mask); +> sigaction(SIGFPE, &sa, NULL); +> fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP); +> d = 1.0 / strtod("0", NULL); +> } +> printf("FPE signal handler invoked %d times.\n"); + +And, of course, I still missed the extra agument: + + printf("FPE signal handler invoked %d times.\n", flt_signal); + + +> } +> +> Executing the program gives the following results: +> +> # cc -o test test.c +> # ./test +> Start +> FPE signal handler invoked 0 times. +> # +> +> On "real" hardware, +> +> {225} cc -o test test.c +> {226} ./test +> Start +> FPE signal handler invoked 1 times. +> {227} +> +> +> ------------------------------------------------------------------------- +> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | +> | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | +> | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | +> | Kernel Developer | | pgoyette at netbsd.org | +> ------------------------------------------------------------------------- +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/696834 +> +> Title: +> FP exception reporting not working on NetBSD host +> +> Status in QEMU: +> New +> +> Bug description: +> I recognize that NetBSD is not one of the officially supported host OS. However, qemu 0.13.0 is available in the NetBSD pkgsrc collection, and works quite well. Well, with one exception (pun intended): It seems that Floating Point exceptions don't get reported properly. +> +> The following code-snippet demonstrates the problem: +> +> +> volatile int flt_signal = 0; +> +> static sigjmp_buf sigfpe_flt_env; +> static void +> sigfpe_flt_action(int signo, siginfo_t *info, void *ptr) +> { +> flt_signal++; +> } +> +> void trigger(void) +> { +> struct sigaction sa; +> double d = strtod("0", NULL); +> +> if (sigsetjmp(sigfpe_flt_env, 0) == 0) { +> sa.sa_flags = SA_SIGINFO; +> sa.sa_sigaction = sigfpe_flt_action; +> sigemptyset(&sa.sa_mask); +> sigaction(SIGFPE, &sa, NULL); +> fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP); +> printf("%g\n", 1 / d); +> } +> printf("FPE signal handler invoked %d times.\n"); +> } +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/696834/+subscribe +> +> !DSPAM:4d21f0752341470756574! +> +> +> + +------------------------------------------------------------------------- +| Paul Goyette | PGP Key fingerprint: | E-mail addresses: | +| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | +| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | +| Kernel Developer | | pgoyette at netbsd.org | +------------------------------------------------------------------------- + +LinkedIn +------------ + + +Bug, + +I'd like to add you to my professional network on LinkedIn. + +- Paulo + +Paulo Cezar +Platform Researcher and Developer at INdT +São Paulo Area, Brazil + +Confirm that you know Paulo Cezar +https://www.linkedin.com/e/-g11m92-go1e59vx-23/isd/2968180228/v_gmfnNW/ + + + +-- +(c) 2011, LinkedIn Corporation + +QEMU 0.13 is completely outdated nowadays - can you still reproduce this problem with the latest version of QEMU (currently version 2.8) ? + +On Tue, 10 Jan 2017, Thomas Huth wrote: + +> QEMU 0.13 is completely outdated nowadays - can you still reproduce this +> problem with the latest version of QEMU (currently version 2.8) ? + +The test program running on qemu 2.8.0 now produces the expected results +- 1 FP exception + +You can close this bug. + + + ++------------------+--------------------------+------------------------+ +| Paul Goyette | PGP Key fingerprint: | E-mail addresses: | +| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | +| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | ++------------------+--------------------------+------------------------+ + + +Thanks for verifying! + diff --git a/results/classifier/zero-shot/108/permissions/721659 b/results/classifier/zero-shot/108/permissions/721659 new file mode 100644 index 000000000..740262138 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/721659 @@ -0,0 +1,55 @@ +permissions: 0.942 +KVM: 0.875 +device: 0.833 +socket: 0.789 +debug: 0.695 +graphic: 0.692 +semantic: 0.668 +PID: 0.621 +other: 0.590 +performance: 0.538 +network: 0.529 +boot: 0.471 +vnc: 0.434 +files: 0.293 + +qemu-kvm-0.13.0 doesn't pass USB devices to the VM + +I have the bug, similar to this one: +https://bugzilla.redhat.com/show_bug.cgi?id=583108 +but under gentoo + +When I add parameters -usb -usbdevice host:4348:5584, I see the following lines in console: + +husb: config #1 need -1 +USBDEVFS_DISCONNECT: No route to host +husb: open device 2.11 +(...many repetitions of three above lines...) + +All parameters (2.11) are verified with lsusb at host computer - parameters are correct + +Error description is very confusing - I don't know what to check, what "config #1" mean, which route should be checked and how to check it. + +Hi, + +Thanks for reporting this problem. + +Can you tell me a bit more about your configuration? For example: +What are the guest and host operating systems? + +Is it always "need -1"? Do you ever see "need 1"? + +What is the device you're trying to open? Can you show the USB descriptors (e.g. from lsusb)? + +Do you have rights to open the device (e.g. are you running qemu with elevated privileges)? Does it help / change things if you do or don't? + +I'm not sure that the error messages are very accurate in this particular case. I think the problem with those messages comes from use of perror() in the QEMU code and that the underlying operations aren't returning / setting errno in the right way (or perhaps at all). However the fact that we're even getting to the error path indicates a problem. If I had to guess, the device is already bound to a driver on the host and you don't have permissions to unbind it. However I'm pretty fuzzy on this one, and I'm really hoping the additional information might help someone else fix it. + +Brad + + + + + +QEMU 0.13.0 is quite outdated - and I assume that USB passthrough should be working fine with the latest version, so I'm closing this bug ticket now. If you still have problems with the latest version of QEMU, feel free to open it again (or create a new bug ticket instead). + diff --git a/results/classifier/zero-shot/108/permissions/74715356 b/results/classifier/zero-shot/108/permissions/74715356 new file mode 100644 index 000000000..d579d4ad3 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/74715356 @@ -0,0 +1,136 @@ +permissions: 0.930 +other: 0.927 +semantic: 0.916 +debug: 0.907 +performance: 0.905 +device: 0.900 +PID: 0.897 +graphic: 0.894 +boot: 0.881 +KVM: 0.863 +vnc: 0.850 +files: 0.850 +socket: 0.843 +network: 0.838 + +[Bug] x86 EFLAGS refresh is not happening correctly + +Hello, +I'm posting this here instead of opening an issue as it is not clear to me if this is a bug or not. +The issue is located in function "cpu_compute_eflags" in target/i386/cpu.h +( +https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/cpu.h#L2071 +) +This function is exectued in an out of cpu loop context. +It is used to synchronize TCG internal eflags registers (CC_OP, CC_SRC, etc...) with the CPU eflags field upon loop exit. +It does: +  eflags +|= +cpu_cc_compute_all +( +env +, +CC_OP +) +| +( +env +-> +df +& +DF_MASK +); +Shouldn't it be: +   +eflags += +cpu_cc_compute_all +( +env +, +CC_OP +) +| +( +env +-> +df +& +DF_MASK +); +as eflags is entirely reevaluated by "cpu_cc_compute_all" ? +Thanks, +Kind regards, +Stevie + +On 05/08/21 11:51, Stevie Lavern wrote: +Shouldn't it be: +eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK); +as eflags is entirely reevaluated by "cpu_cc_compute_all" ? +No, both are wrong. env->eflags contains flags other than the +arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved. +The right code is in helper_read_eflags. You can move it into +cpu_compute_eflags, and make helper_read_eflags use it. +Paolo + +On 05/08/21 13:24, Paolo Bonzini wrote: +On 05/08/21 11:51, Stevie Lavern wrote: +Shouldn't it be: +eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK); +as eflags is entirely reevaluated by "cpu_cc_compute_all" ? +No, both are wrong. env->eflags contains flags other than the +arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved. +The right code is in helper_read_eflags. You can move it into +cpu_compute_eflags, and make helper_read_eflags use it. +Ah, actually the two are really the same, the TF/VM bits do not apply to +cpu_compute_eflags so it's correct. +What seems wrong is migration of the EFLAGS register. There should be +code in cpu_pre_save and cpu_post_load to special-case it and setup +CC_DST/CC_OP as done in cpu_load_eflags. +Also, cpu_load_eflags should assert that update_mask does not include +any of the arithmetic flags. +Paolo + +Thank for your reply! +It's still a bit cryptic for me. +I think i need to precise that I'm using a x86_64 custom user-mode,base on linux user-mode, that i'm developing (unfortunately i cannot share the code) with modifications in the translation loop (I've added cpu loop exits on specific instructions which are not control flow instructions). +If my understanding is correct, in the user-mode case 'cpu_compute_eflags' is called directly by 'x86_cpu_exec_exit' with the intention of synchronizing the CPU env->eflags field with its real value (represented by the CC_* fields). +I'm not sure how 'cpu_pre_save' and 'cpu_post_load' are involved in this case. + +As you said in your first email, 'helper_read_eflags' seems to be the correct way to go. +Here is some detail about my current experimentation/understanding of this "issue": +With the current implementation +     +eflags |= cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK); +if I exit the loop with a CC_OP different from CC_OP_EFLAGS, I found that the resulting env->eflags may be invalid. +In my test case, the loop was exiting with eflags = 0x44 and CC_OP = CC_OP_SUBL with CC_DST=1, CC_SRC=258, CC_SRC2=0. +While 'cpu_cc_compute_all' computes the correct flags (ZF:0, PF:0), the result will still be 0x44 (ZF:1, PF:1) due to the 'or' operation, thus leading to an incorrect eflags value loaded into the CPU env. +In my case, after loop reentry, it led to an invalid branch to be taken. +Thanks for your time! +Regards +Stevie + +On Thu, Aug 5, 2021 at 1:33 PM Paolo Bonzini < +pbonzini@redhat.com +> wrote: +On 05/08/21 13:24, Paolo Bonzini wrote: +> On 05/08/21 11:51, Stevie Lavern wrote: +>> +>> Shouldn't it be: +>> eflags = cpu_cc_compute_all(env, CC_OP) | (env->df & DF_MASK); +>> as eflags is entirely reevaluated by "cpu_cc_compute_all" ? +> +> No, both are wrong. env->eflags contains flags other than the +> arithmetic flags (OF/SF/ZF/AF/PF/CF) and those have to be preserved. +> +> The right code is in helper_read_eflags. You can move it into +> cpu_compute_eflags, and make helper_read_eflags use it. +Ah, actually the two are really the same, the TF/VM bits do not apply to +cpu_compute_eflags so it's correct. +What seems wrong is migration of the EFLAGS register. There should be +code in cpu_pre_save and cpu_post_load to special-case it and setup +CC_DST/CC_OP as done in cpu_load_eflags. +Also, cpu_load_eflags should assert that update_mask does not include +any of the arithmetic flags. +Paolo + diff --git a/results/classifier/zero-shot/108/permissions/778032 b/results/classifier/zero-shot/108/permissions/778032 new file mode 100644 index 000000000..a34cce418 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/778032 @@ -0,0 +1,110 @@ +permissions: 0.945 +socket: 0.943 +semantic: 0.941 +debug: 0.940 +PID: 0.939 +performance: 0.929 +other: 0.928 +device: 0.925 +network: 0.920 +graphic: 0.920 +boot: 0.913 +files: 0.896 +vnc: 0.892 +KVM: 0.885 + +qemu spinning on serial port writes + +As originally found at http://<email address hidden>/msg08745.html from 3 years ago! + +Basically qemu seizes up in the event that the file descriptor for its emulated serial port has a full buffer, i.e. write() returns EAGAIN. For me, this happened when the serial port was being directed through a UNIX socket, with a default-sized 4KB buffer. Just the normal output from a Linux kernel boot caused it to seize up, and stop the main emulation / select loop. + +My suggestion is to remove the detection of EAGAIN in qemu-char.c:521, so that if the buffer is full, KVM discards the byte(s) it was trying to write. This is a surely better outcome than the process spinning forever. + +I will submit a separate patch to control the buffer sizes when creating UNIX sockets, which will help allow slow-reading processes to tune things so that they don't miss any output. + +Additionally, in the context of a hosted environment, if the -serial option is used, this could be a small security issue. An untrusted user of a guest system, knowing their serial output is going via a small buffer, could spew output to their /dev/ttyS0 at a rate fast enough to trigger this bug and eat a CPU core on the host. + +To quote David S. Ahern's original bug report (mine was the same, only with the latest version from git, so line numbers may have changed - my suggested fix above is accurate though): + +I am trying to redirect a guest's boot output through the host's serial +port. Shortly after launching qemu, the main thread is spinning on: + +write(9, "0", 1) = -1 EAGAIN (Resource temporarily unavailable) + +fd 9 is the serial port, ttyS0. + + +The backtrace for the thread is: + +#0 0x00002ac3433f8c0b in write () from /lib64/libpthread.so.0 +#1 0x0000000000475df9 in send_all (fd=9, buf=<value optimized out>, +len1=1) at qemu-char.c:477 +#2 0x000000000043a102 in serial_xmit (opaque=<value optimized out>) at +/root/kvm-81/qemu/hw/serial.c:311 +#3 0x000000000043a591 in serial_ioport_write (opaque=0x14971790, +addr=<value optimized out>, val=48) + at /root/kvm-81/qemu/hw/serial.c:366 +#4 0x00000000410eeedc in ?? () +#5 0x0000000000129000 in ?? () +#6 0x0000000014821fa0 in ?? () +#7 0x0000000000000007 in ?? () +#8 0x00000000004a54c5 in tlb_set_page_exec (env=0x10ab4, +vaddr=46912496956816, paddr=1, prot=-1, mmu_idx=0, is_softmmu=1) + at /root/kvm-81/qemu/exec.c:388 +#9 0x0000000000512f3b in tlb_fill (addr=345446292, is_write=1, +mmu_idx=-1, retaddr=0x0) + at /root/kvm-81/qemu/target-i386/op_helper.c:4690 +#10 0x00000000004a6bd2 in __ldb_cmmu (addr=9, mmu_idx=0) at +/root/kvm-81/qemu/softmmu_template.h:135 +#11 0x00000000004a879b in cpu_x86_exec (env1=<value optimized out>) at +/root/kvm-81/qemu/cpu-exec.c:628 +#12 0x000000000040ba29 in main (argc=12, argv=0x7fff67f7a398) at +/root/kvm-81/qemu/vl.c:3816 + +send_all() invokes unix_write() which by design is not breaking out on +EAGAIN. + +The following command is enough to show the problem: + +qemu-system-x86_64 -m 256 -smp 1 -no-kvm \ + -drivefile=/dev/cciss/c0d0,if=scsi,cache=off,boot=on \ + -vnc :1 -serial /dev/ttyS0 + + +The guest is running RHEL3 with the parameter 'console=ttyS0' added to +grub.conf; the problem appears to be with qemu, so I would expect it to +show with any linux guest. This particular host is running RHEL5.2 with +kvm-81, but I have also seen the problem with Fedora-9 as the host OS. + +Yes, the serial port of the server is connected to another system via a +null modem. If I change the serial argument to '-serial udp::4555' and +use 'nc -u -l localhost 4555 > /dev/ttyS0' I see the guest's boot +output show up on the second system as expected. I'd prefer to be able +to use the serial port connection directly without nc as a proxy. +Suggestions? + +I have a similar problem, and the problem goes away if I remove the "-serial pty" device from my command line: + +/home/mrhines/qemu/x86_64-softmmu/qemu-system-x86_64 /kvm_repo/cb/vmbase -serial pty + +Such a simple command line, but QEMU seizes up and slows to a crawl and the host CPU is spinning at 100% + +Which version of QEMU have you been using here? Can you still reproduce this problem with the latest version of QEMU (currently version 2.9)? + +I'm confident this has been solved a while ago. When this bug was reported, the code was indeed broken wrt EAGAIN handling. + +The chardev code has long since been re-written though, and the send_all method replaced by io_channel_send_all() which will handle EAGAIN by returning instead of spinning in a loop. + +Specifically this commit changed the code to stop spinning in send_all() on EAGAIN + +commit 23673ca740e0eda66901ca801a5a901df378b063 +Author: Anthony Liguori <email address hidden> +Date: Tue Mar 5 23:21:23 2013 +0530 + + qemu-char: add watch support + + This allows a front-end to request for a callback when the backend + is writable again. + + diff --git a/results/classifier/zero-shot/108/permissions/784977 b/results/classifier/zero-shot/108/permissions/784977 new file mode 100644 index 000000000..678dce0be --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/784977 @@ -0,0 +1,121 @@ +permissions: 0.930 +graphic: 0.929 +performance: 0.925 +other: 0.921 +semantic: 0.913 +socket: 0.913 +debug: 0.910 +device: 0.896 +network: 0.882 +boot: 0.881 +PID: 0.879 +vnc: 0.859 +KVM: 0.858 +files: 0.853 + +qemu-img convert fails to convert, generates a 512byte file output + +I have a Vmware image, so I have files like 'Ubuntu.vmdk', want to convert to VirtualBox .vdi format using qemu, the first stage of extracting the image with 'qemu-img convert Ubuntu.vmdk output.bin' just generates a 512byte file: + +{quote} +# Disk DescriptorFile +version=1 +CID=36be9761 +parentCID=ffffffff +createType="twoGbMaxExtentSparse" + +# Extent description +RW 4192256 SPARSE "Ubuntu-s001.vmdk" +RW 4192256 SPARSE "Ubuntu-s002.vmdk" +RW 4192256 SPARSE "Ubuntu-s003.vmdk" +RW 4192256 SPARSE "Ubuntu-s004.vmdk" +RW 4192256 SPARSE "Ubuntu-s005.vmdk" +RW 4192256 SPARSE "Ubuntu-s006.vmdk" +RW 4192256 SPARSE "Ubuntu-s007.vmdk" +RW 4192256 SPARSE "Ubuntu-s008.vmdk" +RW 4192256 SPARSE "Ubuntu-s009.vmdk" +RW 4192256 SPARSE "Ubuntu-s010.vmdk" +RW 20480 SPARSE "Ubunt +{quote} + +No stack trace or other output was found. Anything I can add (other than the 20G VM image to reproduce and I'll be happy to provide) + +On Thu, May 19, 2011 at 5:17 AM, Andy Brook <email address hidden> wrote: +> Public bug reported: +> +> I have a Vmware image, so I have files like 'Ubuntu.vmdk', want to +> convert to VirtualBox .vdi format using qemu, the first stage of +> extracting the image with 'qemu-img convert Ubuntu.vmdk output.bin' just +> generates a 512byte file: +> +> {quote} +> # Disk DescriptorFile +> version=1 +> CID=36be9761 +> parentCID=ffffffff +> createType="twoGbMaxExtentSparse" +> +> # Extent description +> RW 4192256 SPARSE "Ubuntu-s001.vmdk" +> RW 4192256 SPARSE "Ubuntu-s002.vmdk" +> RW 4192256 SPARSE "Ubuntu-s003.vmdk" +> RW 4192256 SPARSE "Ubuntu-s004.vmdk" +> RW 4192256 SPARSE "Ubuntu-s005.vmdk" +> RW 4192256 SPARSE "Ubuntu-s006.vmdk" +> RW 4192256 SPARSE "Ubuntu-s007.vmdk" +> RW 4192256 SPARSE "Ubuntu-s008.vmdk" +> RW 4192256 SPARSE "Ubuntu-s009.vmdk" +> RW 4192256 SPARSE "Ubuntu-s010.vmdk" +> RW 20480 SPARSE "Ubunt +> {quote} +> +> Here is the input Ubuntu.vmdk file: +> {quote} +> # Disk DescriptorFile +> version=1 +> CID=36be9761 +> parentCID=ffffffff +> createType="twoGbMaxExtentSparse" +> +> # Extent description +> RW 4192256 SPARSE "Ubuntu-s001.vmdk" +> RW 4192256 SPARSE "Ubuntu-s002.vmdk" +> RW 4192256 SPARSE "Ubuntu-s003.vmdk" +> RW 4192256 SPARSE "Ubuntu-s004.vmdk" +> RW 4192256 SPARSE "Ubuntu-s005.vmdk" +> RW 4192256 SPARSE "Ubuntu-s006.vmdk" +> RW 4192256 SPARSE "Ubuntu-s007.vmdk" +> RW 4192256 SPARSE "Ubuntu-s008.vmdk" +> RW 4192256 SPARSE "Ubuntu-s009.vmdk" +> RW 4192256 SPARSE "Ubuntu-s010.vmdk" +> RW 20480 SPARSE "Ubuntu-s011.vmdk" +> +> # The Disk Data Base +> #DDB +> +> ddb.toolsVersion = "7240" +> ddb.adapterType = "lsilogic" +> ddb.geometry.sectors = "63" +> ddb.geometry.heads = "255" +> ddb.geometry.cylinders = "2610" +> ddb.virtualHWVersion = "6" +> {quote} +> +> No stack trace or other output was found. Anything I can add (other +> than the 20G VM image to reproduce and I'll be happy to provide) + +Please post the output of "qemu-img info Ubuntu.vmdk". I suspect this +image file is not being recognized as vmdk and is being treated as a +raw image, hence the literal copy of its 512-byte sector size +contents. + +I have CCed Fam who is working on VMDK image format improvements and +may be able to help here. + +Stefan + + +Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/788697 b/results/classifier/zero-shot/108/permissions/788697 new file mode 100644 index 000000000..4b79fb31b --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/788697 @@ -0,0 +1,249 @@ +permissions: 0.955 +other: 0.950 +graphic: 0.945 +performance: 0.938 +socket: 0.937 +debug: 0.937 +semantic: 0.934 +device: 0.930 +PID: 0.927 +files: 0.924 +network: 0.916 +boot: 0.916 +KVM: 0.895 +vnc: 0.878 + +[PowerPC] [patch] mtmsr does not preserve high bits of MSR + +The mtmsr instruction on 64-bit PPC does not preserve the high-order 32-bits of the MSR the way it is supposed to, instead setting them to 0, which takes 64-bit code out of 64-bit mode. There is some code that does the right thing, but it brokenly only preserves these bits when the thread is not in 64-bit mode (i.e. when it doesn't matter). The attached patch unconditionally enables this code when TARGET_PPC64 is set, per the ISA spec, which fixes early boot failures trying to start FreeBSD/powerpc64 under qemu. + + + + +On 26.05.2011, at 18:09, Nathan Whitehorn wrote: + +> ** Patch added: "mtmstr.diff" +> https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/788697 +> +> Title: +> [PowerPC] [patch] mtmsr does not preserve high bits of MSR +> +> Status in QEMU: +> New +> +> Bug description: +> The mtmsr instruction on 64-bit PPC does not preserve the high-order +> 32-bits of the MSR the way it is supposed to, instead setting them to +> 0, which takes 64-bit code out of 64-bit mode. There is some code that +> does the right thing, but it brokenly only preserves these bits when +> the thread is not in 64-bit mode (i.e. when it doesn't matter). The +> attached patch unconditionally enables this code when TARGET_PPC64 is +> set, per the ISA spec, which fixes early boot failures trying to start +> FreeBSD/powerpc64 under qemu. +> + +Please send the patch as proper patch to the ML and CC me. + +Alex + + + +On 05/26/11 11:45, agraf wrote: +> On 26.05.2011, at 18:09, Nathan Whitehorn wrote: +> +>> ** Patch added: "mtmstr.diff" +>> https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff +>> +>> -- +>> You received this bug notification because you are a member of qemu- +>> devel-ml, which is subscribed to QEMU. +>> https://bugs.launchpad.net/bugs/788697 +>> +>> Title: +>> [PowerPC] [patch] mtmsr does not preserve high bits of MSR +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> The mtmsr instruction on 64-bit PPC does not preserve the high-order +>> 32-bits of the MSR the way it is supposed to, instead setting them to +>> 0, which takes 64-bit code out of 64-bit mode. There is some code that +>> does the right thing, but it brokenly only preserves these bits when +>> the thread is not in 64-bit mode (i.e. when it doesn't matter). The +>> attached patch unconditionally enables this code when TARGET_PPC64 is +>> set, per the ISA spec, which fixes early boot failures trying to start +>> FreeBSD/powerpc64 under qemu. +>> +> +> Please send the patch as proper patch to the ML and CC me. + +What isn't proper about the patch? I'm happy to re-email it, but don't +want things to be in the wrong format. +-Nathan + + + +On 27.05.2011, at 01:33, Nathan Whitehorn wrote: + +> On 05/26/11 11:45, agraf wrote: +>> On 26.05.2011, at 18:09, Nathan Whitehorn wrote: +>> +>>> ** Patch added: "mtmstr.diff" +>>> https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff +>>> +>>> -- +>>> You received this bug notification because you are a member of qemu- +>>> devel-ml, which is subscribed to QEMU. +>>> https://bugs.launchpad.net/bugs/788697 +>>> +>>> Title: +>>> [PowerPC] [patch] mtmsr does not preserve high bits of MSR +>>> +>>> Status in QEMU: +>>> New +>>> +>>> Bug description: +>>> The mtmsr instruction on 64-bit PPC does not preserve the high-order +>>> 32-bits of the MSR the way it is supposed to, instead setting them to +>>> 0, which takes 64-bit code out of 64-bit mode. There is some code that +>>> does the right thing, but it brokenly only preserves these bits when +>>> the thread is not in 64-bit mode (i.e. when it doesn't matter). The +>>> attached patch unconditionally enables this code when TARGET_PPC64 is +>>> set, per the ISA spec, which fixes early boot failures trying to start +>>> FreeBSD/powerpc64 under qemu. +>>> +>> +>> Please send the patch as proper patch to the ML and CC me. +> +> What isn't proper about the patch? I'm happy to re-email it, but don't +> want things to be in the wrong format. +> -Nathan + +The patch needs a patch description in its header and a subject line (all of which are present in the bug, so it's a simple matter of copy&paste). Basically at the end of the day, I should be able to save the mail and "git am" on it and simply have it in my tree :). + +Also, does this get FreeBSD booting up to anything useful, so I can verify it helps? + + +Alex + + + +On 05/26/11 18:47, agraf wrote: +> On 27.05.2011, at 01:33, Nathan Whitehorn wrote: +> +>> On 05/26/11 11:45, agraf wrote: +>>> On 26.05.2011, at 18:09, Nathan Whitehorn wrote: +>>> +>>>> ** Patch added: "mtmstr.diff" +>>>> https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff +>>>> +>>>> -- +>>>> You received this bug notification because you are a member of qemu- +>>>> devel-ml, which is subscribed to QEMU. +>>>> https://bugs.launchpad.net/bugs/788697 +>>>> +>>>> Title: +>>>> [PowerPC] [patch] mtmsr does not preserve high bits of MSR +>>>> +>>>> Status in QEMU: +>>>> New +>>>> +>>>> Bug description: +>>>> The mtmsr instruction on 64-bit PPC does not preserve the high-order +>>>> 32-bits of the MSR the way it is supposed to, instead setting them to +>>>> 0, which takes 64-bit code out of 64-bit mode. There is some code that +>>>> does the right thing, but it brokenly only preserves these bits when +>>>> the thread is not in 64-bit mode (i.e. when it doesn't matter). The +>>>> attached patch unconditionally enables this code when TARGET_PPC64 is +>>>> set, per the ISA spec, which fixes early boot failures trying to start +>>>> FreeBSD/powerpc64 under qemu. +>>>> +>>> Please send the patch as proper patch to the ML and CC me. +>> What isn't proper about the patch? I'm happy to re-email it, but don't +>> want things to be in the wrong format. +>> -Nathan +> The patch needs a patch description in its header and a subject line +> (all of which are present in the bug, so it's a simple matter of +> copy&paste). Basically at the end of the day, I should be able to save +> the mail and "git am" on it and simply have it in my tree :). +> +> Also, does this get FreeBSD booting up to anything useful, so I can +> verify it helps? + +OK, I'll send this one out to today. The other issue I'm having (aside +from our own bugs), is that SPR_PIR is not implemented for the POWER7 +target. The architecture manual claims it is implemented on all Book-3S +compliant CPUs, but it seems to be implemented sort of ad-hoc in +target-ppc.c (e.g. the 604, 620, and 7400 have it, but not the 750, 970, +or POWER7). +-Nathan + + + +On 31.05.2011, at 15:35, Nathan Whitehorn wrote: + +> On 05/26/11 18:47, agraf wrote: +>> On 27.05.2011, at 01:33, Nathan Whitehorn wrote: +>> +>>> On 05/26/11 11:45, agraf wrote: +>>>> On 26.05.2011, at 18:09, Nathan Whitehorn wrote: +>>>> +>>>>> ** Patch added: "mtmstr.diff" +>>>>> https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff +>>>>> +>>>>> -- +>>>>> You received this bug notification because you are a member of qemu- +>>>>> devel-ml, which is subscribed to QEMU. +>>>>> https://bugs.launchpad.net/bugs/788697 +>>>>> +>>>>> Title: +>>>>> [PowerPC] [patch] mtmsr does not preserve high bits of MSR +>>>>> +>>>>> Status in QEMU: +>>>>> New +>>>>> +>>>>> Bug description: +>>>>> The mtmsr instruction on 64-bit PPC does not preserve the high-order +>>>>> 32-bits of the MSR the way it is supposed to, instead setting them to +>>>>> 0, which takes 64-bit code out of 64-bit mode. There is some code that +>>>>> does the right thing, but it brokenly only preserves these bits when +>>>>> the thread is not in 64-bit mode (i.e. when it doesn't matter). The +>>>>> attached patch unconditionally enables this code when TARGET_PPC64 is +>>>>> set, per the ISA spec, which fixes early boot failures trying to start +>>>>> FreeBSD/powerpc64 under qemu. +>>>>> +>>>> Please send the patch as proper patch to the ML and CC me. +>>> What isn't proper about the patch? I'm happy to re-email it, but don't +>>> want things to be in the wrong format. +>>> -Nathan +>> The patch needs a patch description in its header and a subject line +>> (all of which are present in the bug, so it's a simple matter of +>> copy&paste). Basically at the end of the day, I should be able to save +>> the mail and "git am" on it and simply have it in my tree :). +>> +>> Also, does this get FreeBSD booting up to anything useful, so I can +>> verify it helps? +> +> OK, I'll send this one out to today. The other issue I'm having (aside +> from our own bugs), is that SPR_PIR is not implemented for the POWER7 +> target. The architecture manual claims it is implemented on all Book-3S +> compliant CPUs, but it seems to be implemented sort of ad-hoc in +> target-ppc.c (e.g. the 604, 620, and 7400 have it, but not the 750, 970, +> or POWER7). + +So the reason POWER7 doesn't have it is probably because it simply does the same as 970. Why 970 doesn't register PIR, I don't know, but to me it sounds like a plain bug :). Just send a patch, CC me and David Gibson. + +Alex + + + +As far as I can see, the issue has been fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8018dc63aab936f1a5 +... so closing this ticket now. + diff --git a/results/classifier/zero-shot/108/permissions/811683 b/results/classifier/zero-shot/108/permissions/811683 new file mode 100644 index 000000000..052596d4c --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/811683 @@ -0,0 +1,321 @@ +permissions: 0.952 +PID: 0.920 +debug: 0.919 +other: 0.911 +semantic: 0.906 +device: 0.904 +performance: 0.896 +files: 0.892 +graphic: 0.891 +socket: 0.887 +boot: 0.848 +KVM: 0.846 +vnc: 0.841 +network: 0.832 + +7400,7410,7450 cpus vector have wrong exception prefix at reset + +I have a proprietary ROM implementing system calls that are executed via the 'SC' instruction. + +I use qemu-0.14.1, + +qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel + +That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x80000201). I found that the emulator jumps to 0x00000c00 instead of 0xfff00c00. +Probably this is due to a wrong setting in target-ppc/translate_init.c: + +init_excp_604() correctly sets env->hreset_vector=0xfff00000UL; + +but + +init_excp_7400() says env->hreset_vector=0x00000000UL; + +which seems wrong. (the 7400 manual says a hard-reset jumps initializes the +prefix to 0xfff00000.) + +Likewise, init_excp_7450() (and probably other, related CPUs) are wrong. + +Indeed, when I change the value in init_excp_7400() to 0xfff00000UL then +everything works as expected for me. + +Hi, + +Am 16.07.2011 um 23:49 schrieb till: + +> I have a proprietary ROM implementing system calls that are executed +> via +> the 'SC' instruction. +> +> I use qemu-0.14.1, +> +> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel +> +> That works fine on a 604 (CPU=0x00040103) - but does not on an +> emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x80000201). I found +> that the emulator jumps to 0x00000c00 instead of 0xfff00c00. +> Probably this is due to a wrong setting in target-ppc/ +> translate_init.c: +> +> init_excp_604() correctly sets env->hreset_vector=0xfff00000UL; +> +> but +> +> init_excp_7400() says env->hreset_vector=0x00000000UL; +> +> which seems wrong. (the 7400 manual says a hard-reset jumps +> initializes the +> prefix to 0xfff00000.) + +Do you have a link to a spec saying so? Should be trivial to change +then. + +> Likewise, init_excp_7450() (and probably other, related CPUs) are +> wrong. +> +> Indeed, when I change the value in init_excp_7400() to 0xfff00000UL +> then +> everything works as expected for me. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + +> Bug description: +> I have a proprietary ROM implementing system calls that are executed +> via the 'SC' instruction. +> +> I use qemu-0.14.1, +> +> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel + +We are currently in the process of revamping the PReP machine you are +using above. Is your BIOS available publicly so that we can test we +don't break anything for you? + +Andreas + + + +On 18.07.2011, at 00:34, Andreas Färber wrote: + +> Hi, +> +> Am 16.07.2011 um 23:49 schrieb till: +> +>> I have a proprietary ROM implementing system calls that are executed via +>> the 'SC' instruction. +>> +>> I use qemu-0.14.1, +>> +>> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel +>> +>> That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x80000201). I found that the emulator jumps to 0x00000c00 instead of 0xfff00c00. +>> Probably this is due to a wrong setting in target-ppc/translate_init.c: +>> +>> init_excp_604() correctly sets env->hreset_vector=0xfff00000UL; +>> +>> but +>> +>> init_excp_7400() says env->hreset_vector=0x00000000UL; +>> +>> which seems wrong. (the 7400 manual says a hard-reset jumps initializes the +>> prefix to 0xfff00000.) +> +> Do you have a link to a spec saying so? Should be trivial to change then. + +According to MPC7450UM.pdf: + +MSR Bit Settings + +Bit: 25 +Name: IP + +Exception prefix. The setting of this bit specifies whether an exception vector offset is prepended with Fs or 0s. In the following description, nnnnn is the offset of the exception. + + 0 Exceptions are vectored to the physical address 0x000n_nnnn. + 1 Exceptions are vectored to the physical address 0xFFFn_nnnn. + +[...] + +9.9.1 Reset Inputs + +The MPC7450 has two reset inputs, described as follows: +• HRESET (hard reset)—The HRESET signal is used for power-on reset sequences, or for situations in which the MPC7450 must go through the entire cold start sequence of internal hardware initialization. The MPC7450 will initiate burst transactions after power-on reset in 60x bus mode. +• SRESET (soft reset)—The soft reset input provides warm reset capability. This input can be used to avoid forcing the MPC7450 to complete the cold start sequence. +When either reset input negates, the processor attempts to fetch code from the system reset exception vector. The vector is located at offset 0x00100 from the exception prefix (MSR[IP]). + +----> The MSR[IP] bit is set when HRESET negates. + + +So the correct implementation would be to set hreset_vector to 0xfff00000, but also set MSR_IP and clear hreset_vector when MSR_IP gets modified. + +I'll happily take patches :). + + +Alex + + + +Google for MPC7450UM.pdf and MPC7410UM.pdf. These two documents cover the + +7441, 7445, 7451, 7455, 7457, 7447, 7448 and the 7410 and 7400 CPUs, respectively. + +For all these, Alex' description applies. However, (and I made a mistake in my original post), +the setting affected is + +env->hreset_excp_prefix = 0xfff00000UL; + +in addition, hreset_vector should be: + +env->hreset_vector = 0x00000100UL; + +NOTE - I believe the other points raised by Alex (initialize MSR[IP] -- which BTW is called MSR_EP in qemu -- and switching the exception prefix when MSR[IP] is changed) are already correctly handled, see: + +target-ppc/helper.c: cpu_reset() +target-ppc/helper-hreg.h: hreg_store_msr() + +Should I post a patch to the mailing-list? + +Hi Andreas. + +I posted a reply to the bug database. Regarding my 'bios' - it is really +nothing. +I need it to boot RTEMS. It just mocks up a minimal residual and jumps to +the kernel load address. +You can take a look at + +http://www.rtems.org/viewvc/rtems/c/src/lib/libbsp/powerpc/shared/bootloader/ + +The stuff that goes into the dummy 'bios' is qemu_fakerom.S and +qemu_fakeres.c + +Regards +- Till + +On 07/17/2011 05:34 PM, Andreas Färber wrote: +> Hi, +> +> Am 16.07.2011 um 23:49 schrieb till: +> +>> I have a proprietary ROM implementing system calls that are executed +>> via +>> the 'SC' instruction. +>> +>> I use qemu-0.14.1, +>> +>> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel +>> +>> That works fine on a 604 (CPU=0x00040103) - but does not on an +>> emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x80000201). I found +>> that the emulator jumps to 0x00000c00 instead of 0xfff00c00. +>> Probably this is due to a wrong setting in target-ppc/ +>> translate_init.c: +>> +>> init_excp_604() correctly sets env->hreset_vector=0xfff00000UL; +>> +>> but +>> +>> init_excp_7400() says env->hreset_vector=0x00000000UL; +>> +>> which seems wrong. (the 7400 manual says a hard-reset jumps +>> initializes the +>> prefix to 0xfff00000.) +> Do you have a link to a spec saying so? Should be trivial to change +> then. +> +>> Likewise, init_excp_7450() (and probably other, related CPUs) are +>> wrong. +>> +>> Indeed, when I change the value in init_excp_7400() to 0xfff00000UL +>> then +>> everything works as expected for me. +>> +>> ** Affects: qemu +>> Importance: Undecided +>> Status: New +>> Bug description: +>> I have a proprietary ROM implementing system calls that are executed +>> via the 'SC' instruction. +>> +>> I use qemu-0.14.1, +>> +>> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel +> We are currently in the process of revamping the PReP machine you are +> using above. Is your BIOS available publicly so that we can test we +> don't break anything for you? +> +> Andreas +> + + + +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 no longer have the test readily available. So I tried to print the initial MSR and IP register contents from the QEMU monitor: + +qemu-system-ppc -machine none -cpu 7400 -S -monitor stdio +QEMU 5.0.93 monitor - type 'help' for more information +(qemu) info registers +NIP 00000000 LR 00000000 CTR 00000000 XER 00000000 CPU#0 +MSR 00000000 HID0 00000000 HF 00000000 iidx 0 didx 0 +Segmentation fault (core dumped) + +Unfortunately this lets qemu (tried 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.29) as well as 5.1.0-rc3) segfault; apparently the time-base is not initialized but still accessed when -machine == none. Yet another bug, it seems. The NIP and MSR seem wrong, however. + +I can generate an empty ppc_rom.bin and fool a prep machine under 2.11.1: + +till@tillp1 $ ls -l empty.bin +-rw-r--r-- 1 till till 0 Aug 8 12:03 empty.bin + +till@tillp1 $ qemu-system-ppc -bios ./empty.bin -cpu 7400 -machine prep -S -monitor stdio +QEMU 2.11.1 monitor - type 'help' for more information +(qemu) info registers +NIP fff00100 LR 00000000 CTR 00000000 XER 00000000 CPU#0 +MSR 00000040 HID0 00000000 HF 00000000 iidx 3 didx 3 + +Here, the issue is fixed! Apparently it is fixed for the 'prep' machine but not 'none'. Unfortunately 'prep' is gone from 5.3.0 and 'none' is buggy; wait - it seems I can emulate 'prep' with '40p': + +till@tillp1 $ build/ppc-softmmu/qemu-system-ppc -machine 40p -cpu 7400 -S -monitor stdio +QEMU 5.0.93 monitor - type 'help' for more information +(qemu) info registers +NIP fff00100 LR 00000000 CTR 00000000 XER 00000000 CPU#0 +MSR 00000040 HID0 00000000 HF 00000000 iidx 3 didx 3 + +This looks good, so I suppose it is OK to close this bug. + + + + + +Ok, thanks for checking! I'll keep the bug open, though, in case someone wants to have a look at the segfault with the "none" machine. + +Please don't close ticket if there's a known problem just to at least +document there's a problem. Is this a CPU feature or board specific? + +Doesn't these CPUs have some way to select the exception vectors base and +could that be set wrong? I've also seen some problems with these CPUs but +last time I asked nobody answered: +https://lists.nongnu.org/archive/html/qemu-ppc/2020-03/msg00292.html +Could this bug be related to that? + + +Yes, it is a CPU feature, and yes you can select the exception vector prefix with the MSR[IP] bit which should be set by a hardware reset. The initial value seems wrong in qemu but that seems to fixed by the machine-specific initialization. The 'none' machine, however, just uses generic code and does not do anything PPC-specific. This means that + + - the MSR and probably other registers, too, are not initialized to what the hardware + documentation specifies as reset values. + - the time-base is not initialized at all (and this leads to a segfault when you start the + ppc 'none' machine) + - probably other things are not properly initialized. I wonder, e.g., about the MMU... + +It seems that all registers are simply initialized to zero. Then, there seems to be a 'reset' function which initializes the registers to the proper reset values (well - sort of bug 812398 reports that HID0 is not properly initialized by some CPU flavours). However, that reset function +is not executed by the 'none' machine initialization.... + + +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/85 + + diff --git a/results/classifier/zero-shot/108/permissions/818647 b/results/classifier/zero-shot/108/permissions/818647 new file mode 100644 index 000000000..2648a8ca1 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/818647 @@ -0,0 +1,338 @@ +permissions: 0.931 +other: 0.918 +device: 0.912 +debug: 0.873 +boot: 0.859 +semantic: 0.851 +graphic: 0.849 +PID: 0.844 +vnc: 0.834 +socket: 0.824 +performance: 0.804 +files: 0.799 +KVM: 0.777 +network: 0.772 + +Getting segmentation fault when trying to boot FreeBSD + +wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1 +commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5 + +wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ qemu-system-sparc64 --version +QEMU emulator version 0.15.50, Copyright (c) 2003-2008 Fabrice Bellard + +wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ uname -a +Linux wkoszek 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux + +Qemu built with default settings (./configure --prefix=<path> && make && make install) + +I run FreeBSD ISO image: +/home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d + +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Loading a.out image... +Loaded 7680 bytes +entry point is 0x4000 + +Jumping to entry point 0000000000004000 for type 0000000000000005... +switching to new context: entry point 0x4000 stack 0x00000000ffe86b49 + +>> FreeBSD/sparc64 boot block + Boot path: cdrom:f + Boot loader: /boot/loader +Consoles: Open Firmware console + +Booting with sun4u support. +Boot path set to cdrom:a + +FreeBSD/sparc64 bootstrap loader, Revision 1.0 +(<email address hidden>, Fri Feb 18 05:38:31 UTC 2011) +bootpath="cdrom:a" +Loading /boot/defaults/loader.conf +/boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966] +| +Unimplemented service milliseconds ([0] -- [1]) +Hit [Enter] to boot immediately, or any other key for command prompt. +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) + +I press CTRL + C and I get out of the looped warning about "unimplemented service". Then I see: + +Type '?' for a list of commands, 'help' for more detailed help. +OK boot +jumping to kernel entry at 0xc0078000. +BOOTUnhandled Exception 0x0000000000000034 +PC = 0x00000000c0637454 NPC = 0x00000000c0637458 + +I wanted to start FreeBSD debugging here - I pressed 'CTRL+A c', I was dropped to the monitor. + +FRom the monitor I typed: + +Stopping execution +QEMU 0.15.50 monitor - type 'help' for more information +(qemu) x 0xc0078000 +00000000c0078000: Cannot access memory +(qemu) x 0x00000000c0637454 +00000000c0637454: Cannot access memory +(qemu) x 0x00000000c0637458 +00000000c0637458: Cannot access memory +(qemu) xp 0xc0078000 +Segmentation fault + +IMO it shouldn't have crashed. + +On Sat, Jul 30, 2011 at 9:13 PM, Wojciech Koszek +<email address hidden> wrote: +> Public bug reported: +> +> wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1 +> commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5 +> +> wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ qemu-system-sparc64 --version +> QEMU emulator version 0.15.50, Copyright (c) 2003-2008 Fabrice Bellard +> +> wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ uname -a +> Linux wkoszek 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux +> +> Qemu built with default settings (./configure --prefix=<path> && make && +> make install) +> +> I run FreeBSD ISO image: +> /home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d +> +> Configuration device id QEMU version 1 machine id 0 +> kernel cmdline +> CPUs: 1 x SUNW,UltraSPARC-IIi +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 +> Type 'help' for detailed information +> Trying cdrom:f... +> Not a bootable ELF image +> Loading a.out image... +> Loaded 7680 bytes +> entry point is 0x4000 +> +> Jumping to entry point 0000000000004000 for type 0000000000000005... +> switching to new context: entry point 0x4000 stack 0x00000000ffe86b49 +> +>>> FreeBSD/sparc64 boot block +> Boot path: cdrom:f +> Boot loader: /boot/loader +> Consoles: Open Firmware console +> +> Booting with sun4u support. +> Boot path set to cdrom:a +> +> FreeBSD/sparc64 bootstrap loader, Revision 1.0 +> (<email address hidden>, Fri Feb 18 05:38:31 UTC 2011) +> bootpath="cdrom:a" +> Loading /boot/defaults/loader.conf +> /boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966] +> | +> Unimplemented service milliseconds ([0] -- [1]) +> Hit [Enter] to boot immediately, or any other key for command prompt. +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> +> I press CTRL + C and I get out of the looped warning about +> "unimplemented service". Then I see: +> +> Type '?' for a list of commands, 'help' for more detailed help. +> OK boot +> jumping to kernel entry at 0xc0078000. +> BOOTUnhandled Exception 0x0000000000000034 +> PC = 0x00000000c0637454 NPC = 0x00000000c0637458 +> +> I wanted to start FreeBSD debugging here - I pressed 'CTRL+A c', I was +> dropped to the monitor. +> +> FRom the monitor I typed: +> +> Stopping execution +> QEMU 0.15.50 monitor - type 'help' for more information +> (qemu) x 0xc0078000 +> 00000000c0078000: Cannot access memory +> (qemu) x 0x00000000c0637454 +> 00000000c0637454: Cannot access memory +> (qemu) x 0x00000000c0637458 +> 00000000c0637458: Cannot access memory +> (qemu) xp 0xc0078000 +> Segmentation fault +> +> IMO it shouldn't have crashed. + +Right. + +FYI: the virtual to physical translations can be examined (before the +exception printout) with 'info tlb': +jumping to kernel entry at 0xc0078000. +QEMU 0.15.50 monitor - type 'help' for more information +(qemu) info tlb +MMU contexts: Primary: 0, Secondary: 0 +DMMU dump +[00] VA: ffe00000, PA: 7e80000, 512k, priv, RW, locked, ctx 0 local +[01] VA: ffe80000, PA: 7f00000, 512k, priv, RW, locked, ctx 0 local +[02] VA: fff00000, PA: 7f80000, 512k, priv, RW, locked, ctx 0 local +[03] VA: ffd00000, PA: 1fff0000000, 512k, priv, RO, locked, ctx 0 local +[04] VA: ffd80000, PA: 1fff0080000, 512k, priv, RO, locked, ctx 0 local +[05] VA: c864e000, PA: 580c000, 8k, priv, RW, unlocked, ctx 0 local +[06] VA: fe000000, PA: 1ff00800000, 4M, priv, RW, locked, ctx 0 local +[07] VA: fe400000, PA: 1ff00c00000, 4M, priv, RW, locked, ctx 0 local +[08] VA: bfc00000, PA: 0, 4M, priv, RW, locked, ctx 0 local +[09] VA: c8658000, PA: 5814000, 8k, priv, RW, unlocked, ctx 0 local +[10] VA: c4080000, PA: 5480000, 8k, priv, RW, unlocked, ctx 0 local +[11] VA: c4082000, PA: 5482000, 8k, priv, RW, unlocked, ctx 0 local +[12] VA: c4084000, PA: 5484000, 8k, priv, RW, unlocked, ctx 0 local +[13] VA: c4086000, PA: 5486000, 8k, priv, RW, unlocked, ctx 0 local +[14] VA: c4088000, PA: 5488000, 8k, priv, RW, unlocked, ctx 0 local +[15] VA: fffff80005a52000, PA: 5800000, 4M, user, RW, unlocked, ctx 0 local +[16] VA: c3fc8000, PA: 53c8000, 8k, priv, RW, unlocked, ctx 0 local +[17] VA: c3fca000, PA: 53ca000, 8k, priv, RW, unlocked, ctx 0 local +[18] VA: c3fcc000, PA: 53cc000, 8k, priv, RW, unlocked, ctx 0 local +[19] VA: c3fce000, PA: 53ce000, 8k, priv, RW, unlocked, ctx 0 local +[20] VA: c3fd0000, PA: 53d0000, 8k, priv, RW, unlocked, ctx 0 local +[21] VA: c3fd2000, PA: 53d2000, 8k, priv, RW, unlocked, ctx 0 local +[22] VA: c3fd4000, PA: 53d4000, 8k, priv, RW, unlocked, ctx 0 local +[23] VA: c3fd6000, PA: 53d6000, 8k, priv, RW, unlocked, ctx 0 local +[24] VA: c3fd8000, PA: 53d8000, 8k, priv, RW, unlocked, ctx 0 local +[25] VA: c3fda000, PA: 53da000, 8k, priv, RW, unlocked, ctx 0 local +[26] VA: c3fdc000, PA: 53dc000, 8k, priv, RW, unlocked, ctx 0 local +[27] VA: c3fde000, PA: 53de000, 8k, priv, RW, unlocked, ctx 0 local +[28] VA: c3fe0000, PA: 53e0000, 8k, priv, RW, unlocked, ctx 0 local +[29] VA: c3fe2000, PA: 53e2000, 8k, priv, RW, unlocked, ctx 0 local +[30] VA: c3fe4000, PA: 53e4000, 8k, priv, RW, unlocked, ctx 0 local +[31] VA: c3fe6000, PA: 53e6000, 8k, priv, RW, unlocked, ctx 0 local +[32] VA: c3fe8000, PA: 53e8000, 8k, priv, RW, unlocked, ctx 0 local +[33] VA: fffff8000106a000, PA: 1000000, 4M, user, RW, unlocked, ctx 0 local +[34] VA: c1016000, PA: 416000, 8k, priv, RW, unlocked, ctx 0 local +[35] VA: fffff8000040e000, PA: 400000, 4M, user, RW, unlocked, ctx 0 local +[36] VA: c7bae000, PA: 6e78000, 8k, priv, RW, unlocked, ctx 0 local +[37] VA: c7bb8000, PA: 5a14000, 8k, priv, RW, unlocked, ctx 0 local +[38] VA: fffff80006e70000, PA: 6c00000, 4M, user, RW, unlocked, ctx 0 local +[39] VA: c7be2000, PA: 6e6c000, 8k, priv, RW, unlocked, ctx 0 local +[40] VA: fffff8000201a000, PA: 2000000, 4M, user, RW, unlocked, ctx 0 local +[41] VA: c101a000, PA: 201a000, 8k, priv, RW, unlocked, ctx 0 local +[42] VA: c101c000, PA: 201c000, 8k, priv, RW, unlocked, ctx 0 local +[43] VA: c101e000, PA: 201e000, 8k, priv, RW, unlocked, ctx 0 local +[44] VA: c1020000, PA: 2020000, 8k, priv, RW, unlocked, ctx 0 local +[45] VA: c85cc000, PA: 6e44000, 8k, priv, RW, unlocked, ctx 0 local +[46] VA: c85d6000, PA: 6e4c000, 8k, priv, RW, unlocked, ctx 0 local +[47] VA: c85e0000, PA: 6e54000, 8k, priv, RW, unlocked, ctx 0 local +[48] VA: c85ea000, PA: 6e5c000, 8k, priv, RW, unlocked, ctx 0 local +[49] VA: c85f4000, PA: 6e04000, 8k, priv, RW, unlocked, ctx 0 local +[50] VA: c85fe000, PA: 6e0c000, 8k, priv, RW, unlocked, ctx 0 local +[51] VA: c8608000, PA: 6e14000, 8k, priv, RW, unlocked, ctx 0 local +[52] VA: c3fb8000, PA: 53b8000, 8k, priv, RW, unlocked, ctx 0 local +[53] VA: c8612000, PA: 6e1c000, 8k, priv, RW, unlocked, ctx 0 local +[54] VA: c3fbc000, PA: 53bc000, 8k, priv, RW, unlocked, ctx 0 local +[55] VA: c861c000, PA: 6e24000, 8k, priv, RW, unlocked, ctx 0 local +[56] VA: c8626000, PA: 6e2c000, 8k, priv, RW, unlocked, ctx 0 local +[57] VA: c8630000, PA: 6e34000, 8k, priv, RW, unlocked, ctx 0 local +[58] VA: c863a000, PA: 6e3c000, 8k, priv, RW, unlocked, ctx 0 local +[59] VA: c8644000, PA: 5804000, 8k, priv, RW, unlocked, ctx 0 local +[60] VA: c0c00000, PA: 5c00000, 4M, priv, RW, locked, ctx 0 local +[61] VA: c0800000, PA: 6000000, 4M, priv, RW, locked, ctx 0 local +[62] VA: c0400000, PA: 6400000, 4M, priv, RW, locked, ctx 0 local +[63] VA: c0000000, PA: 6800000, 4M, priv, RW, locked, ctx 0 local +IMMU dump +[00] VA: ffd00000, PA: 1fff0000000, 512k, priv, locked, ctx 0 local +[01] VA: fe000000, PA: 1ff00800000, 4M, priv, locked, ctx 0 local +[02] VA: fe400000, PA: 1ff00c00000, 4M, priv, locked, ctx 0 local +[60] VA: c0c00000, PA: 5c00000, 4M, priv, locked, ctx 0 local +[61] VA: c0800000, PA: 6000000, 4M, priv, locked, ctx 0 local +[62] VA: c0400000, PA: 6400000, 4M, priv, locked, ctx 0 local +[63] VA: c0000000, PA: 6800000, 4M, priv, locked, ctx 0 local +(qemu) BOOTUnhandled Exception 0x0000000000000034 +PC = 0x00000000c0637454 NPC = 0x00000000c0637458 +Stopping execution + +(qemu) xp/i 0x6637454 +0x0000000006637454: ld [ %i1 + 4 ], %g1 + +But it's easier to use GDB for debugging (add -s -S switches, attach +with Sparc GDB): +$ sparc64-linux-gdb +GNU gdb 6.8 +Copyright (C) 2008 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "--host=x86_64-unknown-linux-gnu +--target=sparc64-linux". +(gdb) set architecture sparc:v9 +The target architecture is assumed to be sparc:v9 +(gdb) b *0x00000000c0637454 +Breakpoint 1 at 0xc0637454 +(gdb) target remote :1234 +[New Thread 1] +0x000001fff0000020 in ?? () +(gdb) c +Breakpoint 1, 0x00000000c0637454 in ?? () +(gdb) info registers +g0 0x0 0x0 +g1 0xc08eb730 0xc08eb730 +g2 0xc08ee910 0xc08ee910 +g3 0xc08eb730 0xc08eb730 +g4 0x186a1 0x186a1 +g5 0xfffff8000040fff8 0xfffff8000040fff8 +g6 0xc1017980 0xc1017980 +g7 0xc093ad68 0xc093ad68 +o0 0xc08ee8f0 0xc08ee8f0 +o1 0xc08eb730 0xc08eb730 +o2 0x0 0x0 +o3 0x0 0x0 +o4 0x0 0x0 +o5 0x0 0x0 +sp 0xc0940299 0xc0940299 +o7 0xc063744c 0xc063744c +l0 0xc08eb730 0xc08eb730 +l1 0x0 0x0 +l2 0x0 0x0 +l3 0xffffffffffffffff 0xffffffffffffffff +l4 0xfffff80001078c70 0xfffff80001078c70 +l5 0xc080b908 0xc080b908 +l6 0xfffff80001084c60 0xfffff80001084c60 +l7 0xc0898320 0xc0898320 +i0 0x0 0x0 +i1 0xffffffffffffffff 0xffffffffffffffff +i2 0x0 0x0 +i3 0x88ca6c00 0x88ca6c00 +i4 0x0 0x0 +i5 0x57e 0x57e +fp 0xc0940399 0xc0940399 +i7 0xc06373e0 0xc06373e0 +pc 0xc0637454 0xc0637454 +npc 0xc0637458 0xc0637458 +state 0x4415001407 0x4415001407 +fsr 0x0 [ ] +fprs 0x0 [ ] +y 0x0 0x0 +cwp 0x7 0x7 +pstate 0x14 [ PRIV PEF ] +asi 0x15 0x15 +ccr 0x44 0x44 +(gdb) disassemble $pc $pc+4 +Dump of assembler code from 0xc0637454 to 0xc0637458: +0x00000000c0637454: ld [ %i1 + 4 ], %g1 +End of assembler dump. + + +Fixed by 67494323f2c782fe3e65c60529fe9dfa613fc500. + + diff --git a/results/classifier/zero-shot/108/permissions/830833 b/results/classifier/zero-shot/108/permissions/830833 new file mode 100644 index 000000000..bde1e3bb8 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/830833 @@ -0,0 +1,129 @@ +permissions: 0.948 +PID: 0.941 +boot: 0.929 +graphic: 0.929 +semantic: 0.924 +debug: 0.919 +socket: 0.915 +performance: 0.905 +other: 0.904 +device: 0.904 +files: 0.886 +vnc: 0.863 +network: 0.863 +KVM: 0.794 + +sparc emulators fail to boot + +The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) doesn't boot sparc. It fails to boot both Linux and NetBSD kernels with this error: + +Configuration device id QEMU version 1 machine id 32 +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 + Type 'help' for detailed information +Trying disk... +Unhandled Exception 0x0000002a +PC = 0xffd10bdc NPC = 0xffd10be0 +Stopping execution + +On Mon, Aug 22, 2011 at 3:19 AM, Nigel Horne <email address hidden> wrote: +> Public bug reported: +> +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels with +> this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution + +This was a bug in OpenBIOS, fixed in r1047. Maybe I should update the +image for QEMU. + +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/830833 +> +> Title: +> sparc emulators fail to boot +> +> Status in QEMU: +> New +> +> Bug description: +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels +> with this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/830833/+subscriptions +> +> + + +Please do update the binary openbios images for QEMU, it would be a great help!! + +On Wed, Sep 28, 2011 at 8:22 PM, <email address hidden> +<email address hidden> wrote: +> Please do update the binary openbios images for QEMU, it would be a +> great help!! + +Updated, please test. + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/830833 +> +> Title: +> sparc emulators fail to boot +> +> Status in QEMU: +> New +> +> Bug description: +> The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) +> doesn't boot sparc. It fails to boot both Linux and NetBSD kernels +> with this error: +> +> Configuration device id QEMU version 1 machine id 32 +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 +> Type 'help' for detailed information +> Trying disk... +> Unhandled Exception 0x0000002a +> PC = 0xffd10bdc NPC = 0xffd10be0 +> Stopping execution +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/830833/+subscriptions +> +> + + +Should be fixed according to the comments from blueswirl ==> setting status to "Fix Released" + diff --git a/results/classifier/zero-shot/108/permissions/85542195 b/results/classifier/zero-shot/108/permissions/85542195 new file mode 100644 index 000000000..328f31033 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/85542195 @@ -0,0 +1,130 @@ +permissions: 0.968 +PID: 0.945 +other: 0.944 +semantic: 0.941 +graphic: 0.938 +device: 0.936 +performance: 0.933 +boot: 0.932 +vnc: 0.923 +files: 0.920 +debug: 0.915 +socket: 0.905 +network: 0.899 +KVM: 0.898 + +[Qemu-devel] [Bug in qemu-system-ppc running Mac OS 9 on Windows 10] + +Hi all, + +I've been experiencing issues when installing Mac OS 9.x using +qemu-system-ppc.exe in Windows 10. After booting from CD image, +partitioning a fresh disk image often hangs Qemu. When using a +pre-partitioned disk image, the OS installation process halts +somewhere during the process. The issues can be resolved by setting +qemu-system-ppc.exe to run in Windows 7 compatibility mode. +AFAIK all Qemu builds for Windows since Mac OS 9 became available as +guest are affected. +The issue is reproducible by installing Qemu for Windows from Stephan +Weil on Windows 10 and boot/install Mac OS 9.x + +Best regards and thanks for looking into this, +Howard + +On Nov 25, 2016, at 9:26 AM, address@hidden wrote: +Hi all, + +I've been experiencing issues when installing Mac OS 9.x using +qemu-system-ppc.exe in Windows 10. After booting from CD image, +partitioning a fresh disk image often hangs Qemu. When using a +pre-partitioned disk image, the OS installation process halts +somewhere during the process. The issues can be resolved by setting +qemu-system-ppc.exe to run in Windows 7 compatibility mode. +AFAIK all Qemu builds for Windows since Mac OS 9 became available as +guest are affected. +The issue is reproducible by installing Qemu for Windows from Stephan +Weil on Windows 10 and boot/install Mac OS 9.x + +Best regards and thanks for looking into this, +Howard +I assume there was some kind of behavior change for some of the +Windows API between Windows 7 and Windows 10, that is my guess as to +why the compatibility mode works. Could you run 'make check' on your +system, once in Windows 7 and once in Windows 10. Maybe the tests +will tell us something. I'm hoping that one of the tests succeeds in +Windows 7 and fails in Windows 10. That would help us pinpoint what +the problem is. +What I mean by run in Windows 7 is set the mingw environment to run +in Windows 7 compatibility mode (if possible). If you have Windows 7 +on another partition you could boot from, that would be better. +Good luck. +p.s. use 'make check -k' to allow all the tests to run (even if one +or more of the tests fails). + +> +> Hi all, +> +> +> +> I've been experiencing issues when installing Mac OS 9.x using +> +> qemu-system-ppc.exe in Windows 10. After booting from CD image, +> +> partitioning a fresh disk image often hangs Qemu. When using a +> +> pre-partitioned disk image, the OS installation process halts +> +> somewhere during the process. The issues can be resolved by setting +> +> qemu-system-ppc.exe to run in Windows 7 compatibility mode. +> +> AFAIK all Qemu builds for Windows since Mac OS 9 became available as +> +> guest are affected. +> +> The issue is reproducible by installing Qemu for Windows from Stephan +> +> Weil on Windows 10 and boot/install Mac OS 9.x +> +> +> +> Best regards and thanks for looking into this, +> +> Howard +> +> +> +I assume there was some kind of behavior change for some of the Windows API +> +between Windows 7 and Windows 10, that is my guess as to why the +> +compatibility mode works. Could you run 'make check' on your system, once in +> +Windows 7 and once in Windows 10. Maybe the tests will tell us something. +> +I'm hoping that one of the tests succeeds in Windows 7 and fails in Windows +> +10. That would help us pinpoint what the problem is. +> +> +What I mean by run in Windows 7 is set the mingw environment to run in +> +Windows 7 compatibility mode (if possible). If you have Windows 7 on another +> +partition you could boot from, that would be better. +> +> +Good luck. +> +> +p.s. use 'make check -k' to allow all the tests to run (even if one or more +> +of the tests fails). +Hi, + +Thank you for you suggestion, but I have no means to run the check you +suggest. I cross-compile from Linux. + +Best regards, +Howard + diff --git a/results/classifier/zero-shot/108/permissions/878 b/results/classifier/zero-shot/108/permissions/878 new file mode 100644 index 000000000..14b2772b4 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/878 @@ -0,0 +1,57 @@ +permissions: 0.946 +other: 0.931 +debug: 0.903 +graphic: 0.901 +semantic: 0.878 +device: 0.876 +files: 0.872 +performance: 0.850 +network: 0.799 +PID: 0.799 +KVM: 0.793 +boot: 0.778 +vnc: 0.763 +socket: 0.694 + +Can't bind PCI device behind a PCI bridge (No such device) +Description of problem: +Qemu fails to assign the device with : +``` +qemu-system-x86_64: -device vfio-pci,host=3b:00.0: vfio 0000:3b:00.0: error getting device from group 72: No such device +Verify all devices in group 72 are bound to vfio-<bus> or pci-stub and not already in use +``` + +Looking at strace, we can see that the device is behind a PCI bridge: +``` +lstat("/sys", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 +lstat("/sys/bus", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci/devices/0000:3b:00.0", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 +readlink("/sys/bus/pci/devices/0000:3b:00.0", "../../../devices/pci0000:3a/0000"..., 4095) = 53 +lstat("/sys/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0/subsystem", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 +readlink("/sys/devices/pci0000:3a/0000:3a:02.0/0000:3b:00.0/subsystem", "../../../../bus/pci", 4095) = 19 +lstat("/sys/bus", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +lstat("/sys/bus/pci", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 +ioctl(14, VFIO_GROUP_GET_DEVICE_FD, 0x56267b3b1320) = -1 ENODEV (No such device) +``` + +The issue is that the PCI bridge `0000:3a:02.0`, is used by "pcieport" kernel driver and not "vfio-pci". +After manually unbinding the PCI bridge from it's driver and binding it to vfio-pci qemu successfully attaches it to the VM. + +I saw online that qemu is suposed to automaticly unbind devices from the host, make them available to the VM and restore them to their previous state once the VM is shutdown. +This is not happening here. +Steps to reproduce: +1. Have a PCI device behind a PCI bridge +2. Launch a VM with the PCI device attached +3. Observe similar error messages +Additional information: +After reading [kernel vfio doc](https://www.kernel.org/doc/html/latest/driver-api/vfio.html#vfio-usage-example), I can see that `ls -l /sys/bus/pci/devices/0000:3b:00.0/iommu_group/devices` was supposed to list the PCI bridge, but it is not the case for me. + +I could only notice the presence of the bridge by looking in the `/sys/bus/pci/devices/0000:3b:00.0` symlink. + +Maybe qemu misses it because of that ? diff --git a/results/classifier/zero-shot/108/permissions/88281850 b/results/classifier/zero-shot/108/permissions/88281850 new file mode 100644 index 000000000..02513facf --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/88281850 @@ -0,0 +1,291 @@ +permissions: 0.985 +other: 0.983 +debug: 0.979 +graphic: 0.974 +network: 0.973 +device: 0.970 +performance: 0.969 +semantic: 0.968 +boot: 0.967 +socket: 0.966 +files: 0.962 +PID: 0.959 +vnc: 0.945 +KVM: 0.881 + +[Bug] Take more 150s to boot qemu on ARM64 + +Hi all, +I encounter a issue with kernel 5.19-rc1 on a ARM64 board: it takes +about 150s between beginning to run qemu command and beginng to boot +Linux kernel ("EFI stub: Booting Linux Kernel..."). +But in kernel 5.18-rc4, it only takes about 5s. I git bisect the kernel +code and it finds c2445d387850 ("srcu: Add contention check to +call_srcu() srcu_data ->lock acquisition"). +The qemu (qemu version is 6.2.92) command i run is : + +./qemu-system-aarch64 -m 4G,slots=4,maxmem=8g \ +--trace "kvm*" \ +-cpu host \ +-machine virt,accel=kvm,gic-version=3 \ +-machine smp.cpus=2,smp.sockets=2 \ +-no-reboot \ +-nographic \ +-monitor unix:/home/cx/qmp-test,server,nowait \ +-bios /home/cx/boot/QEMU_EFI.fd \ +-kernel /home/cx/boot/Image \ +-device +pcie-root-port,port=0x8,chassis=1,id=net1,bus=pcie.0,multifunction=on,addr=0x1 +\ +-device vfio-pci,host=7d:01.3,id=net0 \ +-device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4 \ +-drive file=/home/cx/boot/boot_ubuntu.img,if=none,id=drive0 \ +-append "rdinit=init console=ttyAMA0 root=/dev/vda rootfstype=ext4 rw " \ +-net none \ +-D /home/cx/qemu_log.txt +I am not familiar with rcu code, and don't know how it causes the issue. +Do you have any idea about this issue? +Best Regard, + +Xiang Chen + +On Mon, Jun 13, 2022 at 08:26:34PM +0800, chenxiang (M) wrote: +> +Hi all, +> +> +I encounter a issue with kernel 5.19-rc1 on a ARM64 board: it takes about +> +150s between beginning to run qemu command and beginng to boot Linux kernel +> +("EFI stub: Booting Linux Kernel..."). +> +> +But in kernel 5.18-rc4, it only takes about 5s. I git bisect the kernel code +> +and it finds c2445d387850 ("srcu: Add contention check to call_srcu() +> +srcu_data ->lock acquisition"). +> +> +The qemu (qemu version is 6.2.92) command i run is : +> +> +./qemu-system-aarch64 -m 4G,slots=4,maxmem=8g \ +> +--trace "kvm*" \ +> +-cpu host \ +> +-machine virt,accel=kvm,gic-version=3 \ +> +-machine smp.cpus=2,smp.sockets=2 \ +> +-no-reboot \ +> +-nographic \ +> +-monitor unix:/home/cx/qmp-test,server,nowait \ +> +-bios /home/cx/boot/QEMU_EFI.fd \ +> +-kernel /home/cx/boot/Image \ +> +-device +> +pcie-root-port,port=0x8,chassis=1,id=net1,bus=pcie.0,multifunction=on,addr=0x1 +> +\ +> +-device vfio-pci,host=7d:01.3,id=net0 \ +> +-device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4 \ +> +-drive file=/home/cx/boot/boot_ubuntu.img,if=none,id=drive0 \ +> +-append "rdinit=init console=ttyAMA0 root=/dev/vda rootfstype=ext4 rw " \ +> +-net none \ +> +-D /home/cx/qemu_log.txt +> +> +I am not familiar with rcu code, and don't know how it causes the issue. Do +> +you have any idea about this issue? +Please see the discussion here: +https://lore.kernel.org/all/20615615-0013-5adc-584f-2b1d5c03ebfc@linaro.org/ +Though that report requires ACPI to be forced on to get the +delay, which results in more than 9,000 back-to-back calls to +synchronize_srcu_expedited(). I cannot reproduce this on my setup, even +with an artificial tight loop invoking synchronize_srcu_expedited(), +but then again I don't have ARM hardware. + +My current guess is that the following patch, but with larger values for +SRCU_MAX_NODELAY_PHASE. Here "larger" might well be up in the hundreds, +or perhaps even larger. + +If you get a chance to experiment with this, could you please reply +to the discussion at the above URL? (Or let me know, and I can CC +you on the next message in that thread.) + + Thanx, Paul + +------------------------------------------------------------------------ + +diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c +index 50ba70f019dea..0db7873f4e95b 100644 +--- a/kernel/rcu/srcutree.c ++++ b/kernel/rcu/srcutree.c +@@ -513,7 +513,7 @@ static bool srcu_readers_active(struct srcu_struct *ssp) + + #define SRCU_INTERVAL 1 // Base delay if no expedited GPs +pending. + #define SRCU_MAX_INTERVAL 10 // Maximum incremental delay from slow +readers. +-#define SRCU_MAX_NODELAY_PHASE 1 // Maximum per-GP-phase consecutive +no-delay instances. ++#define SRCU_MAX_NODELAY_PHASE 3 // Maximum per-GP-phase consecutive +no-delay instances. + #define SRCU_MAX_NODELAY 100 // Maximum consecutive no-delay +instances. + + /* +@@ -522,16 +522,22 @@ static bool srcu_readers_active(struct srcu_struct *ssp) + */ + static unsigned long srcu_get_delay(struct srcu_struct *ssp) + { ++ unsigned long gpstart; ++ unsigned long j; + unsigned long jbase = SRCU_INTERVAL; + + if (ULONG_CMP_LT(READ_ONCE(ssp->srcu_gp_seq), +READ_ONCE(ssp->srcu_gp_seq_needed_exp))) + jbase = 0; +- if (rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq))) +- jbase += jiffies - READ_ONCE(ssp->srcu_gp_start); +- if (!jbase) { +- WRITE_ONCE(ssp->srcu_n_exp_nodelay, +READ_ONCE(ssp->srcu_n_exp_nodelay) + 1); +- if (READ_ONCE(ssp->srcu_n_exp_nodelay) > SRCU_MAX_NODELAY_PHASE) +- jbase = 1; ++ if (rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq))) { ++ j = jiffies - 1; ++ gpstart = READ_ONCE(ssp->srcu_gp_start); ++ if (time_after(j, gpstart)) ++ jbase += j - gpstart; ++ if (!jbase) { ++ WRITE_ONCE(ssp->srcu_n_exp_nodelay, +READ_ONCE(ssp->srcu_n_exp_nodelay) + 1); ++ if (READ_ONCE(ssp->srcu_n_exp_nodelay) > +SRCU_MAX_NODELAY_PHASE) ++ jbase = 1; ++ } + } + return jbase > SRCU_MAX_INTERVAL ? SRCU_MAX_INTERVAL : jbase; + } + +å¨ 2022/6/13 21:22, Paul E. McKenney åé: +On Mon, Jun 13, 2022 at 08:26:34PM +0800, chenxiang (M) wrote: +Hi all, + +I encounter a issue with kernel 5.19-rc1 on a ARM64 board: it takes about +150s between beginning to run qemu command and beginng to boot Linux kernel +("EFI stub: Booting Linux Kernel..."). + +But in kernel 5.18-rc4, it only takes about 5s. I git bisect the kernel code +and it finds c2445d387850 ("srcu: Add contention check to call_srcu() +srcu_data ->lock acquisition"). + +The qemu (qemu version is 6.2.92) command i run is : + +./qemu-system-aarch64 -m 4G,slots=4,maxmem=8g \ +--trace "kvm*" \ +-cpu host \ +-machine virt,accel=kvm,gic-version=3 \ +-machine smp.cpus=2,smp.sockets=2 \ +-no-reboot \ +-nographic \ +-monitor unix:/home/cx/qmp-test,server,nowait \ +-bios /home/cx/boot/QEMU_EFI.fd \ +-kernel /home/cx/boot/Image \ +-device +pcie-root-port,port=0x8,chassis=1,id=net1,bus=pcie.0,multifunction=on,addr=0x1 +\ +-device vfio-pci,host=7d:01.3,id=net0 \ +-device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4 \ +-drive file=/home/cx/boot/boot_ubuntu.img,if=none,id=drive0 \ +-append "rdinit=init console=ttyAMA0 root=/dev/vda rootfstype=ext4 rw " \ +-net none \ +-D /home/cx/qemu_log.txt + +I am not familiar with rcu code, and don't know how it causes the issue. Do +you have any idea about this issue? +Please see the discussion here: +https://lore.kernel.org/all/20615615-0013-5adc-584f-2b1d5c03ebfc@linaro.org/ +Though that report requires ACPI to be forced on to get the +delay, which results in more than 9,000 back-to-back calls to +synchronize_srcu_expedited(). I cannot reproduce this on my setup, even +with an artificial tight loop invoking synchronize_srcu_expedited(), +but then again I don't have ARM hardware. + +My current guess is that the following patch, but with larger values for +SRCU_MAX_NODELAY_PHASE. Here "larger" might well be up in the hundreds, +or perhaps even larger. + +If you get a chance to experiment with this, could you please reply +to the discussion at the above URL? (Or let me know, and I can CC +you on the next message in that thread.) +Ok, thanks, i will reply it on above URL. +Thanx, Paul + +------------------------------------------------------------------------ + +diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c +index 50ba70f019dea..0db7873f4e95b 100644 +--- a/kernel/rcu/srcutree.c ++++ b/kernel/rcu/srcutree.c +@@ -513,7 +513,7 @@ static bool srcu_readers_active(struct srcu_struct *ssp) +#define SRCU_INTERVAL 1 // Base delay if no expedited GPs pending. +#define SRCU_MAX_INTERVAL 10 // Maximum incremental delay from slow +readers. +-#define SRCU_MAX_NODELAY_PHASE 1 // Maximum per-GP-phase consecutive +no-delay instances. ++#define SRCU_MAX_NODELAY_PHASE 3 // Maximum per-GP-phase consecutive +no-delay instances. + #define SRCU_MAX_NODELAY 100 // Maximum consecutive no-delay +instances. +/* +@@ -522,16 +522,22 @@ static bool srcu_readers_active(struct srcu_struct *ssp) + */ + static unsigned long srcu_get_delay(struct srcu_struct *ssp) + { ++ unsigned long gpstart; ++ unsigned long j; + unsigned long jbase = SRCU_INTERVAL; +if (ULONG_CMP_LT(READ_ONCE(ssp->srcu_gp_seq), READ_ONCE(ssp->srcu_gp_seq_needed_exp))) +jbase = 0; +- if (rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq))) +- jbase += jiffies - READ_ONCE(ssp->srcu_gp_start); +- if (!jbase) { +- WRITE_ONCE(ssp->srcu_n_exp_nodelay, +READ_ONCE(ssp->srcu_n_exp_nodelay) + 1); +- if (READ_ONCE(ssp->srcu_n_exp_nodelay) > SRCU_MAX_NODELAY_PHASE) +- jbase = 1; ++ if (rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq))) { ++ j = jiffies - 1; ++ gpstart = READ_ONCE(ssp->srcu_gp_start); ++ if (time_after(j, gpstart)) ++ jbase += j - gpstart; ++ if (!jbase) { ++ WRITE_ONCE(ssp->srcu_n_exp_nodelay, +READ_ONCE(ssp->srcu_n_exp_nodelay) + 1); ++ if (READ_ONCE(ssp->srcu_n_exp_nodelay) > +SRCU_MAX_NODELAY_PHASE) ++ jbase = 1; ++ } + } + return jbase > SRCU_MAX_INTERVAL ? SRCU_MAX_INTERVAL : jbase; + } +. + diff --git a/results/classifier/zero-shot/108/permissions/899140 b/results/classifier/zero-shot/108/permissions/899140 new file mode 100644 index 000000000..3bc237659 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/899140 @@ -0,0 +1,802 @@ +permissions: 0.972 +other: 0.956 +device: 0.955 +vnc: 0.937 +files: 0.932 +semantic: 0.932 +socket: 0.932 +performance: 0.931 +PID: 0.919 +network: 0.918 +debug: 0.912 +graphic: 0.906 +boot: 0.863 +KVM: 0.857 + +Problem with Linux Kernel Traffic Control + +Hi, + +The two last main versions of QEMU (0.15 and 1.0) have an important problem when running on a Linux distribution which running itself a Traffic Control (TC) instance. +Indeed, when TC is configured with a Token Bucket Filter (TBF) with a particular rate, the effective rate is very slower than the desired one. + +For instance, lets consider the following configuration : + +# tc qdisc add dev eth0 root tbf rate 20mbit burst 20k latency 50ms + +The effective rate will be about 100kbit/s ! (verified with iperf) +I've encountered this problem on versions 0.15 and 1.0 but not with the 0.14... +In the 0.14, we have a rate of 19.2 mbit/s which is quiet normal. + +I've done the experimentation on several hosts : + +- Debian 32bit core i7, 4GB RAM +- Debian 64bit core i7, 8GB RAM +- 3 different high performance servers : Ubuntu 64 bits, 48 AMD Opteron, 128GB of RAM + +The problem is always the same... The problem is also seen with a Class Based Queuing (CBQ) in TC. + +Thanks + +Hi Vincent, +Please give steps to reproduce the problem including the QEMU +command-lines you used and what commands need to be run inside the +guest and on the host. + +Stefan + + +Hi, + +So, the host command lines are : +*$ qemu -name A -sdl -m 512 -enable-kvm -localtime -k fr -hda +debian1.img -net nic,macaddr=a0:00:00:00:00:01 -net +socket,mcast=230.0.0.1:7000* + +The second is +*$ qemu -name B -sdl -m 512 -enable-kvm -localtime -k fr -hda +debian2.img -net nic,macaddr=a0:00:00:00:00:02 -net +socket,mcast=230.0.0.1:7000* + +On virual machines : + +*root@A# ifconfig eth0 192.168.0.1* +*root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency +50ms* + +*root@B# **ifconfig eth0 192.168.0.2* + +Then if we check with /Iperf/, the real rate will be about 100kbit/s : + +*root@B# iperf -s* + +*root@A# iperf -c 192.168.0.1* + +Vincent + + +Le 02/12/2011 14:34, Stefan Hajnoczi a écrit : +> Hi Vincent, +> Please give steps to reproduce the problem including the QEMU +> command-lines you used and what commands need to be run inside the +> guest and on the host. +> +> Stefan +> + + +On Fri, Dec 2, 2011 at 2:42 PM, Vincent Autefage +<email address hidden> wrote: +> *root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency +> 50ms* +> +> *root@B# **ifconfig eth0 192.168.0.2* +> +> Then if we check with /Iperf/, the real rate will be about 100kbit/s : + +What is the iperf result without tc? It's worth checking what rate +the unlimited interface saturates at before applying tc. Perhaps this +setup is just performing very poorly and it has nothing to do with tc. + +Stefan + + +The result without TC is about 120 Mbit/s. +I check the bandwidth with lot of programs (not only with Iperf) and the +result is also the same.... + +However, if I use the same raw image and the same TC configuration with +the version 0.14.0 of QEMU or with some real physical hosts, the result +with TC is about 19.2 Mbit/s what is the desired result... + +Vincent + + +Le 03/12/2011 19:48, Stefan Hajnoczi a écrit : +> On Fri, Dec 2, 2011 at 2:42 PM, Vincent Autefage +> <email address hidden> wrote: +>> *root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency +>> 50ms* +>> +>> *root@B# **ifconfig eth0 192.168.0.2* +>> +>> Then if we check with /Iperf/, the real rate will be about 100kbit/s : +> What is the iperf result without tc? It's worth checking what rate +> the unlimited interface saturates at before applying tc. Perhaps this +> setup is just performing very poorly and it has nothing to do with tc. +> +> Stefan +> + + +On Sun, Dec 04, 2011 at 03:54:12PM -0000, Vincent Autefage wrote: +> The result without TC is about 120 Mbit/s. +> I check the bandwidth with lot of programs (not only with Iperf) and the +> result is also the same.... +> +> However, if I use the same raw image and the same TC configuration with +> the version 0.14.0 of QEMU or with some real physical hosts, the result +> with TC is about 19.2 Mbit/s what is the desired result... + +Thanks for checking if tc is involved in this bug. + +Git bisect can identify which commit introduced the bug between QEMU +0.14.0 and 0.14.1. The following steps show how to do this: + +Clone the QEMU git repository: +$ git clone git://git.qemu.org/qemu.git +$ cd qemu + +Double-check that 0.14.1 has the bug: +$ git checkout v0.14.1 +$ make distclean +$ ./configure --target-list=x86_64-softmmu +$ make +$ # test x86_64-softmmu/qemu-system-x86_64 binary + +Double-check that 0.14.0 does *not* have the bug: +$ git checkout v0.14.0 +$ make distclean +$ ./configure --target-list=x86_64-softmmu +$ make +$ # test x86_64-softmmu/qemu-system-x86_64 binary + +Now you can be confident that 0.14.0 and 0.14.1 do indeed behave +differently when built from source. It's time to perform the bisect, +you can read more about what this does in the git-bisect(1) man page. + +Find the commit that introduced the bug: +$ git bisect start v0.14.1 0.14.0 +$ make distclean +$ ./configure --target-list=x86_64-softmmu +$ make +$ # test x86_64-softmmu/qemu-system-x86_64 binary + +If tc achieves ~20 Mbit/s: +$ git bisect good + +Otherwise: +$ git bisect bad + +Git bisect will keep splitting the commit history in half until it +reaches the point where QEMU's behavior changes from good to bad. So +you typically need to build and test a couple of times until the guilty +commit has been identified. + +Stefan + + +Hi, + +So we have another problem... +The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +same problem. +However, the package 0.14.0 from Ubuntu does not has this bug... + + +Le 05/12/2011 09:26, Stefan Hajnoczi a écrit : +> On Sun, Dec 04, 2011 at 03:54:12PM -0000, Vincent Autefage wrote: +>> The result without TC is about 120 Mbit/s. +>> I check the bandwidth with lot of programs (not only with Iperf) and the +>> result is also the same.... +>> +>> However, if I use the same raw image and the same TC configuration with +>> the version 0.14.0 of QEMU or with some real physical hosts, the result +>> with TC is about 19.2 Mbit/s what is the desired result... +> Thanks for checking if tc is involved in this bug. +> +> Git bisect can identify which commit introduced the bug between QEMU +> 0.14.0 and 0.14.1. The following steps show how to do this: +> +> Clone the QEMU git repository: +> $ git clone git://git.qemu.org/qemu.git +> $ cd qemu +> +> Double-check that 0.14.1 has the bug: +> $ git checkout v0.14.1 +> $ make distclean +> $ ./configure --target-list=x86_64-softmmu +> $ make +> $ # test x86_64-softmmu/qemu-system-x86_64 binary +> +> Double-check that 0.14.0 does *not* have the bug: +> $ git checkout v0.14.0 +> $ make distclean +> $ ./configure --target-list=x86_64-softmmu +> $ make +> $ # test x86_64-softmmu/qemu-system-x86_64 binary +> +> Now you can be confident that 0.14.0 and 0.14.1 do indeed behave +> differently when built from source. It's time to perform the bisect, +> you can read more about what this does in the git-bisect(1) man page. +> +> Find the commit that introduced the bug: +> $ git bisect start v0.14.1 0.14.0 +> $ make distclean +> $ ./configure --target-list=x86_64-softmmu +> $ make +> $ # test x86_64-softmmu/qemu-system-x86_64 binary +> +> If tc achieves ~20 Mbit/s: +> $ git bisect good +> +> Otherwise: +> $ git bisect bad +> +> Git bisect will keep splitting the commit history in half until it +> reaches the point where QEMU's behavior changes from good to bad. So +> you typically need to build and test a couple of times until the guilty +> commit has been identified. +> +> Stefan +> + + +On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +<email address hidden> wrote: +> So we have another problem... +> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +> same problem. +> However, the package 0.14.0 from Ubuntu does not has this bug... + +Okay, that's actually a good thing because the issue is now isolated +to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. + +Either there is an environmental difference in the build configuration +or Ubuntu has applied patches on top of vanilla 0.14.0. + +I think the next step is to grab the Ubuntu 0.14.0 source package and +rebuild it to confirm that it does *not* have the bug. + +Then it's just a matter of figuring out what the difference is by a +(manual) bisection. + +Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +http://packages.ubuntu.com/natty/qemu-kvm + +Stefan + + +Yes this is the package that seems to not include the bug. +I'm going to check sources of this package. + +Vincent Autefage + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +Well.... + +I've compiled the ubuntu package. +When I've launched qemu, I've got this : +* +*$ *qemu-system-x86_64 -hda debian.img -m 512 +qemu: could not load PC BIOS 'bios.bin' +** +*I've checked the content of the *pc-bios* directory and no bios are +generated but I've got strange file like : +**.bin +*.dtb +openbios-* +* +I think that the *configure* interprets the *** as a base character... +Therefore, I've copied the content of*pc-bios* directory of 0.15.1 in +the *pc-bios* directory of 0.14.0 + +Finally, the bug of rate have disappeared !! +*Iperf* gave me a rate of 19mbit which is the desired rate. + +Vincent + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +Well, + +I have checked differences between the GIT repository (V0.14.0) and the +Ubuntu version (V0.14.0) and generated patch diff file. +The patch contains about 5000 lines... + +What's the next step ? + +Vincent + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +I've just checked the problem with a *ne2k_pci* instead of the default +e1000 and the problem does not exist with the *ne2k_pci*... (Version +0.14-1 of qemu) + +I'm going to check other cards right now + +Vincent + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +On Wed, Dec 14, 2011 at 1:36 PM, Vincent Autefage +<email address hidden> wrote: +> I have checked differences between the GIT repository (V0.14.0) and the +> Ubuntu version (V0.14.0) and generated patch diff file. +> The patch contains about 5000 lines... +> +> What's the next step ? + +Okay, so when you rebuild the Ubuntu package from source the bug is +not present and the largish diff suggests they have added patches on +top of vanilla 0.14.0. + +If the Ubuntu source ships with a number of .diff/.patch files that +get applied during the build then you could manually bisect this. +That means rerunning the Ubuntu build but with only the first half of +the list of patches applied. If that has the bug then split the +untested patches in half too and continue the test cycle. If the bug +is not present then split the patches in half and continue testing +until you reach the point where the bug goes from present to fixed. + +Stefan + + +Ok so the *Intel e1000* seems the only card which is impacted by the bug. + +Vincent + + +Le 05/12/2011 12:11, Stefan Hajnoczi a écrit : +> On Mon, Dec 5, 2011 at 10:45 AM, Vincent Autefage +> <email address hidden> wrote: +>> So we have another problem... +>> The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the +>> same problem. +>> However, the package 0.14.0 from Ubuntu does not has this bug... +> Okay, that's actually a good thing because the issue is now isolated +> to two similar builds: 0.14.0 from source and 0.14.0 from Ubuntu. +> +> Either there is an environmental difference in the build configuration +> or Ubuntu has applied patches on top of vanilla 0.14.0. +> +> I think the next step is to grab the Ubuntu 0.14.0 source package and +> rebuild it to confirm that it does *not* have the bug. +> +> Then it's just a matter of figuring out what the difference is by a +> (manual) bisection. +> +> Are you using qemu-kvm? I found Ubuntu's 0.14.0-based package here: +> http://packages.ubuntu.com/natty/qemu-kvm +> +> Stefan +> + + +On Wed, Dec 14, 2011 at 02:42:12PM -0000, Vincent Autefage wrote: +> Ok so the *Intel e1000* seems the only card which is impacted by the +> bug. + +Let me recap with a summary of your debugging: + +QEMU 0.14.0, 0.15.0, and 1.0 built from source all have poor network +performance below a 20 Mbit/s limit set with tc inside the guest. + +Ubuntu's 0.14.0 QEMU package does not have poor network performance. + +This problem only occurs with the emulated e1000 device. All other +emulated NICs operate correctly. + +Now you could diff the e1000 emulation code to get the code changes +between vanilla and Ubuntu: + + $ diff -u qemu-0.14.0-vanilla/hw/e1000.c qemu-0.14.0-ubuntu/hw/e1000.c + +(It's possible that there are no significant changes and this bug is +caused by something outside e1000.c but this is place to check first.) + +Or you could even try copying Ubuntu's e1000.c into the vanilla QEMU +source tree and retesting to see if the behavior changes. + +Stefan + + +Ok, + +So the e1000.c and the e1000_hw.h have absolutely no difference between +the original and the ubuntu version... +The only differences witch refers to the *Intel e1000* in the wall +sources is this one : + + +diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c +--- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100 ++++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22 +14:34:38.000000000 +0100 + +@@ -123,7 +141,7 @@ + if (!pci_enabled || (nd->model && strcmp(nd->model, +"ne2k_isa") == 0)) + pc_init_ne2k_isa(nd); + else +- pci_nic_init_nofail(nd, "e1000", NULL); ++ pci_nic_init_nofail(nd, "rtl8139", NULL); + } + + if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) { + + +Vincent + + +Le 15/12/2011 09:07, Stefan Hajnoczi a écrit : +> On Wed, Dec 14, 2011 at 02:42:12PM -0000, Vincent Autefage wrote: +>> Ok so the *Intel e1000* seems the only card which is impacted by the +>> bug. +> Let me recap with a summary of your debugging: +> +> QEMU 0.14.0, 0.15.0, and 1.0 built from source all have poor network +> performance below a 20 Mbit/s limit set with tc inside the guest. +> +> Ubuntu's 0.14.0 QEMU package does not have poor network performance. +> +> This problem only occurs with the emulated e1000 device. All other +> emulated NICs operate correctly. +> +> Now you could diff the e1000 emulation code to get the code changes +> between vanilla and Ubuntu: +> +> $ diff -u qemu-0.14.0-vanilla/hw/e1000.c qemu-0.14.0-ubuntu/hw/e1000.c +> +> (It's possible that there are no significant changes and this bug is +> caused by something outside e1000.c but this is place to check first.) +> +> Or you could even try copying Ubuntu's e1000.c into the vanilla QEMU +> source tree and retesting to see if the behavior changes. +> +> Stefan +> + + +On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage +<email address hidden> wrote: +> Ok, +> +> So the e1000.c and the e1000_hw.h have absolutely no difference between +> the original and the ubuntu version... +> The only differences witch refers to the *Intel e1000* in the wall +> sources is this one : +> +> +> diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c +> --- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100 +> +++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22 +> 14:34:38.000000000 +0100 +> +> @@ -123,7 +141,7 @@ +> if (!pci_enabled || (nd->model && strcmp(nd->model, +> "ne2k_isa") == 0)) +> pc_init_ne2k_isa(nd); +> else +> - pci_nic_init_nofail(nd, "e1000", NULL); +> + pci_nic_init_nofail(nd, "rtl8139", NULL); +> } +> +> if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) { + +That looks like it is only changing the default NIC from e1000 to rtl8139. + +Stefan + + +On Thu, Dec 15, 2011 at 4:09 PM, Stefan Hajnoczi <email address hidden> wrote: +> On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage +> <email address hidden> wrote: +>> Ok, +>> +>> So the e1000.c and the e1000_hw.h have absolutely no difference between +>> the original and the ubuntu version... +>> The only differences witch refers to the *Intel e1000* in the wall +>> sources is this one : +>> +>> +>> diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c +>> --- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100 +>> +++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22 +>> 14:34:38.000000000 +0100 +>> +>> @@ -123,7 +141,7 @@ +>> if (!pci_enabled || (nd->model && strcmp(nd->model, +>> "ne2k_isa") == 0)) +>> pc_init_ne2k_isa(nd); +>> else +>> - pci_nic_init_nofail(nd, "e1000", NULL); +>> + pci_nic_init_nofail(nd, "rtl8139", NULL); +>> } +>> +>> if (drive_get_max_bus(IF_IDE) >= MAX_IDE_BUS) { +> +> That looks like it is only changing the default NIC from e1000 to rtl8139. + +Perhaps you can stop Ubuntu from applying its patches on top of +vanilla QEMU but still use the same build process. In other words, +try building the vanilla QEMU source but using Ubuntu's method (not +sure if you are using dpkg build tools here). If it turns out the +binary does not have the bug then we know it's an environmental issue +like a ./configure difference or similar. + +Stefan + + +Here is the problem ! + +The Ubuntu version works only because it not uses an *Intel e1000* but a +*rtl8139*. +Therefore, the problem about the e1000 is present in *all* version +(original or ubuntu ones). + +Thus, the file *e1000.c* must contain some instructions which imply the +bad TC behavior. + +Vincent + +Le 15/12/2011 17:09, Stefan Hajnoczi a écrit : +> On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage +> <email address hidden> wrote: +>> Ok, +>> +>> So the e1000.c and the e1000_hw.h have absolutely no difference between +>> the original and the ubuntu version... +>> The only differences witch refers to the *Intel e1000* in the wall +>> sources is this one : +>> +>> +>> diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c +>> --- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100 +>> +++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22 +>> 14:34:38.000000000 +0100 +>> +>> @@ -123,7 +141,7 @@ +>> if (!pci_enabled || (nd->model&& strcmp(nd->model, +>> "ne2k_isa") == 0)) +>> pc_init_ne2k_isa(nd); +>> else +>> - pci_nic_init_nofail(nd, "e1000", NULL); +>> + pci_nic_init_nofail(nd, "rtl8139", NULL); +>> } +>> +>> if (drive_get_max_bus(IF_IDE)>= MAX_IDE_BUS) { +> That looks like it is only changing the default NIC from e1000 to +> rtl8139. +> +> Stefan +> + + +On Thu, Dec 15, 2011 at 04:48:13PM -0000, Vincent Autefage wrote: +> Here is the problem ! +> +> The Ubuntu version works only because it not uses an *Intel e1000* but a +> *rtl8139*. +> Therefore, the problem about the e1000 is present in *all* version +> (original or ubuntu ones). +> +> Thus, the file *e1000.c* must contain some instructions which imply the +> bad TC behavior. + +You are right! Looking back at your QEMU command-line you are not +explicitly specifying the NIC model so the default will take effect. + +Now we're back to square one: e1000.c performs poorly when the tc +command you posted is used. We don't know why yet. + +Michael: Have you ever encountered unexpectedly low throughput when tc +is used inside the guest? + +# tc qdisc add dev eth0 root tbf rate 20mbit burst 20k latency 50ms + +The observed throughput from iperf is only 100kbit/s, not around +20mbit/s as expected. When tc is not run inside the guest then the NIC +saturates 20mbit/s easily. + +Stefan + + +Hi guys, + +I'm having the same problem with a ubuntu 11.04 (natty) host. I tried to set the rate controllers using tc both at the host and inside the guest i.e.: + +tc qdisc add vnic0 root tbf rate 20mbit burst 20480 latency 50ms (host - to control the traffic going to the guest vm) and +tc qdisc add eth0 root tbf rate 20mbit burst 20480 latency 50ms (guest) + +And the results are the same reported initially: ~140kbit/sec. I also tried to use policing filters at the host but I got the same results. + +However, if I use htb I can get reasonable throughputs (~20mbit). I used these commands (both for host and guest): + +tc qdisc add dev <DEV> root handle 1: htb default 255 +tc class add dev <DEV> parent 1: classid 1:1 htb rate 20mbit burst 20480 +tc filter add dev <DEV> parent 1: prio 255 proto ip u32 match ip src 0.0.0.0/0 flowid 1:1 + +It seems that the problem is related with the root qdisc only. Have you guys found an answer for this? + +Hi, + +The problem seems to come from the implementation of the Intel e1000 +network cards (which is the default one used by QEMU). +If you use another one, the problem does not appear ;) + +Vince + +Le 29/01/2012 05:49, Henrique Rodrigues a écrit : +> Hi guys, +> +> I'm having the same problem with a ubuntu 11.04 (natty) host. I tried to +> set the rate controllers using tc both at the host and inside the guest +> i.e.: +> +> tc qdisc add vnic0 root tbf rate 20mbit burst 20480 latency 50ms (host - to control the traffic going to the guest vm) and +> tc qdisc add eth0 root tbf rate 20mbit burst 20480 latency 50ms (guest) +> +> And the results are the same reported initially: ~140kbit/sec. I also +> tried to use policing filters at the host but I got the same results. +> +> However, if I use htb I can get reasonable throughputs (~20mbit). I used +> these commands (both for host and guest): +> +> tc qdisc add dev<DEV> root handle 1: htb default 255 +> tc class add dev<DEV> parent 1: classid 1:1 htb rate 20mbit burst 20480 +> tc filter add dev<DEV> parent 1: prio 255 proto ip u32 match ip src 0.0.0.0/0 flowid 1:1 +> +> It seems that the problem is related with the root qdisc only. Have you +> guys found an answer for this? +> + + +Hi, + +I figured out what was the problem. It seems that the pkts generated by each guest iperf command is bigger than the default qdisc mtu of 2kb (the pkts have length of 65k). If you set a higher qdisc mtu (=65k) the traffic should be controlled as expected. + +Henrique + +Vincent, + +Have you tried to change the mtu of the tbf qdisc? The traffic control should work well if you set it to 65kb. +I believe that this is happening due to the napi gro functionality. I'm still not sure, but the problem seems to be related to that. + +Henrique + +Hi, + +No I don't try, i will :) +The probleme is not present with another NIC so I use another one for +the moment. + +Vincent + + +Le 09/02/2012 20:05, Henrique Rodrigues a écrit : +> Vincent, +> +> Have you tried to change the mtu of the tbf qdisc? The traffic control should work well if you set it to 65kb. +> I believe that this is happening due to the napi gro functionality. I'm still not sure, but the problem seems to be related to that. +> +> Henrique +> + + +Can you still reproduce this issue with the latest version of QEMU (currently v2.8), or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/899664 b/results/classifier/zero-shot/108/permissions/899664 new file mode 100644 index 000000000..4045e044d --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/899664 @@ -0,0 +1,122 @@ +permissions: 0.950 +vnc: 0.915 +socket: 0.913 +KVM: 0.909 +graphic: 0.908 +debug: 0.904 +other: 0.901 +performance: 0.900 +device: 0.899 +files: 0.898 +boot: 0.885 +semantic: 0.882 +PID: 0.876 +network: 0.871 + +Bad internet performance for Host to Guest or Guest to Host + +Hi, +Internet performance for Host to Quest is low. +The speed Guest to same Guest is 11.3 Gbits/sec +The speed Host to same Host is similar (9.8-11 Gbits/sec) + +But the speed from Guest to Host is slow and around 1Gbit/sec. +In the reality traffic never leave a Host. I expected that in this case speed should be close to Host to Host. +It is important for virtual infrastructure when you have several Guests on a same Host. Guest to Guest on a same host has speed around 1 Gbits/sec too. + +Below you can find testes and additional information: + +========================================================================= +biouml@biouml-db:~$ iperf -c 192.168.2.31 -t 30 #Guest to Guest +------------------------------------------------------------ +Client connecting to 192.168.2.31, TCP port 5001 +TCP window size: 49.7 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.31 port 52170 connected with 192.168.2.31 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 39.6 GBytes 11.3 Gbits/sec +============================================================================ +biouml@biouml-db:~$ iperf -c 192.168.2.11 -t 30 # Guest to Host +------------------------------------------------------------ +Client connecting to 192.168.2.11, TCP port 5001 +TCP window size: 43.4 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.31 port 47148 connected with 192.168.2.11 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 3.69 GBytes 1.06 Gbits/sec +biouml@biouml-db:~$ +============================================================================ +root@s2-8core:~# iperf -c 192.168.2.30 -t 30 #host to guest +------------------------------------------------------------ +Client connecting to 192.168.2.30, TCP port 5001 +TCP window size: 16.0 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.11 port 57403 connected with 192.168.2.30 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 5.47 GBytes 1.57 Gbits/sec + +========================================================================== +root@s2-8core:~# iperf -c 192.168.2.11 -t 30 #host to host +------------------------------------------------------------ +Client connecting to 192.168.2.11, TCP port 5001 +TCP window size: 49.7 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.11 port 38313 connected with 192.168.2.11 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 34.5 GBytes 9.87 Gbits/sec +root@s2-8core:~# +======================================================================== + +I am using virtio drivers and virtual machine was started with following parameters: + +/usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 4,sockets=4,cores=1,threads=1 -name one-25 -uuid d1e125ee-d692-4598-3a75-441cd79a513a -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/one-25.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -drive file=/var/lib/one/OpenNebula/var//25/images/disk.0,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/one/OpenNebula/var//25/images/disk.1,if=none,id=drive-virtio-disk3,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk3,id=virtio-disk3 -netdev tap,fd=19,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=02:00:c0:a8:02:02,bus=pci.0,addr=0x3 -usb -device usb-mouse,id=input0 -vnc 0.0.0.0:98 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 +============================================================================= +Qemu version: +root@s2-8core:~# /usr/bin/kvm --version +QEMU emulator version 0.15.92, Copyright (c) 2003-2008 Fabrice Bellard + +root@s2-8core:~# ls -la /usr/bin/kvm +lrwxrwxrwx 1 root root 27 2011-11-07 17:34 /usr/bin/kvm -> /usr/bin/qemu-system-x86_64 + +========================================================================== +Bridge configuration: + +root@s2-8core:~# cat /etc/network/interfaces +auto lo +iface lo inet loopback + +auto eth0 +iface eth0 inet manual + +auto eth1 +iface eth1 inet manual + +auto br0 +iface br0 inet static + address 192.168.2.11 + network 192.168.2.0 + netmask 255.255.255.0 + broadcast 192.168.2.255 + gateway 192.168.2.1 + bridge_ports eth0 + bridge_stp on + bridge_fd 0 + bridge_maxwait 0 +root@s2-8core:~# + +root@s2-8core:~# brctl show +bridge name bridge id STP enabled interfaces +br0 8000.001e8cec6113 yes eth0 + vnet0 +virbr0 8000.000000000000 yes + +root@s2-8core:~# brctl --version +bridge-utils, 1.5 +=============================================================== +root@s2-8core:~# uname -a +Linux s2-8core 3.0.0-13-server #22-Ubuntu SMP Wed Nov 2 15:09:08 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/permissions/944 b/results/classifier/zero-shot/108/permissions/944 new file mode 100644 index 000000000..a1ab782ae --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/944 @@ -0,0 +1,43 @@ +permissions: 0.976 +device: 0.943 +performance: 0.876 +files: 0.874 +graphic: 0.871 +network: 0.807 +debug: 0.704 +socket: 0.663 +semantic: 0.647 +PID: 0.576 +vnc: 0.433 +boot: 0.390 +other: 0.287 +KVM: 0.083 + +9p virtfs issue under MacOS in 7.0.0-rc1 +Description of problem: +9p virtfs under MacOS has an issue with sed inline replacements (sed -i). +The issue somewhere in xattr I believe +Steps to reproduce: +1. /Users/sid/ is mounted via 9p virtfs from MacOS host +2. +``` +[core@localhost ~]$ sed -i 's/aaa/zzz/g' /Users/sid/q/123 +sed: preserving permissions for ‘/Users/sid/q/sed3MLMjp’: Protocol not supported +``` +Additional information: +strace part with error +``` +openat(AT_FDCWD, "/proc/thread-self/attr/fscreate", O_RDWR|O_CLOEXEC) = 5 +write(5, NULL, 0) = 0 +close(5) = 0 +newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12, ...}, AT_EMPTY_PATH) = 0 +read(3, "qqq\nzzz\nsss\n", 8192) = 12 +newfstatat(4, "", {st_mode=S_IFREG|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0 +read(3, "", 8192) = 0 +fchown(4, 501, 1000) = 0 +fgetxattr(3, "system.posix_acl_access", 0x7ffd6dbd18b0, 132) = -1 ENODATA (No data available) +newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12, ...}, AT_EMPTY_PATH) = 0 +fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EPROTONOSUPPORT (Protocol not supported) +fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EPROTONOSUPPORT (Protocol not supported) +fchmod(4, 0100644) = 0 +``` diff --git a/results/classifier/zero-shot/108/permissions/950692 b/results/classifier/zero-shot/108/permissions/950692 new file mode 100644 index 000000000..782dee06e --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/950692 @@ -0,0 +1,132 @@ +permissions: 0.969 +debug: 0.954 +semantic: 0.937 +device: 0.936 +performance: 0.934 +graphic: 0.931 +other: 0.929 +boot: 0.920 +PID: 0.918 +files: 0.893 +KVM: 0.885 +vnc: 0.879 +socket: 0.829 +network: 0.778 + +High CPU usage in Host (revisited) + +Hi, + +last time QEMU(KVM) was working for us flawlessly was 2.6.35 kernel. + +Actually it still works flawlessly on that one single machine, that still has this kernel. Qemu version is meanwhile 1.0-r3, so the problem seems to be dependent on kernel version and not qemu version. + +We have several other machines, where the "high CPU usage in host" problem is present in various degrees of annoyingness. + +Both host and guest are Gentoo linux, at least that's what we test with. Several tested systems with other linux distributions and FreeBSD show similar - if not worse - behaviour. I will talk about 3 hosts, machine A, machine B and machine C + +A: + +2.6.35-gentoo-r9 #2 SMP Sat Nov 6 22:32:28 CET 2010 x86_64 Intel(R) Xeon(R) CPU L5410 @ 2.33GHz +32GB, runs about 15 KVM guests (all Gentoo, some 32bit, some 64bit, all SMP) +no problems whatsoever, host CPU usage corresponds to Guest CPU usage + 1-2%, that's how we like it +qemu 1.0-r3 + +B: + +3.0.6-gentoo #1 SMP Sun Oct 16 18:57:31 CEST 2011 x86_64 Intel(R) Xeon(R) CPU L5630 @ 2.13GHz +144GB, runs 1(!) KVM guest (Debian 6.x) +/usr/bin/qemu-system-x86_64 --enable-kvm -daemonize -cpu host -k de -net tap -tdf -hda /data/vm/disk.raw -m 768 -smp 1 -vnc :5 -net nic,model=e1000,macaddr=... +100% host CPU load always, therefore it got only "smp 1", if we gave it smp 2, it would have 200%, smp 4 400% and so on. +qemu 1.0-r3 + +C: + +3.1.6-gentoo #5 SMP Tue Mar 6 20:34:44 CET 2012 x86_64 Intel(R) Xeon(R) CPU 5148 @ 2.33GHz +16GB, runs 1-4 KVM guests (mostly Gentoo machines from A, plus some SuSE, RedHat etc.) +X00% CPU usage, where x corresponds to the smp X parameter, at startup as well as if someone "touches" the VM, like logging in, doing a "ls". If the machine is ABSOLUTELY IDLE, the process also exhibits 1-2% CPU load in host, but as soon as you do a simple ls, usage goes to - say - 400%, where it remains for some seconds, then slowly falls 280%, 120%, 60%, ... back to 1-2% +qemu 1.0-r3 + + +B is no go, C tries to well-behave but ultimatively fails, A is golden. + +There seems to be REAL high CPU usage and not only an error in displaying it. Other processes get less CPU power and exhibit definitely a slower runtime. On B, definitely one CPU core is hogged all the time + + +Some years ago we experienced something similar with ~2.6.26 and after a long and woeful period, we found out that compiling the host kernel as a tickless system caused the problem. Enabling high resolution timers made the problem go away and that is the situation on machine A until today. Since then no one dared to touch this production server. Unfortunately, this recipe didn't help with the other machines. + +I have scanned the net for similar problems and there are people complaining about high CPU usage. Unfortunately very often the devs or maintainers cannot reproduce it and the issue is dropped. Well - we cannot reproduce a "good behaviour"(tm) on any but one machine with any recent (read: post-2.6.35) linux kernel. + +Summary what we tried so far: + +* different linux kernels @ host, and @ guest + +-> no difference, especially there are guests @ A, that run newer kernels and there are Guests at B and C that run older kernels than is the host kernel + +* smp and non-smp, 32bit and 64bit guests + +-> 32/64bit in the guest makes no difference whatsoever. The smp just limits how much of the host CPU the guest hogs on non-well behaving systems (smp X -> X * 100%) + +* various linux guest OS, as well as FreeBSD + +-> no difference whatsoever + +* various options parameters in the host kernel (other schedulers, HRT, tickless,...) + +-> no difference whatsoever + +* various versions of qemu/kvm since 0.13 + +-> no difference whatsoever + +* various qemu/kvm options, virtio and non-virtio configurations (most of the VMs @ A run blk-virtio but emulate an e1000) + +-> no difference whatsoever + + +You could say, we've reached wits' end. We could try 2.6.35 @ machine C with the same configuration from A (they are identical except CPU and RAM size, but same RAID, mainboard, etc. plus A once had also the 5148 Xeons and an upgrade luckily made no difference in good behaviour, so I would exclude the CPU factor) but honestly that is not the way I'd like to go. The goal is to update A to something recent and not to loose it's VM-hosting well behaviour. Ideally to propagate this well beaviour to the other machines. + + +Arjan Minski + PetaMem IT + +*Newsflash* + +We do have a "well-behaving" KVM Host with 3.2.9 kernel on machine C + +After again numerous attempts to find the culprit, I decided to copy the kernel 2.6.35 and modules from machine A to machine C, where it exhibited also the desired "well-behaving". + +I then simply copied its config to a 3.2.9 kernel and did "make oldconfig", kept all defaults offered and restarted the machine with that newly created 3.2.9 and it seems it got soem right genes from 2.6.35 config. + +I will now poke the config and see if something breaks. Currently the only significant difference to our unsuccessfull 3.2.9 kernel is the fact, that the bad kernel was configured with kvm and kvm_intel not as module but compiled in. Should that be the culprit... oh man... + +I will test that and report. + + +I see similar problem when few I/Os are pumped and the VM goes non-responsive. +The host sees nearly 100% CPU utilization. + +top - 08:58:57 up 18:42, 2 users, load average: 0.99, 0.98, 0.95 +Tasks: 355 total, 1 running, 354 sleeping, 0 stopped, 0 zombie +%Cpu(s): 1.5 us, 2.7 sy, 0.0 ni, 95.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +KiB Mem: 65937388 total, 11895920 used, 54041468 free, 8163244 buffers +KiB Swap: 67073532 total, 0 used, 67073532 free. 545132 cached Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +2317 libvirt+ 20 0 18.612g 2.556g 8972 S 98.8 4.1 1120:00 qemu-system-x86 + 276 root 25 5 0 0 0 S 0.7 0.0 8:21.94 ksmd + 312 root 20 0 0 0 0 S 0.3 0.0 0:02.63 kworker/5:1 + 315 root 20 0 0 0 0 S 0.3 0.0 0:00.21 kworker/20:1 + +Please let me know if this is fixed. I am currently using QEMU 2.0 + + + +Triaging old bug tickets ... can you somehow still reproduce this problem with the latest version of QEMU (currently v2.9), or could we close this ticket nowadays? + +From our point of view, this ticket can be closed. KVM is running without issues on all our servers for more than 5 years now. + +The problem described above, was due to a weird combination of "timer" kernel parameters in the early 3.x kernels. IIRC, enabling a high-frequency timer and/or "tickless system" solved the issues we had. + +Ok, thanks for your confirmation! + diff --git a/results/classifier/zero-shot/108/permissions/952 b/results/classifier/zero-shot/108/permissions/952 new file mode 100644 index 000000000..0a5246bc9 --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/952 @@ -0,0 +1,112 @@ +permissions: 0.977 +graphic: 0.972 +other: 0.960 +semantic: 0.954 +debug: 0.943 +PID: 0.926 +device: 0.915 +performance: 0.915 +vnc: 0.834 +files: 0.822 +boot: 0.807 +socket: 0.740 +network: 0.686 +KVM: 0.593 + +qemu: uncaught target signal 5 (Trace/breakpoint trap) +Description of problem: +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 + 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello + +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. + +But it's coredump. + +I found that bkpt instruction is not recognized, the bkpt is in 0x0000a608. + +host： +``` +$qemu-arm -g 12345 hello +``` +service: +``` +$gdb-multiarch hello +(gdb) target remote localhost:12345 +Remote debugging using localhost:12345 +0x0000a602 in _start () +(gdb) ni +0x0000a604 in _start () +(gdb) +0x0000a608 in _start () +(gdb) +0x0000a608 in _start () +``` +Another way to check: +``` +$gdb qemu-arm +(gdb) run hello +(gdb) bt +#0 0x00007ffff79474ba in __GI___sigsuspend (set=set@entry=0x7fffffffd9d8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26 +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +#5 0x0000555555603cf4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:883 +(gdb) up +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +772 sigsuspend(&act.sa_mask); +(gdb) +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +1099 dump_core_and_abort(sig); +(gdb) +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +1175 handle_pending_signal(cpu_env, sig, &ts->sync_signal); +(gdb) +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +472 process_pending_signals(env); +(gdb) l +467 default: +468 error: +469 EXCP_DUMP(env, "qemu: unhandled CPU exception 0x%x - aborting\n", trapnr); +470 abort(); +471 } +472 process_pending_signals(env); +473 } +474 } +475 +476 void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs) +(gdb) p cpu_exec(cs) +$2 = 7 +``` +Here process_pending_signals(env) gives SIGTRAP?? + +Here is my binary: +[hello](/uploads/7225e1f1c5a61ace40f90d5d2401a758/hello) diff --git a/results/classifier/zero-shot/108/permissions/955379 b/results/classifier/zero-shot/108/permissions/955379 new file mode 100644 index 000000000..03383a4ec --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/955379 @@ -0,0 +1,438 @@ +permissions: 0.921 +device: 0.918 +boot: 0.916 +performance: 0.881 +semantic: 0.879 +other: 0.878 +debug: 0.869 +PID: 0.862 +vnc: 0.842 +files: 0.830 +socket: 0.829 +network: 0.826 +KVM: 0.808 +graphic: 0.802 + +cmake hangs with qemu-arm-static + +I'm using git commit 3e7ecd976b06f... configured with --target-list=arm-linux-user --static in a chroot environment to compile some things. I ran into this problem with both pcl and opencv-2.3.1. cmake consistently freezes at some point during its execution, though in a different spot each time, usually during a step when it's searching for some libraries. For instance, pcl most commonly stops after: + +[snip] +-- Boost version: 1.46.1 +-- Found the following Boost libraries: +-- system +-- filesystem +-- thread +-- date_time +-- checking for module 'eigen3' +-- found eigen3, version 3.0.1 + +which is perplexing because it freezes after finding what it wants, not during the search. When it does get past that point, it does so almost immediately but freezes somewhere else. + +I'm using 64-bit Ubuntu 11.10 with kernel release 3.0.0-16-generic with an Intel i5. + +I have found several places cmake may hang, with either qemu-arm-static or mipsel, and in debian (testing) as well as in Ubuntu. One of them is the cmake check for c++ compiler, which can be overridden. Things that use cmake's pkg_check_modules and pkg-config files will also hang. Curiously, outside of cmake, equivs also will similarly hang if used. All these things can make it very difficult to use qemu user static driven chroot's or qemu pbuilder for pkg building at present. + + +I am also having this issue with latest qemu on quantal using an armhf chroot. + +cmake will occasionally finish, but mostly it just hangs, most often in the pkg_check bits. + +I can confirm that this is still an issue even with latest qemu-linaro, from Quantal (1.2.0-2012.09-0ubuntu1). + +If you can provide a simple straightforward reproduce case that would be useful. + + +Status changed to 'Confirmed' because the bug affects multiple users. + +Peter, if you try to run the cmake file for lp:unity you should hit it. + +On 25 November 2012 20:40, Tim Penhey <email address hidden> wrote: +> Peter, if you try to run the cmake file for lp:unity you should hit it. + +I'm afraid that's way too little detail. Assume I know nothing about +launchpad, cmake or unity, and give me a set of instructions I +can run on a machine which isn't necessarily running ubuntu to +reproduce this, preferably with as small and limited a repro case +as possible. At least, it should be a command line that starts +out "qemu <some stuff>"... + +thanks +-- PMM + + +Peter, I have qemu chrootable test case under which you could fire one command to hit the bug reliably. Only issue is, are you willing to take a peek at 100M extractable tarball? If not, I'll try to create a smaller one. + +On 28 November 2012 08:42, Janne Karhunen <email address hidden> wrote: +> Peter, I have qemu chrootable test case under which you could fire one +> command to hit the bug reliably. Only issue is, are you willing to take +> a peek at 100M extractable tarball? If not, I'll try to create a smaller +> one. + +Yeah, 100M repro case tarball is manageable. + +-- PMM + + +Ok, test case attached (80M tar). This hugely stripped one is not 100% reproducer, but do few loops and you will hit it. Instructions for using: +- extract, chroot +- cd /home/abuild/rpmbuild +- su abuild +- export RPM_BUILD_ROOT=$PWD +- rpmbuild -ba SOURCES/libshortcut.spec + + +Mind you, when you hit the bug it just hangs and cmake test errors are just to speed up the process of hitting the bug (if cmake just fails you did not hit the bug). Feel free to try with any qemu variant, they all hang similarly when bug is hit. I think that root had some suse 1.2 one inside. + +That test case seems to have very weak reproducibility -- I think I saw a hang perhaps once in 30+ runs. That's not really usable for debugging, I'm afraid :-( + + +If that is the case for you (for me it reproduces it every 4-5 runs or so), there are two options: +1) put while(true) loop around the rpmbuild and you will hit it always, or +2) I can wrap up a bit bigger cmake usecase that systematically hits it. Warn you though, size will jump to 200M. + +I'll take the bigger usecase, please. It's pretty hard to debug race conditions that don't manifest often enough to let you do useful logging. + +From the time or two I caught it hanging, it looks like qemu is sleeping in poll, and there's a zombie child process. I wonder if what's happening is that the SIGCHLD is coming in just before syscall.c executes the poll syscall, so that qemu queues the signal for delivery to the guest (but never actually delivers it) and then enters a poll syscall that won't return (because the SIGCHLD has already arrived). If so, fixing this would require the significant redesign sketched out here: +http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html + + +Actually I just managed to interact with a hung qemu under a debugger sufficiently to confirm what is happening here. + +CMake's code for running child processes (in kwsys/ProcessUNIX.c) does this: +"On UNIX, a child process is forked to exec the program. Three output pipes are read by the parent process using a select call to block until data are ready. Two of the pipes are stdout and stderr for the child. The third is a special pipe populated by a signal handler to indicate that a child has terminated. This is used in conjunction with the timeout on the select call to implement a timeout for program even when it closes stdout and stderr and at the same time avoiding races." + +So (assuming no timeout set up) we can get the following race: + * spawn child process + * parent gets to point of making select() syscall + * this takes the parent process into qemu's linux-user/main.c code + * child process exits + * host kernel sends SIGCHLD to parent + * qemu's signal handler queues this SIGCHLD and does a cpu_exit, which will make the parent take the signal at the next basic block + * parent code (still inside main.c or syscall.c) does the actual host select() syscall + * this blocks forever, because the thing that would wake it up is the signal handler writing to the pipe we're selecting on, but we will never run the signal handler until select exits + +Fixing this bug will indeed require the significant rework I referred to in comment #14, I'm afraid. Don't hold your breath... + + +> this blocks forever, because the thing that would wake it up is the signal handler writing to the pipe we're selecting on, but we will never run the signal handler until select exits + +Duh, makes sense, have to think about this. Thank you for great analysis :) + +Apparently have to dig into qemu's code to understand this better, but first thought was that do you think it would be possible to add some crude hack bit in qemu's signal handler which we could 'almost atomically' check prior to entering system poll/select/read/whatnot ? This bit would tell there are user signals queued and handlers should be executed first.. ? + +On 1 December 2012 10:29, Janne Karhunen <email address hidden> wrote: +>> this blocks forever, because the thing that would wake it up is the +> signal handler writing to the pipe we're selecting on, but we will never +> run the signal handler until select exits +> +> Duh, makes sense, have to think about this. Thank you for great analysis +> :) +> +> Apparently have to dig into qemu's code to understand this better, but +> first thought was that do you think it would be possible to add some +> crude hack bit in qemu's signal handler which we could 'almost +> atomically' check prior to entering system poll/select/read/whatnot ? +> This bit would tell there are user signals queued and handlers should be +> executed first.. ? + +Nope, it's still not going to be non-racy that way (and it would still +be a pretty invasive change so it doesn't really make it easier either +I think). + +-- PMM + + + +On 01.12.2012, at 12:27, Peter Maydell wrote: + +> On 1 December 2012 10:29, Janne Karhunen <email address hidden> wrote: +>>> this blocks forever, because the thing that would wake it up is the +>> signal handler writing to the pipe we're selecting on, but we will never +>> run the signal handler until select exits +>> +>> Duh, makes sense, have to think about this. Thank you for great analysis +>> :) +>> +>> Apparently have to dig into qemu's code to understand this better, but +>> first thought was that do you think it would be possible to add some +>> crude hack bit in qemu's signal handler which we could 'almost +>> atomically' check prior to entering system poll/select/read/whatnot ? +>> This bit would tell there are user signals queued and handlers should be +>> executed first.. ? +> +> Nope, it's still not going to be non-racy that way (and it would still +> be a pretty invasive change so it doesn't really make it easier either +> I think). + +Could you please try and see if this patch makes a difference? + +http://repo.or.cz/w/qemu/agraf.git/patch/489924aa0115dc6cfcd4e91b0747da4ff8425d1f + + +Alex + + + +On 3 December 2012 21:20, Alexander Graf <email address hidden> wrote: +> Could you please try and see if this patch makes a difference? +> +> http://repo.or.cz/w/qemu/agraf.git/patch/489924aa0115dc6cfcd4e91b0747da4ff8425d1f + +I think the answer will turn out to be "no" (though it's worth +testing anyway), because the syscall we're blocking in in this +case is select(), which is a syscall which will exit when a +signal arrives anyway. That is, I think we're really hitting +the race condition of the signal arriving while we're in QEMU's +C code, rather than the stuck-in-blocking-syscall of the boehm +GC case. + +-- PMM + + +So I guess 'raciness' of my proposed patch would only depend on how small I could squeeze the section between 'sigpending' flag comparison and actual syscall entering? + +Yes. You can never shut the window completely trying to do it that way, which is why you need fix the problem properly instead. + + +And what would break if we make poll timeout instantly in case there are signals pending and restart the given syscall after handlers run? + +Moreover, is there even a need to restart anything, just make it async call in case signals were pending? + +Never mind, async/zero timeout call would suffer from same (albeit now tiny) race. It would make this far less invasive as a change though. + +On 4 December 2012 11:21, Janne Karhunen <email address hidden> wrote: +> And what would break if we make poll timeout instantly in case there are +> signals pending and restart the given syscall after handlers run? + +If there are signals pending in the host kernel poll will *already* +return immediately. If there is a signal pending in the QEMU signal +queue (because the host kernel just delivered it to us) then there +will always be a window between the point where you say "ok, queue +is empty" and actually doing the host syscall, where a signal could +be delivered and put in the queue. You cannot fix this bug in the way +you are trying to: you must handle this case by longjumping out of +the signal handler. I've already sketched the correct design for +fixing this. + +[to anybody in the peanut gallery who is thinking about pselect() +now: yes, you could perhaps hack something up with that, but it would +still be a big patch with a bunch of corner cases to review, and +it would only fix this bug for this particular syscall, not in +general.] + +-- PMM + + +Just out of interest tried how far the timeout hackery can go working around the issue. Well, looks like it goes quite far: having previously reproduced the hang in 4-5 runs and in under a minute, now have had this running without a hang for an hour. I will also test the patch under OBS worker(s) and if it solves the issue there as well, I will attach it as a workaround for time being for those interested. However, Peter is right and this is not a final solution of any kind: just a workaround. + +Some kind of semi-workaround patch attached. It seems to leave this kind of race window for me (for select which is worse): + + 0x000000006004bf98 <+136>: xor %r8d,%r8d + 0x000000006004bf9b <+139>: test %eax,%eax + 0x000000006004bf9d <+141>: jne 0x6004c2b7 <do_select+935> + 0x000000006004bfa3 <+147>: mov 0x20(%rsp),%r14 + 0x000000006004bfa8 <+152>: mov 0x246d8(%r14),%esi + 0x000000006004bfaf <+159>: test %esi,%esi + 0x000000006004bfb1 <+161>: je 0x6004bfb8 <do_select+168> + 0x000000006004bfb3 <+163>: lea 0x40(%rsp),%r8 + 0x000000006004bfb8 <+168>: mov 0x28(%rsp),%rdx + 0x000000006004bfbd <+173>: mov %r11,%rsi + 0x000000006004bfc0 <+176>: mov %ebx,%edi + 0x000000006004bfc2 <+178>: callq 0x6012df90 <select> + +I think it could still be narrowed some, but this makes it unlikely enough for me for time being... + +The attachment "racy workaround patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report. + +[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.] + +I have tested cmake.patch but it doesn't work for me. +It didn't hang but it failed to run gmake. +I applied this patch onto qemu-1.3. + +[ 52s] -- Detecting CXX compiler ABI info +[ 53s] CMake Error: Generator: execution of make failed. Make command was: /usr/bin/gmake "cmTryCompileExec/fast" +[ 53s] -- Detecting CXX compiler ABI info - failed + +Luke Kim: quite unlikely that above patch would cause the issue you see.. are you sure something else did not break in your environment? Can you execute that same make manually? + +I wouldn't mind giving this patch a test if given some instructions on doing so. + +I am also unable to compile pcl because of this bug. + +Janne Karhunen: Do you think if it is correct that return 0 when ts->signal_pending is true and select() returns '0' (timeout)? Because the caller doesn't expect to return select() with 0, should we return other error values such as EINTR? +When I modified you patch to return EINTR if select() return '0' when ts->signal_pending is true, it worked fine with me. + +LK: Ok, good catch, that might be more suitable option. Thanks, + +Isn't it fixed yet with latest qemu 2.1 rc? + +No; this is a a complicated issue to fix that basically requires a significant restructuring of the linux-user code. Nobody's done that yet and as far as I know nobody's said they plan to do so either. + + +It's just excellent illustration why I hate pipes. + +So CMake guys can remove this crap from their code and use socketpair() or like instead. + +https://lists.tizen.org/pipermail/dev/2014-July/003424.html + +What cmake is doing is an entirely legitimate and well-recognized Unix idiom for converting signals into effects on filedescriptors for select(), and there's no reason for them to change it. This is absolutely a bug in QEMU, it's just one that's not easy for us to fix. (Using socketpair would not help here. You'd have to use signalfd(), which of course is much less portable.) + + +Most rececnt qemu-devel discussion and a promising looking approach (ie it would work whereas my idea linked from comment #14 would not): +http://lists.gnu.org/archive/html/qemu-devel/2014-02/msg04569.html + + +the above patch still applies with qemu 2.4, but then it fails to build with the following error: + +x86_64-pc-linux-gnu-gcc -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/tcg -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/tcg/i386 -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/linux-headers -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/user-build/linux-headers -I. -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0 -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/include -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/linux-user -Ilinux-user -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I../linux-headers -I.. -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/target-i386 -DNEED_CPU_H -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/include -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/linux-user/x86_64 -I/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/linux-user -MMD -MP -MT linux-user/syscall.o -MF linux-user/syscall.d -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -march=native -mtune=generic -O2 -pipe -c -o linux-user/syscall.o /var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/linux-user/syscall.c +/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/linux-user/syscall.c: In function ‘do_select’: +/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/linux-user/syscall.c:1010:34: error: ‘thread_env’ undeclared (first use in this function) + TaskState *ts = (TaskState *)thread_env->opaque; + ^ +/var/tmp/portage/app-emulation/qemu-2.4.0-r1/work/qemu-2.4.0/linux-user/syscall.c:1010:34: note: each undeclared identifier is reported only once for each function it appears in + +anybody so kind to tell me how to fix it? +thank you. + +Recent patchseries which I think ought to be a proper fix for this bug: +https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01388.html +It does need some more work to address review comments but it's sound in principle. + + +thank you peter, do you know if timothy has a github account? +i'm too lazy to copy&paste the 34 patches by hand from the mailing list... + +ok, i've found a better place for patchset download: + +https://patchwork.ozlabs.org/project/qemu-devel/list/?submitter=Timothy+Baldwin&q=linux-user + +unfortunately cmake still hangs in a way that even sending SIGCHLD doesn't wake it up, i have to send SIGKILL to stop it and consequently breaking the build process... + +please let me know if there's something else i could try. + +thank you. + +Does anybody have a reliable reproduce case for this bug? I have some patches I'd like to test which I think should fix it, but I cannot get the test case attached in comment #10 to hang at all, even without the fixes. + + +iirc i've was able to reproduce this bug every time while compiling kdelibs4 on a chrooted arm image + +I was hoping for a "run this command" level of reproducer :-) + +Alternatively, if anybody's conveniently able to build and test a new QEMU with whatever was failing for them, you can try the git branch +https://git.linaro.org/people/peter.maydell/qemu-arm.git sigrace-fixes + + +I get a hang doing this most times in an emulated ARM chroot with qemu-arm-static (Raspbian). Host machine is x86_64 Ubuntu 16.04 running qemu 2.5.0. + +git clone --depth 1 https://github.com/libretro/picodrive.git +cd picodrive && +git submodule update --init + + +Thanks for that report of a hang running git. I've been able to identify and fix the bug (it is a different problem to the issue that was causing cmake to hang) and have sent a patch: +http://patchwork.ozlabs.org/patch/631708/ +That fix will hopefully make it into QEMU 2.7. + + +That's great news - thanks very much. This will make working on RetroPie development in a chroot much easier (we have workarounds to avoid using git because of this issue). + +Please try the latest qemu git HEAD, Timothys and Peters fixes have been merged in. + +A prebuilt package of qemu-user built statically at: + +http://repo.linaro.org/ubuntu/linaro-tools/pool/main/q/qemu/qemu-user-static_2.6.0+git931+g9bbbf64-1linarojessie1_amd64.deb + + + +That's great! it works for me. Thanks a lot. + +I'm going to mark this bug as 'fix committed', because changes which should fix both the cmake and the git hang are now in QEMU git master. If people have test cases for things which still fail on current git master, please open fresh bugs for them. + + + +I'm so sorry that +cmake still hang with my Ubuntu 12.04 and openSUSE 12.3 machine. +and the hanging point has changed. cmake hung at select() with old qemu. but now cmake hang at pselect6() with new qemu. +And also I could continue build by sending SIGCHLD to hanging qemu. but now cmake still hang even I send SIGCHLD to hanging qemu. + +Please can you (a) double check that you're definitely running the correct new QEMU and (b) provide exact reproduction instructions so I can investigate the hang. + + +I test with b66e10e4c9ae738412b9742db49457f6b703e349 before. +I test with 14c7d99333e4a474c65bdae6f99aa8837e8078e6 today and no hang. +But I had to revert 4fb8320a2efb2216c7ddcc929ad0362f4e285681 which causes segfault. + +Please provide exact reproduction instructions -- I need enough information that I can completely replicate your setup and what you're doing: exactly how you've set up any chroot or whatever other guest setup you have, what cmake command you're running, and so on. + + +chroot env. attached (120M tar). +I hope you can reproduce with this chroot. + +Instructions to reproduce +- extract, chroot +- su - abuild +- cd /home/abuild/rpmbuild/BUILD/cmake-2.8.5/armv7l-tizen-linux-gnueabi/ +- Bootstrap.cmk/cmake .. -CBootstrap.cmk/InitialCacheFlags.cmake '-GUnix Makefiles' -DCMAKE_BOOTSTRAP=1 + +Thanks for that test case; unfortunately it works fine for me (both with current git master and with commit b66e10e4c9ae7384). + +Can you tell me what host machine you're running this on, and in particular whether it is 32 bit or 64 bit? Commit b66e10e4c9ae7384 will fix this hang for x86-64 (64-bit intel) hosts, but it will only be fixed for 32-bit intel hosts by commit 3e904d6ade7 (which also fixes this for aarch64, arm, ppc64 and s390x hosts). + +If you are using a 32-bit x86 host that would explain the failure-vs-success that you report in comment #56. I suspect from looking at the qemu binaries that were in your test case tarball that you are using 32-bit. + + +Thanks for your feedback. +I was running this on intel i7 Ubuntu 64bit. +but I used 32bit qemu as you suspected. + +OK, so the behaviour you saw is expected since we didn't fix 32-bit hosts until a bit later; but they should both be fixed now. + +Hello, Peter Maydell +we have new qemu-arm hang issue. +I guess you are busy for new qemu 2.7 release. +But, could you please help us if you have time? + +https://bugs.launchpad.net/qemu/+bug/1617929 + +Very thank you in advance :-) + +Fixes should be part of QEMU v2.7.0, e.g.: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=014628a705bdaf31c09915 +... so setting the status to "Fix Released" now. + +I am seeing the same symptoms as the original poster. I'm building the opencv package in a debian stretch armfh chroot on a ubuntu bionic amd64 host. So, I'm guessing that the race condition wasn't entirely fixed or there has been some sort of regression. + +Steps to reproduce: + +# on ubuntu bionic amd64 host +sudo apt-add-repository ppa:ev3dev/tools +# assuming apt-add-repository does apt update now +sudo apt install pbuilder-ev3dev git +git clone --depth=1 https://github.com/ev3dev/opencv +cd opencv +OS=debian ARCH=armhf DIST=stretch pbuilder-ev3dev base +OS=debian ARCH=armhf DIST=stretch pbuilder-ev3dev dev-build + +That means our assumption taken in comment #63 that it was fixed in http://git.qemu.org/?p=qemu.git;a=commitdiff;h=014628a705bdaf31c09915 either was wrong (unset fix released) - or this is a similar but not the same issue (which would imply a new bug since this already has plenty of potentially mismatching history). + +Given the time this was considered closed I'd vote for a new bug to analyze things from scratch. +@David - would you mind opening a new bug? + +@TJ - before considering backporting something of the current solution to xenial, (all other releases are >=2.7) would you mind testing e.g. qemu 2.10 via [1]. +Also a trivial reproducer will help to make this SRUable, like David added his (for the probably new issue). Or is the one in comment #58 representing your case as well? + +[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive#Pike + +I have filed a new bug: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1764555 + +What's the status of this bug? I see LP: #1764555 has been marked as invalid as the test environment was tainted - does this imply the fix was correct and everything is working as intended? +The bug is marked for 16.04.5. If it's still something we intent to get released for the point-release we would need someone to prepare an SRU as soon as possible. + +From upstream QEMU's point of view the status of this bug is "it's an old bug report that tended to accumulate 'this seems like it's the same as my bug' extra comments; we have fixed the underlying cause of the original bug, so leave this one closed and file new ones with proper reproducer instructions if necessary". + +LP: #1764555 was closed because it was "bug submitter was still running the old QEMU version and didn't realise it". + + diff --git a/results/classifier/zero-shot/108/permissions/987 b/results/classifier/zero-shot/108/permissions/987 new file mode 100644 index 000000000..466c86dda --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/987 @@ -0,0 +1,64 @@ +permissions: 0.930 +other: 0.908 +performance: 0.893 +KVM: 0.886 +graphic: 0.868 +device: 0.862 +semantic: 0.859 +vnc: 0.859 +debug: 0.859 +PID: 0.841 +files: 0.839 +socket: 0.821 +network: 0.796 +boot: 0.789 + +compiling issue +Description of problem: +compilation error issue while building for qemu-riscv32-static +Steps to reproduce: +1.git clone https://github.com/qemu/qemu.git + +2. ./configure --static --disable-system --target-list=riscv32-linux-user + + +issue output: +``` +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[954/960] Compiling C object tests/unit/test-string-output-visitor.p/test-string-output-visitor.c.o +[955/960] Linking target tests/unit/test-string-output-visitor +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[956/960] Compiling C object tests/unit/test-string-input-visitor.p/test-string-input-visitor.c.o +[957/960] Linking target tests/unit/test-string-input-visitor +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[958/960] Linking target tests/unit/test-x86-cpuid +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[959/960] Compiling C object tests/unit/test-visitor-serialization.p/test-visitor-serialization.c.o +[960/960] Linking target tests/unit/test-visitor-serialization +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +make[1]: Leaving directory '/home/sadiq/work/qemu/build' +changing dir to build for make ""... +make[1]: Entering directory '/home/sadiq/work/qemu/build' + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp +[1/3] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +make[1]: Leaving directory '/home/sadiq/work/qemu/build' +``` + +Any suggestions to resolve the issue would be helpful + +Thanks diff --git a/results/classifier/zero-shot/108/permissions/989 b/results/classifier/zero-shot/108/permissions/989 new file mode 100644 index 000000000..f449f45ec --- /dev/null +++ b/results/classifier/zero-shot/108/permissions/989 @@ -0,0 +1,115 @@ +permissions: 0.965 +debug: 0.961 +other: 0.958 +device: 0.957 +performance: 0.957 +graphic: 0.956 +socket: 0.954 +files: 0.953 +network: 0.949 +semantic: 0.948 +boot: 0.946 +PID: 0.935 +KVM: 0.857 +vnc: 0.854 + +Segmentation fault on Apple M1 inside a docker container +Description of problem: +I cannot build a Rust dependency (`regex-syntax`) in a docker container for the platform linux/amd64 using Rancher Desktop (v1.2.1; Kubernetes v1.22.7) on Apple M1 hardware. +I suppose it is a QEMU issue because I didn't observe it on x86_64 hardware where the exact same docker container was built and executed natively without emulation. +Moreover, valgrind does not detect an invalid memory access either. +Steps to reproduce: +1. `nerdctl build --platform linux/amd64 -t rust-x86_64 .` +2. `nerdctl run --platform linux/amd64 -it rust-x86_64` +3. `cargo new hello` +4. `cd hello` +5. `echo 'regex-syntax = "0.6.25"' >> Cargo.toml` +6. `cargo build --release -v` +Additional information: +Dockerfile: +``` +FROM ubuntu:21.10 + +# Install a basic environment needed for our build tools +ARG DEBIAN_FRONTEND=noninteractive +RUN apt -yq update && \ + apt -yqq install --no-install-recommends curl ca-certificates \ + build-essential pkg-config libssl-dev llvm-dev liblmdb-dev clang cmake + +# Install Rust and Cargo in /opt +ARG rust_version=1.60.0 +ARG platform=x86_64 +ENV RUSTUP_HOME=/opt/rustup \ + CARGO_HOME=/opt/cargo \ + PATH=/opt/cargo/bin:$PATH +RUN curl --fail https://sh.rustup.rs -sSf \ + | sh -s -- -y --default-toolchain ${rust_version}-${platform}-unknown-linux-gnu --no-modify-path && \ + rustup default ${rust_version}-${platform}-unknown-linux-gnu +``` + + + +Output inside the docker container: + +``` +# cargo build --release -v + Updating crates.io index + Downloaded regex-syntax v0.6.25 + Downloaded 1 crate (293.3 KB) in 0.84s + Compiling regex-syntax v0.6.25 + Running `rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow` +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x4b3d23)[0x400215fd23] +/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x4005cab520] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZNK4llvm13AttributeList19addAttributeAtIndexERNS_11LLVMContextEjNS_9AttributeE+0x834)[0x40088d3484] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZN4llvm8Function19addAttributeAtIndexEjNS_9AttributeE+0x18)[0x40088d2c48] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs4_NtCsfrnhObXyzQM_18rustc_codegen_llvm3abiINtNtNtCsaEkRwEFRwNk_12rustc_target3abi4call5FnAbiNtNtCs12ixbLjc5mB_12rustc_middle2ty2TyENtB5_12FnAbiLlvmExt16apply_attrs_llfn+0x14d)[0x40033d532d] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXNtCsfrnhObXyzQM_18rustc_codegen_llvm9mono_itemNtNtB4_7context9CodegenCxNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7declare16PreDefineMethods12predefine_fn+0x56a)[0x40033bba5a] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x17007c0)[0x40033ac7c0] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23761e6)[0x40040221e6] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2373a6f)[0x400401fa6f] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23a1e45)[0x400404de45] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs5_CsfrnhObXyzQM_18rustc_codegen_llvmNtB5_18LlvmCodegenBackendNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7backend14CodegenBackend13codegen_crate+0xda)[0x400400e70a] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23544e7)[0x40040004e7] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x233ac88)[0x4003fe6c88] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvMs0_NtCsf5CM6ndXTHU_15rustc_interface7queriesNtB5_7Queries15ongoing_codegen+0xaf)[0x4003fdd02f] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2308b04)[0x4003fb4b04] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x22ee134)[0x4003f9a134] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23213e9)[0x4003fcd3e9] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/libstd-8d61b92a0a02f53a.so(rust_metadata_std_cd3cf6af28dff6de+0xa7d03)[0x400598fd03] +/lib/x86_64-linux-gnu/libc.so.6(+0x94947)[0x4005cfd947] +/lib/x86_64-linux-gnu/libc.so.6(clone+0x44)[0x4005d8da44] +error: could not compile `regex-syntax` + +Caused by: + process didn't exit successfully: `rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference) + +# valgrind rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow +==977== Memcheck, a memory error detector +==977== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. +==977== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info +==977== Command: rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg feature="default" --cfg feature="unicode" --cfg feature="unicode-age" --cfg feature="unicode-bool" --cfg feature="unicode-case" --cfg feature="unicode-gencat" --cfg feature="unicode-perl" --cfg feature="unicode-script" --cfg feature="unicode-segment" -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow +==977== +{"artifact":"/hello/target/release/deps/regex_syntax-fc954162c3ed8ec3.d","emit":"dep-info"} +{"artifact":"/hello/target/release/deps/libregex_syntax-fc954162c3ed8ec3.rmeta","emit":"metadata"} +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x4b3d23)[0x400215fd23] +/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x4005cab520] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZNK4llvm13AttributeList19addAttributeAtIndexERNS_11LLVMContextEjNS_9AttributeE+0x834)[0x40088d3484] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZN4llvm8Function19addAttributeAtIndexEjNS_9AttributeE+0x18)[0x40088d2c48] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs4_NtCsfrnhObXyzQM_18rustc_codegen_llvm3abiINtNtNtCsaEkRwEFRwNk_12rustc_target3abi4call5FnAbiNtNtCs12ixbLjc5mB_12rustc_middle2ty2TyENtB5_12FnAbiLlvmExt16apply_attrs_llfn+0x101)[0x40033d52e1] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXNtCsfrnhObXyzQM_18rustc_codegen_llvm9mono_itemNtNtB4_7context9CodegenCxNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7declare16PreDefineMethods12predefine_fn+0x56a)[0x40033bba5a] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x17007c0)[0x40033ac7c0] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23761e6)[0x40040221e6] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2373a6f)[0x400401fa6f] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23a1e45)[0x400404de45] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs5_CsfrnhObXyzQM_18rustc_codegen_llvmNtB5_18LlvmCodegenBackendNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7backend14CodegenBackend13codegen_crate+0xda)[0x400400e70a] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23544e7)[0x40040004e7] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x233ac88)[0x4003fe6c88] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvMs0_NtCsf5CM6ndXTHU_15rustc_interface7queriesNtB5_7Queries15ongoing_codegen+0xaf)[0x4003fdd02f] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2308b04)[0x4003fb4b04] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x22ee134)[0x4003f9a134] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23213e9)[0x4003fcd3e9] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/libstd-8d61b92a0a02f53a.so(rust_metadata_std_cd3cf6af28dff6de+0xa7d03)[0x400598fd03] +/lib/x86_64-linux-gnu/libc.so.6(+0x94947)[0x4005cfd947] +/lib/x86_64-linux-gnu/libc.so.6(clone+0x44)[0x4005d8da44] +Segmentation fault (core dumped) +``` |