diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-16 16:59:00 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-16 16:59:33 +0000 |
| commit | 9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch) | |
| tree | b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/permissions | |
| parent | b89a938452613061c0f1f23e710281cf5c83cb29 (diff) | |
| download | emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip | |
add 18th iteration of classifier
Diffstat (limited to 'results/classifier/118/permissions')
176 files changed, 37660 insertions, 0 deletions
diff --git a/results/classifier/118/permissions/1013888 b/results/classifier/118/permissions/1013888 new file mode 100644 index 00000000..96c5ba59 --- /dev/null +++ b/results/classifier/118/permissions/1013888 @@ -0,0 +1,134 @@ +register: 0.924 +permissions: 0.921 +semantic: 0.919 +assembly: 0.904 +graphic: 0.904 +virtual: 0.900 +architecture: 0.896 +debug: 0.896 +PID: 0.893 +device: 0.892 +arm: 0.890 +performance: 0.883 +kernel: 0.880 +VMM: 0.873 +user-level: 0.871 +socket: 0.867 +files: 0.856 +risc-v: 0.853 +mistranslation: 0.847 +vnc: 0.846 +peripherals: 0.845 +hypervisor: 0.832 +ppc: 0.829 +network: 0.826 +boot: 0.826 +KVM: 0.816 +x86: 0.798 +TCG: 0.784 +i386: 0.701 + +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/118/permissions/1066 b/results/classifier/118/permissions/1066 new file mode 100644 index 00000000..ca93347c --- /dev/null +++ b/results/classifier/118/permissions/1066 @@ -0,0 +1,62 @@ +permissions: 0.939 +device: 0.895 +PID: 0.823 +performance: 0.816 +graphic: 0.799 +network: 0.697 +hypervisor: 0.685 +virtual: 0.672 +semantic: 0.601 +mistranslation: 0.587 +boot: 0.568 +files: 0.561 +kernel: 0.553 +ppc: 0.545 +vnc: 0.521 +risc-v: 0.506 +socket: 0.484 +register: 0.480 +VMM: 0.476 +architecture: 0.475 +arm: 0.457 +debug: 0.440 +i386: 0.434 +user-level: 0.426 +TCG: 0.420 +x86: 0.401 +peripherals: 0.364 +KVM: 0.358 +assembly: 0.292 + +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/118/permissions/1067 b/results/classifier/118/permissions/1067 new file mode 100644 index 00000000..301341a6 --- /dev/null +++ b/results/classifier/118/permissions/1067 @@ -0,0 +1,114 @@ +permissions: 0.958 +peripherals: 0.940 +performance: 0.930 +PID: 0.914 +network: 0.882 +graphic: 0.865 +device: 0.848 +files: 0.801 +TCG: 0.787 +ppc: 0.771 +socket: 0.713 +vnc: 0.679 +kernel: 0.670 +user-level: 0.653 +arm: 0.632 +architecture: 0.623 +risc-v: 0.583 +boot: 0.573 +semantic: 0.550 +VMM: 0.500 +register: 0.444 +assembly: 0.366 +mistranslation: 0.317 +hypervisor: 0.304 +i386: 0.303 +debug: 0.204 +virtual: 0.115 +x86: 0.033 +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/118/permissions/1067517 b/results/classifier/118/permissions/1067517 new file mode 100644 index 00000000..bff13642 --- /dev/null +++ b/results/classifier/118/permissions/1067517 @@ -0,0 +1,111 @@ +permissions: 0.817 +virtual: 0.802 +socket: 0.754 +graphic: 0.751 +debug: 0.715 +performance: 0.714 +register: 0.704 +user-level: 0.704 +assembly: 0.703 +architecture: 0.700 +x86: 0.693 +device: 0.691 +PID: 0.690 +TCG: 0.686 +KVM: 0.681 +semantic: 0.680 +network: 0.680 +kernel: 0.673 +peripherals: 0.650 +vnc: 0.649 +ppc: 0.644 +hypervisor: 0.620 +arm: 0.617 +files: 0.582 +boot: 0.582 +VMM: 0.580 +mistranslation: 0.573 +risc-v: 0.552 +i386: 0.450 + +qemu dosn't save snapshots with the 'commit' command + +Usually there is the 'commit' command in qemu which is described as followed: "commit changes to the disk images (if -snapshot is used) or backing files" +From the context i though if i start a guest with the "-snapshot" option, the commit command would save all the changes back to the file. I've tried it out but i didn't get it to work. I tried a few things like first use savevm or stop and than commit all, but actually nothing works. +Interestingly, when using qcow2 files qemu doesn't show's any error at all. The changes in the guest just won't get saved. But if i'm using lvm2 partitions i would get I/O errors after execute 'commit all'. That's probably because lvm2 doesn't support this feature.?!? However i made a attachment which shows the error's in the guest (dmesg). + +Right now i started the guest with following command: +/usr/bin/qemu-system-x86_64 -name g64 -runas kvm -m 4096 -smp 2 \ +-monitor unix:/var/run/kvm/g64.sock,server,nowait -pidfile /var/run/kvm/g64.pid -daemonize -snapshot \ +-device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent \ +-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ +-drive file=/media/btrfs/g64.qcow2,if=virtio,cache=none,aio=threads \ +-netdev type=tap,id=g64_3,vhost=on,ifname=qtap3,script=no,downscript=no \ +-device virtio-net-pci,netdev=g64_3,mac=DE:AD:BE:EF:CB:22 \ +-spice port=5803,addr=192.168.2.60,password=secret -k de -cpu host \ +-usb -usbdevice tablet -vga qxl + +The system is stable gentoo: +Portage 2.1.11.9 (default/linux/amd64/10.0/no-multilib, gcc-4.5.4, glibc-2.15-r2, 3.4.9-gentoo x86_64) +================================================================= + System Settings +================================================================= +System uname: Linux-3.4.9-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5405_@_2.00GHz-with-gentoo-2.1 +Timestamp of tree: Tue, 16 Oct 2012 03:45:01 +0000 +app-shells/bash: 4.2_p37 +dev-lang/python: 2.7.3-r2, 3.2.3 +dev-util/cmake: 2.8.8-r3 +dev-util/pkgconfig: 0.27.1 +sys-apps/baselayout: 2.1-r1 +sys-apps/openrc: 0.9.8.4 +sys-apps/sandbox: 2.5 +sys-devel/autoconf: 2.68 +sys-devel/automake: 1.11.6 +sys-devel/binutils: 2.22-r1 +sys-devel/gcc: 4.5.4 +sys-devel/gcc-config: 1.7.3 +sys-devel/libtool: 2.4-r1 +sys-devel/make: 3.82-r3 +sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) +sys-libs/glibc: 2.15-r2 +Repositories: gentoo x-local x11 sunrise virtualization +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-O2 -pipe -march=native -fopenmp" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" +CXXFLAGS="-O2 -pipe -march=native -fopenmp" +DISTDIR="/usr/portage/distfiles" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS=" http://gentoo.supp.name/ http://ftp.fi.muni.cz/pub/linux/gentoo/ http://gentoo.mirror.web4u.cz/ http://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.ynet.sk/pub" +LANG="de_DE.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed -fopenmp" +LINGUAS="en" +MAKEOPTS="-j12" +PKGDIR="/usr/portage/packages" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" +PORTAGE_TMPDIR="/var/tmp" +PORTDIR="/usr/portage" +PORTDIR_OVERLAY="/home/clown/public/overlays/local /home/clown/public/overlays/layman/x11 /home/clown/public/overlays/layman/sunrise /home/clown/public/overlays/layman/virtualization" +SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage/" +USE="acl acpi amd64 berkdb bzip2 cli cracklib crypt cups cxx dbus dri fortran gdbm gif gpm iconv ipv6 mmx modules mudflap ncurses nls nptl openmp pam pbm pcre png pppd readline session sqlite sse sse2 ssl ssse3 tcpd threads unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="niash" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON + +================================================================= + Package Settings +================================================================= + +app-emulation/qemu-1.1.1-r1 was built with the following: +USE="aio caps curl ncurses sasl spice vde vhost-net -alsa -bluetooth -brltty -debug -doc -fdt -opengl -pulseaudio -python -rbd -sdl -smartcard -static -tci -tls -usbredir -virtfs -xattr -xen -xfs" QEMU_SOFTMMU_TARGETS="i386 x86_64 (-alpha) (-arm) -cris (-m68k) -microblaze -microblazeel (-mips) -mips64 -mips64el -mipsel (-ppc) (-ppc64) -ppcemb -s390x -sh4 -sh4eb (-sparc) -sparc64 -xtensa -xtensaeb" QEMU_USER_TARGETS="i386 x86_64 (-alpha) (-arm) -armeb -cris (-m68k) -microblaze -microblazeel (-mips) -mipsel (-ppc) (-ppc64) -ppc64abi32 -s390x -sh4 -sh4eb (-sparc) -sparc32plus -sparc64 -unicore32" + + + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1077116 b/results/classifier/118/permissions/1077116 new file mode 100644 index 00000000..a0f96b8e --- /dev/null +++ b/results/classifier/118/permissions/1077116 @@ -0,0 +1,130 @@ +permissions: 0.926 +debug: 0.919 +architecture: 0.919 +ppc: 0.898 +register: 0.897 +performance: 0.893 +virtual: 0.887 +semantic: 0.887 +graphic: 0.882 +arm: 0.881 +device: 0.862 +PID: 0.858 +files: 0.847 +socket: 0.847 +kernel: 0.832 +hypervisor: 0.832 +assembly: 0.822 +network: 0.812 +risc-v: 0.809 +KVM: 0.798 +peripherals: 0.788 +user-level: 0.788 +boot: 0.779 +TCG: 0.777 +vnc: 0.718 +mistranslation: 0.696 +VMM: 0.695 +x86: 0.662 +i386: 0.502 + +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/118/permissions/1079 b/results/classifier/118/permissions/1079 new file mode 100644 index 00000000..6840e52f --- /dev/null +++ b/results/classifier/118/permissions/1079 @@ -0,0 +1,62 @@ +x86: 0.992 +permissions: 0.963 +arm: 0.937 +device: 0.921 +graphic: 0.919 +debug: 0.895 +PID: 0.798 +semantic: 0.781 +boot: 0.755 +architecture: 0.731 +register: 0.604 +user-level: 0.600 +files: 0.599 +TCG: 0.565 +virtual: 0.564 +ppc: 0.564 +performance: 0.525 +vnc: 0.518 +network: 0.497 +VMM: 0.494 +risc-v: 0.446 +peripherals: 0.391 +socket: 0.385 +mistranslation: 0.368 +hypervisor: 0.318 +assembly: 0.245 +kernel: 0.161 +KVM: 0.111 +i386: 0.048 + +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/118/permissions/1089281 b/results/classifier/118/permissions/1089281 new file mode 100644 index 00000000..669990ba --- /dev/null +++ b/results/classifier/118/permissions/1089281 @@ -0,0 +1,114 @@ +permissions: 0.881 +semantic: 0.838 +debug: 0.814 +virtual: 0.810 +user-level: 0.791 +architecture: 0.787 +register: 0.787 +mistranslation: 0.776 +performance: 0.775 +peripherals: 0.773 +kernel: 0.766 +vnc: 0.760 +hypervisor: 0.756 +TCG: 0.750 +network: 0.749 +graphic: 0.747 +socket: 0.746 +KVM: 0.744 +x86: 0.733 +ppc: 0.718 +device: 0.716 +assembly: 0.715 +arm: 0.711 +boot: 0.702 +PID: 0.689 +files: 0.663 +VMM: 0.651 +risc-v: 0.639 +i386: 0.504 + +kvm crash when writing on disk + +When running the following command: + +/usr/bin/kvm -S -M pc-1.0 -cpu qemu32 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name winxp -uuid f86ef88f-b90e-699a-74b8-9675063fc26e -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive file=/home/master/xpnew.iso,if=none,media=cdrom,id=drive-ide0-0-0,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/var/lib/zentyal/machines/winxp/winxp.img,if=none,id=drive-scsi0-0-0,format=qcow2 -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=18,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=b3:b8:a9:49:a2:f8,bus=pci.0,addr=0x3 -usb -device usb-mouse,id=input0 -vnc 0.0.0.0:0,password -k de -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + + +running a windows installation (for instance, it has crashed with other OS), when the guest OS installer has reached 60% of the copying files process, the following errors can be found, and KVM gets Force Closed (i am recollecting errors from different times I have tried to references to memory positions may vary) + +syslog: + +Nov 26 19:46:59 mikeboxx kernel: [2254718.689953] kvm6983 general protection ip:7fc451d4be08 sp:7fc44991ab80 error:0 in libc-2.15.so[7fc451ccd000+1b5000] + +/var/log/libvirt/libvirtd.log: + +2012-11-21 10:01:26.464+0000: 16050: error : qemuMonitorIO:603 : internal error End of file from monitor + +/var/log/libvirt/qemu/winxp-ajur.log + +**enclosed as it has a long size due to the core dump + + +The linux kernel running is this one: + +3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +Libvirtd versions are these: +root@mikeboxx:/home/ebox-remote-support# dpkg -l | grep libvirt +ii libvirt-bin 0.9.8-2ubuntu17.4 programs for the libvirt library +ii libvirt0 0.9.8-2ubuntu17.4 library for interfacing with different virtualization systems + +and KVM - QEMU versions are these ones: +root@mikeboxx:/home/ebox-remote-support# dpkg -l | grep qemu +ii qemu-common 1.0+noroms-0ubuntu14.3 qemu common functionality (bios, documentation, etc) +ii qemu-kvm 1.0+noroms-0ubuntu14.3 Full virtualization on i386 and amd64 hardware +ii qemu-utils 1.0+noroms-0ubuntu14.3 qemu utilities + + + +I have checked bug #1022901 in https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1022901 due to the similarity of the error "internal error End of file from monitor", but the sintoms are not the same as long as the partition where the img file resides has plenty of space and so does the img itself: + +root@mikeboxx:/home/ebox-remote-support# df -h +Filesystem Size Used Avail Use% Mounted on +/dev/sda1 226G 3.4G 211G 2% / + +root@mikeboxx:/home/ebox-remote-support# qemu-img info /var/lib/zentyal/machines/winxp/winxp.img +image: /var/lib/zentyal/machines/winxp/winxp.img +file format: qcow2 +virtual size: 11G (11559501824 bytes) +disk size: 384M +cluster_size: 65536 + + +Can you help us to solve this? Case you needed any information else, please do not hesitate to ask for it + + + +On Wed, Dec 12, 2012 at 10:19:06AM -0000, xavy wrote: +> Public bug reported: +> +> When running the following command: +> +> /usr/bin/kvm -S -M pc-1.0 -cpu qemu32 -enable-kvm -m 1024 -smp +> 1,sockets=1,cores=1,threads=1 -name winxp -uuid f86ef88f-b90e-699a- +> 74b8-9675063fc26e -nodefconfig -nodefaults -chardev +> socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait +> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no- +> shutdown -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive + +I'm afraid the emulated LSI SCSI adapter has known issues and doesn't +seem to be under active development. + +Use IDE for compatibility or virtio-blk if you're willing to install the +virtio-win guest drivers. There is also SATA (AHCI) and MegaSAS SCSI +support if you don't want to use IDE/virtio-blk. + +Stefan + + +Running it with ide solved the FC. +Thanks for the comments Stefan ;) + +Closing according to comment #2 and #3 + diff --git a/results/classifier/118/permissions/1129571 b/results/classifier/118/permissions/1129571 new file mode 100644 index 00000000..ead6647c --- /dev/null +++ b/results/classifier/118/permissions/1129571 @@ -0,0 +1,227 @@ +permissions: 0.879 +peripherals: 0.858 +semantic: 0.853 +arm: 0.818 +device: 0.809 +graphic: 0.801 +architecture: 0.791 +assembly: 0.781 +risc-v: 0.747 +PID: 0.746 +register: 0.742 +performance: 0.729 +virtual: 0.719 +files: 0.673 +user-level: 0.673 +boot: 0.670 +debug: 0.662 +TCG: 0.616 +socket: 0.613 +vnc: 0.605 +ppc: 0.600 +kernel: 0.583 +hypervisor: 0.572 +mistranslation: 0.552 +x86: 0.518 +network: 0.515 +KVM: 0.496 +VMM: 0.474 +i386: 0.381 + +libreoffice armhf FTBFS + +We have been experiencing FTBFS of LibreOffice 3.5.7, 12.04, armhf in the launchpad buildds. We believe this is likely due to an error in qemu. + +While we do not have a small test case yet, we do have a build log (attaching here). + +The relevant snippet from the build log is: + +3.5.7/solver/unxlngr.pro/bin/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-analyzers-2.3.jar" com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir ../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swriter_cs.zip.unxlngr.pro +dmake: Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip' + +We believe this is from bash error code 128 + 4, where 4 is illegal instruction, thus leading us to suspect qemu. + +Any help in tracking this down would be appreciated. + + + +Serge, I asked Alex to escalate this because it has required us to make a devirtualised PPA for a commercial project that involves libreoffice builds. This has some risk of being an operational problem, because it's going to be using Ubuntu build resources rather than the usual PPA ones. I'd appreciate any help you can offer in sorting this out so that we can go back to using virtualised PPAs for this. + +I believe that this is with qemu 1.3.0+dfsg-1~exp3ubuntu8~3.IS.12.04 and Linux 2.6.24-32-xen. + +Well, the first step would be to provide a reasonably tractable set of reproduce instructions (at minimum, something like "do this to set up a chroot, then in the chroot run this command and watch it SIGILL".) Also checking it still repros on 1.4.0 (just released) would be nice (though I don't think we've fixed anything in this area, it's an easy thing to try...) + +However I would not be too optimistic -- Java is typically heavily threaded, and QEMU user-mode has a number of known problems with handling multithreaded guests. It's possible this will turn out to be a fairly easy fix, but it's equally possible it will just be another manifestation of problems like LP:668799. + + +Trying to reproduce... + +On a stock ubuntu raring system, I did + +sudo apt-get install lxc qemu-user qemu-user-static +sudo lxc-create -t ubuntu -n r1 -- -a armhf +sudo lxc-start -n r1 +# log into console as ubuntu/ubuntu, there do: +sudo apt-get install ca-certificates-java + +That gave me the attached error (reproducible). + +"The relevant snippet from the build log" doesn't even show the complete command ... + + +The actual command from the build log: + +/usr/lib/jvm/java-6-openjdk-armhf/bin/java -cp ".:../../unxlngr.pro/class:/usr/lib/jvm/java-6-openjdk-armhf/jre/lib/rt.jar:.:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin +/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unx +lngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/ +solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/bu +ild/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/so +lver/unxlngr.pro/bin/lucene-analyzers-2.3.jar" com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir ../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swrit +er_cs.zip.unxlngr.pro +dmake: Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip' + + +Interestingly, this happens after we've successfully run exactly the same Java command to produce swriter_foo.zip for various other values of 'foo' (different locales/languages?) My suspicion is that (a) maybe we're running out of address space? (b) this is going to be really painful to track down because it's obviously dependent on the data input to the tool. Does the build reproducibly fail on exactly the same bit every time? + +Serge: that also looks like it's probably some issue with running Java under QEMU, but it doesn't seem to be the same thing at all as the LibreOffice errors in the build log... + + +Having rebuilt from upstream qemu, the bug when installing ca-certificates-java is solved. Now trying the main package build. + +ubuntu@r1:~$ /usr/lib/jvm/default-java/bin/javac --version +Segmentation fault (core dumped) + + +ubuntu@r1:~$ /usr/lib/jvm/default-java/bin/javac --version +# +# A fatal error has been detected by the Java Runtime Environment: +# +# Internal Error (os_linux_zero.cpp:285), pid=326, tid=4120921200 +# fatal error: caught unhandled signal 11 +# +# JRE version: 7.0_13-b20 +# Java VM: OpenJDK Zero VM (22.0-b10 mixed mode linux-arm ) +# Derivative: IcedTea7 2.3.6 +# Distribution: Ubuntu Raring Ringtail (development branch), package 7u13-2.3.6-1ubuntu1 +# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try +"ulimit -c unlimited" before starting Java again +# +# An error report file with more information is saved as: +# /home/ubuntu/hs_err_pid326.log +# +# If you would like to submit a bug report, please include +# instructions on how to reproduce the bug and visit: +# https://bugs.launchpad.net/ubuntu/+source/openjdk-7/ +# The crash happened outside the Java Virtual Machine in native code. +# See problematic frame for where to report the bug. +# +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) + + +coredump from running javac -version + +hs_err log file from same javac -version run. + +(I understand that still looks like a different error... but i can't get to the reported error to reproduce without getting past this one) + +The patch at least allows java to run without segfaulting. I have not tried to build libreoffice yet. + +Late in 2012 libc started using FUTEX_WAIT_BITSET instead of FUTEX_WAIT so teach qemu about it so it will forward the call to the host kernel rather than returning -TARGET_ENOSYS. The patch also fixes a problem with qemu strace printing when the FUTEX_CLOCK_REALTIME bit is present in the futex cmd. + +Thanks for the patch. John, since you're going to be doing more QEMU work in future I'd encourage you to go through the process of submitting it to upstream's mailing list and shepherding it through the patch review process. Upstream's patch submission guidelines are here: http://wiki.qemu.org/Contribute/SubmitAPatch. A couple of remarks about this patch specifically: + * it's going to need a signed-off-by: line + * it's fixing two different bugs (the actual futex bug and the strace error) and they will need to be in two different patches + * you don't need to treat FUTEX_WAIT and _WAIT_BITSET separately, you can just always pass val3 to sys_futex in both cases (if the op is not FUTEX_WAIT_BITSET the kernel will just ignore the extra parameter) + +Optional but nice: try the futex related bits of the LTP (http://wiki.qemu.org/Testing/LTP) and see if more of them pass now (or at least that we don't regress). + + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +Peter, sorry I attached this quick patch to the bug for Serge to try +out with the intent of sending a proper patch upstream later. +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) +Comment: Using GnuPG with undefined - http://www.enigmail.net/ + +iEYEARECAAYFAlEpNucACgkQnZiV2bTs2IrVxwCgyV0unFmrEiZIZuLVo9j92imn +QlYAoIj858HtwqzlaXomae0aLaGNUAJx +=sDo2 +-----END PGP SIGNATURE----- + + +Thanks, I'll give that a shot! + +@John, + +with that patch applied on top of 1.4.0, I still get segfault when running javac --version. + +It turns out it is javac in raring chroots which gives me the problem. I finally realized that the bug is about a libreoffice build in a precise chroot. I'm running a build (which has been running most of the day) with qemu-arm-static from a hand-built qemu source tree with this morning's latest HEAD. No bugs yet. I suspect 1.4.0 in general fixes it. + +Could you try an updated raring with qemu-user-static 1.4.0? + +Trying to build on a raring amd64 host in a raring armhf chroot, two failures so far. First time was a hang checking ant, an xlc-ls showed several java threads hung. Second time was a segfault again in java. So I have no problems reproducing this now locally. Hang seems like thread waiting for futex not being awakened but that is just my speculation. I will chase this further. + +One more point, these two failures were locally build 1.4.0 with my FUTEX_WAIT_BITSET patches applied. + +John: you might also like to try with this patchset applied: +http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg04207.html +as that fixes one category of races. There are still other races that can cause segfaults and other problems (as the cover letter describes) but it's possible this particular case will be fixed by it. + + +@John, + +as the bug description was about the 12.04 libreoffice build, i'm actually using a raring host with 1.4.0 qemu-user-static, with a *precise* armhf container. The precise libreoffice has been building all day friday and friday so far with no incidents. + +In a raring chroot, I've not been able to get past the javac crash. Once I'm sure the precise package builds, I intend to do some printf debugging to get past the javac crash. + +I see the same thing javac hanging. This is with a raring chroot on raring host with qemu compiled from upstream 1.4.0 plus Peter's patches and my linux-user patches + +I noticed for the case where javac --version hangs the process has several threads all waiting on futexes. Details attached. + +John: it would be interesting to try to determine whether that hang has the same root cause as the cmake and boehm-gc hangs, ie the thing that is supposed to post the futex is a signal handler whose signal comes in either just before or during the syscall [either way, the emulated code for the handler won't be able to run until the syscall returns, which it never does]. + + +cmake bug: LP:955379. +sketch of how to fix signal races: http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html + + +@Peter, + +so you'd recommend testing for the javac hang with https://launchpadlibrarian.net/124927320/cmake.patch ? + +(will try until you shout "no, you idiot") + +Well, you can try, but I don't think it is very likely to help. The patch is a hacky workaround for select() in particular, not for the entire class of hangs. + + +javac switched from hanging forever to segfaulting. + +@Alex, + +in a + armhf precise container +on a + raring host with qemu-user-static version 1.4.0+dfsg-1expubuntu2 + +a libreoffice build has now been going for 6 days with no failures +yet. (How long does that thing go on? :) + +Unless you say otherwise I'm now going to shift to looking into the +javac failure in a *raring* container. + + +Can you still reproduce this issue with the latest upstream version of QEMU? + +The attachment "FUTEX_WAIT_BITSET.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] + +There hasn't been a reply to my question in comment #32 within +months, so I assume nobody cares about this anymore. So I'm closing this +ticket now... + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1146 b/results/classifier/118/permissions/1146 new file mode 100644 index 00000000..9ebb062c --- /dev/null +++ b/results/classifier/118/permissions/1146 @@ -0,0 +1,131 @@ +permissions: 0.851 +graphic: 0.841 +mistranslation: 0.838 +register: 0.811 +user-level: 0.790 +debug: 0.783 +peripherals: 0.778 +arm: 0.776 +semantic: 0.753 +hypervisor: 0.737 +VMM: 0.736 +performance: 0.735 +device: 0.732 +ppc: 0.727 +TCG: 0.707 +boot: 0.704 +assembly: 0.691 +architecture: 0.691 +risc-v: 0.687 +vnc: 0.672 +PID: 0.669 +virtual: 0.666 +KVM: 0.651 +socket: 0.628 +x86: 0.605 +kernel: 0.594 +i386: 0.528 +network: 0.526 +files: 0.510 + +ppc: mac99 immediate segfault in vga_init with bus=pci.0 +Description of problem: +I'm trying to figure out why `mac99` PowerPC VMs launched by libvirt always immediately segfault (signal SIGSEGV, segmentation fault). I narrowed it down to the `bus=pci.0` option that libvirt adds to the `-device VGA` argument. If I remove the `bus=pci.0` option then it doesn't segfault. Full backtrace from gdb: + +``` +#0 memory_region_update_container_subregions (subregion=0x555556d795e0) at ../softmmu/memory.c:2538 + mr = <optimized out> + other = <optimized out> + alias = <optimized out> + __PRETTY_FUNCTION__ = "memory_region_add_subregion_common" +#1 memory_region_add_subregion_common (mr=<optimized out>, offset=<optimized out>, subregion=0x555556d795e0) at ../softmmu/memory.c:2556 + alias = <optimized out> + __PRETTY_FUNCTION__ = "memory_region_add_subregion_common" +#2 0x0000555555b81fad in vga_init (s=s@entry=0x555556dbe590, obj=obj@entry=0x555556dbdb70, address_space=0x5555568ea570, address_space_io=address_space_io@entry=0x5555568ea790, init_vga_ports=init_vga_ports@entry=true) at ../hw/display/vga.c:2305 + vga_io_memory = 0x555556d795e0 + vga_ports = 0x55555623bda0 <vga_portio_list> + vbe_ports = 0x55555623bd20 <vbe_portio_list> +#3 0x00005555558fbe3a in pci_std_vga_realize (dev=0x555556dbdb70, errp=<optimized out>) at ../hw/display/vga-pci.c:245 + d = 0x555556dbdb70 + s = 0x555556dbe590 + qext = false + edid = false +#4 0x0000555555990128 in pci_qdev_realize (qdev=0x555556dbdb70, errp=<optimized out>) at ../hw/pci/pci.c:2218 + pci_dev = 0x555556dbdb70 + pc = <optimized out> + klass = <optimized out> + local_err = 0x0 + is_default_rom = <optimized out> + class_id = <optimized out> + __func__ = "pci_qdev_realize" +#5 0x0000555555c6aa2f in device_set_realized (obj=<optimized out>, value=true, errp=0x7fffffffd570) at ../hw/core/qdev.c:553 + dev = 0x555556dbdb70 + dc = 0x555556634130 + hotplug_ctrl = 0x0 + bus = <optimized out> + ncl = <optimized out> + local_err = 0x0 + unattached_parent = false + unattached_count = 12 + __func__ = "device_set_realized" + __PRETTY_FUNCTION__ = "device_set_realized" +#6 0x0000555555c6de7a in property_set_bool (obj=0x555556dbdb70, v=<optimized out>, name=<optimized out>, opaque=0x5555564c40b0, errp=0x7fffffffd570) at ../qom/object.c:2273 + prop = 0x5555564c40b0 + value = true +#7 0x0000555555c70158 in object_property_set (obj=obj@entry=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", v=v@entry=0x555556d745d0, errp=errp@entry=0x7fffffffd570) at ../qom/object.c:1408 + _auto_errp_prop = {local_err = 0x0, errp = 0x7fffffffd570} + prop = <optimized out> + __func__ = "object_property_set" +#8 0x0000555555c73384 in object_property_set_qobject (obj=obj@entry=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", value=value@entry=0x555556d732c0, errp=errp@entry=0x7fffffffd570) at ../qom/qom-qobject.c:28 + v = 0x555556d745d0 + ok = <optimized out> +#9 0x0000555555c703c9 in object_property_set_bool (obj=0x555556dbdb70, name=name@entry=0x555555ee1196 "realized", value=value@entry=true, errp=errp@entry=0x7fffffffd570) at ../qom/object.c:1477 + qbool = 0x555556d732c0 + ok = <optimized out> +#10 0x0000555555c69ec2 in qdev_realize (dev=<optimized out>, bus=bus@entry=0x5555568eb750, errp=errp@entry=0x7fffffffd570) at ../hw/core/qdev.c:333 + __PRETTY_FUNCTION__ = "qdev_realize" +#11 0x0000555555a1db80 in qdev_device_add_from_qdict (opts=opts@entry=0x555556d72130, from_json=from_json@entry=false, errp=<optimized out>, errp@entry=0x5555563be3d0 <error_fatal>) at /home/rhansen/floss/qemu/include/hw/qdev-core.h:17 + _auto_errp_prop = {local_err = 0x0, errp = 0x5555563be3d0 <error_fatal>} + dc = 0x555556634130 + driver = 0x555556d73150 "VGA" + path = <optimized out> + id = <optimized out> + dev = 0x555556dbdb70 + bus = <optimized out> + __func__ = "qdev_device_add_from_qdict" +#12 0x0000555555a1dca6 in qdev_device_add (opts=0x5555564c10d0, errp=errp@entry=0x5555563be3d0 <error_fatal>) at ../softmmu/qdev-monitor.c:733 + qdict = 0x555556d72130 + ret = <optimized out> +#13 0x0000555555a1fb83 in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:1142 + dev = <optimized out> +#14 0x0000555555dde692 in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x555555a1fb70 <device_init_func>, opaque=opaque@entry=0x0, errp=0x5555563be3d0 <error_fatal>) at ../util/qemu-option.c:1135 + loc = {kind = LOC_CMDLINE, num = 2, ptr = 0x7fffffffd990, prev = 0x5555563be400 <std_loc>} + opts = 0x5555564c10d0 + next = 0x0 + rc = 0 + __PRETTY_FUNCTION__ = "qemu_opts_foreach" +#15 0x0000555555a22921 in qemu_create_cli_devices () at ../softmmu/vl.c:2522 + opt = <optimized out> + __func__ = "qmp_x_exit_preconfig" + __func__ = "qmp_x_exit_preconfig" +#16 qmp_x_exit_preconfig (errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:2590 + __func__ = "qmp_x_exit_preconfig" + __func__ = "qmp_x_exit_preconfig" +#17 qmp_x_exit_preconfig (errp=0x5555563be3d0 <error_fatal>) at ../softmmu/vl.c:2582 + __func__ = "qmp_x_exit_preconfig" +#18 0x0000555555a25ec2 in qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:3586 + opts = <optimized out> + icount_opts = <optimized out> + accel_opts = <optimized out> + olist = <optimized out> + optind = 11 + optarg = 0x7fffffffdec3 "chardev=mon0,mode=readline" + machine_class = <optimized out> + userconfig = <optimized out> + vmstate_dump_file = <optimized out> + __func__ = "qemu_init" + __PRETTY_FUNCTION__ = "qemu_init" +#19 0x000055555585410d in qemu_main (envp=0x0, argv=<optimized out>, argc=<optimized out>) at ../softmmu/main.c:47 + status = <optimized out> +#20 main (argc=<optimized out>, argv=<optimized out>) at ../softmmu/main.c:47 +``` diff --git a/results/classifier/118/permissions/1163474 b/results/classifier/118/permissions/1163474 new file mode 100644 index 00000000..885c2490 --- /dev/null +++ b/results/classifier/118/permissions/1163474 @@ -0,0 +1,44 @@ +permissions: 0.977 +peripherals: 0.935 +x86: 0.903 +device: 0.864 +user-level: 0.795 +boot: 0.739 +graphic: 0.702 +network: 0.661 +mistranslation: 0.609 +socket: 0.586 +PID: 0.577 +assembly: 0.569 +semantic: 0.501 +architecture: 0.464 +ppc: 0.456 +vnc: 0.456 +performance: 0.416 +files: 0.367 +kernel: 0.346 +arm: 0.327 +register: 0.298 +VMM: 0.257 +debug: 0.241 +risc-v: 0.240 +virtual: 0.211 +i386: 0.194 +KVM: 0.192 +TCG: 0.182 +hypervisor: 0.173 + +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/118/permissions/1175513 b/results/classifier/118/permissions/1175513 new file mode 100644 index 00000000..8f6a1bb5 --- /dev/null +++ b/results/classifier/118/permissions/1175513 @@ -0,0 +1,140 @@ +permissions: 0.928 +virtual: 0.882 +graphic: 0.880 +register: 0.871 +user-level: 0.866 +debug: 0.862 +assembly: 0.856 +semantic: 0.851 +device: 0.842 +performance: 0.841 +peripherals: 0.838 +network: 0.832 +architecture: 0.829 +boot: 0.820 +kernel: 0.819 +files: 0.815 +socket: 0.814 +KVM: 0.808 +PID: 0.808 +ppc: 0.797 +hypervisor: 0.763 +vnc: 0.761 +TCG: 0.748 +arm: 0.747 +mistranslation: 0.746 +x86: 0.714 +risc-v: 0.670 +VMM: 0.646 +i386: 0.465 + +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/118/permissions/1180777 b/results/classifier/118/permissions/1180777 new file mode 100644 index 00000000..35897648 --- /dev/null +++ b/results/classifier/118/permissions/1180777 @@ -0,0 +1,1346 @@ +permissions: 0.879 +mistranslation: 0.866 +debug: 0.861 +performance: 0.858 +semantic: 0.856 +network: 0.847 +architecture: 0.835 +device: 0.828 +register: 0.826 +assembly: 0.819 +virtual: 0.812 +risc-v: 0.782 +user-level: 0.777 +peripherals: 0.772 +vnc: 0.770 +PID: 0.769 +boot: 0.746 +graphic: 0.739 +arm: 0.738 +KVM: 0.700 +x86: 0.691 +kernel: 0.675 +socket: 0.650 +TCG: 0.604 +VMM: 0.604 +hypervisor: 0.585 +ppc: 0.570 +files: 0.564 +i386: 0.363 + +RDP traffic freeze on quiet network + +Hi, + +I recently started using KVM over VirtualBox for my Office needs. I setup a Windows 7 VM on KVM and started using it through remote desktop. + +What happens is that, after some hours of usage, the remote desktop connection freezes. I thought it was a remmina bug, as the it was enough to kill and restart it to successfully connect again to the VM. + +However, today I've switched to a different RDP client (2X Client chromium app) and the freeze just happened again! + +Some information: +- the host and the VM are completely idle when the freeze occurs +- I've tried sniffing the network packets toward the RDP port during the freeze and found that the client is sending packets but no packet is sent back + + +Could this be a KVM issue? How can I further debug this one (I expect the freeze to happen again...)? + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +Uname: Linux 3.2.0-41-generic x86_64 +ApportVersion: 2.0.1-0ubuntu17.2 +Architecture: amd64 +Date: Thu May 16 14:12:40 2013 +MachineType: Hewlett-Packard HP ProBook 4520s +MarkForUpload: True +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash vt.handoff=7 +SourcePackage: qemu-kvm +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 08/26/2010 +dmi.bios.vendor: Hewlett-Packard +dmi.bios.version: 68AZZ Ver. F.0A +dmi.board.name: 1411 +dmi.board.vendor: Hewlett-Packard +dmi.board.version: KBC Version 57.30 +dmi.chassis.type: 10 +dmi.chassis.vendor: Hewlett-Packard +dmi.modalias: dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +dmi.product.name: HP ProBook 4520s +dmi.sys.vendor: Hewlett-Packard + + + +Thanks for reporting this bug. Could you please give us more +information on the VM host and the client? What do you mean +by 'kvm over virtualbox'? How exactly did you set it up? +Is the remote desktop running on a windows machine? + +My guess is that the answer lies in 'kvm on virtualbox', and +how that is exporting a display to the client. + +Marking this incomplete, please feel free to re-mark it new +after replying. Marking low priority as, IF I understand right, +the VM continues to run, making this annoying but with no risk of +data loss. + + status: incomplete + importance: low + + +Hi Serge, + +Thanks for the reply. + + +What I meant is that I started using KVM for my virtualization needs, while I was previously using VirtualBox. Sorry for not being clear on this point. + + +Yes the VM continues to run, however it is pretty annoying and can potentially imply that for me Win 7 on KVM is not usable in practice (think about hangs during customer presentations... ). + + +Thanks. + + + + +Could you show the exact remmina command you were using to connect to the VM? + +If you do 'gvncviewer localhost:0' (from the same machine on which kvm is running), what do you see? + +Hi Serge, + +I'm invoking remmina from the Unity shell, not from the terminal. + +As regard your question: I'm connecting to the VM via RDP, not VNC (it is +much faster). + + +On 5 June 2013 00:07, Serge Hallyn <email address hidden> wrote: + +> Could you show the exact remmina command you were using to connect to +> the VM? +> +> If you do 'gvncviewer localhost:0' (from the same machine on which kvm +> is running), what do you see? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> New +> +> Bug description: +> Hi, +> +> I recently started using KVM over VirtualBox for my Office needs. I +> setup a Windows 7 VM on KVM and started using it through remote +> desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +Quoting f3a97 (<email address hidden>): +> Hi Serge, +> +> I'm invoking remmina from the Unity shell, not from the terminal. + +Could you please tell me, perhaps with some screenshots, exactly what +boxes you fill in how to start the connection? + +> As regard your question: I'm connecting to the VM via RDP, not VNC (it is +> much faster). + +IIUC RDP connects to the guest itself over the guest's network. vnc wlil +connect to the kvm process. So if the problem has to do with the +guest's networking hanging, then connecting over vnc might let you +analyze the guest state despite guest network being down. + +When the RDP connection hangs, can you simply start a new one +immediately? + + +Hi Serge, + +Please find attached the remmina configuration screenshots. + +Yes, when the RDP connection hangs I simply close the RDP client and start +a new one immediately and it works correctly. + +As I mentioned, please consider that this happens also with a completely +different RDP client, so it probably has nothing to do with remmina itself. + +Thank you! + + +On 5 June 2013 14:30, Serge Hallyn <email address hidden> wrote: + +> Quoting f3a97 (<email address hidden>): +> > Hi Serge, +> > +> > I'm invoking remmina from the Unity shell, not from the terminal. +> +> Could you please tell me, perhaps with some screenshots, exactly what +> boxes you fill in how to start the connection? +> +> > As regard your question: I'm connecting to the VM via RDP, not VNC (it is +> > much faster). +> +> IIUC RDP connects to the guest itself over the guest's network. vnc wlil +> connect to the kvm process. So if the problem has to do with the +> guest's networking hanging, then connecting over vnc might let you +> analyze the guest state despite guest network being down. +> +> When the RDP connection hangs, can you simply start a new one +> immediately? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> New +> +> Bug description: +> Hi, +> +> I recently started using KVM over VirtualBox for my Office needs. I +> setup a Windows 7 VM on KVM and started using it through remote +> desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +It just happened again. + +This time I have recorded some new information. + +netstat shows a costant, non zero Send-Q: + +@ubuntu:~/WORKS/Programs/apache-jmeter-2.9/bin$ date ; netstat -atn | grep +3389 +Wed Jun 5 15:23:24 CEST 2013 +tcp 0 7301 192.168.122.1:59458 192.168.122.116:3389 + ESTABLISHED +@ubuntu:~/WORKS/Programs/apache-jmeter-2.9/bin$ date ; netstat -atn | grep +3389 +Wed Jun 5 15:23:27 CEST 2013 +tcp 0 7301 192.168.122.1:59458 192.168.122.116:3389 + ESTABLISHED +@ubuntu:~/WORKS/Programs/apache-jmeter-2.9/bin$ date ; netstat -atn | grep +3389 +Wed Jun 5 15:23:47 CEST 2013 +tcp 0 7301 192.168.122.1:59458 192.168.122.116:3389 + ESTABLISHED +@ubuntu:~/WORKS/Programs/apache-jmeter-2.9/bin$ date ; netstat -atn | grep +3389 +Wed Jun 5 15:24:34 CEST 2013 +tcp 0 7301 192.168.122.1:59458 192.168.122.116:3389 + ESTABLISHED + +Sniffing that connection with tcpdump, I can see that no packets flows back +from the VM (port 3389) back to the client: + +15:22:03.402659 IP 192.168.122.1.59458 > 192.168.122.116.3389: Flags [P.], +seq 2389102186:2389102247, ack 1393955760, win 1968, options [nop,nop,TS +val 4537984 ecr 1648164], length 61 +15:22:03.402676 IP 192.168.122.1.59458 > 192.168.122.116.3389: Flags [P.], +seq 0:61, ack 1, win 1968, options [nop,nop,TS val 4537984 ecr 1648164], +length 61 + +--- 30 seconds here --- +15:24:03.722660 IP 192.168.122.1.59458 > 192.168.122.116.3389: Flags [P.], +seq 0:61, ack 1, win 1968, options [nop,nop,TS val 4568064 ecr 1648164], +length 61 +15:24:03.722675 IP 192.168.122.1.59458 > 192.168.122.116.3389: Flags [P.], +seq 0:61, ack 1, win 1968, options [nop,nop,TS val 4568064 ecr 1648164], +length 61 + + +Looks like a network issue? + + +On 5 June 2013 15:17, Stefano Doni <email address hidden> wrote: + +> Hi Serge, +> +> Please find attached the remmina configuration screenshots. +> +> Yes, when the RDP connection hangs I simply close the RDP client and start +> a new one immediately and it works correctly. +> +> As I mentioned, please consider that this happens also with a completely +> different RDP client, so it probably has nothing to do with remmina itself. +> +> Thank you! +> +> +> On 5 June 2013 14:30, Serge Hallyn <email address hidden> wrote: +> +>> Quoting f3a97 (<email address hidden>): +>> > Hi Serge, +>> > +>> > I'm invoking remmina from the Unity shell, not from the terminal. +>> +>> Could you please tell me, perhaps with some screenshots, exactly what +>> boxes you fill in how to start the connection? +>> +>> > As regard your question: I'm connecting to the VM via RDP, not VNC (it +>> is +>> > much faster). +>> +>> IIUC RDP connects to the guest itself over the guest's network. vnc wlil +>> connect to the kvm process. So if the problem has to do with the +>> guest's networking hanging, then connecting over vnc might let you +>> analyze the guest state despite guest network being down. +>> +>> When the RDP connection hangs, can you simply start a new one +>> immediately? +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1180777 +>> +>> Title: +>> Windows 7 VM freeze on Ubuntu 12.04 KVM +>> +>> Status in “qemu-kvm” package in Ubuntu: +>> New +>> +>> Bug description: +>> Hi, +>> +>> I recently started using KVM over VirtualBox for my Office needs. I +>> setup a Windows 7 VM on KVM and started using it through remote +>> desktop. +>> +>> What happens is that, after some hours of usage, the remote desktop +>> connection freezes. I thought it was a remmina bug, as the it was +>> enough to kill and restart it to successfully connect again to the VM. +>> +>> However, today I've switched to a different RDP client (2X Client +>> chromium app) and the freeze just happened again! +>> +>> Some information: +>> - the host and the VM are completely idle when the freeze occurs +>> - I've tried sniffing the network packets toward the RDP port during +>> the freeze and found that the client is sending packets but no packet is +>> sent back +>> +>> +>> Could this be a KVM issue? How can I further debug this one (I expect +>> the freeze to happen again...)? +>> +>> ProblemType: Bug +>> DistroRelease: Ubuntu 12.04 +>> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +>> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +>> Uname: Linux 3.2.0-41-generic x86_64 +>> ApportVersion: 2.0.1-0ubuntu17.2 +>> Architecture: amd64 +>> Date: Thu May 16 14:12:40 2013 +>> MachineType: Hewlett-Packard HP ProBook 4520s +>> MarkForUpload: True +>> ProcEnviron: +>> TERM=xterm +>> PATH=(custom, no user) +>> LANG=en_US.UTF-8 +>> SHELL=/bin/bash +>> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +>> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +>> vt.handoff=7 +>> SourcePackage: qemu-kvm +>> UpgradeStatus: No upgrade log present (probably fresh install) +>> dmi.bios.date: 08/26/2010 +>> dmi.bios.vendor: Hewlett-Packard +>> dmi.bios.version: 68AZZ Ver. F.0A +>> dmi.board.name: 1411 +>> dmi.board.vendor: Hewlett-Packard +>> dmi.board.version: KBC Version 57.30 +>> dmi.chassis.type: 10 +>> dmi.chassis.vendor: Hewlett-Packard +>> dmi.modalias: +>> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +>> dmi.product.name: HP ProBook 4520s +>> dmi.sys.vendor: Hewlett-Packard +>> +>> To manage notifications about this bug go to: +>> +>> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +>> +> +> + + +Confirmed in raring. + +Actually no, in my case after I had started up IE and left it sitting, the desktop logged me out, which made windows change its network settings so that RDP was not allowed. I had to log back in over spicy before I could reconnect over RDP. + +In fact that did not suffice (this is raring, not precise) - windows needed to reboot to reset the model=rtl8139 nic (over tap device). + +Could you tell me which network device type you are using? + +It looks like I should set up a precise host on which to test. + +Hi Serge, + +Thanks for that. + +Please find attached my VM complete xml configuration file (virsh dumpxml). + + + +On 12 June 2013 21:21, Serge Hallyn <email address hidden> wrote: + +> In fact that did not suffice (this is raring, not precise) - windows +> needed to reboot to reset the model=rtl8139 nic (over tap device). +> +> Could you tell me which network device type you are using? +> +> It looks like I should set up a precise host on which to test. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Hi, +> +> I recently started using KVM over VirtualBox for my Office needs. I +> setup a Windows 7 VM on KVM and started using it through remote +> desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +Hi, + +(You probably knkow this, but to explain my request, the RDP connection goes over the VM's virtual network card to talk directly to the VM. Provided you have only a single VM running, 'gvncviewer localhost:0' (or the equivalent with ssh port forwarding if you can't run X on the host) talks to the kvm process.) + +Could you please start the VM, run RDP until it hangs, then connect with vnc and use the windows network admin commands to see what windows thinks is going on? I.e. does it think it is still connected to a network? If not, can you simply reconnect, or do you have to restart the driver, or do you have to restart the VM altogether? + +I'm pretty sure htis is a bug in the qemu nic emulation, but am not sure where to begin diagnosing. + +Hi Serge, + +I performed the experiment you suggested: + +1) Connected with RDP client +2) Worked until it hanged +3) Successfully connected to the VM via virt-manager (RDP client still +freezed) +4) Verified that Windows is still connected to the network +5) Successfully pinged my host IP from within the VM (ping 192.168.122.1) + + +So it doesn't seem to be a network disconnect issue. + + +Can you think of anything else? + + + +Thanks! + + + +On 27 June 2013 16:12, Serge Hallyn <email address hidden> wrote: + +> Hi, +> +> (You probably knkow this, but to explain my request, the RDP connection +> goes over the VM's virtual network card to talk directly to the VM. +> Provided you have only a single VM running, 'gvncviewer localhost:0' (or +> the equivalent with ssh port forwarding if you can't run X on the host) +> talks to the kvm process.) +> +> Could you please start the VM, run RDP until it hangs, then connect with +> vnc and use the windows network admin commands to see what windows +> thinks is going on? I.e. does it think it is still connected to a +> network? If not, can you simply reconnect, or do you have to restart +> the driver, or do you have to restart the VM altogether? +> +> I'm pretty sure htis is a bug in the qemu nic emulation, but am not sure +> where to begin diagnosing. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Hi, +> +> I recently started using KVM over VirtualBox for my Office needs. I +> setup a Windows 7 VM on KVM and started using it through remote +> desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +Quoting f3a97 (<email address hidden>): +> Hi Serge, +> +> I performed the experiment you suggested: +> +> 1) Connected with RDP client +> 2) Worked until it hanged +> 3) Successfully connected to the VM via virt-manager (RDP client still +> freezed) +> 4) Verified that Windows is still connected to the network +> 5) Successfully pinged my host IP from within the VM (ping 192.168.122.1) + +Thanks! So just to be sure, after this did you check whether the RDP +client worked again? If not, were you able to re-connect with a new +RDP client? If so, then can you also re-connect with a new RDP client +without first connecting via VNC and pinging the host from the guest? +(This should tell us whether the problem is the RDP server in windows, +or the network connection at some layer going stale until we ping). + + +Hi Serge, + +In order to reconnect, I have simply restarted another RDP client without +any further step required (no need to use VNC and ping, it was just a test +to check network connectivity). + + +On 24 July 2013 15:16, Serge Hallyn <email address hidden> wrote: + +> Quoting f3a97 (<email address hidden>): +> > Hi Serge, +> > +> > I performed the experiment you suggested: +> > +> > 1) Connected with RDP client +> > 2) Worked until it hanged +> > 3) Successfully connected to the VM via virt-manager (RDP client still +> > freezed) +> > 4) Verified that Windows is still connected to the network +> > 5) Successfully pinged my host IP from within the VM (ping 192.168.122.1) +> +> Thanks! So just to be sure, after this did you check whether the RDP +> client worked again? If not, were you able to re-connect with a new +> RDP client? If so, then can you also re-connect with a new RDP client +> without first connecting via VNC and pinging the host from the guest? +> (This should tell us whether the problem is the RDP server in windows, +> or the network connection at some layer going stale until we ping). +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Hi, +> +> I have recently setup a Windows 7 VM on KVM and started using it +> through remote desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> +> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777/+subscriptions +> + + +Hi, + +I reported the #1212051 (https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1212051) bug with Windows XP, but reading this case i think it could be the same issue. + +I connect via RDP to my windows XP VM and after a while it seems to freeze, then, I connect via VNC an without doing anything the communications are restored between the VM and the outside world. So i can connect again with RDP. + +Even more, if i leave an open connection with VNC (minimized because is more slow than RDP), connecting via RDP has no trouble and no problem of freeze (lost of communications) occurs. + +f3a97, Could you do this test and tell if you have the same experience than i?, If so, my bug is the same of this. +Thanks. + + +Hi Hector, + + +My network configuration is different than yours - it is not bridged. +Perhaps this might help to diagnose the issue? + + +I'm now trying to sniff network traffic generated by the VM and see what +happens during RDP hangs: does it still poll outside servers (i.e. google +drive) or will become disconnected? + + +I'll report the results, stay tuned. + + +On 19 August 2013 00:42, Hector Perez <email address hidden> wrote: + +> Hi, +> +> I reported the #1212051 (https://bugs.launchpad.net/ubuntu/+source/qemu- +> kvm/+bug/1212051) bug with Windows XP, but reading this case i think it +> could be the same issue. +> +> I connect via RDP to my windows XP VM and after a while it seems to +> freeze, then, I connect via VNC an without doing anything the +> communications are restored between the VM and the outside world. So i +> can connect again with RDP. +> +> Even more, if i leave an open connection with VNC (minimized because is +> more slow than RDP), connecting via RDP has no trouble and no problem of +> freeze (lost of communications) occurs. +> +> f3a97, Could you do this test and tell if you have the same experience +> than i?, If so, my bug is the same of this. +> Thanks. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> Windows 7 VM freeze on Ubuntu 12.04 KVM +> +> Status in QEMU: +> New +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> +> Bug description: +> Hi, +> +> I have recently setup a Windows 7 VM on KVM and started using it +> through remote desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions +> + + +Hi, + +Eventually I've been able to reproduce the hang. + +Just to recap the experiment: I have recorded network traffic during RDP +connection hangs. The result is that the VM has do not experience total +network loss: network traffic continues to flow (tcpdump from the host on +ports other than 3389). + + + + + + +On 5 September 2013 15:22, Stefano Doni <email address hidden> wrote: + +> Hi Hector, +> +> +> My network configuration is different than yours - it is not bridged. +> Perhaps this might help to diagnose the issue? +> +> +> I'm now trying to sniff network traffic generated by the VM and see what +> happens during RDP hangs: does it still poll outside servers (i.e. google +> drive) or will become disconnected? +> +> +> I'll report the results, stay tuned. +> +> +> On 19 August 2013 00:42, Hector Perez <email address hidden> wrote: +> +>> Hi, +>> +>> I reported the #1212051 (https://bugs.launchpad.net/ubuntu/+source/qemu- +>> kvm/+bug/1212051<https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1212051>) +>> bug with Windows XP, but reading this case i think it +>> could be the same issue. +>> +>> I connect via RDP to my windows XP VM and after a while it seems to +>> freeze, then, I connect via VNC an without doing anything the +>> communications are restored between the VM and the outside world. So i +>> can connect again with RDP. +>> +>> Even more, if i leave an open connection with VNC (minimized because is +>> more slow than RDP), connecting via RDP has no trouble and no problem of +>> freeze (lost of communications) occurs. +>> +>> f3a97, Could you do this test and tell if you have the same experience +>> than i?, If so, my bug is the same of this. +>> Thanks. +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1180777 +>> +>> Title: +>> Windows 7 VM freeze on Ubuntu 12.04 KVM +>> +>> Status in QEMU: +>> New +>> Status in “qemu-kvm” package in Ubuntu: +>> Confirmed +>> +>> Bug description: +>> Hi, +>> +>> I have recently setup a Windows 7 VM on KVM and started using it +>> through remote desktop. +>> +>> What happens is that, after some hours of usage, the remote desktop +>> connection freezes. I thought it was a remmina bug, as the it was +>> enough to kill and restart it to successfully connect again to the VM. +>> +>> However, today I've switched to a different RDP client (2X Client +>> chromium app) and the freeze just happened again! +>> +>> Some information: +>> - the host and the VM are completely idle when the freeze occurs +>> - I've tried sniffing the network packets toward the RDP port during +>> the freeze and found that the client is sending packets but no packet is +>> sent back +>> +>> Could this be a KVM issue? How can I further debug this one (I expect +>> the freeze to happen again...)? +>> +>> ProblemType: Bug +>> DistroRelease: Ubuntu 12.04 +>> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +>> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +>> Uname: Linux 3.2.0-41-generic x86_64 +>> ApportVersion: 2.0.1-0ubuntu17.2 +>> Architecture: amd64 +>> Date: Thu May 16 14:12:40 2013 +>> MachineType: Hewlett-Packard HP ProBook 4520s +>> MarkForUpload: True +>> ProcEnviron: +>> TERM=xterm +>> PATH=(custom, no user) +>> LANG=en_US.UTF-8 +>> SHELL=/bin/bash +>> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +>> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +>> vt.handoff=7 +>> SourcePackage: qemu-kvm +>> UpgradeStatus: No upgrade log present (probably fresh install) +>> dmi.bios.date: 08/26/2010 +>> dmi.bios.vendor: Hewlett-Packard +>> dmi.bios.version: 68AZZ Ver. F.0A +>> dmi.board.name: 1411 +>> dmi.board.vendor: Hewlett-Packard +>> dmi.board.version: KBC Version 57.30 +>> dmi.chassis.type: 10 +>> dmi.chassis.vendor: Hewlett-Packard +>> dmi.modalias: +>> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +>> dmi.product.name: HP ProBook 4520s +>> dmi.sys.vendor: Hewlett-Packard +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions +>> +> +> + + +I also see these EXACT symptoms, using kvm (VM managed through livirt virsh) on Debian x64 host, guest is Windows 8, RedHat VirtIo network driver. + +rgds + +Hi f3a97, did you tried to connect via VNC when the freeze situation occurs? + +This method works as a a workaround to defreeze my windows VM. + +Since a couple of weeks ago, we started to reboot the VM diary. With this way, the problem occurs very less. We have counted only twice in this period. + +I added a rtl8139c netcard to the VM and connected through it by RDP - no more freezes. + +It looks like kvm does not play well with virtio network cards and RDP. + +Red Hat virtio net windows driver version: 62.65.104.6500, 6/19/2013 + +I left the RH adapter on the VM, I just connect via RDP through the rtl8139c network card. + + + + + +Thanks for the tip Dumitrescu, + +I'll rive it a try AMD report here che result. + +Regards + Il 29/set/2013 14:50 "Vasile Dumitrescu" <email address hidden> ha +scritto: + +> I added a rtl8139c netcard to the VM and connected through it by RDP - +> no more freezes. +> +> It looks like kvm does not play well with virtio network cards and RDP. +> +> Red Hat virtio net windows driver version: 62.65.104.6500, 6/19/2013 +> +> I left the RH adapter on the VM, I just connect via RDP through the +> rtl8139c network card. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> RDP traffic freeze on quiet network +> +> Status in QEMU: +> New +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> Status in Debian GNU/Linux: +> New +> +> Bug description: +> To summarize what I think has been found so far, +> +> 1. The main symptom is that RDP connections hang after some time +> 2. This bug affects qemu 1.0 .. 1.6.5 +> 3. This bug affects at least windows xp and windows 7 guests +> 4. Keeping another network connection open, such as vnc, prevents the +> RDP connection from hanging. +> +> ======================================== +> Hi, +> +> I have recently setup a Windows 7 VM on KVM and started using it +> through remote desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions +> + + +Quoting Vasile Dumitrescu (<email address hidden>): +> I added a rtl8139c netcard to the VM and connected through it by RDP - +> no more freezes. +> +> It looks like kvm does not play well with virtio network cards and RDP. +> +> Red Hat virtio net windows driver version: 62.65.104.6500, 6/19/2013 + +This makes me wonder if the bug may not actually be in the virtio net driver. +The source for that is at +https://github.com/YanVugenfirer/kvm-guest-drivers-windows . +Something like commit 9b1b81a731f722efa8df24429649b527a17bf433 might +be relevant (assuming the git HEAD has this fixed, which I've not +tested). + + +Hi, + +I've double checked my conf, I can confirm I'm not using virtio but +standard Win 7 drivers. (please see my VM conf that I posted some time ago). + +So it's not definitely a virtio-specific issue. + + +On 3 October 2013 16:31, Serge Hallyn <email address hidden> wrote: + +> Quoting Vasile Dumitrescu (<email address hidden>): +> > I added a rtl8139c netcard to the VM and connected through it by RDP - +> > no more freezes. +> > +> > It looks like kvm does not play well with virtio network cards and RDP. +> > +> > Red Hat virtio net windows driver version: 62.65.104.6500, 6/19/2013 +> +> This makes me wonder if the bug may not actually be in the virtio net +> driver. +> The source for that is at +> https://github.com/YanVugenfirer/kvm-guest-drivers-windows . +> Something like commit 9b1b81a731f722efa8df24429649b527a17bf433 might +> be relevant (assuming the git HEAD has this fixed, which I've not +> tested). +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1180777 +> +> Title: +> RDP traffic freeze on quiet network +> +> Status in QEMU: +> New +> Status in “qemu-kvm” package in Ubuntu: +> Confirmed +> Status in Debian GNU/Linux: +> New +> +> Bug description: +> To summarize what I think has been found so far, +> +> 1. The main symptom is that RDP connections hang after some time +> 2. This bug affects qemu 1.0 .. 1.6.5 +> 3. This bug affects at least windows xp and windows 7 guests +> 4. Keeping another network connection open, such as vnc, prevents the +> RDP connection from hanging. +> +> ======================================== +> Hi, +> +> I have recently setup a Windows 7 VM on KVM and started using it +> through remote desktop. +> +> What happens is that, after some hours of usage, the remote desktop +> connection freezes. I thought it was a remmina bug, as the it was +> enough to kill and restart it to successfully connect again to the VM. +> +> However, today I've switched to a different RDP client (2X Client +> chromium app) and the freeze just happened again! +> +> Some information: +> - the host and the VM are completely idle when the freeze occurs +> - I've tried sniffing the network packets toward the RDP port during the +> freeze and found that the client is sending packets but no packet is sent +> back +> +> Could this be a KVM issue? How can I further debug this one (I expect +> the freeze to happen again...)? +> +> ProblemType: Bug +> DistroRelease: Ubuntu 12.04 +> Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 +> ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 +> Uname: Linux 3.2.0-41-generic x86_64 +> ApportVersion: 2.0.1-0ubuntu17.2 +> Architecture: amd64 +> Date: Thu May 16 14:12:40 2013 +> MachineType: Hewlett-Packard HP ProBook 4520s +> MarkForUpload: True +> ProcEnviron: +> TERM=xterm +> PATH=(custom, no user) +> LANG=en_US.UTF-8 +> SHELL=/bin/bash +> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic +> root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash +> vt.handoff=7 +> SourcePackage: qemu-kvm +> UpgradeStatus: No upgrade log present (probably fresh install) +> dmi.bios.date: 08/26/2010 +> dmi.bios.vendor: Hewlett-Packard +> dmi.bios.version: 68AZZ Ver. F.0A +> dmi.board.name: 1411 +> dmi.board.vendor: Hewlett-Packard +> dmi.board.version: KBC Version 57.30 +> dmi.chassis.type: 10 +> dmi.chassis.vendor: Hewlett-Packard +> dmi.modalias: +> dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: +> dmi.product.name: HP ProBook 4520s +> dmi.sys.vendor: Hewlett-Packard +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions +> + + +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.] + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1192780 b/results/classifier/118/permissions/1192780 new file mode 100644 index 00000000..ec420e7b --- /dev/null +++ b/results/classifier/118/permissions/1192780 @@ -0,0 +1,196 @@ +permissions: 0.886 +user-level: 0.882 +register: 0.880 +virtual: 0.868 +debug: 0.861 +socket: 0.832 +semantic: 0.826 +architecture: 0.820 +kernel: 0.818 +network: 0.817 +device: 0.812 +assembly: 0.812 +performance: 0.806 +PID: 0.802 +arm: 0.801 +graphic: 0.793 +mistranslation: 0.791 +KVM: 0.782 +hypervisor: 0.778 +files: 0.777 +peripherals: 0.773 +TCG: 0.761 +vnc: 0.748 +boot: 0.747 +risc-v: 0.742 +ppc: 0.686 +x86: 0.671 +VMM: 0.657 +i386: 0.610 + +qemu-kvm with snapshot option always fails with Permission denied Could not open disk image + +I'm trying to use the option: -snapshot write to temporary files instead of disk image files + +How to reproduce? See following log: +2013-06-20 02:13:18.532+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -S -M pc-1.0 -no-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name instance-0000002b -uuid 2d600758-ae56-48b8-bd4d-999744a038e4 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000002b.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -kernel /opt/stack/data/nova/instances/instance-0000002b/kernel -initrd /opt/stack/data/nova/instances/instance-0000002b/ramdisk -append root=/dev/vda console=ttyS0 -drive file=/opt/stack/data/nova/instances/instance-0000002b/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -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 -netdev tap,fd=19,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=fa:16:3e:03:ab:18,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/instance-0000002b/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:26868 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -snapshot +Domain id=1 is tainted: custom-argv +char device redirected to /dev/pts/18 +qemu-system-x86_64: -drive file=/opt/stack/data/nova/instances/instance-0000002b/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /opt/stack/data/nova/instances/instance-0000002b/disk: Permission denied +2013-06-20 02:13:18.683+0000: shutting down + +Version: QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +Related info: +The disk is a qcow2 image with a backing file. Both the backing file and the disk are cmodded with 777. + +This is a log from dmesg related to apparmor: +[ 236.531287] type=1400 audit(1371694399.156:17): apparmor="STATUS" operation="profile_remove" name="libvirt-2d600758-ae56-48b8-bd4d-999744a038e4" pid=4201 comm="apparmor_parser" + + +libvirt.xml that I'm using: +<domain type="qemu" xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <uuid>2d600758-ae56-48b8-bd4d-999744a038e4</uuid> + <name>instance-0000002b</name> + <memory>524288</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <kernel>/opt/stack/data/nova/instances/instance-0000002b/kernel</kernel> + <initrd>/opt/stack/data/nova/instances/instance-0000002b/ramdisk</initrd> + <cmdline>root=/dev/vda console=ttyS0</cmdline> + </os> + <features> + <acpi/> + <apic/> + </features> + <clock offset="utc"/> + <devices> + <disk type="file" device="disk"> + <driver name="qemu" type="qcow2" cache="none"/> + <source file="/opt/stack/data/nova/instances/instance-0000002b/disk"/> + <target bus="virtio" dev="vda"/> + </disk> + <disk type="block" device="cdrom"> + <driver name="qemu" type="raw"/> + <target tray="open" dev="hdc"/> + <readonly/> + </disk> + <interface type="bridge"> + <mac address="fa:16:3e:03:ab:18"/> + <source bridge="br100"/> + <filterref filter="nova-instance-instance-0000002b-fa163e03ab18"> + <parameter name="IP" value="10.0.0.3"/> + <parameter name="DHCPSERVER" value="10.0.0.1"/> + <parameter name="PROJNET" value="10.0.0.0"/> + <parameter name="PROJMASK" value="255.255.255.0"/> + </filterref> + </interface> + <serial type="file"> + <source path="/opt/stack/data/nova/instances/instance-0000002b/console.log"/> + </serial> + <serial type="pty"/> + <input type="tablet" bus="usb"/> + <graphics type="vnc" autoport="no" port="32768" keymap="en-us" listen="127.0.0.1"/> + </devices> +<qemu:commandline> + <qemu:arg value='-snapshot'/> +</qemu:commandline> +</domain> + +On 06/19/2013 08:42 PM, Sam Stoelinga wrote: +> Public bug reported: +> +> I'm trying to use the option: -snapshot write to temporary files +> instead of disk image files +> + +> +> libvirt.xml that I'm using: +> <domain type="qemu" xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + +> <qemu:commandline> +> <qemu:arg value='-snapshot'/> +> </qemu:commandline> +> </domain> + +This is unsupported usage of libvirt, and not a qemu bug. You'd need to +take this up with the libvirt list to get libvirt to properly support +temporary disk images without needing <qemu:commandline>, and so that +libvirt is properly setting SELinux permissions on the temporary file. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Hi, quick question, + I thought that using the <transient/> xml tag of <disk> element is the right way to do in libvirt ? +Why is <qemu:commandline> method being used ? + +Also with -snapshot, iiuc the temp. file is created by QEMU internally, so which temp. file and its selinux perms is being referenced above ? + + +On 07/25/2013 10:09 AM, Deepak C Shetty wrote: +> Hi, quick question, +> I thought that using the <transient/> xml tag of <disk> element is the right way to do in libvirt ? + +Yes, that is the designed way. Unfortunately, it has not been +implemented yet (no one has been clamoring for the feature enough to +write the patch themselves, or for someone else to take interest and +write a patch on their behalf). + +> Why is <qemu:commandline> method being used ? + +To try and work around the unimplemented nature of the libvirt design. + +> +> Also with -snapshot, iiuc the temp. file is created by QEMU internally, +> so which temp. file and its selinux perms is being referenced above ? +> + +Qemu creating a file itself when libvirt has set SELinux rules on the +qemu instance is very likely to fail, since qemu doesn't know what label +to give the temp file, but the temp file must be labeled to be used. +Hence, this really needs to be implemented properly in libvirt, and is +not a qemu bug. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On 07/25/2013 10:32 AM, Eric Blake wrote: +> On 07/25/2013 10:09 AM, Deepak C Shetty wrote: +>> Hi, quick question, +>> I thought that using the <transient/> xml tag of <disk> element is the right way to do in libvirt ? +> +> Yes, that is the designed way. Unfortunately, it has not been +> implemented yet (no one has been clamoring for the feature enough to +> write the patch themselves, or for someone else to take interest and +> write a patch on their behalf). + +In particular, see this libvirt bug, which is stagnating due to +higher-priority bugs that I am working on first: + +https://bugzilla.redhat.com/show_bug.cgi?id=832194 + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Eric, + Thanks for the quick reply. I saw the <transient/> desc. in formatdomain.html and thought its supported. So does that mean its supported for other hypervisors but not QEMU/KVM ? If not supported at all, why does it show up in the doc... its misleading. + +I had a recent need to start exploiting this feature and landed up here. I am willing to work on supporting <transient/> with your guidance :) since I don't have much knowledge of SELinux. + +thanx, +deepak + +According to Eric's comments, this was a libvirt bug, not a QEMU bug, so closing this ticket now. If you still encounter this problem, please report it to the libvirt project instead. + diff --git a/results/classifier/118/permissions/1216845 b/results/classifier/118/permissions/1216845 new file mode 100644 index 00000000..aad9aa2b --- /dev/null +++ b/results/classifier/118/permissions/1216845 @@ -0,0 +1,120 @@ +permissions: 0.851 +ppc: 0.764 +semantic: 0.753 +graphic: 0.750 +assembly: 0.745 +mistranslation: 0.742 +register: 0.737 +device: 0.736 +performance: 0.734 +architecture: 0.733 +virtual: 0.715 +risc-v: 0.707 +PID: 0.700 +vnc: 0.699 +arm: 0.697 +TCG: 0.695 +hypervisor: 0.689 +debug: 0.682 +peripherals: 0.674 +VMM: 0.659 +KVM: 0.650 +user-level: 0.631 +files: 0.628 +network: 0.627 +socket: 0.622 +kernel: 0.590 +x86: 0.577 +boot: 0.549 +i386: 0.349 + +qemu-system-arm semihosting always calls exit(0) + +In my embedded ARM project I have a bunch of unit tests that I run in a POSIX synthetic environment, and, as usual for POSIX processes, these tests return 0 for success and !=0 for error. + +Now I expanded the testing environment to run some of these tests compiled for ARM, under QEMU, with the tracing messages forwarded via the semihosting API. + +Up to now everything is fine with the emulation. + +However I have a problem with passing the failure code back to the operating system, to drive the continuous integration framework. + +I checked the arm-semi.c code and for SYS_EXIT and I discovered that the parameter passed is ignored and it always calls exit(0): + + case SYS_EXIT: + gdb_exit(env, 0); + exit(0); + +To solve my problem I temporarily made a patch, and for cases that should return non zero codes, I call an unsupported BKPT instruction, which makes QEMU abort, and pass an non zero code (1) back to the operating system. + + qemu: Unsupported SemiHosting SWI 0xf1 + +This kludge is more or less functional, but is quite inconvenient. + +After checking the ARM manuals, I discovered that SYS_EXIT is not standard, and the 0x18 code used for it originally was used for angel_SWIreason_ReportException, which has a slightly different purpose. + +Now the question: + +Would it be possible to no longer ignore the code passed to 0x18, and if it is non zero, to call exit() with a different value? + +The suggested rule would be: + +if (code ==0 || code == 0x20026) + exit(0); +elif (code < 256) + exit(code); +else + exit(1); + +The value 0x20026 means ADP_Stopped_ApplicationExit, and, if I understood it right, it means that the program terminated successfully. If this is not true, it can be removed from the first conditional statement. + +What do you think? Can this be added to arm-semi.c? + + +Regards, + +Liviu + +Had a similar problem with my emulation environment. However, I did some inspection of the assembly code generated by newlib for ARM semi-hosting. While it initially appears that exit() and _exit() discard the status code, upon careful inspection one finds that it is pushed on the stack, with the SP pointing right to it at the point at which the SWI is executed. + +Thus, if the code passed to 0x18 is 0x20026, you can fetch the status code passed to exit() from the stack. + +thank you for your suggestion. + +as semihosting servers I use the j-link gdb server, openocd and qemu. if I got it right, you suggest to modify all these servers to retrieve the exit code from a specific location. as long as this is not documented in the ARM manuals, I cannot recommend such a solution. + +in the GNU ARM Eclipse project templates I fixed the problem by using my own semihosting routines, where exit returns different values for 0 and non zero, so I no longer depend on the newlib support for semihosting. + + + +On 4 February 2015 at 15:56, Karl Zimmerman +<email address hidden> wrote: +> Had a similar problem with my emulation environment. However, I did +> some inspection of the assembly code generated by newlib for ARM semi- +> hosting. While it initially appears that exit() and _exit() discard the +> status code, upon careful inspection one finds that it is pushed on the +> stack, with the SP pointing right to it at the point at which the SWI is +> executed. +> +> Thus, if the code passed to 0x18 is 0x20026, you can fetch the status +> code passed to exit() from the stack. + +Yes, but this is an internal implementation detail of newlib, +not a part of the semihosting ABI. It might well change +in different versions of newlib and we can't rely on it. + +-- PMM + + +With the new 2.0 ARM semihosting ABI, there is an optional extension SYS_EXIT_EXTENDED which can be used to implement returning a non-zero exit code for 32-bit ARM programs: + +https://developer.arm.com/docs/100863/latest/semihosting-operations/sys_exit_extended-0x20#sh-ext-exit-extended + +QEMU should implement this. + + +https://<email address hidden>/ is a patchset which adds semihosting v2 support to QEMU. With those patches and a guest binary which understands semihosting v2 and knows how to probe for the existence of the EXIT_EXTENDED extension, arm guest binaries will be able to pass a non-zero exit status. + + +The semihosting v2 support went into QEMU in the 4.2 release, but I forgot to close this bug... + + diff --git a/results/classifier/118/permissions/12360755 b/results/classifier/118/permissions/12360755 new file mode 100644 index 00000000..012fb153 --- /dev/null +++ b/results/classifier/118/permissions/12360755 @@ -0,0 +1,321 @@ +permissions: 0.930 +debug: 0.922 +user-level: 0.920 +semantic: 0.911 +device: 0.902 +register: 0.901 +graphic: 0.899 +performance: 0.895 +assembly: 0.893 +architecture: 0.885 +PID: 0.876 +arm: 0.875 +virtual: 0.870 +risc-v: 0.868 +peripherals: 0.857 +files: 0.851 +mistranslation: 0.844 +VMM: 0.842 +ppc: 0.840 +kernel: 0.830 +hypervisor: 0.829 +boot: 0.818 +vnc: 0.810 +socket: 0.805 +i386: 0.772 +KVM: 0.770 +network: 0.738 +TCG: 0.735 +x86: 0.656 + +[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/118/permissions/1254940 b/results/classifier/118/permissions/1254940 new file mode 100644 index 00000000..ee8dd371 --- /dev/null +++ b/results/classifier/118/permissions/1254940 @@ -0,0 +1,126 @@ +permissions: 0.963 +graphic: 0.962 +architecture: 0.953 +register: 0.953 +assembly: 0.948 +performance: 0.948 +device: 0.945 +debug: 0.941 +socket: 0.940 +semantic: 0.940 +risc-v: 0.933 +PID: 0.933 +arm: 0.932 +virtual: 0.927 +kernel: 0.926 +boot: 0.918 +files: 0.914 +network: 0.897 +peripherals: 0.846 +user-level: 0.831 +KVM: 0.824 +mistranslation: 0.792 +ppc: 0.790 +hypervisor: 0.785 +vnc: 0.777 +x86: 0.769 +TCG: 0.763 +VMM: 0.720 +i386: 0.716 + +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/118/permissions/1295587 b/results/classifier/118/permissions/1295587 new file mode 100644 index 00000000..ca6fff8c --- /dev/null +++ b/results/classifier/118/permissions/1295587 @@ -0,0 +1,97 @@ +permissions: 0.890 +register: 0.884 +semantic: 0.880 +virtual: 0.862 +mistranslation: 0.857 +vnc: 0.851 +peripherals: 0.842 +debug: 0.840 +network: 0.838 +graphic: 0.838 +performance: 0.836 +architecture: 0.834 +assembly: 0.832 +VMM: 0.830 +user-level: 0.828 +hypervisor: 0.825 +device: 0.822 +socket: 0.816 +PID: 0.801 +ppc: 0.799 +KVM: 0.789 +files: 0.784 +risc-v: 0.779 +arm: 0.778 +boot: 0.777 +kernel: 0.770 +TCG: 0.765 +i386: 0.746 +x86: 0.672 + +Temporal freeze and slowdown while using emulated sb16 + +I have been carrying around this bug since previous versions and on different machines: When I use the -soundhw sb16 option, while playing any sound on the virtual machine it freezes and loops the last bit of such sound effect for 1-2 minutes, then goes back to normal speed. + +Console shows: + + sb16: warning: command 0xf9,1 is not truly understood yet + sb16: warning: command 0xf9,1 is not truly understood yet +(...) +main-loop: WARNING: I/O thread spun for 1000 iterations + +-One of my emulated machines is Windows 3.11: I managed to overrun this bug by switching from the local 1.5 version of the sound blaster driver to the 1.0, although since I updated qemu it freezes that machine, so I can't test if it still works. + +I am using the 1.7.90 version, but I suffered this bug for over one year + +this bug happens anytime I use the -soundhw sb16 switch, but the full command I am using in this specific case is: + + +qemu-system-i386 -localtime -cpu pentium -m 32 -display sdl -vga cirrus -hda c.img -cdrom win95stuff.iso -net nic,model=ne2k_pci -net user -soundhw sb16 + +sb16 isn't actively maintained in qemu these days, so it's unlikely this bug fix will be prioritized. + +that said, if you help narrow down the commit where this regressed, it will increase your chances. + +Finding the last working qemu version is a start. From there, consider trying a git bisect to locate the exact commit that caused failure. + +Wow, I didn't know sb16 is not mantained anymore, in fact I tough it was one of the main "features"! + +I will try to do that when I have time. Maybe with a diff on both source codes will put some light on. Thank you! + +I have this exact same isue. + +Windows 98 I had to switch to ES1370 emulation, but Windows 3.1 I can't find a driver for es1370. Thank-you for the suggestion to use the Microsoft 1.0 driver - that appears to work OK for now. + +With regards to 2.0 freezing a Win3.1 machine - there is a patch, but it isn't implemented yet for some reason... +https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00768.html + +On Windows 98 SE: + + * SB16: System hangs as described in this bug report + * ES1370: Causes system freeze with back screen at boot time + * AC97 (as suggested here: https://smcv.pseudorandom.co.uk/2015/discworldnoir/): BSODs during the installation + * GUS: Device is not even detected + +Conclusion: At the moment, there is no way to get audio output from Windows 98 se VM. + +Addendum: Since this report is from 2014, I should mention that I am currently on 16.04. + +Is there any fix or workaround for this bug? Some old games won't use the AC97 and require SB16. + +After banging my head in a wall for tree or four days, I got the ac97 to work on windows 98se applying something called "Auto-patcher for windows 98se" downloaded from retrosystemsrevival, then using the windows 95 "VXD_A406" driver updated manually by unpacking the executable and picking the .inf file manually. The auto-patcher is mandatory to get everything working. I followed steps from a youtube video for creating a windows 98 VM in Virtualbox, worked on qemu. The installation process was long and boring, but in the end, everything seems to be working without problems (so far). All links can be found in a youtube video by the name "Windows 98 on VirualBox Part 2. AutoPatching, AC97 Sound Drivers, Windows 98 Plus! Gamepad Install." or in the following pastebin: https://pastebin.com/hMvcMzFL + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1310324 b/results/classifier/118/permissions/1310324 new file mode 100644 index 00000000..8850e893 --- /dev/null +++ b/results/classifier/118/permissions/1310324 @@ -0,0 +1,110 @@ +permissions: 0.872 +register: 0.849 +debug: 0.841 +semantic: 0.820 +user-level: 0.816 +boot: 0.816 +virtual: 0.814 +risc-v: 0.800 +PID: 0.785 +device: 0.783 +performance: 0.772 +TCG: 0.745 +socket: 0.745 +arm: 0.744 +network: 0.734 +graphic: 0.726 +ppc: 0.726 +hypervisor: 0.722 +architecture: 0.720 +peripherals: 0.711 +assembly: 0.702 +files: 0.699 +vnc: 0.699 +VMM: 0.687 +i386: 0.682 +mistranslation: 0.673 +KVM: 0.615 +x86: 0.578 +kernel: 0.556 + +Commit 0f842f8a introduces regression when using tcg-interpreter + +Hi. + +Commit 0f842f8a246f2b5b51a11c13f933bf7a90ae8e96 apparently introduces a regression when using --enable-tcg-interpreter. The regression is manifested as follows: + + 1. Checkout any qemu commit later or equal that the one said above. Beside that one, I tested v1.7.1, v2.0.0 and a few other commits suggested to my by git bisect. + 2. Possibly cherry-pick commit a32b12741bf45bf3f46bffe5a79cb2548a060cd8, which fixes a compilation bug with --enable-tcg-interpreter. + 3. Compile with: ./configure --target-list=i386-softmmu --enable-tcg-interpreter && make -j8 + 4. Create an empty virtual disk and try to install Windows XP on it booting from Windows CD-ROM. After the loading program, the installer immediately crashes with blue screen (it should instead show the installation confirmation dialog and then the EULA acceptance dialog, if it worked correctly). + +I'm mentioning Windows XP because it is the problem I found. Probably other operating systems would fail as well. I can test others, if you think it would be helpful. I can also give you access to the very exact CD-ROM image I'm using. + +The exact command line I'm using is: +build_location/i386-softmmu/qemu-system-i386 -m 512 -drive file=winxp_test.img -cdrom wipxp_cdrom.iso + +Attached is the blue screen that I see (unfortunately it is Italian, but that's a standard error message and I hope this is not a problem). + +I'm not able to understand the nature of the commit to identify what could be the problem. My nose tells me that it may be some stupid mistake, for example in some offset constant, that nobody ever saw because tcg-interpreter is not much used. + +Thanks, Giovanni. + + + +I forgot: winxp_test.img is just an empty 15 GB (sparse) file. + +On 04/21/2014 06:14 AM, Stefan Weil wrote: +> That commit changed the use of the GETPC macro. I just tried to debug +> the tci.c code and noticed that cputlb.c no longer works as expected: + +Ouch, yes, I see that. + +> This is not specific for the TCG interpreter, but I don't know how the +> normal TCG is affected. + +I believe that normal TCG is not affected, because the value returned for the +return address is outside the code_buffer, so tb_find_pc returns NULL, so +cpu_restore_state does nothing. Whereas the interpreter continues to produce +the address of the last opcode executed. + +To solve this, I believe you need to clear tci_tb_ptr on all exits from the +interpreter loop. That is, both on normal exit (return from tcg_qemu_tb_exec) +as well as exceptional exit (longjmp landing in cpu_exec; see the Reload env +after longjmp section). + +Only setting tci_tb_ptr at the places it's needed, calls and qemu_ld/st calls, +is a good optimization of memory traffic, but is unrelated to this bug. + +> I also noticed that other code like target-i386/seg_helper.c which +> includes exec/softmmu_template.h also results in undefined usage of the +> GETRA macro. + +Huh? That's the normal backend expansion of its load/store helpers. + + + +r~ + + +I can reproduce a similar problem when running the latest ReactOS live CD from http://downloads.sourceforge.net/reactos/ReactOS-0.3.16-REL-live.zip and see the regression caused by the same commit. + +It can be fixed by a small modification in cputlb.c: replace GETPC by GETRA in these two lines + +cputlb.c:#undef GETPC +cputlb.c:#define GETPC() ((uintptr_t)0) + +Giovanni, could you please try your XP image with this modification, so we can confirm that it fixes the regression? +Richard suggested a modification which would be even more safe, but we did not need it before commit +0f842f8a246f2b5b51a11c13f933bf7a90ae8e96, so for a first fix, replacing GETPC by GETRA might be sufficient. + +Regards +Stefan + + +I can confirm that your change fixes my problem as well. Thank you very much! + +The fix mentioned in comment #4 has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7e4e88656c1e6192e9e47 +==> Setting status to "Fix released". + diff --git a/results/classifier/118/permissions/1314667 b/results/classifier/118/permissions/1314667 new file mode 100644 index 00000000..58357fb4 --- /dev/null +++ b/results/classifier/118/permissions/1314667 @@ -0,0 +1,143 @@ +permissions: 0.889 +architecture: 0.864 +virtual: 0.852 +boot: 0.826 +device: 0.822 +mistranslation: 0.814 +socket: 0.810 +VMM: 0.791 +user-level: 0.784 +risc-v: 0.782 +performance: 0.781 +assembly: 0.773 +files: 0.772 +PID: 0.770 +register: 0.769 +arm: 0.761 +semantic: 0.750 +hypervisor: 0.738 +peripherals: 0.735 +vnc: 0.724 +debug: 0.720 +ppc: 0.686 +graphic: 0.683 +network: 0.675 +x86: 0.675 +KVM: 0.673 +TCG: 0.597 +kernel: 0.553 +i386: 0.309 + +PMPrebUSB - appcrash of qemu in Win-7-64bit + +I am not sure if this issue is a bug of qemu or by Win-7. +I want to test in advance with QEMU the ability if my USB-Rescue-Drive is +booting correctly. I have Win-7-64 and run qemu v.o.15.1.0 out of the installed RMPrepUSB v.2.1.719 +program. The settings for the preparation of my USB drive were FAT32 boot as +HD, bootloader WinPE/Win-7/Vista, set for running iso-files directly in %_ISO +\MAINMENU\Hiren’sBootCD.iso. When I run Qemu I get the messages in the cmd starting window it says: + +Administrator: RMPrepUSB QEMU Launcher +************************************** +EXECUTING "C:\Program Files (x86)\RMPrepUSB\qemu\STARTFROMUSB.cmd" +DRIVE NUMBER=3 +MEMORY SIZE=1000 +HARD DISK IMAGE=harddisk.img +NOWRITE= +Found OS=VISTA_OR_LATER +Sending command Start_VM.exe 3 500 qemu.exe -L . -name "RMPrepUSB Emulation +Session RAM=1000MB VirtualHDD=harddisk.i +lt+LCtrl)" -boot c -m 1000 -drive file=\\. +\PhysicalDrive3,if=ide,index=0,media=disk -hdb harddisk.img to shell... + +Win-7: in the second window appears: +*********************************** +-->qemu funktioniert nicht mehr +Problemsignatur: + Problemereignisname: APPCRASH + Anwendungsname: qemu.exe + Anwendungsversion: 0.15.1.0 + Anwendungszeitstempel: 4f478c16 + Fehlermodulname: qemu.exe + Fehlermodulversion: 0.15.1.0 + Fehlermodulzeitstempel: 4f478c16 + Ausnahmecode: 40000015 + Ausnahmeoffset: 00053b06 + Betriebsystemversion: 6.1.7601.2.1.0.256.48 + Gebietsschema-ID: 1031 + Zusatzinformation 1: bf8d + Zusatzinformation 2: bf8d49108a2e5a0707fc48438e01652a + Zusatzinformation 3: b0f1 + Zusatzinformation 4: b0f155b0f1de9c5eb22bd6d100737cbe + +If somebody can understand that behaviour I appreciate everybodies help. Thank you with regards +H.O. + +The QEMU used in RMPrepUSB is 32-bit only - it won't run 64-bit programs. Normally, Windows will just display an error message saying it needs a 64-bit system. Use Virtual Box for 64-bit OS testing and DavidB's Virtual Machine USB Boot application - see www.rmprepusb.com Tutorial #4 + +Hello, +thank you for answering very fast. But in Google is advertised +/"//RMPrepUSB/ <http://www.rmprepusb.com/> + + + www.rmprepusb.com/Diese Seite übersetzen + <http://translate.google.com/translate?hl=de&sl=en&u=http://www.rmprepusb.com/&prev=/search%3Fq%3DRMPrepUSB%2B64%2Bbit%2Bqemu%26hl%3Dde%26biw%3D905%26bih%3D508> + +Rating for /rmprepusb/.com .... 32-bit and /64/-/bit/ versions are fully +supported. ... 2 /RMPrepUSB/ Help form screenshot (includes F11 = Run +/QEMU/ emulator, and ... +Download <http://www.rmprepusb.com/documents/release-2-0> - Latest +RMPrepUSB versions +<http://www.rmprepusb.com/documents/rmprepusb-beta-versions> +- Easy2Boot +<http://www.rmprepusb.com/tutorials/72---easyboot---a-grubdos-multiboot-drive-that-is-easy-to-maintain/e2bv1> +- 47 - How to install Windows +<http://www.rmprepusb.com/tutorials/win7onusb>" +is that correct and valid or not? Fully supported means to me, that qemu +should work too on Win-7-64bit.. Or why does RMPrepUSB +<http://www.rmprepusb.com/documents/rmprepusb-beta-versions> not change +this at times of XP-64 bit, Vista-64 bit, Win-7 64 bit, Win-8 64bit, +Win-8.1 64bit. Thank you with kind regards +H.Ohlerth + + + + + +Am 30.04.2014 20:55, schrieb Steve Si: +> The QEMU used in RMPrepUSB is 32-bit only - it won't run 64-bit +> programs. Normally, Windows will just display an error message saying it +> needs a 64-bit system. Use Virtual Box for 64-bit OS testing and +> DavidB's Virtual Machine USB Boot application - see www.rmprepusb.com +> Tutorial #4 +> + + + +RMPrepUSB will run ON 32-bit and 64-bit Operating Systems. +That is not the same thing as QEMU will run a 64-bit Operating System. +There is a 64-bit version of QEMU but it is very buggy and won't even boot a 64-bit Vista/7 WinPE, so it is not included. +As I said, normally when booting a 64-bit OS under QEMU, you will see a Windows message saying that the system is not a 64-bit system. For some reason you are not seeing this on your system. + + +Hello Steve, I had a lot of trouble over the weekend building a +sufficiently working bootable "USB-Rescue-Drive". I summed it up in an +attached Word-Dokument and I am sure, you have the knowledge to solve +my problems. For your detailed help I will expect with lots of kind regards + +H.Ohlerth + + +Am 01.05.2014 10:40, schrieb Steve Si: +> RMPrepUSB will run ON 32-bit and 64-bit Operating Systems. +> That is not the same thing as QEMU will run a 64-bit Operating System. +> There is a 64-bit version of QEMU but it is very buggy and won't even boot a 64-bit Vista/7 WinPE, so it is not included. +> As I said, normally when booting a 64-bit OS under QEMU, you will see a Windows message saying that the system is not a 64-bit system. For some reason you are not seeing this on your system. +> + + + +Looking through old bug tickets... can you still reproduce this issue with the latest (64-bit) version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1320360 b/results/classifier/118/permissions/1320360 new file mode 100644 index 00000000..59cfbcd8 --- /dev/null +++ b/results/classifier/118/permissions/1320360 @@ -0,0 +1,525 @@ +permissions: 0.919 +mistranslation: 0.917 +user-level: 0.895 +PID: 0.894 +arm: 0.891 +graphic: 0.890 +assembly: 0.884 +files: 0.883 +register: 0.882 +risc-v: 0.877 +architecture: 0.876 +performance: 0.869 +semantic: 0.868 +peripherals: 0.866 +hypervisor: 0.865 +socket: 0.864 +ppc: 0.856 +device: 0.851 +VMM: 0.840 +boot: 0.836 +network: 0.822 +kernel: 0.812 +KVM: 0.784 +debug: 0.773 +virtual: 0.769 +vnc: 0.762 +TCG: 0.747 +x86: 0.646 +i386: 0.513 + +usb passthrough not working anymore + +Hi, + +I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but starting with qemu 2.0.0 passthrough stop working. I can still add the usb device but when I start the guest following message appears: + +"unable to execute QEMU command 'device_add': 'usb-host' is not a valid device model name" + +Then the guest will not start. + +I try it with different usb devices (iphone, stick, hdd), always the same error. + +Are there any news / hints about this ? + +Regards + +Martin + +Be sure to add the -usb option. What is your command line? + +See also http://git.qemu.org/?p=qemu.git;a=blob;f=docs/usb2.txt;h=c7a445afcd55fe1f12033d529d668a1306d5a9f4;hb=HEAD#l111 + +Hi, + +From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +re-implemented by libusbx. So you should build qemu with --enable-libusb, then +you can use usb pass-through capacity. + +BTW, Gerd, should we enable libusb by default now? Thanks. + + +Best regards, +-Gonglei + +> -----Original Message----- +> From: <email address hidden> +> [mailto:<email address hidden>] On +> Behalf Of Martin R?h +> Sent: Saturday, May 17, 2014 3:35 AM +> To: <email address hidden> +> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +> anymore +> +> Public bug reported: +> +> Hi, +> +> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +> starting with qemu 2.0.0 passthrough stop working. I can still add the +> usb device but when I start the guest following message appears: +> +> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +> device model name" +> +> Then the guest will not start. +> +> I try it with different usb devices (iphone, stick, hdd), always the +> same error. +> +> Are there any news / hints about this ? +> +> Regards +> +> Martin +> +> ** 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/1320360 +> +> Title: +> usb passthrough not working anymore +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +> starting with qemu 2.0.0 passthrough stop working. I can still add the +> usb device but when I start the guest following message appears: +> +> "unable to execute QEMU command 'device_add': 'usb-host' is not a +> valid device model name" +> +> Then the guest will not start. +> +> I try it with different usb devices (iphone, stick, hdd), always the +> same error. +> +> Are there any news / hints about this ? +> +> Regards +> +> Martin +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions + + + +The command line is + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name win8 -S -machine +pc-i440fx-2.0,accel=kvm,usb=off -cpu Nehalem -m 2048 -realtime mlock=off +-smp 2,sockets=2,cores=1,threads=1 -uuid +424ca5ec-2fb4-4d1c-84c4-25b92d468b8e -no-user-config -nodefaults +-chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/win8.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control -rtc +base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard +-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=0x4.0x7 -device +ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 +-device +ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 +-device +ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 +-device ahci,id=ahci0,bus=pci.0,addr=0x7 -drive +file=/opt/emu/win8.raw,if=none,id=drive-virtio-disk0,format=raw -device +virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 +-netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device +virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:d1:dc,bus=pci.0,addr=0x3 +-chardev pty,id=charserial0 -device +isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 +-vnc 127.0.0.1:0 -device VGA,id=video0,bus=pci.0,addr=0x2 -device +intel-hda,id=sound0,bus=pci.0,addr=0x8 -device +hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device +virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 + +Am 17.05.2014 01:15, schrieb Lekensteyn: +> Be sure to add the -usb option. What is your command line? +> +> See also +> http://git.qemu.org/?p=qemu.git;a=blob;f=docs/usb2.txt;h=c7a445afcd55fe1f12033d529d668a1306d5a9f4;hb=HEAD#l111 +> + + + +Hi, + +as far as I can see from the rpm specs of the opensuse rpm package the +--enable-libusb is set . + +Regards + +Martin + +Am 18.05.2014 06:52, schrieb Gonglei (Arei): +> Hi, +> +> From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +> re-implemented by libusbx. So you should build qemu with --enable-libusb, then +> you can use usb pass-through capacity. +> +> BTW, Gerd, should we enable libusb by default now? Thanks. +> +> +> Best regards, +> -Gonglei +> +>> -----Original Message----- +>> From: <email address hidden> +>> [mailto:<email address hidden>] On +>> Behalf Of Martin R?h +>> Sent: Saturday, May 17, 2014 3:35 AM +>> To: <email address hidden> +>> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +>> anymore +>> +>> Public bug reported: +>> +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +>> device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> ** 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/1320360 +>> +>> Title: +>> usb passthrough not working anymore +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a +>> valid device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions +> + + + +Hi, + +if I try to start the vm by virt-manager I get this detailed error log: + +Fehler beim Starten der Domain: internal error: early end of file from +monitor: possible problem: +qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +'usb-host' is not a valid device model name + + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in +cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in +tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1363, in +startup + self._backend.create() + File "/usr/lib64/python2.7/site-packages/libvirt.py", line 917, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: internal error: early end of file from monitor: possible +problem: +qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +'usb-host' is not a valid device model name + +Regards + +Martin + +Am 18.05.2014 06:52, schrieb Gonglei (Arei): +> Hi, +> +> From qemu-1.7 release version, the old usb-host(host-linux.c) had been removed, +> re-implemented by libusbx. So you should build qemu with --enable-libusb, then +> you can use usb pass-through capacity. +> +> BTW, Gerd, should we enable libusb by default now? Thanks. +> +> +> Best regards, +> -Gonglei +> +>> -----Original Message----- +>> From: <email address hidden> +>> [mailto:<email address hidden>] On +>> Behalf Of Martin R?h +>> Sent: Saturday, May 17, 2014 3:35 AM +>> To: <email address hidden> +>> Subject: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +>> anymore +>> +>> Public bug reported: +>> +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a valid +>> device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> ** 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/1320360 +>> +>> Title: +>> usb passthrough not working anymore +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> Hi, +>> +>> I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7 +>> as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but +>> starting with qemu 2.0.0 passthrough stop working. I can still add the +>> usb device but when I start the guest following message appears: +>> +>> "unable to execute QEMU command 'device_add': 'usb-host' is not a +>> valid device model name" +>> +>> Then the guest will not start. +>> +>> I try it with different usb devices (iphone, stick, hdd), always the +>> same error. +>> +>> Are there any news / hints about this ? +>> +>> Regards +>> +>> Martin +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1320360/+subscriptions +> + + + +Hi, + +> -----Original Message----- +> From: Martin Röh [mailto:<email address hidden>] +> Sent: Monday, May 19, 2014 4:40 AM +> To: Gonglei (Arei); Bug 1320360; <email address hidden> +> Cc: Gerd Hoffmann +> Subject: Re: [Qemu-devel] [Bug 1320360] [NEW] usb passthrough not working +> anymore +> +> Hi, +> +> if I try to start the vm by virt-manager I get this detailed error log: +> +> Fehler beim Starten der Domain: internal error: early end of file from +> monitor: possible problem: +> qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +> 'usb-host' is not a valid device model name +> +> +> Traceback (most recent call last): +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in +> cb_wrapper +> callback(asyncjob, *args, **kwargs) +> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in +> tmpcb +> callback(*args, **kwargs) +> File "/usr/share/virt-manager/virtManager/domain.py", line 1363, in +> startup +> self._backend.create() +> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 917, in create +> if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +> libvirtError: internal error: early end of file from monitor: possible +> problem: +> qemu-system-x86_64: -device usb-host,hostbus=1,hostaddr=3,id=hostdev0: +> 'usb-host' is not a valid device model name +> +The above error information shows "usb-host" didn't been built in qemu-system-x86_64 +binary file. You can get the qemu-2.0.0 source files from http://wiki.qemu.org/Download +and rebuild it with '--enable-libusb' during configure. + + +Best regards, +-Gonglei + + +On So, 2014-05-18 at 22:36 +0200, Martin Röh wrote: +> Hi, +> +> as far as I can see from the rpm specs of the opensuse rpm package the +> --enable-libusb is set . + +> > BTW, Gerd, should we enable libusb by default now? Thanks. + +By default libusb will be used when found on the system. +When it isn't there qemu will be built without usb-host support. + +If you explicitly ask for libusb support (via --enable-libusb) and +libusbx isn't found configure should fail. + +cheers, + Gerd + + + + +Martin, + +The OBS Virtualization/qemu project doesn't build QEMU v2.0 with libusb support for openSUSE 13.1, because the version provided in that distro was 1.0.9, and QEMU's configure requires 1.0.13. + +Bruce + +Hi, I've done the following on my OpenSUSE 13.1 install where I'm in sore need of USB passthrough with QEMU 2.0.0 +1) zypper source-install qemu to get the sources +2) update of libusb to 1.0.18 from the hardware:/debug/OpenSUSE_Factory repo - packages are libusb-1_0-0 and libusb-1_0-devel +3) removed the version check for --enable-libusb in qemu.spec to ensure that this flag is set when building +The output of rpmbuild -bb /usr/src/packages/SPECS/qemu.spec is +error: Failed build dependencies: + libusb-devel is needed by qemu-2.0.0-240.5.x86_64 + xen-devel is needed by qemu-2.0.0-240.5.x86_64 +Any input is greatly appreciated. + +xen-devel was not an issue (that package was installed so that dependency was resolved immediately) but libusb-devel is still reported as missing, even though I have a 1.0.18 version of a libusb-1_0-devel installed. I would think it's only the package name that is different. I'm not overly familiar with the build process, therefore I'm not certain if it would be sufficient to modify the qemu.spec build spec with the library name as it is installed on my system. Thanks. + +I went ahead and modified the qemu.spec to require libusb-1_0-devel instead of libusb-devel. That seems to work as according to the build output it includes /usr/include/libusb-1.0. I apologize for needing three comments to get to this point. This is all very much a learning experience for me. + +It looks like something may be broken when building seabios. + +ASL Input: /usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.dsl.i - 475 lines, 19178 bytes, 316 keywords +AML Output: /usr/src/packages/BUILD/qemu-2.0.aml - 4407 bytes, 159 named objects, 157 executable opcodes +Listing File: /usr/src/packages/BUILD/qemu-2.0.lst - 174477 bytes +Hex Dump: /usr/src/packages/BUILD/qemu-2.0.hex - 41680 bytes + +Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 246 Optimizations +Traceback (most recent call last): + File "./scripts/acpi_extract.py", line 237, in <module> + for line in fileinput.input(): + File "/usr/lib64/python2.7/fileinput.py", line 252, in next + line = self.readline() + File "/usr/lib64/python2.7/fileinput.py", line 344, in readline + self._file = open(self._filename, self._mode) +IOError: [Errno 2] No such file or directory: '/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.lst' +make[1]: *** [/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios/builds/seabios-128k/src/fw/acpi-dsdt.hex] Error 1 +make[1]: Leaving directory `/usr/src/packages/BUILD/qemu-2.0.0/roms/seabios' +make: *** [build-seabios-config-seabios-128k] Error 2 +make: Leaving directory `/usr/src/packages/BUILD/qemu-2.0.0/roms' +error: Bad exit status from /var/tmp/rpm-tmp.LbOtWA (%build) + +Now I'm well and truly stuck. Is there a way to leave seabios out of the equation or can this be resolved? + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hi, + +the ticket can be close. All works fine with actual opensuse tumbleweed +and qemu 2.10.0 :-) + +Best regards + +Martin + +Am 03.10.2017 um 12:42 schrieb Thomas Huth: +> Triaging old bug tickets... can you still reproduce this issue with the +> latest version of QEMU? Or could we close this ticket nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + +Thanks for checking again! + diff --git a/results/classifier/118/permissions/1350435 b/results/classifier/118/permissions/1350435 new file mode 100644 index 00000000..1243e805 --- /dev/null +++ b/results/classifier/118/permissions/1350435 @@ -0,0 +1,284 @@ +permissions: 0.839 +TCG: 0.819 +vnc: 0.763 +hypervisor: 0.744 +files: 0.727 +debug: 0.722 +ppc: 0.713 +arm: 0.709 +graphic: 0.702 +PID: 0.702 +virtual: 0.700 +assembly: 0.693 +socket: 0.688 +peripherals: 0.682 +performance: 0.678 +semantic: 0.676 +KVM: 0.671 +device: 0.670 +architecture: 0.665 +register: 0.659 +VMM: 0.648 +user-level: 0.646 +mistranslation: 0.613 +boot: 0.606 +x86: 0.604 +risc-v: 0.602 +network: 0.590 +kernel: 0.578 +i386: 0.463 + +tcg.c:1693: tcg fatal error + +this started happening after the launchpad buildd trusty deploy +https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6224439 + + +debconf-updatepo +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +/build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error +/build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error + +this seems to be the patch needed +https://patches.linaro.org/32473/ + +Hi, + +have already tested with that patch to verify that it fixes the +issue? If I put qemu + that patch into a ppa, will your infrastructure +allow you to test that way? + +I'm a bit concerned about this patch, as it appears to be one which has +been in the Suse tree for quite some time, begging the question why it is +not upstream. It would be nice to hear from agraf or pmaydell whether +this patch is safe. + + +That patch is not in mainline because it's an appalling hack. If we care about multi-threaded guests we need to fix them properly, not paper over the issues by constraining multiple threads to one CPU in the hopes the race conditions don't bite us so often. + + +No, I did not test the patch, I don't think that I can push that patch in lp infrastructure, and I don't have my own one. + +Anyway Peter is right, we don't need to hide bugs, but to fix them ;) + +Peter: While this is true, is it actually likely to happen? I thought in our conversations in the past (when I previously attempted to escalate this class of problems via Linaro) it had been fairly clear that this was a very difficult task that isn't likely to be scheduled for the foreseeable future. + +I think it's likely to happen eventually; it depends rather on the balance between this and other work priorities (at least if it's going to be Linaro doing the work). Regardless, I'm not taking hacky workarounds like this into mainline (hacks are hard to get out once you let them in, and they remove any motivation anybody might have had for fixing things properly). + + +Right, I can absolutely understand that. The question would I suppose be whether you think this is a completely unreasonable thing to put in a distro patch; I think SUSE are doing so for basically the same reason we would be, that is, a setup such as PPAs where virtualisation isn't available directly on the architecture in question but we can use qemu-user to run foreign-arch binaries reasonably transparently. My understanding is that this patch would make a pretty huge dent in our failure rate for that setup. + +Well, it won't make anything any worse, so it's your call based on how much it actually improves your failure rate I guess. + + +https://launchpad.net/~serge-hallyn/+archive/ubuntu/qemu-user-thread contains a package with this patch applied (built for trusty). Please let us know how much it helps. + +I got this morning a new FTBFS in a package that have been always built successfully in the past, just FYI +https://launchpadlibrarian.net/181879742/buildlog_ubuntu-trusty-armhf.boinc_7.4.0~nightly1~~git20140809%2Br21874~r184~ubuntu14.04.1_FAILEDTOBUILD.txt.gz + +Interesting enough the utopic build was successful! + +And when I retried the failed build it succeeded but a segmentation fault (core dumped) is in the logs +https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6254532 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +Segmentation fault (core dumped) + +Are these new failures using the qem upackage in ppa:serge-hallyn/qemu-user-thread, or using the stock trusty qemu package? + +How can I use your one? I have no possibility to tweak the host system, I'm not an lp admin, do you think I can try to add your ppa as dependency and it will work? + +No, that won't work as it's the emulator in which the build is running. + +You should however be able to install the ppa's qemu on a local host, +install a standard ubuntu server vm, apt-get install ubuntu-dev-tools, +copy the package sources over to the vm, and build the packages inside +the vm. + + +Hi Serge, sorry for the delay, +the problem is that if I run pbuilder-dist utopic armhf create +pbuilder-dist utopic armhf build boinc_whatever.dsc the build never fails also with the trusty qemu, so I cannot test your package with the patch. +(I'm already on trusty, should I really install a server machine?) + +Perhaps i don't understand what you are doing. + +My understanding was that a package is being built (in the buildds) under qemu. Qemu is failing due to tcg failure. We want to tes twhether a qemu patch fixes it. + +That's why I suggest installing the new qemu package on your host, using it to run a new server VM, and building the problematic package inside that VM. That way we can see whether the proposed qemu package fixes the build error. + +I didn't install a VM because: +-I'm on ubuntu 14.04 on my laptop +-I use pbuilder-dist (from ubuntu-dev-tools) armhf that uses qemu as underlying virtualization system. + +the fact is: +why on my machine it doesn't show this error? + +possible solution: +-because qemu+pbuilder-dist is not multithreaded? + +This patch is still not applied upstream. + +As there has been no discussion in over a year, I assume it is no longer a problem and I'm going to mark it invalid. Please rep;ly if that is not the case. + +If it *is* still a problem, then we should go discuss on oftc#qemu. + +Well. This is definitely wrong. It is a valid bug, but it needs quite serious work to fix, which requires major refactoring of the tcg code. Upstream is working on it, see http://wiki.qemu.org/Features/tcg-multithread + +Ah, thanks for setting me straight. + + +We're now building armhf/arm64 packages on real arm64 hardware in Launchpad, so, while this problem may well still exist in qemu, it no longer applies to Launchpad builds. + +We think we've fixed our linux-user threading issues, so if there are still problems as of qemu-2.11 or later, please raise a fresh bug report with repro instructions. + + +per former comments, in context qemu 2.11 is in proposed + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu1 + +--------------- +qemu (1:2.11+dfsg-1ubuntu1) bionic; urgency=medium + + * Merge with Debian testing, among other fixes this includes + - fix fatal error on negative maxcpus (LP: #1722495) + - fix segfault on dump-guest-memory on guests without memory (LP: #1723381) + - linux user threading issues (LP: #1350435) + - TOD-Clock Epoch Extension Support on s390x (LP: #1732691) + Remaining changes: + - qemu-kvm to systemd unit + - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm, + hugepages and architecture specifics + - d/qemu-kvm.service: systemd unit to call qemu-kvm-init + - d/qemu-system-common.install: install systemd unit and helper script + - d/qemu-system-common.maintscript: clean old sysv and upstart scripts + - d/qemu-system-common.qemu-kvm.default: defaults for + /etc/default/qemu-kvm + - d/rules: install /etc/default/qemu-kvm + - Enable nesting by default + - set nested=1 module option on intel. (is default on amd) + - re-load kvm_intel.ko if it was loaded without nested=1 + - d/p/ubuntu/expose-vmx_qemu64cpu.patch: expose nested kvm by default + in qemu64 cpu type. + - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default + in qemu64 on amd + - libvirt/qemu user/group support + - qemu-system-common.postinst: remove acl placed by udev, and add udevadm + trigger. + - qemu-system-common.preinst: add kvm group if needed + - Distribution specific machine type + - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine + types to ease future live vm migration. + - d/qemu-system-x86.NEWS Info on fixed machine type defintions + - improved dependencies + - Make qemu-system-common depend on qemu-block-extra + - Make qemu-utils depend on qemu-block-extra + - let qemu-utils recommend sharutils + - s390x support + - Create qemu-system-s390x package + - Include s390-ccw.img firmware + - Enable numa support for s390x + - ppc64[le] support + - d/qemu-system-ppc.links provide usr/bin/qemu-system-ppc64le symlink + - arch aware kvm wrappers + * Added Changes + - update VCS-git to match the bionic branch + - sdl2 is yet too unstable for the LTS Ubuntu release given the reports + we still see upstream and in Debian - furthermore sdl2 isn't in main yet, + so we revert related changes to stick with the proven for now: + - 0fd25810 - do not build-depend on libx11-dev (libsdl2-dev already + depends on it) + - 9594f820 - switch from sdl1.2 to sdl2 (#870025) + - d/qemu-system-x86.README.Debian: document intention of nested being + default is comfort, not full support + - update Ubuntu machine types for qemu 2.11 + - qemu-guest-agent: freeze-hook fixes (LP: #1484990) + - d/p/guest-agent-freeze-hook-skip-dpkg-artifacts.patch + - d/qemu-guest-agent.install: provide /etc/qemu/fsfreeze-hook + - d/qemu-guest-agent.dirs: provide /etc/qemu/fsfreeze-hook.d + - Create and install pxe netboot images for KVM s390x (LP: #1732094) + - d/rules enable install s390x-netboot.img + - debian/patches/ubuntu/partial-SLOF-for-s390x-netboot-compilation.patch + - d/control-in: enable RDMA support in qemu (LP: #1692476) + - on s390x provide facility bits 81 (ppa15) and 82 (bpb) (LP: #1743560) + - d/p/ubuntu/linux-headers-update-to-4.15-rc1.patch + - d/p/ubuntu/linux-headers-update-4.15-rc9.patch + - d/p/ubuntu/lp1743560-s390x-kvm-Handle-bpb-feature.patch + - d/p/ubuntu/lp1743560-s390x-kvm-provide-stfle.81.patch + - tolerate ipxe size change on migrations to >=18.04 (LP: #1713490) + - d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types + reference 256k path + - d/control: depend on ipxe-qemu-256k-compat-efi-roms to be able to + handle incoming migrations from former releases. + - d/control-in: enable seccomp on s390x + * Dropped changes (no more needed): + - Dropped VHOST_NET_ENABLED and KVM_HUGEPAGES from /etc/default/qemu-kvm + The functionality is retained for upgraders, but is deprecated. + Post 18.04 the implementation for these configurations will be removed. + * Dropped changes (in Debian now): + - ppc64[le] support + - Enable seccomp for ppc64el + - bump libseccomp-dev dependency, 2.3 is the minimum for ppc64 + - disable missing x32 architecture + - d/rules: or32 is now named or1k (since 4a09d0bb) + - d/qemu-system-common.docs: new paths since (ac06724a) + - d/qemu-system-common.install: qmp-commands.txt removed, but replaced + by qapi-schema.json which is already packaged (since 4d8bb958) + - d/p/02_kfreebsd.patch: utimensat is no more optional upstream (Update + to Debian patch to match qemu 2.10) + - d/qemu-system-common.docs: adapt new path of live-block-operations.rst + since 8508eee7 + - d/qemu-system-common.docs: adapt q35 config paths since 9ca019c1 + - make nios2/hppa not installed explicitly until further stablized + - d/qemu-guest-agent.install: add the new guest agent reference man page + qemu-ga-ref + - d/qemu-system-common.install: add the now generated qapi/qmp reference + along the qapi intro + - d/not-installed: ignore further generated (since 56e8bdd4) files in + dh_missing that are already provided in other formats qemu-doc, + qemu-qmp-ref,qemu-ga-ref + * Dropped changes (integrated upstream): + - d/p/detect-ITS-and-skip-usage-on-older-kernel.patch to avoid crashes + on arm64 when doing suspend/resume and reboots due to older kernels not + supporting ITS (LP 1731051). + - Apply linux-user-return-EINVAL-from-prctl-PR_-_SECCOMP.patch from + James Cowgill to prevent qemu-user from forwarding prctl seccomp + calls (LP 1726394) + - update to upstream 2.10.1 point release (LP 1722808) + + -- Christian Ehrhardt <email address hidden> Mon, 22 Jan 2018 14:35:18 +0100 + +Hello, this seems to be still an issue +W: Failure while unpacking required packages. This will be attempted up to five times. +W: See //debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/bash_4.4.18-1ubuntu1_arm64.deb is at fault) + + +dpkg -l |grep qemu +ii ipxe-qemu 1.0.0+git-20161027.b991c67+really20150424.a25a16d-1ubuntu2 all PXE boot firmware - ROM images for qemu +ii ipxe-qemu-256k-compat-efi-roms 1.0.0+git-20150424.a25a16d-0ubuntu2 all PXE boot firmware - Compat EFI ROM images for qemu +ii qemu 1:2.11+dfsg-1ubuntu1 amd64 fast processor emulator +ii qemu-block-extra:amd64 1:2.11+dfsg-1ubuntu1 amd64 extra block backend modules for qemu-system and qemu-utils +rc qemu-kvm 1:2.11+dfsg-1ubuntu1 amd64 QEMU Full virtualization on x86 hardware +ii qemu-slof 20170724+dfsg-1ubuntu0.1 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries +ii qemu-system-arm 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-mips 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (miscellaneous) +ii qemu-system-ppc 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (ppc) +ii qemu-system-s390x 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (s390x) +ii qemu-system-sparc 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1:2.11+dfsg-1ubuntu1 amd64 QEMU full system emulation binaries (x86) +ii qemu-user 1:2.11+dfsg-1ubuntu1 amd64 QEMU user mode emulation binaries +ii qemu-user-static 1:2.11+dfsg-1ubuntu1 amd64 QEMU user mode emulation binaries (static version) +ii qemu-utils 1:2.11+dfsg-1ubuntu1 amd64 QEMU utilities + + + +to reproduce: pbuilder-dist bionic arm64 create + +(wrong bug, sorry!) + diff --git a/results/classifier/118/permissions/1353947 b/results/classifier/118/permissions/1353947 new file mode 100644 index 00000000..098adca4 --- /dev/null +++ b/results/classifier/118/permissions/1353947 @@ -0,0 +1,118 @@ +permissions: 0.933 +register: 0.917 +mistranslation: 0.901 +peripherals: 0.900 +network: 0.897 +debug: 0.889 +hypervisor: 0.885 +virtual: 0.884 +semantic: 0.872 +boot: 0.866 +user-level: 0.860 +architecture: 0.857 +assembly: 0.856 +risc-v: 0.854 +KVM: 0.854 +kernel: 0.853 +device: 0.851 +files: 0.849 +PID: 0.847 +ppc: 0.833 +arm: 0.833 +vnc: 0.831 +graphic: 0.823 +VMM: 0.813 +TCG: 0.812 +performance: 0.803 +socket: 0.777 +x86: 0.776 +i386: 0.616 + +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/118/permissions/1359383 b/results/classifier/118/permissions/1359383 new file mode 100644 index 00000000..1848f02e --- /dev/null +++ b/results/classifier/118/permissions/1359383 @@ -0,0 +1,247 @@ +permissions: 0.930 +hypervisor: 0.910 +graphic: 0.897 +register: 0.880 +user-level: 0.876 +virtual: 0.874 +debug: 0.863 +boot: 0.858 +risc-v: 0.858 +network: 0.853 +assembly: 0.837 +mistranslation: 0.833 +kernel: 0.831 +architecture: 0.827 +device: 0.825 +KVM: 0.816 +peripherals: 0.806 +vnc: 0.801 +semantic: 0.782 +files: 0.780 +PID: 0.761 +arm: 0.761 +performance: 0.758 +TCG: 0.736 +x86: 0.727 +ppc: 0.719 +socket: 0.719 +VMM: 0.649 +i386: 0.573 + +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/118/permissions/1364 b/results/classifier/118/permissions/1364 new file mode 100644 index 00000000..dd4824da --- /dev/null +++ b/results/classifier/118/permissions/1364 @@ -0,0 +1,45 @@ +permissions: 0.983 +network: 0.981 +user-level: 0.943 +device: 0.939 +graphic: 0.935 +architecture: 0.930 +ppc: 0.783 +vnc: 0.763 +mistranslation: 0.739 +VMM: 0.736 +performance: 0.726 +semantic: 0.694 +kernel: 0.660 +PID: 0.639 +peripherals: 0.576 +virtual: 0.545 +register: 0.497 +debug: 0.478 +i386: 0.462 +x86: 0.426 +boot: 0.401 +arm: 0.385 +socket: 0.382 +TCG: 0.336 +KVM: 0.331 +risc-v: 0.319 +assembly: 0.292 +hypervisor: 0.286 +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/118/permissions/1373362 b/results/classifier/118/permissions/1373362 new file mode 100644 index 00000000..495e5ffc --- /dev/null +++ b/results/classifier/118/permissions/1373362 @@ -0,0 +1,179 @@ +permissions: 0.878 +peripherals: 0.866 +risc-v: 0.837 +user-level: 0.834 +semantic: 0.817 +graphic: 0.808 +debug: 0.806 +virtual: 0.803 +hypervisor: 0.803 +ppc: 0.801 +assembly: 0.799 +arm: 0.791 +mistranslation: 0.782 +x86: 0.781 +architecture: 0.778 +device: 0.764 +register: 0.763 +VMM: 0.755 +files: 0.752 +i386: 0.745 +PID: 0.744 +vnc: 0.739 +socket: 0.734 +performance: 0.734 +KVM: 0.724 +network: 0.711 +kernel: 0.701 +boot: 0.690 +TCG: 0.678 + +qemu-2.1.1 i386-softmmu compile error: q35_dsdt_applesmc_sta undeclared + +I try to compile qemu-2.1.1 (Gentoo/x86), but the i386-softmmu fails to compile: + + CPP i386-softmmu/q35-acpi-dsdt.dsl.i.orig + ACPI_PREPROCESS i386-softmmu/q35-acpi-dsdt.dsl.i + IASL i386-softmmu/q35-acpi-dsdt.dsl.i + ACPI_EXTRACT i386-softmmu/q35-acpi-dsdt.off + CAT i386-softmmu/hw/i386/q35-acpi-dsdt.hex + CC i386-softmmu/hw/i386/acpi-build.o +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c: In function 'acpi_get_dsdt': +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c:119:24: error: 'q35_dsdt_applesmc_sta' undeclared (first use in this function) + applesmc_sta = q35_dsdt_applesmc_sta; + ^ +/tmp/portage/app-emulation/qemu-2.1.1/work/qemu-2.1.1/hw/i386/acpi-build.c:119:24: note: each undeclared identifier is reported only once for each function it appears in +make[1]: *** [hw/i386/acpi-build.o] Error 1 +make: *** [subdir-i386-softmmu] Error 2 + +Something seems to go wrong when generating the file i386-softmmu/hw/i386/q35-acpi-dsdt.hex: + +# grep -r q35_dsdt_applesmc_sta ../ +../softmmu-build/x86_64-softmmu/q35-acpi-dsdt.dsl.i:/* ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta */ +../softmmu-build/x86_64-softmmu/q35-acpi-dsdt.dsl.i.orig: ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta +../softmmu-build/i386-softmmu/q35-acpi-dsdt.dsl.i:/* ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta */ +../softmmu-build/i386-softmmu/q35-acpi-dsdt.dsl.i.orig: ACPI_EXTRACT_NAME_BYTE_CONST q35_dsdt_applesmc_sta +../hw/i386/acpi-build.c: applesmc_sta = q35_dsdt_applesmc_sta; +../hw/i386/q35-acpi-dsdt.dsl:#define DSDT_APPLESMC_STA q35_dsdt_applesmc_sta + +The .orig file in there makes me think that Gentoo is applying some patches before building. + +You should open a bug with them and they can open a bug if there really is a problem upstream (which I believe is general practice with Gentoo anyways). + +sorry, but this has nothing to do with gentoo patches. +Just to prove it, I did the following: + +cd /var/tmp +git clone git://git.qemu.org/qemu.git +mkdir qemu-build +cd qemu-build +../qemu/configure --target-list=i386-softmmu +make 2>&1 | tee ../qemu-build.log +xz ../qemu-build.log + +rm -Rf * +../qemu/configure --target-list=i386-softmmu +make -d 2>&1 | tee ../qemu-build-debug.log +xz ../qemu-build-debug.log + + + + + +Works fine here. Even made sure the resulting binary runs okay (which it does). Maybe try in a clean chroot or something? + +I retried it on another machine, running Kubuntu 14.10 (x86_64) -> fails at exactly the same point ! + +update: I found out that the latest version on the stable-1.7 branch builds fine, but all stable-2.0 and later fail. +I did some binary search on all versions on the stable-2.0 branch and found out that the problem occurs after this commit: + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=15bce1b7c55c69f47e13c9eb2a4b80f41da26581 + +Unfortunately this is not so much surprising, as this is the first commit that introduced a reference to that symbol. So the question is: where is that symbol defined in *your* version? + +Just to track this down: could you please do a "grep" in your source to see where it is defined on your side? +(grep -r q35_dsdt_applesmc_sta ../) +I expect there is some slight difference to the hits that I get here (see my initial post) + +My guess is that it is defined in some "generated" file and that there is a problem with the generator/converter that produces it. + +On 27 September 2014 10:28, Thomas Eschenbacher +<email address hidden> wrote: +> update: I found out that the latest version on the stable-1.7 branch builds fine, but all stable-2.0 and later fail. +> I did some binary search on all versions on the stable-2.0 branch and found out that the problem occurs after this commit: +> +> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=15bce1b7c55c69f47e13c9eb2a4b80f41da26581 + +Do you also see this compile failure on git master, or is +it only a problem on the stable branch? + +> Unfortunately this is not so much surprising, as this is the first +> commit that introduced a reference to that symbol. So the question is: +> where is that symbol defined in *your* version? +> +> Just to track this down: could you please do a "grep" in your source to see where it is defined on your side? +> (grep -r q35_dsdt_applesmc_sta ../) +> I expect there is some slight difference to the hits that I get here (see my initial post) +> +> My guess is that it is defined in some "generated" file and that there +> is a problem with the generator/converter that produces it. + +Note that there are two different possible paths here: + * if configure finds you have iasl it will build the + q35-acpi-dsdt.hex files from the dsl source files + * otherwise, we just copy hw/i386/q35-acpi-dsdt.hex.generated + into the build tree as the .hex file +(at least, this is how master is doing it.) + +Some things that might be useful for debugging: + * if you add "V=1" to your make command line it will print the + full commands being run rather than the pretty "IASL/CPP/CC" + short progress info + * you could look at whether the .hex file you've generated + matches the .hex.generated file we ship at all + +My guess is that your system has a busted iasl of some kind, +in which case you can work around this by passing '--iasl=none' +to configure, but it would be good to identify what's actually +going wrong here. + +thanks +-- PMM + + +Hi Peter, + +thanks for the hints! Indeed there was an outdated version of iasl on my system, which I have manually installed in /usr/local/bin many years ago... (on both machines, on the gentoo as well as the kubuntu box) - sorry for that!!! + +That produced an error message during build (see below), but for some reason the make system did not recognize that and continued with broken files (not only here, all other files were affected too). + +------------------------------------------------------------------------------------ +iasl -vs -l -tc -p q35-acpi-dsdt q35-acpi-dsdt.dsl.i 2>&1 +q35-acpi-dsdt.dsl.i 48: If (LEqual(Arg0, ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) { +Error 1037 - ^ syntax error, unexpected PARSEOP_NAMESEG, expecting ')' + +q35-acpi-dsdt.dsl.i 61: } Else { +Error 1037 - ^ syntax error, unexpected PARSEOP_ELSE + +ASL Input: q35-acpi-dsdt.dsl.i - 308 lines, 22112 bytes, 47 keywords +Compilation complete. 2 Errors, 0 Warnings, 0 Remarks, 5 Optimizations +------------------------------------------------------------------------------------ + +The bad old version of iasl that produced the trouble was: +------------------------------------------------------------------- +Intel ACPI Component Architecture +ASL Optimizing Compiler / AML Disassembler version 20040715 [Oct 11 2004] +Copyright (C) 2000 - 2004 Intel Corporation +Supports ACPI Specification Revision 2.0c +------------------------------------------------------------------- + +Now I checked with iasl-20130117-32 (Gentoo) and iasl-20140214-64 (Kubuntu), both worked fine and both understand the command line parameter "-v" to get their version (which is not the case for the old one). Maybe it is worth writing some version check in the configure script ? + +IMO we can close this bug. + +thanks a lot for your help, + Thomas + + +Closing according to the last comment. + diff --git a/results/classifier/118/permissions/1382 b/results/classifier/118/permissions/1382 new file mode 100644 index 00000000..bf6757ef --- /dev/null +++ b/results/classifier/118/permissions/1382 @@ -0,0 +1,70 @@ +permissions: 0.855 +debug: 0.771 +architecture: 0.718 +register: 0.708 +user-level: 0.672 +semantic: 0.668 +PID: 0.656 +graphic: 0.654 +arm: 0.652 +device: 0.649 +assembly: 0.648 +performance: 0.645 +x86: 0.642 +ppc: 0.633 +boot: 0.628 +virtual: 0.609 +risc-v: 0.591 +peripherals: 0.588 +i386: 0.579 +hypervisor: 0.555 +files: 0.553 +kernel: 0.553 +vnc: 0.548 +socket: 0.541 +VMM: 0.521 +TCG: 0.520 +mistranslation: 0.473 +KVM: 0.449 +network: 0.438 + +x86-64 In long mode the Selector Error Code has an improperly encoded Selector Index when dealing with IDT descriptor indexes +Description of problem: +When in long mode an IDT descriptor is 16 bytes in size. When an exception is raised where an index to an IDT descriptor entry needs to be encoded in an error code's selector index field it appears that QEMU's software emulation improperly encodes the IDT descriptor index as if each entry is 8 bytes rather than 16. The effect is that the descriptor index is encoded with a value that is double what it should be. + +As an example if I have a *Segment Not Present* (#NP) exception handler (which has a selector error code pushed on the stack) that is raised when I try to generate a software interrupt 0x97 that is marked not present in its IDT descriptor entry - I expect that QEMU would properly encode the value 0x97 in the Selector Index of the Selector Error Code pushed on the stack. Instead, the value stored is actually 0x12E. 0x12E is double the expected value 0x97. + +You can observe this errant value in the output of QEMU when using the `-d int` option. I have cut out the unnecessary state information as I'm focussed on the `v=` and `e=`. + + 0: v=97 e=0000 i=1 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00 + 1: v=0b e=0972 i=0 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00 + +When I used `int 0x97` to generate the software interrupt it properly shows that `v=97` had occurred in the output above. Because 0x97 was marked not present exception 0x0b (Not Present) was raised as you can see in the second line. The problem is that `e=0972` is a Selector Error Code where *Bits 3..16* contain the value 0x12E instead of 0x97. **It isn't just the display value in QEMU's debug output that is wrong**, as the **Selector Error Code pushed on the interrupt stack is the same erroneous value**. + +This issue doesn't occur if you run QEMU with the `-enable-kvm` option; in BOCHS; or on real hardware. The value in those environments contains a Selector Error Code of 0x4ba. *Bits 3..16* of 0x4ba contains the descriptor index 0x97 as expected. See additional information for more details. +Steps to reproduce: +1. Put processor in long mode. 64-bit mode will suffice. +2. Load an IDT with: + - A valid Segment Not Present (#NP) 0x0B Exception Handler. Handler doesn't really need to do anything. + - At least one interrupt handler marked *Not Present* higher than 0x00. Interrupt 0x97 as an example. +3. Raise the interrupt with something like `int 0x097` for this example. +Additional information: +In order to test this problem out in other environments like real hardware and virtual machines I wrote a test program on a floppy disk image that can be run on machines and virtual machines that support legacy boot from floppy media (or emulated floppy media). The test program code can be found [in my Github repository](https://github.com/mpetch/SelectorErrorCodeTest). A pre-built [disk image](https://github.com/mpetch/SelectorErrorCodeTest/blob/main/disk.img) is also available. + +When the disk image is executed with QEMU using `qemu-system-x86_64 -fda disk.img` the result (with incorrect encoding) can be seen here: + + + +When QEMU is run with `qemu-system-x86_64 -fda disk.img -enable-kvm` the result (with correct encoding) can be seen here: + + + +Correct results are also obtained in BOCHS and real hardware. + +--- +The [Intel Software Development Manual Volume 3A](https://www.intel.ca/content/www/ca/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html) documents the error code as: + + + +--- +# diff --git a/results/classifier/118/permissions/1386 b/results/classifier/118/permissions/1386 new file mode 100644 index 00000000..25d64d0c --- /dev/null +++ b/results/classifier/118/permissions/1386 @@ -0,0 +1,658 @@ +permissions: 0.932 +graphic: 0.920 +user-level: 0.903 +performance: 0.891 +register: 0.885 +peripherals: 0.883 +assembly: 0.867 +architecture: 0.863 +arm: 0.855 +files: 0.853 +device: 0.852 +semantic: 0.843 +hypervisor: 0.836 +virtual: 0.834 +socket: 0.827 +TCG: 0.821 +KVM: 0.821 +PID: 0.817 +risc-v: 0.816 +vnc: 0.813 +debug: 0.802 +mistranslation: 0.798 +network: 0.793 +ppc: 0.787 +VMM: 0.770 +kernel: 0.755 +boot: 0.755 +x86: 0.737 +i386: 0.710 + +Qemu 7.2.0 - Failed compilation under Windows with MSYS (MINGW64) +Description of problem: +I follow the faq here + +https://wiki.qemu.org/Hosts/W32#Debian_based_cross_builds + +to compile qemu source under Windows with MSYS2 (MINGW64). +Steps to reproduce: +Follow the FAQ guide and I get + +``` +xxxx@DESKTOP-NBACH6G MINGW64 ~/qemu +$ ./configure --enable-sdl --enable-gtk +Using './build' as the directory for build output +ln: failed to create symbolic link 'aarch64-softmmu/qemu-system-aarch64.exe': No such file or directory +ln: failed to create symbolic link 'alpha-softmmu/qemu-system-alpha.exe': No such file or directory +ln: failed to create symbolic link 'arm-softmmu/qemu-system-arm.exe': No such file or directory +ln: failed to create symbolic link 'avr-softmmu/qemu-system-avr.exe': No such file or directory +ln: failed to create symbolic link 'cris-softmmu/qemu-system-cris.exe': No such file or directory +ln: failed to create symbolic link 'hppa-softmmu/qemu-system-hppa.exe': No such file or directory +ln: failed to create symbolic link 'i386-softmmu/qemu-system-i386.exe': No such file or directory +ln: failed to create symbolic link 'loongarch64-softmmu/qemu-system-loongarch64.exe': No such file or directory +ln: failed to create symbolic link 'm68k-softmmu/qemu-system-m68k.exe': No such file or directory +ln: failed to create symbolic link 'microblaze-softmmu/qemu-system-microblaze.exe': No such file or directory +ln: failed to create symbolic link 'microblazeel-softmmu/qemu-system-microblazeel.exe': No such file or directory +ln: failed to create symbolic link 'mips-softmmu/qemu-system-mips.exe': No such file or directory +ln: failed to create symbolic link 'mips64-softmmu/qemu-system-mips64.exe': No such file or directory +ln: failed to create symbolic link 'mips64el-softmmu/qemu-system-mips64el.exe': No such file or directory +ln: failed to create symbolic link 'mipsel-softmmu/qemu-system-mipsel.exe': No such file or directory +ln: failed to create symbolic link 'nios2-softmmu/qemu-system-nios2.exe': No such file or directory +ln: failed to create symbolic link 'or1k-softmmu/qemu-system-or1k.exe': No such file or directory +ln: failed to create symbolic link 'ppc-softmmu/qemu-system-ppc.exe': No such file or directory +ln: failed to create symbolic link 'ppc64-softmmu/qemu-system-ppc64.exe': No such file or directory +ln: failed to create symbolic link 'riscv32-softmmu/qemu-system-riscv32.exe': No such file or directory +ln: failed to create symbolic link 'riscv64-softmmu/qemu-system-riscv64.exe': No such file or directory +ln: failed to create symbolic link 'rx-softmmu/qemu-system-rx.exe': No such file or directory +ln: failed to create symbolic link 's390x-softmmu/qemu-system-s390x.exe': No such file or directory +ln: failed to create symbolic link 'sh4-softmmu/qemu-system-sh4.exe': No such file or directory +ln: failed to create symbolic link 'sh4eb-softmmu/qemu-system-sh4eb.exe': No such file or directory +ln: failed to create symbolic link 'sparc-softmmu/qemu-system-sparc.exe': No such file or directory +ln: failed to create symbolic link 'sparc64-softmmu/qemu-system-sparc64.exe': No such file or directory +ln: failed to create symbolic link 'tricore-softmmu/qemu-system-tricore.exe': No such file or directory +ln: failed to create symbolic link 'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory +ln: failed to create symbolic link 'xtensa-softmmu/qemu-system-xtensa.exe': No such file or directory +ln: failed to create symbolic link 'xtensaeb-softmmu/qemu-system-xtensaeb.exe': No such file or directory +The Meson build system +Version: 0.64.1 +Source dir: C:/msys64/home/Roberto/qemu +Build dir: C:/msys64/home/Roberto/qemu/build +Build type: native build +Project name: qemu +Project version: 7.2.50 +C compiler for the host machine: cc -m64 -mcx16 (gcc 12.2.0 "cc (Rev6, Built by MSYS2 project) 12.2.0") +C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.39 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +Program scripts/symlink-install-tree.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/symlink-install-tree.py) +Program sh found: YES (C:\msys64\usr\bin/sh.EXE) +Program python3 found: YES (C:/msys64/mingw64/bin/python.exe) +Program bzip2 found: YES (C:\msys64\mingw64\bin/bzip2.EXE) +Program iasl found: NO +Compiler for C supports link arguments -Wl,-z,relro: NO +Compiler for C supports link arguments -Wl,-z,now: NO +Compiler for C supports link arguments -Wl,--no-seh: YES +Compiler for C supports link arguments -Wl,--nxcompat: YES +C++ compiler for the host machine: c++ -m64 -mcx16 (gcc 12.2.0 "c++ (Rev6, Built by MSYS2 project) 12.2.0") +C++ linker for the host machine: c++ -m64 -mcx16 ld.bfd 2.39 +Compiler for C++ supports link arguments -Wl,--warn-common: YES +Program cgcc found: NO +Library m found: YES +Run-time dependency threads found: YES +Library util found: NO +Program midl found: NO +Program widl found: YES +Library pathcch found: YES +Library ws2_32 found: YES +Library winmm found: YES +Windows resource compiler: GNU windres (GNU Binutils) 2.39 +Has header "WinHvPlatform.h" : YES +Has header "WinHvEmulation.h" : YES +Run-time dependency appleframeworks found: NO (tried framework) +Found pkg-config: C:\msys64\mingw64\bin/pkg-config.EXE (1.8.0) +Run-time dependency gio-2.0 found: YES 2.74.3 +Program C:/msys64/mingw64/bin/gdbus-codegen found: YES (C:/msys64/mingw64/bin/gdbus-codegen.exe) +Run-time dependency gio-unix-2.0 found: NO (tried pkgconfig) +Run-time dependency pixman-1 found: YES 0.42.2 +Run-time dependency zlib found: YES 1.2.13 +Has header "libaio.h" : NO +Run-time dependency liburing found: NO (tried pkgconfig) +Run-time dependency libnfs found: YES 5.0.2 +Has header "attr/xattr.h" : NO +Run-time dependency appleframeworks found: NO (tried framework) +Run-time dependency appleframeworks found: NO (tried framework) +Run-time dependency libseccomp found: NO (tried pkgconfig) +Has header "cap-ng.h" : NO +Run-time dependency xkbcommon found: NO (tried pkgconfig) +Run-time dependency slirp found: YES 4.7.0 +Has header "libvdeplug.h" : NO +Run-time dependency jack found: NO (tried pkgconfig) +Run-time dependency sndio found: NO (tried pkgconfig) +Run-time dependency spice-protocol found: YES 0.14.4 +Run-time dependency spice-server found: YES 0.15.1 +Library rt found: NO +Run-time dependency libiscsi found: NO (tried pkgconfig) +Run-time dependency libzstd found: YES 1.5.2 +Run-time dependency virglrenderer found: NO (tried pkgconfig) +Run-time dependency blkio found: NO (tried pkgconfig) +Run-time dependency libcurl found: YES 7.86.0 +Run-time dependency ncurses found: NO (tried pkgconfig) +Run-time dependency ncursesw found: YES 6.3.20211021 +Has header "brlapi.h" : NO +Run-time dependency sdl2 found: YES 2.26.1 +Run-time dependency sdl2_image found: YES 2.6.2 +Library rados found: NO +Has header "rbd/librbd.h" : NO +Run-time dependency glusterfs-api found: NO (tried pkgconfig) +Run-time dependency libssh found: YES 0.10.4 +Has header "bzlib.h" : YES +Library bz2 found: YES +Has header "lzfse.h" : NO +Has header "sys/soundcard.h" : NO +Has header "dsound.h" : YES +Run-time dependency epoxy found: YES 1.5.10 +Has header "epoxy/egl.h" with dependency epoxy: NO +Run-time dependency gnutls found: YES 3.7.8 +Run-time dependency gmp found: YES 6.2.1 +Run-time dependency gtk+-3.0 found: YES 3.24.35 +Run-time dependency gtk+-x11-3.0 found: NO (tried pkgconfig) +Run-time dependency vte-2.91 found: NO (tried pkgconfig) +Run-time dependency libpng found: YES 1.6.39 +Run-time dependency libjpeg found: YES 2.1.4 +Has header "sasl/sasl.h" : YES +Library sasl2 found: YES +Has header "security/pam_appl.h" : NO +Has header "snappy-c.h" : YES +Library snappy found: YES +Has header "lzo/lzo1x.h" : YES +Library lzo2 found: YES +Has header "numa.h" : NO +Library ibumad found: NO +Has header "rdma/rdma_cma.h" : NO +Library ibverbs found: NO +Run-time dependency xencontrol found: NO (tried pkgconfig) +Library xenstore found: NO +Library xenctrl found: NO +Library xendevicemodel found: NO +Library xenforeignmemory found: NO +Library xengnttab found: NO +Library xenevtchn found: NO +Library xentoolcore found: NO +Run-time dependency libcacard found: NO (tried pkgconfig) +Run-time dependency u2f-emu found: NO (tried pkgconfig) +Run-time dependency canokey-qemu found: NO (tried pkgconfig) +Run-time dependency libusbredirparser-0.5 found: YES 0.8.0 +Run-time dependency libusb-1.0 found: YES 1.0.26 +Run-time dependency libpmem found: NO (tried pkgconfig) +Run-time dependency libdaxctl found: NO (tried pkgconfig) +Run-time dependency libtasn1 found: YES 4.19.0 +Run-time dependency libkeyutils found: NO (tried pkgconfig) +Checking for function "gettid" : NO +Run-time dependency libselinux found: NO (tried pkgconfig) +Run-time dependency fuse3 found: NO (tried pkgconfig) +Run-time dependency libbpf found: NO (tried pkgconfig) +Checking for function "pthread_fchdir_np" : NO +Has header "sys/epoll.h" : NO +Has header "linux/magic.h" : NO +Has header "valgrind/valgrind.h" : NO +Has header "linux/btrfs.h" : NO +Has header "libdrm/drm.h" : NO +Has header "pty.h" : NO +Has header "sys/disk.h" : NO +Has header "sys/ioccom.h" : NO +Has header "sys/kcov.h" : NO +Has header "afunix.h" : YES +Checking for function "close_range" : NO +Checking for function "accept4" : NO +Checking for function "clock_adjtime" : NO +Checking for function "dup3" : NO +Checking for function "fallocate" : NO +Checking for function "posix_fallocate" : NO +Checking for function "posix_memalign" : NO +Checking for function "_aligned_malloc" : YES +Checking for function "valloc" : NO +Checking for function "memalign" : NO +Checking for function "ppoll" : NO +Checking for function "preadv" : NO +Checking for function "pthread_fchdir_np" : NO (cached) +Checking for function "sendfile" : NO +Checking for function "setns" : NO +Checking for function "syncfs" : NO +Checking for function "sync_file_range" : NO +Checking for function "timerfd_create" : NO +Checking for function "copy_file_range" : NO +Checking for function "getifaddrs" : NO +Checking for function "openpty" with dependency -lutil: NO +Checking for function "strchrnul" : NO +Checking for function "system" : YES +Header "byteswap.h" has symbol "bswap_32" : NO +Header "sys/epoll.h" has symbol "epoll_create1" : NO +Header "linux/falloc.h" has symbol "FALLOC_FL_PUNCH_HOLE" : NO +Header "linux/falloc.h" has symbol "FALLOC_FL_ZERO_RANGE" : NO +Has header "linux/fiemap.h" : NO +Checking for function "getrandom" : NO +Header "sys/inotify.h" has symbol "inotify_init" : NO +Header "sys/inotify.h" has symbol "inotify_init1" : NO +Header "machine/bswap.h" has symbol "bswap32" : NO +Header "sys/prctl.h" has symbol "PR_SET_TIMERSLACK" : NO +Header "linux/rtnetlink.h" has symbol "IFLA_PROTO_DOWN" : NO +Header "sys/sysmacros.h" has symbol "makedev" : NO +Header "getopt.h" has symbol "optreset" : NO +Header "netinet/in.h" has symbol "IPPROTO_MPTCP" : NO +Header "sys/mount.h" has symbol "FSCONFIG_SET_FLAG" : NO +Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO +Checking whether type "struct stat" has member "st_atim" : NO +Checking for type "struct iovec" : NO +Checking for type "struct utmpx" : NO +Checking for type "struct mmsghdr" : NO +Header "linux/vm_sockets.h" has symbol "AF_VSOCK" : NO +Has header "vscoordint.h" : NO +Checking if "_lock_file and _unlock_file" : links: YES +Program scripts/minikconf.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/minikconf.py) +Configuring aarch64-softmmu-config-target.h using configuration +Configuring aarch64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/aarch64-softmmu-config-devices.mak.d +Configuring aarch64-softmmu-config-devices.h using configuration +Configuring alpha-softmmu-config-target.h using configuration +Configuring alpha-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/alpha-softmmu-config-devices.mak.d +Configuring alpha-softmmu-config-devices.h using configuration +Configuring arm-softmmu-config-target.h using configuration +Configuring arm-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/arm-softmmu-config-devices.mak.d +Configuring arm-softmmu-config-devices.h using configuration +Configuring avr-softmmu-config-target.h using configuration +Configuring avr-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/avr-softmmu-config-devices.mak.d +Configuring avr-softmmu-config-devices.h using configuration +Configuring cris-softmmu-config-target.h using configuration +Configuring cris-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/cris-softmmu-config-devices.mak.d +Configuring cris-softmmu-config-devices.h using configuration +Configuring hppa-softmmu-config-target.h using configuration +Configuring hppa-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/hppa-softmmu-config-devices.mak.d +Configuring hppa-softmmu-config-devices.h using configuration +Configuring i386-softmmu-config-target.h using configuration +Configuring i386-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/i386-softmmu-config-devices.mak.d +Configuring i386-softmmu-config-devices.h using configuration +Configuring loongarch64-softmmu-config-target.h using configuration +Configuring loongarch64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/loongarch64-softmmu-config-devices.mak.d +Configuring loongarch64-softmmu-config-devices.h using configuration +Configuring m68k-softmmu-config-target.h using configuration +Configuring m68k-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/m68k-softmmu-config-devices.mak.d +Configuring m68k-softmmu-config-devices.h using configuration +Configuring microblaze-softmmu-config-target.h using configuration +Configuring microblaze-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/microblaze-softmmu-config-devices.mak.d +Configuring microblaze-softmmu-config-devices.h using configuration +Configuring microblazeel-softmmu-config-target.h using configuration +Configuring microblazeel-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/microblazeel-softmmu-config-devices.mak.d +Configuring microblazeel-softmmu-config-devices.h using configuration +Configuring mips-softmmu-config-target.h using configuration +Configuring mips-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips-softmmu-config-devices.mak.d +Configuring mips-softmmu-config-devices.h using configuration +Configuring mips64-softmmu-config-target.h using configuration +Configuring mips64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips64-softmmu-config-devices.mak.d +Configuring mips64-softmmu-config-devices.h using configuration +Configuring mips64el-softmmu-config-target.h using configuration +Configuring mips64el-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mips64el-softmmu-config-devices.mak.d +Configuring mips64el-softmmu-config-devices.h using configuration +Configuring mipsel-softmmu-config-target.h using configuration +Configuring mipsel-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/mipsel-softmmu-config-devices.mak.d +Configuring mipsel-softmmu-config-devices.h using configuration +Configuring nios2-softmmu-config-target.h using configuration +Configuring nios2-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/nios2-softmmu-config-devices.mak.d +Configuring nios2-softmmu-config-devices.h using configuration +Configuring or1k-softmmu-config-target.h using configuration +Configuring or1k-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/or1k-softmmu-config-devices.mak.d +Configuring or1k-softmmu-config-devices.h using configuration +Configuring ppc-softmmu-config-target.h using configuration +Configuring ppc-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/ppc-softmmu-config-devices.mak.d +Configuring ppc-softmmu-config-devices.h using configuration +Configuring ppc64-softmmu-config-target.h using configuration +Configuring ppc64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/ppc64-softmmu-config-devices.mak.d +Configuring ppc64-softmmu-config-devices.h using configuration +Configuring riscv32-softmmu-config-target.h using configuration +Configuring riscv32-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/riscv32-softmmu-config-devices.mak.d +Configuring riscv32-softmmu-config-devices.h using configuration +Configuring riscv64-softmmu-config-target.h using configuration +Configuring riscv64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/riscv64-softmmu-config-devices.mak.d +Configuring riscv64-softmmu-config-devices.h using configuration +Configuring rx-softmmu-config-target.h using configuration +Configuring rx-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/rx-softmmu-config-devices.mak.d +Configuring rx-softmmu-config-devices.h using configuration +Configuring s390x-softmmu-config-target.h using configuration +Configuring s390x-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/s390x-softmmu-config-devices.mak.d +Configuring s390x-softmmu-config-devices.h using configuration +Configuring sh4-softmmu-config-target.h using configuration +Configuring sh4-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sh4-softmmu-config-devices.mak.d +Configuring sh4-softmmu-config-devices.h using configuration +Configuring sh4eb-softmmu-config-target.h using configuration +Configuring sh4eb-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sh4eb-softmmu-config-devices.mak.d +Configuring sh4eb-softmmu-config-devices.h using configuration +Configuring sparc-softmmu-config-target.h using configuration +Configuring sparc-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sparc-softmmu-config-devices.mak.d +Configuring sparc-softmmu-config-devices.h using configuration +Configuring sparc64-softmmu-config-target.h using configuration +Configuring sparc64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/sparc64-softmmu-config-devices.mak.d +Configuring sparc64-softmmu-config-devices.h using configuration +Configuring tricore-softmmu-config-target.h using configuration +Configuring tricore-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/tricore-softmmu-config-devices.mak.d +Configuring tricore-softmmu-config-devices.h using configuration +Configuring x86_64-softmmu-config-target.h using configuration +Configuring x86_64-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d +Configuring x86_64-softmmu-config-devices.h using configuration +Configuring xtensa-softmmu-config-target.h using configuration +Configuring xtensa-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/xtensa-softmmu-config-devices.mak.d +Configuring xtensa-softmmu-config-devices.h using configuration +Configuring xtensaeb-softmmu-config-target.h using configuration +Configuring xtensaeb-softmmu-config-devices.mak with command +Reading depfile: C:/msys64/home/Roberto/qemu/build/meson-private/xtensaeb-softmmu-config-devices.mak.d +Configuring xtensaeb-softmmu-config-devices.h using configuration +Program scripts/make-config-poison.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/make-config-poison.sh) +Run-time dependency capstone found: YES 4.0.2 +Library fdt found: NO +Configuring config-host.h using configuration +Program scripts/hxtool found: YES (sh C:/msys64/home/Roberto/qemu/scripts/hxtool) +Program scripts/shaderinclude.pl found: YES (perl C:/msys64/home/Roberto/qemu/scripts/shaderinclude.pl) +Program scripts/qapi-gen.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/qapi-gen.py) +Program scripts/qemu-version.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/qemu-version.sh) +Program scripts/decodetree.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/decodetree.py) +Program ../scripts/modules/module_block.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/block/../scripts/modules/module_block.py) +Program ../scripts/block-coroutine-wrapper.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/block/../scripts/block-coroutine-wrapper. +py) +Program scripts/modinfo-collect.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/modinfo-collect.py) +Program scripts/modinfo-generate.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/modinfo-generate.py) +Program nm found: YES +Program scripts/undefsym.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/undefsym.py) +Program scripts/feature_to_c.sh found: YES (sh C:/msys64/home/Roberto/qemu/scripts/feature_to_c.sh) +Compiler for C supports link arguments -fstack-protector-all: YES +Compiler for C supports link arguments -fstack-protector-strong: YES +Compiler for C supports link arguments -Wl,--add-stdcall-alias: YES +Compiler for C supports link arguments -Wl,--enable-stdcall-fixup: YES +Library ole32 found: YES +Library oleaut32 found: YES +Library shlwapi found: YES +Library uuid found: YES +Library intl found: YES +Program wixl found: NO +Configuring 50-edk2-i386-secure.json using configuration +Configuring 50-edk2-x86_64-secure.json using configuration +Configuring 60-edk2-aarch64.json using configuration +Configuring 60-edk2-arm.json using configuration +Configuring 60-edk2-i386.json using configuration +Configuring 60-edk2-x86_64.json using configuration +Program qemu-keymap found: NO +Program sphinx-build found: YES (C:\msys64\mingw64\bin/sphinx-build.EXE) +../docs/meson.build:74: WARNING: Project targets '>=0.61.3' but uses feature deprecated since '0.60.0': install_subdir with empty directory. It worked by accide +nt and is buggy. Use install_emptydir instead. +Program diff found: YES (C:\msys64\usr\bin/diff.EXE) +Program dbus-daemon found: NO +Did not find CMake 'cmake' +Found CMake: NO +Run-time dependency gvnc-1.0 found: NO (tried pkgconfig and cmake) +Program initrd-stress.sh found: YES (sh C:/msys64/home/Roberto/qemu/tests/migration/initrd-stress.sh) +Program xgettext found: YES (C:\msys64\mingw64\bin/xgettext.EXE) +Program msgfmt found: YES (C:\msys64\mingw64\bin/msgfmt.EXE) +Program msginit found: YES (C:\msys64\mingw64\bin/msginit.EXE) +Program msgmerge found: YES (C:\msys64\mingw64\bin/msgmerge.EXE) +Program xgettext found: YES (C:\msys64\mingw64\bin/xgettext.EXE) +Program scripts/nsis.py found: YES (C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/nsis.py) +Build targets in project: 639 +WARNING: Deprecated features used: + * 0.60.0: {'install_subdir with empty directory'} + +qemu 7.2.50 + + Directories + Install prefix : C:/msys64/qemu + BIOS directory : share/ + firmware path : share/qemu-firmware + binary directory : C:/msys64/qemu/. + library directory : C:/msys64/qemu/lib + module directory : lib/ + libexec directory : C:/msys64/qemu/libexec + include directory : C:/msys64/qemu/include + config directory : C:/msys64/qemu/etc + local state directory : queried at runtime + Doc directory : C:/msys64/qemu/share/doc + Build directory : C:/msys64/home/xxx/qemu/build + Source path : C:/msys64/home/xxx/qemu + GIT submodules : ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc + + Host binaries + git : git + make : make + python : C:/msys64/mingw64/bin/python.exe (version: 3.10) + sphinx-build : C:\msys64\mingw64\bin/sphinx-build.EXE + gdb : /mingw64/bin/gdb-multiarch + iasl : NO + genisoimage : + wixl : NO + smbd : NO + + Configurable features + Documentation : YES + system-mode emulation : YES + user-mode emulation : NO + block layer : YES + Install blobs : YES + module support : NO + fuzzing support : NO + Audio drivers : dsound sdl + Trace backends : log + D-Bus display : NO + QOM debugging : NO + vhost-kernel support : NO + vhost-net support : NO + vhost-user support : NO + vhost-user-crypto support : NO + vhost-user-blk server support: NO + vhost-vdpa support : NO + build guest agent : YES + + Compilation + host CPU : x86_64 + host endianness : little + C compiler : cc -m64 -mcx16 + Host C compiler : cc -m64 -mcx16 + C++ compiler : c++ -m64 -mcx16 + CFLAGS : -O2 -g + CXXFLAGS : -O2 -g + QEMU_CFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prot +otypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -W +type-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallt +hrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong + QEMU_CXXFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwri +te-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -W +expansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong + QEMU_OBJCFLAGS : -Wold-style-declaration -Wold-style-definition -Wtype-limits -Winit-self -Wempty-body -Wnested-externs -Wendif-labels -Wexpan +sion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi + QEMU_LDFLAGS : -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--warn-common + profiler : NO + link-time optimization (LTO) : NO + PIE : NO + static build : NO + malloc trim support : NO + membarrier : NO + debug stack usage : NO + mutex debugging : NO + memory allocator : system + avx2 optimization : YES + avx512f optimization : NO + gprof enabled : NO + gcov : NO + thread sanitizer : NO + CFI support : NO + strip binaries : NO + sparse : NO + mingw32 support : YES + + Cross compilers + x86_64 : cc + + Targets and accelerators + KVM support : NO + HAX support : YES + HVF support : NO + WHPX support : YES + NVMM support : NO + Xen support : NO + TCG support : YES + TCG backend : native (x86_64) + TCG plugins : NO + TCG debug enabled : NO + target list : aarch64-softmmu alpha-softmmu arm-softmmu avr-softmmu cris-softmmu hppa-softmmu i386-softmmu loongarch64-softmmu m68k-softmmu + microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu nios2-softmmu or1k-softmmu ppc-softmmu ppc64-softmmu riscv3 +2-softmmu riscv64-softmmu rx-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu x86_64-softmmu xtensa-softmmu xtensae +b-softmmu + default devices : YES + out of process emulation : NO + vfio-user server : NO + + Block layer support + coroutine backend : win32 + coroutine pool : YES + Block whitelist (rw) : + Block whitelist (ro) : + Use block whitelist in tools : NO + VirtFS support : NO + build virtiofs daemon : NO + Live block migration : YES + replication support : YES + bochs support : YES + cloop support : YES + dmg support : YES + qcow v1 support : YES + vdi support : YES + vvfat support : YES + qed support : YES + parallels support : YES + FUSE exports : NO + VDUSE block exports : NO + + Crypto + TLS priority : NORMAL + GNUTLS support : YES 3.7.8 + GNUTLS crypto : YES + libgcrypt : NO + nettle : NO + AF_ALG support : NO + rng-none : NO + Linux keyring : NO + + Dependencies + SDL support : YES + SDL image support : YES 2.6.2 + GTK support : YES + pixman : YES 0.42.2 + VTE support : NO + slirp support : YES 4.7.0 + libtasn1 : YES 4.19.0 + PAM : NO + iconv support : YES + curses support : YES + virgl support : NO + blkio support : NO + curl support : YES 7.86.0 + Multipath support : NO + PNG support : YES 1.6.39 + VNC support : YES + VNC SASL support : YES + VNC JPEG support : YES 2.1.4 + DirectSound support : YES + JACK support : NO + brlapi support : NO + vde support : NO + netmap support : NO + l2tpv3 support : NO + Linux AIO support : NO + Linux io_uring support : NO + ATTR/XATTR support : NO + RDMA support : NO + PVRDMA support : NO + fdt support : internal + libcap-ng support : NO + bpf support : NO + spice protocol support : YES 0.14.4 + spice server support : YES 0.15.1 + rbd support : NO + smartcard support : NO + U2F support : NO + libusb : YES 1.0.26 + usb net redir : YES 0.8.0 + OpenGL support (epoxy) : NO + GBM : NO + libiscsi support : NO + libnfs support : YES 5.0.2 + QGA VSS support : YES + seccomp support : NO + GlusterFS support : NO + TPM support : NO + libssh support : YES 0.10.4 + lzo support : YES + snappy support : YES + bzip2 support : YES + lzfse support : NO + zstd support : YES 1.5.2 + NUMA host support : NO + capstone : YES 4.0.2 + libpmem support : NO + libdaxctl support : NO + libudev : NO + FUSE lseek : NO + selinux : NO + + User defined options + Native files : config-meson.cross + bindir : + prefix : C:/msys64/qemu + werror : true + b_pie : false + gtk : enabled + qemu_suffix : + sdl : enabled + vfio_user_server : disabled + +Found ninja-1.11.1 at C:/msys64/mingw64/bin/ninja.exe +Running postconf script 'C:/msys64/mingw64/bin/python.exe C:/msys64/home/Roberto/qemu/scripts/symlink-install-tree.py' +--- stdout --- + +--- stderr --- +error making symbolic link C:/msys64/qemu/share/trace-events-all +Traceback (most recent call last): + File "C:\msys64\home\Roberto\qemu\scripts\symlink-install-tree.py", line 33, in <module> + raise e + File "C:\msys64\home\Roberto\qemu\scripts\symlink-install-tree.py", line 29, in <module> + os.symlink(source, bundle_dest) +OSError: [WinError 1314] Il privilegio richiesto non appartiene al client: 'C:/msys64/home/Roberto/qemu/build/trace/trace-events-all' -> 'qemu-bundle/msys64/qem +u/share/trace-events-all' +``` +Additional information: +The line below ensures that proper tags are added to the issue. +Please do not remove it. +--> diff --git a/results/classifier/118/permissions/1388735 b/results/classifier/118/permissions/1388735 new file mode 100644 index 00000000..66c023bc --- /dev/null +++ b/results/classifier/118/permissions/1388735 @@ -0,0 +1,77 @@ +permissions: 0.866 +vnc: 0.822 +performance: 0.821 +peripherals: 0.691 +architecture: 0.686 +device: 0.686 +semantic: 0.681 +mistranslation: 0.670 +network: 0.666 +x86: 0.588 +user-level: 0.587 +graphic: 0.582 +ppc: 0.579 +risc-v: 0.544 +register: 0.525 +arm: 0.514 +kernel: 0.513 +PID: 0.500 +debug: 0.500 +socket: 0.460 +assembly: 0.427 +files: 0.423 +VMM: 0.396 +TCG: 0.389 +hypervisor: 0.384 +boot: 0.378 +KVM: 0.297 +virtual: 0.245 +i386: 0.245 + +QEMU no longer allows to use full TCP port range for VNC + +After upgrade to QEMU version 2.1.0 (Debian 2.1+dfsg-4ubuntu6), I am no longer able to use any TCP port for VNC display. +For example, if I need to assign VNC server a TCP port 443, I used to run: +# qemu-system-x86_64 -vnc :-5457 +qemu-system-x86_64: Failed to start VNC server on `:-1000': can't convert to a number:-5457 +expected behavior: as any VNC software, take port base of 5900, substract 5457 display number, and use TCP port 443 + +I ask to change vnc port conversion routine to allow input values in range of all TCP ports, from 1 to 65535. + +I really depend on ability to use full TCP range for VNC port numbers, and inablity to do so in new version of QEMU is very disappointing. + +I disagree. This is a vnc port number, and by definition it can't really be negative. The fact that some vnc software allows negative port like this, or that some software uses tcp port number in place of vnc port number, does not make it more valid. + +We're talking about an issue in original vnc specification, -- maybe they should have used tcp port in the first place. + +And yes, this way we can't specify tcp port less than 5900. + +In order to solve this issue for real, I think the best way is to allow specifying tcp port somehow. How does other vnc software deal with this? One example I can think of is to use double-semicolon syntax, like this: -vnc ::443. But we should just agree on some common way, already used by other vnc software. + +What is in use today? + +Thanks, + +/mjt + +Unfortunately, standard (eirther RFB Protocl V 3.X or RFC 6143) doesn't define bahavior with ports different from 5900: + Note that the only port number assigned by IANA for RFB is port 5900, + so RFB clients and servers should avoid using other port numbers + unless they are communicating with servers or clients known to use + the non-standard ports. + +So it is absolutely dependant on implementation, how to handle non-standard port numbers. +Both implementations from RealNetworks (authors of original VNC) and all other implementations (Tight, and numberous java applets) are allowing negative display numbers with one of two options: +* negative port number accepted, like :-5457 (like QEMU allowed to do before), +* ::<port number> allowed for direct port number instead of display number, like ::443. + +It will be best for me, to allow behavior of QEMU before 2.1 (with negative display numbers). +But notation of ::<tcp portnumber> would also solve my problem. + +Use for this is very simple - in hosting environment, I am not able to adjust firewall to allow inbound connections for not privileged ports. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1395217 b/results/classifier/118/permissions/1395217 new file mode 100644 index 00000000..3829f5f9 --- /dev/null +++ b/results/classifier/118/permissions/1395217 @@ -0,0 +1,347 @@ +permissions: 0.931 +semantic: 0.905 +mistranslation: 0.859 +peripherals: 0.859 +register: 0.856 +user-level: 0.841 +debug: 0.832 +architecture: 0.825 +assembly: 0.806 +graphic: 0.801 +socket: 0.789 +network: 0.781 +device: 0.776 +arm: 0.767 +hypervisor: 0.760 +ppc: 0.747 +x86: 0.745 +TCG: 0.734 +risc-v: 0.731 +vnc: 0.719 +performance: 0.719 +kernel: 0.710 +PID: 0.704 +virtual: 0.696 +KVM: 0.655 +VMM: 0.638 +files: 0.632 +boot: 0.588 +i386: 0.466 + +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/118/permissions/1400 b/results/classifier/118/permissions/1400 new file mode 100644 index 00000000..920aa03d --- /dev/null +++ b/results/classifier/118/permissions/1400 @@ -0,0 +1,31 @@ +permissions: 0.931 +network: 0.861 +device: 0.852 +vnc: 0.665 +arm: 0.659 +ppc: 0.650 +kernel: 0.606 +VMM: 0.570 +socket: 0.564 +performance: 0.526 +x86: 0.524 +debug: 0.494 +TCG: 0.483 +architecture: 0.483 +risc-v: 0.469 +i386: 0.415 +KVM: 0.360 +hypervisor: 0.360 +register: 0.268 +graphic: 0.263 +boot: 0.239 +PID: 0.233 +semantic: 0.230 +assembly: 0.197 +files: 0.193 +peripherals: 0.147 +mistranslation: 0.054 +user-level: 0.029 +virtual: 0.024 + +helper_access_check_cp_reg() raising Undefined Instruction on big-endian host diff --git a/results/classifier/118/permissions/1411 b/results/classifier/118/permissions/1411 new file mode 100644 index 00000000..1281faef --- /dev/null +++ b/results/classifier/118/permissions/1411 @@ -0,0 +1,485 @@ +permissions: 0.816 +debug: 0.813 +graphic: 0.804 +user-level: 0.794 +register: 0.777 +architecture: 0.775 +semantic: 0.771 +mistranslation: 0.753 +performance: 0.753 +PID: 0.747 +arm: 0.746 +virtual: 0.741 +risc-v: 0.741 +socket: 0.691 +files: 0.689 +assembly: 0.670 +network: 0.663 +peripherals: 0.663 +ppc: 0.648 +TCG: 0.645 +vnc: 0.642 +hypervisor: 0.629 +VMM: 0.625 +device: 0.623 +KVM: 0.595 +boot: 0.582 +x86: 0.531 +kernel: 0.501 +i386: 0.366 + +QEMU 7.2.0 - Failed compilation under MacOS +Description of problem: +I downloaded and tried to build QEMU from git following the instructions from here: +https://www.qemu.org/download/ + +(I successfully installed QEMU with homebrew later, but I still want to figure out why my compilation failed.) +Steps to reproduce: +``` +git clone https://gitlab.com/qemu-project/qemu.git +cd qemu +git submodule init +git submodule update --recursive +./configure +make +``` +Additional information: +With `./configure` I got: + +``` +Using './build' as the directory for build output +Disabling PIE due to missing toolchain support +The Meson build system +Version: 0.61.5 +Source dir: /Users/xxx/qemu +Build dir: /Users/xxx/qemu/build +Build type: native build +Project name: qemu +Project version: 7.2.50 +C compiler for the host machine: cc (clang 14.0.0 "Apple clang version 14.0.0 (clang-1400.0.29.202)") +C linker for the host machine: cc ld64 820.1 +Host machine cpu family: aarch64 +Host machine cpu: arm64 +Program scripts/symlink-install-tree.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/symlink-install-tree.py) +Program sh found: YES (/bin/sh) +Program python3 found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10) +Program bzip2 found: YES (/usr/bin/bzip2) +Program iasl found: NO +Compiler for C supports link arguments -Wl,-z,relro: NO +Compiler for C supports link arguments -Wl,-z,now: NO +C++ compiler for the host machine: c++ (clang 14.0.0 "Apple clang version 14.0.0 (clang-1400.0.29.202)") +C++ linker for the host machine: c++ ld64 820.1 +Compiler for C++ supports link arguments -Wl,--warn-common: NO +Objective-C compiler for the host machine: clang (clang 14.0.0) +Objective-C linker for the host machine: clang ld64 820.1 +Program cgcc found: NO +Library m found: YES +Run-time dependency threads found: YES +Library util found: YES +Run-time dependency appleframeworks found: YES (CoreFoundation) +Run-time dependency appleframeworks found: YES (IOKit) +Run-time dependency appleframeworks found: YES (Hypervisor) +Found pkg-config: /opt/homebrew/bin/pkg-config (0.29.2) +Run-time dependency gio-2.0 found: YES 2.74.4 +Program /opt/homebrew/Cellar/glib/2.74.4/bin/gdbus-codegen found: YES (/opt/homebrew/Cellar/glib/2.74.4/bin/gdbus-codegen) +Run-time dependency gio-unix-2.0 found: YES 2.74.4 +Run-time dependency pixman-1 found: YES 0.42.2 +Run-time dependency zlib found: YES 1.2.11 +Has header "libaio.h" : NO +Run-time dependency liburing found: NO (tried pkgconfig) +Run-time dependency libnfs found: NO (tried pkgconfig) +Has header "attr/xattr.h" : NO +Run-time dependency appleframeworks found: YES (Cocoa, CoreVideo) +Run-time dependency appleframeworks found: YES (vmnet) +Header <vmnet/vmnet.h> has symbol "VMNET_BRIDGED_MODE" with dependency appleframeworks: YES +Run-time dependency libseccomp found: NO (tried pkgconfig) +Has header "cap-ng.h" : NO +Run-time dependency xkbcommon found: NO (tried pkgconfig) +Run-time dependency slirp found: NO (tried pkgconfig) +Has header "libvdeplug.h" : NO +Run-time dependency jack found: NO (tried pkgconfig) +Run-time dependency sndio found: NO (tried pkgconfig) +Run-time dependency spice-protocol found: NO (tried pkgconfig) +Run-time dependency spice-server found: NO (tried pkgconfig) +Library rt found: NO +Run-time dependency libiscsi found: NO (tried pkgconfig) +Run-time dependency libzstd found: NO (tried pkgconfig) +Run-time dependency virglrenderer found: NO (tried pkgconfig) +Run-time dependency blkio found: NO (tried pkgconfig) +Run-time dependency libcurl found: YES 7.84.0 +Run-time dependency ncursesw found: YES 5.7.20081102 +Has header "brlapi.h" : NO +sdl2-config found: NO +Run-time dependency sdl2 found: NO (tried pkgconfig, config-tool and framework) +Library rados found: NO +Has header "rbd/librbd.h" : NO +Run-time dependency glusterfs-api found: NO (tried pkgconfig) +Run-time dependency libssh found: NO (tried pkgconfig) +Has header "bzlib.h" : YES +Library bz2 found: YES +Has header "lzfse.h" : NO +Has header "sys/soundcard.h" : NO +Run-time dependency appleframeworks found: YES (CoreAudio) +Run-time dependency epoxy found: NO (tried pkgconfig) +Has header "epoxy/egl.h" with dependency epoxy: NO +Run-time dependency gnutls found: NO (tried pkgconfig) +Run-time dependency gnutls found: NO (tried pkgconfig) +libgcrypt-config found: NO need ['>=1.8'] +Run-time dependency libgcrypt found: NO (tried config-tool) +Run-time dependency nettle found: NO (tried pkgconfig) +Run-time dependency gmp found: NO (tried pkgconfig) +Run-time dependency gtk+-3.0 found: NO (tried pkgconfig) +Run-time dependency libpng found: NO (tried pkgconfig) +Run-time dependency libjpeg found: NO (tried pkgconfig) +Has header "sasl/sasl.h" : YES +Library sasl2 found: YES +Has header "security/pam_appl.h" : YES +Library pam found: YES +Has header "snappy-c.h" : NO +Has header "lzo/lzo1x.h" : NO +Has header "numa.h" : NO +Library ibumad found: NO +Has header "rdma/rdma_cma.h" : NO +Library ibverbs found: NO +Run-time dependency xencontrol found: NO (tried pkgconfig) +Library xenstore found: NO +Library xenctrl found: NO +Library xendevicemodel found: NO +Library xenforeignmemory found: NO +Library xengnttab found: NO +Library xenevtchn found: NO +Library xentoolcore found: NO +Run-time dependency libcacard found: NO (tried pkgconfig) +Run-time dependency u2f-emu found: NO (tried pkgconfig) +Run-time dependency canokey-qemu found: NO (tried pkgconfig) +Run-time dependency libusbredirparser-0.5 found: NO (tried pkgconfig) +Run-time dependency libusb-1.0 found: NO (tried pkgconfig) +Run-time dependency libpmem found: NO (tried pkgconfig) +Run-time dependency libdaxctl found: NO (tried pkgconfig) +Run-time dependency libkeyutils found: NO (tried pkgconfig) +Checking for function "gettid" : NO +Run-time dependency libselinux found: NO (tried pkgconfig) +Run-time dependency fuse3 found: NO (tried pkgconfig) +Run-time dependency libbpf found: NO (tried pkgconfig) +Has header "IOKit/storage/IOMedia.h" : YES +Checking for function "pthread_fchdir_np" : YES +Has header "sys/epoll.h" : NO +Has header "linux/magic.h" : NO +Has header "valgrind/valgrind.h" : NO +Has header "linux/btrfs.h" : NO +Has header "libdrm/drm.h" : NO +Has header "pty.h" : NO +Has header "sys/disk.h" : YES +Has header "sys/ioccom.h" : YES +Has header "sys/kcov.h" : NO +Checking for function "close_range" : NO +Checking for function "accept4" : NO +Checking for function "clock_adjtime" : NO +Checking for function "dup3" : NO +Checking for function "fallocate" : NO +Checking for function "posix_fallocate" : NO +Checking for function "posix_memalign" : YES +Checking for function "_aligned_malloc" : NO +Checking for function "valloc" : YES +Checking for function "memalign" : NO +Checking for function "ppoll" : NO +Checking for function "preadv" : YES +Checking for function "pthread_fchdir_np" : YES (cached) +Checking for function "sendfile" : YES +Checking for function "setns" : NO +Checking for function "syncfs" : NO +Checking for function "sync_file_range" : NO +Checking for function "timerfd_create" : NO +Checking for function "copy_file_range" : NO +Checking for function "getifaddrs" : YES +Checking for function "openpty" with dependency -lutil: YES +Checking for function "strchrnul" : NO +Checking for function "system" : YES +Header <byteswap.h> has symbol "bswap_32" : NO +Header <sys/epoll.h> has symbol "epoll_create1" : NO +Header <linux/falloc.h> has symbol "FALLOC_FL_PUNCH_HOLE" : NO +Header <linux/falloc.h> has symbol "FALLOC_FL_ZERO_RANGE" : NO +Has header "linux/fiemap.h" : NO +Checking for function "getrandom" : NO +Header <sys/inotify.h> has symbol "inotify_init" : NO +Header <sys/inotify.h> has symbol "inotify_init1" : NO +Header <machine/bswap.h> has symbol "bswap32" : NO +Header <sys/prctl.h> has symbol "PR_SET_TIMERSLACK" : NO +Header <linux/rtnetlink.h> has symbol "IFLA_PROTO_DOWN" : NO +Header <sys/sysmacros.h> has symbol "makedev" : NO +Header <getopt.h> has symbol "optreset" : YES +Header <netinet/in.h> has symbol "IPPROTO_MPTCP" : NO +Header <sys/mount.h> has symbol "FSCONFIG_SET_FLAG" : NO +Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO +Checking whether type "struct stat" has member "st_atim" : NO +Checking for type "struct iovec" : YES +Checking for type "struct utmpx" : YES +Checking for type "struct mmsghdr" : NO +Header <linux/vm_sockets.h> has symbol "AF_VSOCK" : NO +Program scripts/minikconf.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/minikconf.py) +Configuring x86_64-softmmu-config-target.h using configuration +Configuring x86_64-softmmu-config-devices.mak with command +Reading depfile: /Users/xxx/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d +Configuring x86_64-softmmu-config-devices.h using configuration +Program scripts/make-config-poison.sh found: YES (/Users/xxx/qemu/scripts/make-config-poison.sh) +Run-time dependency capstone found: NO (tried pkgconfig) +Library fdt found: NO +Configuring config-host.h using configuration +Program scripts/hxtool found: YES (/Users/xxx/qemu/scripts/hxtool) +Program scripts/shaderinclude.pl found: YES (/usr/bin/env perl /Users/xxx/qemu/scripts/shaderinclude.pl) +Program scripts/qapi-gen.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/qapi-gen.py) +Program scripts/qemu-version.sh found: YES (/Users/xxx/qemu/scripts/qemu-version.sh) +Program scripts/decodetree.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/decodetree.py) +Program ../scripts/modules/module_block.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/block/../scripts/modules/module_block.py) +Program ../scripts/block-coroutine-wrapper.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/block/../scripts/block-coroutine-wrapper.py) +Configuring qemu-plugins-ld64.symbols with command +Program scripts/modinfo-collect.py found: YES (/Users/xxx/qemu/scripts/modinfo-collect.py) +Program scripts/modinfo-generate.py found: YES (/Users/xxx/qemu/scripts/modinfo-generate.py) +Program nm found: YES +Program scripts/undefsym.py found: YES (/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/undefsym.py) +Program scripts/feature_to_c.sh found: YES (/bin/sh /Users/xxx/qemu/scripts/feature_to_c.sh) +Program scripts/entitlement.sh found: YES (/Users/xxx/qemu/scripts/entitlement.sh) +Configuring 50-edk2-i386-secure.json using configuration +Configuring 50-edk2-x86_64-secure.json using configuration +Configuring 60-edk2-aarch64.json using configuration +Configuring 60-edk2-arm.json using configuration +Configuring 60-edk2-i386.json using configuration +Configuring 60-edk2-x86_64.json using configuration +Program qemu-keymap found: NO +Program sphinx-build-3 sphinx-build found: NO +Program bash found: NO found 3.2.57 but need: '>= 4.0' (/bin/bash) +Message: bash >= v4.0 not available ==> Disabled the qemu-iotests. +Program diff found: YES (/usr/bin/diff) +Program dbus-daemon found: NO +Did not find CMake 'cmake' +Found CMake: NO +Run-time dependency gvnc-1.0 found: NO (tried pkgconfig, framework and cmake) +Program initrd-stress.sh found: YES (/Users/xxx/qemu/tests/migration/initrd-stress.sh) +Build targets in project: 499 + +qemu 7.2.50 + + Directories + Install prefix : /usr/local + BIOS directory : share/qemu + firmware path : share/qemu-firmware + binary directory : /usr/local/bin + library directory : /usr/local/lib + module directory : lib/qemu + libexec directory : /usr/local/libexec + include directory : /usr/local/include + config directory : /usr/local/etc + local state directory : /var/local + Manual directory : /usr/local/share/man + Doc directory : /usr/local/share/doc + Build directory : /Users/xxx/qemu/build + Source path : /Users/xxx/qemu + GIT submodules : ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc + + Host binaries + git : git + make : make + python : /opt/homebrew/opt/python@3.10/bin/python3.10 (version: 3.10) + sphinx-build : NO + iasl : NO + genisoimage : + + Configurable features + Documentation : NO + system-mode emulation : YES + user-mode emulation : NO + block layer : YES + Install blobs : YES + module support : NO + fuzzing support : NO + Audio drivers : coreaudio + Trace backends : log + D-Bus display : NO + QOM debugging : NO + vhost-kernel support : NO + vhost-net support : NO + vhost-user support : NO + vhost-user-crypto support : NO + vhost-user-blk server support: NO + vhost-vdpa support : NO + build guest agent : NO + + Compilation + host CPU : aarch64 + host endianness : little + C compiler : cc + Host C compiler : cc + C++ compiler : c++ + Objective-C compiler : clang + CFLAGS : -O2 -g + CXXFLAGS : -O2 -g + OBJCFLAGS : -O2 -g + QEMU_CFLAGS : -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong + QEMU_CXXFLAGS : -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong + QEMU_OBJCFLAGS : -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end + QEMU_LDFLAGS : -fstack-protector-strong + profiler : NO + link-time optimization (LTO) : NO + PIE : NO + static build : NO + malloc trim support : NO + membarrier : NO + debug stack usage : NO + mutex debugging : NO + memory allocator : system + avx2 optimization : NO + avx512f optimization : NO + gprof enabled : NO + gcov : NO + thread sanitizer : NO + CFI support : NO + strip binaries : NO + sparse : NO + mingw32 support : NO + + Targets and accelerators + KVM support : NO + HAX support : NO + HVF support : NO + WHPX support : NO + NVMM support : NO + Xen support : NO + TCG support : YES + TCG backend : native (aarch64) + TCG plugins : YES + TCG debug enabled : NO + target list : x86_64-softmmu + default devices : YES + out of process emulation : NO + vfio-user server : NO + + Block layer support + coroutine backend : sigaltstack + coroutine pool : YES + Block whitelist (rw) : + Block whitelist (ro) : + Use block whitelist in tools : NO + VirtFS support : YES + build virtiofs daemon : NO + Live block migration : YES + replication support : YES + bochs support : YES + cloop support : YES + dmg support : YES + qcow v1 support : YES + vdi support : YES + vvfat support : YES + qed support : YES + parallels support : YES + FUSE exports : NO + VDUSE block exports : NO + + Crypto + TLS priority : NORMAL + GNUTLS support : NO + libgcrypt : NO + nettle : NO + AF_ALG support : NO + rng-none : NO + Linux keyring : NO + + Dependencies + Cocoa support : YES + vmnet.framework support : YES + SDL support : NO + SDL image support : NO + GTK support : NO + pixman : YES 0.42.2 + VTE support : NO + slirp support : NO + libtasn1 : NO + PAM : YES + iconv support : YES + curses support : YES + virgl support : NO + blkio support : NO + curl support : YES 7.84.0 + Multipath support : NO + PNG support : NO + VNC support : YES + VNC SASL support : YES + VNC JPEG support : NO + CoreAudio support : YES + JACK support : NO + brlapi support : NO + vde support : NO + netmap support : NO + l2tpv3 support : NO + Linux AIO support : NO + Linux io_uring support : NO + ATTR/XATTR support : NO + RDMA support : NO + PVRDMA support : NO + fdt support : internal + libcap-ng support : NO + bpf support : NO + spice protocol support : NO + rbd support : NO + smartcard support : NO + U2F support : NO + libusb : NO + usb net redir : NO + OpenGL support (epoxy) : NO + GBM : NO + libiscsi support : NO + libnfs support : NO + seccomp support : NO + GlusterFS support : NO + TPM support : YES + libssh support : NO + lzo support : NO + snappy support : NO + bzip2 support : YES + lzfse support : NO + zstd support : NO + NUMA host support : NO + capstone : NO + libpmem support : NO + libdaxctl support : NO + libudev : NO + FUSE lseek : NO + selinux : NO + + User defined options + Native files : config-meson.cross + prefix : /usr/local + b_pie : false + vfio_user_server : disabled + +Found ninja-1.11.1 at /opt/homebrew/bin/ninja +Running postconf script '/opt/homebrew/opt/python@3.10/bin/python3.10 /Users/xxx/qemu/scripts/symlink-install-tree.py' +``` + + +With `make` I got: + +``` +changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""... + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc +[1/75] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""... + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc +[1/75] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""... +/opt/homebrew/bin/ninja build.ninja && touch build.ninja.stamp +ninja: no work to do. +/opt/homebrew/bin/python3 -B /Users/xxx/qemu/meson/meson.py introspect --targets --tests --benchmarks | /opt/homebrew/bin/python3 -B scripts/mtest2make.py > Makefile.mtest + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc +[1/2455] Generating config-poison.h with a custom command (wrapped by meson to capture output) +[2/2455] Compiling C object libfdt.a.p/dtc_libfdt_fdt.c.o +[3/2455] Compiling C object libfdt.a.p/dtc_libfdt_fdt_ro.c.o +[4/2455] Compiling C object libfdt.a.p/dtc_libfdt_fdt_wip.c.o +[5/2455] Compiling C object libfdt.a.p/dtc_libfdt_fdt_sw.c.o +... (no error) +[2455/2455] Linking target tests/qtest/readconfig-test +changing dir to build for /Library/Developer/CommandLineTools/usr/bin/make ""... + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc +[1/48] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +[2/34] Generating tests/include/QAPI test (include) with a custom command +``` diff --git a/results/classifier/118/permissions/1414466 b/results/classifier/118/permissions/1414466 new file mode 100644 index 00000000..d86d3a4b --- /dev/null +++ b/results/classifier/118/permissions/1414466 @@ -0,0 +1,216 @@ +permissions: 0.914 +semantic: 0.901 +register: 0.894 +user-level: 0.888 +debug: 0.884 +virtual: 0.871 +mistranslation: 0.868 +assembly: 0.862 +network: 0.861 +peripherals: 0.861 +device: 0.850 +hypervisor: 0.840 +PID: 0.838 +graphic: 0.830 +arm: 0.826 +kernel: 0.820 +boot: 0.819 +architecture: 0.817 +vnc: 0.811 +risc-v: 0.808 +files: 0.803 +KVM: 0.803 +performance: 0.777 +TCG: 0.774 +socket: 0.728 +VMM: 0.726 +ppc: 0.707 +x86: 0.675 +i386: 0.639 + +-net user,hostfwd=... is not working + +QEMU version: git a46b3aaf6bb038d4f6f192a84df204f10929e75c + + /opt/qemu.git/bin/qemu-system-aarch64 --version +QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard + +Hosts: +ovs - host machine (Ubuntu 14.04.1, x86_64) +debian8-arm64 - guest + +Guest start: +user@ovs:~$ /opt/qemu.git/bin/qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic -smp 1 -m 512 -kernel vmlinuz-run -initrd initrd-run.img -append "root=/dev/sda2 console=ttyAMA0" -global virtio-blk-device.scsi=off -device virtio-scsi-device,id=scsi -drive file=debian8-arm64.img,id=rootimg,cache=unsafe,if=none -device scsi-hd,drive=rootimg -netdev user,id=unet -device virtio-net-device,netdev=unet -net user,hostfwd=tcp:127.0.0.1:1122-:22 + +root@debian8-arm64:~# netstat -ntplu | grep ssh +tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 410/sshd +tcp6 0 0 :::22 :::* LISTEN 410/sshd + +(no firewall in guest vm) + +user@ovs:~$ netstat -ntplu | grep 1122 +tcp 0 0 127.0.0.1:1122 0.0.0.0:* LISTEN 18722/qemu-system-a + +user@ovs:~$ time ssh user@127.0.0.1 -p 1122 +ssh_exchange_identification: read: Connection reset by peer + +real 1m29.341s +user 0m0.005s +sys 0m0.000s + +Inside guest vm sshd works fine: +root@debian8-arm64:~# ssh user@127.0.0.1 -p 22 +user@127.0.0.1's password: +.... +user@debian8-arm64:~$ exit +logout +Connection to 127.0.0.1 closed. + +root@debian8-arm64:~# ssh user@10.0.2.15 -p 22 +user@10.0.2.15's password: +... +user@debian8-arm64:~$ exit +logout +Connection to 10.0.2.15 closed. + +Also happens on Ubuntu 16.04.1 64-bit with QEMU 1:2.5+dfsg-5ubuntu10.4. I have the following settings added to instance xml config: + +<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + + <qemu:commandline> + <qemu:arg value='-net'/> + <qemu:arg value='user,hostfwd=tcp::2222-:22'/> + </qemu:commandline> + +It looks like forwarding does not happen at all. When I try to connect to guest instance, I get exactly the same results regardless of whether sshd is running in that instance or not. + +I think this is not a bug, but you are using the command line parameters in a wrong way. When you use "-net user,hostfwd=tcp:127.0.0.1:1122-:22" you are creating a *new*, second host network device which is not connected to the guest NIC device that you specified. Please try to avoid mixing "-net" and "-netdev" options. You should rather do something like this instead: + + -netdev user,id=unet,hostfwd=tcp:127.0.0.1:1122-:22 -device virtio-net-device,netdev=unet + + +Doesn't work even with proper hostfwd +Doesn't work even with `-redir` + +$ qemu-system-x86_64 -machine type=pc,accel=kvm -netdev user,id=user.0,hostfwd=tcp::2851-:22 -display sdl -cpu host -smp cpus=2 -device rtl8139,netdev=user.0 -cdrom /home/kit/git/packer-xenserver/packer_cache/57f4a00eef5b4d4157f20847e586e5ef2a503ee05c83c9296c08fd0c2f0c8e4f.iso -boot once=d -vnc 127.0.0.1:19 -name XenServer62 -m 2048M -drive file=output-qemu/XenServer62,if=scsi,cache=writeback,discard=ignore,format=qcow2 + + + +Redirect does happen, but no packets appear on guest interface: checked by iptables rule for `NEW` on `tcpport 22` inside guest. + +On host: + +$ sudo lsof -itcp | grep 2851 +packer 24233 kit 6u IPv4 1532725 0t0 TCP localhost:52822->localhost:2851 (ESTABLISHED) +qemu-syst 24286 kit 12u IPv4 1530169 0t0 TCP *:2851 (LISTEN) +qemu-syst 24286 kit 21u IPv4 1575945 0t0 TCP localhost:2851->localhost:52820 (CLOSE_WAIT) +qemu-syst 24286 kit 22u IPv4 1532726 0t0 TCP localhost:2851->localhost:52822 (ESTABLISHED) +qemu-syst 24286 kit 23u IPv4 1532645 0t0 TCP localhost:2851->localhost:52812 (CLOSE_WAIT) +qemu-syst 24286 kit 24u IPv4 1532646 0t0 TCP localhost:2851->localhost:52814 (CLOSE_WAIT) + + +Do we got any solution for this issue ? + +I am seeing similar issue for qemu-system-arm, I have tried with "-nic user,model=virtio-net-pci,hostfwd=tcp:127.0.0.1:31258-:22,hostfwd=tcp:127.0.0.1:47175-:443,hostname=xxx.com" and also with "-net nic -net user,hostfwd=tcp:127.0.0.1:45276-:22,hostfwd=tcp:127.0.0.1:52541-:443,hostname=hostname=xxx.com" + +Is this issue resolved.? + + +Finally I found what was the issue. in the /etc/ssh/sshd_config after commenting the below lines I am able to ssh to the vm. +# grep -i LISTEN /etc/ssh/sshd_config +#ListenAddress 127.0.0.1 +#ListenAddress :: +# +check your sshd config. + +So is this now working for everybody with the correct ssh config (maybe also check your firewall settings)? Could we close this ticket nowadays? Or is somebody still having trouble? + +[Expired for QEMU because there has been no activity for 60 days.] + +Hello, I'm also experiencing such a problem, using qemu-system-x86_64 (hence the retitling of this issue). More information and output is available at http://issues.guix.gnu.org/48739, but basically with the following QEMU command used to run a VM: + +/gnu/store/vbjfas8smw260r0qw1d5bbnh5hz08haz-qemu-5.2.0/bin/qemu-system-x86_64 -kernel /gnu/store/0fylx9z8lzyrbdivqa2jzn574gk8lcjv-linux-libre-5.12.7/bzImage -initrd /gnu/store/76ikiyg6arhd40pmq6yyi0vgdszfl08w-system/initrd -append "--root=/dev/vda1 --system=/gnu/store/76ikiyg6arhd40pmq6yyi0vgdszfl08w-system --load=/gnu/store/76ikiyg6arhd40pmq6yyi0vgdszfl08w-system/boot modprobe.blacklist=usbmouse,usbkbd quiet" -enable-kvm -no-reboot -object rng-random,filename=/dev/urandom,id=guixsd-vm-rng -device virtio-rng-pci,rng=guixsd-vm-rng -virtfs local,path="/gnu/store",security_model=none,mount_tag="TAGjoptajej2oynju6yvboauz7pl6uj" -vga std -drive file=/gnu/store/gj50g71n2b7xa2s9lgcfijprvr4vj66y-qemu-image,if=virtio,cache=writeback,werror=report,readonly -m 512 -nic user,hostfwd=tcp::3333-:22 + +Trying to connect to the VM which has its sshd_config set to: +Port 22 +PermitRootLogin yes +PermitEmptyPasswords yes +PasswordAuthentication yes +PubkeyAuthentication yes +X11Forwarding no +AllowAgentForwarding yes +AllowTcpForwarding yes +GatewayPorts no +PidFile /var/run/sshd.pi +ChallengeResponseAuthentication no +UsePAM yes +PrintLastLog yes +LogLevel DEBUG +AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 /etc/ssh/authorized_keys.d/%u +Subsytsem sftp internal-sftp + +The SSH client would hang with its last debug output being: + +debug1: Local version string SSH-2.0-OpenSSH_8.6 + +Inside the guest, /var/log/secure doesn't show any activity so itd oesn't seem to be reached. + +Ideas? + + +Here's what `tcpdump -i lo` reports during attempting the SSH access: + +17:09:30.573545 IP localhost.55526 > localhost.3333: Flags [S], seq 1198531632, win 65495, options [mss 65495,sackOK,TS val 1662149852 ecr 0,nop,wscale 7], length 0 +17:09:30.573569 IP localhost.3333 > localhost.55526: Flags [S.], seq 476868813, ack 1198531633, win 65483, options [mss 65495,sackOK,TS val 1662149852 ecr 1662149852,nop,wscale 7], length 0 +17:09:30.573588 IP localhost.55526 > localhost.3333: Flags [.], ack 1, win 512, options [nop,nop,TS val 1662149852 ecr 1662149852], length 0 +17:09:30.574162 IP localhost.55526 > localhost.3333: Flags [P.], seq 1:22, ack 1, win 512, options [nop,nop,TS val 1662149853 ecr 1662149852], length 21 +17:09:30.574176 IP localhost.3333 > localhost.55526: Flags [.], ack 22, win 512, options [nop,nop,TS val 1662149853 ecr 1662149853], length 0 +17:09:35.127136 IP localhost.3333 > localhost.55518: Flags [R.], seq 1, ack 1, win 512, options [nop,nop,TS val 1662154406 ecr 1662125014], length 0 + + +That's rather embarrassing, but the problem with my VM was that it was lacking networking support. I turned this (too) minimal example of a Guix System: + +;;; file: os.scm +(use-modules (gnu services ssh) + (gnu system) + (gnu tests)) + +(simple-operating-system + (service openssh-service-type + (openssh-configuration + (permit-root-login #t) + (allow-empty-passwords? #t) + (log-level 'debug)))) + +Into: +;;; file: os.scm +(use-modules (gnu services networking) + (gnu services ssh) + (gnu system) + (gnu tests)) + +(simple-operating-system + (service dhcp-client-service-type) + (service openssh-service-type + (openssh-configuration + (permit-root-login #t) + (allow-empty-passwords? #t) + (log-level 'debug)))) + +After which using the '-nic user,hostfwd=tcp::3333-:22' allowed me to SSH to localhost port 3333 successfully. Closing! + +I have had the same problem, I tried logging into a buildroot image that was started using the following command line: + + qemu-system-i386 -drive file=output/images/disk.img,format=raw,index=0,media=disk -vga std -nic user,ipv6=off,model=e1000,mac=10:10:10:10:10:10,hostfwd=tcp::4000-:22 + +The ssh connection was picked up, but nothing happened. The problem was that the network device was not brought up! I added the following to /etc/network/interfaces + + auto eth0 + iface eth0 inet dhcp + +And voila, I can use + + ssh username@localhost -p 4000 + +to log into the machine using ssh. + diff --git a/results/classifier/118/permissions/1421 b/results/classifier/118/permissions/1421 new file mode 100644 index 00000000..9b7f2d6e --- /dev/null +++ b/results/classifier/118/permissions/1421 @@ -0,0 +1,49 @@ +permissions: 0.976 +graphic: 0.843 +device: 0.804 +debug: 0.803 +arm: 0.769 +kernel: 0.744 +architecture: 0.742 +performance: 0.739 +ppc: 0.661 +semantic: 0.534 +peripherals: 0.474 +vnc: 0.443 +PID: 0.401 +socket: 0.372 +boot: 0.317 +risc-v: 0.311 +network: 0.296 +user-level: 0.271 +VMM: 0.263 +register: 0.256 +virtual: 0.245 +x86: 0.244 +assembly: 0.221 +mistranslation: 0.200 +hypervisor: 0.182 +files: 0.161 +TCG: 0.147 +KVM: 0.028 +i386: 0.016 + +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/118/permissions/1424237 b/results/classifier/118/permissions/1424237 new file mode 100644 index 00000000..14ad0445 --- /dev/null +++ b/results/classifier/118/permissions/1424237 @@ -0,0 +1,86 @@ +permissions: 0.888 +graphic: 0.850 +register: 0.847 +peripherals: 0.846 +assembly: 0.846 +architecture: 0.835 +virtual: 0.791 +semantic: 0.790 +KVM: 0.789 +vnc: 0.779 +device: 0.775 +debug: 0.770 +hypervisor: 0.769 +socket: 0.759 +mistranslation: 0.754 +arm: 0.754 +PID: 0.751 +ppc: 0.744 +kernel: 0.743 +VMM: 0.734 +network: 0.715 +performance: 0.691 +boot: 0.687 +files: 0.661 +risc-v: 0.637 +user-level: 0.634 +TCG: 0.618 +x86: 0.590 +i386: 0.332 + +missing manpage for bridge.conf + +There's currently no (easy) way to figure out the form of content of `/etc/qemu/bridge.conf`. Some howtos (e.g. https://wiki.archlinux.org/index.php/QEMU#Bridged_networking_using_qemu-bridge-helper) mention `bridge.conf.sample` which is not available according to `apt-file` and the official wiki at wiki.qemu.org doesn't mention the file at all, it seems necessary, though, because specification of `-net nic -net bridge,br=bridge0` fails with `failed to get mtu of bridge `bridge0': No such device` (can't be investigated further because setup is completely unclear). + +ProblemType: Bug +DistroRelease: Ubuntu 14.10 +Package: qemu 2.1+dfsg-4ubuntu6.4 +Uname: Linux 3.19.0-031900-generic x86_64 +ApportVersion: 2.14.7-0ubuntu8.2 +Architecture: amd64 +CurrentDesktop: Unity +Date: Sat Feb 21 19:39:07 2015 +EcryptfsInUse: Yes +InstallationDate: Installed on 2015-01-26 (25 days ago) +InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + kvm-irqfd-clean S< 0 0 1026 2 0.0 [kvm-irqfd-clean] + qemu-system-x86 Sl+ 0 0 25905 25904 11.9 qemu-system-x86_64 -boot c -hda ubuntu.img -m 2048 -smp 16 -enable-kvm -vnc :0,abc -k de -drive file=/dev/sda14,if=ide -net nic -net bridge,br=bridge0 + kvm-pit/25905 S 0 0 25948 2 0.0 [kvm-pit/25905] +MachineType: LENOVO 20221 +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=de_DE.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-031900-generic root=UUID=ac20c93a-0ec5-445a-98cd-941f0fbc0e50 ro rootflags=subvol=@ +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 07/12/2013 +dmi.bios.vendor: LENOVO +dmi.bios.version: 71CN51WW(V1.21) +dmi.board.asset.tag: No Asset Tag +dmi.board.name: INVALID +dmi.board.vendor: LENOVO +dmi.board.version: 31900003WIN8 STD MLT +dmi.chassis.asset.tag: No Asset Tag +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Lenovo IdeaPad Z500 Touch +dmi.modalias: dmi:bvnLENOVO:bvr71CN51WW(V1.21):bd07/12/2013:svnLENOVO:pn20221:pvrLenovoIdeaPadZ500Touch:rvnLENOVO:rnINVALID:rvr31900003WIN8STDMLT:cvnLENOVO:ct10:cvrLenovoIdeaPadZ500Touch: +dmi.product.name: 20221 +dmi.product.version: Lenovo IdeaPad Z500 Touch +dmi.sys.vendor: LENOVO + + + + +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/113 + + diff --git a/results/classifier/118/permissions/1425 b/results/classifier/118/permissions/1425 new file mode 100644 index 00000000..2b79e012 --- /dev/null +++ b/results/classifier/118/permissions/1425 @@ -0,0 +1,114 @@ +mistranslation: 0.956 +user-level: 0.930 +permissions: 0.929 +device: 0.900 +register: 0.897 +debug: 0.895 +performance: 0.891 +semantic: 0.889 +virtual: 0.889 +boot: 0.877 +peripherals: 0.874 +architecture: 0.872 +files: 0.868 +assembly: 0.868 +arm: 0.864 +graphic: 0.861 +risc-v: 0.849 +PID: 0.844 +network: 0.832 +socket: 0.827 +ppc: 0.826 +VMM: 0.822 +kernel: 0.818 +TCG: 0.811 +KVM: 0.805 +x86: 0.795 +hypervisor: 0.794 +vnc: 0.756 +i386: 0.664 + +Assertion failed in transfer_fifo() +Description of problem: +In transfer_fifo(), fifo32_pop() fails since less than 32 bytes are in the fifo. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio -audio none +writel 0xff070000 0x0f73720a +writel 0xff07003c 0x1f37ee63 +EOF +``` +Additional information: +``` +==31717==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55871da359f0). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1734665286 +INFO: Loaded 1 modules (618606 inline 8-bit counters): 618606 [0x558720b94000, 0x558720c2b06e), +INFO: Loaded 1 PC tables (618606 PCs): 618606 [0x558720222e60,0x558720b93540), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: 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 , *xlnx.zynqmp-can* +This process will fuzz the following MemoryRegions: + * xlnx.zynqmp-can[1] (size 84) + * xlnx.zynqmp-can[0] (size 84) + * xlnx.zynqmp-can[1] (size 84) + * xlnx.zynqmp-can[0] (size 84) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff070000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff070000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff060000 +0x84, 4,4 + * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff060000 +0x84, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 491Mb +Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can-crash-97ef02583c679111ba6ad823f573f139fac7c72e +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: ../util/fifo8.c:62: uint8_t fifo8_pop(Fifo8 *): Assertion `fifo->num > 0' failed. +==31717== ERROR: libFuzzer: deadly signal + #0 0x558718e0e10e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x558718d5cd81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x558718d35cb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x558718d35d82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x558718d35d82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f3ad4eba41f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f3ad4ccc00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f3ad4ccc00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f3ad4cab858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f3ad4cab728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f3ad4cbcfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55871d6eeac9 in fifo8_pop /root/videzzo/videzzo_qemu/qemu/build-san-6/../util/fifo8.c:62:5 + #12 0x55871a33f303 in fifo32_pop /root/videzzo/videzzo_qemu/qemu/include/qemu/fifo32.h:137:17 + #13 0x55871a334bb5 in transfer_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/can/xlnx-zynqmp-can.c:455:23 + #14 0x55871a32d4c0 in can_tx_post_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/can/xlnx-zynqmp-can.c:830:9 + #15 0x558719393dcb in register_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/register.c:122:9 + #16 0x558719397de8 in register_write_memory /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/register.c:203:5 + #17 0x55871c9e9073 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #18 0x55871c9e89b1 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #19 0x55871c9e72d6 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #20 0x55871ca7548e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #21 0x55871ca635cb in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #22 0x55871ca63088 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #23 0x558718e4e0cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1081:5 + #24 0x558718e4c544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1222:28 + #25 0x55871da313af in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #26 0x55871da2872b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #27 0x55871da28600 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #28 0x558718e5510c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1497:12 + #29 0x55871da35c92 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #30 0x558718d36826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #31 0x558718d19454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #32 0x558718d243fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #33 0x558718d109e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #34 0x7f3ad4cad082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #35 0x558718d10a3d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can+0x3291a3d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/118/permissions/1497204 b/results/classifier/118/permissions/1497204 new file mode 100644 index 00000000..d3d5d388 --- /dev/null +++ b/results/classifier/118/permissions/1497204 @@ -0,0 +1,90 @@ +permissions: 0.853 +semantic: 0.841 +virtual: 0.771 +graphic: 0.770 +user-level: 0.764 +TCG: 0.738 +peripherals: 0.730 +hypervisor: 0.721 +device: 0.707 +register: 0.701 +ppc: 0.698 +PID: 0.694 +architecture: 0.689 +debug: 0.684 +assembly: 0.683 +arm: 0.679 +VMM: 0.667 +risc-v: 0.628 +network: 0.625 +boot: 0.621 +performance: 0.609 +socket: 0.584 +mistranslation: 0.577 +kernel: 0.559 +KVM: 0.534 +vnc: 0.530 +files: 0.497 +x86: 0.493 +i386: 0.360 + +qemu-system-s390x: no SMP support without KVM + +It seems SMP support is not implemented for s390x target, at least when not running under KVM. There is also no error message when starting qemu, it just fails when the kernel tries to bring up the CPUs: + +$ qemu-system-s390x -nographic -smp 8 -kernel s390x/kernel.debian +[ 0.003309] Initializing cgroup subsys cpuset +[ 0.004183] Initializing cgroup subsys cpu +[ 0.004263] Initializing cgroup subsys cpuacct +[ 0.004493] Linux version 3.16.0-4-s390x (<email address hidden>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) +[ 0.005816] setup: Linux is running under KVM in 64-bit mode +[ 0.007231] setup: Max memory size: 128MB +[ 0.032383] Zone ranges: +[ 0.034115] DMA [mem 0x00000000-0x7fffffff] +[ 0.034652] Normal empty +[ 0.034686] Movable zone start for each node +[ 0.034737] Early memory node ranges +[ 0.034847] node 0: [mem 0x00000000-0x07ffffff] +[ 0.047489] PERCPU: Embedded 12 pages/cpu @0000000007f29000 s17920 r8192 d23040 u49152 +[ 0.049613] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32320 +[ 0.049802] Kernel command line: +[ 0.053715] PID hash table entries: 512 (order: 0, 4096 bytes) +[ 0.053993] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) +[ 0.054330] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) +[ 0.061216] Memory: 115912K/131072K available (5701K kernel code, 847K rwdata, 2512K rodata, 452K init, 776K bss, 15160K reserved) +[ 0.062432] Write protected kernel read-only data: 0x100000 - 0x905fff +[ 0.068906] Hierarchical RCU implementation. +[ 0.068934] CONFIG_RCU_FANOUT set to non-default value of 32 +[ 0.068953] RCU dyntick-idle grace-period acceleration is enabled. +[ 0.068989] RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=9. +[ 0.069045] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=9 +[ 0.070043] NR_IRQS:260 +[ 0.094273] console [ttyS1] enabled +[ 0.095630] pid_max: default: 32768 minimum: 301 +[ 0.097792] Security Framework initialized +[ 0.100624] AppArmor: AppArmor disabled by boot time parameter +[ 0.100677] Yama: disabled by default; enable with sysctl kernel.yama.* +[ 0.102466] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) +[ 0.102556] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) +[ 0.116828] Initializing cgroup subsys memory +[ 0.117460] Initializing cgroup subsys devices +[ 0.117678] Initializing cgroup subsys freezer +[ 0.118080] Initializing cgroup subsys net_cls +[ 0.118267] Initializing cgroup subsys blkio +[ 0.118393] Initializing cgroup subsys perf_event +[ 0.118477] Initializing cgroup subsys net_prio +[ 0.119176] ftrace: allocating 17140 entries in 67 pages +XXX unknown sigp: 0xb +XXX unknown sigp: 0xb +XXX unknown sigp: 0xb +[...] +XXX unknown sigp: 0xb +[ 0.211835] cpu: 8 configured CPUs, 0 standby CPUs +XXX unknown sigp: 0xb +XXX unknown sigp: 0xb +[endless stream of messages continues until qemu is killed] + +The XXX message is printed by qemu FWIW. + +QEMU v2.11 has now experimental SMP support (see https://wiki.qemu.org/ChangeLog/2.11#s390 ... commit has been made here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=11b0079cec6b1f46ba76c ). + diff --git a/results/classifier/118/permissions/1499908 b/results/classifier/118/permissions/1499908 new file mode 100644 index 00000000..8e977b75 --- /dev/null +++ b/results/classifier/118/permissions/1499908 @@ -0,0 +1,116 @@ +permissions: 0.914 +register: 0.867 +user-level: 0.867 +assembly: 0.866 +graphic: 0.856 +performance: 0.849 +device: 0.847 +debug: 0.847 +architecture: 0.847 +PID: 0.830 +semantic: 0.822 +virtual: 0.813 +KVM: 0.812 +vnc: 0.803 +hypervisor: 0.788 +network: 0.786 +x86: 0.784 +risc-v: 0.781 +files: 0.772 +arm: 0.770 +socket: 0.770 +mistranslation: 0.757 +boot: 0.756 +ppc: 0.751 +kernel: 0.739 +VMM: 0.710 +peripherals: 0.709 +TCG: 0.629 +i386: 0.406 + +hda sound capture broken with VNC + +QEmu is being used to run the Wine conformance tests in Windows virtual machines. Wine's conformance tests check the behavior of various Windows APIs and verify that they behave as expected. One of the tests checks the behavior of the mmdevapi sound capture APIs. This test works fine on real hardware and also works fine in various QEmu VMs but fails in some others. Further investigation showed that: + + * The mmdevapi:capture tests work on the two Vista VMs. Those use the ac97 sound card and are configured for VNC access to the VM. + + * The mmdevapi:capture tests fail in the Windows 7+ VMs. Those use an hda sound card and are configured for VNC access to the VM (so '-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0' and '-vnc 127.0.0.1:0'). + + * Furthermore configuring the VM for Spice access fixes the mmdevapi:capture test (so replacing -vnc with '-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on'), this even if no client connects to the VM. + +So in effect the -spice and -vnc options change the behavior of the sound device. + +To reproduce this bug: +1. Set up a Windows 7+ VM with an hda sound card ('ich6' in libvirt). +2. Set it up for access using VNC. +3. Copy the attached mmdevapi_test.exe file to it. (*) +4. Run the tests as follows: + mmdevapi_test.exe capture + +If you see these 'Test Failed' lines then the bug is still present: + +capture.c:586: Returned latency: 5.8050 ms +capture.c:178: Test failed: Position 1015 expected 0 +capture.c:186: Wait'ed position 1015 pad 0 flags 1, amount of frames locked: 448 +capture.c:228: Test failed: Position 2167 expected 1463 +capture.c:248: Sleep.1 position 2167 pad 4032 flags 1, amount of frames locked: 448 +capture.c:256: Test failed: Position 2167 expected 1463 +capture.c:292: GetBufferSize 21996 period size 448 +capture.c:302: Overrun position 4215 pad 8960 flags 1, amount of frames locked: 448 +capture.c:308: Test failed: GCP 8960 vs. BufferSize 21996 +capture.c:313: Test failed: Position 4215 gap 2304 +capture.c:329: Cont'ed position 5303 pad 8512 flags 1, amount of frames locked: 448 +capture.c:333: Test failed: Position 5303 expected 4663 +capture.c:334: Test failed: flags 1 +capture.c:353: Restart position 7351 pad 8064 flags 1, amount of frames locked: 448 +capture.c:358: Test failed: Position 7351 expected 5111 +capture.c:359: Test failed: flags 1 + +In case it helps, here is the source of mmdevapi_test.exe: +https://source.winehq.org/git/wine.git/?a=blob;f=dlls/mmdevapi/tests/capture.c;hb=60d1d6f5952e8b5d6fb0327a28c047058851fa70#l178 + + +So far I have confirmed that this bug is present in QEmu as shipped in the following Debian packages: + * qemu-kvm + qemu-system-x86 1:2.1+dfsg-12+deb8u2 + linux-image-3.16.0-4-amd64 3.16.7-ckt11-1+deb8u3 + * qemu-system-x86 1:2.3+dfsg-6a + linux-image-4.1.0-1-amd64 4.1.3-1 + + +(*) As alternatives to using the attached binary you can: +- Compile it from Wine's source. See: + https://source.winehq.org/git/wine.git/ + +- Or download the latest WineTest binary from https://test.winehq.org/builds/winetest-latest.exe + And extract the mmdevapi_test.exe from there: + winetest.exe -x tests + tests\mmdevapi_test.exe capture + + + +On Debian this is still present in QEMU 1:2.7+dfsg-3+b1 with the 4.8.11-1 Linux kernel. +So no change in the past 5 quarters :-( + +So I'm attaching a tar file containing standalone and somewhat minimalist source code for reproducing this issue. Just compile it with MinGW by typing 'make', send the capture.exe binary to the VM and run it. Again if you see 'Test failed' messages the bug is still present. + +As an alternative to compiling the source code yourselves, I have attached the capture.exe binary. + +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/70 + + diff --git a/results/classifier/118/permissions/1500175 b/results/classifier/118/permissions/1500175 new file mode 100644 index 00000000..fef0d99f --- /dev/null +++ b/results/classifier/118/permissions/1500175 @@ -0,0 +1,154 @@ +permissions: 0.861 +mistranslation: 0.860 +debug: 0.847 +semantic: 0.835 +graphic: 0.779 +user-level: 0.764 +device: 0.720 +performance: 0.705 +kernel: 0.702 +virtual: 0.702 +assembly: 0.694 +arm: 0.692 +peripherals: 0.692 +architecture: 0.682 +boot: 0.678 +PID: 0.673 +register: 0.664 +VMM: 0.658 +vnc: 0.628 +TCG: 0.624 +socket: 0.595 +network: 0.588 +ppc: 0.578 +hypervisor: 0.542 +files: 0.539 +risc-v: 0.510 +KVM: 0.413 +x86: 0.280 +i386: 0.248 + +unable to init msix vectors + +Using the latest stable (2.4.0.1) and earlier releases (at least down to 2.3.1), I am unable to run a qemu-system-arm virtualization on a Mac OS X Yosemite machine. QEMU was compiled with --enable-sdl. + +Command line: + +qemu-system-arm -device virtio-net,netdev=user.0 -drive file=pack,if=virtio,cache=writeback,discard=ignore -netdev user,id=user.0,hostfwd=tcp::3499-:22 -cdrom /opt/node-4.1.0/packer/2015-05-05-raspbian-wheezy.img -m 512M -boot once=d -vnc 0.0.0.0:87 -name packer-qemu -machine type=versatilepb -nographic + +Output: + +qemu-system-arm: -device virtio-net,netdev=user.0: unable to init msix vectors to 3 +qemu-system-arm: -drive file=pack,if=virtio,cache=writeback,discard=ignore: unable to init msix vectors to 2 +qemu: fatal: Trying to execute code outside RAM or ROM at 0x10000000 + +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=10000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +FPSCR: 00000000 +[1] 1322 abort qemu-system-arm -device virtio-net,netdev=user.0 -drive -netdev -cdrom -m + +The "unable to init msix vectors" message is just a warning, and is harmless -- it is expected for the ARM boards. (There's a patch around that suppresses the incorrect warning but unfortunately it didn't get into 2.4.) + +Your actual problem is that you haven't specified either a guest kernel (via -kernel) or a firmware image (via a suitable flash drive command). This means that QEMU executes zeroes (which are nop instructions) from its start at address 0 all the way to the end of RAM and then stops because we can't execute out of device registers. (This is approximately what real hardware would do if you booted it with an uninitialized ROM.) + +I suggest you provide QEMU with a suitable kernel that will work on a versatile PB board. + + +Oh right, stupid mistake then! Never mind. Thanks for pointing this out. + +No problem -- QEMU is unfortunately not as clear as it perhaps could be about what happens in this situation. + +As a sidenote: may I ask why the given command does not work? The IMG should contain a kernel that should be bootable, so there should be no need to specify an extra kernel. + +None of QEMU's ARM boards automatically boot a bios image shipped with QEMU. You must provide one explicitly, or else use the 'built in bootloader" with -kernel. (I'm not aware of any rom image that would work on QEMU versatilepb and load a kernel off a disk image, so in practice -kernel is what you want.) + + +Got it, thanks! + +> Op 29-sep.-2015, om 03:51 heeft Peter Maydell <email address hidden> het volgende geschreven: +> +> None of QEMU's ARM boards automatically boot a bios image shipped with +> QEMU. You must provide one explicitly, or else use the 'built in +> bootloader" with -kernel. (I'm not aware of any rom image that would +> work on QEMU versatilepb and load a kernel off a disk image, so in +> practice -kernel is what you want.) +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1500175 +> +> Title: +> unable to init msix vectors +> +> Status in QEMU: +> Invalid +> +> Bug description: +> Using the latest stable (2.4.0.1) and earlier releases (at least down +> to 2.2.1), I am unable to run a qemu-system-arm virtualization on a +> Mac OS X Yosemite machine. QEMU was compiled with --enable-sdl. +> +> Command line: +> +> qemu-system-arm -device virtio-net,netdev=user.0 -drive +> file=pack,if=virtio,cache=writeback,discard=ignore -netdev +> user,id=user.0,hostfwd=tcp::3499-:22 -cdrom +> /opt/node-4.1.0/packer/2015-05-05-raspbian-wheezy.img -m 512M -boot +> once=d -vnc 0.0.0.0:87 -name packer-qemu -machine type=versatilepb +> -nographic +> +> Output: +> +> qemu-system-arm: -device virtio-net,netdev=user.0: unable to init msix vectors to 3 +> qemu-system-arm: -drive file=pack,if=virtio,cache=writeback,discard=ignore: unable to init msix vectors to 2 +> qemu: fatal: Trying to execute code outside RAM or ROM at 0x10000000 +> +> R00=00000000 R01=00000000 R02=00000000 R03=00000000 +> R04=00000000 R05=00000000 R06=00000000 R07=00000000 +> R08=00000000 R09=00000000 R10=00000000 R11=00000000 +> R12=00000000 R13=00000000 R14=00000000 R15=10000000 +> PSR=400001d3 -Z-- A svc32 +> s00=00000000 s01=00000000 d00=0000000000000000 +> s02=00000000 s03=00000000 d01=0000000000000000 +> s04=00000000 s05=00000000 d02=0000000000000000 +> s06=00000000 s07=00000000 d03=0000000000000000 +> s08=00000000 s09=00000000 d04=0000000000000000 +> s10=00000000 s11=00000000 d05=0000000000000000 +> s12=00000000 s13=00000000 d06=0000000000000000 +> s14=00000000 s15=00000000 d07=0000000000000000 +> s16=00000000 s17=00000000 d08=0000000000000000 +> s18=00000000 s19=00000000 d09=0000000000000000 +> s20=00000000 s21=00000000 d10=0000000000000000 +> s22=00000000 s23=00000000 d11=0000000000000000 +> s24=00000000 s25=00000000 d12=0000000000000000 +> s26=00000000 s27=00000000 d13=0000000000000000 +> s28=00000000 s29=00000000 d14=0000000000000000 +> s30=00000000 s31=00000000 d15=0000000000000000 +> FPSCR: 00000000 +> [1] 1322 abort qemu-system-arm -device virtio-net,netdev=user.0 -drive -netdev -cdrom -m +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1500175/+subscriptions + + + diff --git a/results/classifier/118/permissions/1505 b/results/classifier/118/permissions/1505 new file mode 100644 index 00000000..78fc45c3 --- /dev/null +++ b/results/classifier/118/permissions/1505 @@ -0,0 +1,31 @@ +permissions: 0.955 +peripherals: 0.784 +network: 0.714 +device: 0.697 +performance: 0.643 +arm: 0.536 +ppc: 0.529 +VMM: 0.415 +boot: 0.362 +semantic: 0.361 +TCG: 0.309 +mistranslation: 0.286 +socket: 0.283 +hypervisor: 0.267 +KVM: 0.252 +register: 0.247 +PID: 0.239 +virtual: 0.234 +vnc: 0.212 +i386: 0.210 +graphic: 0.193 +x86: 0.189 +architecture: 0.162 +risc-v: 0.140 +kernel: 0.120 +assembly: 0.071 +files: 0.067 +debug: 0.030 +user-level: 0.010 + +guest agent: add --allow-rpcs / whitelist mode diff --git a/results/classifier/118/permissions/1509336 b/results/classifier/118/permissions/1509336 new file mode 100644 index 00000000..81053749 --- /dev/null +++ b/results/classifier/118/permissions/1509336 @@ -0,0 +1,97 @@ +permissions: 0.870 +debug: 0.858 +user-level: 0.807 +device: 0.792 +peripherals: 0.782 +vnc: 0.781 +architecture: 0.771 +virtual: 0.768 +assembly: 0.754 +arm: 0.753 +TCG: 0.751 +boot: 0.746 +VMM: 0.739 +KVM: 0.731 +PID: 0.730 +kernel: 0.725 +network: 0.723 +semantic: 0.719 +performance: 0.716 +risc-v: 0.701 +graphic: 0.700 +socket: 0.681 +files: 0.674 +ppc: 0.664 +register: 0.619 +x86: 0.584 +hypervisor: 0.528 +i386: 0.416 +mistranslation: 0.380 + +USB passthru not work with Mac OS X El Capitan + +QEMU emulator version 2.4.50 with kernel kvm module from linux kernel 3.16.0 or 4.2.3 + +Since upgrading from Yosemite to El Capitan - USB passthru does not work. Note USB passthru worked perfectly with Maverick and Yosemite. I attempt to use different USB hosts. I found a patch for widows xp that had similar problem the patch was applied in 2012. Note NO problems with USB passthru with windows or linux clients. If it matters the devices that I am trying to passthru USB are smartcard reader and webcam. The devices are present in El Capitan but do not function. + +These are the massages from loading the VM (El Capitan). The first two lines are from the clover bootloader. The ehci warnings are generated when loading Mac Os X El Capitan. + +QEMU 2.4.50 monitor - type 'help' for more information +### These messages below started when using the clover bootloader and occur when loading El Capitan, Maverick or Yosemite. +### The bootloader is Clover version 3292 +(qemu) ehci: PERIODIC list base register set while periodic schedule + is enabled and HC is enabled +ehci: ASYNC list address register set while async schedule + is enabled and HC is enabled + +#### Below are errors when the guest host (El Capitan) is loading from qemu monitor. The messages below only occur when loading El Capitan. +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC +ehci warning: guest requested more bytes than allowed +processing error - resetting ehci HC + +This is the errors from the guest os - Mac Os X - El Capitan +000000.580358 AppleUSBLegacyRoot@: AppleUSBLegacyRoot::init: enabling legacy matching +000001.803455 AppleUSBEHCIPCI@fd000000: AppleUSBEHCI::WaitForAsyncSchedule: USBC +MD (0x00080020) and USBSTS (0x00001000) did not synchronize + +the following qemu command has worked flawlessly with Yosemite and Maverick. +qemu-system-x86_64 -enable-kvm -m 4096 -cpu core2duo -machine q35 \ +-bios /usr/local/share/qemu/bios.bin \ +-name "El Capitan" \ +-mem-path /hugetlbfs \ +-rtc base=utc,clock=vm,driftfix=slew \ +-balloon none \ +-parallel none \ +-smp 4,sockets=1,cores=2,threads=2 \ +-boot menu=on \ +-usb -device usb-kbd -device usb-mouse \ +-device usb-host,vendorid=0x0455,productid=0x0777 \ +-vga std \ +-monitor stdio \ +-device isa-applesmc,osk="youknowwhatitis" \ +-smbios type=2 \ +-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 \ +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-device e1000-82545em,netdev=hub0port0,id=mac_vnet0,mac=62:64:44:34:64:54 \ +-netdev bridge,id=hub0port0,br=br0,helper=/usr/local/libexec/qemu-bridge-helper \ +-device ide-drive,bus=ide.0,drive=elcapitan \ +-drive id=elcapitan,format=qcow2,if=none,file=./iElCapitan.qcow2 + +If anything else I can do to debug the problem please let me know. + +My problem was solved by using the UEFI boot loader and I followed the instructions at the following links: + +https://github.com/tianocore/tianocore.github.io/wiki/How-to-build-OVMF + +http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt + +Also remove the "-bios" option above and added the following options. + +-drive if=pflash,format=raw,readonly,file=OVMF_CODE.fd \ +-drive if=pflash,format=raw,file=OVMF_VARS.fd \ + +Also changed clover to boot with UEFI only. Anyway that has used clover will know how to change this option. + diff --git a/results/classifier/118/permissions/1516408 b/results/classifier/118/permissions/1516408 new file mode 100644 index 00000000..e64e3f15 --- /dev/null +++ b/results/classifier/118/permissions/1516408 @@ -0,0 +1,146 @@ +permissions: 0.888 +assembly: 0.873 +arm: 0.873 +risc-v: 0.872 +performance: 0.872 +socket: 0.872 +semantic: 0.868 +device: 0.867 +register: 0.866 +peripherals: 0.865 +user-level: 0.861 +hypervisor: 0.856 +virtual: 0.848 +PID: 0.844 +mistranslation: 0.841 +graphic: 0.839 +TCG: 0.837 +architecture: 0.834 +debug: 0.825 +kernel: 0.822 +vnc: 0.804 +boot: 0.796 +x86: 0.773 +ppc: 0.772 +VMM: 0.767 +KVM: 0.746 +network: 0.736 +files: 0.664 +i386: 0.592 + +sh4: Unsupported syscall: 186 + +Hello! + +I'm currently testing qemu as a possibility to set up a buildd for the Debian sh4 port. + +I set up qemu and an sh4 chroot as described in the Debian Wiki [1]. This seems to be working mostly fine (besides the fact that qemu segfaults on an amd64 host while it runs fine on an i386 host, I'll file a separate bug report). However, when installing python3.4 in the sh4 chroot, qemu repeatedly printed an error message about an unimplemented syscall: 186: + +qemu: Unsupported syscall: 186 + +From the source code in linux-user/sh4/syscall_nr.h it's apparent that 186 is defined as + +#define TARGET_NR_sigaltstack 186 + +Looking at the implementation part, it becomes obvious that this syscall is not enabled for sh4: + +#if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \ + defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_ALPHA) || \ + defined(TARGET_M68K) || defined(TARGET_S390X) || defined(TARGET_OPENRISC) + ret = do_sigaltstack(arg1, arg2, get_sp_from_cpustate((CPUArchState *)cpu_env)); + break; +#else + goto unimplemented; +#endif + +Is there any particular reason why TARGET_NR_sigaltstack is not enabled on sh4? If not, could you enable it? + +Thanks, +Adrian + +> [1] https://wiki.debian.org/QemuUserEmulation + +I have enabled this syscall in the source code now and performing a test build and run and will report back. + +Furthermore, looking at the kernel sources, both the 32-bit and 64-bit Linux SH-specific code defines "sigaltstack" as syscall 186: + +> https://github.com/torvalds/linux/blob/master/arch/sh/kernel/syscalls_32.S#L205 +> https://github.com/torvalds/linux/blob/master/arch/sh/kernel/syscalls_64.S#L209 + +The whole syscall also doesn't appear to be architecture-specific after reading the manpage for sigaltstack. Is it? + +Will report back after further testing. + +Thanks, +Adrian + +Hello! + +The attached patch enables the sigaltstack syscall in qemu-sh4. + +The following minimal test code verifies that sigaltstack works as expected: + +============================================================= + +#include <setjmp.h> +#include <signal.h> +#include <stdlib.h> +#include <stdio.h> + +jmp_buf exit_jmp; + +void handler(int x) +{ + longjmp(exit_jmp, 1); +} + +int f(void) +{ + return f(); +} + +int main(void) +{ + stack_t sigstack; + sigstack.ss_sp = malloc(1024*1024); + sigstack.ss_size = 1024*1024; + sigstack.ss_flags = 0; + sigaltstack(&sigstack, NULL); + struct sigaction sa; + sa.sa_handler = handler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = SA_ONSTACK; + sigaction(SIGSEGV, &sa, NULL); + if (setjmp(exit_jmp) == 0) + { + return f(); + } + puts("recovered"); + return 0; +} + +============================================================= + +Without sigaltstack enabled, this code produces a segmentation fault. With sigaltstack enabled, it prints out "recovered". + +Also posted on qemu-devel mailing list: + +> http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg04300.html +> http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg04301.html + +Cheers, +Adrian + +Ping. Any chance to get this merged? + +I don't think this patch could have any particular bad impact on qemu as it affects the sh4 emulation only and so far my tests with building packages on qemu-sh4 have shown no regressions. But with the patch, sigaltstack now works fine on sh4 which the above testcase also positively has proven. + +Having this bug and #1254824 fixed would help the sh4 porters in Debian quite a lot as qemu-sh4 can be used to set up a virtual buildd for this architecture. + +Adrian + +> [1] https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824 + +Looks like we fixed this in commit c0d35736323e5b in December, which was released as part of QEMU 2.6. + + diff --git a/results/classifier/118/permissions/1523811 b/results/classifier/118/permissions/1523811 new file mode 100644 index 00000000..f7bd21a9 --- /dev/null +++ b/results/classifier/118/permissions/1523811 @@ -0,0 +1,136 @@ +permissions: 0.893 +device: 0.877 +debug: 0.873 +register: 0.861 +virtual: 0.858 +hypervisor: 0.852 +performance: 0.847 +PID: 0.847 +architecture: 0.845 +risc-v: 0.842 +assembly: 0.842 +network: 0.835 +arm: 0.834 +graphic: 0.829 +VMM: 0.829 +ppc: 0.817 +user-level: 0.815 +semantic: 0.815 +TCG: 0.814 +vnc: 0.811 +files: 0.809 +socket: 0.809 +KVM: 0.803 +peripherals: 0.783 +x86: 0.775 +kernel: 0.762 +boot: 0.715 +i386: 0.658 +mistranslation: 0.633 + +USB assert failure on dev-storage.c + +On executing the attached python script in the guest OS, QEMU dies with assert failure: + +[run python script in guest root shell] +# python a.py + +[host message] +qemu-system-x86_64: hw/usb/dev-storage.c:445: usb_msd_handle_data: Assertion `le32_to_cpu(s->csw.residue) == 0' failed. +Aborted (core dumped) + + +When I detach the kernel driver and send CBW and reattach it again, without conforming to the command/data/status protocol, QEMU dies. +I think this is due to misimplementation of Command/Data/Status protocol in Bulk-only transfer. +This kind of assert failure can be misused by malwares to avoid being analyzed by terminating only in the virtual environments and still execute the malicious code in real machines. +Before running python script, make sure to change a.py that it should points to usb mass storage's vid and pid. + +QEMU was running on these environment : +[CPU model] Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz +[qemu version] QEMU 2.5.0-rc2 (compiled from source, gcc 4.8.4) +[host info] Ubuntu 14.04.3, x86_64, 3.19.0-32-generic +[guest info] Ubuntu 14.04.3, x86_64, 3.19.0-28-generic +[QEMU argument] +x86_64-softmmu/qemu-system-x86_64 -hda /media/hdd/img/ubuntu1404.qcow2.5 \ + -m 512 \ + --usbdevice disk:format=qcow2:../usb.img.5 \ + --enable-kvm + + + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (version 2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through nec-usb-xhci emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master, 51db2d7cf26d05a961ec0ee0eb773594b32cc4a1) + +To reproduce the assertion failure, please run the QEMU with the following command line. + +``` + +$ qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -drive if=none,id=stick,file=./usbdisk.img,format=raw -device nec-usb-xhci,id=usb -device usb-storage,bus=usb.0,drive=stick + + +``` + + +``` + +qemu-system-i386: ../hw/usb/dev-storage.c:454: void usb_msd_handle_data(USBDevice *, USBPacket *): Assertion `le32_to_cpu(s->csw.residue) == 0' failed. + +#0 0x00007ffff1a60fb7 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007ffff1a62921 in __GI_abort () at abort.c:79 +#2 0x00007ffff1a5248a in __assert_fail_base (fmt=0x7ffff1bd9750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x555557518dc0 <.str.30> "le32_to_cpu(s->csw.residue) == 0", file=file@entry=0x5555575189e0 <.str.19> "../hw/usb/dev-storage.c", line=line@entry=0x1c6, function=function@entry=0x555557518e20 <__PRETTY_FUNCTION__.usb_msd_handle_data> "void usb_msd_handle_data(USBDevice *, USBPacket *)") at assert.c:92 +#3 0x00007ffff1a52502 in __GI___assert_fail (assertion=0x555557518dc0 <.str.30> "le32_to_cpu(s->csw.residue) == 0", file=0x5555575189e0 <.str.19> "../hw/usb/dev-storage.c", line=0x1c6, function=0x555557518e20 <__PRETTY_FUNCTION__.usb_msd_handle_data> "void usb_msd_handle_data(USBDevice *, USBPacket *)") at assert.c:101 +#4 0x0000555556299749 in usb_msd_handle_data (dev=<optimized out>, p=<optimized out>) at ../hw/usb/dev-storage.c:454 +#5 0x00005555563120b3 in usb_device_handle_data (dev=0x62300000a900, p=0x611001da3fc8) at ../hw/usb/bus.c:180 +#6 0x000055555610ac07 in usb_process_one (p=0x611001da3fc8) at ../hw/usb/core.c:406 +#7 0x0000555556109d8f in usb_handle_packet (dev=0x62300000a900, p=<optimized out>) at ../hw/usb/core.c:438 +#8 0x000055555687de55 in xhci_submit (xhci=<optimized out>, xfer=<optimized out>, epctx=<optimized out>) at ../hw/usb/hcd-xhci.c:1779 +#9 0x000055555687de55 in xhci_fire_transfer (xhci=<optimized out>, xfer=<optimized out>, epctx=<optimized out>) at ../hw/usb/hcd-xhci.c:1788 +#10 0x000055555687de55 in xhci_kick_epctx (epctx=<optimized out>, streamid=0x0) at ../hw/usb/hcd-xhci.c:1947 +#11 0x000055555688c7f6 in xhci_kick_ep (xhci=<optimized out>, slotid=<optimized out>, epid=<optimized out>, streamid=0x0) at ../hw/usb/hcd-xhci.c:1813 +#12 0x00005555568943b7 in xhci_doorbell_write (ptr=<optimized out>, reg=0x1, val=0x4, size=<optimized out>) at ../hw/usb/hcd-xhci.c:3114 +#13 0x0000555556c6617a in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:491 +#14 0x0000555556c65d96 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) + at ../softmmu/memory.c:552 +#15 0x0000555556c65d96 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#16 0x0000555556fb4b90 in flatview_write_continue (fv=0x6060002bf460, addr=0xfebf2004, attrs=..., ptr=<optimized out>, len=0x4, addr1=0x7fff775fa810, l=<optimized out>, mr=0x7fff74937610) at ../softmmu/physmem.c:2776 +#17 0x0000555556fb9e3d in flatview_write (fv=<optimized out>, addr=<optimized out>, attrs=..., len=0x4, buf=<optimized out>) at ../softmmu/physmem.c:2816 +#18 0x0000555556fb9e3d in subpage_write (opaque=<optimized out>, addr=<optimized out>, value=<optimized out>, len=<optimized out>, attrs=...) at ../softmmu/physmem.c:2482 +#19 0x0000555556c668ff in memory_region_write_with_attrs_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:511 +#20 0x0000555556c65de6 in access_with_adjusted_size (addr=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, mr=<optimized out>, attrs=..., value=<optimized out>, access_fn=<optimized out>) + at ../softmmu/memory.c:552 +#21 0x0000555556c65de6 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1508 +#22 0x0000555556cd2796 in io_writex (iotlbentry=<optimized out>, mmu_idx=<optimized out>, val=<optimized out>, addr=<optimized out>, retaddr=<optimized out>, op=4054192055, env=<optimized out>) at ../accel/tcg/cputlb.c:1425 +#23 0x0000555556cd2796 in store_helper (env=<optimized out>, addr=<optimized out>, val=0x4, oi=<optimized out>, retaddr=<optimized out>, op=MO_32) at ../accel/tcg/cputlb.c:2444 +#24 0x0000555556cd2796 in helper_le_stl_mmu (env=<optimized out>, addr=<optimized out>, val=0x1ca6828, oi=<optimized out>, retaddr=0x7fff97c4ce9f) at ../accel/tcg/cputlb.c:2510 +#25 0x00007fff97c4ce9f in code_gen_buffer () +#26 0x0000555556f3ea44 in cpu_tb_exec (cpu=0x62e000000400, itb=<optimized out>, tb_exit=0x7fff775fbf20) at ../accel/tcg/cpu-exec.c:191 +#27 0x0000555556f40cf4 in cpu_loop_exec_tb (tb=<optimized out>, tb_exit=<optimized out>, cpu=<optimized out>, last_tb=<optimized out>) at ../accel/tcg/cpu-exec.c:672 +#28 0x0000555556f40cf4 in cpu_exec (cpu=0x62e000000400) at ../accel/tcg/cpu-exec.c:797 +#29 0x0000555556c5cd73 in tcg_cpus_exec (cpu=0x62e000000400) at ../accel/tcg/tcg-accel-ops.c:60 +#30 0x0000555556cfd60d in mttcg_cpu_thread_fn (arg=0x62e000000400) at ../accel/tcg/tcg-accel-ops-mttcg.c:70 +#31 0x00005555573f75cf in qemu_thread_start (args=0x6030000d9870) at ../util/qemu-thread-posix.c:521 +#32 0x0000555556022f5f in __asan::AsanThread::ThreadStart(unsigned long, __sanitizer::atomic_uintptr_t*) () +#33 0x00007ffff243e6db in start_thread (arg=0x7fff775ff700) at pthread_create.c:463 +#34 0x00007ffff1b4371f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +``` + + + +Looking at commit 0659879e6e5 ("usb-storage: remove MSDState->residue") +this assert seems a left-over, CSW residue should be irrelevant in CBW +path... +Gerd, can we simply remove it? + +No, we can't. csw.residue is non-zero if the request didn't complete yet (usb_msd_send_status clears it via memset). We *really* should not be in USB_MSDM_CBW state with a non-zero residue. +We need to figure how we end up with this inconsistency. Possibly via usb_msd_handle_reset(). + +https://gitlab.com/qemu-project/qemu/-/commit/39912c14da07a2d + diff --git a/results/classifier/118/permissions/1527765 b/results/classifier/118/permissions/1527765 new file mode 100644 index 00000000..136ddab8 --- /dev/null +++ b/results/classifier/118/permissions/1527765 @@ -0,0 +1,183 @@ +permissions: 0.851 +graphic: 0.848 +debug: 0.822 +assembly: 0.817 +performance: 0.807 +semantic: 0.800 +device: 0.800 +peripherals: 0.799 +arm: 0.788 +virtual: 0.787 +boot: 0.779 +register: 0.777 +KVM: 0.763 +PID: 0.760 +user-level: 0.757 +hypervisor: 0.750 +socket: 0.743 +vnc: 0.735 +risc-v: 0.734 +architecture: 0.729 +VMM: 0.716 +network: 0.716 +files: 0.715 +kernel: 0.702 +TCG: 0.701 +ppc: 0.680 +mistranslation: 0.542 +x86: 0.541 +i386: 0.514 + +sh4: ghc randomly segfaults on qemu-sh4-static + +Hello! + +I am currently in the process of bootstrapping ghc for the Debian sh4 port and ran into a strange problem with qemu-sh4-static which randomly segfaults when running ghc to compile a Haskell source: + +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ls +Main.hi Main.hs Setup.hs ghc-pwd.cabal ghc.mk +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +Bad interface file: /usr/local/lib/sh4-unknown-linux-gnu-ghc-7.10.3/time/dist-install/build/Data/Time/Format/Parse.hi + ghc: panic! (the 'impossible' happened) + (GHC version 7.10.3 for sh4-unknown-linux): + getSymtabName:unknown known-key unique +<<details unavailable>> + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +Linking Main ... +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# + +As seen above, compiling a Haskell source code often results in a segfault but simply by retrying to run ghc over and over again, the compile process will eventually succeed and no segfault occurs. + +I have created a tarball which contains the sh4 chroot from the example above which also includes ghc, gcc and the source code in question (in /root/ghc-7.8.4/utils/ghc-pwd). To test, it's probably a good idea to replace the qemu-sh4-static binary in /usr/bin with a current git snapshot (which I tried but didn't help). + +> http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz + +In case anyone wants to try ghc with their own sh4 chroot, here's my version of ghc: + +> https://people.debian.org/~glaubitz/sh4-unknown-linux-gnu-ghc-7.10.3.tar.gz + +Just extract in the chroot of the sh4 chroot. + +Please note, that it might be advisable on sh4 to apply the patches from these two bug reports as otherwise qemu-sh4-static won't work properly on sh4 and misses syscall 186: + +> https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824 +> https://bugs.launchpad.net/qemu/+bug/1516408 + +The above issue is reproducible with the two patches applied and without. It's also reproducible with both libc6 2.19 and 2.21 in the chroot. Thus, I am currently out of ideas what else to test. + +Cheers, +Adrian + +Thank you for the 611 MB tar.... + +The behavior is a little bit different on my system: + +root@Quad:~# ls +ghc-7.8.4 ghc_7.8.4-9~bpo8+1.dsc +ghc_7.8.4-9~bpo8+1.debian.tar.xz ghc_7.8.4.orig.tar.xz +root@Quad:~# cd ghc-7.8.4/utils/ghc-p +ghc-pkg/ ghc-pwd/ +root@Quad:~# cd ghc-7.8.4/utils/ghc-p +ghc-pkg/ ghc-pwd/ +root@Quad:~# cd ghc-7.8.4/utils/ghc-pwd/ +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ls +Main Main.hi Main.hs Main.o Setup.hs ghc-pwd.cabal ghc.mk +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main +Main Main.hi Main.hs Main.o +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +ghc: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) + +The emulated "tas.b" instruction is not atomic, this is why sometimes the locking fails... + + +Interestingly, cmake also seems to crash in a similar way: + +- Log: https://buildd.debian.org/status/fetch.php?pkg=apt-cacher-ng&arch=sh4&ver=0.8.8-1&stamp=1450985460 +- Log: https://buildd.debian.org/status/fetch.php?pkg=texworks&arch=sh4&ver=0.5~svn1363-6%2Bb1&stamp=1450992669 +- Log: https://buildd.debian.org/status/fetch.php?pkg=x265&arch=sh4&ver=1.8-6&stamp=1450995672 +- Log: https://buildd.debian.org/status/fetch.php?pkg=libwebsockets&arch=sh4&ver=1.6.0-2&stamp=1450997039 + +Maybe those are related? + +Just tested with the latest git snapshot of qemu, still no improvement: + +... +checking for gfind... no +checking for find... /usr/bin/find +checking for sort... /usr/bin/sort +checking for GHC Git commit id... given 4986837f8168cacf95c24fecc84d7b36c47f3c11 +checking version of ghc... 8.0.1 +ghc: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +ghc: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +ghc: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Bootstrapping GHC is a cross compiler. This probably isn't going to work +checking build system type... sh4-unknown-linux-gnu +checking host system type... sh4-unknown-linux-gnu +checking target system type... sh4-unknown-linux-gnu +Build platform inferred as: sh4-unknown-linux +Host platform inferred as: sh4-unknown-linux +Target platform inferred as: sh4-unknown-linux +GHC build : sh4-unknown-linux +GHC host : sh4-unknown-linux +GHC target : sh4-unknown-linux +configure: Building in-tree ghc-pwd +(hangs here) + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1529449 b/results/classifier/118/permissions/1529449 new file mode 100644 index 00000000..ab9af377 --- /dev/null +++ b/results/classifier/118/permissions/1529449 @@ -0,0 +1,225 @@ +permissions: 0.911 +user-level: 0.904 +register: 0.900 +risc-v: 0.897 +semantic: 0.896 +device: 0.895 +assembly: 0.890 +architecture: 0.888 +mistranslation: 0.883 +virtual: 0.881 +debug: 0.879 +arm: 0.867 +network: 0.862 +performance: 0.861 +PID: 0.860 +kernel: 0.853 +graphic: 0.849 +files: 0.844 +vnc: 0.838 +hypervisor: 0.830 +boot: 0.819 +VMM: 0.815 +socket: 0.812 +TCG: 0.808 +peripherals: 0.796 +KVM: 0.788 +ppc: 0.788 +i386: 0.722 +x86: 0.709 + +serial is required for -device nvme + +I am not exactly sure if this is a bug, but I don't see why the option "serial" is required for -device nvme like drive. Truth is it seem to accept random string as its value anyway, if that's the case, couldn't qemu just generate one for it when it's not specified? + +On Mon, Jan 11, 2016 at 05:35:50PM +0100, Markus Armbruster wrote: +> Tom Yan <email address hidden> writes: +> > Public bug reported: +> > +> > I am not exactly sure if this is a bug, but I don't see why the option +> > "serial" should be required for -device nvme like the option "drive". +> > Truth is it seem to accept random string as its value anyway, if that's +> > the case, couldn't qemu just generate one for it when it's not +> > specified? +> +> You should've included a reproducer. Here are mine: +> +> 1. Bad error reporting on missing drive: +> +> $ upstream-qemu -nodefaults -device nvme +> upstream-qemu: -device nvme: Device initialization failed +> +> Expected: error reported like for other devices, e.g. +> +> $ upstream-qemu -nodefaults -device virtio-blk +> upstream-qemu: -device virtio-blk: drive property not set +> +> 2. Bad error reporting on empty drive: +> +> $ upstream-qemu -nodefaults -drive if=none,id=foo -device nvme,drive=foo +> upstream-qemu: -device nvme,drive=foo: Device initialization failed +> +> Expected: error is reported like for other devices, e.g. +> +> $ upstream-qemu -nodefaults -drive if=none,id=foo -device virtio-blk,drive=foo +> upstream-qemu: -device virtio-blk,drive=foo: Device needs media, but drive is empty +> +> 3. Bad handling of missing serial: +> +> $ upstream-qemu -nodefaults -drive if=none,id=foo,file=tmp.qcow2 -device nvme,drive=foo +> upstream-qemu: -device nvme,drive=foo: Device initialization failed +> +> Expected: either default the serial number, like some other devices +> do, or a decent error message. +> +> I recommend to convert the device to realize(), and add the missing +> error_setg(). Keith? + +Requiring a serial was a concious choice to push that responsibility +on the user, but I don't see a problem having the code provide default +serial string if the user does not over ride it. + +If you've multiple nvme devices in your guest, creating the same serial +could cause problems with multipathing if they're basing end device +uniqueness on the serial (some do). If we have the code provide the +serial, perhaps it would be best to make each unique. That's easy enough +to append an incrementing number to the end of the serial. + + +Instead of requiring a serial of arbitrary length/format, I think a WWN/EUI-64 is more useful/important, not to mention that the WWN/EUI-64 can pretty much always be used as the serial at the same time. + +Unlike Linux, Windows consider the WWN/EUI-64 as the "serial": + +"C:\Windows\system32>sg_vpd -i PD1 +Device Identification VPD page: + Addressed logical unit: + designator type: SCSI name string, code set: UTF-8 + SCSI name string: + 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +C:\Windows\system32>sg_vpd -p sn PD1 +Unit serial number VPD page: + Unit serial number: 0000_0000_0000_0000." + +(https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650553/+files/02.PNG) + +UEFI also makes use of the WWN/EUI-64 to generate boot entries for NVMe devices: +https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650554/+files/03.png +https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650555/+files/04.png + + +On 04/28/16 20:07, Tom Yan wrote: +> Instead of requiring a serial of arbitrary length/format, I think a +> WWN/EUI-64 is more useful/important, + +WWN/EUI-64 is not "more important". Section "7.9 Unique Identifier" in +the NVMe spec (Revision 1.2a, October 23, 2015) says that the serial +number is mandatory, while implementing an EUI-64 is optional. Let me +quote it all (emphases mine): + +> 7.9 Unique Identifier +> +> Information is returned in the Identify Controller data structure that +> may be used to construct a unique identifier. Specifically, the PCI +> Vendor ID, *Serial Number*, and Model Number fields when combined +> shall form a globally unique value that identifies the NVM subsystem. +> The mechanism used by the vendor to assign Serial Number and Model +> Number values to ensure uniqueness is *outside the scope* of this +> specification. +> +> An NVM subsystem may contain multiple controllers. All of the +> controllers that make up an NVM subsystem share the same NVM subsystem +> identifier (i.e., PCI Vendor ID, Serial Number, and Model Number). The +> Controller ID (CNTLID) value returned in the Identify Controller data +> structure may be used to uniquely identify a controller within an NVM +> subsystem. The Controller ID value when combined with the NVM +> subsystem identifier forms a globally unique value that identifies the +> controller. The mechanism used by the vendor to assign Controller ID +> values is outside the scope of this specification. +> +> The Identify Namespace data structure contains the IEEE Extended +> Unique Identifier (EUI64) and the Namespace Globally Unique Identifier +> (NGUID) fields. EUI64 is an 8-byte EUI-64 identifier and NGUID is a +> 16-byte identifier based on EUI-64. When creating a namespace, the +> controller specifies a globally unique value in the EUI64 or NGUID +> field (the controller may optionally specify a globally unique value +> in both fields). In cases where the 64-bit EUI64 field is unable to +> ensure a globally unique namespace identifier, the EUI64 field shall +> be cleared to 0h. *When not implemented*, these fields contain a value +> of 0h. + +The QEMU device model conforms to this: + +- The serial number is mandatory, and its generation is unspecified. +(First paragraph quoted.) Accordingly, QEMU forces the user to generate +and provide a serial number. + +- The EUI64 is optional (third paragraph); it shall be zero-filled when +not implemented. QEMU conforms. + +> not to mention that the WWN/EUI-64 +> can pretty much always be used as the serial at the same time. +> +> Unlike Linux, Windows consider the WWN/EUI-64 as the "serial": + +That's Windows's problem. Not the first (and not the last) occasion +where Microsoft interpret a specification creatively. + +> "C:\Windows\system32>sg_vpd -i PD1 +> Device Identification VPD page: +> Addressed logical unit: +> designator type: SCSI name string, code set: UTF-8 +> SCSI name string: +> 8086QEMU NVMe Ctrl 00012BDAC262CF831698 +> +> C:\Windows\system32>sg_vpd -p sn PD1 +> Unit serial number VPD page: +> Unit serial number: 0000_0000_0000_0000." +> +> (https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650553/+files/02.PNG) +> +> UEFI also makes use of the WWN/EUI-64 to generate boot entries for NVMe devices: +> https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650554/+files/03.png +> https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650555/+files/04.png + +The UEFI specification (version 2.6, January 2016) says in "9.3.5.22 NVM +Express namespace messaging device path node": + + Mnemonic: IEEE Extended Unique Identifier + Byte Offset: 8 + Byte Length: 8 + Description: This field contains the IEEE Extended Unique + Identifier (EUI-64). Devices without an EUI-64 value + must initialize this field with a value of 0. + +QEMU conforms. + +The device paths visible on your OVMF screenshots are distinguishable +from each other by their Pci() device path nodes. There is no collision. + +I recommend reviewing the following commits: + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a907ec52cc1a +https://github.com/tianocore/edk2/commit/d7c0dfaef26c + +The point being: if QEMU grows a capability to store a nonzero EUI64, +and that EUI64 is reflected in the OpenFirmware device path that is +placed into the "bootorder" fw_cfg file, then OVMF will parse it just +fine. However, QEMU is not required to grow such a capability, according +to the NVMe and UEFI specifications. In practice, multiple NVMe devices +can be distinguished from each other by their different PCI B/D/F locations. + +Thanks, +Laszlo + + +Since both "drive=" and "serial=" expects an arbitrary string (while the value for "drive=" must be unique since it's the "id=" of a "-drive"), why not use the same string from "drive=" as the value of "serial=" when it's not specified explicitly? + +Apparently "-device scsi-hd" has already been doing that (although it does not create the "sn" VPD when a serial is not explicitly specified). + + + + + +No new developments for 4+ years, closing as invalid (I'd prefer "wontfix due to lack of resources", but I'm unable to pick that resolution). + diff --git a/results/classifier/118/permissions/1549 b/results/classifier/118/permissions/1549 new file mode 100644 index 00000000..2df47b85 --- /dev/null +++ b/results/classifier/118/permissions/1549 @@ -0,0 +1,125 @@ +permissions: 0.887 +device: 0.848 +debug: 0.848 +graphic: 0.845 +register: 0.842 +performance: 0.841 +hypervisor: 0.838 +vnc: 0.832 +socket: 0.829 +KVM: 0.826 +TCG: 0.826 +assembly: 0.819 +network: 0.817 +PID: 0.817 +user-level: 0.803 +semantic: 0.802 +virtual: 0.796 +peripherals: 0.792 +arm: 0.784 +architecture: 0.762 +ppc: 0.754 +risc-v: 0.738 +files: 0.738 +boot: 0.737 +VMM: 0.692 +kernel: 0.675 +x86: 0.621 +mistranslation: 0.620 +i386: 0.347 + +8.0.0rc0 Regression: spicy windows doesn't open +Description of problem: +Soon after start the qemu process outputs +``` +qemu-system-x86_64.exe: fd=900 is not a socket, AIO implementation is missing +qemu-system-x86_64.exe: fd=800 is not a socket, AIO implementation is missing +``` +On connecting with `spicy -h localhost -p 5905 --spice-debug` spicy stops progress after writing this line +``` +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.406: ../spice-gtk-0.42/src/spice-channel.c:1415 main-1:0: channel type 1 id 0 num common caps 1 num caps 1 +``` +Steps to reproduce: +1. Start qemu with `qemu-system-x86_64 -m 1536 -vga qxl -spice port=5905,addr=127.0.0.1,disable-ticketing=on -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` in first MSYS2 MinGW64 terminal +2. Start spice with `spicy -h localhost -p 5905 --spice-debug` in second MSYS2 MinGW64 terminal +Additional information: +Final output of `git bisect` +``` +abe34282b088499f4e86fff9bb6d6dafd57ae1d0 is the first bad commit +commit abe34282b088499f4e86fff9bb6d6dafd57ae1d0 +Author: Marc-André Lureau <marcandre.lureau@redhat.com> +Date: Tue Feb 21 16:47:59 2023 +0400 + + win32: avoid mixing SOCKET and file descriptor space + + Until now, a win32 SOCKET handle is often cast to an int file + descriptor, as this is what other OS use for sockets. When necessary, + QEMU eventually queries whether it's a socket with the help of + fd_is_socket(). However, there is no guarantee of conflict between the + fd and SOCKET space. Such conflict would have surprising consequences, + we shouldn't mix them. + + Also, it is often forgotten that SOCKET must be closed with + closesocket(), and not close(). + + Instead, let's make the win32 socket wrapper functions return and take a + file descriptor, and let util/ wrappers do the fd/SOCKET conversion as + necessary. A bit of adaptation is necessary in io/ as well. + + Unfortunately, we can't drop closesocket() usage, despite + _open_osfhandle() documentation claiming transfer of ownership, testing + shows bad behaviour if you forget to call closesocket(). + + Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> + Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> + Message-Id: <20230221124802.4103554-15-marcandre.lureau@redhat.com> + + include/sysemu/os-win32.h | 4 +- + io/channel-watch.c | 6 +- + util/aio-win32.c | 9 +- + util/oslib-win32.c | 219 +++++++++++++++++++++++++++++++++++++++------- + 4 files changed, 197 insertions(+), 41 deletions(-) +``` +Complete spicy output +``` +$ spicy -h localhost -p 5905 --spice-debug +(spicy.exe:5584): GSpice-DEBUG: 18:43:52.890: ../spice-gtk-0.42/src/spice-session.c:288 New session (compiled from package spice-gtk 0.42) +(spicy.exe:5584): GSpice-DEBUG: 18:43:53.872: ../spice-gtk-0.42/src/spice-session.c:292 Supported channels: main, display, inputs, cursor, playback, record, smartcard, usbredir, webdav +(spicy.exe:5584): GSpice-WARNING **: 18:43:53.877: SpiceSession:gl-scanout is only available on Unix +(spicy.exe:5584): GSpice-WARNING **: 18:43:53.881: UsbDk driver is not installed +(spicy.exe:5584): GSpice-DEBUG: 18:43:53.908: ../spice-gtk-0.42/src/usb-device-manager.c:393 auto-connect filter set to 0x03,-1,-1,-1,0|-1,-1,-1,-1,1 +(spicy.exe:5584): GSpice-DEBUG: 18:43:53.913: ../spice-gtk-0.42/src/usb-backend.c:440 spice_usb_backend_new >> +(spicy.exe:5584): GSpice-DEBUG: 18:43:53.918: ../spice-gtk-0.42/src/usb-backend.c:462 spice_usb_backend_new << +(spicy.exe:5584): GSpice-DEBUG: 18:43:53.995: ../spice-gtk-0.42/src/usb-backend.c:207 adding 04F2:B43C at 1:1 +(spicy.exe:5584): GSpice-DEBUG: 18:43:53.998: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C26 at 3:0 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.000: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C2D at 1:0 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.003: ../spice-gtk-0.42/src/usb-backend.c:207 adding 0BDA:B728 at 1:4 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.006: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e280, usblib dev 00000148d27a2590 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.010: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C31 at 2:0 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.014: ../spice-gtk-0.42/src/usb-backend.c:207 adding 05E3:0608 at 3:5 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.017: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8087:8008 at 1:5 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.020: ../spice-gtk-0.42/src/usb-backend.c:207 adding 0BDA:0129 at 1:3 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.023: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e140, usblib dev 00000148d27a2b30 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.027: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8087:8000 at 3:4 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.030: ../spice-gtk-0.42/src/usb-backend.c:207 adding 045E:00DB at 3:1 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.033: ../spice-gtk-0.42/src/usb-backend.c:207 adding 17EF:6019 at 3:2 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.035: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e190, usblib dev 00000148d27a5460 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.074: ../spice-gtk-0.42/tools/spicy.c:1881 connection_new (1) +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.074: ../spice-gtk-0.42/src/usb-backend.c:469 handle_libusb_events >> +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.081: ../spice-gtk-0.42/src/spice-session.c:1835 no migration in progress +Spice-INFO: 18:43:54.086: ../spice-gtk-0.42/src/channel-main.c:342:spice_main_set_property: SpiceMainChannel::color-depth has been deprecated. Property is ignored +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.090: ../spice-gtk-0.42/src/spice-channel.c:142 main-1:0: spice_channel_constructed +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.093: ../spice-gtk-0.42/src/spice-session.c:2330 main-1:0: new main channel, switching +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.097: ../spice-gtk-0.42/tools/spicy.c:1758 new channel (#0) +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.099: ../spice-gtk-0.42/tools/spicy.c:1761 new main channel +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.102: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 0bda:b728 (00000148d2a9e280) +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.105: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 0bda:0129 (00000148d2a9e140) +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.108: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 17ef:6019 (00000148d2a9e190) +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.113: ../spice-gtk-0.42/src/spice-channel.c:2763 main-1:0: Open coroutine starting 00000148d2a403f0 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.116: ../spice-gtk-0.42/src/spice-channel.c:2587 main-1:0: Started background coroutine 00000148d2a402b0 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.120: ../spice-gtk-0.42/src/spice-session.c:2267 main-1:0: Using plain text, port 5905 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.124: ../spice-gtk-0.42/src/spice-session.c:2198 open host localhost:5905 +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.136: ../spice-gtk-0.42/src/spice-session.c:2120 main-1:0: connecting 000000010f1ffc90... +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.402: ../spice-gtk-0.42/src/spice-session.c:2104 main-1:0: connect ready +(spicy.exe:5584): GSpice-DEBUG: 18:43:54.406: ../spice-gtk-0.42/src/spice-channel.c:1415 main-1:0: channel type 1 id 0 num common caps 1 num caps 1 +``` diff --git a/results/classifier/118/permissions/1581334 b/results/classifier/118/permissions/1581334 new file mode 100644 index 00000000..b1a44839 --- /dev/null +++ b/results/classifier/118/permissions/1581334 @@ -0,0 +1,267 @@ +permissions: 0.865 +user-level: 0.857 +architecture: 0.790 +register: 0.779 +semantic: 0.776 +mistranslation: 0.758 +performance: 0.749 +debug: 0.733 +graphic: 0.727 +kernel: 0.720 +assembly: 0.717 +device: 0.707 +network: 0.701 +PID: 0.700 +risc-v: 0.697 +hypervisor: 0.685 +ppc: 0.662 +TCG: 0.660 +KVM: 0.659 +VMM: 0.655 +socket: 0.652 +virtual: 0.651 +peripherals: 0.634 +boot: 0.602 +vnc: 0.590 +x86: 0.588 +files: 0.538 +arm: 0.498 +i386: 0.493 + +qemu + librbd takes high %sy cpu under high random io workload + +I got an IO problem. When running Qemu + ceph(use librbd), and do a random IO benchmark or some high load random IO test, it will exhaust all my host cpu on %sy cpu. +It doesn’t happen all the time, but when it appear it will reproduce every time I start a random IO benchmark(test with Fio). +And the only way to fix the problem is shutdown my vm and start it, but the problem will happen again with high random IO load. + +Some information: + Vendor : HP + Product : HP ProLiant BL460c Gen9 + Kernel : 3.16.0-4-amd64 + Disto : Debian + Version : 8.4 + Arch : amd64 + Qemu : 2.1 ~ 2.6 (Yes, I already test the latest qemu2.6 version, but still got the problem) + Ceph : Hammer 0.94.5 + Librbd : 0.94.5 ~ 10.2 (I rebuild librbd with ceph 10.2 source code, but the problem still here) + Qemu config : cache=none + Qemu cpu&mem: 4core, 8GB + +How can i reproduce the problem? + +while :; do bash randwrite.sh ; sleep 3600; done >test.log 2>&1 & +(Sleep 3600 is the key to reproduce my problem. I don’t known how long sleep suit for reproduce, but one hour sleep is enough. the problem will easy reproduce after a long sleep, if i keep benchmark running without sleep, i can't reproduce it) + +My randwrite.sh script +---------------------------------------------- +#!/bin/sh +sync +echo 3 > /proc/sys/vm/drop_caches + +FILENAME=/dev/vdc +RUNTIME=100 +BLOCKSIZE=4K +IOENGINE=libaio +RESULTFILE=fio-randwrite.log +IODEPTH=32 +RAMP_TIME=5 +SIZE=100G + +fio --numjobs 10 --norandommap --randrepeat=0 --readwrite=randwrite --ramp_time=$RAMP_TIME --bs=$BLOCKSIZE --runtime=$RUNTIME --iodepth=$IODEPTH --filename=$FILENAME --ioengine=$IOENGINE --direct=1 --name=iops_randwrite --group_reporting | tee $RESULTFILE +---------------------------------------------- + +What happened after the problem appear? +my vm will got huge IOPS drop. In my case, it will drop from 15000 IOPS to 3500 IOPS. And other thing, my host cpu will exhaust on %sy. Top output like this. + +Qemu Fio benchmark +---------------------------------------------------- +Tasks: 284 total, 2 running, 282 sleeping, 0 stopped, 0 zombie +%Cpu0 : 11.8 us, 66.7 sy, 0.0 ni, 21.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu1 : 12.7 us, 64.9 sy, 0.0 ni, 22.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu2 : 13.7 us, 64.5 sy, 0.0 ni, 21.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu3 : 13.2 us, 64.1 sy, 0.0 ni, 22.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu4 : 11.7 us, 65.4 sy, 0.0 ni, 22.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu5 : 13.2 us, 64.4 sy, 0.0 ni, 22.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu6 : 12.4 us, 65.1 sy, 0.0 ni, 22.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu7 : 13.6 us, 63.8 sy, 0.0 ni, 22.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu8 : 9.8 us, 73.0 sy, 0.0 ni, 17.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu9 : 7.8 us, 74.5 sy, 0.0 ni, 17.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu10 : 6.0 us, 81.4 sy, 0.0 ni, 6.6 id, 0.0 wa, 0.0 hi, 6.0 si, 0.0 st +%Cpu11 : 8.4 us, 79.5 sy, 0.0 ni, 8.8 id, 0.0 wa, 0.0 hi, 3.4 si, 0.0 st +%Cpu12 : 7.6 us, 80.7 sy, 0.0 ni, 7.0 id, 0.0 wa, 0.0 hi, 4.7 si, 0.0 st +%Cpu13 : 7.4 us, 79.9 sy, 0.0 ni, 7.7 id, 0.0 wa, 0.0 hi, 5.0 si, 0.0 st +%Cpu14 : 9.8 us, 75.4 sy, 0.0 ni, 11.4 id, 0.0 wa, 0.0 hi, 3.4 si, 0.0 st +%Cpu15 : 6.7 us, 80.1 sy, 0.0 ni, 10.1 id, 0.0 wa, 0.0 hi, 3.0 si, 0.0 st +%Cpu16 : 9.2 us, 69.2 sy, 0.0 ni, 17.5 id, 0.0 wa, 0.0 hi, 4.1 si, 0.0 st +%Cpu17 : 9.9 us, 66.6 sy, 0.0 ni, 20.1 id, 0.0 wa, 0.0 hi, 3.4 si, 0.0 st +%Cpu18 : 16.6 us, 49.0 sy, 0.0 ni, 34.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu19 : 16.7 us, 46.4 sy, 0.0 ni, 36.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu20 : 13.0 us, 50.8 sy, 0.0 ni, 36.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu21 : 18.9 us, 46.2 sy, 0.0 ni, 34.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu22 : 12.1 us, 52.9 sy, 0.0 ni, 35.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu23 : 15.9 us, 47.6 sy, 0.0 ni, 36.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu24 : 6.7 us, 62.0 sy, 0.0 ni, 31.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu25 : 7.6 us, 63.7 sy, 0.0 ni, 28.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu26 : 8.1 us, 75.8 sy, 0.0 ni, 16.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu27 : 6.7 us, 73.6 sy, 0.0 ni, 19.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu28 : 9.2 us, 74.3 sy, 0.0 ni, 16.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu29 : 8.2 us, 73.3 sy, 0.0 ni, 18.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu30 : 4.4 us, 73.1 sy, 0.0 ni, 22.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +%Cpu31 : 7.5 us, 69.6 sy, 0.0 ni, 22.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +KiB Mem: 13217662+total, 3721572 used, 12845504+free, 283228 buffers +KiB Swap: 4194300 total, 0 used, 4194300 free. 2242976 cached Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +30349 root 20 0 25.381g 499892 20640 R 2495 0.4 119:11.98 qemu-system-x86 + +Anything I do? +I use perf top, profile to debug the problem. It show me that something like thread deadlock problem. Any I test QEMU with kernel RBD, it work fine. +Here are the perf top output on host. +--------------------------------------------------------------- + PerfTop: 12393 irqs/sec kernel:87.3% exact: 0.0% [4000Hz cycles], (all, 32 CPUs) +------------------------------------------------------------------------------- + + 75.25% [kernel] [k] _raw_spin_lock + 1.17% [kernel] [k] futex_wait_setup + 0.86% libc-2.19.so [.] malloc + 0.58% [kernel] [k] futex_wake + 0.55% libc-2.19.so [.] 0x00000000000ea96f + 0.41% [kernel] [k] native_write_msr_safe +--------------------------------------------------------------- + + affects linux + + +Since this works fine with krbd, it sounds like the bug may be in librbd. Could you install debug symbols (the librbd1-dbg package) and when this occurs, attach to the qemu process with gdb and get a backtrace of all threads (there will be a lot of them) via 'gdb -p $pid' and in gdb 'thread apply all bt'? + + affects ceph + + +Here are gdb oupout with librbd1-dbg and librados2-dbg. + +--------------------------------------------------------- +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +0x00007ff8cf8dddff in ppoll () from /lib/x86_64-linux-gnu/libc.so.6 + +Thread 522 (Thread 0x7ff8ccb56700 (LWP 4959)): +#0 0x00007ff8cf8e2809 in syscall () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007ff8cf198012 in ?? () from /usr/lib/x86_64-linux-gnu/liblttng-ust.so.0 +#2 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#3 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +Thread 521 (Thread 0x7ff8cc355700 (LWP 4960)): +#0 0x00007ff8cf8e2809 in syscall () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007ff8cf198012 in ?? () from /usr/lib/x86_64-linux-gnu/liblttng-ust.so.0 +#2 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#3 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +Thread 520 (Thread 0x7ff8cbb54700 (LWP 4961)): +#0 0x00007ff8cf8e2809 in syscall () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x0000000000833d00 in futex_wait (ev=0x1222e04 <rcu_call_ready_event>, val=4294967295) at util/qemu-thread-posix.c:292 +#2 0x0000000000833e8e in qemu_event_wait (ev=0x1222e04 <rcu_call_ready_event>) at util/qemu-thread-posix.c:399 +#3 0x0000000000849382 in call_rcu_thread (opaque=0x0) at util/rcu.c:250 +#4 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#5 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +Thread 519 (Thread 0x7ff8cab1c700 (LWP 4974)): +#0 0x00007ff8cfbb508f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 +#1 0x00007ff8d17a563b in ceph::log::Log::entry (this=0x1643a60) at log/Log.cc:353 +#2 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#3 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +Thread 518 (Thread 0x7ff8c9b8d700 (LWP 4975)): +#0 0x00007ff8cfbb5438 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 +#1 0x00007ff8d1535acb in WaitUntil (when=..., mutex=..., this=0x1692bd8) at ./common/Cond.h:71 +#2 WaitInterval (interval=..., mutex=..., cct=<optimized out>, this=0x1692bd8) at ./common/Cond.h:79 +#3 CephContextServiceThread::entry (this=0x1692b60) at common/ceph_context.cc:96 +#4 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#5 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 + + +Thread 517 (Thread 0x7ff8c938c700 (LWP 4976)): +#0 0x00007ff8cfbb5438 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 +#1 0x00007ff8d15125c1 in WaitUntil (when=..., mutex=..., this=0x1694978) at common/Cond.h:71 +#2 SafeTimer::timer_thread (this=0x1694968) at common/Timer.cc:118 +#3 0x00007ff8d1512efd in SafeTimerThread::entry (this=<optimized out>) at common/Timer.cc:38 +#4 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#5 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +Thread 516 (Thread 0x7ff8c8b8b700 (LWP 4977)): +#0 0x00007ff8cfbb508f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 +#1 0x00007ff8d1696b70 in Wait (mutex=..., this=0x1693f50) at ./common/Cond.h:55 +#2 DispatchQueue::entry (this=0x1693ee8) at msg/simple/DispatchQueue.cc:196 +#3 0x00007ff8d16c65fd in DispatchQueue::DispatchThread::entry (this=<optimized out>) at msg/simple/DispatchQueue.h:103 +#4 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#5 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +Thread 515 (Thread 0x7ff8c838a700 (LWP 4978)): +#0 0x00007ff8cfbb508f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 +#1 0x00007ff8d1699ba6 in Wait (mutex=..., this=0x16940f0) at ./common/Cond.h:55 +#2 DispatchQueue::run_local_delivery (this=0x1693ee8) at msg/simple/DispatchQueue.cc:114 +#3 0x00007ff8d16c66dd in DispatchQueue::LocalDeliveryThread::entry (this=<optimized out>) at msg/simple/DispatchQueue.h:117 +#4 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#5 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +Thread 514 (Thread 0x7ff8c7b89700 (LWP 4979)): +#0 0x00007ff8cfbb508f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 +#1 0x00007ff8d16bde99 in Wait (mutex=..., this=0x1694358) at ./common/Cond.h:55 +#2 SimpleMessenger::reaper_entry (this=0x1693d20) at msg/simple/SimpleMessenger.cc:211 +#3 0x00007ff8d16c6cdd in SimpleMessenger::ReaperThread::entry (this=<optimized out>) at msg/simple/SimpleMessenger.h:195 +#4 0x00007ff8cfbb10a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#5 0x00007ff8cf8e687d in clone () from /lib/x86_64-linux-gnu/libc.so.6 +........ +........ +........ +(all the log in attachment: debug.log) +--------------------------------------------------------------------------- + +Can you run 'perf top' against just the QEMU process? There was an email chain from nearly a year ago about tcmalloc causing extremely high '_raw_spin_lock' calls under high IOPS scenarios. + +Here are 'perf top -p `pgrep qemu` -a` output; I met tcmalloc problem on the osd host and fix it with a larger TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES. The perf top of tcmalloc problem is a little bit different of my problem. +------------------------------------------------------------------ +Samples: 15M of event 'cycles', Event count (approx.): 463535858808 + 87.68% [kernel] [k] _raw_spin_lock + 1.02% [kernel] [k] futex_wait_setup + 0.66% [kernel] [k] futex_wake + 0.47% libc-2.19.so [.] malloc + 0.42% [kernel] [k] try_to_wake_up + 0.22% [kernel] [k] __unqueue_futex + 0.22% [kernel] [k] _raw_spin_lock_irq + 0.18% libpthread-2.19.so [.] pthread_mutex_lock + 0.18% libc-2.19.so [.] 0x00000000000f4dff + 0.17% libc-2.19.so [.] 0x00000000000ea96f + 0.15% [kernel] [k] idle_cpu + 0.15% libpthread-2.19.so [.] __pthread_mutex_unlock_usercnt + 0.14% [kernel] [k] get_futex_value_locked + 0.13% [kernel] [k] get_futex_key_refs.isra.13 + 0.13% libc-2.19.so [.] free + 0.12% [kernel] [k] _raw_spin_lock_irqsave + 0.11% [kernel] [k] update_curr + 0.11% [kernel] [k] select_task_rq_fair + 0.10% [kernel] [k] native_write_msr_safe + 0.10% [kernel] [k] futex_wait_queue_me + 0.10% [kernel] [k] __schedule + 0.09% [kernel] [k] wake_futex +Press '?' for help on key bindings +---------------------------------------------------------------- + +Tcmalloc problem perf top (log from ceph bug tracer email, same with tcmalloc problem i met) +------------------------------------------------------------- +34.37% libtcmalloc.so.4.1.2 [.] tcmalloc::CentralFreeList::FetchFromSpans + 18.06% libtcmalloc.so.4.1.2 [.] tcmalloc::ThreadCache::ReleaseToCentralCache + 13.76% libtcmalloc.so.4.1.2 [.] tcmalloc::CentralFreeList::ReleaseToSpans + 1.45% libtcmalloc.so.4.1.2 [.] tcmalloc::CentralFreeList::RemoveRange +------------------------------------------------------------- + +Some more test I have do: +1. running qemu with TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES 256MB, still got problem +2. prevent cpu go into C3 and C6 state, still got problem +3. running qemu with aio=native, still got problem + +Any chance you can re-test with a more recent kernel on the hypervisor host? If the spin-lock was coming from user-space, I would expect futex_wait_setup and futex_wake to be much higher. + +Looking through old bug tickets... can you still reproduce this issue with the latest available versions? Or could we close this ticket nowadays? + +Since there wasn't a reply within the last two months, I'm assuming this doesn't affect QEMU anymore, thus I'm closing this ticket for QEMU now. + diff --git a/results/classifier/118/permissions/1581796 b/results/classifier/118/permissions/1581796 new file mode 100644 index 00000000..e3baff00 --- /dev/null +++ b/results/classifier/118/permissions/1581796 @@ -0,0 +1,249 @@ +permissions: 0.923 +register: 0.897 +graphic: 0.896 +performance: 0.887 +user-level: 0.882 +debug: 0.871 +virtual: 0.869 +device: 0.869 +i386: 0.859 +PID: 0.856 +arm: 0.852 +VMM: 0.850 +architecture: 0.840 +TCG: 0.828 +risc-v: 0.820 +assembly: 0.817 +semantic: 0.815 +vnc: 0.798 +hypervisor: 0.780 +files: 0.778 +socket: 0.766 +ppc: 0.759 +KVM: 0.742 +kernel: 0.718 +network: 0.717 +boot: 0.715 +x86: 0.714 +peripherals: 0.712 +mistranslation: 0.580 + +console-gl.c:96:surface_gl_create_texture:code should not be reached + +Facing this if i enable gtk,gl option same is with sd2 gl options. + +PowerPc P5020 4gb ram Ubuntu Mate 16:04 + +tested on +RadeonSi 7750HD 2gb ddr3 +r600 6570 2gb ddr3 + + +Thanks +Luigi + +Could you please add a + printf("Pixel format = 0x%x\n", surface->format); +in front of the g_assert_not_reached() in that function, and report which value is printed when you run it again? + +Will report soon + +here is the result + +qemu-2.5.1.1/i386-softmmu$ ./qemu-system-i386 -display sdl,gl=on +Pixel format = 0x20020888 +** +ERROR:ui/console-gl.c:96:surface_gl_create_texture: code should not be reached +Aborted (core dumped) + + + + + +In case is needed this is my ldd +linux-vdso32.so.1 => (0x00100000) + libvirglrenderer.so.0 => /usr/local/lib/libvirglrenderer.so.0 (0x0ff8a000) + libepoxy.so.0 => /usr/lib/powerpc-linux-gnu/libepoxy.so.0 (0x0fe86000) + libX11.so.6 => /usr/lib/powerpc-linux-gnu/libX11.so.6 (0x0fd23000) + libz.so.1 => /lib/powerpc-linux-gnu/libz.so.1 (0x0fce2000) + libcurl-gnutls.so.4 => /usr/lib/powerpc-linux-gnu/libcurl-gnutls.so.4 (0x0fc41000) + libbz2.so.1.0 => /lib/powerpc-linux-gnu/libbz2.so.1.0 (0x0fc00000) + libpixman-1.so.0 => /usr/lib/powerpc-linux-gnu/libpixman-1.so.0 (0x0fb5f000) + libutil.so.1 => /lib/powerpc-linux-gnu/libutil.so.1 (0x0fb2e000) + libncurses.so.5 => /lib/powerpc-linux-gnu/libncurses.so.5 (0x0fadd000) + libtinfo.so.5 => /lib/powerpc-linux-gnu/libtinfo.so.5 (0x0fa8c000) + libpulse.so.0 => /usr/lib/powerpc-linux-gnu/libpulse.so.0 (0x0fa1b000) + libpng16.so.16 => /usr/lib/powerpc-linux-gnu/libpng16.so.16 (0x0f9ba000) + libjpeg.so.8 => /usr/lib/powerpc-linux-gnu/libjpeg.so.8 (0x0f949000) + libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0x0f7f2000) + libnettle.so.6 => /usr/lib/powerpc-linux-gnu/libnettle.so.6 (0x0f791000) + libgnutls.so.30 => /usr/lib/powerpc-linux-gnu/libgnutls.so.30 (0x0f63f000) + libgtk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgtk-x11-2.0.so.0 (0x0f15b000) + libgdk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk-x11-2.0.so.0 (0x0f07a000) + libcairo.so.2 => /usr/lib/powerpc-linux-gnu/libcairo.so.2 (0x0ef38000) + libgdk_pixbuf-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x0eee7000) + libgobject-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgobject-2.0.so.0 (0x0ee66000) + libglib-2.0.so.0 => /lib/powerpc-linux-gnu/libglib-2.0.so.0 (0x0ed15000) + libsnappy.so.1 => /usr/lib/powerpc-linux-gnu/libsnappy.so.1 (0x0ece4000) + librt.so.1 => /lib/powerpc-linux-gnu/librt.so.1 (0x0ecb3000) + libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0ebc2000) + libgcc_s.so.1 => /lib/powerpc-linux-gnu/libgcc_s.so.1 (0x0eb81000) + libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 (0x0eb3e000) + libc.so.6 => /lib/powerpc-linux-gnu/libc.so.6 (0x0e98a000) + libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x0e959000) + libdrm.so.2 => /usr/lib/powerpc-linux-gnu/libdrm.so.2 (0x0e928000) + libdl.so.2 => /lib/powerpc-linux-gnu/libdl.so.2 (0x0e8f7000) + libxcb.so.1 => /usr/lib/powerpc-linux-gnu/libxcb.so.1 (0x0e8b6000) + libidn.so.11 => /usr/lib/powerpc-linux-gnu/libidn.so.11 (0x0e855000) + librtmp.so.1 => /usr/lib/powerpc-linux-gnu/librtmp.so.1 (0x0e814000) + libgssapi_krb5.so.2 => /usr/lib/powerpc-linux-gnu/libgssapi_krb5.so.2 (0x0e7a3000) + liblber-2.4.so.2 => /usr/lib/powerpc-linux-gnu/liblber-2.4.so.2 (0x0e772000) + libldap_r-2.4.so.2 => /usr/lib/powerpc-linux-gnu/libldap_r-2.4.so.2 (0x0e6f0000) + /lib/ld.so.1 (0x203e7000) + libjson-c.so.3 => /lib/powerpc-linux-gnu/libjson-c.so.3 (0x0e6bf000) + libpulsecommon-8.0.so => /usr/lib/powerpc-linux-gnu/pulseaudio/libpulsecommon-8.0.so (0x0e61e000) + libdbus-1.so.3 => /lib/powerpc-linux-gnu/libdbus-1.so.3 (0x0e5ad000) + libsndio.so.6.1 => /usr/lib/powerpc-linux-gnu/libsndio.so.6.1 (0x0e57a000) + libp11-kit.so.0 => /usr/lib/powerpc-linux-gnu/libp11-kit.so.0 (0x0e4f9000) + libtasn1.so.6 => /usr/lib/powerpc-linux-gnu/libtasn1.so.6 (0x0e4b8000) + libhogweed.so.4 => /usr/lib/powerpc-linux-gnu/libhogweed.so.4 (0x0e457000) + libgmp.so.10 => /usr/lib/powerpc-linux-gnu/libgmp.so.10 (0x0e3b6000) + libgmodule-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgmodule-2.0.so.0 (0x0e385000) + libpangocairo-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpangocairo-1.0.so.0 (0x0e354000) + libXfixes.so.3 => /usr/lib/powerpc-linux-gnu/libXfixes.so.3 (0x0e32e000) + libatk-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libatk-1.0.so.0 (0x0e2dd000) + libgio-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgio-2.0.so.0 (0x0e0eb000) + libpangoft2-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpangoft2-1.0.so.0 (0x0e0aa000) + libpango-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpango-1.0.so.0 (0x0e039000) + libfontconfig.so.1 => /usr/lib/powerpc-linux-gnu/libfontconfig.so.1 (0x0dfc4000) + libXrender.so.1 => /usr/lib/powerpc-linux-gnu/libXrender.so.1 (0x0df93000) + libXinerama.so.1 => /usr/lib/powerpc-linux-gnu/libXinerama.so.1 (0x0df70000) + libXi.so.6 => /usr/lib/powerpc-linux-gnu/libXi.so.6 (0x0df2f000) + libXrandr.so.2 => /usr/lib/powerpc-linux-gnu/libXrandr.so.2 (0x0defe000) + libXcursor.so.1 => /usr/lib/powerpc-linux-gnu/libXcursor.so.1 (0x0ded3000) + libXcomposite.so.1 => /usr/lib/powerpc-linux-gnu/libXcomposite.so.1 (0x0deb0000) + libXdamage.so.1 => /usr/lib/powerpc-linux-gnu/libXdamage.so.1 (0x0de8d000) + libXext.so.6 => /usr/lib/powerpc-linux-gnu/libXext.so.6 (0x0de59000) + libfreetype.so.6 => /usr/lib/powerpc-linux-gnu/libfreetype.so.6 (0x0dd88000) + libxcb-shm.so.0 => /usr/lib/powerpc-linux-gnu/libxcb-shm.so.0 (0x0dd57000) + libxcb-render.so.0 => /usr/lib/powerpc-linux-gnu/libxcb-render.so.0 (0x0dd26000) + libffi.so.6 => /usr/lib/powerpc-linux-gnu/libffi.so.6 (0x0dcf5000) + libpcre.so.3 => /lib/powerpc-linux-gnu/libpcre.so.3 (0x0dc64000) + libstdc++.so.6 => /usr/lib/powerpc-linux-gnu/libstdc++.so.6 (0x0da70000) + libexpat.so.1 => /lib/powerpc-linux-gnu/libexpat.so.1 (0x0da1f000) + libXau.so.6 => /usr/lib/powerpc-linux-gnu/libXau.so.6 (0x0d9fb000) + libXdmcp.so.6 => /usr/lib/powerpc-linux-gnu/libXdmcp.so.6 (0x0d9ca000) + libkrb5.so.3 => /usr/lib/powerpc-linux-gnu/libkrb5.so.3 (0x0d8d9000) + libk5crypto.so.3 => /usr/lib/powerpc-linux-gnu/libk5crypto.so.3 (0x0d888000) + libcom_err.so.2 => /lib/powerpc-linux-gnu/libcom_err.so.2 (0x0d857000) + libkrb5support.so.0 => /usr/lib/powerpc-linux-gnu/libkrb5support.so.0 (0x0d826000) + libresolv.so.2 => /lib/powerpc-linux-gnu/libresolv.so.2 (0x0d7e3000) + libsasl2.so.2 => /usr/lib/powerpc-linux-gnu/libsasl2.so.2 (0x0d7a2000) + libgssapi.so.3 => /usr/lib/powerpc-linux-gnu/libgssapi.so.3 (0x0d740000) + libsystemd.so.0 => /lib/powerpc-linux-gnu/libsystemd.so.0 (0x0d68d000) + libwrap.so.0 => /lib/powerpc-linux-gnu/libwrap.so.0 (0x0d664000) + libsndfile.so.1 => /usr/lib/powerpc-linux-gnu/libsndfile.so.1 (0x0d5bf000) + libasyncns.so.0 => /usr/lib/powerpc-linux-gnu/libasyncns.so.0 (0x0d58e000) + libasound.so.2 => /usr/lib/powerpc-linux-gnu/libasound.so.2 (0x0d45d000) + libbsd.so.0 => /lib/powerpc-linux-gnu/libbsd.so.0 (0x0d41c000) + libselinux.so.1 => /lib/powerpc-linux-gnu/libselinux.so.1 (0x0d3ca000) + libharfbuzz.so.0 => /usr/lib/powerpc-linux-gnu/libharfbuzz.so.0 (0x0d319000) + libthai.so.0 => /usr/lib/powerpc-linux-gnu/libthai.so.0 (0x0d2e8000) + libkeyutils.so.1 => /lib/powerpc-linux-gnu/libkeyutils.so.1 (0x0d2b7000) + libheimntlm.so.0 => /usr/lib/powerpc-linux-gnu/libheimntlm.so.0 (0x0d286000) + libkrb5.so.26 => /usr/lib/powerpc-linux-gnu/libkrb5.so.26 (0x0d1d4000) + libasn1.so.8 => /usr/lib/powerpc-linux-gnu/libasn1.so.8 (0x0d112000) + libhcrypto.so.4 => /usr/lib/powerpc-linux-gnu/libhcrypto.so.4 (0x0d0b0000) + libroken.so.18 => /usr/lib/powerpc-linux-gnu/libroken.so.18 (0x0d06f000) + liblzma.so.5 => /lib/powerpc-linux-gnu/liblzma.so.5 (0x0d02a000) + libgcrypt.so.20 => /lib/powerpc-linux-gnu/libgcrypt.so.20 (0x0cf37000) + libnsl.so.1 => /lib/powerpc-linux-gnu/libnsl.so.1 (0x0cef4000) + libFLAC.so.8 => /usr/lib/powerpc-linux-gnu/libFLAC.so.8 (0x0ce73000) + libvorbisenc.so.2 => /usr/lib/powerpc-linux-gnu/libvorbisenc.so.2 (0x0cdc2000) + libgraphite2.so.3 => /usr/lib/powerpc-linux-gnu/libgraphite2.so.3 (0x0cd71000) + libdatrie.so.1 => /usr/lib/powerpc-linux-gnu/libdatrie.so.1 (0x0cd40000) + libwind.so.0 => /usr/lib/powerpc-linux-gnu/libwind.so.0 (0x0ccef000) + libheimbase.so.1 => /usr/lib/powerpc-linux-gnu/libheimbase.so.1 (0x0ccbe000) + libhx509.so.5 => /usr/lib/powerpc-linux-gnu/libhx509.so.5 (0x0cc4c000) + libsqlite3.so.0 => /usr/lib/powerpc-linux-gnu/libsqlite3.so.0 (0x0cb1a000) + libcrypt.so.1 => /lib/powerpc-linux-gnu/libcrypt.so.1 (0x0cac2000) + libgpg-error.so.0 => /lib/powerpc-linux-gnu/libgpg-error.so.0 (0x0ca81000) + libogg.so.0 => /usr/lib/powerpc-linux-gnu/libogg.so.0 (0x0ca59000) + libvorbis.so.0 => /usr/lib/powerpc-linux-gnu/libvorbis.so.0 (0x0ca08000) + + + +OK, thanks for checking. Pixel format = 0x20020888 is the PIXMAN_x8r8g8b8 format, if I've got the pixman.h header right. So could you please try the following patch to see whether it fixes the issue for you? + +diff --git a/ui/console-gl.c b/ui/console-gl.c +--- a/ui/console-gl.c ++++ b/ui/console-gl.c +@@ -88,6 +88,10 @@ void surface_gl_create_texture(ConsoleGLState *gls, + surface->glformat = GL_BGRA_EXT; + surface->gltype = GL_UNSIGNED_BYTE; + break; ++ case PIXMAN_BE_x8r8g8b8: ++ surface->glformat = GL_RGBA; ++ surface->gltype = GL_UNSIGNED_BYTE; ++ break; + case PIXMAN_r5g6b5: + surface->glformat = GL_RGB; + surface->gltype = GL_UNSIGNED_SHORT_5_6_5; + + +Uh, seems like the web interface ate up the spaces in my previous comment. Here's the patch as attachment instead. + +Hi T. +i been test and build your patch with the qemu 2.6 on mate 16.10 and look like not crashing when qemu open like before +but i continue have the black display here,look like the emulated hardware have a issue someware. +(check the attached image)... the strange of this issue is it was not present before and not is relative something about sdl or gtk . +I try all the options available adding a bios, changing the vga the machine type, gave a cpu option but nothing... all the time the same issue. + +About your sdl parch: +I will check your patch on qemu 2.5.1 and on fedora 24 for confirm everything working right. + +thanks for you parches +Luigi + +Hi T, +tested on 2.5.1 and the patch is working. +it can be included in the mainstream + +Luigi + +When you say it's failing with qemu 2.6, are you using the official release 2.6.0 or the current version from the git repository? Also, which target machine are you emulating? x86_64? ppc64? + +Hi T. +yes the official git 2.6 from qemu.org +No video come with all type of machine i had been tested: ppc, ppc64, i386, x86_64 , but this only on Ubuntu 16.10 +on Fedora 24 all is working right . +I think there is something broken on ubuntu 16.10. + +ah sorry i forgot ... on Fedora 24 qemu 2.6.0 with the patch is working + +Luigi + + + +Fix has been pulled into the QEMU git repository: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2c2311c5451f4555e850772 + +Thomas, +thank you very much +for your fix + +Luigi + +Hi T.Huth, +is possible add the sdl patches on BigEndian on Qemu 2.5.1 ? +the lastest are not initializing the display i dont understand what appening with last qemu on Big Endian. + +Sorry, I didn't quite get your question ... do you want to see the patch included in the 2.5 stable branch (i.e. included in version 2.5.2)? Or do you have a problem applying the patch on top of 2.5.1 on your own? + +i think the best will be it included in the stable branch for have a full working qemu options + + +Well, QEMU 2.7 is likely to be released next months, so I'm not sure whether there will be another 2.5.x stable release ... but if you like, you can try to send the patch to the qemu-stable mailing list (that's the official way to get a patch included into the stable tree) and ask to include it in 2.5.2 if it ever gets released. + +I will send your old sdl patches? i dont like to tief code ;-) + diff --git a/results/classifier/118/permissions/1581936 b/results/classifier/118/permissions/1581936 new file mode 100644 index 00000000..bcc6ebb1 --- /dev/null +++ b/results/classifier/118/permissions/1581936 @@ -0,0 +1,262 @@ +permissions: 0.982 +debug: 0.956 +virtual: 0.950 +register: 0.950 +device: 0.949 +performance: 0.949 +semantic: 0.948 +architecture: 0.944 +risc-v: 0.943 +assembly: 0.942 +boot: 0.942 +arm: 0.931 +kernel: 0.931 +graphic: 0.929 +PID: 0.929 +files: 0.924 +socket: 0.920 +user-level: 0.908 +KVM: 0.847 +peripherals: 0.845 +network: 0.825 +VMM: 0.820 +x86: 0.779 +mistranslation: 0.770 +hypervisor: 0.722 +vnc: 0.694 +TCG: 0.675 +ppc: 0.663 +i386: 0.454 + +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/118/permissions/1592351 b/results/classifier/118/permissions/1592351 new file mode 100644 index 00000000..9ae52b81 --- /dev/null +++ b/results/classifier/118/permissions/1592351 @@ -0,0 +1,93 @@ +permissions: 0.821 +debug: 0.728 +device: 0.711 +PID: 0.702 +user-level: 0.701 +graphic: 0.681 +files: 0.652 +hypervisor: 0.641 +assembly: 0.636 +virtual: 0.629 +architecture: 0.622 +socket: 0.621 +risc-v: 0.618 +x86: 0.610 +semantic: 0.604 +performance: 0.598 +vnc: 0.591 +arm: 0.588 +peripherals: 0.581 +TCG: 0.580 +boot: 0.564 +KVM: 0.556 +VMM: 0.552 +i386: 0.529 +network: 0.501 +ppc: 0.500 +kernel: 0.489 +register: 0.471 +mistranslation: 0.456 + +mouse pointer offset with gtk,gl=on + +When I turn gl=on for -display gtk, some Y offset is added to the mouse pointer coordinates. That is, when I click on an icon, an icon _above_ the one I clicked triggers. + +Using xev, it seems to be offset of 10-12 pixels. + +It happens with all ps/2 mouse, -usbdevice mouse and -usbdevice tablet. + +Without gl=on, the pointer is precise. + +I have these qemu versions: +qemu-2.6.0-470.2.x86_64 +qemu-ipxe-1.0.0-470.2.noarch +qemu-ksm-2.6.0-470.2.x86_64 +qemu-kvm-2.6.0-470.2.x86_64 +qemu-ovmf-x86_64-2015+git1462940744.321151f-2.1.noarch +qemu-ppc-2.6.0-470.2.x86_64 +qemu-seabios-1.9.1-470.2.noarch +qemu-sgabios-8-470.2.noarch +qemu-tools-2.6.0-470.2.x86_64 +qemu-vgabios-1.9.1-470.2.noarch +qemu-x86-2.6.0-470.2.x86_64 + +The same happens with qemu from git, commit a28aae041aa76a779df6467a7fe68b9e8a8b2c0a. + +This is because height from gdk_drawable_get_size() in gd_motion_event() includes menu or whatever: + +gl=off: +gd_motion_event: fbw= 640 fbh= 480 ww= 640 wh= 480 mx= 0 my= 0 x= 576 y= 3 + +gl=on: +gd_motion_event: fbw= 640 fbh= 480 ww= 640 wh= 506 mx= 0 my= 13 x= 571 y= 471 + + +Yeh I saw this behaviour as well. + +s->menu_bar's height is really 26px (506-480) +both s->notebook's and vc->tab_item's height is 506 px (the same as vc->gfx.drawing_area). + +I cannot figure out why... + +Ok, should we use + gtk_widget_get_allocated_height and gtk_widget_get_allocated_width +instead of + gdk_drawable_get_size +? + +That works for scale = 1. Given scale is set only in draw (2d) and not in render (3d), it never worked with other scales. Apart from that, the code is full of bugs. + +I could make it work with the attached diff modulo the fprintfs, basically. However I am not going to invest more time into that, as it has to be audited and fixed by someone who actually understands the code. + +Mouse still doesn't work properly with 2.9.0 and Ubuntu 17.04 guest +-smp 2 -enable-kvm -vga virtio -display gtk,gl=on -m 2048 -cdrom ubuntu-17.04-desktop-amd64.iso + +mouse works better with debug & fix patch + +seems to be fixed with f1aba960cc40ab65fa88c8678883bd2201708c55 : https://git.qemu.org/?p=qemu.git;a=commit;h=f1aba960cc40ab65fa88c8678883bd2201708c55 + + +anyone else can confirm, i have another issue affecting scaling with my setup. + +FWIW: Commit f1aba960cc40 has been released with v3.1.0. + diff --git a/results/classifier/118/permissions/1594069 b/results/classifier/118/permissions/1594069 new file mode 100644 index 00000000..258458c3 --- /dev/null +++ b/results/classifier/118/permissions/1594069 @@ -0,0 +1,104 @@ +permissions: 0.953 +TCG: 0.928 +peripherals: 0.925 +register: 0.920 +mistranslation: 0.916 +performance: 0.906 +graphic: 0.897 +device: 0.892 +architecture: 0.872 +user-level: 0.858 +debug: 0.855 +arm: 0.854 +boot: 0.847 +socket: 0.846 +ppc: 0.844 +risc-v: 0.843 +hypervisor: 0.843 +VMM: 0.838 +files: 0.823 +semantic: 0.821 +assembly: 0.814 +network: 0.782 +kernel: 0.768 +PID: 0.757 +virtual: 0.720 +vnc: 0.665 +x86: 0.661 +KVM: 0.641 +i386: 0.620 + +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/118/permissions/1599214 b/results/classifier/118/permissions/1599214 new file mode 100644 index 00000000..0f4ce06f --- /dev/null +++ b/results/classifier/118/permissions/1599214 @@ -0,0 +1,170 @@ +permissions: 0.903 +hypervisor: 0.901 +peripherals: 0.899 +graphic: 0.896 +debug: 0.893 +semantic: 0.883 +assembly: 0.868 +vnc: 0.868 +architecture: 0.862 +performance: 0.859 +register: 0.856 +network: 0.856 +boot: 0.854 +device: 0.849 +socket: 0.846 +PID: 0.841 +KVM: 0.811 +user-level: 0.809 +TCG: 0.804 +ppc: 0.802 +files: 0.802 +arm: 0.801 +virtual: 0.794 +mistranslation: 0.786 +VMM: 0.785 +risc-v: 0.723 +x86: 0.689 +kernel: 0.640 +i386: 0.334 + +virtlogd: qemu 2.6.0 doesn't log boot message + +This report is related to the OpenStack Nova bug [1]. + +OpenStack tries to utilize the "virtlogd" feature of qemu [2]. + +steps to reproduce: +1) launch a quest with qemu 2.6.0 which uses virtlogd for the stdout/stderr of its char device +2) check the contents of the backing file of that char device + +expected result: +The boot messages of the guest are logged in this file + +actual result: +The file is empty + +notes: +When I'm connected to that char device and reboot the guest, I see the boot messages in the terminal and also in the backing log file. + +References: +[1] https://bugs.launchpad.net/nova/+bug/1597789 +[2] http://git.qemu.org/?p=qemu.git;a=blobdiff;f=qemu-char.c;h=11caa5648de99c9e0ee158f280fbc02ab05915d3;hp=d7be1851e5e9d268aa924a05958da292b048839c;hb=d0d7708ba29cbcc343364a46bff981e0ff88366f;hpb=f1c17521e79df863a5771d96974fab0d07f02be0 + +Can you provide the full QEMU command line arguments you're using to reproduce this problem. I tested a guest with the following console config: + + <serial type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/f25-console.sock'/> + <log file='/var/lib/libvirt/qemu/f25-console.log'/> + <target port='1'/> + <alias name='serial1'/> + </serial> + +and confirmed that the log file gets written, even when no client is connected to the UNIX domain socket. + +qemu log: +http://paste.openstack.org/show/542559/ + +Ok, relevant part of command line is + +-add-fd set=2,fd=33 +-chardev socket,id=charconsole0,host=9.152.151.129,port=10000,server,nowait,logfile=/dev/fdset/2,logappend=on +-device virtconsole,chardev=charconsole0,id=console0 +-chardev pty,id=charconsole1 +-device sclpconsole,chardev=charconsole1,id=console1 + + +Which shows a TCP based serial console with log file + +> Which shows a TCP based serial console with log file + +Yes, that's true. It's also on the s390x architecture. + +The char device in the libvirt domain XML is this: + + <console type="tcp"> + <source host="9.152.151.133" mode="bind" service="10000"/> + <log file="/opt/stack/data/nova/instances/40fd2986-69f3-4db5-a17f-fd9ef1c69350/console.log" append="off"/> + </console> + +Full domain XML: http://paste.openstack.org/show/542597/ + +Ok, so the problem is a difference in behaviour for virtio-console vs serial ports. + +For plain x86 serial ports, if there's no client connected to the backend, any data is just discarded. + +For virtio-console, if there's no client connected to the backend, it'll refuse to send data, hence we never get to log it either. + +What i'm not sure on is whether this is supposed to work this way. The virtio-console device actually provides two separate services - a paravirt serial port and a paravirt interactive console. The paravirt serial port mode, certainly requires this behaviour, but I'm not convinced the console mode should do this. + +Patch at https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg06708.html + +Fix in 2.7.0 release thanks to + +commit bce6261eb2d879625126485d4ddd28cacb93152e +Author: Daniel P. Berrange <email address hidden> +Date: Wed Aug 3 17:22:36 2016 +0100 + + virtio-console: set frontend open permanently for console devs + + The virtio-console.c file handles both serial consoles + and interactive consoles, since they're backed by the + same device model. + + Since serial devices are expected to be reliable and + need to notify the guest when the backend is opened + or closed, the virtio-console.c file wires up support + for chardev events. This affects both serial consoles + and interactive consoles, using a network connection + based chardev backend such as 'socket', but not when + using a PTY based backend or plain 'file' backends. + + When the host side is not connected the handle_output() + method in virtio-serial-bus.c will drop any data sent + by the guest, before it even reaches the virtio-console.c + code. This means that if the chardev has a logfile + configured, the data will never get logged. + + Consider for example, configuring a x86_64 guest with a + plain UART serial port + + -chardev socket,id=charserial1,host=127.0.0.1,port=9001,server,nowait,logfile=console1.log,logappend=on + -device isa-serial,chardev=charserial1,id=serial1 + + vs a s390 guest which has to use the virtio-console port + + -chardev socket,id=charconsole1,host=127.0.0.1,port=9000,server,nowait,logfile=console2.log,logappend=on + -device virtconsole,chardev=charconsole1,id=console1 + + The isa-serial one gets data written to the log regardless + of whether a client is connected, while the virtioconsole + one only gets data written to the log when a client is + connected. + + There is no need for virtio-serial-bus.c to aggressively + drop the data for console devices, as the chardev code is + prefectly capable of discarding the data itself. + + So this patch changes virtconsole devices so that they + are always marked as having the host side open. This + ensures that the guest OS will always send any data it + has (Linux virtio-console hvc driver actually ignores + the host open state and sends data regardless, but we + should not rely on that), and also prevents the + virtio-serial-bus code prematurely discarding data. + + The behaviour of virtserialport devices is *not* changed, + only virtconsole, because for the former, it is important + that the guest OSknow exactly when the host side is opened + / closed so it can do any protocol re-negotiation that may + be required. + + Fixes bug: https://bugs.launchpad.net/qemu/+bug/1599214 + + Acked-by: Cornelia Huck <email address hidden> + Signed-off-by: Daniel P. Berrange <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Amit Shah <email address hidden> + + + diff --git a/results/classifier/118/permissions/1603693 b/results/classifier/118/permissions/1603693 new file mode 100644 index 00000000..df1a4375 --- /dev/null +++ b/results/classifier/118/permissions/1603693 @@ -0,0 +1,158 @@ +permissions: 0.944 +virtual: 0.882 +semantic: 0.876 +assembly: 0.867 +debug: 0.849 +user-level: 0.816 +architecture: 0.813 +register: 0.810 +kernel: 0.795 +performance: 0.793 +device: 0.775 +graphic: 0.768 +network: 0.767 +boot: 0.754 +hypervisor: 0.736 +arm: 0.732 +PID: 0.715 +VMM: 0.705 +risc-v: 0.691 +files: 0.678 +mistranslation: 0.663 +socket: 0.658 +ppc: 0.629 +TCG: 0.628 +vnc: 0.560 +KVM: 0.556 +peripherals: 0.545 +x86: 0.508 +i386: 0.255 + +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/118/permissions/1628 b/results/classifier/118/permissions/1628 new file mode 100644 index 00000000..fd29afca --- /dev/null +++ b/results/classifier/118/permissions/1628 @@ -0,0 +1,160 @@ +permissions: 0.818 +graphic: 0.783 +peripherals: 0.753 +hypervisor: 0.745 +debug: 0.745 +architecture: 0.743 +performance: 0.739 +mistranslation: 0.730 +semantic: 0.729 +assembly: 0.723 +network: 0.722 +PID: 0.713 +socket: 0.706 +register: 0.701 +arm: 0.697 +virtual: 0.688 +risc-v: 0.686 +vnc: 0.675 +kernel: 0.672 +device: 0.666 +user-level: 0.662 +boot: 0.661 +files: 0.649 +KVM: 0.649 +TCG: 0.637 +ppc: 0.623 +VMM: 0.617 +x86: 0.601 +i386: 0.316 + +windows 10 display scale will cause an exception +Description of problem: +windows dispaly sacle 150% or higher, windows system will exception +Steps to reproduce: +1. windows dispaly sacle 150% +Additional information: +- code in: qemu/hw/display/qxl-render.c + +static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl, + QXLDataChunk *chunk, uint32_t group_id) +{ + uint32_t max_chunks = 32; + size_t offset = 0; + size_t bytes; + for (;;) { + bytes = MIN(size - offset, chunk->data_size); + memcpy(dest + offset, chunk->data, bytes); + offset += bytes; + if (offset == size) { + return; + } + chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id, + sizeof(QXLDataChunk) + chunk->data_size); + **// get next chunk, but the chunk size use current chunk's data size, not next chunk's data size!!!!** + **// if next chunk alloc size < current chunk's data size, there will be exception ** + + if (!chunk) { + return; + } + max_chunks--; + if (max_chunks == 0) { + return; + } + } +} + + + +- code in: qxl_wddm_dod/QXLDod.cpp exist next chunk alloc size < current chunk's data size + +NTSTATUS QxlDevice::SetPointerShape(_In_ CONST DXGKARG_SETPOINTERSHAPE* pSetPointerShape) +{ +..... + res = (Resource *)AllocMem(MSPACE_TYPE_VRAM, CURSOR_ALLOC_SIZE, TRUE); // here we all the first QXLDataChunk , and alloc_size = (CURSOR_ALLOC_SIZE - sizeof(Resource) - sizeof(InternalCursor)) = 8118 + +..... + for (; src != src_end; src += pSetPointerShape->Pitch) { + if (!PutBytesAlign(&chunk, &now, &end, src, line_size, PAGE_SIZE - PAGE_SIZE % line_size, NULL)) { // in this function ,we will alloc next QXLDataChunk + .......... + break; + } + } +} + +BOOLEAN QxlDevice::PutBytesAlign(QXLDataChunk **chunk_ptr, UINT8 **now_ptr, + UINT8 **end_ptr, UINT8 *src, int size, + size_t alloc_size, PLIST_ENTRY pDelayed) +{ + ..... + size_t maxAllocSize = BITS_BUF_MAX - BITS_BUF_MAX % size; + alloc_size = MIN(alloc_size, maxAllocSize); + void *ptr = AllocMem(MSPACE_TYPE_VRAM, alloc_size + sizeof(QXLDataChunk), bForced); *** //here will alloc next QXLDataChunk and alloc_size = (PAGE_SIZE - PAGE_SIZE % line_size) = 3876 **** +} + + +eg: +dispaly sacle 150% ，mouse size will bu change to 57* 55 ，rgba data size = 12540, we need three QXLDataChunk + +QXLDataChunk* first; +first->data_size = 8118; +first->prev_chunk = 0; +first->next_chunk=second; +first->data = [alloc_size(8118), data_size(8118)] + +QXLDataChunk* second; +second->data_size = 3876; +second->prev_chunk = first; +second->next_chunk=third; +second->data = [alloc_size(3876), data_size(3876)] + +QXLDataChunk* third; +third->data_size = 546; +third->prev_chunk =second; +third->next_chunk=0; +third->data = [alloc_size(3876), data_size(546)] + + +chunk = first; +qxl_phys2virt(qxl, second, group_id, sizeof(QXLDataChunk) + 8118) + + +this size [sizeof(QXLDataChunk) + 8118] > second QXLDataChunk's alloc size , will cause qxl_get_check_slot_offset check fail + + +for second QXLDataChunk, we actual alloc size is (sizeof(QXLDataChunk) + 3876), but we assign (8118 + sizeof(QXLDataChunk)) will cause an exception + + +suggest code : + +static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl, + QXLDataChunk *chunk, uint32_t group_id) +{ + uint32_t max_chunks = 32; + size_t offset = 0; + size_t bytes; + QXLPHYSICAL next_chunk_phys = 0; + for (;;) { + bytes = MIN(size - offset, chunk->data_size); + memcpy(dest + offset, chunk->data, bytes); + offset += bytes; + if (offset == size) { + return; + } + next_chunk_phys = chunk->next_chunk; + chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id, + sizeof(QXLDataChunk)); // fist time, only get the next chunk's data size; + if (!chunk) { + return; + } + chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id, + sizeof(QXLDataChunk) + chunk->data_size); // second time, check data size and get data; + if (!chunk) { + return; + } + max_chunks--; + if (max_chunks == 0) { + return; + } + } +} diff --git a/results/classifier/118/permissions/1636 b/results/classifier/118/permissions/1636 new file mode 100644 index 00000000..a7b626f4 --- /dev/null +++ b/results/classifier/118/permissions/1636 @@ -0,0 +1,132 @@ +permissions: 0.924 +architecture: 0.889 +register: 0.862 +graphic: 0.861 +performance: 0.857 +assembly: 0.840 +device: 0.816 +virtual: 0.814 +debug: 0.812 +files: 0.789 +PID: 0.780 +semantic: 0.778 +user-level: 0.770 +socket: 0.762 +hypervisor: 0.749 +KVM: 0.742 +boot: 0.741 +arm: 0.734 +network: 0.726 +TCG: 0.725 +ppc: 0.709 +VMM: 0.706 +risc-v: 0.706 +vnc: 0.691 +kernel: 0.670 +peripherals: 0.565 +mistranslation: 0.549 +x86: 0.522 +i386: 0.338 + +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/118/permissions/1658120 b/results/classifier/118/permissions/1658120 new file mode 100644 index 00000000..99dfb9de --- /dev/null +++ b/results/classifier/118/permissions/1658120 @@ -0,0 +1,240 @@ +permissions: 0.856 +graphic: 0.838 +semantic: 0.823 +user-level: 0.818 +architecture: 0.802 +virtual: 0.789 +performance: 0.778 +device: 0.766 +arm: 0.764 +assembly: 0.759 +register: 0.759 +risc-v: 0.757 +PID: 0.757 +hypervisor: 0.745 +VMM: 0.740 +TCG: 0.733 +debug: 0.724 +peripherals: 0.724 +boot: 0.719 +x86: 0.715 +KVM: 0.711 +mistranslation: 0.711 +kernel: 0.710 +vnc: 0.679 +files: 0.678 +socket: 0.666 +network: 0.660 +ppc: 0.619 +i386: 0.237 + +building with gcc-aarch64-linux-gnu + +Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross-compiler I'm getting the following : + + +In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, + from /root/qemu/util/compatfd.c:21: +/root/qemu/util/compatfd.c: In function 'qemu_signalfd': +/root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) + ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); + ^ +/root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +/root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +make: *** [util/compatfd.o] Error 1 + + +I had configured it with : + +../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +And I'm on : + +Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Thanks + +On 20 January 2017 at 15:21, Bilal Amarni <email address hidden> wrote: +> Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross- +> compiler I'm getting the following : +> +> +> In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, +> from /root/qemu/util/compatfd.c:21: +> /root/qemu/util/compatfd.c: In function 'qemu_signalfd': +> /root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) +> ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); +> ^ +> /root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +> /root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +> make: *** [util/compatfd.o] Error 1 + +You can see from the error message that the compile has +pulled in the include file /usr/include/x86_64-linux-gnu/sys/syscall.h +from the host, which is the x86-64 version. This is an +indication that either your cross compiler is broken, or +you're not using it at all. + +> ../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +You haven't told configure to use a cross compiler at all, +so it is building with the x86 system compiler, which +doesn't work. You shouldn't need to use the --cpu argument +at all, because if you get the build to use the right +compiler it can figure that out itself. (Passing --cpu=aarch64 +tells configure "ignore the fact this is an x86 compiler +and assume it's aarch64 instead", which just results in +things breaking because that assumption is wrong.) + +You need to pass configure --cross-prefix=aarch64-linux-gnu- +You'll also need to ensure you have an aarch64-linux-gnu-pkg-config +and that you have cross versions of all QEMU's library +dependencies (notably zlib and glib) in the right place that +your cross-compiler can find them, and that your cross +pkg-config is set up to point to them. + +On Ubuntu, you may find it easier to set up a cross-architecture +chroot and do the build in that (where it looks like a native +build). Cross-compilation of software with non-trivial +dependencies is always an enormous pain in the neck. + +thanks +-- PMM + + + +Bilal Amarni <email address hidden> writes: + +> Public bug reported: +> +> Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross- +> compiler I'm getting the following : +> +> +> In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, +> from /root/qemu/util/compatfd.c:21: +> /root/qemu/util/compatfd.c: In function 'qemu_signalfd': +> /root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) +> ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); +> ^ +> /root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +> /root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +> make: *** [util/compatfd.o] Error 1 +> +> +> I had configured it with : +> +> ../configure --target-list=x86_64-linux-user --static --cpu=aarch64 +> +> And I'm on : +> +> Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 +> 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Do you have: + +/usr/include/aarch64-linux-gnu/bits/syscall.h + +In your system? + +When cross compiling it is these sort of problems come from not having +the architecture specific development files. On Ubuntu you want +something like: + + apt-get build-dep -a arm64 qemu + +-- +Alex Bennée + + +Thanks for your replies, + +I've managed to compile it using a chroot as suggested by Peter. I just grabbed a pre-built rootfs from here : https://wiki.debian.org/Arm64Port#Pre-built_Rootfses, then installed qemu-user-static with apt-get and run the build from the chroot. + +Somehow "apt-get build-dep -a arm64 qemu" didn't work, I had tried to do "dpkg --add-architecture arm64 && apt-get update" before running this command but it couldn't find the needed packages, not sure why. + +In any case thanks for your help :) + +this was an issue in my setup + +Hello everyone!! + +I am having a issue when build qemu using gcc aarch64-linux-gnu-* on ubuntu 16.04: + +dong02@dong:~/qemu$ ./configure \ +> --prefix=/usr --cross-prefix=/usr/bin/aarch64-linux-gnu- \ +> --target-list=aarch64-softmmu \ +> --enable-attr --enable-fdt --enable-kvm \ +> --enable-sdl --enable-system --enable-tools \ +> --audio-drv-list= \ +> --disable-bluez --disable-brlapi --disable-bsd-user \ +> --disable-cap-ng --disable-curl --disable-curses \ +> --disable-docs --disable-libiscsi --disable-linux-aio \ +> --disable-rbd --disable-seccomp --disable-slirp \ +> --disable-sparse --disable-spice --disable-strip \ +> --disable-usb-redir --disable-vde --disable-virtfs \ +> --disable-vnc --disable-werror --disable-xen + +ERROR: zlib check failed + Make sure to have the zlib libs and headers installed. + +I installed zlib library: sudo apt-get install zlib1g-dev. However, result no change +Please help me!! + + +Hi Cao Van Dong, + +you need to install zlib1g-dev:arm64, see: + +https://github.com/qemu/qemu/blob/master/tests/docker/dockerfiles/debian-arm64-cross.docker + +Regards, + +Phil. + + +Cao Van Dong <email address hidden> writes: + +> Hello everyone!! +> +> I am having a issue when build qemu using gcc aarch64-linux-gnu-* on +> ubuntu 16.04: +> +> dong02@dong:~/qemu$ ./configure \ +>> --prefix=/usr --cross-prefix=/usr/bin/aarch64-linux-gnu- \ +>> --target-list=aarch64-softmmu \ +>> --enable-attr --enable-fdt --enable-kvm \ +>> --enable-sdl --enable-system --enable-tools \ +>> --audio-drv-list= \ +>> --disable-bluez --disable-brlapi --disable-bsd-user \ +>> --disable-cap-ng --disable-curl --disable-curses \ +>> --disable-docs --disable-libiscsi --disable-linux-aio \ +>> --disable-rbd --disable-seccomp --disable-slirp \ +>> --disable-sparse --disable-spice --disable-strip \ +>> --disable-usb-redir --disable-vde --disable-virtfs \ +>> --disable-vnc --disable-werror --disable-xen +> +> ERROR: zlib check failed +> Make sure to have the zlib libs and headers installed. +> +> I installed zlib library: sudo apt-get install zlib1g-dev. However, result no change +> Please help me!! + +You will have installed the x86 version of the zlib1g-dev libraries. +Unfortunately headers are not uniform across all architectures. + +If you want to ensure you have all the appropriate headers for cross +compiling QEMU do: + + apt-get build-dep -a arm64 qemu + +But you may well run into problems if the distribution isn't fully +multi-arch clean. This is one of the reasons we use docker to isolate +our various cross build environments: + + make docker-test-build@debian-arm64-cross J=9 TARGET_LIST=aarch64-softmmu + +-- +Alex Bennée + + diff --git a/results/classifier/118/permissions/1668103 b/results/classifier/118/permissions/1668103 new file mode 100644 index 00000000..ebfad9cd --- /dev/null +++ b/results/classifier/118/permissions/1668103 @@ -0,0 +1,100 @@ +permissions: 0.942 +semantic: 0.930 +virtual: 0.921 +arm: 0.918 +architecture: 0.909 +device: 0.905 +PID: 0.900 +graphic: 0.898 +register: 0.898 +VMM: 0.887 +performance: 0.887 +debug: 0.883 +vnc: 0.882 +assembly: 0.881 +peripherals: 0.881 +network: 0.880 +socket: 0.875 +boot: 0.863 +user-level: 0.851 +mistranslation: 0.847 +files: 0.842 +hypervisor: 0.841 +kernel: 0.828 +TCG: 0.819 +risc-v: 0.805 +ppc: 0.794 +KVM: 0.787 +i386: 0.774 +x86: 0.736 + +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/118/permissions/1670377 b/results/classifier/118/permissions/1670377 new file mode 100644 index 00000000..a8aafed2 --- /dev/null +++ b/results/classifier/118/permissions/1670377 @@ -0,0 +1,129 @@ +permissions: 0.833 +semantic: 0.751 +PID: 0.736 +graphic: 0.735 +register: 0.717 +architecture: 0.715 +debug: 0.715 +virtual: 0.713 +assembly: 0.707 +user-level: 0.702 +performance: 0.694 +arm: 0.693 +device: 0.683 +network: 0.681 +files: 0.666 +peripherals: 0.656 +x86: 0.638 +risc-v: 0.629 +vnc: 0.624 +TCG: 0.620 +kernel: 0.615 +VMM: 0.556 +boot: 0.513 +hypervisor: 0.509 +KVM: 0.505 +socket: 0.486 +i386: 0.481 +ppc: 0.477 +mistranslation: 0.437 + + VNC: short read for zlre data/RDR EndOfStream + +In openQA we have a custom VNC client (https://github.com/os-autoinst/os-autoinst/tree/master/consoles), which connects to QEMU guest and from there performs actions (sends keys, handles pointer, ...). We have several backends (https://github.com/os-autoinst/os-autoinst/tree/master/backend). With qemu backend we start QEMU guest *locally* on openQA worker which connects to it via VNC and sends commands. That works fine. + +However, with svirt backend we start QEMU on a KVM or Xen host and then connect to it remotely from openQA worker - the guest and worker are different systems. In this scenario fairly often happens that while system operates in Grub2, QEMU stops sending data via VNC: + +... +15:24:15.5341 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:50 called testapi::send_key +15:24:15.5342 27074 <<< testapi::send_key(key='c') +15:24:15.7361 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:51 called testapi::type_string +15:24:15.7362 27074 <<< testapi::type_string(string='gfxmode=1024x768; terminal_output console; terminal_output gfxterm +', max_interval=250, wait_screen_changes=0) +15:24:22.2243 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:53 called testapi::send_key +15:24:22.2244 27074 <<< testapi::send_key(key='esc') +15:24:22.4255 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:79 called testapi::send_key +15:24:22.4256 27074 <<< testapi::send_key(key='e') +15:24:22.6264 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:22.6265 27074 <<< testapi::send_key(key='down') +15:24:22.8273 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:22.8274 27074 <<< testapi::send_key(key='down') +15:24:23.0282 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:23.0283 27074 <<< testapi::send_key(key='down') +DIE short read for zlre data 107132 - 995002 at /usr/lib/os-autoinst/consoles/VNC.pm line 978. + + at /usr/lib/os-autoinst/backend/baseclass.pm line 73. +... + +My observation is that it happens only while in Grub, when resolution happened a short while ago. See attached video and log. + +Prior to QEMU 2.8.0 I was able to reproduce a similar issue with vncviewer. I started QEMU with SLES JeOS image pressed several times a 'down' key in Grub and vncviewer (Tiger VNC 1.6.0 from openSUSE Leap 42.2) crashed with rdr::EndOfStream exception. This does not happen with QEMU 2.8.0, but I am still able to reproduce similar issue via openQA. + +/usr/bin/qemu-system-x86_64 -name guest=openQA-SUT-20,debug-threads=on -S -machine pc-i440fx-2.6,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 87535fc1-e693-41b9-813e-834d6fc4cb5a -no-user-config -nodefaults -rtc base=utc -no-reboot -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/openQA-SUT-20.img,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:12:34:56,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-tablet-pci,id=input0,bus=pci.0,addr=0x6 -device virtio-keyboard-pci,id=input1,bus=pci.0,addr=0x7 -vnc 0.0.0.0:20,share=force-shared -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on -monitor stdio + +Host: openSUSE Leap 42.2 x86_64 KVM or Xen on x86_64 Intel with QEMU 2.6.0. +Guest: Leap 42.2. + +I can't reproduce the problem with QEMU 2.5.0, but I can with any QEMU version from 2.6 RC1 on. + + + + + +It isn't 100% clear from the info provided, but this is almost certainly fixed in 2.9.0 by + +commit 537848ee62195fc06c328b1cd64f4218f404a7f1 +Author: Michael Tokarev <email address hidden> +Date: Fri Feb 3 12:52:29 2017 +0300 + + vnc: do not disconnect on EAGAIN + + When qemu vnc server is trying to send large update to clients, + there might be a situation when system responds with something + like EAGAIN, indicating that there's no system memory to send + that much data (depending on the network speed, client and server + and what is happening). In this case, something like this happens + on qemu side (from strace): + + sendmsg(16, {msg_name(0)=NULL, + msg_iov(1)=[{"\244\"..., 729186}], + msg_controllen=0, msg_flags=0}, 0) = 103950 + sendmsg(16, {msg_name(0)=NULL, + msg_iov(1)=[{"lz\346"..., 1559618}], + msg_controllen=0, msg_flags=0}, 0) = -1 EAGAIN + sendmsg(-1, {msg_name(0)=NULL, + msg_iov(1)=[{"lz\346"..., 1559618}], + msg_controllen=0, msg_flags=0}, 0) = -1 EBADF + + qemu closes the socket before the retry, and obviously it gets EBADF + when trying to send to -1. + + This is because there WAS a special handling for EAGAIN, but now it doesn't + work anymore, after commit 04d2529da27db512dcbd5e99d0e26d333f16efcc, because + now in all error-like cases we initiate vnc disconnect. + + This change were introduced in qemu 2.6, and caused numerous grief for many + people, resulting in their vnc clients reporting sporadic random disconnects + from vnc server. + + Fix that by doing the disconnect only when necessary, i.e. omitting this + very case of EAGAIN. + + Hopefully the existing condition (comparing with QIO_CHANNEL_ERR_BLOCK) + is sufficient, as the original code (before the above commit) were + checking for other errno values too. + + Apparently there's another (semi?)bug exist somewhere here, since the + code tries to write to fd# -1, it probably should check if the connection + is open before. But this isn't important. + + Signed-off-by: Michael Tokarev <email address hidden> + Reviewed-by: Daniel P. Berrange <email address hidden> + Message-id: <email address hidden> + Fixes: 04d2529da27db512dcbd5e99d0e26d333f16efcc + Cc: Daniel P. Berrange <email address hidden> + Cc: Gerd Hoffmann <email address hidden> + Cc: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + + diff --git a/results/classifier/118/permissions/1672365 b/results/classifier/118/permissions/1672365 new file mode 100644 index 00000000..634a095a --- /dev/null +++ b/results/classifier/118/permissions/1672365 @@ -0,0 +1,83 @@ +permissions: 0.892 +architecture: 0.857 +user-level: 0.856 +performance: 0.853 +device: 0.838 +mistranslation: 0.836 +virtual: 0.829 +peripherals: 0.828 +vnc: 0.816 +graphic: 0.811 +network: 0.810 +register: 0.796 +boot: 0.793 +files: 0.787 +TCG: 0.785 +kernel: 0.785 +semantic: 0.783 +assembly: 0.779 +hypervisor: 0.776 +KVM: 0.768 +ppc: 0.767 +socket: 0.760 +PID: 0.748 +risc-v: 0.741 +debug: 0.736 +arm: 0.732 +VMM: 0.730 +x86: 0.713 +i386: 0.428 + +nested 9pfs read fail + +tl;dr: A virtfs read fails. The init being on this virtfs (mounted by the initrd), the linux kernel guest is unable to boot, and kernel panics. The fact that qemu still takes 100%cpu after the kernel panic makes me think it's a qemu bug. + +Here is the setup (some hashes replaced with "..."): + * A (NixOS) host system, with /nix/store as a btrfs on lvm on cryptsetup + * Running a qemu-kvm NixOS guest, with /nix/.ro-store as a virtfs mapping to host /nix/store: +``` +exec /nix/store/...-qemu-x86-only-for-vm-tests-2.8.0/bin/qemu-kvm \ + -name test \ + -m 8192 \ + -cpu kvm64 \ + -net nic,vlan=0,model=virtio -net user,vlan=0 \ + -virtfs local,path=/nix/store,security_model=none,mount_tag=store \ + -virtfs local,path=/tmp/nix-vm..../xchg,security_model=none,mount_tag=xchg \ + -virtfs local,path=/tmp/nix-vm..../xchg,security_model=none,mount_tag=shared \ + -drive index=0,id=drive1,file=/home/ekleog/nixos/test.qcow2,if=virtio,cache=writeback,werror=report \ +-kernel /nix/store/...-nixos-system-test-17.09.git.deee8da/kernel \ +-initrd /nix/store/...-nixos-system-test-17.09.git.deee8da/initrd \ +-append "$(cat /nix/store/...-nixos-system-test-17.09.git.deee8da/kernel-params) init=/nix/store/...-nixos-system-test-17.09.git.deee8da/init regInfo=/nix/store/...-reginfo" \ + -vga std -usbdevice tablet +``` + * With /nix/store as an overlayfs between /nix/.ro-store and /nix/.rw-store + * Running a qemu-kvm NixOS guest, with /nix/.ro-store as a virtfs mapping to host /nix/store/...-vm-nginx-store: +``` +/nix/store/...-qemu-2.8.0/bin/qemu-kvm \ + -name nginx -m 128 -smp 2 -cpu kvm64 \ + -nographic -serial unix:"/var/lib/vm/consoles/nginx/socket.unix",server,nowait \ + -drive file="/var/lib/vm/images/nginx.img",if=virtio,media=disk \ + -virtfs local,path="/nix/store/...-vm-nginx-store",security_model=none,mount_tag=store \ + -netdev type=tap,id=net0,ifname=vm-nginx,script=no,dscript=no -device virtio-net-pci,netdev=net0,mac=56:00:00:00:00:01 \ + -kernel /nix/store/...-nixos-system-nginx-17.09.git.deee8da/kernel \ + -initrd /nix/store/...-nixos-system-nginx-17.09.git.deee8da/initrd \ + -append "$(cat /nix/store/...-nixos-system-nginx-17.09.git.deee8da/kernel-params) init=/nix/store/...-nixos-system-nginx-17.09.git.deee8da/init console=ttyS0 boot.shell_on_fail" \ + -virtfs local,path="/var/lib/vm/persist/nginx/home",security_model=mapped-xattr,mount_tag="shared1" \ + -virtfs local,path="/var/lib",security_model=mapped-xattr,mount_tag="shared2" \ + -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared3" +``` + * With /nix/store as an overlayfs between /nix/.ro-store and /nix/.rw-store + * With init in /nix/store + +What happens is that at boot time the inner VM doesn't manage to read the init script after the initrd has mounted the 9pfs and overlayfs. + +What makes me think it's a qemu bug is that htop in the outer VM shows the inner VM's qemu as using 100% cpu, despite the fact the kernel it's running is under kernel panic, thus doing nothing. + +What do you think about this? + +Oh, I forgot to mention: it first worked for some time, then in the middle of a shell session running over a screen /var/lib/vm/consoles/nginx/screen from the outer VM (socat-linked to /var/lib/vm/consoles/nginx/socket.unix to provide a predictable pty link), the 9pfs stopped returning any data, and it didn't go away after a reboot of the inner VM, as it then no longer managed to boot. + +I was unfortunately unable to identify exactly which operation caused the thing to "stop working", but I'd say it is due to zsh's path-full autocompletion in paths including directories with ~700 entries, without being certain of that. + +Hmm, actually it looks like a kernel in kernel panic always takes 100% CPU (just got another unrelated one), so I guess it's not necessarily a qemu bug but can arise from anywhere in the stack. I'm marking the bug as invalid as a consequence. + diff --git a/results/classifier/118/permissions/1682681 b/results/classifier/118/permissions/1682681 new file mode 100644 index 00000000..2b73bc24 --- /dev/null +++ b/results/classifier/118/permissions/1682681 @@ -0,0 +1,107 @@ +permissions: 0.801 +performance: 0.782 +semantic: 0.770 +graphic: 0.769 +user-level: 0.769 +network: 0.747 +register: 0.744 +assembly: 0.742 +architecture: 0.736 +PID: 0.732 +peripherals: 0.727 +virtual: 0.726 +device: 0.716 +arm: 0.694 +debug: 0.681 +kernel: 0.676 +ppc: 0.674 +files: 0.651 +socket: 0.642 +boot: 0.638 +mistranslation: 0.637 +risc-v: 0.608 +hypervisor: 0.604 +vnc: 0.577 +VMM: 0.559 +TCG: 0.522 +KVM: 0.491 +x86: 0.320 +i386: 0.297 + +qemu 2.5 network model rtl8139 collisions Ubuntu 16.04.2 LTS + +When I use NIC model rtl8139, I have a lot collisions and very low transfer. +I tested that with brctl and Open vSwitch, because I thought that was a vSwitch issue. +When I change NIC model to virtio all works as expect. + +Host: Ubuntu 16.04.2 LTS +Guest: Ubuntu 14.04.5 LTS - affected +Guest: Ubuntu 16.04.2 LTS - not affected + +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.10) + +Thanks Thomas for reassigning, and hi Bartłomeij, +Btw - I'd recommend very much to user virtio over rtl driver anyway [1], but that is not the point here. + +Thanks for retesting with brctl and moving OVS out of the equation already. +The difference certainly is within the guest drivers for that network card between the 14.04 and 16.04 guest. + +I checked the changes we had in between the respective kernels and there were not that much for the drivers themselves at least. Mostly bug fixes and while it could be anything else in the kernels this is certainly worth a quick test. There is one in particular which could be interesting that enabled TSO offloading by default. +You can check in your guests with + $ ethtool -k <device> +what the offloads currently are. +Please check if more differ than just TSO (usually the list grows the newer things get). +Then on the 16.04 guest modify the config one-by-one to match the one you have seen with the 14.04 guest. +If you happen to find a single offload feature that switches good/bad behavior get back here. + +Furthermore we can exclude other packages here by using the HWE kernels [2]. Could you confirm that the 14.04 guest with the HWE-x kernel booted shows the same bad behavior? +That would exclude anything of 16.04 other than the kernel to cause the difference. + +If so it would be great to further shrink the range we are looking at by trying HWE- +To do so in your case take the 14.04 the guest and install the packages +linux-image-virtual-lts-utopic, linux-image-virtual-lts-vivid, linux-image-virtual-lts-wily, linux-image-virtual-lts-xenial. Then modify the boot loader (or interactively select at the prompt) to boot one after the other and check your results as well as the maybe related offload settings of above. + +Also to better reproduce this could you outline what kind/direction of workload you are testing +- Is it Guest-to-Guest or Traffic from the outside? +- What is the network traffic you are using, can it be in archive net tools or only a custom workload in your setup? + +Summary: +- please verify that the same happens in 14.04 + HWE+x kernel (go on with that setup if it shows the issue) +- please check different HWE level which is the first to show the issue (go on with the oldest of the HWE kernels that show the issue) +- please compare and test different offload settings as outlined above +- please describe your workload more in Details so that we can try to reproduce + +[1]: http://www.linux-kvm.org/page/Tuning_KVM +[2]: https://wiki.ubuntu.com/Kernel/LTSEnablementStack + +A quick check on a Trusty Guest modified from the uvt default of virtio to use rtl8139 and then moving into the kernel that is likely the reason shows me this for a trivial 1 connection duplex iperf streaming load to the Host: + +Release Nettype Kernel - Result +1. 14.04 virtio 3.13.0-116 - ~11 + 8 GBits/s +2. 14.04 rtl8139 3.13.0-116 - 124 + 824 Mbits/s +3. 14.04 rtl8139 4.4.0-72 - 758 + 703 MBits/s +4. 14.04 rtl8139 4.4.0-72 - 115 + 795 MBits/s + +Notes: +On #2: I already see 13k receive drops here +on #3: I can confirm TSO, GSO, SG and IP Checksum offloads on as expected, they help to speed up my load despite now seeing 26k receive drops +On #4: slow again back to ~14k drops + +Note: disabling offloads via: +$ sudo ethtool -K eth0 tx-tcp-segmentation off +$ sudo ethtool -K eth0 tx-checksum-ipv4 off +$ sudo ethtool -K eth0 tx-scatter-gather off + +There is quite a chance that the generally much better behavior of enabling those offloads for your specific case it is a drawback. In that case please check with the disabling of the offloads and help to clarify the details I asked for. + +Yet overall IMHO - as I stated in my first comment - I'd strongly vote to use the virtio driver and be much faster than any rtl8139 based network would be. + +The affected Ubuntu 14.04.5 LTS has kernel HWE 4.4.0-72-generic + +Usually I'm using virtio but that was first time when I used vSwitch and I would rather start with rtl8139. + +Because that is my production env I need to prepare new VMs. It's take me few days. + + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1686170 b/results/classifier/118/permissions/1686170 new file mode 100644 index 00000000..64f3ebc8 --- /dev/null +++ b/results/classifier/118/permissions/1686170 @@ -0,0 +1,441 @@ +permissions: 0.931 +graphic: 0.899 +hypervisor: 0.888 +debug: 0.888 +register: 0.887 +user-level: 0.877 +peripherals: 0.876 +x86: 0.868 +semantic: 0.862 +TCG: 0.862 +KVM: 0.862 +performance: 0.857 +i386: 0.847 +mistranslation: 0.847 +assembly: 0.840 +boot: 0.836 +device: 0.826 +risc-v: 0.807 +architecture: 0.801 +vnc: 0.798 +VMM: 0.789 +arm: 0.784 +files: 0.780 +virtual: 0.770 +PID: 0.760 +ppc: 0.751 +kernel: 0.728 +socket: 0.727 +network: 0.725 + +qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options + +OS: Void Linux x86_64 (glibc) +QEMU version: 2.9.0 +GDB version: 7.12.1 + +Problem description: + +After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'. +To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult. + +Steps to reproduce: + +- Run QEMU +- In another terminal, run GDB +- In GDB, connect to QEMU +- In GDB, disassemble some Real mode machine code. + +Expected results (from QEMU version 2.8.1): + + [terminal #1] + $ qemu-system-x86_64 -S -s + + [terminal #2] + (gdb) set architecture i8086 + warning: A handler for the OS ABI "GNU/Linux" is not built + into this configuration + of GDB. Attempting to continue with the default i8086 settings. + + The target architecture is assumed to be i8086 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x0000fff0 in ?? () + (gdb) x/i $cs*16+$eip + 0xffff0: ljmp $0xf000,$0xe05b + +Actual results: + + [terminal #1] + $ qemu-system-x86_64 -S -s + + [terminal #2] + $ gdb -q + (gdb) set architecture i8086 + warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration + of GDB. Attempting to continue with the default i8086 settings. + + The target architecture is assumed to be i8086 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + Remote 'g' packet reply is too long: + [..snip..] + +Workarounds tried: + + - Try different architecures + (gdb) set architecture i386:intel + The target architecture is assumed to be i386:intel + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + Remote 'g' packet reply is too long: + [..snip..] + (gdb) set architecture i386:x86-64 + The target architecture is assumed to be i386:x86-64 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x000000000000fff0 in ?? () + +The last try finally allowed me to connect to QEMU, but as can be expected from using an incorrect architecture setting, disassembly output is complete gibberish: + + (gdb) x/10i $cs*16+$rip + 0xffff0: (bad) + 0xffff1: pop %rbx + 0xffff2: loopne 0xffff4 + 0xffff4: lock xor %dh,(%rsi) + 0xffff7: (bad) + 0xffff8: xor (%rbx),%dh + 0xffffa: (bad) + 0xffffb: cmp %edi,(%rcx) + 0xffffd: add %bh,%ah + 0xfffff: add %al,(%rax) + +Discussion: + +I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1]. +While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features. + +In fact, there is a well-known workaround to this problem published on OSDev Wiki (Workaround #1)[2] which doesn't require patching either QEMU or GDB. This workaround has worked for me using several previous versions of QEMU. + + $ gdb -q + (gdb) set architecture i8086 + (gdb) target remote :1234 + (gdb) break some_breakpoint_in_32_bit_or_64_bit_code + (gdb) continue + [...] + Remote 'g' packet reply is too long: [...] + (gdb) disconnect # IMPORTANT STEP #1 + (gdb) set architecture i386:x86-64 + (gdb) target remote :1234 # IMPORTANT STEP #2 + (gdb) continue + +[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b +[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting + +If it is decided to retain the change, please do consider adding a commandline option to enable debugging Real mode code after `set architecture i8086`, even if this requires the GDB workaround previously mentioned. Thanks in advance. + +Apparently none of the 32bit x86 modes are supported in 2.9 version of qemu-system-x86_64. I realize the desire to simplify the code, and separate i386 from x86_64, but x86_64 really does need to support all the modes in which the processor can operate. True that for major operating systems the processor is only briefly in any 32bit mode, but for boot ROM and boot loader work, and non-mainstream kernels we still very much need 32bit support *in* the x86_64 qemu. + +Previously the 'g' RDP query (gdbstub.c:1056) would send a different length of reg data depending on in which mode the cpu was currently operating. Although maybe not a great ABI, it was sufficient to tell exactly when the cpu changed states and front end debuggers need to know this. + +Unfortunately the much more portable new .xml register definition scheme needs to be changed to properly support multiple register sets (with different names sizes etc.), but x86 is not the only processor to have multiple personalities. + An example implementation for x86 could be that the "top" level xml file i386-64bit.xml describes all the different possible modes (something like): + +<feature name="org.gnu.gdb.i386.64bit"> + <xi:include href="i386-64bit-core.xml"/> + <xi:include href="i386-64bit-sse.xml"/> +</feature> +<feature name="org.gnu.gdb.i386.32bit.protectedmode"> + <xi:include href="i386-32bit-core.xml"/> + <xi:include href="i386-32bit-sse.xml"/> +</feature> +<feature name="org.gnu.gdb.i386.32bit.realmode"> + <xi:include href="i386-i8086-core.xml"/> +</feature> + +all of which are loaded when the frontend starts. The 'g' RDP response should then start with one of the feature names (or an abbreviated unique id). + +In fact, ring0 vs ring1-3 should likely also have different xml files as the crX config registers need to be sent when in ring 0 as well. + + +Commit that made this change: + +https://github.com/qemu/qemu/commit/00fcd100c3f47445f6a59d39e11601460880cfe4#diff-b8f1948d6e81e8ccdbe828ba7973c483 + + +Hi, +are there any updates on this issue? + +I'm using qemu 2.11.1 and I believe I'm experiencing the same problem explained by Duane. +I'm unable to debug with gdb 32-bit kernel code using qemu-system-x86_64. GDB complains that the target architecture is x86_64, even if VM's CPU is currently running in 32-bit protected mode. + +Steps to reproduce: +- qemu-system-x86_64 -s -hda <a bootable image using PM32> [note: no need to use -S] +- gdb +- (in gdb): set arch i386 +- (in gdb): target remote localhost:1234 [note: no need to specify an ELF binary] + +I get: +Remote debugging using localhost:1234 +warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 +warning: No executable has been specified and target does not support +determining executable automatically. Try using the "file" command. +Remote 'g' packet reply is too long (expected 312 bytes, got 536 bytes): [SKIPPING the raw data] + +Unfortunately, I was unable to find any workaround. +Not even patching GDB as suggested here https://wiki.osdev.org/QEMU_and_GDB_in_long_mode +really works (because forcing GDB to ignore the exceeding data, does not really solve the whole problem). + +I remember that with older versions of qemu the behavior was different and by just using gdb's "set arch" command I was able to debug both 32-bit and 64-bit code running on a x86_64 qemu VM. + +Could the older behavior be restored somehow? Even by adding an ad-hoc command-line option would be OK. + +Thanks a lot, +Vlad + + + + + + + + + + +I had the same issue. My workaround is to force the target description to be loaded from a local xml file where the architecture tag is i8086. I took the one that was sent over the network from the server to the client and changed the architecture tag from i386 to i8086 and also the size of the i386_efer flags from 8 to 4. + +$ gdb -q +(gdb) set tdesc filename ./target.xml +(gdb) target remote :29096 +... +(gdb) x/i 0x10*$cs+$pc + 0xffff0: ljmp $0xf000,$0xe05b +(gdb) quit + +$ cat target.xml +<?xml version="1.0"?> + +<!-- Copyright (C) 2010-2017 Free Software Foundation, Inc. + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. --> + +<!-- I386 with SSE --> + +<!DOCTYPE target SYSTEM "gdb-target.dtd"> +<target> +<architecture>i8086</architecture> +<feature name="org.gnu.gdb.i386.core"> + <flags id="i386_eflags" size="4"> + <field name="" start="22" end="31"/> + <field name="ID" start="21" end="21"/> + <field name="VIP" start="20" end="20"/> + <field name="VIF" start="19" end="19"/> + <field name="AC" start="18" end="18"/> + <field name="VM" start="17" end="17"/> + <field name="RF" start="16" end="16"/> + <field name="" start="15" end="15"/> + <field name="NT" start="14" end="14"/> + <field name="IOPL" start="12" end="13"/> + <field name="OF" start="11" end="11"/> + <field name="DF" start="10" end="10"/> + <field name="IF" start="9" end="9"/> + <field name="TF" start="8" end="8"/> + <field name="SF" start="7" end="7"/> + <field name="ZF" start="6" end="6"/> + <field name="" start="5" end="5"/> + <field name="AF" start="4" end="4"/> + <field name="" start="3" end="3"/> + <field name="PF" start="2" end="2"/> + <field name="" start="1" end="1"/> + <field name="CF" start="0" end="0"/> + </flags> + + <reg name="eax" bitsize="32" type="int32" regnum="0"/> + <reg name="ecx" bitsize="32" type="int32"/> + <reg name="edx" bitsize="32" type="int32"/> + <reg name="ebx" bitsize="32" type="int32"/> + <reg name="esp" bitsize="32" type="data_ptr"/> + <reg name="ebp" bitsize="32" type="data_ptr"/> + <reg name="esi" bitsize="32" type="int32"/> + <reg name="edi" bitsize="32" type="int32"/> + + <reg name="eip" bitsize="32" type="code_ptr"/> + <reg name="eflags" bitsize="32" type="i386_eflags"/> + + <reg name="cs" bitsize="32" type="int32"/> + <reg name="ss" bitsize="32" type="int32"/> + <reg name="ds" bitsize="32" type="int32"/> + <reg name="es" bitsize="32" type="int32"/> + <reg name="fs" bitsize="32" type="int32"/> + <reg name="gs" bitsize="32" type="int32"/> + + <!--reg name="cs_base" bitsize="32" type="int32"/> + <reg name="ss_base" bitsize="32" type="int32"/> + <reg name="ds_base" bitsize="32" type="int32"/> + <reg name="es_base" bitsize="32" type="int32"/--> + <reg name="fs_base" bitsize="32" type="int32"/> + <reg name="gs_base" bitsize="32" type="int32"/> + <reg name="k_gs_base" bitsize="32" type="int32"/> + + <flags id="i386_cr0" size="4"> + <field name="PG" start="31" end="31"/> + <field name="CD" start="30" end="30"/> + <field name="NW" start="29" end="29"/> + <field name="AM" start="18" end="18"/> + <field name="WP" start="16" end="16"/> + <field name="NE" start="5" end="5"/> + <field name="ET" start="4" end="4"/> + <field name="TS" start="3" end="3"/> + <field name="EM" start="2" end="2"/> + <field name="MP" start="1" end="1"/> + <field name="PE" start="0" end="0"/> + </flags> + + <flags id="i386_cr3" size="4"> + <field name="PDBR" start="12" end="31"/> + <!--field name="" start="3" end="11"/> + <field name="WT" start="2" end="2"/> + <field name="CD" start="1" end="1"/> + <field name="" start="0" end="0"/--> + <field name="PCID" start="0" end="11"/> + </flags> + + <flags id="i386_cr4" size="4"> + <field name="VME" start="0" end="0"/> + <field name="PVI" start="1" end="1"/> + <field name="TSD" start="2" end="2"/> + <field name="DE" start="3" end="3"/> + <field name="PSE" start="4" end="4"/> + <field name="PAE" start="5" end="5"/> + <field name="MCE" start="6" end="6"/> + <field name="PGE" start="7" end="7"/> + <field name="PCE" start="8" end="8"/> + <field name="OSFXSR" start="9" end="9"/> + <field name="OSXMMEXCPT" start="10" end="10"/> + <field name="UMIP" start="11" end="11"/> + <field name="LA57" start="12" end="12"/> + <field name="VMXE" start="13" end="13"/> + <field name="SMXE" start="14" end="14"/> + <field name="FSGSBASE" start="16" end="16"/> + <field name="PCIDE" start="17" end="17"/> + <field name="OSXSAVE" start="18" end="18"/> + <field name="SMEP" start="20" end="20"/> + <field name="SMAP" start="21" end="21"/> + <field name="PKE" start="22" end="22"/> + </flags> + + <flags id="i386_efer" size="4"> + <field name="TCE" start="15" end="15"/> + <field name="FFXSR" start="14" end="14"/> + <field name="LMSLE" start="13" end="13"/> + <field name="SVME" start="12" end="12"/> + <field name="NXE" start="11" end="11"/> + <field name="LMA" start="10" end="10"/> + <field name="LME" start="8" end="8"/> + <field name="SCE" start="0" end="0"/> + </flags> + + <reg name="cr0" bitsize="32" type="i386_cr0"/> + <reg name="cr2" bitsize="32" type="int32"/> + <reg name="cr3" bitsize="32" type="i386_cr3"/> + <reg name="cr4" bitsize="32" type="i386_cr4"/> + <reg name="cr8" bitsize="32" type="int32"/> + <reg name="efer" bitsize="32" type="i386_efer"/> + + <reg name="st0" bitsize="80" type="i387_ext"/> + <reg name="st1" bitsize="80" type="i387_ext"/> + <reg name="st2" bitsize="80" type="i387_ext"/> + <reg name="st3" bitsize="80" type="i387_ext"/> + <reg name="st4" bitsize="80" type="i387_ext"/> + <reg name="st5" bitsize="80" type="i387_ext"/> + <reg name="st6" bitsize="80" type="i387_ext"/> + <reg name="st7" bitsize="80" type="i387_ext"/> + + <reg name="fctrl" bitsize="32" type="int" group="float"/> + <reg name="fstat" bitsize="32" type="int" group="float"/> + <reg name="ftag" bitsize="32" type="int" group="float"/> + <reg name="fiseg" bitsize="32" type="int" group="float"/> + <reg name="fioff" bitsize="32" type="int" group="float"/> + <reg name="foseg" bitsize="32" type="int" group="float"/> + <reg name="fooff" bitsize="32" type="int" group="float"/> + <reg name="fop" bitsize="32" type="int" group="float"/> +<!--/feature> +<feature name="org.gnu.gdb.i386.32bit.sse"--> + <vector id="v4f" type="ieee_single" count="4"/> + <vector id="v2d" type="ieee_double" count="2"/> + <vector id="v16i8" type="int8" count="16"/> + <vector id="v8i16" type="int16" count="8"/> + <vector id="v4i32" type="int32" count="4"/> + <vector id="v2i64" type="int64" count="2"/> + <union id="vec128"> + <field name="v4_float" type="v4f"/> + <field name="v2_double" type="v2d"/> + <field name="v16_int8" type="v16i8"/> + <field name="v8_int16" type="v8i16"/> + <field name="v4_int32" type="v4i32"/> + <field name="v2_int64" type="v2i64"/> + <field name="uint128" type="uint128"/> + </union> + <flags id="i386_mxcsr" size="4"> + <field name="IE" start="0" end="0"/> + <field name="DE" start="1" end="1"/> + <field name="ZE" start="2" end="2"/> + <field name="OE" start="3" end="3"/> + <field name="UE" start="4" end="4"/> + <field name="PE" start="5" end="5"/> + <field name="DAZ" start="6" end="6"/> + <field name="IM" start="7" end="7"/> + <field name="DM" start="8" end="8"/> + <field name="ZM" start="9" end="9"/> + <field name="OM" start="10" end="10"/> + <field name="UM" start="11" end="11"/> + <field name="PM" start="12" end="12"/> + <field name="FZ" start="15" end="15"/> + </flags> + + <reg name="xmm0" bitsize="128" type="vec128"/> + <reg name="xmm1" bitsize="128" type="vec128"/> + <reg name="xmm2" bitsize="128" type="vec128"/> + <reg name="xmm3" bitsize="128" type="vec128"/> + <reg name="xmm4" bitsize="128" type="vec128"/> + <reg name="xmm5" bitsize="128" type="vec128"/> + <reg name="xmm6" bitsize="128" type="vec128"/> + <reg name="xmm7" bitsize="128" type="vec128"/> + + <reg name="mxcsr" bitsize="32" type="i386_mxcsr" group="vector"/> +</feature> +</target> + + +I had the same problem when I tried to run [boot.asm](https://github.com/yifengyou/The-design-and-implementation-of-a-64-bit-os/blob/master/code/c03/1/boot.asm). + +i tested `qemu-system-x86_64` and `qemu-system-i386` with [gdb_init_real_mode.txt](https://github.com/mhugo/gdb_init_real_mode/blob/master/gdbinit_real_mode.txt) and [target.xml](https://gist.githubusercontent.com/MatanShahar/1441433e19637cf1bb46b1aa38a90815/raw/2687fb5daf60cf6aa8435efc8450d89f1ccf2205/target.xml), all faild. + +my env: +1. deepin 15.11 x86_64 + + - qemu: QEMU emulator version 4.2.94 // qemu 5.0.0-rc4 + - gdb: GNU gdb (Debian 7.12-6) 7.12.0.20161007-git +1. ubuntu 20.04 + + - qemu: QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6) + - gdb: GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1 + + +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/141 + + diff --git a/results/classifier/118/permissions/1687270 b/results/classifier/118/permissions/1687270 new file mode 100644 index 00000000..0bb00bee --- /dev/null +++ b/results/classifier/118/permissions/1687270 @@ -0,0 +1,51 @@ +permissions: 0.965 +files: 0.952 +virtual: 0.940 +device: 0.755 +hypervisor: 0.735 +graphic: 0.725 +performance: 0.705 +semantic: 0.686 +architecture: 0.669 +network: 0.655 +ppc: 0.621 +user-level: 0.619 +register: 0.607 +vnc: 0.583 +VMM: 0.563 +risc-v: 0.560 +socket: 0.558 +peripherals: 0.543 +i386: 0.541 +boot: 0.541 +kernel: 0.538 +mistranslation: 0.511 +arm: 0.495 +x86: 0.494 +PID: 0.446 +assembly: 0.435 +TCG: 0.417 +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/118/permissions/1689 b/results/classifier/118/permissions/1689 new file mode 100644 index 00000000..42f6bafc --- /dev/null +++ b/results/classifier/118/permissions/1689 @@ -0,0 +1,41 @@ +permissions: 0.983 +mistranslation: 0.968 +boot: 0.943 +files: 0.933 +performance: 0.922 +device: 0.890 +graphic: 0.882 +semantic: 0.851 +peripherals: 0.814 +architecture: 0.809 +debug: 0.699 +ppc: 0.647 +user-level: 0.601 +x86: 0.579 +i386: 0.568 +network: 0.560 +PID: 0.557 +vnc: 0.547 +risc-v: 0.539 +hypervisor: 0.483 +register: 0.477 +VMM: 0.470 +kernel: 0.434 +arm: 0.427 +TCG: 0.412 +socket: 0.305 +assembly: 0.287 +virtual: 0.282 +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/118/permissions/1700380 b/results/classifier/118/permissions/1700380 new file mode 100644 index 00000000..721d3662 --- /dev/null +++ b/results/classifier/118/permissions/1700380 @@ -0,0 +1,51 @@ +permissions: 0.986 +x86: 0.952 +socket: 0.942 +network: 0.935 +virtual: 0.931 +register: 0.903 +PID: 0.897 +semantic: 0.884 +user-level: 0.880 +device: 0.878 +graphic: 0.869 +architecture: 0.858 +debug: 0.844 +mistranslation: 0.842 +performance: 0.830 +vnc: 0.822 +ppc: 0.737 +hypervisor: 0.652 +risc-v: 0.608 +arm: 0.607 +boot: 0.606 +TCG: 0.576 +VMM: 0.557 +i386: 0.539 +assembly: 0.533 +files: 0.531 +peripherals: 0.527 +KVM: 0.359 +kernel: 0.306 + +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/118/permissions/1702621 b/results/classifier/118/permissions/1702621 new file mode 100644 index 00000000..7403e460 --- /dev/null +++ b/results/classifier/118/permissions/1702621 @@ -0,0 +1,85 @@ +permissions: 0.816 +user-level: 0.793 +performance: 0.752 +virtual: 0.727 +device: 0.707 +arm: 0.693 +debug: 0.692 +peripherals: 0.691 +hypervisor: 0.679 +register: 0.671 +architecture: 0.664 +semantic: 0.663 +socket: 0.650 +assembly: 0.650 +graphic: 0.645 +KVM: 0.642 +mistranslation: 0.624 +vnc: 0.617 +network: 0.616 +PID: 0.615 +x86: 0.614 +VMM: 0.588 +files: 0.585 +TCG: 0.559 +boot: 0.558 +risc-v: 0.558 +i386: 0.531 +ppc: 0.530 +kernel: 0.529 + +colo: secondary vm crash during loadvm + +Following document 'COLO-FT.txt', I test colo feature on my hosts. It seems goes well. But after a while the secondary vm crash. The stack is as follows: +#0 0x00007f191456dc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007f1914571028 in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x00007f1914566bf6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 0x00007f1914566ca2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 +#4 0x0000564154ad9147 in pcibus_reset (qbus=0x564156760d10) at ../hw/pci/pci.c:311 +#5 0x0000564154a07cdb in qbus_reset_one (bus=0x564156760d10, opaque=0x0) at hw/core/qdev.c:319 +#6 0x0000564154a0d721 in qbus_walk_children (bus=0x564156760d10, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/bus.c:68 +#7 0x0000564154a08b4d in qdev_walk_children (dev=0x56415675f2b0, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/qdev.c:617 +#8 0x0000564154a0d6e5 in qbus_walk_children (bus=0x564156594d30, pre_devfn=0, pre_busfn=0, + post_devfn=0x564154a07c26 <qdev_reset_one>, post_busfn=0x564154a07c6c <qbus_reset_one>, opaque=0x0) + at hw/core/bus.c:59 +#9 0x0000564154a07df5 in qbus_reset_all (bus=0x564156594d30) at hw/core/qdev.c:336 +#10 0x0000564154a07e3a in qbus_reset_all_fn (opaque=0x564156594d30) at hw/core/qdev.c:342 +#11 0x0000564154a0e222 in qemu_devices_reset () at hw/core/reset.c:69 +#12 0x00005641548b3b47 in pc_machine_reset () at /vms/git/qemu/hw/i386/pc.c:2234 +#13 0x0000564154972ca7 in qemu_system_reset (report=false) at vl.c:1697 +#14 0x0000564154b9d007 in colo_process_incoming_thread (opaque=0x5641553c1280) at migration/colo.c:617 +#15 0x00007f1914907184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#16 0x00007f1914634bed in clone () from /lib/x86_64-linux-gnu/libc.so.6 + +(gdb) frame 4 +#4 0x0000564154ad9147 in pcibus_reset (qbus=0x564156760d10) at ../hw/pci/pci.c:311 +warning: Source file is more recent than executable. +311 assert(bus->irq_count[i] == 0); +(gdb) ^CQuit +(gdb) p bus->irq_count[i] +$1 = -1 + + + +The qemu version is 2.9.0 release. +The 'irq_count' and 'irq_state' are sent by private vm, and loaded by secondary vm. When they sent by private vm, they maybe not in a consistent state. So sometimes 'bus->irq_count[i]' becomes '-1' on secondary vm. +I deleted the assertions and then tested it several times, it worked well + + +I haven't tried COLO for a while; I've got a note I hit a similar error in the past - +I think I came to the conclusion it was the e1000 that was unhappy - probably sending an interrupt after it had stopped. +Try a different NIC. I flipped to using a virtio-net at one point (but I think I had to disable vhost, there are some patches for this recently). + + + +I agree with David, you can try the RTL8139. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1711 b/results/classifier/118/permissions/1711 new file mode 100644 index 00000000..c68875c8 --- /dev/null +++ b/results/classifier/118/permissions/1711 @@ -0,0 +1,31 @@ +permissions: 0.879 +device: 0.745 +arm: 0.540 +architecture: 0.533 +performance: 0.527 +network: 0.513 +semantic: 0.408 +i386: 0.381 +graphic: 0.334 +KVM: 0.323 +x86: 0.305 +peripherals: 0.247 +VMM: 0.245 +risc-v: 0.240 +boot: 0.236 +TCG: 0.232 +mistranslation: 0.222 +hypervisor: 0.214 +vnc: 0.201 +virtual: 0.200 +files: 0.150 +PID: 0.142 +debug: 0.136 +user-level: 0.126 +ppc: 0.116 +socket: 0.109 +assembly: 0.093 +register: 0.064 +kernel: 0.050 + +unable to set PWD with guest-exec without starting a shell diff --git a/results/classifier/118/permissions/1723927 b/results/classifier/118/permissions/1723927 new file mode 100644 index 00000000..01a96680 --- /dev/null +++ b/results/classifier/118/permissions/1723927 @@ -0,0 +1,135 @@ +permissions: 0.874 +files: 0.792 +user-level: 0.789 +hypervisor: 0.780 +register: 0.776 +KVM: 0.761 +performance: 0.760 +peripherals: 0.757 +VMM: 0.742 +boot: 0.741 +virtual: 0.738 +architecture: 0.734 +TCG: 0.706 +assembly: 0.702 +graphic: 0.690 +arm: 0.689 +device: 0.686 +risc-v: 0.684 +debug: 0.680 +network: 0.680 +semantic: 0.670 +mistranslation: 0.654 +kernel: 0.651 +vnc: 0.643 +i386: 0.636 +socket: 0.634 +PID: 0.611 +ppc: 0.605 +x86: 0.475 + +Linux or windows guest boot failed by uefi on CPU of Intel Xeon X5675 + +Hi, + +I started windows server 2012 DC or redhat7.0, but boot failed by UEFI, and start process stop on +"TianoCore" image by looking at VNCviewer. + +VM using the command:(redhat7.0) +/usr/bin/kvm -name guest=ytest,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/run/lib/libvirt/qemu/domain-40-ytest/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,system=windows,dump-guest-core=off -bios /usr/share/qemu-kvm/OVMF_CODE.fd -m size=8388608k,slots=10,maxmem=34359738368k -realtime mlock=off -smp 1,maxcpus=24,sockets=24,cores=1,threads=1 -numa node,nodeid=0,cpus=0-23,mem=8192 -uuid 8cf40bd6-258a-4550-ba4e-b38230547a11 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -chardev socket,id=charmonitor_cas,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock.cas,server,nowait -mon chardev=charmonitor_cas,id=monitor_cas,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x3 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x4 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -device usb-hub,id=hub0,bus=usb.0,port=1 -drive file=/vms/hw235/ytest,format=qcow2,if=none,id=drive-virtio-disk0,cache=directsync,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,pci_hotpluggable=on,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-fdc0-0-0,readonly=on -global isa-fdc.driveA=drive-fdc0-0-0 -global isa-fdc.bootindexA=2 -netdev tap,fd=48,id=hostnet0,vhost=on,vhostfd=50 -device virtio-net-pci,pci_hotpluggable=on,netdev=hostnet0,id=net0,mac=0c:da:41:1d:67:6f,bus=pci.0,addr=0x5,bootindex=4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/ytest.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -vnc 0.0.0.0:9 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -msg timestamp=on + +qemu version: 2.7.1 +edk2 version: git://git.code.sf.net/p/tianocore/edk2.git, commit: cc0b456a05f8dd1ebfb9be485465be37e96999e7 +server: ProLiant BL460c G7, CPU: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz + +Another, last version of edk2(compiled by myself) start guest is failed, too. But r15214 of edk2 start guest is ok(Download from http://sourceforge.net/projects/edk2/files/OVMF/, OVMF-X64-r15214.zip) + +Thanks in Advance + +On 10/16/17 13:26, chan wrote: +> Public bug reported: +> +> Hi, +> +> I started windows server 2012 DC or redhat7.0, but boot failed by UEFI, and start process stop on +> "TianoCore" image by looking at VNCviewer. +> +> VM using the command:(redhat7.0) +> /usr/bin/kvm -name guest=ytest,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/run/lib/libvirt/qemu/domain-40-ytest/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,system=windows,dump-guest-core=off -bios /usr/share/qemu-kvm/OVMF_CODE.fd -m size=8388608k,slots=10,maxmem=34359738368k -realtime mlock=off -smp 1,maxcpus=24,sockets=24,cores=1,threads=1 -numa node,nodeid=0,cpus=0-23,mem=8192 -uuid 8cf40bd6-258a-4550-ba4e-b38230547a11 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -chardev socket,id=charmonitor_cas,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock.cas,server,nowait -mon chardev=charmonitor_cas,id=monitor_cas,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x3 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x4 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -device usb-hub,id=hub0,bus=usb.0,port=1 -drive file=/vms/hw235/ytest,format=qcow2,if=none,id=drive-virtio-disk0,cache=directsync,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,pci_hotpluggable=on,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-fdc0-0-0,readonly=on -global isa-fdc.driveA=drive-fdc0-0-0 -global isa-fdc.bootindexA=2 -netdev tap,fd=48,id=hostnet0,vhost=on,vhostfd=50 -device virtio-net-pci,pci_hotpluggable=on,netdev=hostnet0,id=net0,mac=0c:da:41:1d:67:6f,bus=pci.0,addr=0x5,bootindex=4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/ytest.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -vnc 0.0.0.0:9 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -msg timestamp=on +> +> qemu version: 2.7.1 +> edk2 version: git://git.code.sf.net/p/tianocore/edk2.git, commit: cc0b456a05f8dd1ebfb9be485465be37e96999e7 +> server: ProLiant BL460c G7, CPU: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz +> +> Another, last version of edk2(compiled by myself) start guest is failed, +> too. But r15214 of edk2 start guest is ok(Download from +> http://sourceforge.net/projects/edk2/files/OVMF/, OVMF-X64-r15214.zip) +> +> Thanks in Advance +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + +Your command line is broken; + + -bios /usr/share/qemu-kvm/OVMF_CODE.fd + +has never been a correct option to boot OVMF. + +Your cmdline seems to have been generated by libvirt; make sure your domain XML says + +<domain type='kvm'> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/qemu-kvm/OVMF_CODE.fd</loader> + </os> +</domain> + +If your libvirt daemon is set up correctly, then libvirt will generate the <nvram> element automatically for the above. (See the "nvram" stanza in "/etc/libvirt/qemu.conf". If you modify that, don't forget to restart libvirt.) + + +Also, you can capture the OVMF debug log with + +<domain type='kvm' + xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <------- don't forget to add this too + <qemu:commandline> + <qemu:arg value='-global'/> + <qemu:arg value='isa-debugcon.iobase=0x402'/> + <qemu:arg value='-debugcon'/> + <qemu:arg value='file:/tmp/GUEST_NAME.log'/> + </qemu:commandline> +</domain> + +Thanks, +Laszlo + + +Ersek, thank you very much! + +I set up correctly in "/etc/libvirt/qemu.conf", so command +-bios /usr/share/qemu-kvm/OVMF_CODE.fd +also boot UEFI guest. + +Current, my question only in the platform in server of ProLiant BL460c G7, +the same ovmf firmware. + +How can capture the OVMF debug log? +I use your advise, open ovmf debug in guest xml: +<qemu:commandline> + <qemu:arg value='-global'/> + <qemu:arg value='isa-debugcon.iobase=0x402'/> + <qemu:arg value='-debugcon'/> + <qemu:arg value='file:/tmp/GUEST_NAME.log'/> + </qemu:commandline> +but nothing output in /tmp/GUEST_NAME.log. +Another, I used debug version ovmf. + +I success to capture the OVMF debug log. + +"-bios /usr/share/qemu-kvm/OVMF_CODE.fd" is *never* a correct option to boot OVMF. + +Closing due to almost 3 years of inactivity. + diff --git a/results/classifier/118/permissions/1728639 b/results/classifier/118/permissions/1728639 new file mode 100644 index 00000000..bbadbd90 --- /dev/null +++ b/results/classifier/118/permissions/1728639 @@ -0,0 +1,141 @@ +permissions: 0.918 +virtual: 0.871 +architecture: 0.867 +user-level: 0.855 +device: 0.852 +graphic: 0.832 +register: 0.831 +semantic: 0.818 +risc-v: 0.808 +performance: 0.803 +arm: 0.798 +socket: 0.795 +boot: 0.789 +assembly: 0.783 +debug: 0.780 +PID: 0.765 +KVM: 0.756 +kernel: 0.755 +TCG: 0.741 +peripherals: 0.729 +files: 0.726 +ppc: 0.721 +hypervisor: 0.700 +x86: 0.696 +network: 0.691 +mistranslation: 0.688 +VMM: 0.679 +vnc: 0.647 +i386: 0.632 + +qemu-io crashes with SIGSEGV when did -c truncate 320000 on a image_fuzzer image + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached files named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "truncate 320000" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 +723 if (drv->bdrv_getlength) { +Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 +#1 0x000000001000fa10 in bdrv_open_driver (bs=0x1fe86f60, drv=0x102036f0 <bdrv_qcow2>, node_name=0x0, options=0x1fe8c240, open_flags=24578, + errp=0x3fffea0fc920) at block.c:1153 +#2 0x0000000010010480 in bdrv_open_common (bs=0x1fe86f60, file=0x1fe92540, options=0x1fe8c240, errp=0x3fffea0fc920) at block.c:1395 +#3 0x0000000010013ac8 in bdrv_open_inherit (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x1fe8c240, flags=24578, parent=0x0, child_role=0x0, + errp=0x3fffea0fcae0) at block.c:2616 +#4 0x0000000010013e8c in bdrv_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) at block.c:2698 +#5 0x000000001008b6d4 in blk_new_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) + at block/block-backend.c:321 +#6 0x000000001000a6ec in openfile (name=0x3fffea0ff661 "copy.img", flags=16386, writethrough=true, force_share=false, opts=0x0) at qemu-io.c:81 +#7 0x000000001000c040 in main (argc=4, argv=0x3fffea0fd208) at qemu-io.c:624 +(gdb) bt full +#0 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 + drv = 0x0 +#1 0x000000001000fa10 in bdrv_open_driver (bs=0x1fe86f60, drv=0x102036f0 <bdrv_qcow2>, node_name=0x0, options=0x1fe8c240, open_flags=24578, + errp=0x3fffea0fc920) at block.c:1153 + local_err = 0x0 + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_open_driver" + __func__ = "bdrv_open_driver" +#2 0x0000000010010480 in bdrv_open_common (bs=0x1fe86f60, file=0x1fe92540, options=0x1fe8c240, errp=0x3fffea0fc920) at block.c:1395 + ret = 16383 + open_flags = 24578 + filename = 0x1fe8e2b1 "copy.img" + driver_name = 0x1fe54810 "qcow2" + node_name = 0x0 + discard = 0x0 + detect_zeroes = 0x0 + opts = 0x1fe93100 + drv = 0x102036f0 <bdrv_qcow2> + local_err = 0x0 + __PRETTY_FUNCTION__ = "bdrv_open_common" + __func__ = "bdrv_open_common" +#3 0x0000000010013ac8 in bdrv_open_inherit (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x1fe8c240, flags=24578, parent=0x0, child_role=0x0, + errp=0x3fffea0fcae0) at block.c:2616 + ret = 512 + file = 0x1fe92540 + bs = 0x1fe86f60 + drv = 0x102036f0 <bdrv_qcow2> + drvname = 0x0 + backing = 0x0 + local_err = 0x0 + snapshot_options = 0x0 + snapshot_flags = 0 + __PRETTY_FUNCTION__ = "bdrv_open_inherit" + __func__ = "bdrv_open_inherit" +#4 0x0000000010013e8c in bdrv_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) at block.c:2698 +No locals. +#5 0x000000001008b6d4 in blk_new_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) + at block/block-backend.c:321 + blk = 0x1fe79410 + bs = 0x0 + perm = 3 +#6 0x000000001000a6ec in openfile (name=0x3fffea0ff661 "copy.img", flags=16386, writethrough=true, force_share=false, opts=0x0) at qemu-io.c:81 + local_err = 0x0 +#7 0x000000001000c040 in main (argc=4, argv=0x3fffea0fd208) at qemu-io.c:624 + readonly = 0 + sopt = 0x101b2608 "hVc:d:f:rsnCmkt:T:U" + lopt = {{name = 0x101b26d0 "driver", has_arg = 0, flag = 0x0, val = 104}, {name = 0x101b26d8 "help", has_arg = 0, flag = 0x0, val = 86}, { + name = 0x101b26e0 "version", has_arg = 1, flag = 0x0, val = 99}, {name = 0x101b26e8 "cmd", has_arg = 1, flag = 0x0, val = 102}, { + name = 0x101b26f0 "format", has_arg = 0, flag = 0x0, val = 114}, {name = 0x101b2700 "y", has_arg = 0, flag = 0x0, val = 115}, { + name = 0x101b2710 "", has_arg = 0, flag = 0x0, val = 110}, {name = 0x101b2718 "nocache", has_arg = 0, flag = 0x0, val = 67}, { +---Type <return> to continue, or q <return> to quit--- + name = 0x101b2728 "read", has_arg = 0, flag = 0x0, val = 109}, {name = 0x101b2738 "", has_arg = 0, flag = 0x0, val = 107}, { + name = 0x101b2748 "io", has_arg = 1, flag = 0x0, val = 100}, {name = 0x101b2750 "discard", has_arg = 1, flag = 0x0, val = 116}, { + name = 0x101b2758 "cache", has_arg = 1, flag = 0x0, val = 84}, {name = 0x101b25e8 "object", has_arg = 1, flag = 0x0, val = 256}, { + name = 0x101b2760 "trace", has_arg = 0, flag = 0x0, val = 257}, {name = 0x101b1c48 "force-share", has_arg = 0, flag = 0x0, val = 85}, {name = 0x0, + has_arg = 0, flag = 0x0, val = 0}} + c = -1 + opt_index = 0 + flags = 16386 + writethrough = true + local_error = 0x0 + opts = 0x0 + format = 0x0 + trace_file = 0x0 + force_share = false +(gdb) +(gdb) quit + +Will attach image_fuzzer image. + + + +Hi, + +Thanks a lot for reporting this bug! I've found a fix and I'll send a patch once I've written a test case. + +Max + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=791fff504cad4d935df + diff --git a/results/classifier/118/permissions/1728643 b/results/classifier/118/permissions/1728643 new file mode 100644 index 00000000..74413d0a --- /dev/null +++ b/results/classifier/118/permissions/1728643 @@ -0,0 +1,146 @@ +user-level: 0.953 +permissions: 0.937 +mistranslation: 0.926 +graphic: 0.926 +semantic: 0.924 +architecture: 0.920 +performance: 0.907 +register: 0.902 +virtual: 0.890 +arm: 0.888 +debug: 0.883 +PID: 0.879 +x86: 0.878 +peripherals: 0.876 +assembly: 0.863 +boot: 0.856 +hypervisor: 0.854 +ppc: 0.850 +files: 0.847 +socket: 0.844 +risc-v: 0.844 +network: 0.839 +device: 0.835 +TCG: 0.834 +KVM: 0.820 +vnc: 0.819 +kernel: 0.819 +VMM: 0.766 +i386: 0.723 + +qemu-io fails with Assertion `*host_offset != 0' failed + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached files named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# cp test.img copy.img +# qemu-io <path to>/copy.img -c "write 884736 34816" + +from gdb: +(gdb) bt +#0 0x00003fffad63eff0 in raise () from /lib64/libc.so.6 +#1 0x00003fffad64136c in abort () from /lib64/libc.so.6 +#2 0x00003fffad634c44 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00003fffad634d34 in __assert_fail () from /lib64/libc.so.6 +#4 0x000000001006426c in qcow2_alloc_cluster_offset (bs=0x391e9ad0, offset=884736, bytes=0x3fffaa89fb4c, host_offset=0x3fffaa89fb58, m=0x3fffaa89fb60) + at block/qcow2-cluster.c:1524 +#5 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x391e9ad0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=0) at block/qcow2.c:1919 +#6 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x391e9ad0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=16) at block/io.c:898 +#7 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x391f51a0, req=0x3fffaa89fdd8, offset=884736, bytes=34816, align=1, qiov=0x3fffce0e2940, flags=16) + at block/io.c:1440 +#8 0x00000000100ac4ac in bdrv_co_pwritev (child=0x391f51a0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=BDRV_REQ_FUA) at block/io.c:1691 +#9 0x000000001008da0c in blk_co_pwritev (blk=0x391d9410, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#10 0x000000001008db68 in blk_write_entry (opaque=0x3fffce0e2958) at block/block-backend.c:1110 +#11 0x00000000101aa444 in coroutine_trampoline (i0=958427472, i1=0) at util/coroutine-ucontext.c:79 +#12 0x00003fffad652b9c in makecontext () from /lib64/libc.so.6 +#13 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fffad63eff0 in raise () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00003fffad64136c in abort () from /lib64/libc.so.6 +No symbol table info available. +#2 0x00003fffad634c44 in __assert_fail_base () from /lib64/libc.so.6 +No symbol table info available. +#3 0x00003fffad634d34 in __assert_fail () from /lib64/libc.so.6 +No symbol table info available. +#4 0x000000001006426c in qcow2_alloc_cluster_offset (bs=0x391e9ad0, offset=884736, bytes=0x3fffaa89fb4c, host_offset=0x3fffaa89fb58, m=0x3fffaa89fb60) + at block/qcow2-cluster.c:1524 + s = 0x391f5d80 + start = 919552 + remaining = 0 + cluster_offset = 399360 + cur_bytes = 34816 + ret = 1 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#5 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x391e9ad0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=0) at block/qcow2.c:1919 + s = 0x391f5d80 + offset_in_cluster = 360448 + ret = 0 + cur_bytes = 34816 + cluster_offset = 0 + hd_qiov = {iov = 0x391b85a0, niov = 0, nalloc = 1, size = 0} + bytes_done = 0 + cluster_data = 0x0 + l2meta = 0x392074c0 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#6 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x391e9ad0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 958319760 + nb_sectors = 2340082071 + ret = 743104256 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#7 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x391f51a0, req=0x3fffaa89fdd8, offset=884736, bytes=34816, align=1, qiov=0x3fffce0e2940, flags=16) + at block/io.c:1440 + bs = 0x391e9ad0 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 + end_sector = 1796 + bytes_remaining = 34816 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#8 0x00000000100ac4ac in bdrv_co_pwritev (child=0x391f51a0, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=BDRV_REQ_FUA) at block/io.c:1691 + bs = 0x391e9ad0 + req = {bs = 0x391e9ad0, offset = 884736, bytes = 34816, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 884736, + overlap_bytes = 34816, list = {le_next = 0x0, le_prev = 0x391ecd48}, co = 0x39207150, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fffaa89fe20}}, waiting_for = 0x0} + align = 1 +---Type <return> to continue, or q <return> to quit--- + head_buf = 0x0 + tail_buf = 0x0 + local_qiov = {iov = 0x3fffaa89fdb0, niov = -1433797136, nalloc = 16383, size = 884736} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#9 0x000000001008da0c in blk_co_pwritev (blk=0x391d9410, offset=884736, bytes=34816, qiov=0x3fffce0e2940, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x391e9ad0 +#10 0x000000001008db68 in blk_write_entry (opaque=0x3fffce0e2958) at block/block-backend.c:1110 + rwco = 0x3fffce0e2958 +#11 0x00000000101aa444 in coroutine_trampoline (i0=958427472, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x39207150, i = {958427472, 0}} + self = 0x39207150 + co = 0x39207150 +#12 0x00003fffad652b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#13 0x0000000000000000 in ?? () +No symbol table info available. + + +Will be attaching image_fuzzer images. + + + +Hi, + +Once more, thanks a lot for reporting this bug! I've found a fix and I'll send a patch once I've written a test case. + +Max + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=93bbaf03ff7fd490e82 + diff --git a/results/classifier/118/permissions/1736655 b/results/classifier/118/permissions/1736655 new file mode 100644 index 00000000..5802ad46 --- /dev/null +++ b/results/classifier/118/permissions/1736655 @@ -0,0 +1,105 @@ +permissions: 0.877 +peripherals: 0.858 +user-level: 0.852 +architecture: 0.850 +register: 0.847 +network: 0.844 +VMM: 0.841 +semantic: 0.841 +debug: 0.834 +mistranslation: 0.829 +device: 0.822 +performance: 0.812 +ppc: 0.807 +risc-v: 0.803 +virtual: 0.802 +vnc: 0.797 +boot: 0.797 +assembly: 0.791 +KVM: 0.784 +graphic: 0.782 +files: 0.778 +PID: 0.776 +arm: 0.774 +kernel: 0.773 +TCG: 0.769 +hypervisor: 0.764 +i386: 0.748 +socket: 0.713 +x86: 0.593 + +2k3/xp guests w/virtio-net randomly DHCP fail on boot + +Host: +Debian GNU/Linux 9 with Linux 4.13.0-0.bpo.1-amd64 +QEMU 2.10.1 + +Guest: +Windows 2003 Standard SP2 (x64) +Windows XP SP3 (i386) + +QEMU command line: +http://cfp.vim-cn.com/cbdF3 + +Description: +After upgrading from QEMU 2.8 to 2.10.1, my Windows 2003 x64 and Windows XP guests with "virtio-net-pci" NIC would randomly fail to aquire DHCP address on boot. When it fails, cycle disable/enable the connection in Control Panel could make it connect successfully. As an immediate workaround, I switched to the RTL8139 NIC which works fine. Further investigation showed that manually reverting commit '4a3f03ba8dbf53fce36d0c1dd5d0cc0f340fe5f3' on top of 2.10.1 "fixed" the problem. + +Here are the test results: +git branch 4a3f03b: 25 boots, 8 failures +git branch 39f099e: 60 boots, 0 failure +2.10.1 with revert: 194 boots, 0 failure + +Hi Patrick, +thank you so much for the report and your help to make Ubuntu better. +Also for all the bisecting that is very helpful. + +While backporting the change itself would be very trivial we need to find what the final solution has to be first. + +I checked latest upstream which is about to release 2.11 these days and there was not related change. +- no revert to this commit +- no other major disabling/fixes for ioeventfd in these cases + +That would imply that this is an issue unknown to upstream - and that means that we need to make it known there to not end up carrying a Delta forever and deriving more and more. +So we should bring it up there and find a solution for everyone. + +First of all let me try if I can reproduce it over here, then we can decide on next steps. +Very likely one of them would be to report it to upstream as well - which since you have a great bug description already they track Launchpad I can easily do for you by adding a bug Task. + +Well I see you already opened it against upstream - sorry (too early for me) - great. +Adding an Ubuntu task then to track potential fixes to take eventually. + +I wanted an XP guest testbed anyway for some time, so this was the perfect reason to create one. +# virtio drivers from [1] and otherwise a "normal" virt-manager setup of a winxp sp3 (32bit) guest + +- Modified to use virtio for net +- Modified to have the virtio drivers as floppy +- Installed virtio drivers for network afer base install + +So after that I assume I'm at the same stage you are. +- WinXP Guest +- Virtio Driver for network +- Host provides DHCP to a bridged network + +I set that to a rebot loop and checked the internet connection through the dhcp virtiop net after reboot. This worked through 10 reboots without an issue, but then IIRC with vhost ioeventfd was on all the time. + +I realized the change identified by you should only make a differenc on non-vhost virtio-net. +But libvirt will make use of vhost automatically if available, so I set the interface to use driver qemu explicitly. + +Another 10 reboots without issue - the virtio version is of 7/19/2017 version 51.75.104.14100 +There must be something more to your case, so please if you have more info how to trigger the case let us know. + +I really think I have the same case you were describing as affected by the change you identified: +$ virsh qemu-monitor-command --hmp winxp 'info network' +net0: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:ce:ca:72 + \ hostnet0: index=0,type=tap,fd=26 +Here from qtree on the device [2] ioeventfd is on. + +Could you try and run it with vhost and see if this changes behavior it for you? + +[1]: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win_amd64.vfd +[2]: http://paste.ubuntu.com/26123654/ + +[Expired for qemu (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/118/permissions/1740219 b/results/classifier/118/permissions/1740219 new file mode 100644 index 00000000..6a9c9057 --- /dev/null +++ b/results/classifier/118/permissions/1740219 @@ -0,0 +1,209 @@ +permissions: 0.950 +semantic: 0.891 +user-level: 0.881 +register: 0.880 +peripherals: 0.876 +performance: 0.875 +architecture: 0.874 +debug: 0.874 +assembly: 0.866 +device: 0.864 +virtual: 0.839 +risc-v: 0.831 +network: 0.828 +graphic: 0.824 +arm: 0.817 +PID: 0.815 +mistranslation: 0.813 +VMM: 0.810 +hypervisor: 0.806 +ppc: 0.800 +KVM: 0.790 +vnc: 0.784 +files: 0.779 +socket: 0.777 +TCG: 0.760 +x86: 0.750 +boot: 0.737 +kernel: 0.711 +i386: 0.555 + +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/118/permissions/1742 b/results/classifier/118/permissions/1742 new file mode 100644 index 00000000..9fef5b31 --- /dev/null +++ b/results/classifier/118/permissions/1742 @@ -0,0 +1,125 @@ +user-level: 0.931 +permissions: 0.922 +device: 0.905 +boot: 0.897 +register: 0.892 +performance: 0.888 +architecture: 0.884 +peripherals: 0.869 +debug: 0.862 +virtual: 0.857 +files: 0.856 +ppc: 0.853 +assembly: 0.848 +arm: 0.846 +graphic: 0.845 +kernel: 0.841 +vnc: 0.840 +mistranslation: 0.837 +hypervisor: 0.837 +semantic: 0.833 +risc-v: 0.830 +PID: 0.821 +KVM: 0.811 +VMM: 0.810 +network: 0.801 +TCG: 0.787 +socket: 0.781 +x86: 0.743 +i386: 0.659 + +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/118/permissions/1745312 b/results/classifier/118/permissions/1745312 new file mode 100644 index 00000000..aef0d52a --- /dev/null +++ b/results/classifier/118/permissions/1745312 @@ -0,0 +1,2253 @@ +permissions: 0.950 +debug: 0.925 +register: 0.922 +mistranslation: 0.922 +architecture: 0.920 +socket: 0.909 +assembly: 0.905 +peripherals: 0.901 +graphic: 0.899 +boot: 0.898 +device: 0.896 +semantic: 0.888 +virtual: 0.881 +PID: 0.874 +files: 0.871 +hypervisor: 0.871 +VMM: 0.859 +performance: 0.856 +network: 0.855 +arm: 0.844 +user-level: 0.840 +risc-v: 0.818 +vnc: 0.774 +kernel: 0.771 +TCG: 0.765 +ppc: 0.748 +KVM: 0.728 +x86: 0.692 +i386: 0.409 + +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/118/permissions/1750899 b/results/classifier/118/permissions/1750899 new file mode 100644 index 00000000..dd4a9bbd --- /dev/null +++ b/results/classifier/118/permissions/1750899 @@ -0,0 +1,68 @@ +permissions: 0.915 +user-level: 0.911 +semantic: 0.891 +register: 0.869 +mistranslation: 0.868 +assembly: 0.847 +graphic: 0.846 +virtual: 0.844 +vnc: 0.836 +hypervisor: 0.809 +arm: 0.808 +debug: 0.805 +device: 0.797 +PID: 0.794 +peripherals: 0.793 +VMM: 0.774 +files: 0.769 +network: 0.762 +architecture: 0.755 +socket: 0.738 +performance: 0.723 +risc-v: 0.719 +KVM: 0.697 +ppc: 0.696 +kernel: 0.695 +TCG: 0.656 +i386: 0.638 +boot: 0.630 +x86: 0.620 + +Mouse cursor sometimes can't pass the invisible border on the right side of the screen + +I'm using qemu 2.11 on Gentoo Linux, with configured GPU passthrough (Radeon RX580) to the guest Windows 10. +This configuration is alive for last 4 years, this time I changed a lot qemu, linux kernel and windows versions, changed GPU and always all was working as expected. I always used standard PS/2 mouse emulation and that was enough for me. + +Now, I bought two new monitors, instead of old one, and setup them as one logical monitor, using technology called Eyefinity - it's a part of standard Radeon software. Now Windows thinks, that I have one monitor with resolution 2160x1920 (I bought Dell monitors with a thin borders and use them in portrait mode). + +Windows uses it without any problems, but mouse become crazy - sometimes (~3 times from each 5) I can't move cursor to the right border of the screen, it looks like the invisible vertical border. I spent really huge amount of time to understand, which component is the root of problem and found, that it's really a mouse. I tried all possible variants (standard, tablet, virtio-mouse-pci, virtio-tablet-pci), and found, that in both mouse variants bug is reproducing, and in both tablet variants - cursor stuck near all real borders and corners, so it's not a variant too. +The only working variant becomes passing real USB port to my VM and insert second mouse to this port. So, now it's working, but I have two mice on my working place, which doesn't seems very useful. + +Here is my command line: + +QEMU_AUDIO_DRV=pa QEMU_PA_SAMPLES=4096 qemu-system-x86_64 -enable-kvm -M q35 -m 12168 -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ +-bios /usr/share/qemu/bios.bin -rtc base=localtime -vga none -device secondary-vga \ +-drive id=virtiocd,if=none,format=raw,file=/home/akushsky/virtio-win-0.1.141.iso \ +-device driver=ide-cd,bus=ide.1,drive=virtiocd \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=05:00.0,bus=root.1,addr=00.0,multifunction=on,romfile=/opt/kvm/images/Sapphire.RX580.8192.170320_1.bin,x-vga=on \ +-device virtio-scsi-pci,id=scsi \ +-drive file=/dev/sdb,id=disk,format=raw,if=none,discard=on,cache=none,aio=native,detect-zeroes=unmap -device scsi-hd,drive=disk,id=scsi0 \ +-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ +-usb -usbdevice host:046d:c52b + +All in all, I checked on Windows 7 and Windows 10, and on qemu 2.10 and 2.11 - bug is always reproducible. + +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.] + + +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/76 + + diff --git a/results/classifier/118/permissions/1752026 b/results/classifier/118/permissions/1752026 new file mode 100644 index 00000000..5a39e548 --- /dev/null +++ b/results/classifier/118/permissions/1752026 @@ -0,0 +1,1279 @@ +permissions: 0.836 +VMM: 0.816 +TCG: 0.769 +register: 0.755 +peripherals: 0.750 +KVM: 0.732 +vnc: 0.730 +ppc: 0.701 +debug: 0.700 +virtual: 0.696 +performance: 0.692 +semantic: 0.691 +architecture: 0.690 +risc-v: 0.687 +socket: 0.684 +boot: 0.670 +network: 0.663 +hypervisor: 0.655 +graphic: 0.652 +device: 0.633 +mistranslation: 0.633 +arm: 0.630 +PID: 0.623 +user-level: 0.618 +assembly: 0.583 +x86: 0.572 +files: 0.561 +kernel: 0.508 +i386: 0.397 + +Ubuntu18.04:POWER9:DD2.2 - Unable to start a KVM guest with default machine type(pseries-bionic) complaining "KVM implementation does not support Transactional Memory, try cap-htm=off" (kvm) + +== Comment: #0 - Satheesh Rajendran <email address hidden> - 2018-02-23 08:31:06 == +---Problem Description--- +libvirt unable to start a KVM guest complaining about cap-htm machine property to be off + +Host Env: +# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 160 +On-line CPU(s) list: 0-159 +Thread(s) per core: 4 +Core(s) per socket: 20 +Socket(s): 2 +NUMA node(s): 2 +Model: 2.2 (pvr 004e 1202) +Model name: POWER9 (raw), altivec supported +CPU max MHz: 3800.0000 +CPU min MHz: 2166.0000 +L1d cache: 32K +L1i cache: 32K +L2 cache: 512K +L3 cache: 10240K +NUMA node0 CPU(s): 0-79 +NUMA node8 CPU(s): 80-159 + +ii qemu-kvm 1:2.11+dfsg-1ubuntu2 ppc64el QEMU Full virtualization on x86 hardware + +ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +# lsmcode +Version of System Firmware : + Product Name : OpenPOWER Firmware + Product Version : open-power-SUPERMICRO-P9DSU-V1.03-20180205-imp + Product Extra : occ-577915f + Product Extra : skiboot-v5.9-240-g081882690163-pcbedce4 + Product Extra : petitboot-v1.6.6-p019c87e + Product Extra : sbe-095e608 + Product Extra : machine-xml-fb5f933 + Product Extra : hostboot-9bfb201 + Product Extra : linux-4.14.13-openpower1-p78d7eee + + + +Contact Information = <email address hidden> + +---uname output--- +4.15.0-10-generic + +Machine Type = power9 boston 2.2 (pvr 004e 1202) + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + 1. Boot a guest from libvirt with default pseries machine type or pseries-bionic + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'virt-tests-vm1' --machine pseries --memory=32768 --vcpu=32,sockets=1,cores=32,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:77:78:79 --noautoconsole +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +Starting install... +ERROR internal error: process exited while connecting to monitor: ,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///system start virt-tests-vm1 +otherwise, please restart your installation. + +2. Fails to boot.. + +Note: if we specify machine type as pseries=2.12 it boots fine like below + +/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 'virt-tests-vm1' --machine pseries-2.12 --memory=32768 --vcpu=32,sockets=1,cores=32,threads=1 --import --nographics --serial pty --memballoon model=virtio --controller type=scsi,model=virtio-scsi --disk path=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-ppc64le.qcow2,bus=scsi,size=10,format=qcow2 --network=bridge=virbr0,model=virtio,mac=52:54:00:77:78:79 --noautoconsole +WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. + +qemu-cmd line: + +libvirt+ 4283 1 99 09:26 ? 00:00:38 qemu-system-ppc64 -enable-kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/master-key.aes -machine pseries-2.12,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 108ac2b5-e8b2-4399-a925-a707e8020871 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-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=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + + +Userspace tool common name: ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +The userspace tool has the following bit modes: both + +Userspace rpm: ii libvirt-bin 4.0.0-1ubuntu3 ppc64el programs for the libvirt library + +Userspace tool obtained from project website: na + +*Additional Instructions for <email address hidden>: +-Post a private note with access information to the machine that the bug is occuring on. +-Attach ltrace and strace of userspace application. + +== Comment: #1 - Satheesh Rajendran <email address hidden> - 2018-02-23 08:35:17 == +vm qemu log for failed and passed cases: + +Failed:(pseries-bionic) +2018-02-23 14:21:10.806+0000: starting up libvirt version: 4.0.0, package: 1ubuntu3 (Christian Ehrhardt <email address hidden> Mon, 19 Feb 2018 14:18:44 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu2), hostname: ltc-boston8.aus.stglabs.ibm.com +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-virt-tests-vm1/master-key.aes -machine pseries-bionic,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 36c37d3b-fb24-4350-94f9-3271b257f75c -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-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=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:10.909242Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +2018-02-23 14:21:18.857+0000: shutting down, reason=failed + + +Passed:(pseries-2.12) +2018-02-23 14:26:07.047+0000: starting up libvirt version: 4.0.0, package: 1ubuntu3 (Christian Ehrhardt <email address hidden> Mon, 19 Feb 2018 14:18:44 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu2), hostname: ltc-boston8.aus.stglabs.ibm.com +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name guest=virt-tests-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/master-key.aes -machine pseries-2.12,accel=kvm,usb=off,dump-guest-core=off -m 32768 -realtime mlock=off -smp 32,sockets=1,cores=32,threads=1 -uuid 108ac2b5-e8b2-4399-a925-a707e8020871 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/libvirt/images/workspace/runAvocadoFVTTest/avocado-fvt-wrapper/data/avocado-vt/images/ubuntu-18.04-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=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:26:07.116991Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) + +Regards, +-Satheesh + +== Comment: #8 - VIPIN K. PARASHAR <email address hidden> - 2018-02-25 23:38:29 == +Starting install... +ERROR internal error: process exited while connecting to monitor: ,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:78:79,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on +2018-02-23T14:21:11.081809Z qemu-system-ppc64: KVM implementation does not support Transactional Memory, try cap-htm=off +Domain installation does not appear to have been successful. +If it was, you can restart your domain by running: + virsh --connect qemu:///system start virt-tests-vm1 +otherwise, please restart your installation. + +As per above message, qemu is reporting TM to be not supported by KVM on this hardware +and thus recommending to turn off cap-htm. + +== Comment: #12 - Suraj Jitindar Singh <email address hidden> - 2018-02-26 23:35:02 == +I don't know what a pseries-bionic is, there is no reference to it upstream. + +What you are seeing is expected behaviour as far as I can tell. POWER9 currently does not support HTM for a guest and thus it must not be turned on, otherwise qemu will fail to start. + +HTM can be disabled from the qemu command line by setting cap-htm=off, as stated in the the error message. The pseries-2.12 machine type has htm disabled by default and thus with that machine type there is no requirement to set cap-htm=off on the command line to get qemu to start. + +So depending on what machine pseries-bionic is based on it will be required to disable htm on the command line (with cap-htm=off) if it is not disabled by default for the machine. + +== Comment: #13 - Satheesh Rajendran <email address hidden> - 2018-02-27 00:05:12 == +Had a chat with Suraj and here is the summary + +1. Currently Power9 DD2.2(host kernel) does not support HTM, so guest should be booted with cap-htm=off, looks like host kernel patch rework in progress--> Initial patch, https://www.spinics.net/lists/kvm-ppc/msg13378.html +2. Libvirt does not know about this cap-htm yet and currently it does not set any default values? +3. pseries-2.12 does have cap-htm=off by default but not the older machine types, so we see the guest is booting from libvirt with pseries-2.12 +4. Once 1 is fixed, we can boot cap-htm=on, I guess by that time pseries-2.12 to be changed to cap-htm=on bydefault. + +---> 3. Immediate fix can be Canonical defaults their machine type(pseries-bioic) to pseries-2.12... +---> Future 1 and 4 to be addressed, not sure about 2? + +Needs a mirror to Canonical to address this. + +Regards, +-Satheesh + +Hi, the long description in this bug is a little confusing. Some of the comments appear to suggest that the required support is not yet upstream. + +Could the reporter confirm whether there any current upstream patches that require backporting urgently (the bug is marked as critical)? + +Or whether further upstream work is required before backporting should begin. + +Thanks, Andy. + + +Hi, +Thanks Andrew - I agree in general. +The following is based on the assumption that the linked discussion (kernel change) is not upstream yet. +Any clarification on that will help thou. + +OTOH I want to start the discussion on the options we have early on. + +I have seen the pseries-2.12 changes in the qemu 2.11.1 stable release (didn't like them). +Especially for things like those that you mentioned "... I guess by that time pseries-2.12 to be changed to cap-htm=on by default" is the reason I can't pick a 2.12 type until 2.12 is final and released. + +We never can allow a case where pseries-2.12 != pseries-2.12 (for migrations and such). + +So at the moment the default pseries-bionic is based on 2.11 being the usual default of qemu 2.11 and the one that is meant to be (and stay) stable. + +So on the proposed change "3. Immediate fix can be Canonical defaults their machine type(pseries-bioic) to pseries-2.12" I'm reluctant to do so, as: + - only pseries would be 2.12 + - there is a high chance we end up with 2.12 != 2.12 down the road + + +Suggestion #1: +If you (=IBM as the authoritative entity for Power) decide that you want htm to be off in the 2.11 machine type in the Ubuntu 18.04 (=Bionic) release we can do that (as Bionic is not released yet we can still change it). + +But that would stay for the entire time of the Bionic release. +So pseries-bionic (the default) => pseries-2.11 (+htm off) will be the default until year 2023 + +Once (if) the host kernel at some point supports htm properly you can surely change the 2.12 type upstream, we would pick that up and later releases will default to a htm on case then. +Also people could run Bionic (which sets htm=off by default then) and run if needed with a htm=on override. + +But even all that would mean that e.g. a new qemu from the Ubuntu cloud archive in a year, would fail the same on a 18.04 base kernel. + +The real fix is to get that host support upstream (kernel) and get it in the Ubuntu kernel prior to the release of 18.04 - is that a realistic timeline, when do you expect this gets upstream? + +I hope those clarifications helped to see why I think just choosing the 2.12 type is no option. + +Thereby Counter-proposing: +1. in qemu we can make default pseries-bionic => pseries-2.11 (+htm off) if you want. + That makes things safe to use for now, but OTOH htm an opt-in feature on Ubuntu 18.04 + That would stay that way for the support time of 18.04 +OR +2. You get the kernel fix upstream asap and Ubuntu integrates before release of 18.04 + Then qemu/libvirt as is would work on P9 DD 2.2+ + (until that happens you can test with an override to set htm=off) + + +But any decision between #1/#2 depends very much on: +- the expected timeline of your kernel changes +- your preferenc in regard to the htm feature +So it is up to you to clarify on that as Andrew pointed out. + +------- Comment From <email address hidden> 2018-02-27 22:50 EDT------- +1. +If it's decided thatwe want to default to cap-htm=off, then that can be achieved by adding: +```smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;``` +to the spapr-bionic machine class init + +2. +What is the timeframe we are talking about here, a week/a month? It's hard to give a firm timeframe on the patches going upstream + +For 1. I mostly agree, the default is currently off in code and in 2.11 there is this for backwards compatability: + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_ON; + +We would have to +- Moving that "keep the old default" entry to 2.10 (to cover <=2.10) + spapr_machine_2_10_class_options + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_ON; +- And we would set it explicit off in 2.11 (which is what pseries-bionic refers to) + spapr_machine_2_11_class_options + smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF; +- 2.12 we would not change IMHO, that might become whatever it becomes with 2.12 development + + +For #2 - this is a bug fix so it does not fall under the Feature Freeze (tomorrow). +But I don't know how much lead time the kernel team needs. +Given that kernel fixes are involved this clearly needs a kernel task for them to know about - adding ... + +@Kernel - please read the context - what is the last date you'd need to have this commit upstream by IBM to be able to pick it and still be in the initial 18.04 release kernel (not in -updates)? + +@IBM - how about this approach: +A) We switch the default to HTM=off in qemu "now" (as soon as you ack this) to be safe +B) If you get the kernel fixes upstream fast enough for the kernel Team to pick up in time: + B1) a fixed kernel will be pushed (before 18.04 release) + B2) we unroll this change in qemu (before 18.04 release) + +That way we would surely have something that "works" by default via (A) and if (B) is in time we can switch back to "working but with HTM enabled". +And if (B) is too late we will keep HTM disabled in the 2.11/Bionic machine type. + +------- Comment From <email address hidden> 2018-03-01 00:00 EDT------- +*** Bug 165240 has been marked as a duplicate of this bug. *** + +------- Comment From <email address hidden> 2018-03-01 01:22 EDT------- +Seems like the best option in my opinion + +Sorry, but to be sure is that a clear "yes please disable HTM by default in qemu on ppc64el for Ubuntu 18.04" ? + +Status changed to 'Confirmed' because the bug affects multiple users. + +------- Comment From <email address hidden> 2018-03-01 10:42 EDT------- +@paelzer yes, that is us agreeing with your plan +>A) We switch the default to HTM=off in qemu "now" (as soon as you ack this) to be safe +>B) If you get the kernel fixes upstream fast enough for the kernel Team to pick up in time: +>... + +Sorry for the delay. + +------- Comment From <email address hidden> 2018-03-01 12:41 EDT------- +(In reply to comment #27) +> @paelzer yes, that is us agreeing with your plan + +Does it mean that we are not going to have HTM support on KVM guests, even in POWER8? + +------- Comment From <email address hidden> 2018-03-01 13:17 EDT------- +(In reply to comment #28) +> (In reply to comment #27) +> > @paelzer yes, that is us agreeing with your plan +> +> Does it mean that we are not going to have HTM support on KVM guests, even +> in POWER8? + +you would use the 2.10 machine type for that, right? + +------- Comment From <email address hidden> 2018-03-01 15:07 EDT------- +(In reply to comment #29) +> (In reply to comment #28) +> > (In reply to comment #27) +> > > @paelzer yes, that is us agreeing with your plan +> > +> > Does it mean that we are not going to have HTM support on KVM guests, even +> > in POWER8? +> +> you would use the 2.10 machine type for that, right? +Right. This is about the new machine type. + +To the mini-discussion above - yes it would be default off on P8 as well then. +But by selecting an older machine type, or - even better - using the new type but with cap-htm=on + +Starting the fix in qemu early next week then (the one outlined as (A) in comment #4. + + +FYI: There is bug 1753826 which postponed the release/testing of this one a bit. +Currently in rebuild/test together. + +Fix pushed to bionic proposed, I'll track migration after it built and some time for the tests have passed. + +BTW - tests on P8 are already good on my side, and since the request from IBM came fro P9 I have to assume it will be good there. But e.g. cross release migration X->B and such I had tested explicitly to be sure. + +That said, please be aware that this will be a remaining "itch" for you at the current solution. +If somebody had guests on pre-Xenial it will have HTM enabled by default. +If those users migrate to a P9 system on Bionic they will still carry the feature of HTM being enabled and run into the issue, but there is nothing we can do about it other than getting your kernel fix completed and integrated. But I thought I make you aware to be sure. + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu4 + +--------------- +qemu (1:2.11+dfsg-1ubuntu4) bionic; urgency=medium + + * d/p/ubuntu/define-ubuntu-machine-types.patch: Disable HTM feature for + ppc64el in spapr to let the defaults not fail on Power9 HW (LP: #1752026). + * d/p/ubuntu/lp1753826-memfd-fix-configure-test.patch: fix FTBFS with newer + versions of glibc >=2.27 (LP: #1753826) + + -- Christian Ehrhardt <email address hidden> Mon, 05 Mar 2018 16:43:01 +0100 + +------- Comment From <email address hidden> 2018-03-13 12:52 EDT------- +Paul's RFC patch to kernel, https://www.spinics.net/lists/kvm/msg165629.html + +Patch posted to lkml, but not yet accepted upstream. + +------- Comment From <email address hidden> 2018-03-20 16:38 EDT------- +I went to https://www.spinics.net/lists/kvm/msg165629.html but it only has source code change for the problem. + +Can Linux team build a patch against Ubuntu 18.04 kernel 4.15.0-12-generic for test team to install. Thanks + +------- Comment From <email address hidden> 2018-03-21 07:12 EDT------- +The latest version of the patches has been posted and is available at https://patchwork.ozlabs.org/project/kvm-ppc/list/?series=35017. I will add a note when the series has been put in a maintainer's tree. + +------- Comment From <email address hidden> 2018-03-21 12:20 EDT------- +Gustavo, would you please add this patch to the Ubuntu kernel you created with the trap/HMI patches? + +------- Comment From <email address hidden> 2018-03-22 15:48 EDT------- +- Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily build below + +http://cdimages.ubuntu.com/ubuntu-server/daily/current/ + +- With today build, it no longer has the Transaction Memory error when start up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily build. + +------- Comment From <email address hidden> 2018-03-23 01:53 EDT------- +(In reply to comment #43) +> - Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily +> build below +> +> http://cdimages.ubuntu.com/ubuntu-server/daily/current/ +> +> - With today build, it no longer has the Transaction Memory error when start +> up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily +> build. + +(In reply to comment #43) +> - Today, I setup Ubuntu KVM on my Boston system using Ubuntu 18.04 daily +> build below +> +> http://cdimages.ubuntu.com/ubuntu-server/daily/current/ +> +> - With today build, it no longer has the Transaction Memory error when start +> up a KVM guest. So the fix in this LTCbug mhave made it into Ubuntu daily +> build. + +Hi Nguyen, + +Pauls patch(https://patchwork.ozlabs.org/project/kvm-ppc/list/?series=35017) yet to get merged in linux master as of now{f36b7534b833 (HEAD -> master, upstream/master) Merge branch 'akpm' (patches from Andrew)} + +Does ubuntu daily kernel include custom patches? + +If it does not include custom patches and one reason why you do not hit the issue now, coz qemu disable cap-htm by default temporarily till the above kernel patches included, check if that is the case. + +you can confirm the TM patches are included by explicitly start qemu-kvm command with cap-htm=on + +Regards, +-Satheesh. + +------- Comment From <email address hidden> 2018-04-02 19:22 EDT------- +The patches that make it possible to use HTM in guests running on POWER9 processors are now in the PowerPC kernel maintainer tree and will be requested to get merged into kernel 4.17: + +681c617b7c42 KVM: PPC: Book3S HV: Work around TEXASR bug in fake suspend state +87a11bb6a7f7 KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode +4bb3c7a0208f KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9 +7672691a08c8 powerpc/powernv: Provide a way to force a core into SMT4 mode +b5af4f279323 powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2 +9bbf0b576d32 powerpc: Free up CPU feature bits on 64-bit machines +dd0efb3f11cc powerpc: Book E: Remove unused CPU_FTR_L2CSR bit +c0d64cf9fefd powerpc: Use feature bit for RTC presence rather than timebase presence + +Fom Paul Mackerras: for a backport, we can probably avoid the feature bit rework, I hope, and just find two free CPU feature bits. If there aren't 2 free feature bits then let me know, we might be able to scavenge some that are only used on Book E or something. + +Since the kernel team is now investigating the integration of the kernel patches into bionic (the kernel bits are already Fix Committed), we should plan to get the temporary workaround again removed from qemu-kvm. +It's hard to time it in a way that the kernel changes are rolled-out and the qemu workaround got removed at the same time. +So this could lead to a short time of the qemu mitigation being reverted, but the kernel not yet being released, which would make you need the cap-htm=0ff workaround. But that way it would be much safer that both changes are available prior to the release of 18.04 Bionic. +Hence the question (to IBM) is if it would be okay to plan ahead and to get the qemu changes reverted back now? + +------- Comment From <email address hidden> 2018-04-04 04:18 EDT------- +(In reply to comment #48) +> Since the kernel team is now investigating the integration of the kernel +> patches into bionic (the kernel bits are already Fix Committed), we should +> plan to get the temporary workaround again removed from qemu-kvm. +> It's hard to time it in a way that the kernel changes are rolled-out and the +> qemu workaround got removed at the same time. +> So this could lead to a short time of the qemu mitigation being reverted, +> but the kernel not yet being released, which would make you need the +> cap-htm=0ff workaround. But that way it would be much safer that both +> changes are available prior to the release of 18.04 Bionic. +> Hence the question (to IBM) is if it would be okay to plan ahead and to get +> the qemu changes reverted back now? + +Yes, we need the qemu workaround to be removed. I see all required kernel patches are in master-next of bionic. Understand that both of these cannot be timed.. but having qemu changes revert today.. would we get updated kernel and qemu in tomorrows daily build? just wanted to understand what would be time window.. + +It's not possible to turn around a kernel that quickly. I intend to get a kernel with the fix uploaded bionic-proposed today, but it takes a few days at minimum to get it built, tested, and promoted to the -release pocket. + +@Seth - that is fine, for the Kernel we only need to rely on "will be out before Bionic release" and that looks good - don't feel pushed. +The updates were about asking IBM "If we assume the kernel fixes will be there, should we remove the qemu mitigation (as we can't remove it after Bionic release date)". + +------- Comment From <email address hidden> 2018-04-04 08:50 EDT------- +Hi Frank, + +First of all, thanks for caring about this bug and accepting the out-of-the-tree patches. + +You are right, the motivation to include this patchset is to re-enable the HTM in the KVM guests. So, we just need to schedule the fixes on both side. + +Here are some assumptions I have: + +1) If you need to revert the qemu-kvm "HTM off" patches right now, We can survive, since we have a internal kernel that contains the fix, and we can use this custom kernel in the mean time. Not a big deal. + +2) On the other side, I understand that the Final Freeze for Ubuntu will be in April 19th, so, we still have some time to release qemu, how long can we wait without affecting the time to we spend testing this package? + +3) Releasing the fixed kernel prior to the fixed qemu package would be better than the other way around. + +4) Can't we fix fix qemu now and keep it in the proposed until the kernel is released? + +Thanks! + +------- Comment From <email address hidden> 2018-04-04 08:55 EDT------- +One other possibility could be to have the changes going into the kernel and, then, remove the workaround from QEMU. QEMU with the workaround should continue to work with the kernel with the proper changes. HTM will be disabled in the guests, which would not be needed anymore, but would not block a VM from running. + +Anyway, I am OK either way. We need to make progress here and I understand this came in late. We need to have the fixes in the kernel and the workaround out of QEMU. If that means we will have a broken QEMU for few days, that would be OK. We can continue our tests with previous versions of kernel and QEMU until everything is settled in bionic repositories or disable HTM by hand when running tests. + +@Breno - I agree to #3 but since we have no hard ETA on the kernel I want to avoid punting qemu to the very last few days. History told me that always something happens/blocks and if we would miss GA we can't SRu to keep the final pseries-bionic type in sync. + +For #4 there is no good "keep in proposed" for the current Dev release. + +I discussed with lagarcia and JFH on IRC once more: +... +[15:02] <lagarcia_> cpaelzer, I am OK with that. TBH, we can live with QEMU removing the workaround now or after the kernel has been changed. +[15:05] <cpaelzer> there was a bug update by breno 3 minutes ago +[15:05] * cpaelzer is reading +[15:06] <cpaelzer> oh I see, and your comment - mirrored both at once +[15:06] <cpaelzer> my concern is that if anything comes up late +[15:06] <cpaelzer> we might end up with the qemu change not reverted +[15:07] <cpaelzer> as after release it becomes an issue +[15:07] <cpaelzer> and will no more be removable +[15:07] <cpaelzer> for consistency of the pseries-bionic type +[15:07] <jfh1> cpaelzer, lagarcia: ah - just saw the ticket update and a reply from Breno ... +[15:08] <cpaelzer> jfh1: do we have anything like an expected date by the kernel Team? +[15:08] <cpaelzer> I'd not want to wait with qemu later than end of this week TBH +[15:08] <cpaelzer> history teached me not to try changing things last minute +[15:08] <jfh1> cpaelzer: I agree - there is always the option to pin a package to prevent it from getting updated +[15:09] <jfh1> that can be an option for those guys who still need to KVM on P9 ... +[15:09] <cpaelzer> jfh1: lagarcia_: so are we agreeing that I'll revert the avoidance in qemu now considering the various constraints? +[15:09] * cpaelzer is +1 +[15:10] <jfh1> I think so ... +[15:12] <lagarcia_> cpaelzer, yep +[15:13] <lagarcia_> cpaelzer, when the patches reach bionic kernel, everything should work out of the box. Meanwhile, we can implement the workaround by hand. + + +With all that said, I'm including the revert of the current mitigation from the next qemu upload. + +Revert will be hanlded via bug 1761175 + +@ lagarcia and Breno: +People/tester who still need the patched qemu can prevent that from being upgraded by pinning it aka marking it as hold (https://help.ubuntu.com/community/PinningHowto). +Even in case of an accidental upgrade - it's easy to go again back to that version. + +------- Comment From <email address hidden> 2018-04-10 06:53 EDT------- +We have got the qemu build with htm-on today [April 10th]. Now we are able to start compat mode guests with htm-on.. apart from bug 166570 things look good. We can close this one. + +This bug was fixed in the package linux - 4.15.0-15.16 + +--------------- +linux (4.15.0-15.16) bionic; urgency=medium + + * linux: 4.15.0-15.16 -proposed tracker (LP: #1761177) + + * FFe: Enable configuring resume offset via sysfs (LP: #1760106) + - PM / hibernate: Make passing hibernate offsets more friendly + + * /dev/bcache/by-uuid links not created after reboot (LP: #1729145) + - SAUCE: (no-up) bcache: decouple emitting a cached_dev CHANGE uevent + + * Ubuntu18.04:POWER9:DD2.2 - Unable to start a KVM guest with default machine + type(pseries-bionic) complaining "KVM implementation does not support + Transactional Memory, try cap-htm=off" (kvm) (LP: #1752026) + - powerpc: Use feature bit for RTC presence rather than timebase presence + - powerpc: Book E: Remove unused CPU_FTR_L2CSR bit + - powerpc: Free up CPU feature bits on 64-bit machines + - powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2 + - powerpc/powernv: Provide a way to force a core into SMT4 mode + - KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9 + - KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode + - KVM: PPC: Book3S HV: Work around TEXASR bug in fake suspend state + + * Important Kernel fixes to be backported for Power9 (kvm) (LP: #1758910) + - powerpc/mm: Fixup tlbie vs store ordering issue on POWER9 + + * Ubuntu 18.04 - IO Hang on some namespaces when running HTX with 16 + namespaces (Bolt / NVMe) (LP: #1757497) + - powerpc/64s: Fix lost pending interrupt due to race causing lost update to + irq_happened + + * fwts-efi-runtime-dkms 18.03.00-0ubuntu1: fwts-efi-runtime-dkms kernel module + failed to build (LP: #1760876) + - [Packaging] include the retpoline extractor in the headers + +linux (4.15.0-14.15) bionic; urgency=medium + + * linux: 4.15.0-14.15 -proposed tracker (LP: #1760678) + + * [Bionic] mlx4 ETH - mlnx_qos failed when set some TC to vendor + (LP: #1758662) + - net/mlx4_en: Change default QoS settings + + * AT_BASE_PLATFORM in AUXV is absent on kernels available on Ubuntu 17.10 + (LP: #1759312) + - powerpc/64s: Fix NULL AT_BASE_PLATFORM when using DT CPU features + + * Bionic update to 4.15.15 stable release (LP: #1760585) + - net: dsa: Fix dsa_is_user_port() test inversion + - openvswitch: meter: fix the incorrect calculation of max delta_t + - qed: Fix MPA unalign flow in case header is split across two packets. + - tcp: purge write queue upon aborting the connection + - qed: Fix non TCP packets should be dropped on iWARP ll2 connection + - sysfs: symlink: export sysfs_create_link_nowarn() + - net: phy: relax error checking when creating sysfs link netdev->phydev + - devlink: Remove redundant free on error path + - macvlan: filter out unsupported feature flags + - net: ipv6: keep sk status consistent after datagram connect failure + - ipv6: old_dport should be a __be16 in __ip6_datagram_connect() + - ipv6: sr: fix NULL pointer dereference when setting encap source address + - ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state + - mlxsw: spectrum_buffers: Set a minimum quota for CPU port traffic + - net: phy: Tell caller result of phy_change() + - ipv6: Reflect MTU changes on PMTU of exceptions for MTU-less routes + - net sched actions: return explicit error when tunnel_key mode is not + specified + - ppp: avoid loop in xmit recursion detection code + - rhashtable: Fix rhlist duplicates insertion + - test_rhashtable: add test case for rhltable with duplicate objects + - kcm: lock lower socket in kcm_attach + - sch_netem: fix skb leak in netem_enqueue() + - ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event() + - net: use skb_to_full_sk() in skb_update_prio() + - net: Fix hlist corruptions in inet_evict_bucket() + - s390/qeth: free netdevice when removing a card + - s390/qeth: when thread completes, wake up all waiters + - s390/qeth: lock read device while queueing next buffer + - s390/qeth: on channel error, reject further cmd requests + - soc/fsl/qbman: fix issue in qman_delete_cgr_safe() + - dpaa_eth: fix error in dpaa_remove() + - dpaa_eth: remove duplicate initialization + - dpaa_eth: increment the RX dropped counter when needed + - dpaa_eth: remove duplicate increment of the tx_errors counter + - dccp: check sk for closed state in dccp_sendmsg() + - ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option() + - l2tp: do not accept arbitrary sockets + - net: ethernet: arc: Fix a potential memory leak if an optional regulator is + deferred + - net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY + interface + - net: fec: Fix unbalanced PM runtime calls + - net/iucv: Free memory obtained by kzalloc + - netlink: avoid a double skb free in genlmsg_mcast() + - net: Only honor ifindex in IP_PKTINFO if non-0 + - net: systemport: Rewrite __bcm_sysport_tx_reclaim() + - qede: Fix qedr link update + - skbuff: Fix not waking applications when errors are enqueued + - team: Fix double free in error path + - Linux 4.15.15 + + * Ubuntu 18.04 [ WSP DD2.2 with stop4 and stop5 enabled ]: kdump fails to + capture dump when smt=2 or off. (LP: #1758206) + - powerpc/crash: Remove the test for cpu_online in the IPI callback + - powernv/kdump: Fix cases where the kdump kernel can get HMI's + - powerpc/kdump: Fix powernv build break when KEXEC_CORE=n + + * [Intel Ubuntu 18.04 Bug] Null pointer dereference, when disconnecting RAID + rebuild target (LP: #1759279) + - md: document lifetime of internal rdev pointer. + + * [Feature]Crystal Ridge:add support for the platform capabilities NFIT sub- + table in ACPI 6.2A (LP: #1730829) + - ACPICA: ACPI 6.0A: Changes to the NFIT ACPI table + - acpi: nfit: Add support for detect platform CPU cache flush on power loss + - acpi: nfit: add persistent memory control flag for nd_region + - libnvdimm: expose platform persistence attribute for nd_region + - libnvdimm: re-enable deep flush for pmem devices via fsync() + - libnvdimm, nfit: fix persistence domain reporting + + * Allow multiple mounts of zfs datasets (LP: #1759848) + - SAUCE: Allow mounting datasets more than once (LP: #1759848) + + * Update Aquantia driver to fix various issues (LP: #1759303) + - net: aquantia: Eliminate AQ_DIMOF, replace with ARRAY_SIZE + - net: aquantia: Cleanup status flags accesses + - net: aquantia: Cleanup hardware access modules + - net: aquantia: Remove duplicate hardware descriptors declarations + - net: aquantia: Add const qualifiers for hardware ops tables + - net: aquantia: Simplify dependencies between pci modules + - net: aquantia: Eliminate aq_nic structure abstraction + - net: aquantia: Fix register definitions to linux style + - net: aquantia: Prepend hw access functions declarations with prefix + - net: aquantia: Fix internal stats calculation on rx + - net: aquantia: Introduce new device ids and constants + - net: aquantia: Introduce new AQC devices and capabilities + - net: aquantia: Convert hw and caps structures to const static pointers + - net: aquantia: Cleanup pci functions module + - net: aquantia: Remove create/destroy from hw ops + - net: aquantia: Change confusing no_ff_addr to more meaningful name + - net: aquantia: Introduce firmware ops callbacks + - net: aquantia: Introduce support for new firmware on AQC cards + - net: aquantia: Introduce global AQC hardware reset sequence + - net: aquantia: Report correct mediatype via ethtool + - net: aquantia: bump driver version to match aquantia internal numbering + - net: aquantia: Fix hardware reset when SPI may rarely hangup + - net: aquantia: Fix a regression with reset on old firmware + - net: aquantia: Change inefficient wait loop on fw data reads + - net: aquantia: Add tx clean budget and valid budget handling logic + - net: aquantia: Allow live mac address changes + - net: aquantia: Implement pci shutdown callback + - net: aquantia: driver version bump + + * ISST-LTE:KVM:Ubuntu1804:BostonLC:boslcp3: cpu hotplug on boslcp3g4 guest + dumping call traces continuously. (LP: #1759722) + - blk-mq: turn WARN_ON in __blk_mq_run_hw_queue into printk + + * ISST-LTE:KVM:Ubuntu18.04:BostonLC:boslcp3:boslcp3g3:Guest conosle hangs + after hotplug CPU add operation. (LP: #1759723) + - genirq/affinity: assign vectors to all possible CPUs + - blk-mq: simplify queue mapping & schedule with each possisble CPU + + * test_bpf fails (LP: #1756150) + - test_bpf: Fix testing with CONFIG_BPF_JIT_ALWAYS_ON=y on other arches + + * Bionic update to v4.15.14 stable release (LP: #1759655) + - MIPS: ralink: Remove ralink_halt() + - MIPS: ralink: Fix booting on MT7621 + - MIPS: lantiq: Fix Danube USB clock + - MIPS: lantiq: Enable AHB Bus for USB + - MIPS: lantiq: ase: Enable MFD_SYSCON + - iio: chemical: ccs811: Corrected firmware boot/application mode transition + - iio: st_pressure: st_accel: pass correct platform data to init + - iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock() + - ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit + - ALSA: aloop: Sync stale timer before release + - ALSA: aloop: Fix access to not-yet-ready substream via cable + - ALSA: hda - Force polling mode on CFL for fixing codec communication + - ALSA: hda/realtek - Fix speaker no sound after system resume + - ALSA: hda/realtek - Fix Dell headset Mic can't record + - ALSA: hda/realtek - Always immediately update mute LED with pin VREF + - mmc: core: Fix tracepoint print of blk_addr and blksz + - mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards + - mmc: block: fix updating ext_csd caches on ioctl call + - mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systems + - mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433 + - mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs + - PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L + - ahci: Add PCI-id for the Highpoint Rocketraid 644L card + - lockdep: fix fs_reclaim warning + - clk: bcm2835: Fix ana->maskX definitions + - clk: bcm2835: Protect sections updating shared registers + - clk: sunxi-ng: a31: Fix CLK_OUT_* clock ops + - RDMA/mlx5: Fix crash while accessing garbage pointer and freed memory + - Drivers: hv: vmbus: Fix ring buffer signaling + - pinctrl: samsung: Validate alias coming from DT + - Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table + - Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table + - Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174 + - libata: fix length validation of ATAPI-relayed SCSI commands + - libata: remove WARN() for DMA or PIO command without data + - libata: don't try to pass through NCQ commands to non-NCQ devices + - libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs + - libata: Enable queued TRIM for Samsung SSD 860 + - libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs + - libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions + - libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version + - sched, cgroup: Don't reject lower cpu.max on ancestors + - cgroup: fix rule checking for threaded mode switching + - nfsd: remove blocked locks on client teardown + - media: tegra-cec: reset rx_buf_cnt when start bit detected + - hugetlbfs: check for pgoff value overflow + - h8300: remove extraneous __BIG_ENDIAN definition + - mm/vmalloc: add interfaces to free unmapped page table + - x86/mm: implement free pmd/pte page interfaces + - mm/khugepaged.c: convert VM_BUG_ON() to collapse fail + - mm/thp: do not wait for lock_page() in deferred_split_scan() + - mm/shmem: do not wait for lock_page() in shmem_unused_huge_shrink() + - Revert "mm: page_alloc: skip over regions of invalid pfns where possible" + - drm/vmwgfx: Fix black screen and device errors when running without fbdev + - drm/vmwgfx: Fix a destoy-while-held mutex problem. + - drm/radeon: Don't turn off DP sink when disconnected + - drm/amd/display: We shouldn't set format_default on plane as atomic driver + - drm/amd/display: Add one to EDID's audio channel count when passing to DC + - drm: Reject getfb for multi-plane framebuffers + - drm: udl: Properly check framebuffer mmap offsets + - mm/vmscan: wake up flushers for legacy cgroups too + - module: propagate error in modules_open() + - acpi, numa: fix pxm to online numa node associations + - ACPI / watchdog: Fix off-by-one error at resource assignment + - libnvdimm, {btt, blk}: do integrity setup before add_disk() + - brcmfmac: fix P2P_DEVICE ethernet address generation + - rtlwifi: rtl8723be: Fix loss of signal + - tracing: probeevent: Fix to support minus offset from symbol + - mtdchar: fix usage of mtd_ooblayout_ecc() + - mtd: nand: fsl_ifc: Fix nand waitfunc return value + - mtd: nand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0 + - mtd: nand: fsl_ifc: Read ECCSTAT0 and ECCSTAT1 registers for IFC 2.0 + - staging: ncpfs: memory corruption in ncp_read_kernel() + - can: peak/pcie_fd: fix echo_skb is occupied! bug + - can: peak/pcie_fd: remove useless code when interface starts + - can: ifi: Repair the error handling + - can: ifi: Check core revision upon probe + - can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack + - can: cc770: Fix queue stall & dropped RTR reply + - can: cc770: Fix use after free in cc770_tx_interrupt() + - tty: vt: fix up tabstops properly + - x86/entry/64: Don't use IST entry for #BP stack + - selftests/x86/ptrace_syscall: Fix for yet more glibc interference + - x86/vsyscall/64: Use proper accessor to update P4D entry + - x86/efi: Free efi_pgd with free_pages() + - posix-timers: Protect posix clock array access against speculation + - kvm/x86: fix icebp instruction handling + - x86/build/64: Force the linker to use 2MB page size + - x86/boot/64: Verify alignment of the LOAD segment + - hwmon: (k10temp) Only apply temperature offset if result is positive + - hwmon: (k10temp) Add temperature offset for Ryzen 1900X + - perf/x86/intel/uncore: Fix Skylake UPI event format + - perf stat: Fix CVS output format for non-supported counters + - perf/core: Fix ctx_event_type in ctx_resched() + - trace/bpf: remove helper bpf_perf_prog_read_value from tracepoint type + programs + - perf/x86/intel: Don't accidentally clear high bits in bdw_limit_period() + - perf/x86/intel/uncore: Fix multi-domain PCI CHA enumeration bug on Skylake + servers + - iio: ABI: Fix name of timestamp sysfs file + - iio: imu: st_lsm6dsx: fix endianness in st_lsm6dsx_read_oneshot() + - iio: imu: st_lsm6dsx: introduce conf_lock mutex + - staging: android: ion: Zero CMA allocated memory + - kbuild: disable clang's default use of -fmerge-all-constants + - bpf: skip unnecessary capability check + - bpf, x64: increase number of passes + - Linux 4.15.14 + + * System fails to start (boot) on battery due to read-only root file-system + (LP: #1726930) // Bionic update to v4.15.14 stable release (LP: #1759655) + - libata: disable LPM for Crucial BX100 SSD 500GB drive + + * [Feature][CFL][ICL] [CNL]Thunderbolt support (Titan Ridge) (LP: #1730775) + - thunderbolt: Resume control channel after hibernation image is created + - thunderbolt: Serialize PCIe tunnel creation with PCI rescan + - thunderbolt: Handle connecting device in place of host properly + - thunderbolt: Do not overwrite error code when domain adding fails + - thunderbolt: Wait a bit longer for root switch config space + - thunderbolt: Wait a bit longer for ICM to authenticate the active NVM + - thunderbolt: Handle rejected Thunderbolt devices + - thunderbolt: Factor common ICM add and update operations out + - thunderbolt: Correct function name in kernel-doc comment + - thunderbolt: Add tb_switch_get() + - thunderbolt: Add tb_switch_find_by_route() + - thunderbolt: Add tb_xdomain_find_by_route() + - thunderbolt: Add constant for approval timeout + - thunderbolt: Move driver ready handling to struct icm + - thunderbolt: Add 'boot' attribute for devices + - thunderbolt: Add support for preboot ACL + - Documentation/admin-guide: fixes for thunderbolt.rst + - thunderbolt: Introduce USB only (SL4) security level + - thunderbolt: Add support for Intel Titan Ridge + + * QCA9377 requires more IRAM banks for its new firmware (LP: #1748345) + - ath10k: update the IRAM bank number for QCA9377 + + * nfp: fix disabling on hw-tc-offload in flower (LP: #1752828) + - nfp: bpf: require ETH table + - nfp: don't advertise hw-tc-offload on non-port netdevs + - nfp: forbid disabling hw-tc-offload on representors while offload active + + * Fix an issue that when system in S3, USB keyboard can't wake up the system. + (LP: #1759511) + - ACPI / PM: Allow deeper wakeup power states with no _SxD nor _SxW + + * retpoline hints: primary infrastructure and initial hints (LP: #1758856) + - [Packaging] retpoline -- add safe usage hint support + - [Packaging] retpoline-check -- only report additions + - [Packaging] retpoline -- widen indirect call/jmp detection + - [Packaging] retpoline -- elide %rip relative indirections + - [Packaging] retpoline -- clear hint information from packages + - SAUCE: apm -- annotate indirect calls within + firmware_restrict_branch_speculation_{start,end} + - SAUCE: EFI -- annotate indirect calls within + firmware_restrict_branch_speculation_{start,end} + - SAUCE: early/late -- annotate indirect calls in early/late initialisation + code + - SAUCE: vga_set_mode -- avoid jump tables + - [Config] retpoine -- switch to new format + + * zfs system process hung on container stop/delete (LP: #1754584) + - SAUCE: Fix non-prefaulted page deadlock (LP: #1754584) + - Revert "UBUNTU: SAUCE: Fix non-prefaulted page deadlock (LP: #1754584)" + - SAUCE: Fix non-prefaulted page deadlock (LP: #1754584) + + * Important KVM fixes for ppc64el (LP: #1759045) + - KVM: PPC: Book3S HV: Do SLB load/unload with guest LPCR value loaded + - KVM: PPC: Book3S HV: Fix handling of secondary HPTEG in HPT resizing code + - KVM: PPC: Book3S HV: Make HPT resizing work on POWER9 + - KVM: PPC: Book3S: Add MMIO emulation for VMX instructions + - KVM: PPC: Book3S: Fix compile error that occurs with some gcc versions + - KVM: PPC: Book3S HV: Fix trap number return from __kvmppc_vcore_entry + - KVM: PPC: Book3S HV: Fix duplication of host SLB entries + + * ubuntu_zram_smoke test will cause soft lockup on Artful ThunderX ARM64 + (LP: #1755073) + - SAUCE: crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK + + * Update to ocxl driver (LP: #1755161) + - ocxl: fix signed comparison with less than zero + - ocxl: Fix potential bad errno on irq allocation + - ocxl: Add get_metadata IOCTL to share OCXL information to userspace + + * CAPI Flash (cxlflash) update (LP: #1752672) + - scsi: cxlflash: Update cxl-specific arguments to generic cookie + - scsi: cxlflash: Explicitly cache number of interrupts per context + - scsi: cxlflash: Remove embedded CXL work structures + - scsi: cxlflash: Adapter context init can return error + - scsi: cxlflash: Staging to support future accelerators + - SAUCE: cxlflash: Preserve number of interrupts for master contexts + - SAUCE: cxlflash: Avoid clobbering context control register value + - SAUCE: cxlflash: Add argument identifier names + - SAUCE: cxlflash: Introduce OCXL backend + - SAUCE: cxlflash: Hardware AFU for OCXL + - SAUCE: cxlflash: Read host function configuration + - SAUCE: cxlflash: Setup function acTag range + - SAUCE: cxlflash: Read host AFU configuration + - SAUCE: cxlflash: Setup AFU acTag range + - SAUCE: cxlflash: Setup AFU PASID + - SAUCE: cxlflash: Adapter context support for OCXL + - SAUCE: cxlflash: Use IDR to manage adapter contexts + - SAUCE: cxlflash: Support adapter file descriptors for OCXL + - SAUCE: cxlflash: Support adapter context discovery + - SAUCE: cxlflash: Support image reload policy modification + - SAUCE: cxlflash: MMIO map the AFU + - SAUCE: cxlflash: Support starting an adapter context + - SAUCE: cxlflash: Support process specific mappings + - SAUCE: cxlflash: Support AFU state toggling + - SAUCE: cxlflash: Support reading adapter VPD data + - SAUCE: cxlflash: Setup function OCXL link + - SAUCE: cxlflash: Setup OCXL transaction layer + - SAUCE: cxlflash: Support process element lifecycle + - SAUCE: cxlflash: Support AFU interrupt management + - SAUCE: cxlflash: Support AFU interrupt mapping and registration + - SAUCE: cxlflash: Support starting user contexts + - SAUCE: cxlflash: Support adapter context polling + - SAUCE: cxlflash: Support adapter context reading + - SAUCE: cxlflash: Support adapter context mmap and release + - SAUCE: cxlflash: Support file descriptor mapping + - SAUCE: cxlflash: Introduce object handle fop + - SAUCE: cxlflash: Setup LISNs for user contexts + - SAUCE: cxlflash: Setup LISNs for master contexts + - SAUCE: cxlflash: Update synchronous interrupt status bits + - SAUCE: cxlflash: Introduce OCXL context state machine + - SAUCE: cxlflash: Register for translation errors + - SAUCE: cxlflash: Support AFU reset + - SAUCE: cxlflash: Enable OCXL operations + + * [Feature][CFL] Enable pmc_core driver for H, S, and U SKUs (LP: #1730770) + - platform/x86: intel_pmc_core: Remove unused EXPORTED API + - platform/x86: intel_pmc_core: Change driver to a module + - platform/x86: intel_pmc_core: Fix file permission warnings + - platform/x86: intel_pmc_core: Refactor debugfs entries + - platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration + - platform/x86: intel_pmc_core: Convert to ICPU macro + - platform/x86: intel_pmc_core: Remove unused header file + - ACPI / LPIT: Export lpit_read_residency_count_address() + - platform/x86: intel_pmc_core: Read base address from LPIT + - x86/cpu: Add Cannonlake to Intel family + - platform/x86: intel_pmc_core: Add CannonLake PCH support + - platform/x86: intel_pmc_core: Special case for Coffeelake + + * Cpu utilization showing system time for kvm guests (performance) (sysstat) + (LP: #1755979) + - KVM: PPC: Book3S HV: Fix guest time accounting with VIRT_CPU_ACCOUNTING_GEN + + * [Artful][Wyse 3040] System hang when trying to enable an offlined CPU core + (LP: #1736393) + - SAUCE: drm/i915:Don't set chip specific data + - SAUCE: drm/i915: make previous commit affects Wyse 3040 only + + * [Bug] ISH support for CFL-H (LP: #1739522) + - HID: intel-ish-hid: Enable Cannon Lake and Coffee Lake laptop/desktop + + * ath9k can't connect to wifi AP (LP: #1727228) + - ath9k: add MSI support + - ath9k: add a quirk to set use_msi automatically + + * [P9,Power NV][Witherspoon][Ubuntu 18.04][Perf] : PMU events by name it is + not listed under perf list (LP: #1755470) + - iperf vendor events: Use more flexible pattern matching for CPU + identification for mapfile.csv + + * zed process consuming 100% cpu (LP: #1751796) + - SAUCE: Fix ioctl loop-spin in zed (LP: #1751796) + + * Bionic update to 4.15.13 stable release (LP: #1758886) + - scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura + controllers + - staging: android: ashmem: Fix possible deadlock in ashmem_ioctl + - drm/amdgpu: use polling mem to set SDMA3 wptr for VF + - Bluetooth: hci_qca: Avoid setup failure on missing rampatch + - Bluetooth: btqcomsmd: Fix skb double free corruption + - cpufreq: longhaul: Revert transition_delay_us to 200 ms + - media: c8sectpfe: fix potential NULL pointer dereference in + c8sectpfe_timer_interrupt + - drm/msm: fix leak in failed get_pages + - IB/ipoib: Warn when one port fails to initialize + - RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() + - hv_netvsc: Fix the receive buffer size limit + - hv_netvsc: Fix the TX/RX buffer default sizes + - tcp: allow TLP in ECN CWR + - spi: sh-msiof: Avoid writing to registers from spi_master.setup() + - libbpf: prefer global symbols as bpf program name source + - rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. + - rtlwifi: always initialize variables given to RT_TRACE() + - media: bt8xx: Fix err 'bt878_probe()' + - ath10k: handling qos at STA side based on AP WMM enable/disable + - media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart + - qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect + - tty: goldfish: Enable 'earlycon' only if built-in + - serial: 8250_dw: Disable clock on error + - cros_ec: fix nul-termination for firmware build info + - watchdog: Fix potential kref imbalance when opening watchdog + - watchdog: Fix kref imbalance seen if handle_boot_enabled=0 + - platform/chrome: Use proper protocol transfer function + - dmaengine: zynqmp_dma: Fix race condition in the probe + - drm/tilcdc: ensure nonatomic iowrite64 is not used + - mmc: avoid removing non-removable hosts during suspend + - mmc: block: fix logical error to avoid memory leak + - /dev/mem: Add bounce buffer for copy-out + - net: phy: meson-gxl: check phy_write return value + - sfp: fix EEPROM reading in the case of non-SFF8472 SFPs + - sfp: fix non-detection of PHY + - media: s5p-mfc: Fix lock contention - request_firmware() once + - rtc: ac100: Fix multiple race conditions + - IB/ipoib: Avoid memory leak if the SA returns a different DGID + - RDMA/cma: Use correct size when writing netlink stats + - IB/umem: Fix use of npages/nmap fields + - iser-target: avoid reinitializing rdma contexts for isert commands + - bpf/cgroup: fix a verification error for a CGROUP_DEVICE type prog + - vgacon: Set VGA struct resource types + - omapdrm: panel: fix compatible vendor string for td028ttec1 + - mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable + - drm/omap: DMM: Check for DMM readiness after successful transaction commit + - pty: cancel pty slave port buf's work in tty_release + - coresight: Fix disabling of CoreSight TPIU + - PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit + - PCI: endpoint: Fix find_first_zero_bit() usage + - PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures + - media: davinci: fix a debug printk + - clk: check ops pointer on clock register + - dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000 + - clk: use round rate to bail out early in set_rate + - pinctrl: Really force states during suspend/resume + - pinctrl: rockchip: enable clock when reading pin direction register + - iommu/vt-d: clean up pr_irq if request_threaded_irq fails + - ip6_vti: adjust vti mtu according to mtu of lower device + - ip_gre: fix error path when erspan_rcv failed + - ip_gre: fix potential memory leak in erspan_rcv + - soc: qcom: smsm: fix child-node lookup + - RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS + - ARM: dts: aspeed-evb: Add unit name to memory node + - nfsd4: permit layoutget of executable-only files + - clk: at91: pmc: Wait for clocks when resuming + - clk: Don't touch hardware when reparenting during registration + - clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() + - clk: si5351: Rename internal plls to avoid name collisions + - crypto: artpec6 - set correct iv size for gcm(aes) + - hwrng: core - Clean up RNG list when last hwrng is unregistered + - dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 + - IB/mlx5: Fix integer overflows in mlx5_ib_create_srq + - IB/mlx5: Fix out-of-bounds read in create_raw_packet_qp_rq + - RDMA/vmw_pvrdma: Fix usage of user response structures in ABI file + - serial: 8250_pci: Don't fail on multiport card class + - RDMA/core: Do not use invalid destination in determining port reuse + - clk: migrate the count of orphaned clocks at init + - RDMA/ucma: Fix access to non-initialized CM_ID object + - RDMA/ucma: Don't allow join attempts for unsupported AF family + - Linux 4.15.13 + + * Ubuntu18.04:PowerPC - Set Transparent Huge Pages (THP) by default to + "always" (LP: #1753708) + - Config: Set TRANSPARENT_HUGEPAGE_ALWAYS=y on ppc64el + + * Bionic update to 4.15.12 stable release (LP: #1757465) + - x86/cpufeatures: Add Intel Total Memory Encryption cpufeature + - x86/cpufeatures: Add Intel PCONFIG cpufeature + - selftests/x86/entry_from_vm86: Exit with 1 if we fail + - selftests/x86/entry_from_vm86: Add test cases for POPF + - x86/vm86/32: Fix POPF emulation + - x86/speculation, objtool: Annotate indirect calls/jumps for objtool on + 32-bit kernels + - x86/speculation: Remove Skylake C2 from Speculation Control microcode + blacklist + - KVM: x86: Fix device passthrough when SME is active + - x86/mm: Fix vmalloc_fault to use pXd_large + - parisc: Handle case where flush_cache_range is called with no context + - ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats() + - ALSA: hda - Revert power_save option default value + - ALSA: seq: Fix possible UAF in snd_seq_check_queue() + - ALSA: seq: Clear client entry before deleting else at closing + - drm/nouveau/bl: Fix oops on driver unbind + - drm/nouveau/mmu: ALIGN_DOWN correct variable + - drm/amdgpu: fix prime teardown order + - drm/radeon: fix prime teardown order + - drm/amdgpu/dce: Don't turn off DP sink when disconnected + - fs: Teach path_connected to handle nfs filesystems with multiple roots. + - KVM: arm/arm64: Reduce verbosity of KVM init log + - KVM: arm/arm64: Reset mapped IRQs on VM reset + - kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3 + - KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid + - lock_parent() needs to recheck if dentry got __dentry_kill'ed under it + - fs/aio: Add explicit RCU grace period when freeing kioctx + - fs/aio: Use RCU accessors for kioctx_table->table[] + - RDMAVT: Fix synchronization around percpu_ref + - irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis + - nvme: fix subsystem multiple controllers support check + - xfs: preserve i_rdev when recycling a reclaimable inode + - btrfs: Fix NULL pointer exception in find_bio_stripe + - btrfs: add missing initialization in btrfs_check_shared + - btrfs: alloc_chunk: fix DUP stripe size handling + - btrfs: Fix use-after-free when cleaning up fs_devs with a single stale + device + - btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes + - btrfs: Fix memory barriers usage with device stats counters + - scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que + - scsi: qla2xxx: Fix NULL pointer access for fcport structure + - scsi: qla2xxx: Fix logo flag for qlt_free_session_done() + - scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure + - usb: dwc2: fix STM32F7 USB OTG HS compatible + - dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding + - USB: gadget: udc: Add missing platform_device_put() on error in + bdc_pci_probe() + - usb: dwc3: Fix GDBGFIFOSPACE_TYPE values + - usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode + - usb: dwc3: of-simple: fix oops by unbalanced clk disable call + - usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove() + - phy: phy-brcm-usb: Fix two DT properties to match bindings doc + - phy: phy-brcm-usb-init: Some Low Speed keyboards fail on 7271 + - phy: phy-brcm-usb-init: DRD mode can cause crash on startup + - phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled + - Linux 4.15.12 + + * cxl: Fix timebase synchronization status on POWER9 missing (CAPI) + (LP: #1757228) + - cxl: Fix timebase synchronization status on P9 + + * [Feature][GLK] Enable L2 CDP (Code and Data Prioritization) (LP: #1737873) + - x86/intel_rdt: Enumerate L2 Code and Data Prioritization (CDP) feature + - x86/intel_rdt: Add command line parameter to control L2_CDP + + * [Feature] Crystal Ridge-Restrict DAX to configurations with struct page + (LP: #1751724) + - mm, dax: introduce pfn_t_special() + - ext2: auto disable dax instead of failing mount + - ext4: auto disable dax instead of failing mount + - dax: require 'struct page' by default for filesystem dax + - Config: Enable CONFIG_FS_DAX_LIMITED + + * Bionic update to 4.15.11 stable release (LP: #1756978) + - x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 + - ASoC: sun4i-i2s: Fix RX slot number of SUN8I + - ASoC: sgtl5000: Fix suspend/resume + - ASoC: wm_adsp: For TLV controls only register TLV get/set + - ASoC: rt5651: Fix regcache sync errors on resume + - usb: host: xhci-rcar: add support for r8a77965 + - xhci: Fix front USB ports on ASUS PRIME B350M-A + - xhci: fix endpoint context tracer output + - serial: sh-sci: prevent lockup on full TTY buffers + - tty/serial: atmel: add new version check for usart + - uas: fix comparison for error code + - staging: comedi: fix comedi_nsamples_left. + - staging: android: ashmem: Fix lockdep issue during llseek + - scsi: sd_zbc: Fix potential memory leak + - USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h + - usbip: vudc: fix null pointer dereference on udc->lock + - usb: quirks: add control message delay for 1b1c:1b20 + - usb: usbmon: Read text within supplied buffer size + - usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb() + - usb: dwc3: Fix lock-up on ID change during system suspend/resume + - serial: 8250_pci: Add Brainboxes UC-260 4 port serial device + - serial: core: mark port as initialized in autoconfig + - earlycon: add reg-offset to physical address before mapping + - dm mpath: fix passing integrity data + - Revert "btrfs: use proper endianness accessors for super_copy" + - gfs2: Clean up {lookup,fillup}_metapath + - gfs2: Fixes to "Implement iomap for block_map" (2) + - drm/panel: rpi-touchscreen: propagate errors in rpi_touchscreen_i2c_read() + - spi: imx: Fix failure path leak on GPIO request error correctly + - HID: multitouch: Only look at non touch fields in first packet of a frame + - KVM: PPC: Book3S HV: Avoid shifts by negative amounts + - drm/edid: set ELD connector type in drm_edid_to_eld() + - dma-buf/fence: Fix lock inversion within dma-fence-array + - video/hdmi: Allow "empty" HDMI infoframes + - KVM: PPC: Book3S HV: Fix typo in kvmppc_hv_get_dirty_log_radix() + - HID: elo: clear BTN_LEFT mapping + - iwlwifi: mvm: rs: don't override the rate history in the search cycle + - ARM: dts: koelsch: Move cec_clock to root node + - clk: meson: gxbb: fix wrong clock for SARADC/SANA + - ARM: dts: exynos: Correct Trats2 panel reset line + - drm/amdgpu: fix get_max_engine_clock_in_mhz + - staging: rtl8822be: fix missing null check on dev_alloc_skb return + - typec: tcpm: fusb302: Resolve out of order messaging events + - USB: ledtrig-usbport: fix of-node leak + - dt-bindings: serial: Add common rs485 binding for RTS polarity + - sched: Stop switched_to_rt() from sending IPIs to offline CPUs + - sched: Stop resched_cpu() from sending IPIs to offline CPUs + - crypto: chelsio - Fix an error code in chcr_hash_dma_map() + - crypto: ecc - Fix NULL pointer deref. on no default_rng + - crypto: keywrap - Add missing ULL suffixes for 64-bit constants + - crypto: cavium - fix memory leak on info + - test_firmware: fix setting old custom fw path back on exit + - drm/vblank: Fix vblank timestamp debugs + - net: ieee802154: adf7242: Fix bug if defined DEBUG + - rtc: brcmstb-waketimer: fix error handling in brcmstb_waketmr_probe() + - perf report: Fix -D output for user metadata events + - net: xfrm: allow clearing socket xfrm policies. + - gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags simultaneously + - mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]() + - net: thunderx: Set max queue count taking XDP_TX into account + - ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin + - ARM: dts: omap3-n900: Fix the audio CODEC's reset pin + - mtd: nand: ifc: update bufnum mask for ver >= 2.0.0 + - userns: Don't fail follow_automount based on s_user_ns + - xfrm: Fix xfrm_replay_overflow_offload_esn + - leds: pm8058: Silence pointer to integer size warning + - bpf: fix stack state printing in verifier log + - power: supply: sbs-message: double left shift bug in sbsm_select() + - power: supply: ab8500_charger: Fix an error handling path + - power: supply: ab8500_charger: Bail out in case of error in + 'ab8500_charger_init_hw_registers()' + - drm/etnaviv: make THERMAL selectable + - iio: adc: ina2xx: Shift bus voltage register to mask flag bits + - iio: health: max30102: Add power enable parameter to get_temp function + - ath10k: update tdls teardown state to target + - cpufreq: Fix governor module removal race + - KVM: X86: Restart the guest when insn_len is zero and SEV is enabled + - drm/amdgpu:fix random missing of FLR NOTIFY + - scsi: ses: don't ask for diagnostic pages repeatedly during probe + - pwm: stmpe: Fix wrong register offset for hwpwm=2 case + - drm/sun4i: Fix format mask in DE2 driver + - pinctrl: sh-pfc: r8a7791: Add can_clk function + - pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using + STP_ISEN_1_D + - perf annotate: Fix unnecessary memory allocation for s390x + - perf annotate: Fix objdump comment parsing for Intel mov dissassembly + - iwlwifi: mvm: avoid dumping assert log when device is stopped + - drm/amdgpu:fix virtual dce bug + - drm/amdgpu: fix amdgpu_sync_resv v2 + - bnxt_en: Uninitialized variable in bnxt_tc_parse_actions() + - clk: qcom: msm8916: fix mnd_width for codec_digcodec + - mwifiex: cfg80211: do not change virtual interface during scan processing + - ath10k: fix invalid STS_CAP_OFFSET_MASK + - tools/usbip: fixes build with musl libc toolchain + - spi: sun6i: disable/unprepare clocks on remove + - bnxt_en: Don't print "Link speed -1 no longer supported" messages. + - scsi: core: scsi_get_device_flags_keyed(): Always return device flags + - scsi: devinfo: apply to HP XP the same flags as Hitachi VSP + - scsi: dh: add new rdac devices + - clk: renesas: r8a77970: Add LVDS clock + - staging: fsl-dpaa2/eth: Fix access to FAS field + - media: vsp1: Prevent suspending and resuming DRM pipelines + - dm raid: fix raid set size revalidation + - media: cpia2: Fix a couple off by one bugs + - media: davinci: vpif_capture: add NULL check on devm_kzalloc return value + - virtio_net: Disable interrupts if napi_complete_done rescheduled napi + - net: sched: drop qdisc_reset from dev_graft_qdisc + - veth: set peer GSO values + - drm/amdkfd: Fix memory leaks in kfd topology + - powerpc/64: Don't trace irqs-off at interrupt return to soft-disabled + context + - arm64: dts: renesas: salvator-common: Add EthernetAVB PHY reset + - agp/intel: Flush all chipset writes after updating the GGTT + - mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED + - mac80211: remove BUG() when interface type is invalid + - crypto: caam/qi - use correct print specifier for size_t + - ASoC: nuc900: Fix a loop timeout test + - mmc: mmc_test: Ensure command queue is disabled for testing + - Fix misannotated out-of-line _copy_to_user() + - ipvlan: add L2 check for packets arriving via virtual devices + - rcutorture/configinit: Fix build directory error message + - locking/locktorture: Fix num reader/writer corner cases + - ima: relax requiring a file signature for new files with zero length + - IB/mlx5: revisit -Wmaybe-uninitialized warning + - dmaengine: qcom_hidma: check pending interrupts + - drm/i915/glk: Disable Guc and HuC on GLK + - Linux 4.15.11 + - Config: Enable CONFIG_DRM_ETNAVIV_THERMAL=y + + * [FFE][Feature] KVM CLX avx512_vnni (LP: #1739665) + - KVM: x86: add support for UMIP + - KVM: Expose new cpu features to guest + + * Ubuntu18.04[P9 DD2.2 Boston]:Unable to boot power8 compat mode + guests(ubuntu14.04.5) (kvm) (LP: #1756254) + - KVM: PPC: Book3S HV: Allow HPT and radix on the same core for POWER9 v2.2 + + * Allow hugepage backing for "p8compat" mode kvm guests (LP: #1754206) + - KVM: PPC: Book3S HV: Fix VRMA initialization with 2MB or 1GB memory backing + + * [Bug][KVM][Crystal Ridge] Terrible performance of vNVDIMM on QEMU with + device DAX backend (LP: #1745899) + - x86/mm: add a function to check if a pfn is UC/UC-/WC + - KVM: MMU: consider host cache mode in MMIO page check + + * nfp: read ME frequency from vNIC ctrl memory (LP: #1752818) + - nfp: add TLV capabilities to the BAR + - nfp: read ME frequency from vNIC ctrl memory + - nfp: fix TLV offset calculation + + * Miscellaneous Ubuntu changes + - [Packaging] skip cloud tools packaging when not building package + - [Packaging] final-checks -- remove check for empty retpoline files + + -- Seth Forshee <email address hidden> Wed, 04 Apr 2018 08:26:19 -0500 + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +This bug was erroneously marked for verification in bionic; verification is not required and verification-needed-bionic is being removed. + diff --git a/results/classifier/118/permissions/1753309 b/results/classifier/118/permissions/1753309 new file mode 100644 index 00000000..d05ec2d9 --- /dev/null +++ b/results/classifier/118/permissions/1753309 @@ -0,0 +1,135 @@ +permissions: 0.927 +semantic: 0.903 +virtual: 0.883 +assembly: 0.882 +kernel: 0.869 +network: 0.863 +arm: 0.862 +graphic: 0.860 +architecture: 0.857 +device: 0.843 +debug: 0.836 +hypervisor: 0.827 +PID: 0.808 +register: 0.800 +risc-v: 0.787 +files: 0.777 +ppc: 0.767 +user-level: 0.764 +vnc: 0.738 +performance: 0.735 +peripherals: 0.735 +TCG: 0.728 +KVM: 0.702 +VMM: 0.682 +mistranslation: 0.680 +boot: 0.644 +socket: 0.627 +x86: 0.549 +i386: 0.229 + +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/118/permissions/1757 b/results/classifier/118/permissions/1757 new file mode 100644 index 00000000..8c20b0c4 --- /dev/null +++ b/results/classifier/118/permissions/1757 @@ -0,0 +1,31 @@ +permissions: 0.904 +network: 0.762 +device: 0.697 +performance: 0.589 +arm: 0.553 +semantic: 0.413 +architecture: 0.366 +VMM: 0.345 +boot: 0.324 +peripherals: 0.285 +ppc: 0.267 +vnc: 0.245 +mistranslation: 0.224 +TCG: 0.224 +graphic: 0.212 +kernel: 0.212 +i386: 0.200 +hypervisor: 0.198 +KVM: 0.197 +register: 0.190 +virtual: 0.176 +x86: 0.161 +debug: 0.156 +risc-v: 0.151 +socket: 0.140 +PID: 0.136 +files: 0.123 +assembly: 0.042 +user-level: 0.017 + +guest-agent: improve help for --allow-rpcs and --block-rpcs diff --git a/results/classifier/118/permissions/1759338 b/results/classifier/118/permissions/1759338 new file mode 100644 index 00000000..4a95ddca --- /dev/null +++ b/results/classifier/118/permissions/1759338 @@ -0,0 +1,157 @@ +permissions: 0.937 +socket: 0.930 +network: 0.920 +boot: 0.915 +ppc: 0.914 +vnc: 0.911 +VMM: 0.911 +peripherals: 0.911 +device: 0.901 +graphic: 0.901 +architecture: 0.899 +virtual: 0.892 +hypervisor: 0.891 +register: 0.886 +assembly: 0.885 +performance: 0.876 +PID: 0.875 +arm: 0.857 +risc-v: 0.848 +TCG: 0.847 +debug: 0.846 +semantic: 0.844 +kernel: 0.824 +user-level: 0.788 +KVM: 0.734 +files: 0.732 +mistranslation: 0.720 +x86: 0.717 +i386: 0.431 + +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/118/permissions/1761798 b/results/classifier/118/permissions/1761798 new file mode 100644 index 00000000..db3b7b71 --- /dev/null +++ b/results/classifier/118/permissions/1761798 @@ -0,0 +1,538 @@ +permissions: 0.846 +semantic: 0.837 +architecture: 0.835 +debug: 0.823 +device: 0.819 +register: 0.813 +TCG: 0.810 +assembly: 0.810 +PID: 0.804 +virtual: 0.803 +performance: 0.800 +graphic: 0.786 +KVM: 0.782 +arm: 0.771 +peripherals: 0.770 +files: 0.758 +risc-v: 0.752 +vnc: 0.751 +socket: 0.747 +VMM: 0.746 +ppc: 0.744 +kernel: 0.735 +boot: 0.732 +network: 0.728 +user-level: 0.725 +hypervisor: 0.718 +mistranslation: 0.698 +x86: 0.692 +i386: 0.493 + +live migration intermittently fails in CI with "VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8" + +Seen here: + +http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-multinode-live-migration/8de6e74/logs/subnode-2/libvirt/qemu/instance-00000002.txt.gz + +2018-04-05T21:48:38.205752Z qemu-system-x86_64: -chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on: char device redirected to /dev/pts/0 (label charserial0) +warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] +2018-04-05T21:48:43.153268Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8 +2018-04-05T21:48:43.153288Z qemu-system-x86_64: Failed to load virtio-blk:virtio +2018-04-05T21:48:43.153292Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' +2018-04-05T21:48:43.153347Z qemu-system-x86_64: load of migration failed: Operation not permitted +2018-04-05 21:48:43.198+0000: shutting down, reason=crashed + +And in the n-cpu logs on the other host: + +http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-multinode-live-migration/8de6e74/logs/screen-n-cpu.txt.gz#_Apr_05_21_48_43_257541 + +There is a related Red Hat bug: + +https://bugzilla.redhat.com/show_bug.cgi?id=1450524 + +The CI job failures are at present using the Pike UCA: + +ii libvirt-bin 3.6.0-1ubuntu6.2~cloud0 + +ii qemu-system-x86 1:2.10+dfsg-0ubuntu3.5~cloud0 + +Maybe when we move to use the Queens UCA we'll have better luck with this: + +https://review.openstack.org/#/c/554314/ + +That has these package versions: + +ii libvirt-bin 4.0.0-1ubuntu4~cloud0 + +ii qemu-system-x86 1:2.11+dfsg-1ubuntu2~cloud0 + +The offending instance QEMU from the log that crashed: + +http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm-multinode-live-migration/8de6e74/logs/subnode-2/libvirt/qemu/instance-00000002.txt.gz + +---------------------------------------------------------------------------- +2018-04-05 21:48:38.136+0000: starting up libvirt version: 3.6.0, package: 1ubuntu6.2~cloud0 (Openstack Ubuntu Testing Bot <email address hidden> Wed, 07 Feb 2018 20:05:24 +0000), qemu version: 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5~cloud0), hostname: ubuntu-xenial-ovh-bhs1-0003361707 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name guest=instance-00000002,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-instance-00000002/master-key.aes -machine pc-i440fx-artful,accel=tcg,usb=off,dump-guest-core=off -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid e70df34f-395e-4482-9c24-101f12cf635d -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=17.0.0,serial=97e1e00c-8afb-4356-b55e-92e997c5a1a7,uuid=e70df34f-395e-4482-9c24-101f12cf635d,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-instance-00000002/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/opt/stack/data/nova/instances/e70df34f-395e-4482-9c24-101f12cf635d/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=29,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:15:ea:59,bus=pci.0,addr=0x3 -add-fd set=1,fd=32 -chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on +2018-04-05T21:48:38.205752Z qemu-system-x86_64: -chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on: char device redirected to /dev/pts/0 (label charserial0) +warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] +2018-04-05T21:48:43.153268Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8 +2018-04-05T21:48:43.153288Z qemu-system-x86_64: Failed to load virtio-blk:virtio +2018-04-05T21:48:43.153292Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' +2018-04-05T21:48:43.153347Z qemu-system-x86_64: load of migration failed: Operation not permitted +2018-04-05 21:48:43.198+0000: shutting down, reason=crashed +---------------------------------------------------------------------------- + + + +I'm not sure that's the same as the bz 1450524 - in this case it's virtio-blk, where I *think* that bz was tracked down to a virtio-balloon and a virtio-net issue. + +Hm, looks like the e-r query [1] for this bug doesn't find it if the screen-n-cpu.txt is on the subnode-2: + +http://logs.openstack.org/25/566425/4/gate/nova-live-migration/27afb39/logs/subnode-2/screen-n-cpu.txt.gz?level=TRACE#_May_15_00_54_26_234161 + +[1] https://github.com/openstack-infra/elastic-recheck/blob/master/queries/1761798.yaml + +Ran into a similar issue, when snapshotting an instance, it won't start afterwards. +Root cause is inconsistency between state of device virtio-scsi and the saved VM RAM state in /var/lib/libvirt/qemu/save/ +Removing instance-0000****.save file from thsi folder allows starting the VM back but may cause data corruption. +Specifics of my case - using virtio-scsi driver and discard enabled, backend is Ceph. Impacted 2 Windows VMs so far. + +I also think this is a qemu bug, will do some tests, try to reproduce. + +We hit a very similar issue https://zuul.opendev.org/t/openstack/build/d50877ae15db4022b82f4bb1d1d52cea/log/logs/subnode-2/screen-n-cpu.txt?severity=0#13482 + +Source node +https://zuul.opendev.org/t/openstack/build/d50877ae15db4022b82f4bb1d1d52cea/log/logs/subnode-2/libvirt/qemu/instance-0000001a.txt + +2020-11-20 14:25:24.887+0000: starting up libvirt version: 6.0.0, package: 0ubuntu8.4~cloud0 (Openstack Ubuntu Testing Bot <email address hidden> Tue, 15 Sep 2020 20:36:28 +0000), qemu version: 4.2.1Debian 1:4.2-3ubuntu6.7~cloud0, kernel: 4.15.0-124-generic, hostname: ubuntu-bionic-ovh-bhs1-0021872195 + +LC_ALL=C \ + +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ + +HOME=/var/lib/libvirt/qemu/domain-19-instance-0000001a \ + +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-19-instance-0000001a/.local/share \ + +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-19-instance-0000001a/.cache \ + +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-19-instance-0000001a/.config \ + +QEMU_AUDIO_DRV=none \ + +/usr/bin/qemu-system-x86_64 \ + +-name guest=instance-0000001a,debug-threads=on \ + +-S \ + +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-instance-0000001a/master-key.aes \ + +-machine pc-i440fx-4.2,accel=tcg,usb=off,dump-guest-core=off \ + +-cpu qemu64,hypervisor=on,lahf-lm=on \ + +-m 128 \ + +-overcommit mem-lock=off \ + +-smp 1,sockets=1,cores=1,threads=1 \ + +-uuid 2c468d92-4b19-426a-8c25-16b4624c21a4 \ + +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=22.1.0,serial=2c468d92-4b19-426a-8c25-16b4624c21a4,uuid=2c468d92-4b19-426a-8c25-16b4624c21a4,family=Virtual Machine' \ + +-no-user-config \ + +-nodefaults \ + +-chardev socket,id=charmonitor,fd=35,server,nowait \ + +-mon chardev=charmonitor,id=monitor,mode=control \ + +-rtc base=utc \ + +-no-shutdown \ + +-boot strict=on \ + +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ + +-blockdev '{"driver":"file","filename":"/opt/stack/data/nova/instances/_base/61bd5e531ab4c82456aa5300ede7266b3610be79","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ + +-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ + +-blockdev '{"driver":"file","filename":"/opt/stack/data/nova/instances/2c468d92-4b19-426a-8c25-16b4624c21a4/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ + +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \ + +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \ + +-netdev tap,fd=37,id=hostnet0 \ + +-device virtio-net-pci,host_mtu=1400,netdev=hostnet0,id=net0,mac=fa:16:3e:43:11:f4,bus=pci.0,addr=0x3 \ + +-add-fd set=2,fd=39 \ + +-chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on \ + +-device isa-serial,chardev=charserial0,id=serial0 \ + +-vnc 127.0.0.1:0 \ + +-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \ + +-incoming defer \ + +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ + +-object rng-random,id=objrng0,filename=/dev/urandom \ + +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 \ + +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ + +-msg timestamp=on + +char device redirected to /dev/pts/2 (label charserial0) + +virtio: bogus descriptor or out of resources + +2020-11-20 14:25:39.911+0000: initiating migration + +2020-11-20T14:26:21.409517Z qemu-system-x86_64: terminating on signal 15 from pid 17395 (/usr/sbin/libvirtd) + +2020-11-20 14:26:21.610+0000: shutting down, reason=destroyed + + + +Target node +https://zuul.opendev.org/t/openstack/build/d50877ae15db4022b82f4bb1d1d52cea/log/logs/libvir +t/qemu/instance-0000001a.txt + +2020-11-20 14:25:11.589+0000: starting up libvirt version: 6.0.0, package: 0ubuntu8.4~cloud0 (Openstack Ubuntu Testing Bot <email address hidden> Tue, 15 Sep 2020 20:36:28 +0000), qemu version: 4.2.1Debian 1:4.2-3ubuntu6.7~cloud0, kernel: 4.15.0-124-generic, hostname: ubuntu-bionic-ovh-bhs1-0021872194 + +LC_ALL=C \ + +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ + +HOME=/var/lib/libvirt/qemu/domain-10-instance-0000001a \ + +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-10-instance-0000001a/.local/share \ + +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-10-instance-0000001a/.cache \ + +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-10-instance-0000001a/.config \ + +QEMU_AUDIO_DRV=none \ + +/usr/bin/qemu-system-x86_64 \ + +-name guest=instance-0000001a,debug-threads=on \ + +-S \ + +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10-instance-0000001a/master-key.aes \ + +-machine pc-i440fx-4.2,accel=tcg,usb=off,dump-guest-core=off \ + +-cpu qemu64 \ + +-m 128 \ + +-overcommit mem-lock=off \ + +-smp 1,sockets=1,cores=1,threads=1 \ + +-uuid 2c468d92-4b19-426a-8c25-16b4624c21a4 \ + +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=22.1.0,serial=2c468d92-4b19-426a-8c25-16b4624c21a4,uuid=2c468d92-4b19-426a-8c25-16b4624c21a4,family=Virtual Machine' \ + +-no-user-config \ + +-nodefaults \ + +-chardev socket,id=charmonitor,fd=32,server,nowait \ + +-mon chardev=charmonitor,id=monitor,mode=control \ + +-rtc base=utc \ + +-no-shutdown \ + +-boot strict=on \ + +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ + +-blockdev '{"driver":"file","filename":"/opt/stack/data/nova/instances/_base/61bd5e531ab4c82456aa5300ede7266b3610be79","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ + +-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ + +-blockdev '{"driver":"file","filename":"/opt/stack/data/nova/instances/2c468d92-4b19-426a-8c25-16b4624c21a4/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ + +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \ + +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \ + +-netdev tap,fd=34,id=hostnet0 \ + +-device virtio-net-pci,host_mtu=1400,netdev=hostnet0,id=net0,mac=fa:16:3e:43:11:f4,bus=pci.0,addr=0x3 \ + +-add-fd set=2,fd=36 \ + +-chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on \ + +-device isa-serial,chardev=charserial0,id=serial0 \ + +-vnc 0.0.0.0:0 \ + +-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \ + +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ + +-object rng-random,id=objrng0,filename=/dev/urandom \ + +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 \ + +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ + +-msg timestamp=on + +char device redirected to /dev/pts/0 (label charserial0) + +2020-11-20 14:25:25.637+0000: initiating migration + +2020-11-20 14:25:26.776+0000: shutting down, reason=migrated + +2020-11-20T14:25:26.777394Z qemu-system-x86_64: terminating on signal 15 from pid 31113 (/usr/sbin/libvirtd) + +2020-11-20 14:25:38.909+0000: starting up libvirt version: 6.0.0, package: 0ubuntu8.4~cloud0 (Openstack Ubuntu Testing Bot <email address hidden> Tue, 15 Sep 2020 20:36:28 +0000), qemu version: 4.2.1Debian 1:4.2-3ubuntu6.7~cloud0, kernel: 4.15.0-124-generic, hostname: ubuntu-bionic-ovh-bhs1-0021872194 + +LC_ALL=C \ + +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ + +HOME=/var/lib/libvirt/qemu/domain-13-instance-0000001a \ + +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-13-instance-0000001a/.local/share \ + +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-13-instance-0000001a/.cache \ + +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-13-instance-0000001a/.config \ + +QEMU_AUDIO_DRV=none \ + +/usr/bin/qemu-system-x86_64 \ + +-name guest=instance-0000001a,debug-threads=on \ + +-S \ + +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-instance-0000001a/master-key.aes \ + +-machine pc-i440fx-4.2,accel=tcg,usb=off,dump-guest-core=off \ + +-cpu qemu64,hypervisor=on,lahf-lm=on \ + +-m 128 \ + +-overcommit mem-lock=off \ + +-smp 1,sockets=1,cores=1,threads=1 \ + +-uuid 2c468d92-4b19-426a-8c25-16b4624c21a4 \ + +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=22.1.0,serial=2c468d92-4b19-426a-8c25-16b4624c21a4,uuid=2c468d92-4b19-426a-8c25-16b4624c21a4,family=Virtual Machine' \ + +-no-user-config \ + +-nodefaults \ + +-chardev socket,id=charmonitor,fd=34,server,nowait \ + +-mon chardev=charmonitor,id=monitor,mode=control \ + +-rtc base=utc \ + +-no-shutdown \ + +-boot strict=on \ + +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ + +-blockdev '{"driver":"file","filename":"/opt/stack/data/nova/instances/_base/61bd5e531ab4c82456aa5300ede7266b3610be79","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ + +-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ + +-blockdev '{"driver":"file","filename":"/opt/stack/data/nova/instances/2c468d92-4b19-426a-8c25-16b4624c21a4/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ + +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \ + +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \ + +-netdev tap,fd=36,id=hostnet0 \ + +-device virtio-net-pci,host_mtu=1400,netdev=hostnet0,id=net0,mac=fa:16:3e:43:11:f4,bus=pci.0,addr=0x3 \ + +-add-fd set=2,fd=38 \ + +-chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on \ + +-device isa-serial,chardev=charserial0,id=serial0 \ + +-vnc 0.0.0.0:0 \ + +-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \ + +-incoming defer \ + +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ + +-object rng-random,id=objrng0,filename=/dev/urandom \ + +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 \ + +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ + +-msg timestamp=on + +char device redirected to /dev/pts/1 (label charserial0) + +2020-11-20T14:25:40.720757Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 0xb8 inconsistent with Host index 0xe0: delta 0xffd8 + +2020-11-20T14:25:40.720785Z qemu-system-x86_64: Failed to load virtio-blk:virtio + +2020-11-20T14:25:40.720790Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' + +2020-11-20T14:25:40.720824Z qemu-system-x86_64: load of migration failed: Operation not permitted + +2020-11-20 14:25:40.778+0000: shutting down, reason=failed + + + + + +in the new case we have the same qemu/libvirt version in both nodes + +4.2.1Debian 1:4.2-3ubuntu6.7~cloud0 + +and in this cae its failng for the virtio-blk device not the memroy ballon + +before the migration starts we see + +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/2 (label charserial0) +virtio: bogus descriptor or out of resources +2020-11-20 14:25:39.911+0000: initiating migration + +on the destination +https://zuul.opendev.org/t/openstack/build/d50877ae15db4022b82f4bb1d1d52cea/log/logs/subnode-2/libvirt/qemu/instance-0000001a.txt + +then on the source we see + +char device redirected to /dev/pts/1 (label charserial0) +2020-11-20T14:25:40.720757Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 0xb8 inconsistent with Host index 0xe0: delta 0xffd8 +2020-11-20T14:25:40.720785Z qemu-system-x86_64: Failed to load virtio-blk:virtio +2020-11-20T14:25:40.720790Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' +2020-11-20T14:25:40.720824Z qemu-system-x86_64: load of migration failed: Operation not permitted + +when it fails +https://zuul.opendev.org/t/openstack/build/d50877ae15db4022b82f4bb1d1d52cea/log/logs/libvirt/qemu/instance-0000001a.txt + + + +[Copy/pasting my comment from here: https://bugs.launchpad.net/nova/+bug/1737625/comments/4] + +I just talked to Dave Gilbert from upstream QEMU. Overall, as I implied in comment#2, this gnarly issue requires specialized debugging, digging deep into the bowels of QEMU, 'virtio-blk' and 'virtio. + +That said, Dave notes that we get this "guest index inconsistent" error when the migrated RAM is inconsistent with the migrated 'virtio' device state. And a common case is where a 'virtio' device does an operation after the vCPU is stopped and after RAM has been transmitted. + +Dave makes some guesswork of a potential scenario where this can occur: + + - Guest is running + - ... live migration starts + - ... a "block read" request gets submitteed + - ... live migration stops the vCPUs, finishes transmitting RAM + - ... the "block read" completes, 'virtio-blk' updates pointers + - ... live migration "serializes" the 'virito-blk' state + +So the "guest index inconsistent" state would only happen if you got unlucky with the timing of that read. + +Another possibility, Dave points out, is that the guest has screwed up the device state somehow; the migration code in 'virtio' checks the state a lot. We have ruled this possibility out becausethe guest is just a garden-variety CirrOS instance idling; nothing special about it. + + +hang on, I've just noticed the : + + char device redirected to /dev/pts/2 (label charserial0) +virtio: bogus descriptor or out of resources +2020-11-20 14:25:39.911+0000: initiating migration + +I've never seen that 'bogus descriptor or out of resources' one before; the fact that's happening before the migration starts is suspicious that something has already gone wrong before migration started. +Is that warning present in all these failures? + +I see two recent hits we have still logs for. + +The one described in comment #10 + +And another but there the error message is a bit different: + +on the migration source host: +: https://6f0be18d925d64906a23-689ad0b9b6f06bc0c51bfb99bf86ea04.ssl.cf5.rackcdn.com/698706/4/check/nova-grenade-multinode/ee2dbea/logs/libvirt/qemu/instance-0000001b.txt + +char device redirected to /dev/pts/0 (label charserial0) +virtio: zero sized buffers are not allowed +2020-11-23 22:20:54.297+0000: initiating migration + +on the migration destination +https://6f0be18d925d64906a23-689ad0b9b6f06bc0c51bfb99bf86ea04.ssl.cf5.rackcdn.com/698706/4/check/nova-grenade-multinode/ee2dbea/logs/subnode-2/libvirt/qemu/instance-0000001b.txt + +char device redirected to /dev/pts/0 (label charserial0) +2020-11-23T22:20:55.129189Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 0x62 inconsistent with Host index 0xa1: delta 0xffc1 +2020-11-23T22:20:55.129230Z qemu-system-x86_64: Failed to load virtio-blk:virtio +2020-11-23T22:20:55.129241Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:03.0/virtio-blk' +2020-11-23T22:20:55.129259Z qemu-system-x86_64: load of migration failed: Operation not permitted + + + + + + + +OK, but that still says in both cases here we've got a virtio error telling us that the queues are broken before migration even starts; so we should try and figure out why that's happening first. + +Is this still an issue with the latest release of QEMU (v6.0)? + +I got same issue on centos 7 stein + + +Hello, some news ....I wonder if they can help: +I am testing with some virtual machine again. +If I follows this steps it works (but I lost network connection): + +1) Detach network interface from instance +2) Attach network interface to instance +3) Migrate instance +4) Loggin into instance using console and restart networking + +while if I restart networking before live migration it does not work. +So, when someone mentioned + +######################## +we get this "guest index inconsistent" error when the migrated RAM is inconsistent with the migrated 'virtio' device state. And a common case is where a 'virtio' device does an operation after the vCPU is stopped and after RAM has been transmitted. +#############################à +the network traffic could be the problem ? +Ignazio + +Be careful, it might not be the same bug. + +Yes, it *shouldn't* be a problem, but if the virtio code in qemu is broken then it will keep accepting incoming packets even when the guest is stopped in the final part of the migration and you get the contents of the RAM taken before the reception ofthe packet, but hte virtio state that's in the migration stream after the reception of the packet, and it's inconsistent. + +But the case the other reporter mentioned is on a virtio-blk device; the same thing can happen if the storage device stalls/is slow during the migration code - i.e. a block read takes ages to complete and happens to complete after the point it should have stopped for migration. + +Is this still happening with the latest release? + +[Expired for OpenStack Compute (nova) 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/118/permissions/1769053 b/results/classifier/118/permissions/1769053 new file mode 100644 index 00000000..140baf3f --- /dev/null +++ b/results/classifier/118/permissions/1769053 @@ -0,0 +1,1172 @@ +permissions: 0.944 +PID: 0.905 +assembly: 0.903 +semantic: 0.902 +debug: 0.900 +architecture: 0.898 +VMM: 0.887 +register: 0.886 +arm: 0.884 +user-level: 0.879 +performance: 0.879 +device: 0.872 +KVM: 0.867 +kernel: 0.858 +graphic: 0.857 +virtual: 0.856 +boot: 0.853 +files: 0.849 +mistranslation: 0.845 +risc-v: 0.826 +peripherals: 0.802 +socket: 0.787 +ppc: 0.771 +TCG: 0.760 +vnc: 0.751 +hypervisor: 0.746 +network: 0.713 +x86: 0.672 +i386: 0.582 + +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/118/permissions/1771238 b/results/classifier/118/permissions/1771238 new file mode 100644 index 00000000..1ed9c260 --- /dev/null +++ b/results/classifier/118/permissions/1771238 @@ -0,0 +1,221 @@ +permissions: 0.838 +virtual: 0.811 +debug: 0.803 +network: 0.779 +files: 0.769 +assembly: 0.764 +architecture: 0.763 +PID: 0.760 +semantic: 0.759 +peripherals: 0.754 +graphic: 0.754 +user-level: 0.752 +mistranslation: 0.747 +TCG: 0.745 +socket: 0.744 +arm: 0.739 +register: 0.733 +device: 0.731 +VMM: 0.731 +kernel: 0.730 +vnc: 0.724 +KVM: 0.705 +performance: 0.702 +boot: 0.684 +risc-v: 0.668 +ppc: 0.647 +hypervisor: 0.603 +x86: 0.567 +i386: 0.444 + +Not able to passthrough > 32 PCIe devices to a KVM Guest + +Using an Ubuntu Server 16.04-based host with KVM hypervisor installed, we are unable to launch a vanilla Ubuntu Server 16.04.4 guest with >= 32 PCIe devices. It is 100% reproducible. Using fewer PCIe devices works fine. We are using the vanilla kvm and qemu packages from the Canonical repos. + +The ultimate goal is to create a KVM Guest wherein I can passthrough 44 PCI devices. + +When a KVM Guest launches, it also has some internal PCIe devices including host bridge, USB, IDE (for virtual disk), and virtual nic etc. + +Script used to launch all devices looks like this: + +#!/bin/bash +NAME=16gpuvm + +sudo qemu-img create -f qcow2 /home/lab/kvm/images/${NAME}.img 40G && +sudo virt-install \ +--name ${NAME} \ +--ram 716800 \ +--vcpus 88 \ +--disk path=/home/lab/kvm/images/${NAME}.img,format=qcow2 \ +--network bridge=virbr0 \ +--graphics none \ +--host-device 34:00.0 \ +--host-device 36:00.0 \ +--host-device 39:00.0 \ +--host-device 3b:00.0 \ +--host-device 57:00.0 \ +--host-device 59:00.0 \ +--host-device 5c:00.0 \ +--host-device 5e:00.0 \ +--host-device 61:00.0 \ +--host-device 62:00.0 \ +--host-device 63:00.0 \ +--host-device 65:00.0 \ +--host-device 66:00.0 \ +--host-device 67:00.0 \ +--host-device 35:00.0 \ +--host-device 3a:00.0 \ +--host-device 58:00.0 \ +--host-device 5d:00.0 \ +--host-device 2e:00.0 \ +--host-device 2f:00.0 \ +--host-device 51:00.0 \ +--host-device 52:00.0 \ +--host-device b7:00.0 \ +--host-device b9:00.0 \ +--host-device bc:00.0 \ +--host-device be:00.0 \ +--host-device e0:00.0 \ +--host-device e2:00.0 \ +--host-device e5:00.0 \ +--host-device e7:00.0 \ +--host-device c1:00.0 \ +--host-device c2:00.0 \ +--host-device c3:00.0 \ +--host-device c5:00.0 \ +--host-device c6:00.0 \ +--host-device c7:00.0 \ +--host-device b8:00.0 \ +--host-device bd:00.0 \ +--host-device e1:00.0 \ +--host-device e6:00.0 \ +--host-device b1:00.0 \ +--host-device b2:00.0 \ +--host-device da:00.0 \ +--host-device db:00.0 \ +--console pty,target_type=serial \ +--location http://ftp.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64 \ +--initrd-inject=/home/lab/kvm/images/preseed.cfg \ +--extra-args=" +console=ttyS0,115200 +locale=en_US +console-keymaps-at/keymap=us +console-setup/ask_detect=false +console-setup/layoutcode=us +keyboard-configuration/layout=USA +keyboard-configuration/variant=USA +hostname=${NAME} +file=file:/preseed.cfg +" + +Passing > 32 device causes this issue: 32nd device hits a DPC error and the host/HV crashes: + + +Apr 25 22:34:35 xpl-evt-16 kernel: [18125.977496] dpc 0000:5b:10.0:pcie210: DPC containment event, status:0x0009 source:0x0000 +Apr 25 22:34:35 xpl-evt-16 kernel: [18125.977500] dpc 0000:5b:10.0:pcie210: DPC unmasked uncorrectable error detected, remove downstream devices +Apr 25 22:34:35 xpl-evt-16 kernel: [18125.994326] vfio-pci 0000:5e:00.0: Refused to change power state, currently in D3 +Apr 25 22:34:35 xpl-evt-16 kernel: [18125.994427] iommu: Removing device 0000:5e:00.0 from group 92 + + +From syslog (attached) + +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194358] dpc 0000:bb:04.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194387] dpc 0000:bb:10.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194413] dpc 0000:d9:00.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194439] dpc 0000:d9:01.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194472] dpc 0000:d9:02.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194499] dpc 0000:d9:03.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194526] dpc 0000:d9:04.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194553] dpc 0000:d9:0c.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194583] dpc 0000:df:00.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194619] dpc 0000:df:04.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194649] dpc 0000:df:10.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194679] dpc 0000:e4:00.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194709] dpc 0000:e4:04.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194742] dpc 0000:e4:10.0:pcie210: DPC error containment capabilities: Int Msg #3, RPExt- PoisonedTLP+ SwTrigger+ RP PIO Log 0, DL_ActiveErr+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.194763] pciehp 0000:00:1c.0:pcie004: Slot #0 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.195036] pciehp 0000:60:02.0:pcie204: Slot #2 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.195278] pciehp 0000:60:0a.0:pcie204: Slot #10 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.195513] pciehp 0000:c0:02.0:pcie204: Slot #2 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.195753] pciehp 0000:c0:0a.0:pcie204: Slot #10 AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+ +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196196] efifb: probing for efifb +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196242] efifb: framebuffer at 0x9c000000, using 1920k, total 1920k +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196247] efifb: mode is 800x600x32, linelength=3200, pages=1 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196250] efifb: scrolling: redraw +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.196254] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.206652] Console: switching to colour frame buffer device 100x37 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.217034] fb0: EFI VGA frame buffer device +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.217173] intel_idle: MWAIT substates: 0x2020 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.217174] intel_idle: v0.4.1 model 0x55 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.220874] intel_idle: lapic_timer_reliable_states 0xffffffff +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.221219] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.221590] ACPI: Power Button [PWRF] +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.231089] ERST: Error Record Serialization Table (ERST) support is initialized. +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.231312] pstore: using zlib compression +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.231444] pstore: Registered erst as persistent store backend +Apr 25 22:37:13 xpl-evt-16 kernel: [ 2.232503] GHES: APEI firmware first mode is enabled by APEI bit and WHEA _OSC. + + + +All PCI devices go offline include NVMe. + +OS Drives go away, RAID-1 is remounted as RO, and eventually system crashes. + + +Apr 25 22:37:13 xpl-evt-16 rsyslogd-2007: action 'action 9' suspended, next retry is Wed Apr 25 22:37:43 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ] +Apr 25 22:37:13 xpl-evt-16 systemd-udevd[1383]: Process '/sbin/mdadm --incremental /dev/nvme1n1p2 --offroot' failed with exit code 1. +Apr 25 22:37:13 xpl-evt-16 systemd-udevd[1371]: Process '/sbin/mdadm --incremental /dev/nvme0n1p2 --offroot' failed with exit code 1. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting Apply Kernel Variables... +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Mounted Configuration File System. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Mounted FUSE Control File System. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Started Apply Kernel Variables. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Found device /dev/disk/by-uuid/269E-631A. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting File System Check on /dev/disk/by-uuid/269E-631A... +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Started File System Check Daemon to report status. +Apr 25 22:37:13 xpl-evt-16 systemd-fsck[1576]: fsck.fat 3.0.28 (2015-05-16) +Apr 25 22:37:13 xpl-evt-16 systemd-fsck[1576]: /dev/nvme0n1p1: 10 files, 1168/130812 clusters +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Started File System Check on /dev/disk/by-uuid/269E-631A. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Mounting /boot/efi... +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Mounted /boot/efi. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Reached target Local File Systems. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting Preprocess NFS configuration... +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting Create Volatile Files and Directories... +Apr 25 22:37:13 xpl-evt-16 systemd-tmpfiles[1714]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring. +Apr 25 22:37:13 xpl-evt-16 systemd[1]: Starting openibd - configure Mellanox devices... +Apr 25 22:37:13 xpl-evt-16 kernel: [ 0.000000] random: get_random_bytes called from start_kernel+0x42/0x50d with crng_init=0 + +If the host kernel crashes, this is certainly rather a KVM bug than a QEMU bug, so you should report this to the KVM / kernel mailing list instead of opening an (upstream) QEMU bug ticket. + +@David Coronel: It's not clear to me - is this a regression? + +@Khaled El Mously: It's more a feature request. + +I removed upstream QEMU from this bug pending further analysis and so we can go through the right channels if this needs to go upstream. + +At least for the DPC protection it seems more a kernel issue in regard to PCIe handling than anything else for now. Due to that I'm adding a task for the kernel as well. + +This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: + +apport-collect 1771238 + +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. + +Agreed with the initial analysis, there's nothing in device assignment to limit to 32 devices except where downstream distros have intentionally added a limit for support purposes. The issue here is that the host hit a PCIe Downstream Port Containment uncorrectable error, apparently causing at least a sub-hierarchy of the PCIe topology to go offline. This is potentially more likely a hardware issue than a software issue. It may be possible to mask the issue by unbinding the interconnect devices in the affected sub-hierarchy from the dpc driver. It might also be interesting to test with a subset of devices to understand if there are specific devices triggering spurious DPC errors, it may only be a sub-set or single device triggering spurious errors, or perhaps it's the succession of bus resets for GPU assignment that trigger such a fault. The system firmware logs may provide additional information regarding the source(s) of the fault. + +Thanks Alex for cross checking. +I got handed a seabios change that was mentioned to make this work. +I'll clean it up and build/test on my own. + +Once I have a good feeling I'll submit an RFC upstream for review and set you on CC. + +I got access to such a machine and successfully added >32 cards via hotplug as well as statically in the initial guest xml of libvirt. + +I face maybe related issue around "accel/kvm/kvm-all.c:952: kvm_irqchip_commit_routes: Assertion `ret == 0' failed." now but noting seems like the old DPC issue. + +Closing this bug (and considering to open a new one for the different issue mentioned above). + diff --git a/results/classifier/118/permissions/1772262 b/results/classifier/118/permissions/1772262 new file mode 100644 index 00000000..28353290 --- /dev/null +++ b/results/classifier/118/permissions/1772262 @@ -0,0 +1,84 @@ +permissions: 0.881 +virtual: 0.852 +assembly: 0.849 +register: 0.847 +device: 0.843 +user-level: 0.835 +hypervisor: 0.834 +semantic: 0.830 +graphic: 0.825 +network: 0.816 +PID: 0.816 +architecture: 0.814 +performance: 0.807 +debug: 0.805 +boot: 0.804 +files: 0.803 +KVM: 0.795 +arm: 0.792 +ppc: 0.790 +TCG: 0.786 +vnc: 0.784 +mistranslation: 0.781 +kernel: 0.780 +VMM: 0.779 +peripherals: 0.774 +socket: 0.762 +risc-v: 0.749 +x86: 0.726 +i386: 0.626 + +Adding -spice doesn't respect environment variable QEMU_AUDIO_DRV + +When -spice is added to the commandline, QEMU_AUDIO_DRV=alsa is not respected and I receive no audio from the guest using the alsa driver. When -spice options are omitted, audio works as usual. + +I want to channel mouse and keyboard events to the guest using spice (with looking-glass) instead of a third-party product over a network interface (with synergy), but audio ends up over the spice protocol as well instead of using alsa despite asking otherwise. For example, one will only hear audio when a program like spicy is running. Naturally it would be nice if this were not needed, since spice audio is gappier than regular audio on my machine. + +Perhaps if -spice added an option similar to agent-mouse=off but for audio, (say audio-pipe=off or so for example,) this might mitigate the issue in a more naive fashion UX-wise, without having to force the issue with environment variables that unfortunately for me don't seem to work. :( + +QEMU emulator version 2.12.0 + +Commandline + + qemu-system-x86_64 \ + -ctrl-grab \ + -enable-kvm \ + -cpu host,hv-time,kvm=off \ + -smp cores=4 \ + -m 8G \ + -M q35 \ + -vga none \ + -netdev tap,id=hostnet,ifname=tap1,script=no,downscript=no \ + -net nic,model=virtio,macaddr=52:54:FD:BF:F7:9A,netdev=hostnet \ + -netdev user,id=usernet,smb=/media/DRIVE-C/tux/vms/share \ + -net nic,model=virtio,macaddr=52:54:2E:40:4F:C8,netdev=usernet \ + -usb \ + -device usb-ehci,id=ehci \ + -device ioh3420,bus=pcie.0,addr=1c,multifunction=on,port=1,chassis=1,id=root.1 \ + -device vfio-pci,host=07:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ + -device ich9-intel-hda \ + -device hda-micro \ + -drive if=virtio,file=vm/win10/disk.img,media=disk \ + -boot menu=on,splash=splash/boot.jpg,splash-time=5000 \ + -name win10 \ + -device ivshmem-plain,memdev=ivshmem \ + -object memory-backend-file,id=ivshmem,share=on,mem-path=/dev/shm/looking-glass,size=32M \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent \ + -spice addr=127.0.0.1,port=5900,disable-ticketing + +When the last four options are not present, audio works as expected. This is with both a windows 10 guest and a windows 7 guest. + +Doesn't reproduce. The *default* driver is changed to spice when spice is enabled, but overriding using QEMU_AUDIO_DRV is not disabled. Any chance you didn't export QEMU_AUDIO_DRV? + +>Any chance you didn't export QEMU_AUDIO_DRV? + +Okay, I just checked by calling env in the same fashion. + +Well lash me bootlaces, it turns out that sudo needs to be invoked with the -E flag to preserve the environment. It's funny, the examples I read up on never mentioned this. + +Sorry for littering the bug tracker with a silly end-user problem. + +Cheers. + diff --git a/results/classifier/118/permissions/1779017 b/results/classifier/118/permissions/1779017 new file mode 100644 index 00000000..cc517531 --- /dev/null +++ b/results/classifier/118/permissions/1779017 @@ -0,0 +1,125 @@ +permissions: 0.940 +user-level: 0.932 +performance: 0.917 +device: 0.905 +semantic: 0.900 +register: 0.898 +arm: 0.897 +graphic: 0.895 +debug: 0.892 +architecture: 0.882 +assembly: 0.881 +virtual: 0.875 +socket: 0.874 +boot: 0.859 +kernel: 0.852 +risc-v: 0.847 +peripherals: 0.838 +PID: 0.836 +network: 0.834 +hypervisor: 0.834 +vnc: 0.833 +mistranslation: 0.828 +TCG: 0.825 +KVM: 0.823 +files: 0.812 +ppc: 0.802 +VMM: 0.790 +i386: 0.736 +x86: 0.698 + +qemu-system-arm: crashes raspian kernels with divide-by-zero + +While trying to boot a arm kernel for a raspi2 machine (kernel7-4.9.41-stretch.img in my case, but applies to other versions, too) the kernel crash with a division by zero. The output on the sreial console is: +[ 10.022377] [<8011d344>] (__warn) from [<8011d42c>] (warn_slowpath_null+0x30/0x38) +[ 10.024726] [<8011d42c>] (warn_slowpath_null) from [<804da378>] (uart_get_baud_rate+0xf8/0x160) + +... + +[ 10.094933] Hardware name: BCM2835 +[ 10.101507] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24) +[ 10.105413] [<8010c058>] (show_stack) from [<80455f84>] (dump_stack+0xd4/0x118) +[ 10.140268] [<80455f84>] (dump_stack) from [<8010bed4>] (__div0+0x24/0x28) +[ 10.143065] [<8010bed4>] (__div0) from [<8045498c>] (Ldiv0+0x8/0x14) +[ 10.145553] [<8045498c>] (Ldiv0) from [<804e5538>] (pl011_set_termios+0x9c/0x37c) +[ 10.148017] [<804e5538>] (pl011_set_termios) from [<804da954>] (uart_change_speed+0x40/0xfc) +[ 10.185887] [<804da954>] (uart_change_speed) from [<804ddedc>] (uart_startup.part.3+0xa4/0x13c) +[ 10.222187] [<804ddedc>] (uart_startup.part.3) from [<804ddfcc>] (uart_port_activate+0x58/0x64) +[ 10.226014] [<804ddfcc>] (uart_port_activate) from [<804c93b8>] (tty_port_open+0xa0/0xe0) +[ 10.228398] [<804c93b8>] (tty_port_open) from [<804dce64>] (uart_open+0x40/0x48) +[ 10.264254] [<804dce64>] (uart_open) from [<804c1d70>] (tty_open+0xc0/0x678) +[ 10.266697] [<804c1d70>] (tty_open) from [<802753f0>] (chrdev_open+0xe0/0x1a0) +[ 10.269049] [<802753f0>] (chrdev_open) from [<8026d964>] (do_dentry_open+0x1f4/0x314) +[ 10.271620] [<8026d964>] (do_dentry_open) from [<8026ec00>] (vfs_open+0x60/0x8c) +[ 10.275245] [<8026ec00>] (vfs_open) from [<8027f39c>] (path_openat+0x2bc/0x1040) +[ 10.312827] [<8027f39c>] (path_openat) from [<80281040>] (do_filp_open+0x70/0xd4) +[ 10.317860] [<80281040>] (do_filp_open) from [<8026efd8>] (do_sys_open+0x120/0x1d0) +[ 10.320370] [<8026efd8>] (do_sys_open) from [<8026f0b4>] (SyS_open+0x2c/0x30) +[ 10.357033] [<8026f0b4>] (SyS_open) from [<801080c0>] (ret_fast_syscall+0x0/0x1c) + +Tracking that down in the linux kernel source, it looks like somehow uart_get_baud_rate() returns 0. + +The same kernel could be booted without problem with qemu version 2.11. +Trying to bisecting the issue revealed commit @d9f8bbd8eb4e95db97cf02bd03af86a3d606f4f1 as the culprit. + +Commandline to run was: +qemu-system-arm -M raspi2 \ + -kernel "$KERNEL" \ + -m 1024 \ + -d guest_errors,unimp \ + -dtb bcm2709-rpi-2-b.dtb \ + -drive file="$IMG,if=sd,format=raw" + +Distribution is SuSE tumbleweed (x86_64, kernel 4.17.2), but same problem also happens with a freshly compiled qemu from git repository. + +This isn't a kernel crash, it's just a warning (which I think is safely ignorable). The problem is that QEMU doesn't implement the 'cprman' clock control hardware, which means Linux thinks the UART is running at a zero baud rate. Unfortunately the cprman hardware is as far as I can determine undocumented, so it's not really possible to write an emulation of it. + +I'm not sure your bisection has landed on the right thing, as d9f8bbd8eb4e95 should be a no-behaviour-change commit. + + +On Donnerstag, 28. Juni 2018 11:32:08 CEST Peter Maydell wrote: + +Thanks for your quick answer. + +> I'm not sure your bisection has landed on the right thing, as +> d9f8bbd8eb4e95 should be a no-behaviour-change commit. + +Yes, i saw that already. But strangely, the commit before worked (tested +manually after the bisect), and with that commit i get the division by zero. + +The problem is that the kernel stops booting at this point (maybe not because +of the exception, but that is the last message printed) + +>Unfortunately the cprman hardware is as far as I can +>determine undocumented + +Would there be some way to fake it at least, so that linux does not get a zero +baudrate? + + + + + +This does not appear to be DIRECTLY a bug in QEMU, but 'something' has changed in the RPi Kernel to cause this issue. + +The actual cause of the panic is (in my situation) because the kernel is unable to mount root, and this is caused by it being unable to access the SD interface, as it can't get timing. + +This is a random working kernel (using QEMU 3.0) - https://pastebin.com/wvkneNNF + +This is the latest 4.14 kernel (using the identical QEMU) - https://pastebin.com/QTwgCkV2 + +The actual error is on line 160: + +[ 1.706622] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe + +This never actually activates the mmc controller, and the root volume is not available. + + + +Thanks for the followup. Yes, that sounds like the problem is indeed that we don't currently emulate enough of the clock-control in the raspi's SoC. There were a couple of patches on list a while back that were trying to provide at least a basic dummy emulation of that device; I'm not sure what happened to them. + +This should be fixed for the 5.2 release, as we now have a model of the cprman clock control module. + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/permissions/1792 b/results/classifier/118/permissions/1792 new file mode 100644 index 00000000..d723e188 --- /dev/null +++ b/results/classifier/118/permissions/1792 @@ -0,0 +1,111 @@ +permissions: 0.827 +TCG: 0.736 +virtual: 0.706 +architecture: 0.686 +register: 0.684 +debug: 0.680 +network: 0.671 +assembly: 0.662 +socket: 0.654 +files: 0.647 +PID: 0.645 +peripherals: 0.643 +device: 0.636 +boot: 0.631 +KVM: 0.627 +x86: 0.616 +semantic: 0.615 +performance: 0.615 +vnc: 0.612 +arm: 0.608 +user-level: 0.597 +kernel: 0.585 +hypervisor: 0.563 +graphic: 0.560 +VMM: 0.552 +ppc: 0.528 +i386: 0.526 +risc-v: 0.511 +mistranslation: 0.313 + +qemu-8.1-rc1 and rc0 fail build. 8.0 is fine +Description of problem: +Build error with 8.1.0-rc0 and 8.1.0-rc1. +Build of 8.0.3 works correctly, using the same build configuration. +Steps to reproduce: +1. Run configure as below in logs +2.`/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3 -m ensurepip --upgrade --default-pip` +3. +Additional information: +``` +$ s/build qemu:host +CLEAN qemu + * Removing /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc0 ... + * Removing /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/qa_checks/qemu-* ... +UNPACK qemu +BUILD qemu (host) + TOOLCHAIN configure +Executing (host): /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/configure --bindir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/bin --extra-cflags=-I/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/include --extra-ldflags=-L/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib --libexecdir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib --localstatedir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/var --prefix=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain --sbindir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/sbin --sysconfdir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/etc --enable-tools --enable-malloc=system --disable-attr --disable-auth-pam --disable-install-blobs --disable-capstone --disable-curl --disable-debug-info --disable-debug-mutex --disable-debug-tcg --disable-docs --disable-gcrypt --disable-gnutls --disable-system --disable-user --disable-vnc --disable-werror --disable-xkbcommon --disable-zstd +python determined to be '/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/bin/python3' +python version: Python 3.11.4 +mkvenv: Creating non-isolated virtual environment at 'pyvenv' +mkvenv subprocess failed: +cmd: ['/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3', '-m', 'ensurepip', '--upgrade', '--default-pip'] +returncode: 1 +========== stdout ========== +Looking in links: /tmp/tmpio395oka +Processing /tmp/tmpio395oka/setuptools-65.5.0-py3-none-any.whl +Processing /tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl +Installing collected packages: setuptools, pip +ERROR: Exception: +Traceback (most recent call last): + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/cli/base_command.py", line 169, in exc_logging_wrapper + status = run_func(*args) + ^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/cli/req_command.py", line 248, in wrapper + return func(self, options, args) + ^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/commands/install.py", line 449, in run + installed = install_given_reqs( + ^^^^^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/req/__init__.py", line 72, in install_given_reqs + requirement.install( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/req/req_install.py", line 800, in install + install_wheel( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 731, in install_wheel + _install_wheel( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 620, in _install_wheel + assert os.path.exists(pyc_path) +AssertionError +Traceback (most recent call last): + File "<frozen runpy>", line 198, in _run_module_as_main + File "<frozen runpy>", line 88, in _run_code + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__main__.py", line 5, in <module> + sys.exit(ensurepip._main()) + ^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 286, in _main + return _bootstrap( + ^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 202, in _bootstrap + return _run_pip([*args, *_PACKAGE_NAMES], additional_paths) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 103, in _run_pip + return subprocess.run(cmd, check=True).returncode + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/subprocess.py", line 571, in run + raise CalledProcessError(retcode, process.args, +subprocess.CalledProcessError: Command '['/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3', '-W', 'ignore::DeprecationWarning', '-c', '\nimport runpy\nimport sys\nsys.path = [\'/tmp/tmpio395oka/setuptools-65.5.0-py3-none-any.whl\', \'/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl\'] + sys.path\nsys.argv[1:] = [\'install\', \'--no-cache-dir\', \'--no-index\', \'--find-links\', \'/tmp/tmpio395oka\', \'--upgrade\', \'setuptools\', \'pip\']\nrunpy.run_module("pip", run_name="__main__", alter_sys=True)\n']' returned non-zero exit status 2. + +============================ + +*** Ouch! *** + +VENV creation subprocess failed. + + + +ERROR: python venv creation failed + +FAILURE: s/build qemu:host during configure_host (default) + +``` diff --git a/results/classifier/118/permissions/1803872 b/results/classifier/118/permissions/1803872 new file mode 100644 index 00000000..ccd7fef3 --- /dev/null +++ b/results/classifier/118/permissions/1803872 @@ -0,0 +1,1353 @@ +permissions: 0.801 +register: 0.741 +performance: 0.698 +debug: 0.698 +user-level: 0.683 +architecture: 0.665 +hypervisor: 0.631 +arm: 0.622 +virtual: 0.613 +device: 0.603 +semantic: 0.601 +ppc: 0.596 +assembly: 0.588 +PID: 0.587 +risc-v: 0.571 +network: 0.557 +graphic: 0.555 +files: 0.545 +vnc: 0.528 +socket: 0.528 +boot: 0.514 +VMM: 0.508 +peripherals: 0.505 +TCG: 0.494 +kernel: 0.483 +KVM: 0.464 +mistranslation: 0.449 +x86: 0.262 +i386: 0.262 + +gcc 8.2 reports stringop-truncation when building qemu + +QEMU 3.0 + +block/sheepdog.c: In function 'find_vdi_name': +block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] + strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +If this is the intended behavior, please suppress the warning. For example: + +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstringop-truncation" + strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +#pragma GCC diagnostic pop + +On Tue, Dec 18, 2018 at 3:09 PM Philippe Mathieu-Daudé +<email address hidden> wrote: +> +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_store_running': +> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] +> strncpy((char *)global_state.runstate, state, sizeof(global_state.runstate)); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> The runstate name doesn't require the strings to be NUL-terminated, +> therefore strncpy is the right function to use here. +> +> We could add a #pragma GCC diagnostic ignored "-Wstringop-truncation" +> around, disable the warning globally using -Wno-stringop-truncation, +> but since QEMU provides the strpadcpy() which does the same purpose, +> simply use it to avoid the annoying warning. +> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> + +Reviewed-by: Marc-André Lureau <email address hidden> + +> --- +> migration/global_state.c | 4 ++-- +> 1 file changed, 2 insertions(+), 2 deletions(-) +> +> diff --git a/migration/global_state.c b/migration/global_state.c +> index 8e8ab5c51e..c7e7618118 100644 +> --- a/migration/global_state.c +> +++ b/migration/global_state.c +> @@ -42,8 +42,8 @@ int global_state_store(void) +> void global_state_store_running(void) +> { +> const char *state = RunState_str(RUN_STATE_RUNNING); +> - strncpy((char *)global_state.runstate, +> - state, sizeof(global_state.runstate)); +> + strpadcpy((char *)global_state.runstate, +> + sizeof(global_state.runstate), state, '\0'); +> } +> +> bool global_state_received(void) +> -- +> 2.17.2 +> +> + + +-- +Marc-André Lureau + + +On Tue, 18 Dec 2018 12:03:31 +0100 +Philippe Mathieu-Daudé <email address hidden> wrote: + +> From: Marc-André Lureau <email address hidden> +> +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC hw/acpi/core.o +> In function 'acpi_table_install', inlined from 'acpi_table_add' at qemu/hw/acpi/core.c:296:5: +> qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals destination size [-Werror=stringop-truncation] +> strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1 +> +> The ACPI tables don't require the strings to be NUL-terminated, +> therefore strncpy is the right function to use here. +> +> We could add a #pragma GCC diagnostic ignored "-Wstringop-truncation" +> around, disable the warning globally using -Wno-stringop-truncation, +> but since QEMU provides the strpadcpy() which does the same purpose, +> simply use it to avoid the annoying warning. +> +> Signed-off-by: Marc-André Lureau <email address hidden> +> Reviewed-by: Eric Blake <email address hidden> +> Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +> [PMD: reword commit subject and description] +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> + +Reviewed-by: Igor Mammedov <email address hidden> + +> --- +> hw/acpi/aml-build.c | 6 ++++-- +> hw/acpi/core.c | 13 +++++++------ +> 2 files changed, 11 insertions(+), 8 deletions(-) +> +> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c +> index 1e43cd736d..397833462a 100644 +> --- a/hw/acpi/aml-build.c +> +++ b/hw/acpi/aml-build.c +> @@ -24,6 +24,7 @@ +> #include "hw/acpi/aml-build.h" +> #include "qemu/bswap.h" +> #include "qemu/bitops.h" +> +#include "qemu/cutils.h" +> #include "sysemu/numa.h" +> +> static GArray *build_alloc_array(void) +> @@ -1532,13 +1533,14 @@ build_header(BIOSLinker *linker, GArray *table_data, +> h->revision = rev; +> +> if (oem_id) { +> - strncpy((char *)h->oem_id, oem_id, sizeof h->oem_id); +> + strpadcpy((char *)h->oem_id, sizeof h->oem_id, oem_id, '\0'); +> } else { +> memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6); +> } +> +> if (oem_table_id) { +> - strncpy((char *)h->oem_table_id, oem_table_id, sizeof(h->oem_table_id)); +> + strpadcpy((char *)h->oem_table_id, sizeof(h->oem_table_id), +> + oem_table_id, '\0'); +> } else { +> memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4); +> memcpy(h->oem_table_id + 4, sig, 4); +> diff --git a/hw/acpi/core.c b/hw/acpi/core.c +> index aafdc61648..6e8f4e5713 100644 +> --- a/hw/acpi/core.c +> +++ b/hw/acpi/core.c +> @@ -31,6 +31,7 @@ +> #include "qapi/qapi-visit-misc.h" +> #include "qemu/error-report.h" +> #include "qemu/option.h" +> +#include "qemu/cutils.h" +> +> struct acpi_table_header { +> uint16_t _length; /* our length, not actual part of the hdr */ +> @@ -181,7 +182,7 @@ static void acpi_table_install(const char unsigned *blob, size_t bloblen, +> ext_hdr->_length = cpu_to_le16(acpi_payload_size); +> +> if (hdrs->has_sig) { +> - strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> + strpadcpy(ext_hdr->sig, sizeof ext_hdr->sig, hdrs->sig, '\0'); +> ++changed_fields; +> } +> +> @@ -200,12 +201,12 @@ static void acpi_table_install(const char unsigned *blob, size_t bloblen, +> ext_hdr->checksum = 0; +> +> if (hdrs->has_oem_id) { +> - strncpy(ext_hdr->oem_id, hdrs->oem_id, sizeof ext_hdr->oem_id); +> + strpadcpy(ext_hdr->oem_id, sizeof ext_hdr->oem_id, hdrs->oem_id, '\0'); +> ++changed_fields; +> } +> if (hdrs->has_oem_table_id) { +> - strncpy(ext_hdr->oem_table_id, hdrs->oem_table_id, +> - sizeof ext_hdr->oem_table_id); +> + strpadcpy(ext_hdr->oem_table_id, sizeof ext_hdr->oem_table_id, +> + hdrs->oem_table_id, '\0'); +> ++changed_fields; +> } +> if (hdrs->has_oem_rev) { +> @@ -213,8 +214,8 @@ static void acpi_table_install(const char unsigned *blob, size_t bloblen, +> ++changed_fields; +> } +> if (hdrs->has_asl_compiler_id) { +> - strncpy(ext_hdr->asl_compiler_id, hdrs->asl_compiler_id, +> - sizeof ext_hdr->asl_compiler_id); +> + strpadcpy(ext_hdr->asl_compiler_id, sizeof ext_hdr->asl_compiler_id, +> + hdrs->asl_compiler_id, '\0'); +> ++changed_fields; +> } +> if (hdrs->has_asl_compiler_rev) { + + + +On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote: +> GCC 8 new warning prevents builds to success since quite some time. +> First report on the mailing list is in July 2018: +> https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html +> +> Various intents has been sent to fix this: +> - Incorrectly using g_strlcpy() +> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html +> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html +> - Using assert() and strpadcpy() +> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html +> - Use #pragma GCC diagnostic ignored "-Wstringop-truncation" +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - adding an inline wrapper with said pragma in there +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - -Wno-stringop-truncation is the makefile +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> +> This series replace the strncpy() calls by strpadcpy() which seemed +> to me the saniest option. +> +> Regards, +> +> Phil. + +Do you happen to know why does it build fine with +Gcc 8.2.1? + +Reading the GCC manual it seems that +there is a "nostring" attribute that means +"might not be 0 terminated". +I think we should switch to that which fixes the warning +but also warns if someone tries to misuse these +as C-strings. + +Seems to be a better option, does it not? + + +> Marc-André Lureau (1): +> hw/acpi: Replace strncpy() by strpadcpy(pad='\0') +> +> Philippe Mathieu-Daudé (2): +> block/sheepdog: Replace strncpy() by strpadcpy(pad='\0') +> migration: Replace strncpy() by strpadcpy(pad='\0') +> +> block/sheepdog.c | 6 +++--- +> hw/acpi/aml-build.c | 6 ++++-- +> hw/acpi/core.c | 13 +++++++------ +> migration/global_state.c | 4 ++-- +> 4 files changed, 16 insertions(+), 13 deletions(-) +> +> -- +> 2.17.2 + + +On Tue, Dec 18, 2018 at 09:31:00AM -0500, Michael S. Tsirkin wrote: +> On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote: +> > GCC 8 new warning prevents builds to success since quite some time. +> > First report on the mailing list is in July 2018: +> > https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html +> > +> > Various intents has been sent to fix this: +> > - Incorrectly using g_strlcpy() +> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html +> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html +> > - Using assert() and strpadcpy() +> > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html +> > - Use #pragma GCC diagnostic ignored "-Wstringop-truncation" +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > - adding an inline wrapper with said pragma in there +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > - -Wno-stringop-truncation is the makefile +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > +> > This series replace the strncpy() calls by strpadcpy() which seemed +> > to me the saniest option. +> > +> > Regards, +> > +> > Phil. +> +> Do you happen to know why does it build fine with +> Gcc 8.2.1? +> +> Reading the GCC manual it seems that +> there is a "nostring" attribute that means + +typo - its "nonstring" + +> "might not be 0 terminated". +> I think we should switch to that which fixes the warning +> but also warns if someone tries to misuse these +> as C-strings. +> +> Seems to be a better option, does it not? + +Yes, it does look best as gcc manual explicitly suggests "nonstring" +as the way to stop this strncpy warning. + + +Regards, +Daniel +-- +|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +|: https://libvirt.org -o- https://fstop138.berrange.com :| +|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| + + +On Tue, Dec 18, 2018 at 09:31:00AM -0500, Michael S. Tsirkin wrote: +> On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote: +> > GCC 8 new warning prevents builds to success since quite some time. +> > First report on the mailing list is in July 2018: +> > https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html +> > +> > Various intents has been sent to fix this: +> > - Incorrectly using g_strlcpy() +> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html +> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html +> > - Using assert() and strpadcpy() +> > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html +> > - Use #pragma GCC diagnostic ignored "-Wstringop-truncation" +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > - adding an inline wrapper with said pragma in there +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > - -Wno-stringop-truncation is the makefile +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > +> > This series replace the strncpy() calls by strpadcpy() which seemed +> > to me the saniest option. +> > +> > Regards, +> > +> > Phil. +> +> Do you happen to know why does it build fine with +> Gcc 8.2.1? +> +> Reading the GCC manual it seems that +> there is a "nostring" attribute + +Sorry that should be "nonstring". + + +> that means +> "might not be 0 terminated". +> I think we should switch to that which fixes the warning +> but also warns if someone tries to misuse these +> as C-strings. +> +> Seems to be a better option, does it not? +> + +Also maybe we can make strpadcpy check for the nonstring +attribute too somehow? +Or did gcc just hardcode the strncpy name? + +> > Marc-André Lureau (1): +> > hw/acpi: Replace strncpy() by strpadcpy(pad='\0') +> > +> > Philippe Mathieu-Daudé (2): +> > block/sheepdog: Replace strncpy() by strpadcpy(pad='\0') +> > migration: Replace strncpy() by strpadcpy(pad='\0') +> > +> > block/sheepdog.c | 6 +++--- +> > hw/acpi/aml-build.c | 6 ++++-- +> > hw/acpi/core.c | 13 +++++++------ +> > migration/global_state.c | 4 ++-- +> > 4 files changed, 16 insertions(+), 13 deletions(-) +> > +> > -- +> > 2.17.2 + + +On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote: +> On 18/12/18 15:31, Michael S. Tsirkin wrote: +> > Do you happen to know why does it build fine with +> > Gcc 8.2.1? +> > +> > Reading the GCC manual it seems that +> > there is a "nostring" attribute that means +> > "might not be 0 terminated". +> > I think we should switch to that which fixes the warning +> > but also warns if someone tries to misuse these +> > as C-strings. +> > +> > Seems to be a better option, does it not? +> > +> > +> +> Using strpadcpy is clever and self-documenting, though. We have it +> already, so why not use it. +> +> Paolo + +The advantage of nonstring is that it will catch attempts to +use these fields with functions that expect a 0 terminated string. + +strpadcpy will instead just silence the warning. + + +-- +MST + + +On Tue, Dec 18, 2018 at 05:38:17PM +0100, Paolo Bonzini wrote: +> On 18/12/18 15:54, Michael S. Tsirkin wrote: +> > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote: +> >> On 18/12/18 15:31, Michael S. Tsirkin wrote: +> >>> Do you happen to know why does it build fine with +> >>> Gcc 8.2.1? +> >>> +> >>> Reading the GCC manual it seems that +> >>> there is a "nostring" attribute that means +> >>> "might not be 0 terminated". +> >>> I think we should switch to that which fixes the warning +> >>> but also warns if someone tries to misuse these +> >>> as C-strings. +> >>> +> >>> Seems to be a better option, does it not? +> >>> +> >>> +> >> +> >> Using strpadcpy is clever and self-documenting, though. We have it +> >> already, so why not use it. +> >> +> >> Paolo +> > +> > The advantage of nonstring is that it will catch attempts to +> > use these fields with functions that expect a 0 terminated string. +> > +> > strpadcpy will instead just silence the warning. +> +> Ah, I see. We could also do both, that's a matter of taste. +> +> Paolo + +Do you happen to know how to make gcc check the buffer size +for strpadcpy? Is the name strncpy just hard-coded? + +-- +MST + + +On Tue, Dec 18, 2018 at 05:55:27PM +0100, Philippe Mathieu-Daudé wrote: +> On 12/18/18 3:54 PM, Michael S. Tsirkin wrote: +> > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote: +> >> On 18/12/18 15:31, Michael S. Tsirkin wrote: +> >>> Do you happen to know why does it build fine with +> >>> Gcc 8.2.1? +> >>> +> >>> Reading the GCC manual it seems that +> >>> there is a "nostring" attribute that means +> >>> "might not be 0 terminated". +> >>> I think we should switch to that which fixes the warning +> >>> but also warns if someone tries to misuse these +> >>> as C-strings. +> >>> +> >>> Seems to be a better option, does it not? +> >>> +> >>> +> >> +> >> Using strpadcpy is clever and self-documenting, though. We have it +> >> already, so why not use it. +> >> +> >> Paolo +> > +> > The advantage of nonstring is that it will catch attempts to +> > use these fields with functions that expect a 0 terminated string. +> > +> > strpadcpy will instead just silence the warning. +> +> migration/global_state.c:109:15: error: 'strlen' argument 1 declared +> attribute 'nonstring' [-Werror=stringop-overflow=] +> s->size = strlen((char *)s->runstate) + 1; +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +> +> GCC won... It is true this strlen() is buggy, indeed s->runstate might +> be not NUL-terminated. + + +Ooh nice. I smell some CVE fixes coming from this effort. + + +-- +MST + + +On Tue, Dec 18, 2018 at 06:12:05PM +0100, Paolo Bonzini wrote: +> On 18/12/18 17:55, Philippe Mathieu-Daudé wrote: +> >> strpadcpy will instead just silence the warning. +> > migration/global_state.c:109:15: error: 'strlen' argument 1 declared +> > attribute 'nonstring' [-Werror=stringop-overflow=] +> > s->size = strlen((char *)s->runstate) + 1; +> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +> > +> > GCC won... It is true this strlen() is buggy, indeed s->runstate might +> > be not NUL-terminated. +> +> No, runstate is declared as an array of 100 bytes, which are more than +> enough. It's ugly code but not buggy. +> +> Paolo + +Yes ... but it is loaded using + VMSTATE_BUFFER(runstate, GlobalState), +and parsed using qapi_enum_parse which does not get +the buffer length. + +So unless we are lucky there's a buffer overrun +on a remote/file input here. + +Seems buggy to me - what am I missing? + +-- +MST + + +On Tue, Dec 18, 2018 at 12:03:34PM -0500, Michael S. Tsirkin wrote: +> On Tue, Dec 18, 2018 at 05:38:17PM +0100, Paolo Bonzini wrote: +> > On 18/12/18 15:54, Michael S. Tsirkin wrote: +> > > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote: +> > >> On 18/12/18 15:31, Michael S. Tsirkin wrote: +> > >>> Do you happen to know why does it build fine with +> > >>> Gcc 8.2.1? +> > >>> +> > >>> Reading the GCC manual it seems that +> > >>> there is a "nostring" attribute that means +> > >>> "might not be 0 terminated". +> > >>> I think we should switch to that which fixes the warning +> > >>> but also warns if someone tries to misuse these +> > >>> as C-strings. +> > >>> +> > >>> Seems to be a better option, does it not? +> > >>> +> > >>> +> > >> +> > >> Using strpadcpy is clever and self-documenting, though. We have it +> > >> already, so why not use it. +> > >> +> > >> Paolo +> > > +> > > The advantage of nonstring is that it will catch attempts to +> > > use these fields with functions that expect a 0 terminated string. +> > > +> > > strpadcpy will instead just silence the warning. +> > +> > Ah, I see. We could also do both, that's a matter of taste. +> > +> > Paolo +> +> Do you happen to know how to make gcc check the buffer size +> for strpadcpy? Is the name strncpy just hard-coded? + +GCC provides strncpy as a builtin function and its warning only +checks its builtin. + +Regards, +Daniel +-- +|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +|: https://libvirt.org -o- https://fstop138.berrange.com :| +|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 introduced the -Wstringop-truncation checker to detect truncation by +> the strncat and strncpy functions (closely related to -Wstringop-overflow, +> which detect buffer overflow by string-modifying functions declared in +> <string.h>). + +This paragraph talks about a new warning checker, but makes no mention +of an attribute. + +> +> Add the QEMU_NONSTRING macro which checks if the compiler supports this +> attribute. + +Thus, "this attribute" has no antecedent; did you forget to add a +sentence to the previous paragraph, or maybe put the mention of adding +QEMU_NONSTRING after... + +> +>>From the GCC manual [*]: +> +> The nonstring variable attribute specifies that an object or member +> declaration with type array of char, signed char, or unsigned char, +> or pointer to such a type is intended to store character arrays that +> do not necessarily contain a terminating NUL. This is useful in detecting +> uses of such arrays or pointers with functions that expect NUL-terminated +> strings, and to avoid warnings when such an array or pointer is used as +> an argument to a bounded string manipulation function such as strncpy. + +...the explanation of how the attribute was added in tandem with the new +warning checker for silencing specific instances of the warning? + +> +> [*] https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-nonstring-variable-attribute +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> include/qemu/compiler.h | 15 +++++++++++++++ +> 1 file changed, 15 insertions(+) +> + +Reviewed-by: Eric Blake <email address hidden> + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC block/sheepdog.o +> qemu/block/sheepdog.c: In function 'find_vdi_name': +> qemu/block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] +> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: block/sheepdog.o] Error 1 +> +> As described previous to the strncpy() calls, the use of strncpy() is +> correct here: +> +> /* This pair of strncpy calls ensures that the buffer is zero-filled, +> * which is desirable since we'll soon be sending those bytes, and +> * don't want the send_req to read uninitialized data. +> */ +> strncpy(buf, filename, SD_MAX_VDI_LEN); +> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> block/sheepdog.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) + +Reviewed-by: Eric Blake <email address hidden> + +> +> diff --git a/block/sheepdog.c b/block/sheepdog.c +> index 0125df9d49..d4ad6b119d 100644 +> --- a/block/sheepdog.c +> +++ b/block/sheepdog.c +> @@ -1224,7 +1224,7 @@ static int find_vdi_name(BDRVSheepdogState *s, const char *filename, +> SheepdogVdiReq hdr; +> SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr; +> unsigned int wlen, rlen = 0; +> - char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN]; +> + QEMU_NONSTRING char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN]; +> +> fd = connect_to_sdog(s, errp); +> if (fd < 0) { +> + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_store_running': +> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] +> strncpy((char *)global_state.runstate, state, sizeof(global_state.runstate)); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> migration/global_state.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) + +Should this be squashed with 5/5? + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 introduced the -Wstringop-overflow, which detect buffer overflow +> by string-modifying functions declared in <string.h>, such strncpy(), +> used in global_state_store_running(). +> +> Since the global_state.runstate does not necessarily contains a +> terminating NUL character, We had to use the QEMU_NONSTRING attribute. + +s/We/we/ + +> +> The GCC manual says about the nonstring attribute: +> +> However, when the array is declared with the attribute the call to +> strlen is diagnosed because when the array doesn’t contain a +> NUL-terminated string the call is undefined. [...] +> In addition, calling strnlen and strndup with such arrays is safe +> provided a suitable bound is specified, and not diagnosed. +> +> GCC indeed found an incorrect use of strlen(), because this array +> is loaded by VMSTATE_BUFFER(runstate, GlobalState) then parsed +> using qapi_enum_parse which does not get the buffer length. +> +> Use strnlen() which returns sizeof(s->runstate) if the array is not +> NUL-terminated. +> +> This fixes: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_pre_save': +> qemu/migration/global_state.c:109:15: error: 'strlen' argument 1 declared attribute 'nonstring' [-Werror=stringop-overflow=] +> s->size = strlen((char *)s->runstate) + 1; +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +> qemu/migration/global_state.c:24:13: note: argument 'runstate' declared here +> uint8_t runstate[100] QEMU_NONSTRING; +> ^~~~~~~~ +> cc1: all warnings being treated as errors +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> migration/global_state.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/migration/global_state.c b/migration/global_state.c +> index 6e19333422..c19030ef62 100644 +> --- a/migration/global_state.c +> +++ b/migration/global_state.c +> @@ -106,7 +106,7 @@ static int global_state_pre_save(void *opaque) +> GlobalState *s = opaque; +> +> trace_migrate_global_state_pre_save((char *)s->runstate); +> - s->size = strlen((char *)s->runstate) + 1; + +The old code sets s->size to the string length + space for the NUL byte +(by assuming that a NUL byte was present), and accidentally sets it +beyond the s->runstate array if there was no NUL byte (our existing +runstate names are shorter than 100 bytes, so this could only happen on +a malicious stream). + +> + s->size = strnlen((char *)s->runstate, sizeof(s->runstate)) + 1; + +The new code can still end up setting s->size beyond the array. Is that +intended, or would it be better to use strnlen(s->runstate, +sizeof(s->runstate) - 1) + 1? + +Also, as I argued on 4/5, why isn't this squashed in with the patch that +marks the field NONSTRING? + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_store_running': +> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] +> strncpy((char *)global_state.runstate, state, sizeof(global_state.runstate)); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. + +> typedef struct { +> uint32_t size; +> - uint8_t runstate[100]; +> + uint8_t runstate[100] QEMU_NONSTRING; + +Since 100 bytes for runstate[] is larger than any string possible in our +current enum string values, could we instead add an assert that +strlen(state) < sizeof(global_state.runstate), and then use strpadcpy() +to make our intent obvious while still shutting up the compiler warning, +but without having to deal with the fallout of marking runstate as a +non-string? + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On Tue, Dec 18, 2018 at 06:51:17PM +0100, Philippe Mathieu-Daudé wrote: +> GCC 8 new warning prevents builds to success since quite some time. +> First report on the mailing list is in July 2018: +> https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html +> +> Various intents has been sent to fix this: +> - Incorrectly using g_strlcpy() +> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html +> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html +> - Using assert() and strpadcpy() +> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html +> - Use #pragma GCC diagnostic ignored "-Wstringop-truncation" +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - adding an inline wrapper with said pragma in there +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - -Wno-stringop-truncation is the makefile +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - Use the 'nonstring' attribute +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04493.html +> +> This series add the QEMU_NONSTRING definition and use it. +> +> Regards, +> +> Phil. + + +Reviewed-by: Michael S. Tsirkin <email address hidden> + +> Philippe Mathieu-Daudé (5): +> qemu/compiler: Define QEMU_NONSTRING +> block/sheepdog: Use QEMU_NONSTRING for non NUL-terminated arrays +> hw/acpi: Use QEMU_NONSTRING for non NUL-terminated arrays +> migration: Use QEMU_NONSTRING for non NUL-terminated arrays +> migration: Use strnlen() for fixed-size string +> +> block/sheepdog.c | 2 +- +> hw/acpi/core.c | 8 ++++---- +> include/hw/acpi/acpi-defs.h | 8 ++++---- +> include/qemu/compiler.h | 15 +++++++++++++++ +> migration/global_state.c | 4 ++-- +> 5 files changed, 26 insertions(+), 11 deletions(-) +> +> -- +> 2.17.2 + + +On Tue, Dec 18, 2018 at 06:51:19PM +0100, Philippe Mathieu-Daudé wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC block/sheepdog.o +> qemu/block/sheepdog.c: In function 'find_vdi_name': +> qemu/block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] +> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: block/sheepdog.o] Error 1 +> +> As described previous to the strncpy() calls, the use of strncpy() is +> correct here: +> +> /* This pair of strncpy calls ensures that the buffer is zero-filled, +> * which is desirable since we'll soon be sending those bytes, and +> * don't want the send_req to read uninitialized data. +> */ +> strncpy(buf, filename, SD_MAX_VDI_LEN); +> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> block/sheepdog.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/block/sheepdog.c b/block/sheepdog.c +> index 0125df9d49..d4ad6b119d 100644 +> --- a/block/sheepdog.c +> +++ b/block/sheepdog.c +> @@ -1224,7 +1224,7 @@ static int find_vdi_name(BDRVSheepdogState *s, const char *filename, +> SheepdogVdiReq hdr; +> SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr; +> unsigned int wlen, rlen = 0; +> - char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN]; +> + QEMU_NONSTRING char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN]; + +In case you decide to respin anyway - this would be +a bit nicer as: + char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN] QEMU_NONSTRING + + + + +> fd = connect_to_sdog(s, errp); +> if (fd < 0) { +> -- +> 2.17.2 + + +On Tue, Dec 18, 2018 at 06:51:22PM +0100, Philippe Mathieu-Daudé wrote: +> GCC 8 introduced the -Wstringop-overflow, which detect buffer overflow +> by string-modifying functions declared in <string.h>, such strncpy(), +> used in global_state_store_running(). +> +> Since the global_state.runstate does not necessarily contains a +> terminating NUL character, We had to use the QEMU_NONSTRING attribute. +> +> The GCC manual says about the nonstring attribute: +> +> However, when the array is declared with the attribute the call to +> strlen is diagnosed because when the array doesn’t contain a +> NUL-terminated string the call is undefined. [...] +> In addition, calling strnlen and strndup with such arrays is safe +> provided a suitable bound is specified, and not diagnosed. +> +> GCC indeed found an incorrect use of strlen(), because this array +> is loaded by VMSTATE_BUFFER(runstate, GlobalState) then parsed +> using qapi_enum_parse which does not get the buffer length. +> +> Use strnlen() which returns sizeof(s->runstate) if the array is not +> NUL-terminated. +> +> This fixes: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_pre_save': +> qemu/migration/global_state.c:109:15: error: 'strlen' argument 1 declared attribute 'nonstring' [-Werror=stringop-overflow=] +> s->size = strlen((char *)s->runstate) + 1; +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +> qemu/migration/global_state.c:24:13: note: argument 'runstate' declared here +> uint8_t runstate[100] QEMU_NONSTRING; +> ^~~~~~~~ +> cc1: all warnings being treated as errors +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> migration/global_state.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/migration/global_state.c b/migration/global_state.c +> index 6e19333422..c19030ef62 100644 +> --- a/migration/global_state.c +> +++ b/migration/global_state.c +> @@ -106,7 +106,7 @@ static int global_state_pre_save(void *opaque) +> GlobalState *s = opaque; +> +> trace_migrate_global_state_pre_save((char *)s->runstate); +> - s->size = strlen((char *)s->runstate) + 1; +> + s->size = strnlen((char *)s->runstate, sizeof(s->runstate)) + 1; +> +> return 0; + +I don't think this works correctly if strnlen returns +sizeof(s->runstate). Which never happens so we probably should +jus add + + assert(e->size is <= sizeof(s->runstate)); + +But also I think this is not enough, there's a problem in post-load +in the call to qapi_enum_parse. You probably want to force +the last character to 0 there. + + +> } +> -- +> 2.17.2 + + +On Tue, 18 Dec 2018 18:51:20 +0100 +Philippe Mathieu-Daudé <email address hidden> wrote: + +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC hw/acpi/core.o +> In function 'acpi_table_install', inlined from 'acpi_table_add' at qemu/hw/acpi/core.c:296:5: +> qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals destination size [-Werror=stringop-truncation] +> strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1 +> +> Use the QEMU_NONSTRING attribute, since ACPI tables don't require the +> strings to be NUL-terminated. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> hw/acpi/core.c | 8 ++++---- +> include/hw/acpi/acpi-defs.h | 8 ++++---- +> 2 files changed, 8 insertions(+), 8 deletions(-) +> +> diff --git a/hw/acpi/core.c b/hw/acpi/core.c +> index aafdc61648..f60f750c3d 100644 +> --- a/hw/acpi/core.c +> +++ b/hw/acpi/core.c +> @@ -35,14 +35,14 @@ +> struct acpi_table_header { +> uint16_t _length; /* our length, not actual part of the hdr */ +> /* allows easier parsing for fw_cfg clients */ +> - char sig[4]; /* ACPI signature (4 ASCII characters) */ +> + char sig[4] QEMU_NONSTRING; /* ACPI signature (4 ASCII characters) */ +> uint32_t length; /* Length of table, in bytes, including header */ +> uint8_t revision; /* ACPI Specification minor version # */ +> uint8_t checksum; /* To make sum of entire table == 0 */ +> - char oem_id[6]; /* OEM identification */ +> - char oem_table_id[8]; /* OEM table identification */ +> + char oem_id[6] QEMU_NONSTRING; /* OEM identification */ +> + char oem_table_id[8] QEMU_NONSTRING; /* OEM table identification */ +> uint32_t oem_revision; /* OEM revision number */ +> - char asl_compiler_id[4]; /* ASL compiler vendor ID */ +> + char asl_compiler_id[4] QEMU_NONSTRING; /* ASL compiler vendor ID */ +> uint32_t asl_compiler_revision; /* ASL compiler revision number */ +> } QEMU_PACKED; +> +> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h +> index af8e023968..3bf0bec8ba 100644 +> --- a/include/hw/acpi/acpi-defs.h +> +++ b/include/hw/acpi/acpi-defs.h +> @@ -43,7 +43,7 @@ enum { +> struct AcpiRsdpDescriptor { /* Root System Descriptor Pointer */ +> uint64_t signature; /* ACPI signature, contains "RSD PTR " */ +> uint8_t checksum; /* To make sum of struct == 0 */ +> - uint8_t oem_id [6]; /* OEM identification */ +> + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */ +> uint8_t revision; /* Must be 0 for 1.0, 2 for 2.0 */ +> uint32_t rsdt_physical_address; /* 32-bit physical address of RSDT */ +> uint32_t length; /* XSDT Length in bytes including hdr */ + +you'll need to rebase this on top the latest Michael's pull request. +[PULL v2 25/30] hw: arm: Carry RSDP specific data through AcpiRsdpData +[PULL v2 29/30] hw: acpi: Remove AcpiRsdpDescriptor and fix tests + +> @@ -62,10 +62,10 @@ typedef struct AcpiRsdpDescriptor AcpiRsdpDescriptor; +> uint32_t length; /* Length of table, in bytes, including header */ \ +> uint8_t revision; /* ACPI Specification minor version # */ \ +> uint8_t checksum; /* To make sum of entire table == 0 */ \ +> - uint8_t oem_id [6]; /* OEM identification */ \ +> - uint8_t oem_table_id [8]; /* OEM table identification */ \ +> + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */ \ +> + uint8_t oem_table_id [8] QEMU_NONSTRING; /* OEM table identification */ \ +> uint32_t oem_revision; /* OEM revision number */ \ +> - uint8_t asl_compiler_id [4]; /* ASL compiler vendor ID */ \ +> + uint8_t asl_compiler_id [4] QEMU_NONSTRING; /* ASL compiler vendor ID */ \ +> uint32_t asl_compiler_revision; /* ASL compiler revision number */ +> +> + + + +On Wed, 19 Dec 2018 10:20:36 +0100 +Philippe Mathieu-Daudé <email address hidden> wrote: + +> Le mer. 19 déc. 2018 10:16, Igor Mammedov <email address hidden> a écrit : +> +> > On Tue, 18 Dec 2018 18:51:20 +0100 +> > Philippe Mathieu-Daudé <email address hidden> wrote: +> > +> > > GCC 8 added a -Wstringop-truncation warning: +> > > +> > > The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> > > bug 81117 is specifically intended to highlight likely unintended +> > > uses of the strncpy function that truncate the terminating NUL +> > > character from the source string. +> > > +> > > This new warning leads to compilation failures: +> > > +> > > CC hw/acpi/core.o +> > > In function 'acpi_table_install', inlined from 'acpi_table_add' at +> > qemu/hw/acpi/core.c:296:5: +> > > qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals +> > destination size [-Werror=stringop-truncation] +> > > strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> > > make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1 +> > > +> > > Use the QEMU_NONSTRING attribute, since ACPI tables don't require the +> > > strings to be NUL-terminated. +> > > +> > > Suggested-by: Michael S. Tsirkin <email address hidden> +> > > Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> > > --- +> > > hw/acpi/core.c | 8 ++++---- +> > > include/hw/acpi/acpi-defs.h | 8 ++++---- +> > > 2 files changed, 8 insertions(+), 8 deletions(-) +> > > +> > > diff --git a/hw/acpi/core.c b/hw/acpi/core.c +> > > index aafdc61648..f60f750c3d 100644 +> > > --- a/hw/acpi/core.c +> > > +++ b/hw/acpi/core.c +> > > @@ -35,14 +35,14 @@ +> > > struct acpi_table_header { +> > > uint16_t _length; /* our length, not actual part of the hdr +> > */ +> > > /* allows easier parsing for fw_cfg +> > clients */ +> > > - char sig[4]; /* ACPI signature (4 ASCII characters) */ +> > > + char sig[4] QEMU_NONSTRING; /* ACPI signature (4 ASCII characters) +> > */ +> > > uint32_t length; /* Length of table, in bytes, including +> > header */ +> > > uint8_t revision; /* ACPI Specification minor version # */ +> > > uint8_t checksum; /* To make sum of entire table == 0 */ +> > > - char oem_id[6]; /* OEM identification */ +> > > - char oem_table_id[8]; /* OEM table identification */ +> > > + char oem_id[6] QEMU_NONSTRING; /* OEM identification */ +> > > + char oem_table_id[8] QEMU_NONSTRING; /* OEM table identification */ +> > > uint32_t oem_revision; /* OEM revision number */ +> > > - char asl_compiler_id[4]; /* ASL compiler vendor ID */ +> > > + char asl_compiler_id[4] QEMU_NONSTRING; /* ASL compiler vendor ID */ +> > > uint32_t asl_compiler_revision; /* ASL compiler revision number */ +> > > } QEMU_PACKED; +> > > +> > > diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h +> > > index af8e023968..3bf0bec8ba 100644 +> > > --- a/include/hw/acpi/acpi-defs.h +> > > +++ b/include/hw/acpi/acpi-defs.h +> > > @@ -43,7 +43,7 @@ enum { +> > > struct AcpiRsdpDescriptor { /* Root System Descriptor Pointer */ +> > > uint64_t signature; /* ACPI signature, contains "RSD +> > PTR " */ +> > > uint8_t checksum; /* To make sum of struct == 0 */ +> > > - uint8_t oem_id [6]; /* OEM identification */ +> > > + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */ +> > > uint8_t revision; /* Must be 0 for 1.0, 2 for 2.0 */ +> > > uint32_t rsdt_physical_address; /* 32-bit physical address of RSDT +> > */ +> > > uint32_t length; /* XSDT Length in bytes including +> > hdr */ +> > +> > you'll need to rebase this on top the latest Michael's pull request. +> > [PULL v2 25/30] hw: arm: Carry RSDP specific data through AcpiRsdpData +> > [PULL v2 29/30] hw: acpi: Remove AcpiRsdpDescriptor and fix tests +> > +> +> OK. Can I add your Ack-by then? +pls note that new AcpiRsdpData has oem_id field that needs the same treatment + +with rebase +Reviewed-by: Igor Mammedov <email address hidden> + +> +> > @@ -62,10 +62,10 @@ typedef struct AcpiRsdpDescriptor AcpiRsdpDescriptor; +> > > uint32_t length; /* Length of table, in bytes, +> > including header */ \ +> > > uint8_t revision; /* ACPI Specification minor +> > version # */ \ +> > > uint8_t checksum; /* To make sum of entire table == +> > 0 */ \ +> > > - uint8_t oem_id [6]; /* OEM identification */ \ +> > > - uint8_t oem_table_id [8]; /* OEM table identification */ \ +> > > + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */ \ +> > > + uint8_t oem_table_id [8] QEMU_NONSTRING; /* OEM table +> > identification */ \ +> > > uint32_t oem_revision; /* OEM revision number */ \ +> > > - uint8_t asl_compiler_id [4]; /* ASL compiler vendor ID */ \ +> > > + uint8_t asl_compiler_id [4] QEMU_NONSTRING; /* ASL compiler vendor +> > ID */ \ +> > > uint32_t asl_compiler_revision; /* ASL compiler revision number */ +> > > +> > > +> > +> > + + + +On Wed, 19 Dec 2018 14:00:37 +0100 +Andrew Jones <email address hidden> wrote: + +> On Wed, Dec 19, 2018 at 01:43:40PM +0100, Philippe Mathieu-Daudé wrote: +> > Hi Drew, +> > +> > On 12/19/18 11:10 AM, Andrew Jones wrote: +> > > On Tue, Dec 18, 2018 at 06:51:20PM +0100, Philippe Mathieu-Daudé wrote: +> > >> GCC 8 added a -Wstringop-truncation warning: +> > >> +> > >> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> > >> bug 81117 is specifically intended to highlight likely unintended +> > >> uses of the strncpy function that truncate the terminating NUL +> > >> character from the source string. +> > >> +> > >> This new warning leads to compilation failures: +> > >> +> > >> CC hw/acpi/core.o +> > >> In function 'acpi_table_install', inlined from 'acpi_table_add' at qemu/hw/acpi/core.c:296:5: +> > >> qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals destination size [-Werror=stringop-truncation] +> > >> strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> > >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> > >> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1 +> > >> +> > >> Use the QEMU_NONSTRING attribute, since ACPI tables don't require the +> > >> strings to be NUL-terminated. +> > > +> > > Aren't we always starting with zero-initialized structures in ACPI code? +> > > If so, then we should be able to change the strncpy's to memcpy's. +> > +> > The first call zero-initializes, but then we call realloc(): +> > +> > /* We won't fail from here on. Initialize / extend the globals. */ +> > if (acpi_tables == NULL) { +> > acpi_tables_len = sizeof(uint16_t); +> > acpi_tables = g_malloc0(acpi_tables_len); +> > } +> > +> > acpi_tables = g_realloc(acpi_tables, acpi_tables_len + +> > ACPI_TABLE_PFX_SIZE + +> > sizeof dfl_hdr + body_size); +> > +> > ext_hdr = (struct acpi_table_header *)(acpi_tables + +> > acpi_tables_len); +> > +> > So memcpy() isn't enough. +> +> Ah, thanks. +> +> > +> > I can resend the previous patch which uses strpadcpy() if you prefer, +> > Igor already reviewed it: +> > +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04406.html +> > +> +> I do like strpadcpy() better, but I'm not going to lose sleep about +> this either way it goes. +I'm ok with both ways, but v2 consensus was to use QEMU_NONSTRING if I got it right + +> +> Thanks, +> drew + + + +* Philippe Mathieu-Daudé (<email address hidden>) wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_store_running': +> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] +> strncpy((char *)global_state.runstate, state, sizeof(global_state.runstate)); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> migration/global_state.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/migration/global_state.c b/migration/global_state.c +> index 8e8ab5c51e..6e19333422 100644 +> --- a/migration/global_state.c +> +++ b/migration/global_state.c +> @@ -21,7 +21,7 @@ +> +> typedef struct { +> uint32_t size; +> - uint8_t runstate[100]; +> + uint8_t runstate[100] QEMU_NONSTRING; + +Hmm; global_state_post_load needs to be fixed for this; it +uses s->runsate and ends up passing it to both a trace +and a qapi_enum_parse - so it's really treating it as a string. +That code is unsafe anyway since it's assuming the received +runstate would be terminated. + +Dave + +> RunState state; +> bool received; +> } GlobalState; +> -- +> 2.17.2 +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +We think we've fixed all the GCC 8.2 stringop-truncation warnings now, so current QEMU git master and the 4.0 rc1 we've just tagged should both build cleanly. Please reopen the bug if we missed one somehow. + + diff --git a/results/classifier/118/permissions/1805913 b/results/classifier/118/permissions/1805913 new file mode 100644 index 00000000..5622556c --- /dev/null +++ b/results/classifier/118/permissions/1805913 @@ -0,0 +1,171 @@ +permissions: 0.830 +semantic: 0.829 +assembly: 0.794 +network: 0.791 +virtual: 0.790 +user-level: 0.771 +peripherals: 0.771 +hypervisor: 0.741 +VMM: 0.735 +graphic: 0.729 +register: 0.726 +device: 0.725 +TCG: 0.711 +risc-v: 0.709 +socket: 0.709 +architecture: 0.705 +performance: 0.703 +arm: 0.694 +ppc: 0.683 +boot: 0.680 +PID: 0.674 +mistranslation: 0.664 +vnc: 0.650 +debug: 0.634 +files: 0.618 +KVM: 0.589 +kernel: 0.580 +x86: 0.295 +i386: 0.270 + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host + +This can be simply reproduced by compiling and running the attached C code (readdir-bug.c) under 32-bit user-static qemu, such as qemu-arm-static: + +# Setup docker for user-static binfmt +docker run --rm --privileged multiarch/qemu-user-static:register --reset +# Compile the code and run (readdir for / is fine, so create a new directory /test). +docker run -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static -v /path/to/readdir-bug.c:/tmp/readdir-bug.c -it --rm arm32v7/ubuntu:18.10 bash -c '{ apt update && apt install -y gcc; } >&/dev/null && mkdir -p /test && cd /test && gcc /tmp/readdir-bug.c && ./a.out' +dir=0xff5b4150 +readdir(dir)=(nil) +errno=75: Value too large for defined data type + +Do remember to replace the /path/to/qemu-arm-static and /path/to/readdir-bug.c to the actual paths of the files. + +The root cause is in glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getdents.c;h=6d09a5be7057e2792be9150d3a2c7b293cf6fc34;hb=a5275ba5378c9256d18e582572b4315e8edfcbfb#l87 + +By C standard, the return type of readdir() is DIR*, in which the inode number and offset are 32-bit integers, therefore, glibc calls getdents64() and check if the inode number and offset fits the 32-bit range, and reports EOVERFLOW if not. + +The problem here is for 32-bit user-static qemu running on 64-bit host, getdents64 simply passing through the inode number and offset from underlying getdents64 syscall (from 64-bit kernel), which is very likely to not fit into 32-bit range. On real hardware, the 32-bit kernel creates 32-bit inode numbers, therefore works properly. + +The glibc code makes sense to do the check to be conformant with C standard, therefore ideally it should be a fix on qemu side. I admit this is difficult because qemu has to maintain a mapping between underlying 64-bit inode numbers and 32-bit inode numbers, which would severely hurt the performance. I don't expect this could be fix anytime soon (or even there would be a fix), but it would be worthwhile to surface this issue. + + + +More notes: this bug hits glibc-2.28 and later. It works on glibc-2.27. Therefore to reproduce it it needs ubuntu 18.10 or later. Seems like it works for 18.04. + +This bug affects all Java programs that (implicitly) uses File.list() or File.listFiles(). Also it makes dash not expanding wildcard /some/directory/* . However, bash works because it uses glob() instead of readdir(). + + +The bug also affects shared-mime-info. update-mime-database uses readdir and ends up generating an empty database without reporting any errors, causing pixbuf and anything else that relies on the mime database not to work properly. + +Same things happens with update-ca-certificates. It calls c_rehash through openssl, which ends up doing nothing. As a result, curl with https and probably anything else that uses SSL fails to work. + +This probably makes the issue fairly critical for tools that create 32bit environments through qemu-debootstrap or build packages in said environment. + +I was also hit by this on Gentoo with a 64bit host running 32bit static chroot (arm). If it matters at all, I saw it after upgrading the 32bit arm chroot to glibc-2.28, while the host was still on 2.27. + +Downgrading again hides the issue. Upgrading the host to glibc 2.28, but keeping the chroot at 2.27 seems to not hit it either. + +https://lkml.org/lkml/2018/12/27/155 + +After studying linux-user/syscall.c a bit, would it be possible to work around this issue by doing something like the following: + +Add a new #define EMULATE_GETDENTS64_WITH_GETDENTS, and enable this iff we have getdents, and the target is 32, while the host is 64 bits. Something similar, but complementary is done with EMULATE_GETDENTS_WITH_GETDENTS64. + +In that case, when userspace calls getdents64, we implement a "conversion" (similar to getdents #if logic), which calls the host's getdents and converts the data structures back to their 64-bit variants before handing back to user-space. + +I'm likely over-simplifying a problem that I don't fully understand, but would happily work on a patch if someone higher up the food chain could fill in the gaps. + +Unfortunately there is no kernel API which we can use on the host to say "give me inodes and offsets which will fit into a 32 bit field". The 'getdents' syscall uses the "unsigned long" type for the d_ino and d_off fields, so on a 64-bit host these will be the same size as the ino64_t and off64_t used by 'getdents64', and you will still have the "trying to fit a quart into a pint pot" problem. + +The only way to fix this is to fix the host kernel to provide the API QEMU needs for this (see discussion in the kernel thread linked to in comment #5). + + +Is there a workaround for this? I tried: + +- Building on an XFS partition. +- Building from ubuntu:16.04 so the host has glib <2.27. + +It looks like the only way is to have the chroot with glib <2.27, and in alpine images glib is at minimum 2.56. + +If the bug is fixed in glib maybe I can install glib from master? I'm trying to build multi-arch docker images and this bug is what prevents me from providing arm/v7 images for the raspberry pi. + +Sorry, meant `< 2.28` above. + +There has been some motion on this by Aladjev Andrew. I will butcher the explanation of his approach if I try, but it is described in the following bugs. I have no idea of the schedule, or even possibility of adoption; it seems to still be in proof-of-concept phase. + +GLIBC bug (see last several posts) +https://sourceware.org/bugzilla/show_bug.cgi?id=23960 + +Kernel bugzilla (last two posts) +https://bugzilla.kernel.org/show_bug.cgi?id=205957 + +Ah, great thanks. It looks like there are patches that fix qemu, although the setup looks a bit complex. I'll report if I get something going. + +This problem affected my virtual environment which I used (via qemu-static) to build my project for RaspberryPI platform. After I upgraded my virtual Raspbian to buster release `readdir` stopped working (as described in this thread) due to mapping of 64 inode numbers to qemu 32bit ARM land. I needed this builder working and I found a workaround in some obscure (2nd page of google result) blog. + +Before the work around my virtual Raspbian was just a directory on one of my ext4 partitions. To fix the issue I created image file with dd, formatted with mkfs.ext4 it with `dir_index` option disabled and moved my virual Raspbian onto that newly created filesystem. This fixed the issue for me and my builder started again. + +I am posting it here so `dir_index` trick can be easier to found for others in this situation. + + +Thanks Marcin. I tested your solution but by me it still gets stuck at the same point. Here's what I did: + +$ tune2fs -O ^dir_index /dev/sda1 +$ tune2fs -l /dev/sda1 +tune2fs 1.44.2 (14-May-2018) +Filesystem volume name: <none> +Last mounted on: / +Filesystem UUID: c8fee0cb-a610-4fa5-aab8-c5c765678133 +Filesystem magic number: 0xEF53 +Filesystem revision #: 1 (dynamic) +Filesystem features: has_journal ext_attr resize_inode filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum +Filesystem flags: signed_directory_hash +Default mount options: user_xattr acl +Filesystem state: clean +(snip) + +But then my build still get stuck on: + +clock_gettime(CLOCK_REALTIME, {tv_sec=1580996038, tv_nsec=781126598}) = 0 +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 144 +tgkill(29974, 29977, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_REALTIME, {tv_sec=1580996038, tv_nsec=781461434}) = 0 +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 144 +tgkill(29974, 29977, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable + + + +I seem to have found another workaround. Knowing now what causes this my guess was: If I make the qemu-arm-static on the host a 32 bit binary and get "multilib" running to make my 64 bit Linux installation run this, then in theory this incompatibility should not happen. If it would, then 32 bit x86 applications whould run into the same problem. + +And at least according to my tries, I did so far, this seems to be the case. I was able to reproduce this with svn (no checkout possible from 32 bit armv7h). If the qemu-arm-static binary is a 32 bit x86 application, then SVN checkouts work well now. + +So until there is a better solution it seems to be a good idea to make the emulation layer run through multilib for 32 bit target architectures, so the host kernel can switch to its 32 bit backwards compatibility mode. + +Yes, using a 32-bit host QEMU process will also work. You might run into a few guest programs that don't work with that -- a 64-bit QEMU process allows us to give the guest the full address space it might need, while a 32-bit QEMU process means that QEMU itself must share with the guest, so if the guest uses a lot of virtual memory or is picky about where it maps things then it might fail to mmap() things where it wants them. But it's probably overall the least-bad workaround at the current time. + + +After reading through the discussion on the mailing list, as it's all about ext4, I got curious... +I'm testing with qemu-user-static and regulary build arm images in a tmpfs. This show similar behaviour and readdir() fails. However, running in the same root copied onto a btrfs, it seems fine. +Maybe this is an even less bad workaround for some folks? + +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 still a bug, and still blocked on the kernel providing APIs to QEMU to request 32-bit directory entries. Linus Walleij proposed a kernel patch to add a suitable fcntl flag but as far as I'm aware it didn't get in so far: + https://<email address hidden>/ + + + +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/263 + + diff --git a/results/classifier/118/permissions/1806243 b/results/classifier/118/permissions/1806243 new file mode 100644 index 00000000..44f026b2 --- /dev/null +++ b/results/classifier/118/permissions/1806243 @@ -0,0 +1,168 @@ +permissions: 0.935 +debug: 0.930 +peripherals: 0.917 +hypervisor: 0.912 +arm: 0.912 +device: 0.907 +graphic: 0.905 +semantic: 0.893 +architecture: 0.886 +performance: 0.882 +x86: 0.878 +network: 0.862 +user-level: 0.844 +boot: 0.844 +PID: 0.842 +assembly: 0.836 +files: 0.823 +VMM: 0.815 +ppc: 0.797 +kernel: 0.795 +virtual: 0.792 +risc-v: 0.787 +register: 0.775 +mistranslation: 0.775 +TCG: 0.774 +vnc: 0.750 +socket: 0.740 +KVM: 0.705 +i386: 0.692 + +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/118/permissions/1809075 b/results/classifier/118/permissions/1809075 new file mode 100644 index 00000000..25a11818 --- /dev/null +++ b/results/classifier/118/permissions/1809075 @@ -0,0 +1,111 @@ +permissions: 0.940 +semantic: 0.912 +debug: 0.899 +architecture: 0.899 +graphic: 0.899 +assembly: 0.879 +device: 0.878 +kernel: 0.869 +files: 0.868 +risc-v: 0.860 +arm: 0.857 +mistranslation: 0.842 +peripherals: 0.826 +network: 0.822 +register: 0.813 +performance: 0.813 +PID: 0.804 +KVM: 0.793 +vnc: 0.790 +TCG: 0.773 +x86: 0.753 +user-level: 0.748 +virtual: 0.698 +hypervisor: 0.696 +ppc: 0.696 +VMM: 0.685 +i386: 0.675 +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/118/permissions/1810603 b/results/classifier/118/permissions/1810603 new file mode 100644 index 00000000..63becdc6 --- /dev/null +++ b/results/classifier/118/permissions/1810603 @@ -0,0 +1,304 @@ +permissions: 0.834 +graphic: 0.820 +performance: 0.812 +architecture: 0.795 +KVM: 0.777 +peripherals: 0.766 +hypervisor: 0.758 +risc-v: 0.741 +socket: 0.729 +register: 0.729 +VMM: 0.724 +ppc: 0.709 +assembly: 0.701 +vnc: 0.699 +user-level: 0.696 +TCG: 0.695 +virtual: 0.692 +device: 0.686 +mistranslation: 0.678 +x86: 0.671 +PID: 0.644 +debug: 0.642 +semantic: 0.629 +arm: 0.626 +boot: 0.566 +i386: 0.549 +files: 0.545 +kernel: 0.541 +network: 0.516 + +QEMU QCow Images grow dramatically + +I've recently migrated our VM infrastructure (~200 guest on 15 hosts) from vbox to Qemu (using KVM / libvirt). We have a master image (QEMU QCow v3) from which we spawn multiple instances (linked clones). All guests are being revert once per hour for security reasons. + +About 2 weeks after we successfully migrated to Qemu, we noticed that almost all disks went full across all 15 hosts. Our investigation showed that the initial qcow disk images blow up from a few gigabytes to 100GB and more. This should not happen, as we revert all VMs back to the initial snapshot once per hour and hence all changes that have been made to disks must be reverted too. + +We did an addition test with 24 hour time frame with which we could reproduce this bug as documented below. + +Initial disk image size (created on Jan 04): +-rw-r--r-- 1 root root 7.1G Jan 4 15:59 W10-TS01-0.img +-rw-r--r-- 1 root root 7.3G Jan 4 15:59 W10-TS02-0.img +-rw-r--r-- 1 root root 7.4G Jan 4 15:59 W10-TS03-0.img +-rw-r--r-- 1 root root 8.3G Jan 4 16:02 W10-CLIENT01-0.img +-rw-r--r-- 1 root root 8.6G Jan 4 16:05 W10-CLIENT02-0.img +-rw-r--r-- 1 root root 8.0G Jan 4 16:05 W10-CLIENT03-0.img +-rw-r--r-- 1 root root 8.3G Jan 4 16:08 W10-CLIENT04-0.img +-rw-r--r-- 1 root root 8.1G Jan 4 16:12 W10-CLIENT05-0.img +-rw-r--r-- 1 root root 8.0G Jan 4 16:12 W10-CLIENT06-0.img +-rw-r--r-- 1 root root 8.1G Jan 4 16:16 W10-CLIENT07-0.img +-rw-r--r-- 1 root root 7.6G Jan 4 16:16 W10-CLIENT08-0.img +-rw-r--r-- 1 root root 7.6G Jan 4 16:19 W10-CLIENT09-0.img +-rw-r--r-- 1 root root 7.5G Jan 4 16:21 W10-ROUTER-0.img +-rw-r--r-- 1 root root 18G Jan 4 16:25 W10-MASTER-IMG.qcow2 + +Disk image size after 24 hours (printed on Jan 05): +-rw-r--r-- 1 root root 13G Jan 5 15:07 W10-TS01-0.img +-rw-r--r-- 1 root root 8.9G Jan 5 14:20 W10-TS02-0.img +-rw-r--r-- 1 root root 9.0G Jan 5 15:07 W10-TS03-0.img +-rw-r--r-- 1 root root 10G Jan 5 15:08 W10-CLIENT01-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT02-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT03-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT04-0.img +-rw-r--r-- 1 root root 19G Jan 5 15:07 W10-CLIENT05-0.img +-rw-r--r-- 1 root root 14G Jan 5 15:08 W10-CLIENT06-0.img +-rw-r--r-- 1 root root 9.7G Jan 5 15:07 W10-CLIENT07-0.img +-rw-r--r-- 1 root root 35G Jan 5 15:08 W10-CLIENT08-0.img +-rw-r--r-- 1 root root 9.2G Jan 5 15:07 W10-CLIENT09-0.img +-rw-r--r-- 1 root root 41G Jan 5 15:08 W10-ROUTER-0.img +-rw-r--r-- 1 root root 18G Jan 4 16:25 W10-MASTER-IMG.qcow2 + +You can reproduce this bug as follow: +1) create an initial disk image +2) create a linked clone +3) create a snapshot of the linked clone +4) revert the snapshot every X minutes / hours + +Due the described behavior / bug, our VM farm is completely down at the moment (as we run out of disk space on all host systems). A quick fix for this bug would be much appreciated. + +Host OS: Ubuntu 18.04.01 LTS +Kernel: 4.15.0-43-generic +Qemu: 3.1.0 +libvirt: 4.10.0 +Guest OS: Windows 10 64bit + +On 1/5/19 9:32 AM, Lenny Helpline wrote: + +> +> You can reproduce this bug as follow: +> 1) create an initial disk image +> 2) create a linked clone +> 3) create a snapshot of the linked clone +> 4) revert the snapshot every X minutes / hours + +Needs more details to reproduce. What is the exact command you used for +each of these steps? For example, without that command, I can't tell if +you are creating internal or external snapshots, and that drastically +changes the approach for how to deal with reverting snapshots. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + + +I don't have many commands handy, as we manage almost everything through libvirt manager. + +3) create a snapshot of the lined clone: + +virsh snapshot-create-as --domain <VMNAME> --name "test" --halt + +4) revert the snapshot every X minutes / hours: + +virsh destroy <VMNAME> +virsh snapshot-revert --snapshotname test --running --force + +Does that help? + +On 1/8/19 2:30 AM, Lenny Helpline wrote: +> I don't have many commands handy, as we manage almost everything through +> libvirt manager. +> +> 3) create a snapshot of the lined clone: +> +> virsh snapshot-create-as --domain <VMNAME> --name "test" --halt +> +> 4) revert the snapshot every X minutes / hours: +> +> virsh destroy <VMNAME> +> virsh snapshot-revert --snapshotname test --running --force +> +> Does that help? + +Yes. It shows that you are taking internal snapshots, rather than +external. Note that merely reverting to an internal snapshot does not +delete that snapshot, and also note that although qemu has code for +deleting internal snapshots, I doubt that it currently reclaims the disk +space that was previously in use by that snapshot but no longer needed. +Internal snapshots do not get much attention these days, because most of +our work is focused on external snapshots. + +If you were to use external snapshots, then every time you wanted to +create a point in time that you might need to roll back to, you create a +new external snapshot, turning: + +image1 + +into + +image1 <- temp_overlay + +then, at the point when you are done with the work in temp_overlay2, you +reset the domain back to using image1 and throw away the old +temp_overlay (or, recreate temp_overlay to be blank, which is the same +as going back to the state in image1); thus, the size of image1 never +grows because you are doing all work in temp_overlay, and rolling back +no longer keeps the changes that were done in a previous branch of work +the way internal snapshots are doing. + +In libvirt terms, you could create an external snapshot by adding +--diskspec $disk,snapshot=external for each $disk of your domain (virsh +domblklist can be used to get the list of valid $disk names). But +libvirt support for reverting to external snapshots is still not +completely rounded out, so you'll have to do a bit more leg work on your +end to piece things back together. + +Asking on the libvirt list may give you better insights on how best to +use libvirt to drive external snapshots to accomplish your setup of +frequently reverting to older points in time. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + + +Regarding snapshot deletion, QEMU does punch holes into the image file when deleting snapshots, so the space should effectively be freed, even if this isn't visible in the file size. To get actually meaningful numbers, you'd have to look at the allocated blocks rather than the file size (e.g. by using 'du -h' instead of 'ls -lh'). + +A quick test with internal snapshots didn't show any increase of the used space for me. So the condition to trigger the problem must be a little more complicated than just saving, loading and deleting some snapshots. After some random manual testing, I wrote a small script to share the results with you: + +#!/bin/bash + +./qemu-img create -f qcow2 /tmp/test.qcow2 64M +./qemu-io -c 'write 16M 32M' /tmp/test.qcow2 +du /tmp/test.qcow2 +./qemu-img snapshot -c snap0 /tmp/test.qcow2 +./qemu-io -c 'write 0 32M' /tmp/test.qcow2 +./qemu-img snapshot -c snap1 /tmp/test.qcow2 +./qemu-io -c 'write 32M 32M' /tmp/test.qcow2 +./qemu-img snapshot -a snap0 /tmp/test.qcow2 +./qemu-img snapshot -d snap0 /tmp/test.qcow2 +./qemu-img snapshot -d snap1 /tmp/test.qcow2 +du /tmp/test.qcow2 + +The result of this script is that both 'du' invocations show the same value for me, i.e. after taking two snapshots and making the image fully allocated, reverting to the first snapshot and deleting the snapshots gets the image back to the original 32 MB: + +Formatting '/tmp/test.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 lazy_refcounts=off refcount_bits=16 +wrote 33554432/33554432 bytes at offset 16777216 +32 MiB, 1 ops; 0.0088 sec (3.520 GiB/sec and 112.6380 ops/sec) +33028 /tmp/test.qcow2 +wrote 33554432/33554432 bytes at offset 0 +32 MiB, 1 ops; 0.0083 sec (3.739 GiB/sec and 119.6602 ops/sec) +wrote 33554432/33554432 bytes at offset 33554432 +32 MiB, 1 ops; 0.0082 sec (3.785 GiB/sec and 121.1094 ops/sec) +33028 /tmp/test.qcow2 + +Maybe you can play a bit more with qemu-img and qemu-io and find a case where the image grows like you see on your VM? Once we got a reproducer, we can try and check where the growth comes from. + +We have played a bit around with external snapshots (as suggested by Eric Blake in post #3), however, it appears that external snapshots are not fully supported yet. While I can create external snapshots, I'm unable to revert to them using virt-manager (which we use for managing our VM farm): + +Error running snapshot 'test': unsupported configuration: revert to external snapshot not supported yet + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 82, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1225, in revert_to_snapshot + self._backend.revertToSnapshot(snap.get_backend()) + File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1945, in revertToSnapshot + if ret == -1: raise libvirtError ('virDomainRevertToSnapshot() failed', dom=self) +libvirtError: unsupported configuration: revert to external snapshot not supported yet + +.... which means that using external snapshots is not an option for us. + +Kevin Wolf, over which time period did you run the VMs? Have you made any kind of i/o intensive stuff in the guest itself? e.g. user logon / logoff, serving the web, installing updates + +We continue to have big problems with the described issue, here's another example (23GB Vs. 41GB on disk): + +# ls -lah +-rw-r--r-- 1 root root 41G Jan 18 10:57 W10-ROUTER-0.img + +# qemu-img info W10-ROUTER-0.img +image: W10-ROUTER-0.img +file format: qcow2 +virtual size: 320G (343597383680 bytes) +disk size: 23G +cluster_size: 65536 +backing file: /var/lib/libvirt/images/W10-MASTER-IMG.qcow2 +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 1 6.0G 2019-01-04 14:51:49 01:09:32.118 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + + +Looking at the file size isn't helpful. The 23 GB are the space that is actually used. You can use 'du -h' to confirm this, but I think it gets the number in the exact same way as qemu-img. + +> Looking at the file size isn't helpful. The 23 GB +> are the space that is actually used. You can use 'du -h' +> to confirm this, but I think it gets the number in the exact same way as qemu-img. + +Are you sure about that? My OS complains that the disk is full. I can't even start any VM anymore. That's the reason why I've opened this ticket. Otherwise I wouldn't care.... + +$ df -h +Filesystem Size Used Avail Use% Mounted on +udev 63G 0 63G 0% /dev +tmpfs 13G 164M 13G 2% /run +/dev/md1 455G 455G 0 100% / + + + + +# du -sh W10-CLIENT01-0.img +115G W10-CLIENT01-0.img + + +Vs original file size: +8GB W10-CLIENT01-0.img + +How's that possible? + + + +# qemu-img info W10-CLIENT01-0.img +image: W10-CLIENT01-0.img +file format: qcow2 +virtual size: 320G (343597383680 bytes) +disk size: 114G +cluster_size: 65536 +backing file: /var/lib/libvirt/images/W10-MASTER-IMG.qcow2 +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 1 6.4G 2019-01-04 14:33:47 01:14:37.729 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1815721 b/results/classifier/118/permissions/1815721 new file mode 100644 index 00000000..4b321fa3 --- /dev/null +++ b/results/classifier/118/permissions/1815721 @@ -0,0 +1,103 @@ +permissions: 0.905 +debug: 0.876 +arm: 0.841 +risc-v: 0.835 +PID: 0.820 +device: 0.812 +performance: 0.803 +user-level: 0.800 +semantic: 0.800 +virtual: 0.799 +vnc: 0.797 +peripherals: 0.779 +graphic: 0.778 +architecture: 0.743 +register: 0.740 +hypervisor: 0.729 +files: 0.724 +network: 0.718 +KVM: 0.708 +VMM: 0.706 +assembly: 0.699 +boot: 0.696 +TCG: 0.674 +socket: 0.668 +mistranslation: 0.664 +ppc: 0.649 +kernel: 0.645 +x86: 0.591 +i386: 0.588 + +RISC-V PLIC enable interrupt for multicore + +Hello all, + +There is a bug in Qemu related to the enabling of external interrupts for multicores (Virt machine). + +After correcting Qemu as described in #1815078 (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable interrupts for core 1 at address 0x0C00_2080 we don't seem to be able to trigger an external interrupt (e.g. UART0). + +This works perfectly for core 0, but fore core 1 it does not work at all. I assume that given bug #1815078 does not enable any external interrupt then this feature has not been tested. I tried to look at the qemu source code but with no luck so far. + +I guess the problem is related to function parse_hart_config (in sfive_plic.c) that initializes incorrectly the plic->addr_config[addrid].hartid, which is later on read in sifive_plic_update. But this is a guess. + +Best regards, +Pharos team + +Hi, + +After some debugging (and luck), the problem (at least in the Virt board) was that the PLIC code inside QEMU addresses the core x 2 instead of just the core (core=hart). That is why it worked for core 0 (0x2 = 0) but for core 1 it has to address the PLIC memory area for core 2. + +For example, the interrupt enable address for core 1 starts at offset 0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc) but we actually have to change the enable bit for core 2 (at 0x002100) to make to work for core 1. + +The same is true for the priority threshold and claim complete registers (we need to multiply the core by 2) + +Either the documentation at https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc does not have the correct memory addresses for qemu virt board, or qemu appears to be wrong. + +On Tue, Mar 24, 2020 at 4:20 PM RTOS Pharos <email address hidden> wrote: +> +> Hi, +> +> After some debugging (and luck), the problem (at least in the Virt +> board) was that the PLIC code inside QEMU addresses the core x 2 instead +> of just the core (core=hart). That is why it worked for core 0 (0x2 = 0) +> but for core 1 it has to address the PLIC memory area for core 2. +> +> For example, the interrupt enable address for core 1 starts at offset +> 0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master +> /riscv-plic.adoc) but we actually have to change the enable bit for core +> 2 (at 0x002100) to make to work for core 1. + + +https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc says: + +"base + 0x002080: Enable bits for sources 0-31 on context 1" + +This is context 1, not core 1. + +It looks to me you were running an image built for SiFive FU540. +Please test your image against "sifive_u" machine instead. + +> +> The same is true for the priority threshold and claim complete registers +> (we need to multiply the core by 2) +> +> Either the documentation at https://github.com/riscv/riscv-plic- +> spec/blob/master/riscv-plic.adoc does not have the correct memory +> addresses for qemu virt board, or qemu appears to be wrong. +> +> -- + +Regards, +Bin + + +Thank you for the explanation. I actually built it for "Virt" machine. I'll try the "sifive_u" when I can. + +But I guess your explanation is correct so this bug could be closed from my part. + +Hello as far as I can tell, there is a major problem with PLIC implementation. When decompiling DTB on virt board with X harts, I see that hartid 0 has MEI and SEI, hartid 1 has MEI and SEI, etc... But when configuring context 1 (hartid 0 SEI) no interrupt is generated, but context 0, 2, 4 etc... work. So for me the problem is within PLIC or RISC-V implementation... If anyone wants to correct it, I can help. Best regards. Serge Teodori + +I'm going to close this bug as it seems like the issue that RTOS Pharos raised is not an issue. + +@Teodori Serge please open a new issue if you have a bug. Make sure to include as much detail as possible and steps to reproduce it. + diff --git a/results/classifier/118/permissions/1818880 b/results/classifier/118/permissions/1818880 new file mode 100644 index 00000000..92f0d4fe --- /dev/null +++ b/results/classifier/118/permissions/1818880 @@ -0,0 +1,264 @@ +permissions: 0.933 +peripherals: 0.931 +graphic: 0.919 +virtual: 0.914 +debug: 0.907 +register: 0.906 +user-level: 0.898 +KVM: 0.892 +device: 0.889 +hypervisor: 0.874 +ppc: 0.874 +performance: 0.861 +mistranslation: 0.861 +semantic: 0.860 +vnc: 0.859 +TCG: 0.846 +assembly: 0.844 +socket: 0.831 +arm: 0.823 +boot: 0.822 +network: 0.816 +risc-v: 0.808 +PID: 0.798 +VMM: 0.786 +architecture: 0.762 +files: 0.730 +kernel: 0.690 +x86: 0.556 +i386: 0.399 + +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/118/permissions/1819289 b/results/classifier/118/permissions/1819289 new file mode 100644 index 00000000..aefb503f --- /dev/null +++ b/results/classifier/118/permissions/1819289 @@ -0,0 +1,264 @@ +permissions: 0.817 +mistranslation: 0.786 +user-level: 0.781 +register: 0.765 +architecture: 0.739 +performance: 0.735 +semantic: 0.730 +boot: 0.722 +arm: 0.712 +debug: 0.706 +risc-v: 0.703 +device: 0.701 +assembly: 0.691 +graphic: 0.684 +ppc: 0.676 +PID: 0.672 +socket: 0.669 +files: 0.664 +VMM: 0.664 +vnc: 0.657 +virtual: 0.647 +hypervisor: 0.638 +i386: 0.612 +peripherals: 0.612 +KVM: 0.579 +network: 0.567 +kernel: 0.516 +TCG: 0.462 +x86: 0.425 + +Windows 95 and Windows 98 will not install or run + +The last version of QEMU I have been able to run Windows 95 or Windows 98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will either not install or will not run 95 or 98 at all. I have tried every combination of options like isapc or no isapc, cpu pentium or cpu as 486. Tried different memory configurations, but they just don't work anymore. + +I was able to get both running on 3.11.0, but something broke again by the time I re-tested on 4.0.0. 98 seems to work on 4.0 at least, but 95 just reboots infinitely after trying to boot from HDD after the initial setup. I tried searching their mailing list and asking around but nobody seems interested in fixing it. + +Whoops, 3.11.0 does not exist. Went back and did a full bisect. 3.0.0 works fine, and the breakage starts before 3.0.1 and 3.1.0 was released, specifically, with commit 05306935b1ae49107c2dc2f301574dd6c29b6838. + +On 8/19/19 7:26 PM, Brad Parker wrote: +> Whoops, 3.11.0 does not exist. Went back and did a full bisect. 3.0.0 +> works fine, and the breakage starts before 3.0.1 and 3.1.0 was released, +> specifically, with commit 05306935b1ae49107c2dc2f301574dd6c29b6838. + +This commit is migration related. Are you trying to restore/launch a pre-installed image? + +John reported "either not install or will not run 95 or 98 at all" but you report "95 just reboots infinitely after trying to boot from HDD after the initial setup." which is slighly different. + +What host/os/distrib are you using? + +What command line are you using to start QEMU? + +If you are using migration, I wonder if the following commit might affect here: + +commit 341ba0df4c69269cac839ddbacb2a0ca641a856d +Author: Peter Maydell <email address hidden> +Date: Tue Sep 25 17:19:24 2018 +0100 + + migration/ram.c: Avoid taking address of fields in packed MultiFDInit_t struct + + Taking the address of a field in a packed struct is a bad idea, because + it might not be actually aligned enough for that pointer type (and + thus cause a crash on dereference on some host architectures). Newer + versions of clang warn about this: + + Avoid the bug by not using the "modify in place" byteswapping + functions. + + +I am not using anything related to migration, just launching with a simple flat qcow2 file, no snapshots, backing stores or anything like that. + +The host is Archlinux x64 but I'm running inside of a docker container that runs Ubuntu 18.04. + +The command-line is: + +qemu-system-i386 -spice port=5800,disable-ticketing=on -cpu pentium -m 128 -vga std -no-kvm -hda Win95C.qcow2 -nodefaults -no-hpet -no-acpi -cdrom Win95C.iso -nodefaults -M isapc -monitor stdio + +Just FYI that was the second bisect I had to do, the first time it produced an even more unrelated commit, so I assumed I must have done something wrong... apparently that is still the case. After trying the "working" commit outside of the Docker container, it now does not work... so I'm at a loss as to how to reliably bisect I guess. Never had any issues with other projects doing it though. + +Yep, these types of bugs don't necessarily bisect cleanly if they're todo with code layout or dirty memory. +Still, it's good to keep a note of the earliest patches that you find a failure on - because then we know it must be somewhere before that. + +I remember there was a problem reported booting FreeDOS as well; and I've got to wonder if it's related. + +Hopefully third time's the charm. I ran yet another bisect, between 2.5.0 (working) and 2.11.0 (not working), this time reinstalling the entire OS from scratch with a blank disk every single time. Results: + +$ git bisect good +e3af7c788b73a6495eb9d94992ef11f6ad6f3c56 is the first bad commit +commit e3af7c788b73a6495eb9d94992ef11f6ad6f3c56 +Author: Paolo Bonzini <email address hidden> +Date: Wed Apr 26 13:59:34 2017 +0200 + + target/i386: introduce x86_ld*_code + + These take care of advancing s->pc, and will provide a unified point + where to check for the 15-byte instruction length limit. + + Signed-off-by: Paolo Bonzini <email address hidden> + + target/i386/translate.c | 228 ++++++++++++++++++++++++++---------------------- + 1 file changed, 125 insertions(+), 103 deletions(-) + + +If your bisect hit e3af7c788b73a6495 can you try it with cfcca361d77142f25f applied on top? That commit fixed a bug in e3af7c788b73a6495 which may be throwing off your bisection results. + + +e3af7c788b73a6495 was indeed one of the bad commits I tested during the bisect. If I apply cfcca361d77142f25f on top of it, Windows starts up normally instead of giving me a BSOD on bootup. + +So it looks like even though that commit fixed it, it seems to break again (differently) in 3.0.0, so I'll need to do another bisect between cfcca36 and v3.0.0 then I guess. And keep working my way up to master as well. + +Just finished a bisect between cfcca36 (working) and current master (not working), here is the result: + +$ git bisect bad +cd1bfd5ef336166b275a09dc9842542bf5e63ae3 is the first bad commit +commit cd1bfd5ef336166b275a09dc9842542bf5e63ae3 +Author: Gerd Hoffmann <email address hidden> +Date: Wed Jun 20 12:17:34 2018 +0200 + + seabios: update bios and vgabios binaries + + Adds two new vgabios binaries, for ramfb and bochs-display. + + Signed-off-by: Gerd Hoffmann <email address hidden> + + pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes + pc-bios/bios.bin | Bin 131072 -> 131072 bytes + pc-bios/vgabios-bochs-display.bin | Bin 0 -> 27648 bytes + pc-bios/vgabios-cirrus.bin | Bin 38400 -> 38400 bytes + pc-bios/vgabios-qxl.bin | Bin 38912 -> 38912 bytes + pc-bios/vgabios-ramfb.bin | Bin 0 -> 28160 bytes + pc-bios/vgabios-stdvga.bin | Bin 38912 -> 38912 bytes + pc-bios/vgabios-virtio.bin | Bin 38912 -> 38912 bytes + pc-bios/vgabios-vmware.bin | Bin 38912 -> 38912 bytes + pc-bios/vgabios.bin | Bin 38400 -> 38400 bytes + 10 files changed, 0 insertions(+), 0 deletions(-) + create mode 100644 pc-bios/vgabios-bochs-display.bin + create mode 100644 pc-bios/vgabios-ramfb.bin + + +I tried reverting that commit on top of master but it did not help, so I'm guessing it broke yet again (differently) somewhere else. I'll try reverting cd1bfd5 on top of the very next commit and bisect from there to master, and see where that takes me. + +> cd1bfd5ef336166b275a09dc9842542bf5e63ae3 is the first bad commit + +Unfortunately this is a commit related to SeaBIOS submodule. +This commit only update the built BIOS roms. + +The commits before this one are the ones modifying SeaBIOS, justifying roms to be rebuilt: + +eda553a442 seabios: enable ide dma +429d3ae2c8 seabios: update submodule to release 1.11.2 + +The first one (enable ide dma) is a change in the config. +You can rebuild the BIOS image and bisect around this commit. + +You can rebuild the SeaBIOS image running this command in QEMU source repository: + + $ make -C roms bios + +This will update 'pc-bios/bios.bin' which you use while bisecting. + +The second one update the SeaBIOS submodule from commit 0551a4be2c to commit f9626ccb91. + +These are not so many commits, so the bisect won't be painful: + +$ git log --oneline 0551a4be2~..f9626ccb91 +f9626cc (tag: rel-1.11.2) cbvga_set_mode: refine clear display logic +f88297a qemu: add qemu ramfb support +a2e4001 vgasrc: add allocate_pmm() +17b01f4 pmm: use tmp zone on oom +44b17d0 bochs_display_setup: return error on failure +4ba61fa cbvga_set_mode: disable clearmem in windows x86 emulator. +dd69189 cbvga_list_modes: don't list current mode twice +5f0e7c9 cbvga_setup_modes: use real mode number instead of 0x140 +961f67c qemu: add bochs-display support +767365e cbvga: factor out cbvga_setup_modes() +7906460 optionrom: enable non-vga display devices +0551a4b (tag: rel-1.11.1) paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified + +I recommend doing your bisection using 2 terminals: + +- one in QEMU source, running 'make -C roms bios' to rebuild 'pc-bios/bios.bin' and run QEMU installing your image, + +- one in roms/seabios/ where you run the 'git bisect' commands. + +Note, you don't have to rebuild QEMU. + +Alternatively, using a single terminal, you can stand in the roms/seabios/ directory, bisect and run 'make -C .. bios'. In this case it might be useful to run QEMU with -L ../../pc-bios to specify the path to the generated bios.bin. + +You are close, good luck! + +After hours bisecting various QEMU/SeaBIOS combinations, Brad figured out a new commit: + +0a7fa00a13f0852ec6fa83ab987a5ee7978d9867 is the first bad commit +Author: Emilio G. Cota <email address hidden> +Date: Mon Aug 13 20:52:26 2018 -0400 + + configure: enable mttcg for i386 and x86_64 + +Note 1: Brad was not using '-M isapc'. +Note 2: Brad was using the pc-bios/ folder checkout'd at v4.1.0 or 33f18cf7dc to avoid the SeaBIOS issues reported previously + +Brad could succeed booting QEMU using '-accel thread=single' on 0a7fa00a13. + + + +Here is the exact working command line I used for Windows 95C (OSR2.5): + +qemu-system-i386 -cpu pentium -m 128 -vga std -no-kvm -hda ~/Win95C.qcow2 -nodefaults -no-hpet -no-acpi -nodefaults -monitor stdio -sdl -boot menu=on,order=c,splash-time=2000 -accel tcg,thread=single + +To install the OS I simply added -cdrom and -fda, but everything else stayed the same. + +This was using the latest master (33f18cf, after v4.1.0) and its included bios binaries. + +I just did an install of Windows 95 in 4.2 and it installs and runs out of the box with -accel tcg. Thanks!! + +According to the last comment, the problem seems to be fixed since QEMU 4.2, right? ... so I'm closing this ticket now. If there is still something left to do, please open again. + +Per Brad on IRC, this issue persists. Re-opening to move to GitLab. + +Since there is some unclear information in here (which version is working? which is not?), could you please open a new ticket on gitlab instead, with a proper description what is not working with which version? + +Brad said later after testing v6.1 it was fixed so please disregard previous comment ¯\_(ツ)_/¯ + +This is happening again in 8.1. I used Windows 95 for a while in 6.1 and it +was fine, but when I tried to upgrade to 8.1, it started happening again. I +tried reducing the memory and it still happens. Not an urgent issue though. + +On Mon, Aug 30, 2021 at 2:05 AM Philippe Mathieu-Daudé < +<email address hidden>> wrote: + +> Brad said later after testing v6.1 it was fixed so please disregard +> previous comment ¯\_(ツ)_/¯ +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1819289 +> +> Title: +> Windows 95 and Windows 98 will not install or run +> +> Status in QEMU: +> Fix Released +> +> Bug description: +> The last version of QEMU I have been able to run Windows 95 or Windows +> 98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will +> either not install or will not run 95 or 98 at all. I have tried every +> combination of options like isapc or no isapc, cpu pentium or cpu as +> 486. Tried different memory configurations, but they just don't work +> anymore. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1819289/+subscriptions +> +> + + +I found a win98 iso image and gave this a try with qemu 8.1. It works here just fine - either kvm or tcg mode, either qemu x86_64 or i386. Without any extra options, just this: + + + qemu-system-i386 -cdrom w98.iso -drive file=w98.img,format=raw + +It also works fine with a few previous versions of qemu (tried 5.2 and 7.2). Everything tested on debian bookworm (with various versions of qemu debian packages). + diff --git a/results/classifier/118/permissions/1821006 b/results/classifier/118/permissions/1821006 new file mode 100644 index 00000000..96c13663 --- /dev/null +++ b/results/classifier/118/permissions/1821006 @@ -0,0 +1,143 @@ +permissions: 0.851 +device: 0.847 +register: 0.845 +architecture: 0.832 +performance: 0.824 +virtual: 0.813 +assembly: 0.803 +kernel: 0.795 +files: 0.790 +debug: 0.789 +boot: 0.789 +arm: 0.775 +PID: 0.774 +network: 0.771 +semantic: 0.763 +risc-v: 0.758 +VMM: 0.748 +socket: 0.744 +peripherals: 0.720 +user-level: 0.697 +graphic: 0.678 +ppc: 0.669 +mistranslation: 0.648 +vnc: 0.638 +hypervisor: 0.607 +KVM: 0.604 +TCG: 0.600 +x86: 0.588 +i386: 0.478 + +qemu: Unsupported syscall: 382 + +I used + +qemu-user-static/stable,stable,now 1:2.8+dfsg-6+deb9u5 amd64 [installed] + +When I try to build an image of a docker for an arm, an error occurs. + +This affects the operation of applications. + + +Dockerfile + +ARG ARCH +FROM ${ARCH}/debian:buster-slim + +RUN \ + printf "Install dependencies...\n" && \ + apt-get update && \ + apt-get install -y --no-install-recommends ca-certificates curl + +RUN curl https://google.com + +EOF + +The command that I run + +docker build --build-arg ARCH=arm32v7 --file ./Dockerfile -t test . + + +root@unit6:/lib/binfmt.d# cat qemu-arm-static.conf +:qemu-arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:F + +Here is a related discussion. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923479 + +I don't suppose you have a testcase that doesn't require docker? + +Syscall 382 is renameat2 for arm. Note that messages from QEMU about unsupported syscalls are often harmless, because typically they only appear for relatively new syscalls which QEMU hasn't implemented yet. The guest code will have a fallback path so it works on older kernels which don't implement the syscall, so a message is printed but the application still runs. So if the guest program is failing then it is quite likely to be for an entirely unrelated reason to the missing syscalls. + + +...that said, we should implement renameat2 provided that the host kernel does. What host kernel version are you using, and what host kernel minimum requirement was the glibc for your guest compiled to require? renameat2 was added in kernel 3.15, so if your host kernel is older than this but your guest glibc assumes it has at least 3.15 then there's no way QEMU can bridge this gap. + + +Yes, you are right the application works correctly. At least the result is expected. + +Vesion kernel +le9i0nx@unit6:~$ uname -a +Linux unit6 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux +Host debian 9 +quest debian 10 + +quest glib version +root@ddf2245902b3:/app# apt list | grep libc + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +libc-bin/now 2.28-7 armhf [installed,local] +libc6/now 2.28-7 armhf [installed,local] + +Examining the build source. I found an option +MIN_KERNEL_SUPPORTED := 3.2 + +I also tried to repeat through chroot. a message also appears. +https://wiki.debian.org/Arm64Qemu I use armhf. + +qemu-debootstrap --arch=armhf --keyring /usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd --exclude=debfoster buster debian-armhf http://ftp.debian.org/debian +chroot debian-armhf/ +apt-get install -y --no-install-recommends ca-certificates curl +... +debconf: falling back to frontend: Readline +Updating certificates in /etc/ssl/certs... +qemu: Unsupported syscall: 382 +128 added, 0 removed; done. +Setting up libgssapi-krb5-2:armhf (1.17-2) ... +Setting up libcurl4:armhf (7.64.0-1) ... +Setting up curl (7.64.0-1) ... +Processing triggers for libc-bin (2.28-8) ... +Processing triggers for ca-certificates (20190110) ... +... + + + + + +Upgrading the kernel did not change the situation. + +le9i0nx@unit6:~$ uname -a +Linux unit6 4.19.0-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.16-1~bpo9+1 (2019-02-07) x86_64 GNU/Linux + +... +Updating certificates in /etc/ssl/certs... +qemu: Unsupported syscall: 382 +0 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d... +... + +Thanks for that repro case with qemu-debootstrap and chroot. I can confirm that I can repro this with QEMU version 2.11.1. However with current head of git QEMU this is fixed -- the "unsupported syscall" message is not printed. We added support for the renameat2 syscall in commit 95d0307cc10ca3df87 which is in QEMU version 2.12 and later -- could you try with a newer QEMU version? + + +Unfortunately I was only able to check in 3.1. +There is no problem with the call. + +root@unit6:/mnt/build/chroot# dpkg -l | grep qemu-user-static +ii qemu-user-static 1:3.1+dfsg-5 amd64 QEMU user mode emulation binaries (static version) + + +Hello. + +As far as I can tell, this is still an issue with the latest available ubuntu, 18.04.2, which has: version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.15) + +Anyone know where I could get a newer version that would be compatible with Ubuntu? + diff --git a/results/classifier/118/permissions/1821430 b/results/classifier/118/permissions/1821430 new file mode 100644 index 00000000..159d3f0a --- /dev/null +++ b/results/classifier/118/permissions/1821430 @@ -0,0 +1,269 @@ +permissions: 0.927 +performance: 0.916 +debug: 0.900 +risc-v: 0.893 +network: 0.892 +mistranslation: 0.887 +graphic: 0.884 +semantic: 0.869 +device: 0.865 +architecture: 0.861 +peripherals: 0.852 +socket: 0.852 +arm: 0.850 +PID: 0.849 +register: 0.848 +user-level: 0.838 +virtual: 0.826 +hypervisor: 0.825 +files: 0.813 +boot: 0.813 +ppc: 0.811 +assembly: 0.801 +TCG: 0.790 +vnc: 0.789 +kernel: 0.772 +VMM: 0.770 +KVM: 0.760 +x86: 0.707 +i386: 0.522 + +qemu-user-arm (4.0.0-rc0) crashes + +I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper. +qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions: + +first case (sadly I don't have more data handy, can reproduce at a later time if needed): +(gdb) x/i $pc +=> 0xfffce314: vseleq.f64 d0, d17, d0 + +second case (llvm-config): +qemu cmdline: +qemu-arm -strace -cpu max -r 5.0.0 -L /home/asavah/kross/build/rpi3/rootfs -E LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode + +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +output from gdb(arm) attached to qemu-user-arm +Program received signal SIGILL, Illegal instruction. +0xf9f77f80 in ?? () +(gdb) bt +#0 0xf9f77f80 in ?? () +#1 0xfffd796c in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) x/i $pc +=> 0xf9f77f80: vrintm.f64 d18, d18 + + +The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 19.04 package and self built) +work flawlessly. + +This is clearly a regression. +Please fix before releasing 4.0.0. + +Can you provide binaries that reproduce this, please ? Attaching them to the bug is fine. + + +As requested I tarred the failing binaries. + +The first one (first case in the original report) is g-ir-compiler from gobjact-introspection, this one has another interesting detail: +if compiled with -mcpu=cortex-a53 -mfpu=neon-fp-armv8 (the correct flags for raspberry pi 3) it crashes on 4.0.0-rc, but works fine even on 4.0.0 if compiled with -mcpu=cortex-a53 -mfpu=neon-vfpv4 , on 3.1.0 it runs fine with -mfpu=neon-fp-armv8 . + +The second one (second case in original report), I'm not sure if its the llvm-config binary itself, +or the code from libLLVM so I attached the whole thing. +It only crashes if called with llvm-config --shared-mode , llvm-config --version and llvm-config --ldflags works fine. +-mfpu=neon-vfpv4 does not help here, crashes anyway, but has worked fine with 3.1.0 + + + + +asavah <email address hidden> writes: + +> Public bug reported: +> +> I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper. +> qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions: +> +> first case (sadly I don't have more data handy, can reproduce at a later time if needed): +> (gdb) x/i $pc +> => 0xfffce314: vseleq.f64 d0, d17, d0 +> +> second case (llvm-config): +> qemu cmdline: +> qemu-arm -strace -cpu max -r 5.0.0 -L +> /home/asavah/kross/build/rpi3/rootfs -E +> LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib +> /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode + +I should point out that a rpi3 is a cortex-a53 so -cpu cortex-a53 should +be all you need to run the binaries. -cpu max will enabled a bunch of +features you cannot use on an actual pi. + +> +> --- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} --- +> qemu: uncaught target signal 4 (Illegal instruction) - core dumped +> +> output from gdb(arm) attached to qemu-user-arm +> Program received signal SIGILL, Illegal instruction. +> 0xf9f77f80 in ?? () +> (gdb) bt +> #0 0xf9f77f80 in ?? () +> #1 0xfffd796c in ?? () +> Backtrace stopped: previous frame identical to this frame (corrupt stack?) +> (gdb) x/i $pc +> => 0xf9f77f80: vrintm.f64 d18, d18 +> +> +> The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 19.04 package and self built) +> work flawlessly. +> +> This is clearly a regression. +> Please fix before releasing 4.0.0. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + + +-- +Alex Bennée + + +I should point that -cpu cortex-a53 is not available in qemu-arm, +I'm building arm 32 bit stuff. + +qemu-arm -cpu help +Available CPUs: + arm1026 + arm1136 + arm1136-r2 + arm1176 + arm11mpcore + arm926 + arm946 + cortex-a15 + cortex-a7 + cortex-a8 + cortex-a9 + cortex-m0 + cortex-m3 + cortex-m33 + cortex-m4 + cortex-r5 + cortex-r5f + max + pxa250 + pxa255 + pxa260 + pxa261 + pxa262 + pxa270-a0 + pxa270-a1 + pxa270 + pxa270-b0 + pxa270-b1 + pxa270-c0 + pxa270-c5 + sa1100 + sa1110 + ti925t + any + + +Yeah, unfortunately we don't support cortex-a53 (or other 64-bit CPUs) in qemu-arm. (We also don't support them as highest-EL-is-AArch32 config in system mode.) Ideally we should fill in that gap, but in practice most people aren't building aarch32 code for ARMv8 -- either they want the back-compat with v7 CPUs or they are using 64-bit -- so it hasn't been very high priority for us. + + + + +Peter Maydell <email address hidden> writes: + +> Yeah, unfortunately we don't support cortex-a53 (or other 64-bit CPUs) +> in qemu-arm. (We also don't support them as highest-EL-is-AArch32 config +> in system mode.) Ideally we should fill in that gap, but in practice +> most people aren't building aarch32 code for ARMv8 -- either they want +> the back-compat with v7 CPUs or they are using 64-bit -- so it hasn't +> been very high priority for us. + +I was going to suggest -cpu cortex-a53,aarch64=off but that seems to be +only for KVM guests. + +Is there actually a v8 A profile 32 bit only CPU part? + +-- +Alex Bennée + + +On Mon, 25 Mar 2019 at 13:29, Alex Bennée <email address hidden> wrote: +> I was going to suggest -cpu cortex-a53,aarch64=off but that seems to be +> only for KVM guests. +> +> Is there actually a v8 A profile 32 bit only CPU part? + +You can for instance connect up a Cortex-A53 with the +AA64nAA32 config signals hardwired to 0 ("go into AArch32 +on power-on-reset"), which is functionally the same thing. + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> On Mon, 25 Mar 2019 at 13:29, Alex Bennée <email address hidden> wrote: +>> I was going to suggest -cpu cortex-a53,aarch64=off but that seems to be +>> only for KVM guests. +>> +>> Is there actually a v8 A profile 32 bit only CPU part? +> +> You can for instance connect up a Cortex-A53 with the +> AA64nAA32 config signals hardwired to 0 ("go into AArch32 +> on power-on-reset"), which is functionally the same thing. + +So would it be reasonable to have a + +#ifndef TARGET_AARCH64 + { .name = "cortex-a53 (32bit)", .initfn = aarch32_a53_initfn }, +#endif + +and the appropriate init function in cpu.c? That should be all we need right? + +> +> thanks +> -- PMM + + +-- +Alex Bennée + + +On Mon, 25 Mar 2019 at 15:25, Alex Bennée <email address hidden> wrote: +> So would it be reasonable to have a +> +> #ifndef TARGET_AARCH64 +> { .name = "cortex-a53 (32bit)", .initfn = aarch32_a53_initfn }, +> #endif +> +> and the appropriate init function in cpu.c? That should be all we need right? + +As RTH says, for 4.0 the fix for this regression is simpler. +For the longer term I think we should look a little more broadly +at what would be needed for supporting system emulation mode +CPUs which are nominally aarch64 but configured to boot into +aarch32 on reset, to see whether the linux-user mode falls +out as a subset of that. (It may be that it does not, but +it would definitely be better if we can avoid having to +duplicate the ID register and feature settings for the +64-bit CPUs in both cpu64.c and cpu.c.) + +thanks +-- PMM + + +I think this bug should be fixed by commit c8877d0f2f662bf01346a (which has just landed in git master and should be in rc1 when we tag it, probably later today). Please let us know if it hasn't fixed all the regressions for you. + + +qemu-user-arm 4.0.0-rc1 no longer produces any crashes for me. +Huge thanks. + + diff --git a/results/classifier/118/permissions/1821595 b/results/classifier/118/permissions/1821595 new file mode 100644 index 00000000..21673f4b --- /dev/null +++ b/results/classifier/118/permissions/1821595 @@ -0,0 +1,157 @@ +permissions: 0.907 +user-level: 0.874 +semantic: 0.844 +device: 0.842 +virtual: 0.837 +register: 0.825 +assembly: 0.824 +debug: 0.819 +architecture: 0.812 +graphic: 0.804 +performance: 0.797 +hypervisor: 0.791 +mistranslation: 0.790 +risc-v: 0.787 +arm: 0.774 +PID: 0.755 +vnc: 0.755 +VMM: 0.753 +files: 0.740 +socket: 0.735 +peripherals: 0.725 +ppc: 0.722 +boot: 0.698 +KVM: 0.684 +kernel: 0.665 +network: 0.644 +TCG: 0.536 +x86: 0.525 +i386: 0.522 + +Failed to emulate MMIO access with EmulatorReturnStatus: 2 + +I have compiled qemu with enable-whpx parameter for Hyper-V Platform API in Mingw64 . When I tried run with Windows 7 iso file I have faced issue with the following problem: +qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor + + +configuration directives: + +../configure --target-list=x86_64-softmmu,i386-softmmu --enable-lzo\ + --enable-bzip2 --enable-tools --enable-sdl --enable-gtk --enable-hax\ + --enable-vdi --enable-qcow1 --enable-whpx --disable-capstone\ + --disable-werror --disable-stack-protector --prefix="../../QEMU-bin" + + +Qemu command line: +qemu-system-x86_64.exe -m 1024 -cdrom "C:\Users\vmcs\Documents\en_windows_7_home_premium_with_sp1_x86_dvd_u_676701.iso" -display sdl -machine q35 -accel whpx + +Hi, + +Having a similar issue here, running "QEMU emulator version 4.2.91 (v5.0.0-rc1-31-g146aa0f104-dirty)" + +Configuration / build command line, +./configure --cross-prefix=x86_64-w64-mingw32- --target-list=x86_64-softmmu --enable-whpx --enable-fdt --enable-gtk --enable-vnc --disable-pie --enable-opengl && make -j16 && make -j16 installer + +And the QEMU command line, +qemu-system-x86_64.exe \ + -m 2G \ + -machine q35 \ + -cpu Penryn \ + -accel whpx \ + -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ + -smbios type=2 \ + -drive if=pflash,format=raw,readonly,file="./firmware/OVMF_CODE.fd"\ + -drive if=pflash,format=raw,file="./firmware/OVMF_VARS-1024x768.fd" \ + -usb -device usb-kbd -device usb-mouse \ + -netdev user,id=net0 \ + -device e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 \ + -device ich9-ahci,id=sata \ + -drive id=ESP,if=none,format=qcow2,file=ESP.qcow2 \ + -device ide-hd,bus=sata.2,drive=ESP \ + -drive id=InstallMedia,format=raw,if=none,file=BaseSystem.img \ + -device ide-hd,bus=sata.3,drive=InstallMedia \ + -drive id=SystemDisk,if=none,file=MyDisk.qcow2 \ + -device ide-hd,bus=sata.4,drive=SystemDisk \ + + +If I remove (only), -accel whpx \ => Then it all runs, just very slowly ;-). + +Any suggestions, things to try? + +Thanks! + +FYI, I was curious if this was a Ryzen issue or not (which I am running), so I tried another machine - here are the two combos I tried, +1) Ryzen 5 2600X, Windows 19041.172 +2) Core i5-6600K, Windows 18363.720 + +Same issue on both. + +Thanks! + +Which OS do you try with qemu? IIRC Windows 10 should work well with WHPX. Also,this issue is qemu depended that they don't handle specific MMIO instruction/exit. + +Sorry for the typo. I should have mentioned that this issue is WHPX related. I have created an issue in WHPX Github page about it. + +As far as I can tell QEMU just hands this off to the whpx emulation sub-system: + + https://docs.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatortryemulation + +Basically what is happening is the guest has tried to access I/O space and trapped back to QEMU which then passes the instruction back to the whpx support library to decode and emulate. + +Hi, + +I tried backing up ... nothing but startup and UEFI (i.e. no OS, just get to the EFI Shell). Can't even get there ... does that make sense? + +Thanks! + +I think WHPX can't some MMIO requests for EFI. + +Folks seem to think this is the fix, +https://stackoverflow.com/questions/55197032/android-emulator-whpx-failed-to-emulate-mmio-access-exit-code-3 + +But it's not working for me ... does it help you? + +Thanks! + +And here, +https://www.reddit.com/r/androiddev/comments/c7u6h2/android_virtual_device_on_ryzen/ + + +I don't think QEMU can do anything to fix this - you need to build against a new library. + +Sorry, not quite following your comment - but it's likely me :-(. + +I assume you mean QEMU - but build against what upstream library? I ask because for QEMU to build, only the three header files from Windows are copied over, and then it calls / uses the dll's (libraries) in Windows itself ... right? FYI, I'm running Windows 19041.172, to try to make sure I do have the latest related to whpx. + +Thanks! + +Hi, + +I built against the latest library I could (Windows Insider Preview, SDK) - same failure. + +Thoughts? + +Thanks! + +Should say - I rebuilt (today). Still no joy. + +Hi. I didnt build Qemu but I downloaded the last version 5.1.0 from https://qemu.weilnetz.de/w64/ and the error "Failed to emulate MMIO access with EmulatorReturnStatus: 2" happens when I use -drive if=pflash or -pflash with -accel whpx. + +"qemu-system-x86_64.exe -pflash d:\macWIN\OVMF_CODE.fd -accel whpx +Windows Hypervisor Platform accelerator is operational +qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 +qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor" + + +If I remove pflash and change to -bios "ovmf" the machine works. +qemu-system-x86_64.exe -bios d:\macWIN\OVMF_CODE.fd -accel whpx + +If I maintain pflash but remove -accel whpx the machine works too. +qemu-system-x86_64.exe -pflash d:\macWIN\OVMF_CODE.fd + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1825359 b/results/classifier/118/permissions/1825359 new file mode 100644 index 00000000..84ac3493 --- /dev/null +++ b/results/classifier/118/permissions/1825359 @@ -0,0 +1,217 @@ +permissions: 0.886 +arm: 0.817 +semantic: 0.811 +performance: 0.810 +graphic: 0.809 +assembly: 0.786 +ppc: 0.782 +peripherals: 0.767 +vnc: 0.759 +register: 0.756 +hypervisor: 0.753 +device: 0.753 +TCG: 0.751 +risc-v: 0.750 +VMM: 0.746 +virtual: 0.736 +architecture: 0.727 +files: 0.721 +mistranslation: 0.719 +debug: 0.712 +user-level: 0.712 +PID: 0.705 +network: 0.683 +KVM: 0.681 +socket: 0.669 +x86: 0.658 +kernel: 0.640 +i386: 0.608 +boot: 0.601 + +cpu_ld*_code() triggers MMU_DATA_LOAD i.s.o. MMU_INST_FETCH + +commit 377b155bde451d5ac545fbdcdfbf6ca17a4228f5 +Merge: c876180938 328eb60dc1 +Author: Peter Maydell <peter.x@x.x> ; masked for anti-spamming purposes +Date: Mon Mar 11 18:26:37 2019 +0000 +https://github.com/qemu/qemu/commit/377b155bde451d5ac545fbdcdfbf6ca17a4228f5 +-------------------------------------------------- + +cpu_ld*_code() is used for loading code data as the name suggests. Although, it begins +accessing memory with MMU_INST_FETCH access type, somewhere down the road, when the +"io_readx(..., access_type=MMU_INST_FETCH, ...)" is called, it is ignoring this "access_type" +while calling the "tlb_fill()" with a _hardcoded_ MMU_DATA_LOAD: + +cputlb.c +-------- +static uint64_t io_readx(..., MMUAccessType access_type, ...) +{ + + if (recheck) { + CPUTLBEntry *entry; + target_ulong tlb_addr; + + tlb_fill(cpu, addr, size, MMU_DATA_LOAD, mmu_idx, retaddr); + ... +} +-------- + +This is an issue, because there can exist _small_ regions of memory (smaller than the +TARGET_PAGE_SIZE) that are only executable and not readable. + +TL;DR + +What happens is at first, a "tlb_fill(..., access_type=MMU_INST_FETCH, ...)" is +triggered by "tb_lookup_cpu_state()". To be precise, this is the call stack which is good behavior: +--- +#0 tlb_fill (cs=..., vaddr=684, size=0, access_type=MMU_INST_FETCH, mmu_idx=0, retaddr=0) at target/arc/mmu.c:602 +#1 get_page_addr_code (env=..., addr=684) at accel/tcg/cputlb.c:1045 +#2 tb_htable_lookup (cpu=..., pc=684, cs_base=0, flags=0, cf_mask=4278190080) at accel/tcg/cpu-exec.c:337 +#3 tb_lookup__cpu_state (cpu=..., pc=..., cs_base=..., flags=..., cf_mask=4278190080) at include/exec/tb-lookup.h:43 +#4 tb_find (cpu=..., last_tb=... <code_gen_buffer+17811>, tb_exit=0, cf_mask=0) at accel/tcg/cpu-exec.c:404 +#5 cpu_exec (cpu=...) at accel/tcg/cpu-exec.c:729 +#6 tcg_cpu_exec (cpu=...) at cpus.c:1430 +#7 qemu_tcg_rr_cpu_thread_fn (arg=...) at cpus.c:1531 +#8 qemu_thread_start (args=...) at util/qemu-thread-posix.c:502 +--- + +After this call, TLB is filled with an entry that its size field is small, say 32 bytes. +This causes a TLB_RECHECK for consequent memory accesses, which is logical. However, +in our decoder, we use cpu_lduw_code() to read the instructions and decode them. As mentioned, +in the beginning, the access_type=MMU_INST_FETCH is lost in "io_readx()" while calling "tlb_fill()", +and now THIS CAUSES A GUEST EXCEPTION BECAUSE THAT REGION IS NOT ALLOWED TO BE READ. Here, +comes that trace call of the _bad_ behavior: +--- +#0 tlb_fill (..., access_type=MMU_DATA_LOAD, ...) at target/arc/mmu.c:605 +#1 io_readx (..., access_type=MMU_INST_FETCH, size=2) at accel/tcg/cputlb.c:881 +#2 io_readw (..., access_type=MMU_INST_FETCH) at accel/tcg/softmmu_template.h:106 +#3 helper_le_ldw_cmmu (..., oi=16, retaddr=0) at accel/tcg/softmmu_template.h:146 +#4 cpu_lduw_code_ra (env=..., ptr=684, retaddr=0) at include/exec/cpu_ldst_template.h:102 +#5 cpu_lduw_code (env=..., ptr=684) at include/exec/cpu_ldst_template.h:114 +#6 read_and_decode_context (ctx=..., opcode_p=...) at target/arc/arc-decoder.c:1479 +#7 arc_decode (ctx=...) at target/arc/arc-decoder.c:1736 +#8 decode_opc (env=..., ctx=...) at target/arc/translate.c:313 +#9 arc_tr_translate_insn (dcbase=..., cpu=...) at target/arc/translate.c:335 +#10 translator_loop (.. <code_gen_buffer+18131>) at accel/tcg/translator.c:107 +#11 gen_intermediate_code (cpu=..., tb=... <code_gen_buffer+18131>) at target/arc/translate.c:413 +#12 tb_gen_code (cpu=..., pc=684, cs_base=0, flags=0, cflags=-16711679) at accel/tcg/translate-all.c:1723 +#13 tb_find (cpu=..., last_tb=... <code_gen_buffer+17811>, tb_exit=0, cf_mask=0) at accel/tcg/cpu-exec.c:407 +#14 cpu_exec (cpu=...) at accel/tcg/cpu-exec.c:729 +#15 tcg_cpu_exec (cpu=...) at cpus.c:1430 + +--- + +Do you confirm if this is an issue? Maybe there are other ways to read an instruction with +MMU_INST_FETCH access that I don't know about. + +Last but not least, although this is not a security issue for QEMU per se, but it is hindering a +security feature for the guest. + +Yeah, this looks like a bug -- we should pass the access_type through rather than using MMU_DATA_LOAD. + + +Should I make a patch then? + + + + + + +The patch looks OK code-wise, but could you submit it to the mailing list, please? +https://wiki.qemu.org/Contribute/SubmitAPatch has the details, but the most important part is that it needs a Signed-off-by: line from you that says you have the legal right and are willing to contribute it to QEMU under our license. Otherwise we can't use the patch. + + +I have to say, after applying this patch, my test still fails while fetching the instructions from this _small_ region. Although there is no MMU_DATA_LOAD anymore, a few iterations later (while guest code has just jumped to the beginning of the executable region), QEmu segfaults (call stack is attached): + +memory.c +-------- +static MemTxResult +memory_region_read_with_attrs_accessor(MemoryRegion *mr, + ...) +{ + uint64_t tmp = 0; + MemTxResult r; + + r = mr->ops->read_with_attrs(mr->opaque, addr, &tmp, size, attrs); + ... +} +-------- + +Here, "read_with_attrs" is null. The call stack looks like: +--- +#0 memory_region_read_with_attrs_accessor at memory.c:465 +#1 access_with_adjusted_size at memory.c:568 +#2 memory_region_dispatch_read1 at memory.c:1425 +#3 memory_region_dispatch_read at memory.c:1446 +#4 io_readx at accel/tcg/cputlb.c:909 +#5 io_readw at accel/tcg/softmmu_template.h:106 +#6 helper_le_ldw_cmmu at accel/tcg/softmmu_template.h:146 +#7 cpu_lduw_code_ra at include/exec/cpu_ldst_template.h:102 +#8 cpu_lduw_code at include/exec/cpu_ldst_template.h:114 +#9 read_and_decode_context at target/arc/arc-decoder.c:1479 +#10 arc_decode at target/arc/arc-decoder.c:1736 +#11 decode_opc at target/arc/translate.c:313 +#12 arc_tr_translate_insn at target/arc/translate.c:335 +#13 translator_loop at accel/tcg/translator.c:107 +#14 gen_intermediate_code at target/arc/translate.c:413 +#15 tb_gen_code at accel/tcg/translate-all.c:1723 +#16 tb_find at accel/tcg/cpu-exec.c:407 +#17 cpu_exec at accel/tcg/cpu-exec.c:729 +#18 tcg_cpu_exec at cpus.c:1430 +--- +more detailed call stack is attached. + +call stack for SEGFAULT that happens during the execution of small region. This will go away IF THE ENTRY ADDED TO TLB FOR THIS REGION IS OF SIZE TARGET_PAGE_SIZE. However, that would not be correct behavior. + +That should not happen unless you have some device that is incorrectly not providing a suitable read function in its MemoryRegionOps. If you look at 'mr' in the debugger you should be able to figure out which device is the problem. + + +The problem seems to be this piece of code: + +cputlb.c +-------- +static uint64_t io_readx(...) +{ + + if (recheck) { + ... + + tlb_fill(cpu, addr, size, MMU_DATA_LOAD, mmu_idx, retaddr); + + entry = tlb_entry(env, mmu_idx, addr); + tlb_addr = entry->addr_read; + ... +} +-------- + +"entry->addr_read" is indeed looking for a "reading address". in this case, it must look for an +"executing address", i.e. "entry->addr_code". + +I see softmmu_template.h does something like this: +---- +... +#ifdef SOFTMMU_CODE_ACCESS +#define READ_ACCESS_TYPE MMU_INST_FETCH +#define ADDR_READ addr_code +#else +#define READ_ACCESS_TYPE MMU_DATA_LOAD +#define ADDR_READ addr_read +#endif +... + +WORD_TYPE helper_le_ld_name(...) +{ + ... + target_ulong tlb_addr = entry->ADDR_READ; + ... +} +---- + +This patch has fixed for me both issues. Although I am not very proud of the changes in the second hunk. Please let me know if there is a better way. + + +Your patch is now in git master as commit ef5dae6805cce7b59d129 -- thanks! + + +Thank YOU for all the supports along the way :) + diff --git a/results/classifier/118/permissions/1829779 b/results/classifier/118/permissions/1829779 new file mode 100644 index 00000000..82cd47f5 --- /dev/null +++ b/results/classifier/118/permissions/1829779 @@ -0,0 +1,110 @@ +permissions: 0.874 +socket: 0.849 +semantic: 0.821 +performance: 0.810 +register: 0.798 +arm: 0.789 +graphic: 0.788 +TCG: 0.781 +debug: 0.772 +device: 0.767 +architecture: 0.766 +peripherals: 0.758 +kernel: 0.755 +PID: 0.754 +boot: 0.726 +vnc: 0.717 +virtual: 0.698 +files: 0.693 +risc-v: 0.685 +user-level: 0.681 +hypervisor: 0.676 +ppc: 0.671 +assembly: 0.669 +KVM: 0.662 +VMM: 0.597 +network: 0.575 +mistranslation: 0.570 +x86: 0.511 +i386: 0.352 + +qemu-system-arm and qemu-system-aarch64 QMP hangs after kernel boots + +After booting a Linux kernel on both arm and aarch64, the QMP sockets gets unresponsive. Initially, this was thought to be limited to "quit" commands, but it reproduced with others (such as in this +reproducer). This is a partial log output: + + >>> {'execute': 'qmp_capabilities'} + <<< {'return': {}} + Booting Linux on physical CPU 0x0000000000 [0x410fd034] + Linux version 4.18.16-300.fc29.aarch64 (<email address hidden>) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:12:22 UTC 2018 + ... + Policy zone: DMA32 + Kernel command line: printk.time=0 console=ttyAMA0 + >>> {'execute': 'stop'} + <<< {'timestamp': {'seconds': 1558370331, 'microseconds': 470173}, 'event': 'STOP'} + <<< {'return': {}} + >>> {'execute': 'cont'} + <<< {'timestamp': {'seconds': 1558370331, 'microseconds': 470849}, 'event': 'RESUME'} + <<< {'return': {}} + >>> {'execute': 'stop'} + +Sometimes it takes just the first "stop" command. Overall, I was able to reproduce 100% of times when applied on top of 6d8e75d41c58892ccc5d4ad61c4da476684c1c83. + +The reproducer test can be seen/fetched at: + - https://github.com/clebergnu/qemu/commit/c778e28c24030c4a36548b714293b319f4bf18df + +And test results from Travis CI can be seen at: + - https://travis-ci.org/clebergnu/qemu/jobs/534915669 + +For convenience purposes, here's qemu-system-aarch64 launching and hanging on the first "stop": + - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3615 + - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3645 + +And here's qemu-system-arm hanging the very same way: + - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3780 + - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3800 + +I have an update on this. Eric and myself attempted to zero in the +exact cause. A few things we discovered: + + 1) It has nothing to do with having a kernel running + 2) It has to do with having a chardev that is a server socket. This + test produces command line arguments such as: + + -chardev socket,id=console,path=<path>.sock,server,nowait \ + -serial chardev:console + + 3) It doesn't seem to have a connection to the test infrastructure code + (python/qemu/qmp/*), as a I made a number of experiments which + yielded no differences in behavior. + +So, the reproducer given at: + + https://github.com/clebergnu/qemu/commit/c778e28c24030c4a36548b714293b319f4bf18df + +Continues to be be valid (and continues to be limited to arm and aarch64). +Now, after a number of experiments, the following was found to be a 100% +reproducible *workaround*: + + https://github.com/clebergnu/qemu/commit/e1713f3b91972ad57c089f276c54db3f3fa63423 + +That basically shutdowns the *console* socket before proceeding with further QMP +interaction. The effectiveness of the workaround can be seen here: + + aarch64 command line: + - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3633 + aarch64 QMP interaction: + - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3663 + + arm command line: + - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3747 + arm QMP interaction: + - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3767 + +I hope this provides a few more hints into the real issue. + + +A patch for this bug has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=085809670201c6d3a33e3 +... can we close this ticket now? + diff --git a/results/classifier/118/permissions/1830031 b/results/classifier/118/permissions/1830031 new file mode 100644 index 00000000..3c11d3f9 --- /dev/null +++ b/results/classifier/118/permissions/1830031 @@ -0,0 +1,128 @@ +permissions: 0.917 +device: 0.914 +virtual: 0.910 +semantic: 0.904 +user-level: 0.903 +mistranslation: 0.896 +register: 0.895 +architecture: 0.894 +graphic: 0.879 +PID: 0.876 +assembly: 0.871 +performance: 0.869 +files: 0.855 +debug: 0.853 +TCG: 0.849 +risc-v: 0.843 +arm: 0.837 +socket: 0.833 +peripherals: 0.820 +hypervisor: 0.818 +ppc: 0.817 +network: 0.802 +vnc: 0.793 +boot: 0.791 +KVM: 0.785 +VMM: 0.720 +kernel: 0.685 +x86: 0.681 +i386: 0.468 + +fatal error: float32nan on QEmu 3.1 + +Docker throws float32nan errors when running alpine container on a CentOS 7.6 ppc64le Distro VM, when using Fedora 30 Host qemu 3.1. I Compiled qemu 2.11.2 on the Fedora 30 and using this qemu-system-ppc64 we don't see the error. Even using qemu 3.1 and machine 2.11 we still get the same issue. + +Nothing changed on the OS level on the two runs. just the qemu-system-ppc64 used to run the virtual machine. + + Docker on CentOS 7: docker.ppc64le 2:1.13.1-96 + +Running with qemu 2.11.2 behavior and machine 2.11: +[root@machine ~]# /usr/local/bin/qemu-system-ppc64 -version +QEMU emulator version 2.11.2(qemu-2.11.2-5.fc30) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +[root@powericp ~]# docker run -i -t alpine /bin/sh +/ # exit +[root@powericp ~]# uname -a +Linux powericp 3.10.0-957.12.2.el7.ppc64le #1 SMP Tue May 14 22:24:22 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux +[root@powericp ~]# docker version +Client: + Version: 1.13.1 + API version: 1.26 + Package version: docker-1.13.1-96.gitb2f74b2.el7.centos.ppc64le + Go version: go1.10.3 + Git commit: b2f74b2/1.13.1 + Built: Wed May 1 15:05:41 2019 + OS/Arch: linux/ppc64le +… +[root@powericp ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 16 +NUMA node(s): 1 +Model: 2.0 (pvr 004e 1200) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 32K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 +################################################################################################# +#Running with qemu3.1 +################################################################################################# +[root@machine ~]# qemu-system-ppc64 -version +QEMU emulator version 3.1.0 (qemu-3.1.0-8.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers +[root@powericp ~]# docker run -i -t alpine /bin/sh +/usr/bin/docker-current: Error response from daemon: oci runtime error: error running hook: exit status 4, stdout: , stderr: fatal error: float32nan +runtime: panic before malloc heap initialized + +runtime stack: +fatal error: gentraceback before goexitPC initialization +runtime: panic before malloc heap initialized +panic during panic + +runtime stack: +fatal error: gentraceback before goexitPC initialization +runtime: panic before malloc heap initialized +stack trace unavailable. +[root@powericp ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 16 +NUMA node(s): 1 +Model: 2.0 (pvr 004e 1200) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 32K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 + + +strace attached. + + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1831486 b/results/classifier/118/permissions/1831486 new file mode 100644 index 00000000..10379d00 --- /dev/null +++ b/results/classifier/118/permissions/1831486 @@ -0,0 +1,76 @@ +permissions: 0.859 +architecture: 0.854 +register: 0.831 +performance: 0.821 +graphic: 0.821 +semantic: 0.820 +assembly: 0.817 +KVM: 0.808 +files: 0.800 +peripherals: 0.796 +arm: 0.795 +debug: 0.790 +TCG: 0.779 +device: 0.777 +socket: 0.776 +VMM: 0.776 +PID: 0.763 +user-level: 0.761 +x86: 0.761 +hypervisor: 0.756 +network: 0.755 +ppc: 0.751 +virtual: 0.749 +vnc: 0.732 +kernel: 0.724 +boot: 0.699 +risc-v: 0.639 +i386: 0.629 +mistranslation: 0.588 + +qmp monitor deadlock (with spice events for ex) + +If an event is emitted during monitor_flush_locked() it will deadlock. + +Thread 1 (Thread 0x7f14f1854000 (LWP 7245)): +#0 0x00007f14fc30592d in __lll_lock_wait () at /lib64/libpthread.so.0 +#1 0x00007f14fc2fedc9 in pthread_mutex_lock () at /lib64/libpthread.so.0 +#2 0x000055de60e19327 in qemu_mutex_lock_impl (mutex=0x55de61859e58, file=0x55de60f1a640 "/home/elmarco/src/qq/monitor.c", line=438) at /home/elmarco/src/qq/util/qemu-thread-posix.c:66 +#3 0x000055de6085c5af in monitor_puts (mon=0x55de61859d30, str=0x55de62a61d30 "{\"timestamp\": {\"seconds\": 1559585795, \"microseconds\": 508720}, \"event\": \"SPICE_DISCONNECTED\", \"data\": {\"server\": {\"port\": \"/tmp/.9IW52Z/spice.sock\", \"family\": \"unix\", \"host\": \"localhost\"}, \"client\": {"...) at /home/elmarco/src/qq/monitor.c:438 +#4 0x000055de6085c85a in qmp_send_response (mon=0x55de61859d30, rsp=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:493 +#5 0x000055de6085c8ee in monitor_qapi_event_emit (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:521 +#6 0x000055de6085c9ea in monitor_qapi_event_queue_no_reenter (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:546 +#7 0x000055de6085cd7a in qapi_event_emit (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:621 +#8 0x000055de60e04bc3 in qapi_event_send_spice_disconnected (server=0x55de61ee7b30, client=0x55de620c9090) at qapi/qapi-events-ui.c:101 +#9 0x000055de60c84381 in channel_event (event=3, info=0x55de6222f4c0) at /home/elmarco/src/qq/ui/spice-core.c:234 +#10 0x00007f14fc70ba3b in reds_handle_channel_event (reds=<optimized out>, event=3, info=0x55de6222f4c0) at reds.c:318 +#11 0x00007f14fc6f407b in main_dispatcher_self_handle_channel_event (info=0x55de6222f4c0, event=3, self=0x55de61a5b0b0) at main-dispatcher.c:191 +#12 0x00007f14fc6f407b in main_dispatcher_channel_event (self=0x55de61a5b0b0, event=event@entry=3, info=0x55de6222f4c0) at main-dispatcher.c:191 +#13 0x00007f14fc713cf3 in red_stream_push_channel_event (s=s@entry=0x55de6222f400, event=event@entry=3) at red-stream.c:416 +#14 0x00007f14fc713d2b in red_stream_free (s=0x55de6222f400) at red-stream.c:390 +#15 0x00007f14fc6fa67c in red_channel_client_finalize (object=0x55de62511360) at red-channel-client.c:347 +#16 0x00007f14fe4cfcf0 in g_object_unref () at /lib64/libgobject-2.0.so.0 +#17 0x00007f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at red-channel-client.c:1340 +#18 0x00007f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at red-channel-client.c:1303 +#19 0x00007f14fc6cd479 in red_char_device_send_msg_to_client (client=<optimized out>, msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307 +#20 0x00007f14fc6cd479 in red_char_device_send_msg_to_clients (msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307 +#21 0x00007f14fc6cd479 in red_char_device_read_from_device (dev=0x55de61a5b3b0) at char-device.c:355 +#22 0x000055de60a27dba in spice_chr_write (chr=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at /home/elmarco/src/qq/chardev/spice.c:201 +#23 0x000055de60d89e29 in qemu_chr_write_buffer (s=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25, offset=0x7ffcd5e1a860, write_all=false) at /home/elmarco/src/qq/chardev/char.c:113 +#24 0x000055de60d89f96 in qemu_chr_write (s=0x55de61924c00, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25, write_all=false) at /home/elmarco/src/qq/chardev/char.c:148 +#25 0x000055de60d8cf78 in qemu_chr_fe_write (be=0x55de61859d30, buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at /home/elmarco/src/qq/chardev/char-fe.c:42 +#26 0x000055de6085c40f in monitor_flush_locked (mon=0x55de61859d30) at /home/elmarco/src/qq/monitor.c:404 +#27 0x000055de6085c614 in monitor_puts (mon=0x55de61859d30, str=0x55de622f6a40 "{\"return\": {}, \"id\": 2}\n") at /home/elmarco/src/qq/monitor.c:446 +#28 0x000055de6085c85a in qmp_send_response (mon=0x55de61859d30, rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:493 +#29 0x000055de60865902 in monitor_qmp_respond (mon=0x55de61859d30, rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:4128 +#30 0x000055de60865a19 in monitor_qmp_dispatch (mon=0x55de61859d30, req=0x55de622ec000) at /home/elmarco/src/qq/monitor.c:4157 +#31 0x000055de60865ce2 in monitor_qmp_bh_dispatcher (data=0x0) at /home/elmarco/src/qq/monitor.c:4224 + + +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/175 + + diff --git a/results/classifier/118/permissions/1834113 b/results/classifier/118/permissions/1834113 new file mode 100644 index 00000000..10169c3d --- /dev/null +++ b/results/classifier/118/permissions/1834113 @@ -0,0 +1,313 @@ +permissions: 0.942 +mistranslation: 0.912 +risc-v: 0.902 +debug: 0.890 +user-level: 0.879 +performance: 0.873 +graphic: 0.867 +architecture: 0.863 +semantic: 0.861 +virtual: 0.857 +register: 0.853 +device: 0.852 +socket: 0.846 +kernel: 0.845 +assembly: 0.844 +arm: 0.840 +peripherals: 0.834 +PID: 0.828 +boot: 0.812 +VMM: 0.800 +files: 0.796 +hypervisor: 0.796 +KVM: 0.792 +vnc: 0.787 +ppc: 0.784 +network: 0.784 +TCG: 0.704 +x86: 0.701 +i386: 0.644 + +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/118/permissions/1836078 b/results/classifier/118/permissions/1836078 new file mode 100644 index 00000000..061cb33c --- /dev/null +++ b/results/classifier/118/permissions/1836078 @@ -0,0 +1,267 @@ +permissions: 0.900 +semantic: 0.835 +assembly: 0.833 +architecture: 0.829 +graphic: 0.815 +peripherals: 0.804 +register: 0.798 +arm: 0.793 +debug: 0.787 +device: 0.784 +performance: 0.783 +virtual: 0.781 +PID: 0.757 +mistranslation: 0.751 +user-level: 0.750 +risc-v: 0.725 +socket: 0.712 +hypervisor: 0.703 +ppc: 0.696 +kernel: 0.687 +network: 0.678 +VMM: 0.677 +vnc: 0.672 +boot: 0.663 +files: 0.645 +KVM: 0.626 +TCG: 0.613 +x86: 0.601 +i386: 0.521 + +Regressions on arm-linux-gnueabihf target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, +I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite. +I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. + +All tests used to pass w/o error, but with a recent qemu, all of them make qemu crash. + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabihf +--with-cpu cortex-a57 +--with-fpu crypto-neon-fp-armv8 + +Thanks + + + +I bisected the failure for all but the IEEE6 test to: + +commit 602f6e42cfbfe9278be34e9b91d2ceb695837e02 +Author: Peter Maydell <email address hidden> +Date: Thu Feb 28 10:55:16 2019 +0000 + + target/arm: Use MVFR1 feature bits to gate A32/T32 FP16 instructions + + Instead of gating the A32/T32 FP16 conversion instructions on + the ARM_FEATURE_VFP_FP16 flag, switch to our new approach of + looking at ID register bits. In this case MVFR1 fields FPHP + and SIMDHP indicate the presence of these insns. + + This change doesn't alter behaviour for any of our CPUs. + + Signed-off-by: Peter Maydell <email address hidden> + Reviewed-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + + +The IEEE6 test comes down to: + +commit a15945d98d3a3390c3da344d1b47218e91e49d8b +Author: Peter Maydell <email address hidden> +Date: Tue Feb 5 16:52:42 2019 +0000 + + target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI + + The {IOE, DZE, OFE, UFE, IXE, IDE} bits in the FPSCR/FPCR are for + enabling trapped IEEE floating point exceptions (where IEEE exception + conditions cause a CPU exception rather than updating the FPSR status + bits). QEMU doesn't implement this (and nor does the hardware we're + modelling), but for implementations which don't implement trapped + exception handling these control bits are supposed to be RAZ/WI. + This allows guest code to test for whether the feature is present + by trying to write to the bit and checking whether it sticks. + + QEMU is incorrectly making these bits read as written. Make them + RAZ/WI as the architecture requires. + + In particular this was causing problems for the NetBSD automatic + test suite. + + Reported-by: Martin Husemann <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + Reviewed-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + + + +In the ieee6 test case it is attempting to write OFE, bit [10] which: + + This bit is RW only if the implementation supports the trapping of floating-point exceptions. In an implementation that does not support floating-point exception trapping, this bit is RAZ/WI. + + When this bit is RW, it applies only to floating-point operations. Advanced SIMD operations always use untrapped floating-point exception handling in AArch32 state + +This might be a broken test. + +When we converted to using feature bits in 602f6e42cfbf we missed out +the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for +-cpu max configurations. This caused a regression in the GCC test +suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP. + +Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 +Signed-off-by: Alex Bennée <email address hidden> +--- + target/arm/cpu.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/target/arm/cpu.c b/target/arm/cpu.c +index e75a64a25a..0a0a202fe3 100644 +--- a/target/arm/cpu.c ++++ b/target/arm/cpu.c +@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj) + t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1); + cpu->isar.id_isar6 = t; + ++ t = cpu->isar.mvfr1; ++ t = FIELD_DP32(t, MVFR1, FPHP, 2); /* v8.2 FP16 */ ++ cpu->isar.mvfr1 = t; ++ + t = cpu->isar.mvfr2; + t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */ + t = FIELD_DP32(t, MVFR2, FPMISC, 4); /* FP MaxNum */ +-- +2.20.1 + + + + +Richard Henderson <email address hidden> writes: + +> On 7/10/19 7:24 PM, Alex Bennée wrote: +>> When we converted to using feature bits in 602f6e42cfbf we missed out +>> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for +>> -cpu max configurations. This caused a regression in the GCC test +>> suite. Fix this by setting the appropriate FP16 bits in mvfr1.FPHP. +>> +>> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 +>> Signed-off-by: Alex Bennée <email address hidden> +>> --- +>> target/arm/cpu.c | 4 ++++ +>> 1 file changed, 4 insertions(+) +>> +>> diff --git a/target/arm/cpu.c b/target/arm/cpu.c +>> index e75a64a25a..0a0a202fe3 100644 +>> --- a/target/arm/cpu.c +>> +++ b/target/arm/cpu.c +>> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj) +>> t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1); +>> cpu->isar.id_isar6 = t; +>> +>> + t = cpu->isar.mvfr1; +>> + t = FIELD_DP32(t, MVFR1, FPHP, 2); /* v8.2 FP16 */ +> +> The comment is wrong. This is not full v8.2 FP16 support (which would be value +> 3, plus a change to SIMDHP), but v8.0 support for double<->half +> conversions. + +Good catch - will fix in v2. +> +> Otherwise, +> Reviewed-by: Richard Henderson <email address hidden> +> +> +> r~ + + +-- +Alex Bennée + + +When we converted to using feature bits in 602f6e42cfbf we missed out +the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for +-cpu max configurations. This caused a regression in the GCC test +suite. Fix this by setting the appropriate bits in mvfr1.FPHP to +report ARMv8-A with FP support (but not ARMv8.2-FP16). + +Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 +Signed-off-by: Alex Bennée <email address hidden> +Reviewed-by: Richard Henderson <email address hidden> +--- + target/arm/cpu.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/target/arm/cpu.c b/target/arm/cpu.c +index e75a64a25a..ad164a773b 100644 +--- a/target/arm/cpu.c ++++ b/target/arm/cpu.c +@@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj) + t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1); + cpu->isar.id_isar6 = t; + ++ t = cpu->isar.mvfr1; ++ t = FIELD_DP32(t, MVFR1, FPHP, 2); /* v8.0 FP support */ ++ cpu->isar.mvfr1 = t; ++ + t = cpu->isar.mvfr2; + t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */ + t = FIELD_DP32(t, MVFR2, FPMISC, 4); /* FP MaxNum */ +-- +2.20.1 + + + +On Thu, 11 Jul 2019 at 11:37, Alex Bennée <email address hidden> wrote: +> +> When we converted to using feature bits in 602f6e42cfbf we missed out +> the fact (dp && arm_dc_feature(s, ARM_FEATURE_V8)) was supported for +> -cpu max configurations. This caused a regression in the GCC test +> suite. Fix this by setting the appropriate bits in mvfr1.FPHP to +> report ARMv8-A with FP support (but not ARMv8.2-FP16). +> +> Fixes: https://bugs.launchpad.net/qemu/+bug/1836078 +> Signed-off-by: Alex Bennée <email address hidden> +> Reviewed-by: Richard Henderson <email address hidden> +> --- +> target/arm/cpu.c | 4 ++++ +> 1 file changed, 4 insertions(+) +> +> diff --git a/target/arm/cpu.c b/target/arm/cpu.c +> index e75a64a25a..ad164a773b 100644 +> --- a/target/arm/cpu.c +> +++ b/target/arm/cpu.c +> @@ -2452,6 +2452,10 @@ static void arm_max_initfn(Object *obj) +> t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1); +> cpu->isar.id_isar6 = t; +> +> + t = cpu->isar.mvfr1; +> + t = FIELD_DP32(t, MVFR1, FPHP, 2); /* v8.0 FP support */ +> + cpu->isar.mvfr1 = t; +> + +> t = cpu->isar.mvfr2; +> t = FIELD_DP32(t, MVFR2, SIMDMISC, 3); /* SIMD MaxNum */ +> t = FIELD_DP32(t, MVFR2, FPMISC, 4); /* FP MaxNum */ +> -- +> 2.20.1 + + + +Applied to target-arm.next, thanks. + +-- PMM + + +I confirm this patch fixes the problem I reported. +Thanks! + +I think the ieee6 test is due to a broken runtime: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=45b1a243b81a7c9ae562 + diff --git a/results/classifier/118/permissions/1836558 b/results/classifier/118/permissions/1836558 new file mode 100644 index 00000000..bf80a300 --- /dev/null +++ b/results/classifier/118/permissions/1836558 @@ -0,0 +1,475 @@ +permissions: 0.924 +debug: 0.910 +x86: 0.904 +register: 0.901 +user-level: 0.899 +performance: 0.898 +architecture: 0.895 +ppc: 0.892 +PID: 0.886 +TCG: 0.885 +graphic: 0.882 +hypervisor: 0.881 +device: 0.875 +risc-v: 0.870 +semantic: 0.860 +virtual: 0.856 +socket: 0.851 +arm: 0.843 +KVM: 0.840 +assembly: 0.840 +vnc: 0.824 +files: 0.822 +boot: 0.811 +VMM: 0.791 +mistranslation: 0.783 +peripherals: 0.778 +network: 0.771 +kernel: 0.725 +i386: 0.570 + +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/118/permissions/1846816 b/results/classifier/118/permissions/1846816 new file mode 100644 index 00000000..fcf5f4f5 --- /dev/null +++ b/results/classifier/118/permissions/1846816 @@ -0,0 +1,516 @@ +permissions: 0.915 +virtual: 0.903 +register: 0.887 +peripherals: 0.860 +architecture: 0.856 +device: 0.855 +debug: 0.852 +PID: 0.850 +graphic: 0.844 +network: 0.823 +socket: 0.823 +arm: 0.819 +assembly: 0.814 +boot: 0.806 +semantic: 0.805 +user-level: 0.803 +performance: 0.798 +TCG: 0.791 +kernel: 0.780 +files: 0.775 +risc-v: 0.772 +hypervisor: 0.766 +vnc: 0.763 +KVM: 0.746 +ppc: 0.702 +x86: 0.652 +VMM: 0.639 +mistranslation: 0.587 +i386: 0.509 + +Booting error on AIX 6.1 "Illegal Trap Instruction Interrupt in Kernel"" + +# ls -ltr +total 8750584 +-rw-rw-r-- 1 linux linux 4274997248 Oct 4 18:33 AIX.vol1.iso +-rw-rw-r-- 1 linux linux 4293888000 Oct 4 18:45 AIX.vol2.iso +-rw-rw-r-- 1 linux linux 391485440 Oct 4 18:50 AIX.vol3.iso +-rw-r--r-- 1 root root 204608 Oct 4 19:00 AIX61.img + +# qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8192 -serial mon:stdio \ +> -drive file=/qemu/BST/AIX61.img,if=none,id=drive-virtio-disk0 \ +> -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ +> -cdrom /qemu/BST/AIX.vol1.iso \ +> -prom-env boot-command='boot cdrom: -s verbose' + + +VNC server running on ::1:5900 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: -s verbose from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... Successfully loaded +qemu-system-ppc64: Couldn't negotiate a suitable PVR during CAS +AIX +StarLED{814} + +AIX Version 6.1 +exec(/etc/init){1,0} + +INIT: EXECUTING /sbin/rc.boot 1 +exec(/usr/bin/sh,-c,/sbin/rc.boot 1){1114146,1} +exec(/sbin/rc.boot,/sbin/rc.boot,1){1114146,1} ++ PHASE=1 ++ + bootinfo -p +exec(/usr/sbin/bootinfo,-p){1179684,1114146} +PLATFORM=chrp ++ [ ! -x /usr/lib/boot/bin/bootinfo_chrp ] ++ [ 1 -eq 1 ] ++ 1> /usr/lib/libc.a ++ init -c unlink /usr/lib/boot/bin/!(*_chrp) +exec(/etc/init,-c,unlink /usr/lib/boot/bin/!(*_chrp)){1179686,1114146} ++ chramfs -t +exec(/usr/sbin/chramfs,-t){1179688,1114146} ++ init -c unlink /usr/sbin/chramfs ++ 1> /dev/null +exec(/etc/init,-c,unlink /usr/sbin/chramfs){1179690,1114146} ++ + bootinfo -t +exec(/usr/sbin/bootinfo,-t){1179692,1114146} +BOOTYPE=3 ++ [ 0 -ne 0 ] ++ [ -z 3 ] ++ unset pdev_to_ldev undolt native_netboot_cfg ++ unset disknet_odm_init config_ATM ++ /usr/lib/methods/showled 0x510 DEV CFG 1 START +exec(/usr/lib/methods/showled,0x510,DEV CFG 1 START){1179694,1114146} ++ cfgmgr -f -v +exec(/usr/sbin/cfgmgr,-f,-v){1179696,1114146} +cfgmgr is running in phase 1 +---------------- +Time: 0 LEDS: 0x538 +Invoking top level program -- "/etc/methods/defsys" +exec(/bin/sh,-c,/etc/methods/defsys ){1245222,1179696} +exec(/etc/methods/defsys){1245222,1179696} +exec(/bin/sh,-c,/usr/lib/methods/define_rspc -n -c sys -s node -t chrp){1310760,1245222} +exec(/usr/lib/methods/define_rspc,-n,-c,sys,-s,node,-t,chrp){1310760,1245222} +Time: 0 LEDS: 0x539 +Return code = 0 +***** stdout ***** +sys0 + +*** no stderr **** +---------------- +Attempting to configure device 'sys0' +Time: 0 LEDS: 0x811 +Invoking /usr/lib/methods/cfgsys_chrp -1 -l sys0 +exec(/bin/sh,-c,/usr/lib/methods/cfgsys_chrp -1 -l sys0){1245224,1179696} +Number of running methods: 1 +exec(/usr/lib/methods/cfgsys_chrp,-1,-l,sys0){1245224,1179696} +LED{A20} +Illegal Trap Instruction Interrupt in Kernel +04151A74 tweqi r0,0 r0=0 +KDB(0)> + +Did this used to work for you in older versions of QEMU, or is it a new bug (i.e. a regression)? AFAIK running AIX in QEMU has never worked so far... + +I only tried this with the last version of QEMU using an AIX image generated from a running AIX server using mksysb. + +There are some limitations but an AIX guest can run in QEMU: + +https://www.ibm.com/support/knowledgecenter/ssw_aix_72/aixnutanix/nutanix_concepts.html + +The command line in the bug description uses an old syntax: + +# qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries ... + +This should be: + +# qemu-system-ppc64 -cpu POWER8 -machine pseries,max-cpu-compat=power7 + +The following error message seems to indicate that this AIX instance doesn't support POWER7 architected mode (which I don't think is actively tested and supported by the way). + + qemu-system-ppc64: Couldn't negotiate a suitable PVR during CAS + +Maybe try again with max-cpu-compat=power8 instead ? + + +If you want to debug this, it'd be helpful to know few instructions/registers before the TRAP: + + Illegal Trap Instruction Interrupt in Kernel + 04151A74 tweqi r0,0 r0=0 + KDB(0)> + +A quicker way might be running QEMU with '-d unimp' to display missing devices/SPAPR hcalls. + +# qemu-system-ppc64 -cpu POWER8 -machine pseries,max-cpu-compat=power7 -m 8G -d unimp -serial stdio \ +-prom-env boot-command='boot cdrom: -s verbose'> -drive file=/qemu/AIX61.img,if=none,id=drive-virtio-disk0 \ +> -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \ +> -cdrom /qemu/AIX.vol1.iso \ +> -prom-env boot-command='boot cdrom: -s verbose' +VNC server running on ::1:5900 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: -s verbose from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... Successfully loaded +qemu-system-ppc64: Couldn't negotiate a suitable PVR during CAS +AIX Unimplemented SPAPR hcall 0x00000000000000ec +StarUnimplemented SPAPR hcall 0x00000000000000ec +LED{814} + +AIX Version 6.1 +exec(/etc/init){1,0} + +INIT: EXECUTING /sbin/rc.boot 1 +exec(/usr/bin/sh,-c,/sbin/rc.boot 1){1114146,1} +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/sbin/rc.boot,/sbin/rc.boot,1){1114146,1} +Unimplemented SPAPR hcall 0x00000000000002b8 ++ PHASE=1 ++ + bootinfo -p +exec(/usr/sbin/bootinfo,-p){1179684,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 +PLATFORM=chrp ++ [ ! -x /usr/lib/boot/bin/bootinfo_chrp ] ++ [ 1 -eq 1 ] ++ 1> /usr/lib/libc.a ++ init -c unlink /usr/lib/boot/bin/!(*_chrp) +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/etc/init,-c,unlink /usr/lib/boot/bin/!(*_chrp)){1179686,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 ++ chramfs -t +exec(/usr/sbin/chramfs,-t){1179688,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 ++ init -c unlink /usr/sbin/chramfs ++ 1> /dev/null +exec(/etc/init,-c,unlink /usr/sbin/chramfs){1179690,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 ++ + bootinfo -t +exec(/usr/sbin/bootinfo,-t){1179692,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 +BOOTYPE=3 ++ [ 0 -ne 0 ] ++ [ -z 3 ] ++ unset pdev_to_ldev undolt native_netboot_cfg ++ unset disknet_odm_init config_ATM ++ /usr/lib/methods/showled 0x510 DEV CFG 1 START +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/usr/lib/methods/showled,0x510,DEV CFG 1 START){1179694,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 ++ cfgmgr -f -v +exec(/usr/sbin/cfgmgr,-f,-v){1179696,1114146} +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +cfgmgr is running in phase 1 +---------------- +Time: 0 LEDS: 0x538 +Invoking top level program -- "/etc/methods/defsys" +exec(/bin/sh,-c,/etc/methods/defsys ){1245222,1179696} +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/etc/methods/defsys){1245222,1179696} +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/bin/sh,-c,/usr/lib/methods/define_rspc -n -c sys -s node -t chrp){1310760,1245222} +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/usr/lib/methods/define_rspc,-n,-c,sys,-s,node,-t,chrp){1310760,1245222} +Unimplemented SPAPR hcall 0x00000000000002b8 +Time: 0 LEDS: 0x539 +Return code = 0 +***** stdout ***** +sys0 + +*** no stderr **** +Unimplemented SPAPR hcall 0x00000000000002b8 +---------------- +Attempting to configure device 'sys0' +Time: 0 LEDS: 0x811 +Invoking /usr/lib/methods/cfgsys_chrp -1 -l sys0 +exec(/bin/sh,-c,/usr/lib/methods/cfgsys_chrp -1 -l sys0){1245224,1179696} +Number of running methods: 1 +Unimplemented SPAPR hcall 0x00000000000002b8 +exec(/usr/lib/methods/cfgsys_chrp,-1,-l,sys0){1245224,1179696} +Unimplemented SPAPR hcall 0x00000000000002b8 +LED{A20} +Illegal Trap Instruction Interrupt in Kernel +04151A74 tweqi r0,0 r0=0 +KDB(0)> +KDB(0)> stack +pvthread+002100 STACK: +[04151A74]init_extint_chrp+0001B4 (0000000000000000 [??]) +[0415030C]config_pal+00004C (??) +[04152D9C]config_chrp_pal@AF31_1+00009C (??, ??) +[00665BBC]config_kmod+0000DC (??, ??, ??) +[00666650]sysconfig+0001F0 (??, ??, ??) +[00003850]ovlya_addr_sc_flih_main+000130 () +[10004D48]cfgpal_chrp+0004A8 (??) +[100045AC]configure_device+00004C () +[100011B4]make_dvc_available+000034 () +[10000568]main+000248 (??, ??, ??) +[10000168]__start+000068 () + +KDB(0)> + + +The "tweqi r0,0 r0=0" is likely an assert() in the AIX code IIRC. Not sure it helps to see +previous instructions. + +About "Unimplemented SPAPR hcall 0x00000000000002b8": + +arch/powerpc/include/asm/hvcall.h:#define H_GET_EM_PARMS 0x2B8 + +and indeed QEMU doesn't implement this hcall. + +I've just realized this is AIX 6.1, which is so old that I'm pretty sure it doesn't run under QEMU. +And anyway, you need AIX 7.2 to have support for virtio devices. + + +I saw comments about support for virtio devices on AIX 7.2, was it not available on AIX 7.1? +With AIX 7.1 also, I am getting similar issue as faced by other users with AIX 6.1. + + + +qemu-system-ppc64 -cpu POWER8 -machine pseries -m 2048 -d unimp -serial stdio -drive file=disk.img,if=none,id=drive-virtio-disk0 -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 -cdrom AIX_7.1.iso -prom-env "boot-command=boot cdrom:" +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ccf-assist=on +VNC server running on 127.0.0.1:5900 + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 17 2020 11:15:24 + FW Version = git-e18ddad8516ff2cf + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... Successfully loaded + +AIX + StarUnimplemented SPAPR hcall 0x00000000000000ec + +AIX Version 7.1 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Unimplemented SPAPR hcall 0x00000000000002b8 +Illegal Trap Instruction Interrupt in Kernel +05861AAC tweqi r0,0 r0=0 +KDB(0)> + + +I no longer work for IBM so I can't be sure, but I'm not aware of virtio support in AIX 7.1. + +As said in another comment, the "Unimplemented SPAPR hcall 0x00000000000002b8" trace reflects that QEMU doesn't implement PEM (Partition Energy Management) as described in section 14.14 of LoPAPR. +I can't tell if this causing the crash of the AIX kernel, but I'd suggest you try with AIX 7.2. + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +Hello, + +I just wanted to confirm that this bug also affects me and that it also appears in qemu 6.0.0. + +When I try to boot up AIX 7.1 (and 6.1 as well), it prints the following line multiple times during boot: +Unimplemented SPAPR hcall 0x00000000000002b8 + +followed by crash: +Illegal Trap Instruction Interrupt in Kernel +05861AAC tweqi r0,0 r0=0 + + +I executed the following command to start qemu: +qemu-system-ppc64 -cpu POWER8 -machine pseries,max-cpu-compat=power7 -m 4096 -d unimp -serial stdio -drive file=hdisk0.qcow2,if=none,id=drive-virtio-disk0 -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 -cdrom /mnt/hgfs/Images/AIX7.1/install-1.iso -prom-env "boot-command=boot cdrom:" -prom-env "input-device=/vdevice/vty@71000000" -prom-env "output-device=/vdevice/vty@71000000" + +Since I am not the original author of this issue, I am not able to change its state to New again + +Sincerely +David + +The only AIX version that _might_ run with QEMU is 7.2. Older ones don't have virtio AFAIK. + + +Ok, so closing this ticket since AIX older than 7.2 cannot work. For AIX >= 7.2, we already have a different ticket opened instead: https://gitlab.com/qemu-project/qemu/-/issues/269 + +qemu-system-ppc64 should support AIX 5.3/6.1/7.1. If those OSes don't have virtio, then provide another way which simulates the machine's way to support the disk accessing. + diff --git a/results/classifier/118/permissions/1851845 b/results/classifier/118/permissions/1851845 new file mode 100644 index 00000000..2c658a5c --- /dev/null +++ b/results/classifier/118/permissions/1851845 @@ -0,0 +1,58 @@ +permissions: 0.896 +virtual: 0.883 +files: 0.878 +debug: 0.875 +graphic: 0.867 +performance: 0.867 +user-level: 0.866 +register: 0.862 +vnc: 0.861 +architecture: 0.845 +KVM: 0.841 +assembly: 0.840 +device: 0.839 +boot: 0.837 +risc-v: 0.832 +ppc: 0.832 +socket: 0.829 +network: 0.827 +semantic: 0.826 +arm: 0.824 +peripherals: 0.823 +VMM: 0.818 +kernel: 0.815 +hypervisor: 0.815 +PID: 0.808 +TCG: 0.807 +mistranslation: 0.785 +x86: 0.705 +i386: 0.648 + +Windows 10 panics with BlueIris + +Running Windows 10 64bit. Starting BlueIris 64 bit causes Windows to panic with CPU type is set higher than Penryn or CPU type = host. + +I have been able to reproduce the same issue on Proxmox 4,5,6 as well as oVirt 3. and 4. + +Does not panic when CPU type is set to kvm64. + + +pve-qemu-kvm/stable 4.0.1-4 amd64 + + /usr/bin/kvm -id 102 -name win7-01 -chardev socket,id=qmp,path=/var/run/qemu-server/102.qmp,server,nowait -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/102.pid -daemonize -smbios type=1,uuid=3ec61114-c30c-4719-aa00-f3f05be22d48 -smp 8,sockets=1,cores=8,maxcpus=8 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc unix:/var/run/qemu-server/102.vnc,password -no-hpet -cpu penryn,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,hv_synic,hv_stimer,hv_ipi,enforce -m 12000 -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device vmgenid,guid=50deb929-1974-4fd0-9ad3-71722149d568 -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=tablet,bus=uhci.0,port=1 -device VGA,id=vga,bus=pci.0,addr=0x2 -chardev socket,path=/var/run/qemu-server/102.qga,server,nowait,id=qga0 -device virtio-serial,id=qga0,bus=pci.0,addr=0x8 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:203582cea152 -drive if=none,id=drive-ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -drive file=/disk02/prox/images/102/vm-102-disk-0.raw,if=none,id=drive-virtio0,cache=writeback,format=raw,aio=threads,detect-zeroes=on -device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 -drive file=/dev/disk/by-id/ata-WDC_WD80EMAZ-00WJTA0_7SGZLHYC-part1,if=none,id=drive-virtio1,cache=writeback,format=raw,aio=threads,detect-zeroes=on -device virtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb -netdev type=tap,id=net0,ifname=tap102i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=1e:be:cb:0b:6f:13,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 -netdev type=tap,id=net1,ifname=tap102i1,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=EA:76:56:16:2F:D7,netdev=net1,bus=pci.0,addr=0x13,id=net1,bootindex=301 -rtc driftfix=slew,base=localtime -machine type=pc -global kvm-pit.lost_tick_policy=discard + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1858461 b/results/classifier/118/permissions/1858461 new file mode 100644 index 00000000..b3bf4ec7 --- /dev/null +++ b/results/classifier/118/permissions/1858461 @@ -0,0 +1,215 @@ +permissions: 0.875 +debug: 0.862 +device: 0.854 +register: 0.849 +architecture: 0.842 +PID: 0.841 +virtual: 0.837 +socket: 0.837 +kernel: 0.834 +graphic: 0.832 +risc-v: 0.829 +x86: 0.829 +TCG: 0.826 +assembly: 0.822 +semantic: 0.819 +user-level: 0.817 +arm: 0.811 +network: 0.811 +performance: 0.810 +KVM: 0.808 +VMM: 0.798 +ppc: 0.796 +peripherals: 0.788 +mistranslation: 0.783 +vnc: 0.779 +files: 0.775 +boot: 0.765 +hypervisor: 0.698 +i386: 0.580 + +Please refactor linux-user/mips/cpu_loop.c + +Hello. I am working with qemu on test images. I've added a new syscall (436) to qemu but received ENOSYS from mips application. + +Please open "linux-user/mips/cpu_loop.c". I've added at the end of "mips_syscall_args" the following: + +``` +MIPS_SYS(sys_getdents64_x32, 3) +``` + +But + +``` +syscall_num = env->active_tc.gpr[2] - 4000; +if (syscall_num >= sizeof(mips_syscall_args)) { + ret = -TARGET_ENOSYS; +``` + +returns -TARGET_ENOSYS + +We can see that "linux-user/mips/cpu_loop.c" differs a lot from "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc. + +Can you please refactor mips cpu loop in the same way as arm? Thank you. + +Added workaround for now + +Please do not use previous workaround in prod, it is bad, just proof of concept. + +It looks like nobody is maintaining syscall list. It is not possible to trust it. + +We have "arch/mips/kernel/syscalls/syscall_o32.tbl", we need to create generator. Generator should provide maximum possible number of arguments for syscall. For example: + +> sync_file_range sys_sync_file_range sys32_sync_file_range + +"sys_sync_file_range" has 4 arguments, "sys32_sync_file_range" - 7 arguments. Maximum value - 7 should be stored inside our table. + +The problem is that some syscalls in kernel code is prefixed by SYSCALL_DEFINE{N} or COMPAT_SYSCALL_DEFINE{N}. but some (like "sys_sync_file_range" and "sys32_sync_file_range") are not prefixed. + +So I think we may have a generator that provides "WAT?" if it don't know the arguments count and require to update value manualy. + + + +I've found a reliable way to generate syscall arguments count table. + +cd /usr/src/linux +make clean +make CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_SPLIT=y CONFIG_DEBUG_INFO_DWARF4=y +llvm-dwarfdump -debug-info --name ksys_getdents64 --show-children --recurse-depth=1 fs/readdir.dwo + +0x00013738: DW_TAG_subprogram + DW_AT_name ("ksys_getdents64") + ... + +0x00013752: DW_TAG_formal_parameter + ... + +0x00013766: DW_TAG_formal_parameter + ... + +0x00013779: DW_TAG_formal_parameter + ... + +We can count "DW_TAG_formal_parameter" for syscall and it that's it. + +Unfortunately we can generate only very short table of syscalls using this method. Most of the syscalls are missing from "dwo" files. =( + +It is possible to do the following: + +cd /usr/src/linux +make clean +make CC=clang +~/workspace/CastXML/build/bin/castxml -nostdinc -isystem /usr/lib/clang/9.0.1/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -include ./include/linux/kconfig.h -D__KERNEL__ arch/x86/entry/syscall_32.c --castxml-output=1 -o /tmp/syscall_32.xml + +It generates all information including params about 32bit syscalls for current amd64 platform. Unfortunately cross compilation of generic kernel using mips clang toolchain is almost impossible today. It is an idea for future. So today we have to parse "include/linux/syscalls.h", "include/linux/compat.h", "arch/mips/kernel/linux32.c", etc without respect to config and syntax. + + + +There is already a pending patch for mips that will handle the syscall in question. Will provide drtails tommorow. + +Andrew, + +Please take a look at the patch: + +http://patchwork.ozlabs.org/patch/1217454/ + +Once you apply the patch, it should be straightforward to add getdents64_x32() (right after clone3()) for all MIPS ABIs. + +The thing is, kernel folks recently made some rearrangements of syscall numbers, so that all architectures have in future "similar" syscall numbers, but that required some "holes" in syscall numbers schemes for virtuall all archs, and for MIPS among them. That is why ne array in linux-user/mips/cpu_loop.c has some elements defined just as "0" - they are there just to adjust syscall numbers to be in accordance with the new scheme. + +Please let us know if you are able to work with such solution or not. + +Happy New Year! + +Aleksandar + +Hello, thank you. I want to introduce another patch with syscalls related generator. Please review it. + +I think about the following development flow: + +1. Kernel updates and maintains "tbl". +2. Qemu developer wants to implement new syscall (like clone3) in "linux-user/syscall.c". +3. Developer clones new kernel into some directory and runs generators. +4. All syscall related stuff will be updated immediately. + +I think it will very straightforward solution. Qemu won't hardcode kernel related stuff and all linkage between kernel and qemu will be very easy. + + + +I've just written these generators in ruby, but it can be rewritten in python, perl, etc. + +On Wed, 8 Jan 2020 at 17:06, puchuu <email address hidden> wrote: +> I think about the following development flow: +> +> 1. Kernel updates and maintains "tbl". +> 2. Qemu developer wants to implement new syscall (like clone3) in "linux-user/syscall.c". +> 3. Developer clones new kernel into some directory and runs generators. +> 4. All syscall related stuff will be updated immediately. + +That seems like quite a lot of effort, given that we don't really +have to update the set of syscall number #defines very often. +At the moment it's just "somebody submits a patch which +updates the list of #defines every so often". (And if you want +to actually implement a new syscall then the the actual +implementation is the bulk of the work anyhow.) + +In particular if you really want to proceed down the path of +suggesting scripts for doing the update then I think we would +want something that works for all our architectures, not just MIPS. + +thanks +-- PMM + + +After applying my patch it seems like another issue was fixed: "emerge" inside qemu has no permissions bug. Without that patch I was able to reproduce "emerge" program can't apply any patch (permission denied). So it looks like old hardcoded table has some wrong values that are not compatible with current kernel. + +So I think that generator is super critical for mips. With that patch I am able to "emerge app-arch/gzip" inside qemu, works perfect. I will try to rebuild a complete image inside qemu. + +http://patchwork.ozlabs.org/patch/1217454/ + +I want to say that this patch is not safe. Zero values around "MIPS_SYS" means that syscall can be processed but arguments won't be received from stack (please see cpu loop switch). So when main code will receive a new syscall support - mips will become broken. I can recommend to use -1 intead and add additional check for "nb_args". + +Andrew, + +Thanks for your input regarding linked patch. The patch is still under review, and it is normal for patches under review to perhaps have some faults, and that is improved in the process of reviewing - that is, among other things, one of benefits of open source development. I will take into account your opinion, and fix the patch in the next version of the series. + +As far your ideas on other improvements, my advice is to submit them to the QEMU devel list - possibly as a short series of patches. Try to organize your changes in several patches, each representing a logical unit. For example: + + - one patch could be titled "linux-user: mips: Refactor enumerating of syscall numbers" + - the second patch could be "linux-user: Automate updating syscall numbers" (but, yes, this should work preferably for all targets, as Peter said) + - the third patch could be "linux-user: Fix execution of program 'emerge'" (I am not sure if there is a separate portion of code that fixes that) + - etc. - whatever you think should be fixed/improved + +As Thomas said, follow https://wiki.qemu.org/Contribute/SubmitAPatch . For each patch, provide background information, problem that is fixed with the patch, and why is the way you propose good. + +Also, can you please add more info on "emerge" problem, so that I can repro it with the current QEMU. I would prefer to know the roots cause, rather than just accept that the problem disappeared. + +I have certain concerns over a refactoring that changes the behavior. Refactorings in general should not do it, and if they still do, one should at least have a clear explanation. That is why I want more details on "emerge" problem. + +Sure, I will try to reproduce permissions issue and create a new issue later. I will try to provide small patches too. + +I've created a question on kernel bugzilla. https://bugzilla.kernel.org/show_bug.cgi?id=206135 They should know that applications wants much more than "tbl" provides. + +I've created a new patches for getdents bug https://sourceware.org/bugzilla/show_bug.cgi?id=23960 and I can't reproduce python permissions issue anymore. My mips image built with qemu user works perfect. + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/241 + + diff --git a/results/classifier/118/permissions/1862415 b/results/classifier/118/permissions/1862415 new file mode 100644 index 00000000..037e03f3 --- /dev/null +++ b/results/classifier/118/permissions/1862415 @@ -0,0 +1,130 @@ +permissions: 0.890 +graphic: 0.869 +user-level: 0.860 +risc-v: 0.825 +assembly: 0.819 +register: 0.805 +files: 0.803 +semantic: 0.801 +architecture: 0.795 +performance: 0.783 +vnc: 0.766 +arm: 0.759 +virtual: 0.755 +TCG: 0.749 +boot: 0.743 +PID: 0.736 +device: 0.725 +socket: 0.724 +mistranslation: 0.722 +peripherals: 0.706 +debug: 0.703 +network: 0.695 +kernel: 0.667 +KVM: 0.654 +hypervisor: 0.650 +i386: 0.623 +ppc: 0.605 +VMM: 0.602 +x86: 0.576 + +-nic user cannot receive TFTP response from outside on windows 10 host + +Configuration: +qemu is on a windows 10 host, address 192.168.1.24 +A tftp server, which is atftpd, is at address 192.168.1.31 +a guest is started by: +``` +.\qemu-system-x86_64.exe -accel hax \ +-nic user,id=n1,tftp-server-name=192.168.1.31,bootfile=tftp://192.168.1.31/grub/i386-pc/core.0 \ +-object filter-dump,id=f1,netdev=n1,file=dump.dat +``` + +qemu v4.2.0-11797-g2890edc853-dirty, from https://qemu.weilnetz.de/w64/ +windows 10 1909 18363.628 + +Here is the captured traffic from dump.dat, no filter applied: +No. Time Source Destination Protocol Length Info +1 0.000000 0.0.0.0 255.255.255.255 DHCP 439 DHCP Discover - Transaction ID 0xdb38340e +2 0.000081 10.0.2.2 255.255.255.255 DHCP 590 DHCP Offer - Transaction ID 0xdb38340e +3 1.035670 0.0.0.0 255.255.255.255 DHCP 439 DHCP Discover - Transaction ID 0xdb38340e +4 1.035693 10.0.2.2 255.255.255.255 DHCP 590 DHCP Offer - Transaction ID 0xdb38340e +5 3.068055 0.0.0.0 255.255.255.255 DHCP 451 DHCP Request - Transaction ID 0xdb38340e +6 3.068099 10.0.2.2 255.255.255.255 DHCP 590 DHCP ACK - Transaction ID 0xdb38340e +7 3.068209 RealtekU_12:34:56 Broadcast ARP 42 ARP Announcement for 10.0.2.15 +8 3.148419 RealtekU_12:34:56 Broadcast ARP 42 Who has 10.0.2.2? Tell 10.0.2.15 +9 3.148449 52:55:0a:00:02:02 RealtekU_12:34:56 ARP 64 10.0.2.2 is at 52:55:0a:00:02:02 +10 3.148511 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +11 3.398093 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +12 3.946041 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +13 4.990262 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14 7.022839 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +15 11.087041 10.0.2.15 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 + + +Here is the captured traffic at host NIC, filered by from or to 192.168.1.31 +No. Time Source Destination Protocol Length Info +14140 57.729066 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14141 57.732988 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14255 57.977995 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14256 57.979876 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14275 58.525939 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14276 58.527819 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14328 59.570178 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14329 59.581024 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14383 61.602742 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14384 61.605554 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14730 62.736572 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14741 62.987924 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14756 63.533477 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14815 64.577653 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +14916 65.666959 192.168.1.24 192.168.1.31 TFTP 91 Read Request, File: grub/i386-pc/core.0, Transfer type: octet, blksize=1432, tsize=0 +14917 65.668778 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15235 66.615186 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15481 67.745250 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15509 67.991523 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +15566 68.539050 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +16691 69.583531 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17457 70.675366 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17599 71.615337 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +17904 72.747338 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18012 72.995681 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18192 73.544257 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18360 74.588002 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +18981 75.679037 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19270 76.620528 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19839 77.752338 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19852 78.001267 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +19917 78.548965 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20066 79.593232 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20140 80.684604 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20220 81.625996 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20537 82.824574 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20551 83.033318 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20607 83.555510 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20734 84.598612 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20816 85.691535 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +20898 86.631036 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 +22311 90.695296 192.168.1.31 192.168.1.24 TFTP 69 Option Acknowledgement, tsize=45542, blksize=1432 + +From the traffic, the guest sent the request properly, and it is rerouted outside properly, and the server respond to it properly. However, the guest never received the response. + + + + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/1865160 b/results/classifier/118/permissions/1865160 new file mode 100644 index 00000000..29c3d128 --- /dev/null +++ b/results/classifier/118/permissions/1865160 @@ -0,0 +1,109 @@ +permissions: 0.919 +KVM: 0.911 +register: 0.904 +semantic: 0.904 +performance: 0.899 +graphic: 0.891 +peripherals: 0.876 +assembly: 0.872 +architecture: 0.852 +kernel: 0.845 +hypervisor: 0.839 +ppc: 0.834 +arm: 0.831 +virtual: 0.831 +risc-v: 0.830 +PID: 0.820 +TCG: 0.819 +debug: 0.798 +boot: 0.796 +vnc: 0.794 +VMM: 0.785 +device: 0.780 +x86: 0.770 +user-level: 0.743 +files: 0.735 +socket: 0.708 +mistranslation: 0.683 +network: 0.636 +i386: 0.554 + +Unpredictable behaviour resulting in User process faults + +An example of the behaviour can be reproduced when using NPM, whereby running the command multiple times will result in a variety of error conditions causing the command to fail: + +Example of failure: + +Segmentation fault.] / rollbackFailedOptional: verb npm-session 1a805a5e0ff7b8f5 + +[ 3144.216869] User process fault: interruption code 0038 ilc:3 +[ 3144.216981] Failing address: 66616c7365000000 TEID: 66616c7365000800 +[ 3144.217009] Fault in primary space mode while using user ASCE. +[ 3144.217055] AS:00000000ed28c1c7 R3:0000000000000024 + +Feb 28 14:32:08 qemus390x kernel: [ 3144.216869] User process fault: interruption code 0038 ilc:3 +Feb 28 14:32:08 qemus390x kernel: [ 3144.216981] Failing address: 66616c7365000000 TEID: 66616c7365000800 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217009] Fault in primary space mode while using user ASCE. +Feb 28 14:32:08 qemus390x kernel: [ 3144.217055] AS:00000000ed28c1c7 R3:0000000000000024 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217217] CPU: 2 PID: 1018 Comm: npm Not tainted 4.15.0-88-generic #88-Ubuntu +Feb 28 14:32:08 qemus390x kernel: [ 3144.217234] Hardware name: QEMU 2964 QEMU (KVM/Linux) +Feb 28 14:32:08 qemus390x kernel: [ 3144.217257] User PSW : 00000000185db982 00000000c1d5a1a1 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217290] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217322] User GPRS: 000002aa03705200 0000006a16d73ac1 0000003da4b829f1 0000000000000000 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217343] 0000003da4b82a08 0000003da4b82a08 000002aa036a92ec 0000000000000000 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217364] 0000003da4b829f1 000003ffdb8f7e50 0000003da4b82a08 000003ffdb8f7d88 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217385] 66616c7365000000 000002aa036a05b0 000002aa015bcfb2 000003ffdb8f7d88 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] User Code:#0000006a16d73b00: c0f4000000df brcl 15,0000006a16d73cbe +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] >0000006a16d73b06: a7290000 lghi %r2,0 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b0a: 07fe bcr 15,%r14 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b0c: c02f000001f3 llilf %r2,499 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b12: e3d0dff8ff71 lay %r13,-8(%r13) +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b18: e320d0000024 stg %r2,0(%r13) +Feb 28 14:32:08 qemus390x kernel: [ 3144.217512] 0000006a16d73b1e: c028000002aa iihf %r2,682 +Feb 28 14:32:08 qemus390x kernel: [ 3144.217724] Last Breaking-Event-Address: +Feb 28 14:32:08 qemus390x kernel: [ 3144.217759] [<000002aa015bcfae>] 0x2aa015bcfae + + + + +QEMU emulator version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +QEMU Command: + +sudo qemu-system-s390x -smp cpus=5 -machine s390-ccw-virtio -cpu max,zpci=on -serial telnet::4441,server -display none -m 4096 -net nic -net tap -drive file=ubuntu.root,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-ccw,devno=fe.0.0003,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=100,scsi=off -drive file=ubuntu.home,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1,scsi=off -drive file=ubuntu.swap,if=none,id=drive-virtio-disk4,format=raw,cache=none -device virtio-blk-ccw,devno=fe.0.0005,drive=drive-virtio-disk4,id=virtio-disk4,bootindex=101,scsi=off + + +Ubuntu 18.04.4 LTS qemus390x ttysclp0 + +Recreate with 20.04 LTS (GNU/Linux 5.4.0-26-generic s390x) + + +May 6 16:14:47 qemu2004 kernel: [86269.521861] User process fault: interruption code 0038 ilc:1 +May 6 16:14:47 qemu2004 kernel: [86269.521943] Failing address: 6563746de40b6000 TEID: 6563746de40b6800 +May 6 16:14:47 qemu2004 kernel: [86269.521961] Fault in primary space mode while using user ASCE. +May 6 16:14:47 qemu2004 kernel: [86269.521994] AS:00000001cc8581c7 R3:0000000000000024 +May 6 16:14:47 qemu2004 kernel: [86269.522113] CPU: 2 PID: 19249 Comm: npm Not tainted 5.4.0-26-generic #30-Ubuntu +May 6 16:14:47 qemu2004 kernel: [86269.522127] Hardware name: QEMU 2964 QEMU (KVM/Linux) +May 6 16:14:47 qemu2004 kernel: [86269.522145] User PSW : 0705200180000000 6563746de40b6167 +May 6 16:14:47 qemu2004 kernel: [86269.522173] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 +May 6 16:14:47 qemu2004 kernel: [86269.522198] User GPRS: 0000000000000000 000000edc8ef86a1 6563746de40b6167 0000000000000000 +May 6 16:14:47 qemu2004 kernel: [86269.522214] 0000000001cfb968 00000004e40b6164 0000000001cfedec 00000004e40b6100 +May 6 16:14:47 qemu2004 kernel: [86269.522230] 0000000001cf60b0 000003fff32fbfb0 00000004e40b60e9 000003fff32fbee0 +May 6 16:14:47 qemu2004 kernel: [86269.522246] 0000000000000004 00000004e40b616c 000003ffaeb7c5a4 000003fff32fbe70 +May 6 16:14:47 qemu2004 kernel: [86269.522335] User Code: Bad PSW. +May 6 16:14:47 qemu2004 kernel: [86269.522350] Last Breaking-Event-Address: +May 6 16:14:47 qemu2004 kernel: [86269.522380] [<000000edc8ef8a28>] 0xedc8ef8a28 + + +Segmentation fault.] - rollbackFailedOptional: verb npm-session 6b1c07499474304d + + + +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/197 + + diff --git a/results/classifier/118/permissions/1867519 b/results/classifier/118/permissions/1867519 new file mode 100644 index 00000000..188b01e9 --- /dev/null +++ b/results/classifier/118/permissions/1867519 @@ -0,0 +1,280 @@ +permissions: 0.858 +user-level: 0.843 +semantic: 0.842 +register: 0.837 +architecture: 0.835 +socket: 0.830 +peripherals: 0.829 +risc-v: 0.826 +debug: 0.826 +ppc: 0.826 +performance: 0.819 +VMM: 0.810 +hypervisor: 0.805 +assembly: 0.801 +device: 0.791 +vnc: 0.787 +graphic: 0.776 +TCG: 0.773 +network: 0.773 +mistranslation: 0.766 +arm: 0.754 +PID: 0.751 +files: 0.750 +virtual: 0.744 +kernel: 0.726 +KVM: 0.721 +boot: 0.662 +x86: 0.644 +i386: 0.570 + +qemu 4.2 segfaults on VF detach + +After updating Ubuntu 20.04 to the Beta version, we get the following error and the virtual machines stucks when detaching PCI devices using virsh command: + +Error: +error: Failed to detach device from /tmp/vf_interface_attached.xml +error: internal error: End of file from qemu monitor + +steps to reproduce: + 1. create a VM over Ubuntu 20.04 (5.4.0-14-generic) + 2. attach PCI device to this VM (Mellanox VF for example) + 3. try to detaching the PCI device using virsh command: + a. create a pci interface xml file: + + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address type='pci' domain='0x0000' bus='0x11' slot='0x00' function='0x2' /> + </source> + </hostdev> + + b. #virsh detach-device <VM-Doman-name> <pci interface xml file> + + + +- Ubuntu release: + Description: Ubuntu Focal Fossa (development branch) + Release: 20.04 + +- Package ver: + libvirt0: + Installed: 6.0.0-0ubuntu3 + Candidate: 6.0.0-0ubuntu5 + Version table: + 6.0.0-0ubuntu5 500 + 500 http://il.archive.ubuntu.com/ubuntu focal/main amd64 Packages + *** 6.0.0-0ubuntu3 100 + 100 /var/lib/dpkg/status + +- What you expected to happen: + PCI device detached without any errors. + +- What happened instead: + getting the errors above and he VM stuck + +additional info: +after downgrading the libvirt0 package and all the dependent packages to 5.4 the previous, version, seems that the issue disappeared + +Hi Mohammad, +I'll to recreate your issue, but while that goes on I already would want to ask if you could report the following tracked while you try to detach the device: + +1. host dmesg -w +2. journalctl -f +3. /var/log/libvirt/qemu/<questname>.log + +Please report all these in case there is something that helps to pinpoint the root cause. + +Could you also please try more devices to know which kind this issue it restricted to? +1. try other VFs on the same device +2. try VFs on a different device (if you have any) +3. try non-VF but full PCI passthrough + +Does the issue occor on your system for all of these ? + +For the time being I only found a system with a full device to passthrough not a VF. +That worked fine for me, the guest gets the dev and can load its drivers. +[ 297.340525] mlx5_core 0000:00:08.0: Port module event: module 0, Cable unplugged +[ 297.361111] mlx5_core 0000:00:08.0: MLX5E: StrdRq(0) RqSz(1024) StrdSz(256) RxCqeCmprss(0) +[ 297.572313] mlx5_core 0000:00:08.0 ens8: renamed from eth0 + +But since that was "only" PCI-passthrough and not yet VFs I'm looking forward to your answers on your case. + +Once more thing you could track and report is the guests "dmesg -w" while trying to attach to see if there is anything appearing there or aborting much earlier. + +I got VFs enabled now, attach works fine as well. + +But I can confirm that detach breaks it. + +XML used for the device: + <interface type='hostdev' managed='yes'> + <driver name='vfio'/> + <mac address='52:54:00:c3:0e:32'/> + <source> + <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x2'/> + </source> + </interface> + +$ virsh detach-device focal-pttest VF-pass-through.xml +error: Failed to detach device from VF-pass-through.xml +error: internal error: End of file from qemu monitor + +Logs: +1. Guest dmesg (doesn't exist as it dies immediately). + +2. qemu log: +2020-03-18 11:02:18.221+0000: shutting down, reason=crashed + +This one is interesting, Host dmesg: +[ 5819.223023] CPU 0/KVM[2763]: segfault at 0 ip 000055d37b4b245d sp 00007f2f5fffe188 error 6 in qemu-system-x86_64[55d37b008000+529000] +[ 5819.223030] Code: 08 48 89 50 10 48 89 37 48 89 7e 10 c3 f3 0f 1e fa 48 8b 47 08 48 8b 57 10 48 85 c0 74 0c 48 89 50 10 48 8b 57 10 48 8b 47 08 <48> 89 02 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e + +Afterwards I see the device come back to the host, but the segfault is the reason it died. + +I re-run the above, full PCI passthrough still attaches/detaches fine. + +VFs attach fine +VFs break on detach + +I've thrown qemu into GDB and this is the backtrace +Thread 4 "CPU 0/KVM" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7f82f0e31700 (LWP 3998)] +0x000055d2f322d45d in notifier_remove (notifier=notifier@entry=0x55d2f40c5078) at ./util/notify.c:31 +31 QLIST_REMOVE(notifier, node); +(gdb) bt +#0 0x000055d2f322d45d in notifier_remove (notifier=notifier@entry=0x55d2f40c5078) at ./util/notify.c:31 +#1 0x000055d2f2df8df9 in kvm_irqchip_remove_change_notifier (n=n@entry=0x55d2f40c5078) at ./accel/kvm/kvm-all.c:1409 +#2 0x000055d2f2e56989 in vfio_exitfn (pdev=<optimized out>) at ./hw/vfio/pci.c:3079 +#3 0x000055d2f3025c1b in pci_qdev_unrealize (dev=<optimized out>, errp=<optimized out>) at ./hw/pci/pci.c:1131 +#4 0x000055d2f2f8c6e2 in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x0) at ./hw/core/qdev.c:932 +#5 0x000055d2f312449b in property_set_bool (obj=0x55d2f40c4430, v=<optimized out>, name=<optimized out>, opaque=0x55d2f4083ee0, errp=0x0) at ./qom/object.c:2078 +#6 0x000055d2f3128c84 in object_property_set_qobject (obj=obj@entry=0x55d2f40c4430, value=value@entry=0x7f82dc2f7130, name=name@entry=0x55d2f330d85d "realized", errp=errp@entry=0x0) + at ./qom/qom-qobject.c:26 +#7 0x000055d2f31264ba in object_property_set_bool (obj=0x55d2f40c4430, value=<optimized out>, name=0x55d2f330d85d "realized", errp=0x0) at ./qom/object.c:1336 +#8 0x000055d2f2f56bca in acpi_pcihp_device_unplug_cb (hotplug_dev=<optimized out>, s=<optimized out>, dev=0x55d2f40c4430, errp=<optimized out>) at ./hw/acpi/pcihp.c:269 +#9 0x000055d2f2f56253 in acpi_pcihp_eject_slot (s=<optimized out>, bsel=<optimized out>, slots=slots@entry=256) at ./hw/acpi/pcihp.c:170 +#10 0x000055d2f2f56383 in pci_write (size=<optimized out>, data=256, addr=8, opaque=<optimized out>) at ./hw/acpi/pcihp.c:341 +#11 pci_write (opaque=<optimized out>, addr=<optimized out>, data=256, size=<optimized out>) at ./hw/acpi/pcihp.c:332 +#12 0x000055d2f2de9cfb in memory_region_write_accessor (mr=mr@entry=0x55d2f4780970, addr=8, value=value@entry=0x7f82f0e304f8, size=size@entry=4, shift=<optimized out>, + mask=mask@entry=4294967295, attrs=...) at ./memory.c:483 +#13 0x000055d2f2de79ee in access_with_adjusted_size (addr=addr@entry=8, value=value@entry=0x7f82f0e304f8, size=size@entry=4, access_size_min=<optimized out>, + access_size_max=<optimized out>, access_fn=access_fn@entry=0x55d2f2de9bd0 <memory_region_write_accessor>, mr=0x55d2f4780970, attrs=...) at ./memory.c:544 +#14 0x000055d2f2debfc3 in memory_region_dispatch_write (mr=mr@entry=0x55d2f4780970, addr=8, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ./memory.c:1475 +#15 0x000055d2f2d96a30 in flatview_write_continue (fv=fv@entry=0x7f82dc14bbc0, addr=addr@entry=44552, attrs=..., buf=buf@entry=0x7f82f17e9000 "", len=len@entry=4, addr1=<optimized out>, + l=<optimized out>, mr=0x55d2f4780970) at ./include/qemu/host-utils.h:164 +#16 0x000055d2f2d96c46 in flatview_write (fv=0x7f82dc14bbc0, addr=44552, attrs=..., buf=0x7f82f17e9000 "", len=4) at ./exec.c:3169 +#17 0x000055d2f2d9b01f in address_space_write (as=as@entry=0x55d2f3956960 <address_space_io>, addr=addr@entry=44552, attrs=..., buf=<optimized out>, len=len@entry=4) at ./exec.c:3259 +#18 0x000055d2f2d9b09e in address_space_rw (as=as@entry=0x55d2f3956960 <address_space_io>, addr=addr@entry=44552, attrs=..., attrs@entry=..., buf=<optimized out>, len=len@entry=4, + is_write=is_write@entry=true) at ./exec.c:3269 +#19 0x000055d2f2dfc94f in kvm_handle_io (count=1, size=4, direction=<optimized out>, data=<optimized out>, attrs=..., port=44552) at ./accel/kvm/kvm-all.c:2104 +#20 kvm_cpu_exec (cpu=cpu@entry=0x55d2f3dc9090) at ./accel/kvm/kvm-all.c:2350 +#21 0x000055d2f2dde53e in qemu_kvm_cpu_thread_fn (arg=0x55d2f3dc9090) at ./cpus.c:1318 +#22 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x55d2f3dc9090) at ./cpus.c:1290 +#23 0x000055d2f321fe13 in qemu_thread_start (args=<optimized out>) at ./util/qemu-thread-posix.c:519 +#24 0x00007f82f4290609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#25 0x00007f82f41b7153 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +I changed the bug task to Qemu (Ubuntu) as this isn't a libvirt error. + +I also added an upstream qemu task in case this is a known issue for the developers there. Someone might be able to point us at a known discussion/fix. + +The Backtrace I added in the last comment should help to identify known cases. + +Hi Christian, + +yes that exactly what we see in our tests, +so are the logs that you asked for in comment#1 still needed? +also if you fix it can you please provide us a link for a package or even a workaround until the issue resolved, since this issue stuck our QA from testing ASAP over Focal. + +At the breaking function we have: + +29 void notifier_remove(Notifier *notifier) +30 { +31 QLIST_REMOVE(notifier, node); +32 } + + + +(gdb) p notifier +$1 = (Notifier *) 0x55d2f40c5078 +(gdb) p *notifier +$2 = {notify = 0x0, node = {le_next = 0x0, le_prev = 0x0}} + +And since QLIST_REMOVE is defined as: +140 #define QLIST_REMOVE(elm, field) do { \ +141 if ((elm)->field.le_next != NULL) \ +142 (elm)->field.le_next->field.le_prev = \ +143 (elm)->field.le_prev; \ +144 *(elm)->field.le_prev = (elm)->field.le_next; \ +145 } while (/*CONSTCOND*/0) + +(gdb) p (notifier)->node.le_next +$5 = (struct Notifier *) 0x0 +(gdb) p &(notifier->node) +$11 = (struct {...} *) 0x55d2f40c5080 + +There actually is a != NULL check, might it have changed on the fly. +I need to look at it more thoroughly, but it should be enough to recognize a known issue. + +Might be https://git.qemu.org/?p=qemu.git;a=commit;h=0446f8121723b134ca1d1ed0b73e96d4a0a8689d + +This would also match the backtrace path. + +That commit you mention is confirmed to solve a bug reported against Fedora with almost the same stack trace you see here. + +Hi Christian, + +Yes, +seems that the patch you mentioned fixing the issue i rebuilt the qemu with the patch and it's work fine now. +Thank you guys. + + +I regularly before a release pull in fixes that were posted for qemu-stable. +This is one of them, I'll again do such a build and retest this issue with it. + +I identified and backported (only one needed modification) 33 patches. +But as usual there might be some context needed on top - I have build that over night in [1] + +Testing that on my reproducer + +Attach-host: +[84652.671123] vfio-pci 0000:08:00.2: enabling device (0000 -> 0002) + +Attach-guest: +[ 45.199920] pci 0000:00:08.0: [15b3:1016] type 00 class 0x020000 +[ 45.200374] pci 0000:00:08.0: reg 0x10: [mem 0x00000000-0x000fffff 64bit pref] +[ 45.201358] pci 0000:00:08.0: enabling Extended Tags +[ 45.202726] pci 0000:00:08.0: 0.000 Gb/s available PCIe bandwidth, limited by Unknown speed x0 link at 0000:00:08.0 (capable of 63.008 Gb/s with 8 GT/s x8 link) +[ 45.208316] pci 0000:00:08.0: BAR 0: assigned [mem 0x100000000-0x1000fffff 64bit pref] +[ 45.256566] mlx5_core 0000:00:08.0: enabling device (0000 -> 0002) +[ 45.262103] mlx5_core 0000:00:08.0: firmware version: 14.27.1016 +[ 45.544010] mlx5_core 0000:00:08.0: MLX5E: StrdRq(0) RqSz(1024) StrdSz(256) RxCqeCmprss(0) +[ 45.710123] mlx5_core 0000:00:08.0 ens8: renamed from eth0 +[ 60.992547] random: crng init done +[ 60.992552] random: 3 urandom warning(s) missed due to ratelimiting + +Detach-host: +[84926.767411] mlx5_core 0000:08:00.2: enabling device (0000 -> 0002) +[84926.767514] mlx5_core 0000:08:00.2: firmware version: 14.27.1016 +[84927.036146] mlx5_core 0000:08:00.2: MLX5E: StrdRq(0) RqSz(1024) StrdSz(256) RxCqeCmprss(0) +[84927.208523] mlx5_core 0000:08:00.2 ens1v1: renamed from eth0 + +Detach-guest: +<nothing> + + +So yes, these changes fix the issue here (and a bunch of others). +I'll open up an MP to get these changes into Ubuntu 20.04. + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3981 + +This bug was fixed in the package qemu - 1:4.2-3ubuntu3 + +--------------- +qemu (1:4.2-3ubuntu3) focal; urgency=medium + + * d/p/stable/lp-1867519-*: Stabilize qemu 4.2 with upstream + patches @qemu-stable (LP: #1867519) + + -- Christian Ehrhardt <email address hidden> Wed, 18 Mar 2020 13:57:57 +0100 + diff --git a/results/classifier/118/permissions/1868055 b/results/classifier/118/permissions/1868055 new file mode 100644 index 00000000..6ffe3eee --- /dev/null +++ b/results/classifier/118/permissions/1868055 @@ -0,0 +1,166 @@ +permissions: 0.825 +user-level: 0.782 +peripherals: 0.756 +semantic: 0.689 +virtual: 0.680 +hypervisor: 0.654 +ppc: 0.653 +register: 0.613 +debug: 0.579 +risc-v: 0.574 +mistranslation: 0.563 +device: 0.562 +VMM: 0.556 +architecture: 0.547 +graphic: 0.530 +performance: 0.525 +arm: 0.523 +assembly: 0.518 +network: 0.507 +PID: 0.507 +TCG: 0.492 +vnc: 0.487 +boot: 0.476 +files: 0.469 +KVM: 0.426 +socket: 0.415 +kernel: 0.358 +i386: 0.217 +x86: 0.204 + +cannot run golang app with docker, version 17.09.1-ce, disabling core 0 and qemu-arm, version 2.7. + +Hello! +I figure out that sometimes simple go application is not working. +I am using docker + qemu-arm + go( for armv7l). + +These are version info below. + +root@VDBS1535:~# docker -v +Docker version 17.09.1-ce, build 19e2cf6 + +bash-3.2# qemu-arm --version +qemu-arm version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +$ go version +go version go1.12.6 linux/arm +$ go env +GOARCH="arm" +GOBIN="" +GOCACHE="/home/quickbuild/.cache/go-build" +GOEXE="" +GOFLAGS="" +GOHOSTARCH="arm" +GOHOSTOS="linux" +GOOS="linux" +GOPATH="/home/quickbuild/go" +GOPROXY="" +GORACE="" +GOROOT="/usr/lib/golang" +GOTMPDIR="" +GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_arm" +GCCGO="gccgo" +GOARM="7" +CC="gcc" +CXX="g++" +CGO_ENABLED="1" +GOMOD="" +CGO_CFLAGS="-g -O2" +CGO_CPPFLAGS="" +CGO_CXXFLAGS="-g -O2" +CGO_FFLAGS="-g -O2" +CGO_LDFLAGS="-g -O2" +PKG_CONFIG="pkg-config" +GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build242285369=/tmp/go-build -gno-record-gcc-switches" + +This issue is come only when I disable core 0 using a command below. +please check "--cpuset-cpus=1-55" option. + +sudo docker run --privileged -d -i -t --cpuset-cpus=1-55 --mount type=bind,source="/home/dw83kim/mnt",destination="/mnt" --network host --name="ubuntu_core1" ubuntu:xenial-20200212 + + +This is what I have tested in the environment above. + +package main +func main(){ + for i:=0; i<1000; i++ { + println("Hello world") + } +} + +This is one of the error logs have faced sometimes not always. + +bash-3.2# go run test.go +fatal error: schedule: holding locks +panic during panic +SIGILL: illegal instruction +PC=0xc9ec4c m=3 sigcode=2 + +goroutine 122 [runnable]: +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +bash-3.2# + +Please check it. +Thanks in advance. + +This is a known and fixed bug in QEMU. Please try a more recent version than 2.7 (eg 4.2, which is the most recent release). + + +Could you retest with latest version (4.2.0) of QEMU? + +LP:1696773 is the old bug that I think is probably the cause here, though 2.7 is old enough it has a bunch of other linux-user race condition bugs that we've since fixed. + + +Hello! Peter and Laurent, +Thanks for your kind & rapid reply. + +It took long to merge the patch Peter mentioned. +After applying the patch the problem is gone but I found new issue. + +When I had tried to test for the first time after making new docker container it took much longer time. + + +bash-3.2# time go run test.go +Hello world + +real 5m3.516s +user 5m48.696s +sys 13m32.600s +bash-3.2# time go run test.go +Hello world + +real 0m1.784s +user 0m2.339s +sys 0m1.742s +bash-3.2# time go run test.go +Hello world + +real 0m1.881s +user 0m2.302s +sys 0m1.926s +bash-3.2# pwd + +I believe that 5 min for just printing "Hello world" is not your expectation. + +Is it also known issue? +Please check it. + +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/118/permissions/1873 b/results/classifier/118/permissions/1873 new file mode 100644 index 00000000..80f41514 --- /dev/null +++ b/results/classifier/118/permissions/1873 @@ -0,0 +1,114 @@ +permissions: 0.885 +mistranslation: 0.859 +semantic: 0.828 +TCG: 0.757 +virtual: 0.757 +register: 0.757 +device: 0.755 +peripherals: 0.752 +user-level: 0.747 +graphic: 0.742 +VMM: 0.742 +network: 0.741 +socket: 0.736 +debug: 0.732 +architecture: 0.731 +performance: 0.721 +KVM: 0.720 +assembly: 0.713 +hypervisor: 0.707 +x86: 0.703 +ppc: 0.699 +PID: 0.691 +risc-v: 0.657 +boot: 0.634 +vnc: 0.628 +kernel: 0.611 +arm: 0.602 +i386: 0.561 +files: 0.509 + +igb driver failed to change MTU +Description of problem: +I am using the new IGB model to test sriov inside a virtual machine. + +and when the operator tries to configure MTU of 9000 on the VF I get a kernel crash and the node goes into reboot + +``` +virsh console virt-cluster-worker-0 +Connected to domain 'virt-cluster-worker-0' +Escape character is ^] (Ctrl + ]) +[ 486.776188] kernel BUG at include/linux/skbuff.h:2420! +[ 486.779661] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +[ 486.781938] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.0-284.16.1.el9_2.x86_64 #1 +[ 486.783847] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 486.785681] RIP: 0010:eth_type_trans+0xd3/0x140 +[ 486.787051] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 +[ 486.790542] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283 +[ 486.791726] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028 +[ 486.793086] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600 +[ 486.794430] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980 +[ 486.795779] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001 +[ 486.797132] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000 +[ 486.798499] FS: 0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000 +[ 486.800325] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 486.801520] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0 +[ 486.802856] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 486.804171] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 486.805459] PKRU: 55555554 +[ 486.806291] Call Trace: +[ 486.807083] <IRQ> +[ 486.807822] igbvf_clean_rx_irq.constprop.0.isra.0+0x1b4/0x600 [igbvf] +[ 486.809027] igbvf_poll+0x3d/0x210 [igbvf] +[ 486.809981] __napi_poll+0x27/0x170 +[ 486.810886] net_rx_action+0x233/0x2f0 +[ 486.811777] __do_softirq+0xc7/0x2ac +[ 486.812644] __irq_exit_rcu+0xb5/0xe0 +[ 486.813515] common_interrupt+0x80/0xa0 +[ 486.814404] </IRQ> +[ 486.815113] <TASK> +[ 486.815800] asm_common_interrupt+0x22/0x40 +[ 486.816710] RIP: 0010:default_idle+0x10/0x20 +[ 486.817631] Code: cc 0f ae f0 0f ae 38 0f ae f0 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 66 90 0f 00 2d 7e 3e 4d 00 fb f4 <c3> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 65 +[ 486.820523] RSP: 0018:ffffaef2000afed0 EFLAGS: 00000246 +[ 486.821705] RAX: ffffffff99f36ea0 RBX: ffff90bb4032a300 RCX: ffff90bd581f2430 +[ 486.822936] RDX: 000000000013bd13 RSI: 0000000000000001 RDI: 000000000013bd14 +[ 486.824165] RBP: 0000000000000000 R08: 0000007155e9e493 R09: ffff90bb437f4800 +[ 486.825374] R10: 0000000000000232 R11: 0000000000000000 R12: 0000000000000000 +[ 486.826581] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 486.827777] ? mwait_idle+0x80/0x80 +[ 486.828593] default_idle_call+0x33/0xe0 +[ 486.829479] cpuidle_idle_call+0x15d/0x1c0 +[ 486.830381] ? kvm_sched_clock_read+0x14/0x40 +[ 486.831289] do_idle+0x7b/0xe0 +[ 486.832035] cpu_startup_entry+0x19/0x20 +[ 486.833076] start_secondary+0x116/0x140 +[ 486.834527] secondary_startup_64_no_verify+0xe5/0xeb +[ 486.835953] </TASK> +[ 486.836991] Modules linked in: igbvf veth ipt_REJECT nf_reject_ipv4 xt_nat xt_CT vhost_net vhost vhost_iotlb tap tun nf_conntrack_netlink tls xt_MASQUERADE nft_chain_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables rfkill geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 overlay ext4 mbcache jbd2 intel_rapl_msr intel_rapl_common isst_if_common nfit libnvdimm kvm_intel kvm irqbypass rapl iTCO_wdt iTCO_vendor_support cirrus drm_shmem_helper drm_kms_helper pcspkr i2c_i801 syscopyarea sysfillrect i2c_smbus sysimgblt virtio_balloon lpc_ich fb_sys_fops joydev ip_tables drm xfs libcrc32c dm_multipath sr_mod cdrom sg igb nvme_tcp ahci nvme_fabrics nvme libahci nvme_core virtio_net crct10dif_pclmul libata i2c_algo_bit crc32_pclmul dca virtio_console net_failover nvme_common virtio_blk t10_pi crc32c_intel failover ghash_clmulni_intel serio_raw dm_mirror dm_region_hash dm_log dm_mod fuse +[ 486.852907] ---[ end trace d1f9cdb1a6c92411 ]--- +[ 486.854263] RIP: 0010:eth_type_trans+0xd3/0x140 +[ 486.855234] Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 +[ 486.858732] RSP: 0018:ffffaef200114e30 EFLAGS: 00010283 +[ 486.859777] RAX: 000000000000002e RBX: ffffaef206a38000 RCX: 0000000000000028 +[ 486.861020] RDX: ffff90bb7767a840 RSI: ffff90bc7d6a0000 RDI: ffff90bb413bc600 +[ 486.862238] RBP: ffff90bb413bc600 R08: 0000000000000000 R09: ffff90bc7d6a0980 +[ 486.863478] R10: 000000000000003c R11: 00000001a8be8000 R12: 0000000000000001 +[ 486.864718] R13: 0000000000000003 R14: ffff90bd3b94e400 R15: ffff90bdcbc8c000 +[ 486.865969] FS: 0000000000000000(0000) GS:ffff90beafc40000(0000) knlGS:0000000000000000 +[ 486.867317] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 486.868458] CR2: 00007faf740ec058 CR3: 000000010a40c004 CR4: 0000000000770ee0 +[ 486.869705] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 486.870959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 486.872212] PKRU: 55555554 +[ 486.873040] Kernel panic - not syncing: Fatal exception in interrupt +[ 486.875441] Kernel Offset: 0x18400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +[ 486.877044] Rebooting in 10 seconds.. +``` +Steps to reproduce: +1. create a vm using igb driver for the network interface +2. change the MTU of the PF to 9000 +3. allocate virtual functions +4. change the MTU on the virtual function (vm crash) +Additional information: + diff --git a/results/classifier/118/permissions/1873769 b/results/classifier/118/permissions/1873769 new file mode 100644 index 00000000..5d23f1ad --- /dev/null +++ b/results/classifier/118/permissions/1873769 @@ -0,0 +1,118 @@ +permissions: 0.928 +mistranslation: 0.876 +user-level: 0.852 +semantic: 0.850 +register: 0.848 +risc-v: 0.847 +virtual: 0.842 +architecture: 0.835 +arm: 0.834 +VMM: 0.832 +device: 0.820 +peripherals: 0.815 +network: 0.813 +hypervisor: 0.808 +assembly: 0.802 +TCG: 0.799 +debug: 0.796 +graphic: 0.791 +PID: 0.787 +ppc: 0.783 +i386: 0.760 +vnc: 0.757 +boot: 0.695 +performance: 0.693 +kernel: 0.691 +socket: 0.677 +KVM: 0.633 +x86: 0.621 +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/118/permissions/1875012 b/results/classifier/118/permissions/1875012 new file mode 100644 index 00000000..8d5c2141 --- /dev/null +++ b/results/classifier/118/permissions/1875012 @@ -0,0 +1,155 @@ +permissions: 0.906 +mistranslation: 0.903 +graphic: 0.900 +semantic: 0.899 +user-level: 0.881 +debug: 0.876 +TCG: 0.873 +arm: 0.867 +PID: 0.866 +architecture: 0.866 +risc-v: 0.858 +device: 0.853 +ppc: 0.847 +assembly: 0.847 +boot: 0.846 +virtual: 0.839 +register: 0.833 +KVM: 0.822 +VMM: 0.818 +vnc: 0.808 +hypervisor: 0.785 +performance: 0.765 +files: 0.764 +peripherals: 0.761 +socket: 0.737 +network: 0.721 +kernel: 0.666 +i386: 0.658 +x86: 0.609 + +UC20 running in OVMF triggers qemu emulation error (cloudimage works fine on the same) + +Trying to boot a core20 amd64 image on an amd64 Eoan or Focal host via libvirt leads to: + +KVM internal error. Suberror: 1 +emulation failure +RAX=0000000000000000 RBX=000000003bdcd5c0 RCX=000000003ff1d030 RDX=00000000000019a0 +RSI=00000000000000ff RDI=000000003bd73ee0 RBP=000000003bd73e40 RSP=000000003ff1d1f8 +R8 =000000003df52168 R9 =0000000000000000 R10=ffffffffffffffff R11=000000003bd44c40 +R12=000000003bd76500 R13=000000003bd73e00 R14=0000000000020002 R15=000000003df4b483 +RIP=00000000000b0000 RFL=00210246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0038 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000003fbee698 00000047 +IDT= 000000003f2d8018 00000fff +CR0=80010033 CR2=0000000000000000 CR3=000000003fc01000 CR4=00000668 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d00 +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <ff> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + + + + + +Core20 image: http://cdimage.ubuntu.com/ubuntu-core/20/beta/pending/ubuntu-core-20-amd64.img.xz + + +Hmm, +we had a similar issue but that would not affect things back until Bionic as you reported it. +That was in bug 1866870 and fixed by a change in seabios. Also you reported Focal as affected wherer I fixed this particular one for sure. + +In general the error messages we have so far are not usually very helpful. That is more of a "class of errors" than a specific one to look at. Thanks for attaching the XML and image right away. + +In the past this also was dependent on the reporters CPU, so let's see if we can reproduce this for debugging. + +Ok I can reproduce + +One sees just quickly the bootloader flying by: + BdsDxe: loading Boot0001 "UEFI QEMU HARDDISK QM00005 " from + PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0) + BdsDxe: starting Boot0001 "UEFI QEMU HARDDISK QM00005 " from + PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0) + error: no such device: ubuntu-boot. +... and then it crashes. + +I was probing the major conditions to trigger - it seems to be only happening with the efi / ovmf boot. + +Changing the machine= or cpu model= had no impact, neither had a i440fx/q35 change. +But dropping from Efi to the default loader avoided the crash. There it also only worked to some extend - I mean it starts and does not crash. But the guest seems to insist/require UEFI as it doesn't go much further. I first thought the ovmf build might have a similar problem to what we have had in seabios, but then I tested non UC20. + +I also wanted to know if there is anything special in the UC20 image that is needed to trigger this and therefore booted a cloud image with OVMF. + +So I took a usual cloud-image based focal guest and added: + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram template='/usr/share/OVMF/OVMF_VARS.fd'/> + +And that works like a charm. So the issues seems to be triggered by something set up int hat UC20 image that you linked. It must do/trigger something that a cloud-image would not do on the same setup. + +The early boot messages differ - but that might be a red herring. +BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0) +BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0) +error: can't find command `hwmatch'. + +I don't even see the UC20 kernel initializing. +The next step is to know/learn what this image does differently. +How is this UC20 image special, what does it do special on init that other images don't do? +@Juergh do you now or do we need to reach out to mvo and others? + +Can someone help to dissect the UC20 image and what it does differently here? +The cloud-image boots with the same OVMF/Uefi based config, but UC20 runs into a crash. + +Understanding what the UC20 boot does differently and any chance to build that piece by piece (e.g. be able to skip some steps until we find the trigger) would be awesome. + +I subscribed MVO to help, but feel free to pull in others as you see fit. + +Until we got any further on this side I'm unsure what to do about Ubuntu unless you already know much more to help getting this forward. For now this is a bit like "I throw in this blob and it crashes", so helping to un-blobify seems to be the next step to me. Marking qemu task incomplete until we got a hold on this. + +The first thing that grub does when booting is: +loopback /snaps/pc-kernel_461.snap +which kills QEMU. + +In core20 that snap is on an 'EFI System' partition (vfat) whereas in core18 it's on a regular Linux (ext4) partition. + + +That should be: +loopback loop /snaps/pc-kernel_461.snap +in the previous commit #7. + +Ok it seems the kernel snap is causing this. Core20 grub can loopmount pc-kernel_455.snap (from a core18 image) just fine but kills QEMU when loopmounting pc-kernel_461.snap (the original core20 snap). + +Hrm. The core20 kernel snap is bigger than the core18 snap and increasing the VM memory to 2G seems to 'fix' this. I guess the question is is there a way to handle this more gracefully than killing QEMU? + + +I can confirm that with 2G the guest seems to start up now. + +I agree that this should be more graceful, but it has to be triggered by the guest. +So might the error path in the guest run into a dead-end if unable to load the kernel that then is like a illegal instruction to the host or something like that? + +Right now we don't know yet if it unpacks and then execute garbage OR fails even earlier. +We discussed this on IRC if grub might be placing it at a wrong offset making it need more memory, or some padding, or at unsquashing already ... + +We ended for now with: +[09:55] <juergh> cpaelzer, will dig into some more and let you know/update the ticket. +[09:56] <juergh> cpaelzer, maybe it's the unsquashing that kills it already + +Thanks in advance @Juergh for that! + +Maybe adding a bug task for the kernel snap and/or grub would be right, but let us find out more first. + +I've setup a UEFI core18 VM and dialed the memory all the way down to 256M but the loop mounting and loading of the kernel still works fine. + +Then I've copied grubx64.efi from the core18 image to the core20 image and now QEMU no longer crashes. So it looks like a change in grub between 2.02 and 2.04 in combination with UEFI and 'low' memory is causing this issue. + + +The Eoan Ermine has reached end of life, so this bug will not be fixed for that release + +The Eoan Ermine has reached end of life, so this bug will not be fixed for that release + diff --git a/results/classifier/118/permissions/1879425 b/results/classifier/118/permissions/1879425 new file mode 100644 index 00000000..44aeb5e7 --- /dev/null +++ b/results/classifier/118/permissions/1879425 @@ -0,0 +1,95 @@ +permissions: 0.963 +graphic: 0.941 +semantic: 0.938 +mistranslation: 0.923 +debug: 0.910 +user-level: 0.900 +register: 0.898 +risc-v: 0.888 +assembly: 0.887 +ppc: 0.863 +performance: 0.853 +socket: 0.850 +arm: 0.849 +PID: 0.846 +device: 0.845 +peripherals: 0.842 +vnc: 0.838 +virtual: 0.829 +architecture: 0.823 +hypervisor: 0.789 +files: 0.785 +VMM: 0.782 +TCG: 0.773 +network: 0.744 +boot: 0.707 +KVM: 0.666 +kernel: 0.621 +x86: 0.377 +i386: 0.264 + +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/118/permissions/1879955 b/results/classifier/118/permissions/1879955 new file mode 100644 index 00000000..c49f11c1 --- /dev/null +++ b/results/classifier/118/permissions/1879955 @@ -0,0 +1,92 @@ +permissions: 0.807 +semantic: 0.757 +graphic: 0.756 +hypervisor: 0.747 +risc-v: 0.736 +PID: 0.722 +i386: 0.706 +peripherals: 0.704 +TCG: 0.687 +x86: 0.681 +mistranslation: 0.680 +debug: 0.672 +virtual: 0.659 +socket: 0.658 +ppc: 0.637 +arm: 0.624 +user-level: 0.622 +performance: 0.621 +register: 0.620 +VMM: 0.618 +vnc: 0.585 +device: 0.577 +architecture: 0.571 +network: 0.561 +KVM: 0.539 +files: 0.509 +kernel: 0.509 +assembly: 0.475 +boot: 0.434 + +target/i386/seg_helper.c: 16-bit TSS struct format wrong? + +In target/i386/seg_helper.c:switch_tss_ra() we have the following code to load registers from a 16-bit TSS struct: + + /* 16 bit */ + new_cr3 = 0; + new_eip = cpu_lduw_kernel_ra(env, tss_base + 0x0e, retaddr); + new_eflags = cpu_lduw_kernel_ra(env, tss_base + 0x10, retaddr); + for (i = 0; i < 8; i++) { + new_regs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x12 + i * 2), + retaddr) | 0xffff0000; + } + for (i = 0; i < 4; i++) { + new_segs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x22 + i * 4), + retaddr); + } + new_ldt = cpu_lduw_kernel_ra(env, tss_base + 0x2a, retaddr); + +This doesn't match up with the structure described here: https://www.sandpile.org/x86/tss.htm -- which has only 2-byte slots for the segment registers. It also makes the 3rd segreg use the same offset as the LDTR, which is very suspicious. I suspect that this should use "(0x22 + i * 2)". + +The code later in the same function that stores the segment registers to the struct has the same bug. + +Found by code inspection; I don't have a test case to check this. As a non-x86-expert I'm just going to file a bug report in case somebody else feels like confirming the issue and sending a patch. + +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/382 + + diff --git a/results/classifier/118/permissions/1881552 b/results/classifier/118/permissions/1881552 new file mode 100644 index 00000000..068ef525 --- /dev/null +++ b/results/classifier/118/permissions/1881552 @@ -0,0 +1,87 @@ +permissions: 0.917 +architecture: 0.907 +graphic: 0.904 +register: 0.902 +debug: 0.881 +peripherals: 0.877 +assembly: 0.869 +hypervisor: 0.866 +performance: 0.865 +device: 0.865 +arm: 0.862 +semantic: 0.859 +PID: 0.837 +virtual: 0.826 +boot: 0.818 +files: 0.816 +user-level: 0.813 +ppc: 0.808 +VMM: 0.808 +risc-v: 0.799 +TCG: 0.797 +vnc: 0.792 +KVM: 0.781 +socket: 0.779 +network: 0.770 +kernel: 0.764 +mistranslation: 0.695 +x86: 0.695 +i386: 0.539 + +potential AArch64 ABI bug wrt handling of 128-bit bit-fields + +After upgrading to Ubuntu 20.04 LTS, GCC 9.3 displays a lot of notes: + +hw/block/pflash_cfi01.c: In function ‘pflash_mem_read_with_attrs’: +hw/block/pflash_cfi01.c:663:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 663 | static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr, uint64_t *value, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +hw/block/pflash_cfi01.c: In function ‘pflash_mem_write_with_attrs’: +hw/block/pflash_cfi01.c:677:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 677 | static MemTxResult pflash_mem_write_with_attrs(void *opaque, hwaddr addr, uint64_t value, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_mem_valid’: +hw/nvram/fw_cfg.c:475:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 475 | static bool fw_cfg_dma_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_data_mem_valid’: +hw/nvram/fw_cfg.c:483:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 483 | static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_ctl_mem_valid’: +hw/nvram/fw_cfg.c:501:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 501 | static bool fw_cfg_ctl_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_comb_valid’: +hw/nvram/fw_cfg.c:521:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 521 | static bool fw_cfg_comb_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_do_hyp_read’: +hw/intc/arm_gic.c:1996:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 1996 | static MemTxResult gic_do_hyp_read(void *opaque, hwaddr addr, uint64_t *data, + | ^~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_thiscpu_hyp_read’: +hw/intc/arm_gic.c:1979:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 1979 | static MemTxResult gic_thiscpu_hyp_read(void *opaque, hwaddr addr, uint64_t *data, + | ^~~~~~~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_get_current_pending_irq’: +hw/intc/arm_gic.c:419:17: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 419 | static uint16_t gic_get_current_pending_irq(GICState *s, int cpu, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This seems related to: +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 +https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=c590597c45 + + This is pretty unlikely in real code, but similar to Arm, the AArch64 + ABI has a bug with the handling of 128-bit bit-fields, where if the + bit-field dominates the overall alignment the back-end code may end up + passing the argument correctly. This is a regression that started in + gcc-6 when the ABI support code was updated to support overaligned + types. The fix is very similar in concept to the Arm fix. 128-bit + bit-fields are fortunately extremely rare, so I'd be very surprised if + anyone has been bitten by this. + +The warnings aren't a problem for QEMU because we don't expose these functions as public ABI, so the whole compile will be consistently built with the same compiler version. So we added -Wno-psabi in commit bac8d222a19f4a30d to silence the compiler here. + + diff --git a/results/classifier/118/permissions/1884425 b/results/classifier/118/permissions/1884425 new file mode 100644 index 00000000..b5374ee2 --- /dev/null +++ b/results/classifier/118/permissions/1884425 @@ -0,0 +1,72 @@ +user-level: 0.951 +permissions: 0.925 +network: 0.898 +graphic: 0.897 +vnc: 0.885 +architecture: 0.860 +device: 0.850 +boot: 0.832 +files: 0.828 +performance: 0.817 +peripherals: 0.807 +VMM: 0.806 +hypervisor: 0.800 +risc-v: 0.780 +PID: 0.780 +kernel: 0.777 +TCG: 0.760 +arm: 0.760 +semantic: 0.747 +KVM: 0.739 +mistranslation: 0.736 +register: 0.735 +socket: 0.709 +debug: 0.704 +ppc: 0.687 +assembly: 0.665 +virtual: 0.652 +x86: 0.566 +i386: 0.486 + +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/118/permissions/1885332 b/results/classifier/118/permissions/1885332 new file mode 100644 index 00000000..29bdab1e --- /dev/null +++ b/results/classifier/118/permissions/1885332 @@ -0,0 +1,386 @@ +permissions: 0.831 +architecture: 0.825 +debug: 0.825 +kernel: 0.813 +assembly: 0.813 +graphic: 0.811 +arm: 0.808 +register: 0.798 +semantic: 0.797 +device: 0.793 +virtual: 0.773 +risc-v: 0.769 +performance: 0.767 +PID: 0.765 +vnc: 0.731 +VMM: 0.731 +mistranslation: 0.723 +files: 0.720 +TCG: 0.716 +network: 0.714 +boot: 0.690 +user-level: 0.684 +ppc: 0.667 +KVM: 0.631 +socket: 0.626 +hypervisor: 0.595 +peripherals: 0.585 +x86: 0.580 +i386: 0.524 + +Error in user-mode calculation of ELF aux vector's AT_PHDR + + +I have an (admittedly strange) statically-linked ELF binary for Linux that runs just fine on top of the Linux kernel in QEMU full-system emulation, but crashes before main in user-mode emulation. Specifically, it crashes when initializing thread-local storage in glibc's _dl_aux_init, because it reads out a strange value from the AT_PHDR entry of the ELF aux vector. + +The binary has these program headers: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065874 0x00075874 0x00075874 0x00570 0x00570 R 0x4 + PHDR 0x0a3000 0x00900000 0x00900000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x00900000 0x00900000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65de8 0x65de8 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03f44 0x03f44 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +If I build the Linux kernel with the following patch to the very end of create_elf_tables in fs/binfmt_elf.c + + /* Put the elf_info on the stack in the right place. */ + elf_addr_t *my_auxv = (elf_addr_t *) mm->saved_auxv; + int i; + for (i = 0; i < 15; i++) { + printk("0x%x = 0x%x", my_auxv[2*i], my_auxv[(2*i)+ 1]); + } + if (copy_to_user(sp, mm->saved_auxv, ei_index * sizeof(elf_addr_t))) + return -EFAULT; + return 0; + +and run it like this: + + qemu-system-arm \ + -M versatilepb \ + -nographic \ + -dtb ./dts/versatile-pb.dtb \ + -kernel zImage \ + -M versatilepb \ + -m 128M \ + -append "earlyprintk=vga,keep" \ + -initrd initramfs + +after I've built the kernel initramfs like this (where "init" is the binary in question): + + make ARCH=arm versatile_defconfig + make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- all -j10 + cp "$1" arch/arm/boot/init + cd arch/arm/boot + echo init | cpio -o --format=newc > initramfs + +then I get the following output. This is the kernel's view of the aux vector for this binary: + + 0x10 = 0x1d7 + 0x6 = 0x1000 + 0x11 = 0x64 + 0x3 = 0x900000 + 0x4 = 0x20 + 0x5 = 0xb + 0x7 = 0x0 + 0x8 = 0x0 + 0x9 = 0x101b8 + 0xb = 0x0 + 0xc = 0x0 + 0xd = 0x0 + 0xe = 0x0 + 0x17 = 0x0 + 0x19 = 0xbec62fb5 + +However, if I run "qemu-arm -g 12345 binary" and use GDB to peek at the aux vector at the beginning of __libc_start_init (for example, using this Python GDB API script: https://gist.github.com/langston-barrett/5573d64ae0c9953e2fa0fe26847a5e1e), then I see the following values: + + AT_PHDR = 0xae000 + AT_PHENT = 0x20 + AT_PHNUM = 0xb + AT_PAGESZ = 0x1000 + AT_BASE = 0x0 + AT_FLAGS = 0x0 + AT_ENTRY = 0x10230 + AT_UID = 0x3e9 + AT_EUID = 0x3e9 + AT_GID = 0x3e9 + AT_EGID = 0x3e9 + AT_HWCAP = 0x1fb8d7 + AT_CLKTCK = 0x64 + AT_RANDOM = -0x103c0 + AT_HWCAP2 = 0x1f + AT_NULL = 0x0 + +The crucial difference is in AT_PHDR (0x3), which is indeed the virtual address of the PHDR segment when the kernel calculates it, but is not when QEMU calculates it. + +qemu-arm --version +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.26) + +I just confirmed that this is still a problem on git tag v5.0.0, where I applied the following: + + diff --git a/linux-user/elfload.c b/linux-user/elfload.c + index 619c054cc4..093656d059 100644 + --- a/linux-user/elfload.c + +++ b/linux-user/elfload.c + @@ -2016,6 +2016,7 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc, + /* There must be exactly DLINFO_ITEMS entries here, or the assert + * on info->auxv_len will trigger. + */ + + printf("PHDR: %x\n", (abi_ulong)(info->load_addr + exec->e_phoff)); + NEW_AUX_ENT(AT_PHDR, (abi_ulong)(info->load_addr + exec->e_phoff)); + NEW_AUX_ENT(AT_PHENT, (abi_ulong)(sizeof (struct elf_phdr))); + NEW_AUX_ENT(AT_PHNUM, (abi_ulong)(exec->e_phnum)); + +and saw: + + PHDR: ae000 + +Taking a peek at how Linux and QEMU calculate AT_PHDR for static binaries reveals the following. Both involve the program headers' offset (e_phoff) added to a value I'll call load_addr (as in the kernel). + +In the kernel, load_addr is + + elf_ppnt->p_vaddr - elf_ppnt->p_offset + +where elf_ppnt is the program header entry of the first segment with type LOAD: https://github.com/torvalds/linux/blob/242b23319809e05170b3cc0d44d3b4bd202bb073/fs/binfmt_elf.c#L1120 + +In QEMU, load_addr is set to an earlier value loaddr, which is set to + + min_i(phdr[i].p_vaddr - phdr[i].p_offset) + +where min_i is the minimum over indices "i" of LOAD segments. https://github.com/qemu/qemu/blob/9e7f1469b9994d910fc1b185c657778bde51639c/linux-user/elfload.c#L2407. If you perform this calculation by hand for the program headers posted at the beginning of this thread, you'll get ae000, as expected. + +The problem here is that QEMU takes a minimum where Linux just takes the first value. Presumably, changing QEMU's behavior to match that of the kernel wouldn't break anything that wouldn't be broken if it really ran on Linux. Unfortunately, Linux's ELF loader is much more picky than the ELF standard, but that's a whole other story... + +@langston0 Thanks for detailed explanation, got the same problem for qemu-s390. + + +The way to reproduce (linux kernel >= 4.8, for example: Ubuntu 18.04): +# Register qemu binfmt_misc handlers +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + +$ cat Dockerfile.s390x +FROM s390x/ubuntu +RUN apt-get update && \ + apt-get install -y \ + gcc make libpcre3-dev libreadline-dev + +RUN cd /home && git clone https://github.com/nginx/njs + +RUN cd /home/njs && ./configure --cc-opt='-O0 -static -lm -lrt -pthread -Wl,--whole-archive -lpthread -ltinfo -Wl,--no-whole-archive' && make njs + +$ docker build -t njs/390x -f Dockerfile.s390x . + +# check the binary (WORKS!) +# inside docker s390 binaries are executed using qemu-s390-static from the host +$ docker run -t njs/390x /home/njs/build/njs -c 'console.log("hello")' +hello + +# copy binary to host +$ docker run -v `pwd`:/m -ti njs/390x cp /home/njs/build/njs /m/njs-s390 + +# deregister binfmt handler +$ sudo bash -c "echo -1 > /proc/sys/fs/binfmt_misc/qemu-s390x" + +# run qemu gdb +$ qemu-s390x -g 12345 ./njs-s390 + +# in a separate terminal +$ gdb-multiarch ./njs-s390 -ex 'target remote localhost:12345' +0x0000000001000520 in _start () +(gdb) si +0x0000000001000524 in _start () +(gdb) si +0x000000000100052a in _start () +(gdb) c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x00000000011a418c in _dl_aux_init () +(gdb) bt +#0 0x00000000011a418c in _dl_aux_init () +#1 0x00000000011663f0 in __libc_start_main () +#2 0x0000000001000564 in _start () + +qemu-s390x --version +qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.28) + + + + +BTW, before "sudo bash -c "echo -1 > /proc/sys/fs/binfmt_misc/qemu-s390x" + +njs-s390 also works on the host: + +$ ./njs-s390 -c 'console.log("hello")' +hello + +$ file njs-s390 +njs-s390: ELF 64-bit MSB executable, IBM S/390, version 1 (GNU/Linux), statically linked, BuildID[sha1]=e37618578fb0a8c60f426826167a800e4f314ef3, for GNU/Linux 3.2.0, with debug_info, not stripped + +> runs just fine on top of the Linux kernel in QEMU full-system emulation, but crashes before main in user-mode emulation + +So it seems system vs user-mode is not the issue here, probably it is related to gdb mode in user-mode qemu. + +@Dimitry To confirm that this is really the same issue (and not an unrelated crash in the same function), could you post: + + 1. the ELF headers ("readelf -h"), + 2. the program headers ("readelf -l"), and + 3. the output (the AUX VECTOR section) from this GDB script (suitably modified for your program), when connecting to QEMU's GDB server? https://gist.github.com/langston-barrett/5573d64ae0c9953e2fa0fe26847a5e1e + +@Langston will do tomorrow. s390x ABI requires heavy changes to the python script. + +When I switch to armv7 the issue goes away + +$ cat Dockerfile.armv7 +FROM arm32v7/ubuntu +RUN apt-get update && \ + apt-get install -y \ + gcc make libpcre3-dev libreadline-dev git + +RUN cd /home && git clone https://github.com/nginx/njs + +RUN cd /home/njs && ./configure --cc-opt='-O0 -static -lm -lrt -pthread -Wl,--whole-archive -lpthread -ltinfo -Wl,--no-whole-archive' && make njs + +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build -t njs/armv7 -f Dockerfile.armv7 . +$ docker run -v `pwd`:/m -ti njs/armv7 cp /home/njs/build/njs /m/njs-armv7 + +$ readelf -l ./njs-armv7 + +Elf file type is EXEC (Executable file) +Entry point 0x12fb9 +There are 7 program headers, starting at offset 52 + +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x1be338 0x001ce338 0x001ce338 0x009b8 0x009b8 R 0x4 + LOAD 0x000000 0x00010000 0x00010000 0x1becf4 0x1becf4 R E 0x10000 + LOAD 0x1bedfc 0x001dedfc 0x001dedfc 0x17674 0x1c2cc RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x1bedfc 0x001dedfc 0x001dedfc 0x00038 0x00060 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 + GNU_RELRO 0x1bedfc 0x001dedfc 0x001dedfc 0x0e204 0x0e204 R 0x1 + + Section to Segment mapping: + Segment Sections... + 00 .ARM.exidx + 01 .note.ABI-tag .note.gnu.build-id .rel.dyn .init .iplt .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .stapsdt.base __libc_subfreeres __libc_IO_vtables __libc_atexit __libc_thread_subfreeres .ARM.extab .ARM.exidx .eh_frame + 02 .tdata .init_array .fini_array .data.rel.ro .got .data .bss __libc_freeres_ptrs + 03 .note.ABI-tag .note.gnu.build-id + 04 .tdata .tbss + 05 + 06 .tdata .init_array .fini_array .data.rel.ro + +$ readelf -h ./njs-armv7 +ELF Header: + Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - GNU + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0x12fb9 + Start of program headers: 52 (bytes into file) + Start of section headers: 5696248 (bytes into file) + Flags: 0x5000400, Version5 EABI, hard-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 7 + Size of section headers: 40 (bytes) + Number of section headers: 42 + Section header string table index: 41 + +$ qemu-arm -g 12345 ./njs-armv7 -c 'console.log("HH")' + +$ gdb-multiarch ./njs-armv7 -ex 'source showstack.py' +ARGUMENTS +--------- +argc = 3 +arg 0 = ./njs-armv7 +arg 1 = -c +arg 2 = console.log("HH") + +... + +AUX VECTOR +---------- +AT_PHDR = 10034 +AT_PHENT = 20 +AT_PHNUM = 7 +AT_PAGESZ = 1000 +AT_BASE = 0 +AT_FLAGS = 0 +AT_ENTRY = 12fb9 +AT_UID = 3e9 +AT_EUID = 3e9 +AT_GID = 3e9 +AT_EGID = 3e9 +AT_HWCAP = 1fb8d7 +AT_CLKTCK = 64 +AT_RANDOM = -104a0 +AT_HWCAP2 = 1f +AT_NULL = 0 + +$ qemu-arm --version +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.28) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Built the latest QEMU, the issue goes away + + +$ bin/debug/native/s390x-linux-user/qemu-s390x --version +qemu-s390x version 5.0.50 (v5.0.0-2358-g6c87d9f311-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +$ bin/debug/native/s390x-linux-user/qemu-s390x ../njs/njs-s390 -c 'console.log("HI")' +HI + +So my issue seems unrelated, sorry for bothering. + +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" 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 (but you won't be the reporter of the bug +in the new system and thus 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/275 + + diff --git a/results/classifier/118/permissions/1890312 b/results/classifier/118/permissions/1890312 new file mode 100644 index 00000000..0e03ee8b --- /dev/null +++ b/results/classifier/118/permissions/1890312 @@ -0,0 +1,101 @@ +permissions: 0.893 +graphic: 0.891 +semantic: 0.889 +device: 0.880 +assembly: 0.878 +register: 0.869 +performance: 0.869 +architecture: 0.862 +PID: 0.852 +arm: 0.843 +debug: 0.841 +peripherals: 0.821 +virtual: 0.820 +risc-v: 0.810 +VMM: 0.807 +ppc: 0.806 +TCG: 0.798 +user-level: 0.796 +vnc: 0.787 +hypervisor: 0.785 +mistranslation: 0.773 +boot: 0.767 +files: 0.748 +KVM: 0.744 +kernel: 0.728 +x86: 0.716 +i386: 0.712 +socket: 0.696 +network: 0.682 + +Segfault in artist_vram_read + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writew 0xf8118001 0x105a +readq 0xf900f8ff +EOF + +================================================================= +==20118==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc6fb847672 (pc 0x55ec9c0f6828 bp 0x7ffd91000230 sp 0x7ffd90ffffd0 T0) +==20118==The signal is caused by a READ memory access. + #0 0x55ec9c0f6828 in artist_vram_read /hw/display/artist.c:1174:15 + #1 0x55ec9b84a582 in memory_region_read_accessor /softmmu/memory.c:434:11 + #2 0x55ec9b7d1adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #3 0x55ec9b7cd769 in memory_region_dispatch_read1 /softmmu/memory.c:1385:16 + #4 0x55ec9b7cc855 in memory_region_dispatch_read /softmmu/memory.c:1414:9 + #5 0x55ec9ae621de in flatview_read_continue /exec.c:3239:23 + #6 0x55ec9ae64fb1 in flatview_read /exec.c:3279:12 + #7 0x55ec9ae64af7 in address_space_read_full /exec.c:3292:18 + #8 0x55ec9b87c990 in address_space_read /include/exec/memory.h:2429:18 + #9 0x55ec9b87c990 in qtest_process_command /softmmu/qtest.c:485:13 + #10 0x55ec9b870c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #11 0x55ec9b86f895 in qtest_read /softmmu/qtest.c:722:5 + #12 0x55ec9dd2b2f3 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #13 0x55ec9dd2b477 in qemu_chr_be_write /chardev/char.c:200:9 + #14 0x55ec9dd3f763 in fd_chr_read /chardev/char-fd.c:68:9 + #15 0x55ec9de93b24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #16 0x7fc7261ad897 in g_main_context_dispatch () + #17 0x55ec9e28ba2b in glib_pollfds_poll /util/main-loop.c:217:9 + #18 0x55ec9e28915b in os_host_main_loop_wait /util/main-loop.c:240:5 + #19 0x55ec9e288af4 in main_loop_wait /util/main-loop.c:516:11 + #20 0x55ec9b891d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #21 0x55ec9decb911 in main /softmmu/main.c:49:5 + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex + +There's one more slightly further in the same function - line 1231 https://github.com/hdeller/qemu-hppa/blob/1e5391948f977932d17526c491d262a3cd99a690/hw/display/artist.c#L1231 + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf8118005 0x1e7c50ff016d65ff +readl 0xf9080100 +EOF + +[I 1596601465.827371] OPENED +[R +0.043473] writeq 0xf8118005 0x1e7c50ff016d65ff +18615@1596601465.870899:artist_reg_write 1 0x118005 DST_BM_ACCESS <- 0x1e +18615@1596601465.870911:artist_reg_write 2 0x118006 DST_BM_ACCESS <- 0x7c50 +18615@1596601465.870918:artist_reg_write 4 0x118008 SRC_BM_ACCESS <- 0xff016d65 +18615@1596601465.870924:artist_reg_write 1 0x11800c CONTROL_PLANE <- 0xff +OK +[S +0.043557] OK +[R +0.043574] readl 0xf9080100 +AddressSanitizer:DEADLYSIGNAL +================================================================= +==18615==ERROR: AddressSanitizer: SEGV on unknown address 0x7f12d2a01040 (pc 0x560323116048 bp 0x7fffa8723bf0 sp 0x7fffa8723990 T0) +==18615==The signal is caused by a READ memory access. + #0 0x560323116048 in artist_vram_read /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:1231:23 + #1 0x560322868582 in memory_region_read_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:434:11 +... + +Fixed in commit a501bfc91763d4642390090dd4e6039d67b63702. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/permissions/1890545 b/results/classifier/118/permissions/1890545 new file mode 100644 index 00000000..b18392f3 --- /dev/null +++ b/results/classifier/118/permissions/1890545 @@ -0,0 +1,422 @@ +permissions: 0.951 +graphic: 0.942 +virtual: 0.938 +debug: 0.937 +device: 0.932 +semantic: 0.932 +architecture: 0.930 +PID: 0.928 +register: 0.925 +assembly: 0.922 +arm: 0.914 +user-level: 0.910 +performance: 0.906 +kernel: 0.898 +risc-v: 0.881 +vnc: 0.878 +ppc: 0.877 +files: 0.862 +boot: 0.852 +peripherals: 0.843 +hypervisor: 0.842 +mistranslation: 0.840 +VMM: 0.839 +x86: 0.834 +i386: 0.829 +KVM: 0.819 +TCG: 0.819 +network: 0.818 +socket: 0.743 + +(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML + +First I creat a file system that is debian(bullseye amd64)on arm64 machine，then I download google-chrome，however, when I ran Google browser, some errors occurred. + +$ google-chrome --no-sandbox +or +$ qemu-x86_64-static google-chrome --no-sandbox + +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +[1661:1661:0806/074307.502638:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +[1664:1664:0806/074307.504159:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +[1637:1678:0806/074308.337567:ERROR:file_path_watcher_linux.cc(315)] inotify_init() failed: Function not implemented (38) +Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank" +qemu: unknown option 'type=utility' +[1637:1680:0806/074313.598432:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye. +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap + +Why? +And then I run firefox,it can be opened, but it can't load any web pages and HTML. +I really need help！ +Thank. + +Hi + +When I run some app,like google-chrome: + + qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped + + + + + + +Which QEMU version are you using ? + + +Hi Peter,I use 5.1.0-rc3. + +It's fine on x86 that I use qemu-x86_64-static.But it's bad on arm.So what is the problem? + + + +Tony.LI <email address hidden> writes: + +> It's fine on x86 that I use qemu-x86_64-static.But it's bad on arm.So +> what is the problem? + +Could be a number of things - is Chrome using threading alongside it's +multiple processes? + +-- +Alex Bennée + + +Hi,Alex.May be you are right.I don't understand what you want to express. +I don't know what causes traps. +Is it caused by software, or qemu executes CPU-sensitive instruction simulation. + + + +Tony.LI <email address hidden> writes: + +> Hi,Alex.May be you are right.I don't understand what you want to express. +> I don't know what causes traps. +> Is it caused by software, or qemu executes CPU-sensitive instruction simulation. + +Does it work if you run: + + taskset 1 qemu-x86_64 google-chrome + +-- +Alex Bennée + + +Hi,Alex.It can't work.And I find some thing: + +$ glxinfo | grep -i open + +radeon: Failed to get PCI ID, error number -38 +libGL error: failed to create dri screen +libGL error: failed to load driver: radeonsi +libGL error: failed to get magic +libGL error: failed to load driver: radeonsi +OpenGL vendor string: VMware, Inc. +OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits) +OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.6 +OpenGL core profile shading language version string: 3.30 +OpenGL core profile context flags: (none) +OpenGL core profile profile mask: core profile +OpenGL core profile extensions: +OpenGL version string: 3.0 Mesa 13.0.6 +OpenGL shading language version string: 1.30 +OpenGL context flags: (none) +OpenGL extensions: +OpenGL ES profile version string: OpenGL ES 3.0 Mesa 13.0.6 +OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 +OpenGL ES profile extensions: + +So，could it be a problem with the PCI? I see a lot of questions about PCI when use qemu-system.But，what should I do?And I use qemu-user like qemu-x86_64-static. + +$ lspci +00:00.0 PCI bridge: Cadence Design Systems, Inc. Device dc16 +00:01.0 PCI bridge: Cadence Design Systems, Inc. Device dc08 +00:02.0 PCI bridge: Cadence Design Systems, Inc. Device dc01 +00:03.0 PCI bridge: Cadence Design Systems, Inc. Device dc16 +00:04.0 PCI bridge: Cadence Design Systems, Inc. Device dc08 +00:05.0 PCI bridge: Cadence Design Systems, Inc. Device dc01 +02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (rev 87) +02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series] +03:00.0 SATA controller: Marvell Technology Group Ltd. Device 9215 (rev 11) +06:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) + +Outside chroot,I get the same infomation! +Why? "radeon: Failed to get PCI ID, error number -38" + + +And I can get some infomation by "qemu-x86_64-static -d strace". + +.... +17344 getdents(8,274880624768,32768,115,274880624899,39) = 0 +17344 close(8) = 0 +17344 ioctl(7,0xc0406400,0x297330) = 0 +17344 ioctl(7,0xc0406400,0x297330) = 0 +17344 fstat(7,0x0000004001a0b660) = 0 +17344 fcntl(7,F_DUPFD_CLOEXEC,3) = 8 +17344 ioctl(8,0xc0406400,0x297330) = 0 +17344 ioctl(8,0xc0406400,0x297330) = 0 +17344 ioctl(8,0xc0106467,0x1a0b700) = -1 errno=38 (Function not implemented) +.... + +Last ioctl is error,why?It drives me crazy!!! + +ioctl number 0xc0106467 is DRM_IOCTL_RADEON_INFO. QEMU doesn't support that ioctl (each ioctl needs individual handling to convert the data structures it uses between the guest and host architecture). If your guest binary is trying to make graphics-card specific ioctl calls like this then I'm afraid it won't work in QEMU (unless somebody writes the QEMU patch to make it support them). + + +Hi,Peter. +I have added the ioctl() patch for Radeon driver in Qemu. +However, there are many ioctls that only give cmd, I don't know where it comes from. + +12161 poll(275275025312,1,4294967295,1,0,67108865) +12161 futex(0x000000400002f898,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 0 +12161 memfd_create(275207539749,3,100,24,0,7883677795399066671) = 12 +12161 ftruncate(12,4,100,180,0,7883677795399066671) = 0 +12161 mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,12,0) = 0x0000004027f4b000 +12161 clock_gettime(1,274903098336,0,4,274878804488,274878804096) = 0 +12161 ioctl(11,0xc020645d,0x18063f0) = 0 +12161 ioctl(11,0xc018646b,0x18063d0) = 0 +12161 ioctl(11,0xc00c6468,0x18077ac) = 0 +12161 ioctl(11,0xc00c642d,0x1807750) = -1 errno=38 (Function not implemented) +12161 ioctl(11,0xc018646b,0x1807880) = 0 +12161 ioctl(11,0x40086409,0x1807878) = -1 errno=38 (Function not implemented) + +What device is 0xc00c642d??And more... +What should I do ? Can anyone give me some suggestions? + +Hi,I have already added ioctl(), but there is one individual issue. + +Like this: +ioctl(54, _IOC(_IOC_READ, 0xf5, 0x0c, 0x04) <unfinished ...> + +But,despite the appearance: + +15461 open("/home/tony/.config/google-chrome/Default/Web Data",O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC,0600) = 43 +15461 clock_gettime(1,275070715216,0,16,547700673376,4) = 0 +15461 fstat(43,0x0000004025148d50) = 0 +15461 fstat(43,0x00000040251489a0) = 0 +15461 stat("/home/greatwall/.config/google-chrome/Default/Web Data",0x0000004025148910) = 0 +15461 ioctl(43,0x8004f50c,0x25148fc4) = -1 errno=25 (Inappropriate ioctl for device) +15461 pread64(43,275500011632,100,0,0,274910104856)15461 gettimeofday(275070717920,275070717904,1,547702733952,0,275070717328) = 0 + = 100 + +Why is there such an error(Inappropriate ioctl for device)?? + + + +Hi,I added a patch for ioctl(), and in the system call, I found no other errors, but it still doesn't work.And，I use the "qemu-x86_64 -d unimp xxx" command,I found this error: + + Unknown QEMU_IFLA_INFO_KIND sit + +In the Qemu source code: +linux-user/fd-trans.c +.... + /* nested */ + case QEMU_IFLA_INFO_DATA: + if (strncmp(li_context->name, "bridge", + li_context->len) == 0) { + return host_to_target_for_each_nlattr(NLA_DATA(nlattr), + nlattr->nla_len, + NULL, + host_to_target_data_bridge_nlattr); + } else if (strncmp(li_context->name, "tun", + li_context->len) == 0) { + return host_to_target_for_each_nlattr(NLA_DATA(nlattr), + nlattr->nla_len, + NULL, + host_to_target_data_tun_nlattr); + } else { + qemu_log_mask(LOG_UNIMP, "Unknown QEMU_IFLA_INFO_KIND %s\n", + li_context->name); + } + break; + +.... + +What does it mean? +And how can i solve it? +Thank you!!! + +Could you try attached patch? + +Hi,I have add QEMU_IFLA_INFO_KIND nested type for sit.But I still can't open Google browser. +And there are still the following errors: + +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +[1661:1661:0806/074307.502638:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +[1664:1664:0806/074307.504159:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: unknown option 'type=utility' +[1637:1680:0806/074313.598432:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye. +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap + +Qemu get the signal(INT3). +What causes this signal??? + +I don't know how to debug. When I block the operation of int3 in QEMU, it has the following error: + +qemu: 0x4004bc7855: unhandled CPU exception 0x3 - aborting +RAX=953ad79643deb400 RBX=0000007fa1203140 RCX=953ad79643deb400 RDX=000000400863f1d8 +RSI=0000004000b33f18 RDI=000000000000000e RBP=000000400863f590 RSP=000000400863f3c0 +R8 =0000000000000000 R9 =0000000000000001 R10=0000000000000000 R11=000000400aa153c0 +R12=000000400863f5a0 R13=0000000000000000 R14=0000007fa1218e10 R15=000000400863f5a0 +RIP=0000004004bc7855 RFL=00000246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 00000000 00000000 +CS =0033 0000000000000000 ffffffff 00effb00 DPL=3 CS64 [-RA] +SS =002b 0000000000000000 ffffffff 00cff300 DPL=3 DS [-WA] +DS =0000 0000000000000000 00000000 00000000 +FS =0000 000000400c0c3840 00000000 00000000 +GS =0000 0000000000000000 00000000 00000000 +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000400866f000 0000007f +IDT= 000000400866e000 F000001ff +CR0=80010001 CR2=0000000000000000 CR3=0000000000000000 CR4=00000220 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000500 + +Is it possible that the CPU of arm does not support certain instructions?But，I don't know. +Who can give me some advice? +Thank you！ + + +I wrote an example to load local HTML: + +#include "mainwindow.h" +#include "ui_mainwindow.h" +#include <QWebEngineView> +MainWindow::MainWindow(QWidget *parent) : + QMainWindow(parent), + ui(new Ui::MainWindow) +{ + ui->setupUi(this); + + QWebEngineView *webView = new QWebEngineView(this); + + webView->load(QUrl("file:////home/tony/1.html")); + webView->setFixedSize(this->width(),this->height()); + webView->show(); +} + +MainWindow::~MainWindow() +{ + delete ui; +} + + +At the same time, I found that a process(QtWebEngineProcess) did not start properly; +Then,I run: + + $ ./QtWebEngineProcess --type=zygote --webengine-schemes=qrc:sLV --lang=zh + qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped + + But,I didn't find any mistakes.Why does the process exit? + + + + +I wrote an example to load local HTML: + +#include "mainwindow.h" +#include "ui_mainwindow.h" +#include <QWebEngineView> +MainWindow::MainWindow(QWidget *parent) : + QMainWindow(parent), + ui(new Ui::MainWindow) +{ + ui->setupUi(this); + + QWebEngineView *webView = new QWebEngineView(this); + + webView->load(QUrl("file:////home/tony/1.html")); + webView->setFixedSize(this->width(),this->height()); + webView->show(); +} + +MainWindow::~MainWindow() +{ + delete ui; +} + +At the same time, I found that a process(QtWebEngineProcess) did not start properly; +Then,I run: + + $ ./QtWebEngineProcess --type=zygote --webengine-schemes=qrc:sLV + qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped + + But,I didn't find any mistakes.Why does the process exit? + + +Now, I found something new when I use gdb: + +=> 0x400523c858: ud2 + 0x400523c85a: pushq $0xd + 0x400523c85c: mov -0x230(%rbp),%rax + 0x400523c863: mov -0x240(%rbp),%rdi + 0x400523c86a: mov $0x1,%esi + 0x400523c86f: movq $0x0,-0x230(%rbp) + 0x400523c87a: mov %rax,-0x220(%rbp) + 0x400523c881: callq 0x40051ccf00 + 0x400523c886: callq 0x400266c540 + 0x400523c88b: cmp $0x1,%eax + 0x400523c88e: je 0x400523c8ed + 0x400523c890: lea -0x220(%rbp),%rdi + 0x400523c897: callq 0x40040fe8e0 + 0x400523c89c: jmpq 0x400523c60c + 0x400523c8a1: int3 + 0x400523c8a2: ud2 + 0x400523c8a4: pushq $0x10 + 0x400523c8a6: int3 + 0x400523c8a7: ud2 + 0x400523c8a9: pushq $0x11 + 0x400523c8ab: mov -0x200(%rbp),%rax + 0x400523c8b2: lea -0x1c0(%rbp),%rbx + 0x400523c8b9: movq $0x0,-0x200(%rbp) + +This is where the error occurred: +(gdb) x/30i 0x40007ff2c0 + 0x40007ff2c0: xor %al,%dh + 0x40007ff2c2: (bad) + 0x40007ff2c3: add %al,(%rax) + 0x40007ff2c5: add %al,(%rax) + 0x40007ff2c7: add %ch,0x0(%rbp) + 0x40007ff2cd: add %al,(%rax) + 0x40007ff2cf: add %dl,0x62d7(%rax) + 0x40007ff2d5: add %al,(%rax) + 0x40007ff2d7: add %cl,-0x16(%rdx) + 0x40007ff2da: test %ecx,(%rdx) + 0x40007ff2dc: add %al,(%rax) + 0x40007ff2df: add %al,(%rcx) + 0x40007ff2e1: repz jg 0x40007ff2e4 + 0x40007ff2e4: add %al,(%rax) + 0x40007ff2e7: add %bl,-0xd(%rax) + 0x40007ff2ea: jg 0x40007ff2ec + 0x40007ff2ec: add %al,(%rax) + 0x40007ff2ef: add %bl,-0xd(%rax) + 0x40007ff2f2: jg 0x40007ff2f4 + 0x40007ff2f4: add %al,(%rax) + 0x40007ff2f7: add %dh,(%rax) + 0x40007ff2f9: repz jg 0x40007ff2fc + 0x40007ff2fc: add %al,(%rax) + +(bad)?? What's it mean? + +I found out the reason for "qemu: unknown option 'type=utility'", created a sample code to demo it and a small wrokaround patch to chromium. Found more info in: +https://bugs.launchpad.net/qemu/+bug/1926246 + + + +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/280 + + diff --git a/results/classifier/118/permissions/1892581 b/results/classifier/118/permissions/1892581 new file mode 100644 index 00000000..fece8e34 --- /dev/null +++ b/results/classifier/118/permissions/1892581 @@ -0,0 +1,93 @@ +permissions: 0.960 +files: 0.950 +virtual: 0.947 +graphic: 0.902 +architecture: 0.894 +KVM: 0.888 +device: 0.886 +user-level: 0.877 +debug: 0.872 +kernel: 0.872 +assembly: 0.857 +semantic: 0.855 +ppc: 0.837 +mistranslation: 0.835 +performance: 0.833 +network: 0.832 +arm: 0.821 +x86: 0.820 +socket: 0.814 +PID: 0.800 +hypervisor: 0.791 +risc-v: 0.783 +peripherals: 0.775 +vnc: 0.766 +register: 0.755 +boot: 0.717 +VMM: 0.670 +i386: 0.669 +TCG: 0.645 + +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/118/permissions/1892684 b/results/classifier/118/permissions/1892684 new file mode 100644 index 00000000..4839cb39 --- /dev/null +++ b/results/classifier/118/permissions/1892684 @@ -0,0 +1,87 @@ +architecture: 0.934 +x86: 0.926 +permissions: 0.924 +register: 0.906 +graphic: 0.890 +user-level: 0.864 +arm: 0.822 +files: 0.745 +device: 0.742 +ppc: 0.696 +performance: 0.688 +PID: 0.671 +hypervisor: 0.667 +network: 0.665 +semantic: 0.657 +TCG: 0.646 +assembly: 0.593 +vnc: 0.587 +kernel: 0.583 +mistranslation: 0.573 +i386: 0.570 +VMM: 0.550 +KVM: 0.528 +risc-v: 0.523 +peripherals: 0.519 +virtual: 0.502 +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/118/permissions/1893040 b/results/classifier/118/permissions/1893040 new file mode 100644 index 00000000..9bdb5303 --- /dev/null +++ b/results/classifier/118/permissions/1893040 @@ -0,0 +1,327 @@ +register: 0.949 +permissions: 0.941 +device: 0.932 +peripherals: 0.906 +architecture: 0.901 +assembly: 0.879 +virtual: 0.875 +graphic: 0.873 +semantic: 0.869 +debug: 0.865 +risc-v: 0.863 +PID: 0.855 +performance: 0.855 +network: 0.845 +user-level: 0.830 +ppc: 0.790 +arm: 0.757 +VMM: 0.755 +files: 0.745 +TCG: 0.715 +hypervisor: 0.705 +mistranslation: 0.682 +boot: 0.680 +KVM: 0.677 +vnc: 0.610 +kernel: 0.446 +socket: 0.426 +x86: 0.348 +i386: 0.312 + + 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/118/permissions/1894781 b/results/classifier/118/permissions/1894781 new file mode 100644 index 00000000..35f46da7 --- /dev/null +++ b/results/classifier/118/permissions/1894781 @@ -0,0 +1,159 @@ +semantic: 0.953 +permissions: 0.951 +assembly: 0.947 +register: 0.945 +debug: 0.940 +network: 0.938 +PID: 0.931 +graphic: 0.927 +architecture: 0.925 +performance: 0.924 +device: 0.922 +boot: 0.907 +arm: 0.904 +user-level: 0.892 +peripherals: 0.889 +VMM: 0.885 +hypervisor: 0.863 +virtual: 0.848 +files: 0.839 +socket: 0.819 +kernel: 0.815 +risc-v: 0.814 +ppc: 0.798 +KVM: 0.766 +vnc: 0.705 +TCG: 0.687 +mistranslation: 0.673 +x86: 0.650 +i386: 0.543 + +[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/118/permissions/1900122 b/results/classifier/118/permissions/1900122 new file mode 100644 index 00000000..a0585a1a --- /dev/null +++ b/results/classifier/118/permissions/1900122 @@ -0,0 +1,173 @@ +permissions: 0.941 +user-level: 0.936 +register: 0.931 +virtual: 0.927 +performance: 0.917 +device: 0.916 +graphic: 0.911 +risc-v: 0.902 +architecture: 0.897 +debug: 0.896 +peripherals: 0.896 +semantic: 0.890 +VMM: 0.889 +assembly: 0.879 +socket: 0.874 +mistranslation: 0.870 +PID: 0.869 +files: 0.858 +hypervisor: 0.854 +arm: 0.848 +boot: 0.782 +TCG: 0.776 +ppc: 0.765 +kernel: 0.760 +vnc: 0.729 +network: 0.728 +KVM: 0.723 +x86: 0.721 +i386: 0.447 + +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/118/permissions/1900155 b/results/classifier/118/permissions/1900155 new file mode 100644 index 00000000..c50ef23d --- /dev/null +++ b/results/classifier/118/permissions/1900155 @@ -0,0 +1,124 @@ +permissions: 0.881 +register: 0.856 +device: 0.845 +graphic: 0.813 +assembly: 0.812 +KVM: 0.801 +TCG: 0.799 +VMM: 0.799 +performance: 0.796 +semantic: 0.793 +peripherals: 0.788 +boot: 0.781 +arm: 0.779 +user-level: 0.779 +socket: 0.775 +architecture: 0.775 +vnc: 0.771 +PID: 0.763 +risc-v: 0.762 +hypervisor: 0.758 +network: 0.755 +debug: 0.749 +virtual: 0.744 +mistranslation: 0.743 +files: 0.736 +x86: 0.729 +kernel: 0.728 +ppc: 0.684 +i386: 0.617 + +MIPS Malta fails booting due to IDE error + +As of commit 3e407488349: + +$ avocado --show=console run -t machine:malta tests/acceptance/boot_linux_console.py +console: [ 0.000000] Linux version 4.5.0-2-4kc-malta (<email address hidden>) (gcc version 5.3.1 20160519 (Debian 5.3.1-20) ) #1 Debian 4.5.5-1 (2016-05-29) +console: [ 0.000000] earlycon: Early serial console at I/O port 0x3f8 (options '38400n8') +console: [ 0.000000] bootconsole [uart0] enabled +console: [ 0.000000] CPU0 revision is: 00019300 (MIPS 24Kc) +console: [ 0.000000] FPU revision is: 00739300 +console: [ 0.000000] MIPS: machine is mti,malta +[...] +console: ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 +console: ata2.00: Drive reports diagnostics failure. This may indicate a drive +console: ata2.00: fault or invalid emulation. Contact drive vendor for information. +console: ata2.00: configured for UDMA/33 +console: scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 +console: Freeing unused kernel memory: 412K (80979000 - 809e0000) +console: do_page_fault(): sending SIGSEGV to mount for invalid write access to 0018a000 +console: epc = 775cca54 in libc-2.27.so[775b3000+177000] +console: ra = 77754618 in ld-2.27.so[77743000+24000] +console: do_page_fault(): sending SIGSEGV to klogd for invalid write access to 0018a000 +console: epc = 770f0a54 in libc-2.27.so[770d7000+177000] +console: ra = 77278618 in ld-2.27.so[77267000+24000] +console: do_page_fault(): sending SIGSEGV to S20urandom for invalid write access to 0018a000 +console: epc = 77d0ca54 in libc-2.27.so[77cf3000+177000] +console: ra = 77e94618 in ld-2.27.so[77e83000+24000] +console: do_page_fault(): sending SIGSEGV to mkdir for invalid write access to 0018a000 +console: epc = 776b8a54 in libc-2.27.so[7769f000+177000] +console: ra = 77840618 in ld-2.27.so[7782f000+24000] +console: do_page_fault(): sending SIGSEGV to sh for invalid write access to 0018a000 +console: epc = 77364a54 in libc-2.27.so[7734b000+177000] +console: ra = 774ec618 in ld-2.27.so[774db000+24000] +console: do_page_fault(): sending SIGSEGV to sh for invalid write access to 0018a000 +console: epc = 77bd4a54 in libc-2.27.so[77bbb000+177000] +console: ra = 77d5c618 in ld-2.27.so[77d4b000+24000] +console: do_page_fault(): sending SIGSEGV to awk for invalid write access to 0018a000 +console: epc = 76f44a54 in libc-2.27.so[76f2b000+177000] +console: ra = 770cc618 in ld-2.27.so[770bb000+24000] +console: do_page_fault(): sending SIGSEGV to cat for invalid write access to 0018a000 +console: epc = 770cca54 in libc-2.27.so[770b3000+177000] +console: ra = 77254618 in ld-2.27.so[77243000+24000] +$ echo $? +8 + +55adb3c45620c31f29978f209e2a44a08d34e2da is the first bad commit +commit 55adb3c45620c31f29978f209e2a44a08d34e2da +Author: John Snow <email address hidden> +Date: Fri Jul 24 01:23:00 2020 -0400 + + ide: cancel pending callbacks on SRST + + The SRST implementation did not keep up with the rest of IDE; it is + possible to perform a weak reset on an IDE device to remove the BSY/DRQ + bits, and then issue writes to the control/device registers which can + cause chaos with the state machine. + + Fix that by actually performing a real reset. + +Yup. Mark Cave-Ayland pointed this out to me. I have a patch ready for it: + +diff --git a/hw/ide/core.c b/hw/ide/core.c +index 693b352d5e..98cea7ad45 100644 +--- a/hw/ide/core.c ++++ b/hw/ide/core.c +@@ -2254,10 +2254,8 @@ static void ide_perform_srst(IDEState *s) + /* Cancel PIO callback, reset registers/signature, etc */ + ide_reset(s); + +- if (s->drive_kind == IDE_CD) { +- /* ATAPI drives do not set READY or SEEK */ +- s->status = 0x00; +- } ++ /* perform diagnostic */ ++ cmd_exec_dev_diagnostic(s, WIN_DIAGNOSE); + } + + static void ide_bus_perform_srst(void *opaque) +@@ -2282,9 +2280,7 @@ void ide_ctrl_write(void *opaque, uint32_t addr, uint32_t val) + + /* Device0 and Device1 each have their own control register, + * but QEMU models it as just one register in the controller. */ +- if ((bus->cmd & IDE_CTRL_RESET) && +- !(val & IDE_CTRL_RESET)) { +- /* SRST triggers on falling edge */ ++ if (!(bus->cmd & IDE_CTRL_RESET) && (val & IDE_CTRL_RESET)) { + for (i = 0; i < 2; i++) { + s = &bus->ifs[i]; + s->status |= BUSY_STAT; + +Fixed by commits 4ac4e7281a2..1a9925e3390. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/permissions/1907427 b/results/classifier/118/permissions/1907427 new file mode 100644 index 00000000..14587e85 --- /dev/null +++ b/results/classifier/118/permissions/1907427 @@ -0,0 +1,75 @@ +permissions: 0.924 +architecture: 0.890 +assembly: 0.886 +user-level: 0.885 +socket: 0.884 +virtual: 0.882 +files: 0.876 +performance: 0.860 +graphic: 0.855 +VMM: 0.848 +device: 0.845 +TCG: 0.836 +semantic: 0.826 +kernel: 0.822 +debug: 0.820 +network: 0.819 +KVM: 0.818 +PID: 0.815 +register: 0.803 +ppc: 0.798 +arm: 0.796 +risc-v: 0.785 +i386: 0.779 +hypervisor: 0.764 +boot: 0.752 +vnc: 0.738 +x86: 0.735 +mistranslation: 0.717 +peripherals: 0.712 + +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/118/permissions/1909 b/results/classifier/118/permissions/1909 new file mode 100644 index 00000000..2f23ccab --- /dev/null +++ b/results/classifier/118/permissions/1909 @@ -0,0 +1,80 @@ +permissions: 0.865 +risc-v: 0.856 +TCG: 0.827 +debug: 0.827 +graphic: 0.822 +architecture: 0.818 +peripherals: 0.817 +mistranslation: 0.807 +ppc: 0.786 +register: 0.775 +kernel: 0.767 +user-level: 0.759 +semantic: 0.753 +socket: 0.750 +PID: 0.746 +performance: 0.746 +arm: 0.726 +network: 0.710 +hypervisor: 0.710 +device: 0.709 +VMM: 0.665 +assembly: 0.655 +virtual: 0.620 +files: 0.615 +KVM: 0.585 +x86: 0.571 +vnc: 0.570 +boot: 0.545 +i386: 0.522 + +regression: 8.0.0 segfaults on coverage counter increment +Description of problem: +With qemu 8.0.0, my test program segfaults while incrementing a gcov counter: + +``` +Breakpoint 2, 0x00000000004bc9a8 in __CortexA53843419_464004 () +(gdb) x/2i $pc +=> 0x4bc9a8 <__CortexA53843419_464004>: str x8, [x9, #2512] + 0x4bc9ac <__CortexA53843419_464004+4>: b 0x464008 <mock_hyp_params_Destroy+24> +(gdb) p $x8 +$10 = 1 +(gdb) p $x9 +$11 = 5234688 +(gdb) x/x $x9+2512 +0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 +(gdb) stepi + +Program received signal SIGSEGV, Segmentation fault. +0x00000000004bc9a8 in __CortexA53843419_464004 () +(gdb) x/x $x9+2512 +0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 +(gdb) shell llvm-objdump --syms --arch-name=aarch64 ./build/gcov/out/test_hyp-props.out | grep 4fe9d0 +00000000004fe9d0 l O .bss 0000000000000008 __llvm_gcov_ctr.5 +(gdb) shell qemu-aarch64 --version +qemu-aarch64 version 8.0.0 +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +(gdb) +``` + +With qemu 6.2.0, it doesn't segfault (at least not at this point, you +may ignore the segfault at the end due to a bug in the test program). +``` +$ /usr/bin/qemu-aarch64 --version +qemu-aarch64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +$ /usr/bin/qemu-aarch64 ./build/gcov/out/test_hyp-props.out +test_hyp-props.c:13:test__setup_str_prop:PASS +test_hyp-props.c:14:test__log_print_handler:PASS +test_hyp-props.c:15:test__setup_log_print_prop:PASS +test_hyp-props.c:16:test__vm_vcpu_abort_reset_handler:PASS +test_hyp-props.c:17:test__vm_info_alloc:PASS +test_hyp-props.c:18:test__memory_status_get:PASS +test_hyp-props.c:19:test__memory_status_get_fail:PASS +Segmentation fault (core dumped) +``` +Steps to reproduce: +1. Compile and link statically (with ld.lld) a test program, with clang, targetting aarch64 with: -target aarch64-linux-android -mcpu=cortex-a53, using --coverage option to generate gcov coverage. +2. Run it with qemu-aarch64 8.0.0 +3. Hopefully, it will segfault early for no good reason. diff --git a/results/classifier/118/permissions/1912065 b/results/classifier/118/permissions/1912065 new file mode 100644 index 00000000..82f4339a --- /dev/null +++ b/results/classifier/118/permissions/1912065 @@ -0,0 +1,115 @@ +permissions: 0.916 +semantic: 0.889 +peripherals: 0.869 +assembly: 0.849 +graphic: 0.845 +kernel: 0.844 +debug: 0.842 +register: 0.842 +device: 0.818 +network: 0.816 +arm: 0.802 +TCG: 0.801 +PID: 0.796 +risc-v: 0.784 +socket: 0.774 +virtual: 0.761 +architecture: 0.743 +vnc: 0.719 +mistranslation: 0.702 +ppc: 0.679 +user-level: 0.678 +files: 0.672 +KVM: 0.654 +boot: 0.643 +VMM: 0.625 +performance: 0.609 +hypervisor: 0.608 +x86: 0.602 +i386: 0.572 + +Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d + +QEMU segfaults to NULL dereference in tcg/optimize.c:212 semi-randomly after commit 7c79721606be11b5bc556449e5bcbc331ef6867d + +Exception Type: EXC_BAD_ACCESS (SIGSEGV) +Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 +Exception Note: EXC_CORPSE_NOTIFY + +... + +Thread 4 Crashed: +0 qemu-system-ppc 0x0000000109cd26d2 tcg_opt_gen_mov + 178 (optimize.c:212) +1 qemu-system-ppc 0x0000000109ccf838 tcg_optimize + 5656 +2 qemu-system-ppc 0x0000000109c27600 tcg_gen_code + 64 (tcg.c:4490) +3 qemu-system-ppc 0x0000000109c17b6d tb_gen_code + 493 (translate-all.c:1952) +4 qemu-system-ppc 0x0000000109c16085 tb_find + 41 (cpu-exec.c:454) [inlined] +5 qemu-system-ppc 0x0000000109c16085 cpu_exec + 2117 (cpu-exec.c:810) +6 qemu-system-ppc 0x0000000109c09ac3 tcg_cpus_exec + 35 (tcg-cpus.c:57) +7 qemu-system-ppc 0x0000000109c75edd rr_cpu_thread_fn + 445 (tcg-cpus-rr.c:217) +8 qemu-system-ppc 0x0000000109e41fae qemu_thread_start + 126 (qemu-thread-posix.c:521) +9 libsystem_pthread.dylib 0x00007fff2038e950 _pthread_start + 224 +10 libsystem_pthread.dylib 0x00007fff2038a47b thread_start + 15 + +Here the crash is in tcg/optimize.c line 212: + + mask = si->mask; + +"si" is NULL. The NULL value arises from tcg/optimize.c line 198: + + si = ts_info(src_ts); + +I did not attempt to determine the root cause of this issue, however. It clearly is related to the "tcg/optimize" changes in this commit. The previous commit c0dd6654f207810b16a75b673258f5ce2ceffbf0 doesn't crash. + +Thanks for reporting it. Just found it as well and reported on the mailing +list. It's currently being investigated. List thread is here: + +https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg03936.html + + +The problem is that we're now generating many more temporaries +than before, and running out of the statically allocated amount. +Changing a debug assert to a full assert will change the SEGV +into an ABRT. :-) + +diff --git a/tcg/tcg.c b/tcg/tcg.c +index 8f8badb61c..c376afe56a 100644 +--- a/tcg/tcg.c ++++ b/tcg/tcg.c +@@ -1207,7 +1207,7 @@ void tcg_func_start(TCGContext *s) + static inline TCGTemp *tcg_temp_alloc(TCGContext *s) + { + int n = s->nb_temps++; +- tcg_debug_assert(n < TCG_MAX_TEMPS); ++ g_assert(n < TCG_MAX_TEMPS); + return memset(&s->temps[n], 0, sizeof(TCGTemp)); + } + + +The problem can be worked around temporarily by increasing the +number of temporaries: + +diff --git a/include/tcg/tcg.h b/include/tcg/tcg.h +index 504c5e9bb0..8fe32bb03c 100644 +--- a/include/tcg/tcg.h ++++ b/include/tcg/tcg.h +@@ -275,7 +275,7 @@ typedef struct TCGPool { + + #define TCG_POOL_CHUNK_SIZE 32768 + +-#define TCG_MAX_TEMPS 512 ++#define TCG_MAX_TEMPS 2048 + #define TCG_MAX_INSNS 512 + + /* when the size of the arguments of a called function is smaller than + + +But a proper solution is to dynamically allocate the temps. + +Richard, thanks for providing the workaround. It helps. + +A full solution to the problem: +https://<email address hidden>/ + +https://gitlab.com/qemu-project/qemu/-/commit/ae30e86661b0f4 + diff --git a/results/classifier/118/permissions/1913873 b/results/classifier/118/permissions/1913873 new file mode 100644 index 00000000..72c8aa04 --- /dev/null +++ b/results/classifier/118/permissions/1913873 @@ -0,0 +1,100 @@ +permissions: 0.817 +peripherals: 0.814 +mistranslation: 0.810 +VMM: 0.801 +register: 0.797 +TCG: 0.795 +vnc: 0.788 +hypervisor: 0.782 +KVM: 0.779 +virtual: 0.768 +device: 0.765 +user-level: 0.760 +semantic: 0.755 +arm: 0.752 +graphic: 0.749 +performance: 0.748 +architecture: 0.743 +debug: 0.739 +ppc: 0.739 +x86: 0.739 +assembly: 0.719 +PID: 0.714 +risc-v: 0.707 +kernel: 0.665 +i386: 0.655 +network: 0.620 +boot: 0.616 +files: 0.579 +socket: 0.541 + +QEMU: net: vmxnet: integer overflow may crash guest + +* Gaoning Pan from Zhejiang University & Ant Security Light-Year Lab reported a malloc failure + issue locates in vmxnet3_activate_device() of qemu/hw/net/vmxnet3.c NIC emulator + +* This issue is reproducible because while activating the NIC device, vmxnet3_activate_device + does not validate guest supplied configuration values against predefined min/max limits. + +@@ -1420,6 +1420,7 @@ static void vmxnet3_activate_device(VMXNET3State *s) + vmxnet3_setup_rx_filtering(s); + /* Cache fields from shared memory */ + s->mtu = VMXNET3_READ_DRV_SHARED32(d, s->drv_shmem, devRead.misc.mtu); ++ assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU); <= Did not check if MTU is within range + VMW_CFPRN("MTU is %u", s->mtu); + + s->max_rx_frags = +@@ -1473,6 +1474,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* Read rings memory locations for TX queues */ + pa = VMXNET3_READ_TX_QUEUE_DESCR64(d, qdescr_pa, conf.txRingBasePA); + size = VMXNET3_READ_TX_QUEUE_DESCR32(d, qdescr_pa, conf.txRingSize); ++ if (size > VMXNET3_TX_RING_MAX_SIZE) { <= Did not check TX ring size ++ size = VMXNET3_TX_RING_MAX_SIZE; ++ } + + vmxnet3_ring_init(d, &s->txq_descr[i].tx_ring, pa, size, + sizeof(struct Vmxnet3_TxDesc), false); +@@ -1483,6 +1487,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* TXC ring */ + pa = VMXNET3_READ_TX_QUEUE_DESCR64(d, qdescr_pa, conf.compRingBasePA); + size = VMXNET3_READ_TX_QUEUE_DESCR32(d, qdescr_pa, conf.compRingSize); ++ if (size > VMXNET3_TC_RING_MAX_SIZE) { <= Did not check TC ring size ++ size = VMXNET3_TC_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->txq_descr[i].comp_ring, pa, size, + sizeof(struct Vmxnet3_TxCompDesc), true); + VMXNET3_RING_DUMP(VMW_CFPRN, "TXC", i, &s->txq_descr[i].comp_ring); +@@ -1524,6 +1531,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* RX rings */ + pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.rxRingBasePA[j]); + size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.rxRingSize[j]); ++ if (size > VMXNET3_RX_RING_MAX_SIZE) { <= Did not check RX ring size ++ size = VMXNET3_RX_RING_MAX_SIZE; ++ } + vmxnet3_ring_init(d, &s->rxq_descr[i].rx_ring[j], pa, size, + sizeof(struct Vmxnet3_RxDesc), false); + VMW_CFPRN("RX queue %d:%d: Base: %" PRIx64 ", Size: %d", +@@ -1533,6 +1543,9 @@ static void vmxnet3_activate_device(VMXNET3State *s) + /* RXC ring */ + pa = VMXNET3_READ_RX_QUEUE_DESCR64(d, qd_pa, conf.compRingBasePA); + size = VMXNET3_READ_RX_QUEUE_DESCR32(d, qd_pa, conf.compRingSize); ++ if (size > VMXNET3_RC_RING_MAX_SIZE) { <= Did not check RC ring size ++ size = VMXNET3_RC_RING_MAX_SIZE; ++ } + +This may lead to potential integer overflow OR OOB buffer access issues. + +CVE-2021-20203 assigned by Red Hat Inc. + +Is this the same as https://bugs.launchpad.net/qemu/+bug/1890152 ? + +Yes, from the trace looks same. + + +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/308 + + diff --git a/results/classifier/118/permissions/1913916 b/results/classifier/118/permissions/1913916 new file mode 100644 index 00000000..50a452a4 --- /dev/null +++ b/results/classifier/118/permissions/1913916 @@ -0,0 +1,106 @@ +permissions: 0.859 +device: 0.853 +register: 0.846 +hypervisor: 0.810 +virtual: 0.808 +performance: 0.805 +mistranslation: 0.800 +peripherals: 0.791 +risc-v: 0.788 +arm: 0.787 +x86: 0.786 +TCG: 0.783 +semantic: 0.776 +i386: 0.773 +debug: 0.769 +vnc: 0.766 +architecture: 0.765 +graphic: 0.758 +user-level: 0.740 +assembly: 0.737 +ppc: 0.735 +PID: 0.732 +kernel: 0.724 +files: 0.722 +VMM: 0.713 +KVM: 0.689 +socket: 0.669 +boot: 0.661 +network: 0.598 + +aarch64-virt: heap-buffer-overflow in address_space_lookup_region + +Reproducer: +cat << EOF | ./qemu-system-aarch64 \ +-machine virt,accel=qtest -qtest stdio +writel 0x8000f00 0xff4affb0 +writel 0x8000f00 0xf2f8017f +writeq 0x801000e 0x5a5a5a6c8ff7004b +writeq 0x8010010 0x5a5a5a5a73ba2f00 +writel 0x8000000 0x3bf5a03 +writel 0x8000000 0x3bf5a03 +writeq 0x8010000 0x10ffff03fbffffff +writel 0x8000f1f 0x5a55fc00 +readl 0x8011f00 +readl 0x80000d3 +readl 0x80000d3 +clock_step +writeq 0x4010008004 0x4604fffdffc54c01 +writeq 0x4010008002 0xf7478b3f5aff5a55 +writel 0x8000f00 0x2d6954 +writel 0x800005a 0x2706fcf +readq 0x800002c +readw 0x9000004 +readq 0x800002c +writeq 0x801000e 0x5555017f00017f00 +writew 0x8010000 0x55 +writew 0x8010000 0x465a +writew 0x8010000 0x55 +writew 0x8010000 0xaf00 +writeq 0x8010015 0x3b5a5a5555460000 +writeq 0x8010015 0xd546002b2b000000 +writeq 0x8010015 0xc44ea5aaaab9ffff +readq 0x8000a5a +EOF + +Stacktrace: +==638893==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x629000022b84 at pc 0x55915c484d92 bp 0x7ffcde114a00 sp 0x7ffcde1149f8 +READ of size 2 at 0x629000022b84 thread T0 + #0 0x55915c484d91 in address_space_lookup_region /home/alxndr/Development/qemu/build/../softmmu/physmem.c:345:36 + #1 0x55915c484d91 in address_space_translate_internal /home/alxndr/Development/qemu/build/../softmmu/physmem.c:359:15 + #2 0x55915c481d90 in flatview_do_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:497:15 + #3 0x55915c48214e in flatview_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:563:15 + #4 0x55915c107ff9 in address_space_read /home/alxndr/Development/qemu/include/exec/memory.h:2477:18 + #5 0x55915c107ff9 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:572:13 + #6 0x55915c102b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 + #7 0x55915c953286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 + #8 0x7f02be25daae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) + #9 0x55915cfae363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 + #10 0x55915cfae363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 + #11 0x55915cfae363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 + #12 0x55915c069599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 + #13 0x55915a2f61fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 + #14 0x7f02bdd02cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #15 0x55915a249bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +0x629000022b84 is located 660 bytes to the right of 18160-byte region [0x62900001e200,0x6290000228f0) +allocated by thread T0 here: + #0 0x55915a2c3c3d in malloc (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x33cac3d) + #1 0x7f02be263a88 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57a88) + #2 0x55915c932cbd in qdev_new /home/alxndr/Development/qemu/build/../hw/core/qdev.c:153:19 + #3 0x55915b559360 in create_gic /home/alxndr/Development/qemu/build/../hw/arm/virt.c:631:16 + #4 0x55915b5449d2 in machvirt_init /home/alxndr/Development/qemu/build/../hw/arm/virt.c:1966:5 + #5 0x55915a62bac0 in machine_run_board_init /home/alxndr/Development/qemu/build/../hw/core/machine.c:1169:5 + #6 0x55915c02b8d8 in qemu_init_board /home/alxndr/Development/qemu/build/../softmmu/vl.c:2455:5 + #7 0x55915c02b8d8 in qmp_x_exit_preconfig /home/alxndr/Development/qemu/build/../softmmu/vl.c:2526:5 + #8 0x55915c035d91 in qemu_init /home/alxndr/Development/qemu/build/../softmmu/vl.c:3533:9 + #9 0x55915a2f61f8 in main /home/alxndr/Development/qemu/build/../softmmu/main.c:49:5 + #10 0x7f02bdd02cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + +Fix for this 13+ years old issue: +https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg07969.html + +This is a duplicate of the rather simpler bug 1913917. The overrun occurs on the first +writel 0x8000f00 0xff4affb0, which corrupts memory and eventually results in the crash described in the backtrace. I'm not sure why the fuzzer isn't just reporting the original overrun. + + diff --git a/results/classifier/118/permissions/1914021 b/results/classifier/118/permissions/1914021 new file mode 100644 index 00000000..a34b9326 --- /dev/null +++ b/results/classifier/118/permissions/1914021 @@ -0,0 +1,135 @@ +permissions: 0.902 +performance: 0.867 +user-level: 0.864 +debug: 0.843 +peripherals: 0.834 +semantic: 0.828 +risc-v: 0.827 +device: 0.822 +hypervisor: 0.811 +graphic: 0.800 +assembly: 0.800 +arm: 0.798 +virtual: 0.797 +architecture: 0.793 +register: 0.788 +mistranslation: 0.781 +PID: 0.770 +TCG: 0.743 +ppc: 0.710 +boot: 0.696 +vnc: 0.691 +network: 0.681 +kernel: 0.672 +files: 0.665 +socket: 0.662 +x86: 0.646 +i386: 0.643 +VMM: 0.630 +KVM: 0.549 + +qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally + +I'm getting Illegal instruction (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. + +readelf -h a.out_err +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: 0x8220 + Start of program headers: 52 (bytes into file) + Start of section headers: 54228 (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: 3 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 15 + +qemu-arm version 4.0.0 + + + +QEMU 4.0 is quite old now -- does this reproduce with a more recent QEMU? + + +yes, it reproduced on QEMU 5.0.0. + +For me, with current head-of-git QEMU, the program crashes with a SIGSEGV very early in execution, because: + +0x00008260: e59f30f0 ldr r3, [pc, #0xf0] + +loads 0 into r3, and then + +0x00008270: e1a0d003 mov sp, r3 + +sets sp to 0, and then + +0x000087b0: e92d4030 push {r4, r5, lr} + +tries to write to addres 0, which causes a SEGV. + +This happens whether using the gdbstub or not. + + + 0x00008260 <+64>: ldr r3, [pc, #240] + 0x00008264 <+68>: cmp r1, #0 +=> 0x00008268 <+72>: beq 0x8270 + 0x0000826c <+76>: mov r3, r1 + 0x00008270 <+80>: mov sp, r3 + +(gdb) p/x $r1 +$2 = 0xfffef690 + +But r1 is not zero when using Gdb remote-debug, so it will enter + 0x0000826c <+76>: mov r3, r1 + +QEMU 5.0.0. +GNU gdb (GDB; SUSE Linux Enterprise 12) 8.0.1 + + +Oh, your code is trying to use the SYS_HEAPINFO semihosting call to figure out where the stack and heap are. This is generally a bad idea if you're using QEMU user-mode emulation: you start with a perfectly good stack pointer and you should just use the usual Linux syscalls to allocate heap if you need it. + +I have no idea where your code is getting r1 from -- it's too painful to try to reverse-engineer it from the binary. I can't repro any difference between with-gdb and without -- for me with current QEMU r1 is 0 whether running with the gdb stub or not. + + +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/118/permissions/1920913 b/results/classifier/118/permissions/1920913 new file mode 100644 index 00000000..4726fc4b --- /dev/null +++ b/results/classifier/118/permissions/1920913 @@ -0,0 +1,462 @@ +permissions: 0.938 +debug: 0.925 +register: 0.910 +PID: 0.898 +arm: 0.896 +virtual: 0.891 +assembly: 0.888 +peripherals: 0.886 +VMM: 0.885 +TCG: 0.883 +performance: 0.881 +architecture: 0.878 +risc-v: 0.875 +semantic: 0.868 +mistranslation: 0.866 +device: 0.862 +files: 0.856 +socket: 0.851 +vnc: 0.849 +KVM: 0.848 +user-level: 0.847 +graphic: 0.847 +network: 0.831 +ppc: 0.824 +hypervisor: 0.815 +boot: 0.811 +kernel: 0.793 +x86: 0.770 +i386: 0.720 + +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/118/permissions/1921468 b/results/classifier/118/permissions/1921468 new file mode 100644 index 00000000..5330dc12 --- /dev/null +++ b/results/classifier/118/permissions/1921468 @@ -0,0 +1,339 @@ +permissions: 0.933 +semantic: 0.889 +network: 0.878 +virtual: 0.867 +register: 0.867 +user-level: 0.867 +boot: 0.846 +hypervisor: 0.842 +graphic: 0.841 +PID: 0.832 +mistranslation: 0.831 +arm: 0.823 +architecture: 0.816 +performance: 0.811 +assembly: 0.808 +socket: 0.797 +device: 0.797 +ppc: 0.788 +peripherals: 0.783 +risc-v: 0.780 +debug: 0.761 +KVM: 0.748 +files: 0.732 +TCG: 0.717 +vnc: 0.706 +kernel: 0.670 +VMM: 0.637 +x86: 0.496 +i386: 0.433 + +[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/118/permissions/1921948 b/results/classifier/118/permissions/1921948 new file mode 100644 index 00000000..83f8d75d --- /dev/null +++ b/results/classifier/118/permissions/1921948 @@ -0,0 +1,623 @@ +permissions: 0.880 +virtual: 0.867 +architecture: 0.864 +semantic: 0.858 +boot: 0.842 +device: 0.842 +register: 0.840 +debug: 0.830 +arm: 0.825 +performance: 0.820 +assembly: 0.818 +user-level: 0.817 +network: 0.810 +peripherals: 0.807 +kernel: 0.806 +files: 0.803 +PID: 0.769 +graphic: 0.767 +hypervisor: 0.761 +KVM: 0.753 +risc-v: 0.740 +TCG: 0.738 +VMM: 0.725 +ppc: 0.717 +socket: 0.713 +vnc: 0.699 +mistranslation: 0.563 +x86: 0.512 +i386: 0.429 + +MTE tags not checked properly for unaligned accesses at EL1 + +For kernel memory accesses that span across two memory granules, QEMU's MTE implementation only checks the tag of the first granule but not of the second one. + +To reproduce this, build the Linux kernel with CONFIG_KASAN_HW_TAGS enabled, apply the patch below, and boot the kernel: + +diff --git a/sound/last.c b/sound/last.c +index f0bb98780e70..04745cb30b74 100644 +--- a/sound/last.c ++++ b/sound/last.c +@@ -5,12 +5,18 @@ + */ + + #include <linux/init.h> ++#include <linux/slab.h> + #include <sound/core.h> + + static int __init alsa_sound_last_init(void) + { + struct snd_card *card; + int idx, ok = 0; ++ ++ char *ptr = kmalloc(128, GFP_KERNEL); ++ pr_err("KASAN report should follow:\n"); ++ *(volatile unsigned long *)(ptr + 124); ++ kfree(ptr); + + printk(KERN_INFO "ALSA device list:\n"); + for (idx = 0; idx < SNDRV_CARDS; idx++) { + +KASAN tags the 128 allocated bytes with the same tag as the returned pointer. The memory granule that follows the 128 allocated bytes has a different tag (with 1/15 probability). + +Expected result: a tag fault is detected and a KASAN report is printed when accessing bytes [124, 130). +Observed result: no tag fault is detected and no KASAN report is printed. + +Here are the flags that I use to run QEMU if they matter: + +qemu-system-aarch64 -s -machine virt,mte=on -cpu max -m 2G -smp 2 -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 -net nic -nographic -kernel ./Image -append "console=ttyAMA0 root=/dev/vda earlyprintk=serial" -drive file=./fs.img,format=raw,if=virtio -no-shutdown -no-reboot + +I believe that you're correct, and that I mis-read the MTE specification. + +I believed that exactly one mte tag check was made for any single memory +access. But I missed that unaligned accesses are as-if a sequence of byte +accesses -- in the Arm ARM, see aarch64/functions/memory/Mem[]. + +I'm still trying to verify this via the Arm FVP, but so far I've not +found the right incantation of parameters to properly enable MTE. +(I can enable the instructions, but a simple stg/ldg test suggests +that there is no tag storage enabled -- all tags read as 0.) + +The flags that you need to pass to FVP to enable MTE are listed near the end of the README here: + +https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fvpbase/README.md + +Ah, perfect, I was missing dram_metadata.is_enabled. + +And my userland unaligned test case demonstrates that +the second granule is tested, as reported. + +https://<email address hidden>/ + +Hi Richard, + +I tried your patch, but QEMU crashes with: + +ERROR:../target/arm/mte_helper.c:588:mte_check_fail: code should not be reached +Bail out! ERROR:../target/arm/mte_helper.c:588:mte_check_fail: code should not be reached + +when running KASAN tests. + +Thanks! + +Yeah, I saw an error right after posting. Please try v2: + +https://<email address hidden>/ + +With v2, a lot of KASAN tests start failing. This likely means that MTE tag faults stop being generated in certain cases. + +With v3 [1], no MTE faults are generated at all. + +[1] https://<email address hidden>/ + + +Richard Henderson <email address hidden> writes: + +> We were incorrectly assuming that only the first byte of an MTE access +> is checked against the tags. But per the ARM, unaligned accesses are +> pre-decomposed into single-byte accesses. So by the time we reach the +> actual MTE check in the ARM pseudocode, all accesses are aligned. +> +> Therefore, the first failure is always either the first byte of the +> access, or the first byte of the granule. +> +> In addition, some of the arithmetic is off for last-first -> count. +> This does not become directly visible until a later patch that passes +> single bytes into this function, so ptr == ptr_last. +> +> Buglink: https://bugs.launchpad.net/bugs/1921948 + +Minor note: you can Cc: Bug 1921948 <email address hidden> to +automatically copy patches to the appropriate bugs which is useful if +you don't have the Cc for the reporter. + +Anyway I'm trying to get the kasas unit tests running as a way of +testing this (and maybe expanding with a version of Andrey's test). I +suspect this may be a PEBCAC issue but I built an MTE enabled kernel +with: + + CONFIG_HAVE_ARCH_KASAN=y + CONFIG_HAVE_ARCH_KASAN_SW_TAGS=y + CONFIG_HAVE_ARCH_KASAN_HW_TAGS=y + CONFIG_CC_HAS_KASAN_GENERIC=y + CONFIG_KASAN=y + # CONFIG_KASAN_GENERIC is not set + CONFIG_KASAN_HW_TAGS=y + CONFIG_KASAN_STACK=1 + CONFIG_KASAN_KUNIT_TEST=m + CONFIG_TEST_KASAN_MODULE=m + +and was able to boot it. But when I insmod the kasan tests: + + insmod test_kasan.ko + +it looks like it just keeps looping failing on the same test: + + Ignoring spurious kernel translation fault at virtual address dead00000000010a + WARNING: CPU: 0 PID: 1444 at arch/arm64/mm/fault.c:364 __do_kernel_fault+0xc4/0x1bc + Modules linked in: test_kasan(+) + CPU: 0 PID: 1444 Comm: kunit_try_catch Tainted: G B W 5.11.0-ajb-kasan #3 + Hardware name: linux,dummy-virt (DT) + pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) + pc : __do_kernel_fault+0xc4/0x1bc + lr : __do_kernel_fault+0xc4/0x1bc + sp : ffffffc01191b900 + x29: ffffffc01191b900 x28: fcffff8001f7a880 + x27: fcffff8001c01e00 x26: 0000000000000000 + x25: 0000000000000001 x24: 00000000000000f4 + x23: 0000000020400009 x22: dead00000000010a + x21: 0000000000000025 x20: ffffffc01191b9d0 + x19: 0000000097c08004 x18: 0000000000000000 + x17: 000000000000000a x16: 000017a83fb75794 + x15: 0000000000000030 x14: 6c656e72656b2073 + x13: ffffffc010e21be0 x12: 00000000000001aa + x11: 000000000000008e x10: ffffffc010e2d930 + x9 : 000000000003a6d0 x8 : ffffffc010e21be0 + x7 : ffffffc010e2cbe0 x6 : 0000000000000d50 + x5 : ffffff8007f9c850 x4 : ffffffc01191b700 + x3 : 0000000000000001 x2 : 0000000000000000 + x1 : 0000000000000000 x0 : fcffff8001f7a880 + Call trace: + __do_kernel_fault+0xc4/0x1bc + do_translation_fault+0x98/0xb0 + do_mem_abort+0x44/0xb0 + el1_abort+0x40/0x6c + el1_sync_handler+0x6c/0xb0 + el1_sync+0x70/0x100 + kasan_update_kunit_status+0x6c/0x1ac + kasan_report_invalid_free+0x34/0xa0 + ____kasan_slab_free.constprop.0+0xf8/0x1a0 + __kasan_slab_free+0x10/0x20 + slab_free_freelist_hook+0xf8/0x1a0 + kfree+0x148/0x25c + kunit_destroy_resource+0x15c/0x1bc + string_stream_destroy+0x20/0x80 + kunit_do_assertion+0x190/0x1e4 + kmalloc_double_kzfree+0x158/0x190 [test_kasan] + kunit_try_run_case+0x78/0xa4 + kunit_generic_run_threadfn_adapter+0x20/0x2c + kthread+0x134/0x144 + ret_from_fork+0x10/0x38 + ---[ end trace 5acd02cdb9b3d3f0 ]--- + +but maybe I'm using the kunit tests wrong. It's my first time playing +with them. + +> Signed-off-by: Richard Henderson <email address hidden> +> --- +> target/arm/mte_helper.c | 38 +++++++++++++++++--------------------- +> 1 file changed, 17 insertions(+), 21 deletions(-) +> +> diff --git a/target/arm/mte_helper.c b/target/arm/mte_helper.c +> index 8be17e1b70..c87717127c 100644 +> --- a/target/arm/mte_helper.c +> +++ b/target/arm/mte_helper.c +> @@ -757,10 +757,10 @@ uint64_t mte_checkN(CPUARMState *env, uint32_t desc, +> uint64_t ptr, uintptr_t ra) +> { +> int mmu_idx, ptr_tag, bit55; +> - uint64_t ptr_last, ptr_end, prev_page, next_page; +> - uint64_t tag_first, tag_end; +> - uint64_t tag_byte_first, tag_byte_end; +> - uint32_t esize, total, tag_count, tag_size, n, c; +> + uint64_t ptr_last, prev_page, next_page; +> + uint64_t tag_first, tag_last; +> + uint64_t tag_byte_first, tag_byte_last; +> + uint32_t total, tag_count, tag_size, n, c; +> uint8_t *mem1, *mem2; +> MMUAccessType type; +> +> @@ -779,29 +779,27 @@ uint64_t mte_checkN(CPUARMState *env, uint32_t desc, +> +> mmu_idx = FIELD_EX32(desc, MTEDESC, MIDX); +> type = FIELD_EX32(desc, MTEDESC, WRITE) ? MMU_DATA_STORE : MMU_DATA_LOAD; +> - esize = FIELD_EX32(desc, MTEDESC, ESIZE); +> total = FIELD_EX32(desc, MTEDESC, TSIZE); +> +> /* Find the addr of the end of the access, and of the last element. */ +> - ptr_end = ptr + total; +> - ptr_last = ptr_end - esize; +> + ptr_last = ptr + total - 1; +> +> /* Round the bounds to the tag granule, and compute the number of tags. */ +> tag_first = QEMU_ALIGN_DOWN(ptr, TAG_GRANULE); +> - tag_end = QEMU_ALIGN_UP(ptr_last, TAG_GRANULE); +> - tag_count = (tag_end - tag_first) / TAG_GRANULE; +> + tag_last = QEMU_ALIGN_DOWN(ptr_last, TAG_GRANULE); +> + tag_count = ((tag_last - tag_first) / TAG_GRANULE) + 1; +> +> /* Round the bounds to twice the tag granule, and compute the bytes. */ +> tag_byte_first = QEMU_ALIGN_DOWN(ptr, 2 * TAG_GRANULE); +> - tag_byte_end = QEMU_ALIGN_UP(ptr_last, 2 * TAG_GRANULE); +> + tag_byte_last = QEMU_ALIGN_DOWN(ptr_last, 2 * TAG_GRANULE); +> +> /* Locate the page boundaries. */ +> prev_page = ptr & TARGET_PAGE_MASK; +> next_page = prev_page + TARGET_PAGE_SIZE; +> +> - if (likely(tag_end - prev_page <= TARGET_PAGE_SIZE)) { +> + if (likely(tag_last - prev_page <= TARGET_PAGE_SIZE)) { +> /* Memory access stays on one page. */ +> - tag_size = (tag_byte_end - tag_byte_first) / (2 * TAG_GRANULE); +> + tag_size = ((tag_byte_last - tag_byte_first) / (2 * TAG_GRANULE)) + 1; +> mem1 = allocation_tag_mem(env, mmu_idx, ptr, type, total, +> MMU_DATA_LOAD, tag_size, ra); +> if (!mem1) { +> @@ -815,9 +813,9 @@ uint64_t mte_checkN(CPUARMState *env, uint32_t desc, +> mem1 = allocation_tag_mem(env, mmu_idx, ptr, type, next_page - ptr, +> MMU_DATA_LOAD, tag_size, ra); +> +> - tag_size = (tag_byte_end - next_page) / (2 * TAG_GRANULE); +> + tag_size = ((tag_byte_last - next_page) / (2 * TAG_GRANULE)) + 1; +> mem2 = allocation_tag_mem(env, mmu_idx, next_page, type, +> - ptr_end - next_page, +> + ptr_last - next_page + 1, +> MMU_DATA_LOAD, tag_size, ra); +> +> /* +> @@ -838,15 +836,13 @@ uint64_t mte_checkN(CPUARMState *env, uint32_t desc, +> } +> +> /* +> - * If we failed, we know which granule. Compute the element that +> - * is first in that granule, and signal failure on that element. +> + * If we failed, we know which granule. For the first granule, the +> + * failure address is @ptr, the first byte accessed. Otherwise the +> + * failure address is the first byte of the nth granule. +> */ +> if (unlikely(n < tag_count)) { +> - uint64_t fail_ofs; +> - +> - fail_ofs = tag_first + n * TAG_GRANULE - ptr; +> - fail_ofs = ROUND_UP(fail_ofs, esize); +> - mte_check_fail(env, desc, ptr + fail_ofs, ra); +> + uint64_t fault = (n == 0 ? ptr : tag_first + n * TAG_GRANULE); +> + mte_check_fail(env, desc, fault, ra); +> } +> +> done: + + +-- +Alex Bennée + + +This warning is caused by "virtualization=on" QEMU option. This is another QEMU bug AFAIU, see [1] and [2]. + +[1] https://lore.kernel<email address hidden>/ +[2] https://<email address hidden>/T/ + +It gets further without but still spams a lot of failure messages: + +The buggy address belongs to the object at ffffff80036a2200 + which belongs to the cache kmalloc-128 of size 128 +The buggy address is located 11 bytes to the right of + 128-byte region [ffffff80036a2200, ffffff80036a2280) +The buggy address belongs to the page: +page:0000000046e01872 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x436a2 +flags: 0x3fc0000000000200(slab) +raw: 3fc0000000000200 dead000000000100 dead000000000122 f9ffff8001c01e00 +raw: 0000000000000000 0000000080100010 00000001ffffffff f3ffff80036a2401 +page dumped because: kasan: bad access detected +pages's memcg:f3ffff80036a2401 + +Memory state around the buggy address: + ffffff80036a2000: f6 f6 f6 f6 f6 f6 f6 f6 fe fe fe fe fe fe fe fe + ffffff80036a2100: fa fa fa fa fe fe fe fe fe fe fe fe fe fe fe fe +>ffffff80036a2200: f9 f9 f9 f9 f9 f9 f9 f9 fe fe fe fe fe fe fe fe + ^ + ffffff80036a2300: fc fc fc fc fe fe fe fe fe fe fe fe fe fe fe fe + ffffff80036a2400: f3 f3 f3 f3 f3 f3 f3 f3 fe fe fe fe fe fe fe fe +================================================================== +Disabling lock debugging due to kernel taint + # kmalloc_oob_right: EXPECTATION FAILED at lib/test_kasan.c:86 + Expected fail_data.report_expected == fail_data.report_found, but + fail_data.report_expected == 1 + fail_data.report_found == 0 + not ok 1 - kmalloc_oob_right + # kmalloc_oob_left: EXPECTATION FAILED at lib/test_kasan.c:98 + Expected fail_data.report_expected == fail_data.report_found, but + fail_data.report_expected == 1 + fail_data.report_found == 0 + not ok 2 - kmalloc_oob_left + # kmalloc_node_oob_right: EXPECTATION FAILED at lib/test_kasan.c:110 + Expected fail_data.report_expected == fail_data.report_found, but + fail_data.report_expected == 1 + fail_data.report_found == 0 + not ok 3 - kmalloc_node_oob_right + # kmalloc_pagealloc_oob_right: EXPECTATION FAILED at lib/test_kasan.c:130 + Expected fail_data.report_expected == fail_data.report_found, but + fail_data.report_expected == 1 + fail_data.report_found == 0 + not ok 4 - kmalloc_pagealloc_oob_right + # kmalloc_pagealloc_uaf: EXPECTATION FAILED at lib/test_kasan.c:148 + Expected fail_data.report_expected == fail_data.report_found, but + fail_data.report_expected == 1 + fail_data.report_found == 0 + not ok 5 - kmalloc_pagealloc_uaf + + +Is this with QEMU master without the patches mentioned in this bug? + +Which kernel version do you use? + +Could you share your kernel config? + +Re comments #8 and #10, I don't replicate that. +I get full pass on KASAN_UNIT_TEST with +and without virtualization enabled. + +Re comment #9, if there are bugs suspected in qemu, they +need to be reported, or we'll never hear about them. + + +Andrey Konovalov <email address hidden> writes: + +> Is this with QEMU master without the patches mentioned in this bug? + +This is with Richard's latest series. + +> +> Which kernel version do you use? + +v5.11 + +> Could you share your kernel config? + +We are just testing with Richard's config and eliminating compiler +shenanigans now. + + +-- +Alex Bennée + + + +Alex Bennée <email address hidden> writes: + +> Andrey Konovalov <email address hidden> writes: +> +>> Is this with QEMU master without the patches mentioned in this bug? +> +> This is with Richard's latest series. +> +>> +>> Which kernel version do you use? +> +> v5.11 +> +>> Could you share your kernel config? +> +> We are just testing with Richard's config and eliminating compiler +> shenanigans now. + +OK with v5.12-rc5 and Richard's config I get a clean pass. + + +-- +Alex Bennée + + +Ah, there's v4 now. + +Tested with KASAN tests + a custom test to check unaligned accesses that span across two granules, everything works. + +Thank you! + +On Wed, 7 Apr 2021 at 19:54, Alex Bennée <email address hidden> wrote: +> +> +> Richard Henderson <email address hidden> writes: +> +> > We were incorrectly assuming that only the first byte of an MTE access +> > is checked against the tags. But per the ARM, unaligned accesses are +> > pre-decomposed into single-byte accesses. So by the time we reach the +> > actual MTE check in the ARM pseudocode, all accesses are aligned. +> > +> > Therefore, the first failure is always either the first byte of the +> > access, or the first byte of the granule. +> > +> > In addition, some of the arithmetic is off for last-first -> count. +> > This does not become directly visible until a later patch that passes +> > single bytes into this function, so ptr == ptr_last. +> > +> > Buglink: https://bugs.launchpad.net/bugs/1921948 +> +> Minor note: you can Cc: Bug 1921948 <email address hidden> to +> automatically copy patches to the appropriate bugs which is useful if +> you don't have the Cc for the reporter. + +I'm not sure cc'ing bugs on patches is very useful, though (and especially +not for big series). I usually prefer to just add a note to the bug with +the URL of the series in patchew afterwards. + +-- PMM + + + +Richard Henderson <email address hidden> writes: + +> On 4/7/21 11:39 AM, Alex Bennée wrote: +>> Richard Henderson <email address hidden> writes: +>> +>>> We were incorrectly assuming that only the first byte of an MTE access +>>> is checked against the tags. But per the ARM, unaligned accesses are +>>> pre-decomposed into single-byte accesses. So by the time we reach the +>>> actual MTE check in the ARM pseudocode, all accesses are aligned. +>>> +>>> Therefore, the first failure is always either the first byte of the +>>> access, or the first byte of the granule. +>>> +<snip> + +I replicated the original test case as a kunit test: + + static void kmalloc_node_oob_span_right(struct kunit *test) + { + char *ptr; + size_t size = 128; + + ptr = kmalloc_node(size, GFP_KERNEL, 0); + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr); + + KUNIT_EXPECT_KASAN_FAIL(test, *(volatile unsigned long *)(ptr + 124) = 0); + kfree(ptr); + } + +which before this fix triggered: + + [ 6.753429] # kmalloc_node_oob_span_right: EXPECTATION FAILED at lib/test_kasan.c:163 + [ 6.753429] Expected ({ do { extern void __compiletime_assert_337(void) __attribute__((__error__("Unsupported access size for {READ,WRITE}_ONCE()."))); if (!((sizeof( + fail_data.report_expected) == sizeof(char) || sizeof(fail_data.report_expected) == sizeof(short) || sizeof(fail_data.report_expected) == sizeof(int) || sizeof(fail_data.repo + rt_expected) == sizeof(long)) || sizeof(fail_data.report_expected) == sizeof(long long))) __compiletime_assert_337(); } while (0); (*(const volatile typeof( _Generic((fail_d + ata.report_expected), char: (char)0, unsigned char: (unsigned char)0, signed char: (signed char)0, unsigned short: (unsigned short)0, signed short: (signed short)0, unsigned + int: (unsigned int)0, signed int: (signed int)0, unsigned long: (unsigned long)0, signed long: (signed long)0, unsigned long long: (unsigned long long)0, signed long long: + (signed long long)0, default: (fail_data.report_expected))) * + [ 6.759388] not ok 4 - kmalloc_node_oob_span_right + +And is OK by the end of the series: + + [ 6.587381] The buggy address belongs to the object at ffff000003325800 + [ 6.587381] which belongs to the cache kmalloc-128 of size 128 + [ 6.588372] The buggy address is located 0 bytes to the right of + [ 6.588372] 128-byte region [ffff000003325800, ffff000003325880) + [ 6.589354] The buggy address belongs to the page: + [ 6.589948] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x43325 + [ 6.590911] flags: 0x3fffc0000000200(slab) + [ 6.591648] raw: 03fffc0000000200 dead000000000100 dead000000000122 fdff000002401200 + [ 6.592346] raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 + [ 6.593007] page dumped because: kasan: bad access detected + [ 6.593532] + [ 6.593775] Memory state around the buggy address: + [ 6.594360] ffff000003325600: f3 f3 f3 f3 f3 f3 f3 f3 fe fe fe fe fe fe fe fe + [ 6.594991] ffff000003325700: fd fd fd fd fd fd fd fd fe fe fe fe fe fe fe fe + [ 6.595594] >ffff000003325800: f8 f8 f8 f8 f8 f8 f8 f8 fe fe fe fe fe fe fe fe + [ 6.596180] ^ + [ 6.596714] ffff000003325900: f7 f7 f7 f7 fe fe fe fe fe fe fe fe fe fe fe fe + [ 6.597309] ffff000003325a00: f4 f4 fe fe fe fe fe fe fe fe fe fe fe fe fe fe + [ 6.597925] ================================================================== + [ 6.598513] Disabling lock debugging due to kernel taint + [ 6.600353] ok 1 - kmalloc_node_oob_span_right + [ 6.600554] ok 1 - kasan + +But it still fails this patch until: + + target/arm: Fix unaligned checks for mte_check1, mte_probe1 + +So I guess that is the one that should have the buglink. + +Anyway code wise: + +Reviewed-by: Alex Bennée <email address hidden> + +-- +Alex Bennée + + + +Peter Maydell <email address hidden> writes: + +> On Wed, 7 Apr 2021 at 19:54, Alex Bennée <email address hidden> wrote: +>> +>> +>> Richard Henderson <email address hidden> writes: +>> +>> > We were incorrectly assuming that only the first byte of an MTE access +>> > is checked against the tags. But per the ARM, unaligned accesses are +>> > pre-decomposed into single-byte accesses. So by the time we reach the +>> > actual MTE check in the ARM pseudocode, all accesses are aligned. +>> > +>> > Therefore, the first failure is always either the first byte of the +>> > access, or the first byte of the granule. +>> > +>> > In addition, some of the arithmetic is off for last-first -> count. +>> > This does not become directly visible until a later patch that passes +>> > single bytes into this function, so ptr == ptr_last. +>> > +>> > Buglink: https://bugs.launchpad.net/bugs/1921948 +>> +>> Minor note: you can Cc: Bug 1921948 <email address hidden> to +>> automatically copy patches to the appropriate bugs which is useful if +>> you don't have the Cc for the reporter. +> +> I'm not sure cc'ing bugs on patches is very useful, though (and especially +> not for big series). I usually prefer to just add a note to the bug with +> the URL of the series in patchew afterwards. + +Ideally the tooling would pick up bug links in Patchew and automatically +update the relevant bugs when new series are posted. I only mentioned it +because the original bug reporters weren't Cc'ed on the patches and lo +now they know about the iteration they have tested it ;-) + +-- +Alex Bennée + + +It looks like there's still a bug here: I'm seeing false positive MTE faults for unaligned accesses that touch multiple pages. This userspace assembly program demonstrates the problem, but for some reason it only reproduces some of the time for me: + +.arch_extension memtag + +.globl _start +_start: +mov x0, #0x37 // PR_SET_TAGGED_ADDR_CTRL +mov x1, #0x3 // PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_ASYNC +mov x2, #0 +mov x3, #0 +mov x4, #0 +mov x8, #0xa7 // prctl +svc #0 + +mov x0, xzr +mov w1, #0x2000 +mov w2, #0x23 // PROT_READ|PROT_WRITE|PROT_MTE +mov w3, #0x22 // MAP_PRIVATE|MAP_ANONYMOUS +mov w4, #0xffffffff +mov x5, xzr +mov x8, #0xde // mmap +svc #0 + +mov x1, #(1 << 56) +add x0, x0, x1 +add x0, x0, #0xff0 +stg x0, [x0] +stg x0, [x0, #16] +str x1, [x0, #12] + +mov x0, #0 +mov x8, #0x5d // exit +svc #0 + +(s/PR_MTE_TCF_ASYNC/PR_MTE_TCF_SYNC/g in the above program -- but the actual constant is correct) + +I see something similar in memset + +It SEGV on +stur q0, [x4, #-16] +for x4 set to 0xd000055214fe008 + +and near tags are 0xd000055214fdff0 and 0xd000055214fe000 + +I happened to notice that you're moving your bug tracker to gitlab so I refiled this issue over there: https://gitlab.com/qemu-project/qemu/-/issues/403 + +Thanks for opening the new ticket. I'm closing this one here on Launchpad now so that we don't accidentally migrate it later automatically. + diff --git a/results/classifier/118/permissions/1922617 b/results/classifier/118/permissions/1922617 new file mode 100644 index 00000000..26f62603 --- /dev/null +++ b/results/classifier/118/permissions/1922617 @@ -0,0 +1,272 @@ +permissions: 0.935 +virtual: 0.898 +debug: 0.877 +graphic: 0.868 +register: 0.868 +device: 0.862 +architecture: 0.861 +arm: 0.840 +PID: 0.832 +boot: 0.829 +performance: 0.829 +assembly: 0.828 +TCG: 0.813 +socket: 0.810 +semantic: 0.809 +ppc: 0.802 +VMM: 0.799 +files: 0.795 +risc-v: 0.790 +user-level: 0.790 +kernel: 0.782 +vnc: 0.780 +network: 0.767 +peripherals: 0.730 +mistranslation: 0.708 +hypervisor: 0.664 +x86: 0.646 +KVM: 0.625 +i386: 0.466 + +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/118/permissions/1923583 b/results/classifier/118/permissions/1923583 new file mode 100644 index 00000000..acbed598 --- /dev/null +++ b/results/classifier/118/permissions/1923583 @@ -0,0 +1,102 @@ +permissions: 0.878 +semantic: 0.842 +debug: 0.838 +PID: 0.837 +virtual: 0.832 +graphic: 0.827 +socket: 0.813 +architecture: 0.812 +performance: 0.803 +device: 0.800 +user-level: 0.800 +files: 0.794 +assembly: 0.793 +peripherals: 0.787 +kernel: 0.785 +TCG: 0.780 +ppc: 0.776 +boot: 0.774 +vnc: 0.746 +network: 0.745 +arm: 0.745 +mistranslation: 0.745 +KVM: 0.741 +register: 0.727 +hypervisor: 0.718 +VMM: 0.689 +risc-v: 0.689 +x86: 0.677 +i386: 0.626 + +colo: pvm flush failed after svm killed + +Hi, + Primary vm flush failed after killing svm, which leads primary vm guest filesystem unavailable. + +qemu versoin: 5.2.0 +host/guest os: CentOS Linux release 7.6.1810 (Core) + +Reproduce steps: +1. create colo vm following https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt +2. kill secondary vm (don't remove nbd child from quorum on primary vm)and wait for a minute. the interval depends on guest os. +result: primary vm file system shutdown because of flush cache error. + +After serveral tests, I found that qemu-5.0.0 worked well, and it's the commit https://git.qemu.org/?p=qemu.git;a=commit;h=883833e29cb800b4d92b5d4736252f4004885191(block: Flush all children in generic code) leads this change, and both virtio-blk and ide turned out to be bad. + +I think it's nbd(replication) flush failed leads bdrv_co_flush(quorum_bs) failed, here is the call stack. +#0 bdrv_co_flush (bs=0x56242b3cc0b0=nbd_bs) at ../block/io.c:2856 +#1 0x0000562428b0f399 in bdrv_co_flush (bs=0x56242b3c7e00=replication_bs) at ../block/io.c:2920 +#2 0x0000562428b0f399 in bdrv_co_flush (bs=0x56242a4ad800=quorum_bs) at ../block/io.c:2920 +#3 0x0000562428b70d56 in blk_do_flush (blk=0x56242a4ad4a0) at ../block/block-backend.c:1672 +#4 0x0000562428b70d87 in blk_aio_flush_entry (opaque=0x7fd0980073f0) at ../block/block-backend.c:1680 +#5 0x0000562428c5f9a7 in coroutine_trampoline (i0=-1409269904, i1=32721) at ../util/coroutine-ucontext.c:173 + +While i am not sure whether i use colo inproperly? Can we assume that nbd child of quorum immediately removed right after svm crashed? Or it's really a bug? Does the following patch fix? Help is needed! Thanks a lot！ + +diff --git a/block/quorum.c b/block/quorum.c +index cfc1436..f2c0805 100644 +--- a/block/quorum.c ++++ b/block/quorum.c +@@ -1279,7 +1279,7 @@ static BlockDriver bdrv_quorum = { + .bdrv_dirname = quorum_dirname, + .bdrv_co_block_status = quorum_co_block_status, + +- .bdrv_co_flush_to_disk = quorum_co_flush, ++ .bdrv_co_flush = quorum_co_flush, + + .bdrv_getlength = quorum_getlength, + + + +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. + + +https://git.qemu.org/?p=qemu.git;a=commit;h=5529b02da2dcd1ef6bc6cd42d4fbfb537fe2276f + diff --git a/results/classifier/118/permissions/1925512 b/results/classifier/118/permissions/1925512 new file mode 100644 index 00000000..1b5a361b --- /dev/null +++ b/results/classifier/118/permissions/1925512 @@ -0,0 +1,148 @@ +permissions: 0.954 +device: 0.908 +architecture: 0.904 +arm: 0.903 +risc-v: 0.897 +performance: 0.881 +semantic: 0.880 +hypervisor: 0.877 +peripherals: 0.859 +register: 0.857 +debug: 0.855 +PID: 0.847 +mistranslation: 0.837 +VMM: 0.824 +virtual: 0.819 +user-level: 0.812 +ppc: 0.809 +assembly: 0.804 +socket: 0.803 +TCG: 0.799 +files: 0.791 +network: 0.743 +boot: 0.720 +vnc: 0.719 +graphic: 0.718 +KVM: 0.711 +kernel: 0.584 +x86: 0.549 +i386: 0.346 + +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/118/permissions/1967248 b/results/classifier/118/permissions/1967248 new file mode 100644 index 00000000..18091c54 --- /dev/null +++ b/results/classifier/118/permissions/1967248 @@ -0,0 +1,74 @@ +permissions: 0.966 +semantic: 0.933 +device: 0.914 +PID: 0.911 +graphic: 0.907 +architecture: 0.899 +debug: 0.891 +register: 0.890 +performance: 0.873 +arm: 0.866 +files: 0.864 +peripherals: 0.845 +boot: 0.837 +virtual: 0.814 +assembly: 0.807 +ppc: 0.796 +TCG: 0.785 +kernel: 0.777 +user-level: 0.773 +vnc: 0.730 +mistranslation: 0.729 +hypervisor: 0.705 +risc-v: 0.602 +network: 0.586 +x86: 0.552 +VMM: 0.541 +KVM: 0.499 +socket: 0.470 +i386: 0.346 + +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/118/permissions/2133 b/results/classifier/118/permissions/2133 new file mode 100644 index 00000000..ebc320ff --- /dev/null +++ b/results/classifier/118/permissions/2133 @@ -0,0 +1,85 @@ +permissions: 0.894 +debug: 0.878 +graphic: 0.872 +boot: 0.835 +architecture: 0.829 +user-level: 0.824 +register: 0.822 +virtual: 0.821 +semantic: 0.818 +PID: 0.814 +arm: 0.812 +device: 0.803 +assembly: 0.789 +performance: 0.776 +files: 0.765 +kernel: 0.760 +socket: 0.741 +vnc: 0.727 +peripherals: 0.725 +ppc: 0.714 +hypervisor: 0.711 +risc-v: 0.710 +network: 0.709 +TCG: 0.701 +KVM: 0.696 +VMM: 0.691 +mistranslation: 0.686 +x86: 0.667 +i386: 0.625 + +Debian sparc64 works on hardware, segfaults in qemu +Description of problem: + +Steps to reproduce: +1. Start the installer normally (boot cdrom), use guided all disk partition, change ext4 to btrfs for / +2. Installer always segfaults at the same place while installing base system step: + +``` +Jan 28 09:17:48 debootstrap: Setting up mawk (1.3.4.20200120-3.1) ... +Jan 28 09:17:49 debootstrap: update-alternatives: +Jan 28 09:17:49 debootstrap: using /usr/bin/mawk to provide /usr/bin/awk (awk) i +n auto mode +Jan 28 09:17:49 debootstrap: +Jan 28 09:17:54 debootstrap: Selecting previously unselected package debconf. +Jan 28 09:17:54 debootstrap: (Reading database ... 1459 files and directories cu +rrently installed.) +Jan 28 09:17:54 debootstrap: Preparing to unpack .../debconf_1.5.82_all.deb ... +Jan 28 09:17:54 debootstrap: Unpacking debconf (1.5.82) ... +Jan 28 09:17:55 kernel: [ 2994.426867] dpkg-deb[12709]: segfault at ffffffffffff +ffff ip fffff80100a1c3ec (rpc 0000000000000030) sp fffff80102402041 error 1 in l +iblzma.so.5.4.1[fffff80100a00000+2a000] +Jan 28 09:17:55 debootstrap: dpkg-deb: error: <decompress> subprocess was killed + by signal (Segmentation fault) +Jan 28 09:17:56 debootstrap: dpkg: error processing archive /var/cache/apt/archi +ves/debconf_1.5.82_all.deb (--install): +Jan 28 09:17:56 debootstrap: dpkg-deb --fsys-tarfile subprocess returned error +exit status 2 +Jan 28 09:17:57 debootstrap: Errors were encountered while processing: +Jan 28 09:17:57 debootstrap: /var/cache/apt/archives/debconf_1.5.82_all.deb +Jan 28 09:18:10 base-installer: error: exiting on error base-installer/debootstr + + +cd /target/var/cache/apt/archives +# ar x debconf_1.5.82_all.deb +/target/var/cache/apt/archives # unxz data.tar.xz +/target/var/cache/apt/archives # unxz control.tar.xz +``` +another try, to ext2 fs: +``` +Jan 28 10:31:16 debootstrap: Preparing to unpack .../dpkg_1.21.21_sparc64.deb .. +. +Jan 28 10:31:16 debootstrap: Unpacking dpkg (1.21.21) over (1.21.21) ... +Jan 28 10:31:23 kernel: [ 7402.528016] dpkg-deb[20720]: segfault at 7240015 ip f +ffff8010091def4 (rpc 000000006e17c498) sp fffff80103124041 error 1 in liblzma.so +.5.4.1[fffff80100900000+2a000] +Jan 28 10:31:23 debootstrap: dpkg-deb: error: <decompress> subprocess was killed + by signal (Segmentation fault) +Jan 28 10:31:24 debootstrap: dpkg: error processing archive /var/cache/apt/archi +ves/dpkg_1.21.21_sparc64.deb (--install): +Jan 28 10:31:24 debootstrap: cannot copy extracted data for './usr/share/doc/dp +kg/changelog.gz' to '/usr/share/doc/dpkg/changelog.gz.dpkg-new': unexpected end +of file or stream +``` +Additional information: +All times i've tried under Ubuntu qemu or latest build for Windows it segfaults unpacking package, and i believe it's a misleading error message, since very same ISO installs normally on Sun Fire T1000 machine (sun4v). I've tried also booting FreeBSD-12.4-RELEASE-sparc64-disc1.iso which dies shortly after booting the kernel, but i am more interested in Debian, since it was verified to work on a real hardware. BTW i was able to unpack specified file with "ar x" within installer. diff --git a/results/classifier/118/permissions/2157 b/results/classifier/118/permissions/2157 new file mode 100644 index 00000000..97b702f9 --- /dev/null +++ b/results/classifier/118/permissions/2157 @@ -0,0 +1,73 @@ +x86: 0.971 +permissions: 0.951 +architecture: 0.930 +graphic: 0.889 +i386: 0.872 +user-level: 0.859 +device: 0.855 +performance: 0.822 +PID: 0.809 +ppc: 0.801 +files: 0.788 +kernel: 0.786 +peripherals: 0.768 +socket: 0.747 +vnc: 0.746 +network: 0.744 +register: 0.726 +hypervisor: 0.662 +VMM: 0.658 +risc-v: 0.587 +TCG: 0.583 +debug: 0.558 +semantic: 0.524 +arm: 0.523 +assembly: 0.487 +boot: 0.478 +KVM: 0.367 +mistranslation: 0.349 +virtual: 0.332 + +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/118/permissions/2261 b/results/classifier/118/permissions/2261 new file mode 100644 index 00000000..011aeffa --- /dev/null +++ b/results/classifier/118/permissions/2261 @@ -0,0 +1,117 @@ +permissions: 0.872 +architecture: 0.846 +hypervisor: 0.842 +register: 0.833 +performance: 0.821 +virtual: 0.820 +assembly: 0.810 +graphic: 0.805 +network: 0.795 +arm: 0.793 +semantic: 0.788 +peripherals: 0.788 +device: 0.782 +debug: 0.782 +x86: 0.775 +risc-v: 0.772 +TCG: 0.760 +PID: 0.752 +mistranslation: 0.719 +ppc: 0.717 +user-level: 0.713 +i386: 0.710 +boot: 0.707 +kernel: 0.706 +vnc: 0.690 +KVM: 0.688 +socket: 0.677 +VMM: 0.672 +files: 0.565 + +qemu-system-x86_64 crashs in cursor_put functions +Description of problem: +This problem cannot be stably reproduced，but we try enable --enable-sanitizers and catch the following information，why qemu_spice_cursor_refresh_bh be called twice at the same time？ + +==57296==ERROR: AddressSanitizer: heap-use-after-free on address 0x623000738110 at pc 0x55cec2ed06aa bp 0x7ffc54d1fea0 sp 0x7ffc54d1fe90 +READ of size 4 at 0x623000738110 thread T0 + #0 0x55cec2ed06a9 in cursor_put ../qemu-6.0.1/ui/cursor.c:112 + #1 0x55cec2f05d40 in vnc_dpy_cursor_define ../qemu-6.0.1/ui/vnc.c:1041 + #2 0x55cec2ec6352 in dpy_cursor_define ../qemu-6.0.1/ui/console.c:1841 + #3 0x55cec3ab176c in qemu_spice_cursor_refresh_bh ../qemu-6.0.1/ui/spice-display.c:469 + #4 0x55cec4abc6eb in aio_bh_call ../qemu-6.0.1/util/async.c:136 + #5 0x55cec4abce43 in aio_bh_poll ../qemu-6.0.1/util/async.c:164 + #6 0x55cec4a5f457 in aio_dispatch ../qemu-6.0.1/util/aio-posix.c:381 + #7 0x55cec4abe386 in aio_ctx_dispatch ../qemu-6.0.1/util/async.c:306 + #8 0x7fa4fadcdd3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) + #9 0x55cec4b0b5d6 in glib_pollfds_poll ../qemu-6.0.1/util/main-loop.c:231 + #10 0x55cec4b0b7c0 in os_host_main_loop_wait ../qemu-6.0.1/util/main-loop.c:254 + #11 0x55cec4b0bac5 in main_loop_wait ../qemu-6.0.1/util/main-loop.c:530 + #12 0x55cec3f49e70 in qemu_main_loop ../qemu-6.0.1/softmmu/runstate.c:786 + #13 0x55cec2e7f679 in main ../qemu-6.0.1/softmmu/main.c:50 + #14 0x7fa4f96f4d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #15 0x7fa4f96f4e3f in __libc_start_main_impl ../csu/libc-start.c:392 + #16 0x55cec2e7f584 in _start (/usr/bin/qemu-system-x86_64+0x298a584) + +0x623000738110 is located 16 bytes inside of 6416-byte region [0x623000738100,0x623000739a10) +freed by thread T0 here: + #0 0x7fa4fb7d9537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 + #1 0x55cec2ed0769 in cursor_put ../qemu-6.0.1/ui/cursor.c:115 + #2 0x55cec3ab1818 in qemu_spice_cursor_refresh_bh ../qemu-6.0.1/ui/spice-display.c:471 + #3 0x55cec4abc6eb in aio_bh_call ../qemu-6.0.1/util/async.c:136 + #4 0x55cec4abce43 in aio_bh_poll ../qemu-6.0.1/util/async.c:164 + #5 0x55cec4a5f457 in aio_dispatch ../qemu-6.0.1/util/aio-posix.c:381 + #6 0x55cec4abe386 in aio_ctx_dispatch ../qemu-6.0.1/util/async.c:306 + #7 0x7fa4fadcdd3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) + +previously allocated by thread T14 here: + #0 0x7fa4fb7d9a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 + #1 0x7fa4fadd6c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) + #2 0x55cec3b16918 in qxl_cursor ../qemu-6.0.1/hw/display/qxl-render.c:361 + #3 0x55cec3b18698 in qxl_render_cursor ../qemu-6.0.1/hw/display/qxl-render.c:448 + #4 0x55cec3af53a5 in interface_get_cursor_command ../qemu-6.0.1/hw/display/qxl.c:856 + #5 0x7fa4fb39ca1f in red_process_cursor ../../server/red-worker.c:152 + #6 0x7fa4fb39ca1f in red_process_cursor ../../server/red-worker.c:140 + +Thread T14 created by T0 here: + #0 0x7fa4fb77d685 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:216 + #1 0x7fa4fb39ece5 in red_worker_run ../../server/red-worker.c:1588 + #2 0x62100002d94f (<unknown module>) + +SUMMARY: AddressSanitizer: heap-use-after-free ../qemu-6.0.1/ui/cursor.c:112 in cursor_put +Shadow bytes around the buggy address: + 0x0c46800defd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c46800defe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c46800deff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c46800df000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c46800df010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +=>0x0c46800df020: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df030: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df040: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df050: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df060: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c46800df070: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==57296==ABORTING +Steps to reproduce: +This problem cannot be stably reproduced +Additional information: +/label ~"kind::Bug" diff --git a/results/classifier/118/permissions/2296 b/results/classifier/118/permissions/2296 new file mode 100644 index 00000000..3314b07d --- /dev/null +++ b/results/classifier/118/permissions/2296 @@ -0,0 +1,127 @@ +permissions: 0.803 +graphic: 0.772 +register: 0.758 +arm: 0.755 +virtual: 0.733 +user-level: 0.708 +assembly: 0.705 +PID: 0.704 +device: 0.698 +architecture: 0.693 +performance: 0.692 +debug: 0.689 +semantic: 0.668 +TCG: 0.647 +x86: 0.642 +ppc: 0.628 +boot: 0.628 +peripherals: 0.626 +mistranslation: 0.619 +risc-v: 0.601 +hypervisor: 0.591 +KVM: 0.581 +vnc: 0.562 +files: 0.540 +i386: 0.532 +VMM: 0.528 +network: 0.499 +kernel: 0.497 +socket: 0.391 + +heap-buffer-overflow in virtio-sound +Description of problem: +The following log reveals it: + +``` +==3191578==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000068620 at pc 0x55dadcde4ec5 bp 0x7ffe7f18aef0 sp 0x7ffe7f18aee0 +READ of size 8 at 0x602000068620 thread T0 + #0 0x55dadcde4ec4 in virtio_snd_handle_rx_xfer ../hw/audio/virtio-snd.c:988 + #1 0x55daddffbf5e in virtio_queue_notify ../hw/virtio/virtio.c:2296 + #2 0x55dadd6cff4a in virtio_pci_notify_write ../hw/virtio/virtio-pci.c:1721 + #3 0x55dade0ab336 in memory_region_write_accessor ../system/memory.c:497 + #4 0x55dade0af3d0 in access_with_adjusted_size ../system/memory.c:573 + #5 0x55dade0b5032 in memory_region_dispatch_write ../system/memory.c:1528 + #6 0x55dade0ebb62 in flatview_write_continue_step ../system/physmem.c:2713 + #7 0x55dade0ebfb2 in flatview_write_continue ../system/physmem.c:2743 + #8 0x55dade0ebfb2 in flatview_write ../system/physmem.c:2774 + #9 0x55dade0edd58 in address_space_write ../system/physmem.c:2894 + #10 0x55dadd809972 in qtest_process_command ../system/qtest.c:679 + #11 0x55dadd80c3e2 in qtest_process_inbuf ../system/qtest.c:811 + #12 0x55dade6e79a4 in fd_chr_read ../chardev/char-fd.c:72 + #13 0x7f79b0d29c43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) + #14 0x55dade998bcf in glib_pollfds_poll ../util/main-loop.c:287 + #15 0x55dade998bcf in os_host_main_loop_wait ../util/main-loop.c:310 + #16 0x55dade998bcf in main_loop_wait ../util/main-loop.c:589 + #17 0x55dadd810e00 in qemu_main_loop ../system/runstate.c:783 + #18 0x55dade2b703a in qemu_default_main ../system/main.c:37 + #19 0x7f79afe29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #20 0x7f79afe29e3f in __libc_start_main_impl ../csu/libc-start.c:392 + #21 0x55dadcb5a284 in _start (/home/joey/repo/qemu/build/qemu-system-x86_64+0x2ef6284) + +0x602000068620 is located 0 bytes to the right of 16-byte region [0x602000068610,0x602000068620) +allocated by thread T0 here: + #0 0x7f79b18b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 + #1 0x7f79b0d32c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) + #2 0x55dadebf5847 (/home/joey/repo/qemu/build/qemu-system-x86_64+0x4f91847) + +SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/audio/virtio-snd.c:988 in virtio_snd_handle_rx_xfer +Shadow bytes around the buggy address: + 0x0c0480005070: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa + 0x0c0480005080: fa fa 05 fa fa fa 07 fa fa fa 00 03 fa fa fd fd + 0x0c0480005090: fa fa fd fd fa fa fd fd fa fa fd fd fa fa 00 06 + 0x0c04800050a0: fa fa 00 00 fa fa 00 00 fa fa 00 01 fa fa 05 fa + 0x0c04800050b0: fa fa 00 03 fa fa 00 03 fa fa 00 01 fa fa 00 05 +=>0x0c04800050c0: fa fa 00 00[fa]fa 00 00 fa fa 00 04 fa fa 00 00 + 0x0c04800050d0: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fa + 0x0c04800050e0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa + 0x0c04800050f0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa + 0x0c0480005100: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fa + 0x0c0480005110: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd 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 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 -display none \ +-machine accel=qtest -m 512M -machine q35 -device \ +virtio-sound,audiodev=my_audiodev,streams=2 -audiodev \ +alsa,id=my_audiodev -qtest stdio +outl 0xcf8 0x80001804 +outw 0xcfc 0x06 +outl 0xcf8 0x80001820 +outl 0xcfc 0xe0008000 +write 0xe0008016 0x1 0x03 +write 0xe0008020 0x4 0x00901000 +write 0xe0008028 0x4 0x00a01000 +write 0xe000801c 0x1 0x01 +write 0xe000a004 0x1 0x40 +write 0x10c000 0x1 0x02 +write 0x109001 0x1 0xc0 +write 0x109002 0x1 0x10 +write 0x109008 0x1 0x04 +write 0x10a002 0x1 0x01 +write 0xe000b00d 0x1 0x00 +EOF +``` + +# Possible Fix + +check the user-assigned value in virtio_snd_set_config() diff --git a/results/classifier/118/permissions/2390 b/results/classifier/118/permissions/2390 new file mode 100644 index 00000000..1c3546e8 --- /dev/null +++ b/results/classifier/118/permissions/2390 @@ -0,0 +1,93 @@ +permissions: 0.950 +architecture: 0.896 +peripherals: 0.875 +graphic: 0.869 +socket: 0.840 +debug: 0.827 +arm: 0.812 +hypervisor: 0.806 +boot: 0.803 +register: 0.802 +user-level: 0.796 +device: 0.794 +files: 0.788 +PID: 0.784 +risc-v: 0.782 +TCG: 0.770 +network: 0.766 +performance: 0.761 +ppc: 0.759 +vnc: 0.720 +VMM: 0.687 +virtual: 0.572 +mistranslation: 0.564 +assembly: 0.553 +semantic: 0.532 +kernel: 0.434 +KVM: 0.406 +i386: 0.237 +x86: 0.208 + +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/118/permissions/2442 b/results/classifier/118/permissions/2442 new file mode 100644 index 00000000..edffad12 --- /dev/null +++ b/results/classifier/118/permissions/2442 @@ -0,0 +1,177 @@ +permissions: 0.937 +network: 0.925 +graphic: 0.924 +peripherals: 0.923 +debug: 0.921 +risc-v: 0.898 +architecture: 0.895 +semantic: 0.891 +arm: 0.883 +device: 0.881 +x86: 0.876 +boot: 0.873 +hypervisor: 0.872 +performance: 0.870 +register: 0.865 +kernel: 0.863 +socket: 0.856 +virtual: 0.855 +VMM: 0.845 +assembly: 0.842 +KVM: 0.835 +user-level: 0.831 +vnc: 0.824 +PID: 0.820 +ppc: 0.797 +files: 0.774 +TCG: 0.759 +mistranslation: 0.753 +i386: 0.551 + +kvm-unit-tests ept failed +Description of problem: +On the Sierra Forest and Emerald Rapids platform, the ept test in kvm-unit-tests failed on the latest QEMU. + +QEMU first bad commit is 0b2757412cb1d1947d7e2c1fe14985f1e72bba32. + +This bad commit also caused other errors, such as: + +1.kvm-unit-tests vmx_pf_invvpid_test + +Test suite: vmx_pf_invvpid_test + +Host skipping test: INVVPID ADDR unsupported + +filter = vmx_pf_invvpid_test, test = vmx_pf_vpid_test + +filter = vmx_pf_invvpid_test, test = vmx_exception_test + +SUMMARY: 0 tests + +SKIP vmx_pf_invvpid_test (0 tests) + +2.kvm-unit-tests vmx_pf_no_vpid_test + +Test suite: vmx_pf_no_vpid_test + +run + +x86/vmx_tests.c:10568: assert failed: false: Unexpected exit to L1, exit_reason: VMX_CR (0x1c) + STACK: 40717c 4072a3 402039 403f11 4001bd + +FAIL vmx_pf_no_vpid_test + +3.kvm-unit-tests vmx: + +Test suite: vmx_controls_test + +FAIL: Clear primary processor-based controls bit 15: vmlaunch fails + +FAIL: Clear primary processor-based controls bit 16: vmlaunch fails + +Test suite: vmx_mtf_test + +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000025 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0010'0101 - 37 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_MTF, got VMX_CR. + STACK: 406faa 407478 407911 402039 403f11 4001bd + +4.Failed to boot L2 guest on L1 windows guest, host does not support "Intel EPT" hardware assisted MMU virtualization. +Steps to reproduce: +1.git clone https://gitlab.com/kvm-unit-tests/kvm-unit-tests.git + +2.cd kvm-unit-tests; ./configure + +3.make standalone + +4.rmmod kvm_intel + +5.modprobe kvm_intel nested=Y allow_smaller_maxphyaddr=Y + +6.cd tests; ./ept +Additional information: +... +Test suite: ept_access_test_paddr_not_present_ad_disabled +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_VMCALL, got VMX_CR. + STACK: 406faa 40730c 416905 416cf2 416f68 402039 403f11 4001bd +filter = ept_access*, test = ept_access_test_paddr_not_present_ad_enabled + +Test suite: ept_access_test_paddr_not_present_ad_enabled +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_VMCALL, got VMX_CR. + STACK: 406faa 40730c 416905 416cf2 416f09 402039 403f11 4001bd +filter = ept_access*, test = ept_access_test_paddr_read_only_ad_disabled + +Test suite: ept_access_test_paddr_read_only_ad_disabled +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_VMCALL, got VMX_CR. + STACK: 406faa 40730c 416905 416cf2 417150 402039 403f11 4001bd +filter = ept_access*, test = ept_access_test_paddr_read_only_ad_enabled + +Test suite: ept_access_test_paddr_read_only_ad_enabled +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_VMCALL, got VMX_CR. + STACK: 406faa 40730c 416905 416cf2 416e14 402039 403f11 4001bd +filter = ept_access*, test = ept_access_test_paddr_read_write + +Test suite: ept_access_test_paddr_read_write +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_VMCALL, got VMX_CR. + STACK: 406faa 40730c 416905 416fb1 4170fb 402039 403f11 4001bd +filter = ept_access*, test = ept_access_test_paddr_read_write_execute + +Test suite: ept_access_test_paddr_read_write_execute +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_VMCALL, got VMX_CR. + STACK: 406faa 40730c 416905 416fb1 4170b0 402039 403f11 4001bd +filter = ept_access*, test = ept_access_test_paddr_read_execute_ad_disabled + +Test suite: ept_access_test_paddr_read_execute_ad_disabled +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_VMCALL, got VMX_CR. + STACK: 406faa 40730c 416905 416cf2 416fde 402039 403f11 4001bd +filter = ept_access*, test = ept_access_test_paddr_read_execute_ad_enabled + +Test suite: ept_access_test_paddr_read_execute_ad_enabled +FAIL: x86/vmx_tests.c:2164: Assertion failed: (expected) == (actual) + LHS: 0x0000000000000012 - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'0010 - 18 + RHS: 0x000000000000001c - 0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0000'0001'1100 - 28 +Expected VMX_VMCALL, got VMX_CR. + STACK: 406faa 40730c 416905 416cf2 416d1f 402039 403f11 4001bd +filter = ept_access*, test = ept_access_test_paddr_not_present_page_fault + +Test suite: ept_access_test_paddr_not_present_page_fault +filter = ept_access*, test = ept_access_test_force_2m_page + +Test suite: ept_access_test_force_2m_page +filter = ept_access*, test = atomic_switch_max_msrs_test +filter = ept_access*, test = atomic_switch_overflow_msrs_test +filter = ept_access*, test = rdtsc_vmexit_diff_test +filter = ept_access*, test = vmx_mtf_test +filter = ept_access*, test = vmx_mtf_pdpte_test +filter = ept_access*, test = vmx_pf_exception_test +filter = ept_access*, test = vmx_pf_exception_forced_emulation_test +filter = ept_access*, test = vmx_pf_no_vpid_test +filter = ept_access*, test = vmx_pf_invvpid_test +filter = ept_access*, test = vmx_pf_vpid_test +filter = ept_access*, test = vmx_exception_test +SUMMARY: 5824 tests, 8 unexpected failures +FAIL ept (5824 tests, 8 unexpected failures) + +[error.log](/uploads/407a04df83bae220bca6fad3c9bba9ff/error.log) diff --git a/results/classifier/118/permissions/2489 b/results/classifier/118/permissions/2489 new file mode 100644 index 00000000..73d0f834 --- /dev/null +++ b/results/classifier/118/permissions/2489 @@ -0,0 +1,122 @@ +permissions: 0.842 +debug: 0.837 +performance: 0.803 +register: 0.799 +graphic: 0.782 +device: 0.757 +ppc: 0.747 +socket: 0.736 +virtual: 0.735 +semantic: 0.727 +KVM: 0.725 +TCG: 0.717 +architecture: 0.713 +peripherals: 0.702 +user-level: 0.699 +risc-v: 0.690 +arm: 0.688 +vnc: 0.686 +files: 0.685 +VMM: 0.684 +assembly: 0.676 +x86: 0.675 +hypervisor: 0.660 +PID: 0.637 +i386: 0.636 +boot: 0.622 +mistranslation: 0.621 +network: 0.571 +kernel: 0.545 + +qemu-system-x86_64 TCG coredumps when using qemu_plugin_register_vcpu_mem_cb +Description of problem: +QEMU freezes, then exits with `Segmentation fault (core dumped)`. +Steps to reproduce: +1. Install Windows 7 SP1 into `disk.qcow2`. +2. Start the machine, and use `savevm snapshot` at the login screen, then exit. +3. `./qemu-system-x86_64 -m 1G -M q35 -drive file=disk.qcow2 -nic none -loadvm snapshot -plugin contrib/plugins/libexeclog.so` +Additional information: +QEMU runs normally without the plugin. + +This bug can also be reproduced with a simpler plugin just calling `qemu_plugin_register_vcpu_mem_cb` once per instruction: +[minimal_plugin.diff](/uploads/6e6c1af21df90379e726e693a53f7b8f/minimal_plugin.diff). + +Log using `-d op,in_asm,out_asm,plugin -D log`: [log.gz](/uploads/ccfd26c4845422d63f72a357f8fc1137/log.gz) + +GDB full backtrace: +``` +(gdb) bt f +#0 stw_he_p (v=0, ptr=0x2) at /REDACTED/qemu/include/qemu/bswap.h:265 +No locals. +#1 stw_le_p (v=0, ptr=0x2) at /REDACTED/qemu/include/qemu/bswap.h:319 +No locals. +#2 access_stw (ac=ac@entry=0x7f1652dfec70, addr=addr@entry=18446735827410705922, val=val@entry=0) at ../target/i386/tcg/access.c:143 + p = 0x2 +#3 0x000055dfca88534e in do_xsave_fpu (ac=ac@entry=0x7f1652dfec70, ptr=ptr@entry=18446735827410705920) at ../target/i386/tcg/fpu_helper.c:2537 + env = 0x55dff34fe630 + fpus = 0 + fptag = <optimized out> + i = <optimized out> + addr = <optimized out> +#4 0x000055dfca88caf8 in do_fxsave (ptr=18446735827410705920, ac=0x7f1652dfec70) at ../target/i386/tcg/fpu_helper.c:2632 + env = 0x55dff34fe630 + env = <optimized out> +#5 helper_fxsave (env=<optimized out>, ptr=18446735827410705920) at ../target/i386/tcg/fpu_helper.c:2656 + ra = <optimized out> + ac = {vaddr = 18446735827410705920, haddr1 = 0x0, haddr2 = 0x0, size = 512, size1 = 512, mmu_idx = 4, env = 0x55dff34fe630, + ra = 139732667533971} +#6 0x00007f160c030a93 in code_gen_buffer () +No locals. +#7 0x000055dfca979986 in cpu_tb_exec (cpu=cpu@entry=0x55dff34fbe70, itb=itb@entry=0x7f160c030940 <code_gen_buffer+198931>, + tb_exit=tb_exit@entry=0x7f1652dff228) at ../accel/tcg/cpu-exec.c:458 + ret = <optimized out> + last_tb = <optimized out> + tb_ptr = 0x7f160c030a00 <code_gen_buffer+199123> + __PRETTY_FUNCTION__ = "cpu_tb_exec" +#8 0x000055dfca979edd in cpu_loop_exec_tb (tb_exit=0x7f1652dff228, last_tb=<synthetic pointer>, pc=<optimized out>, + tb=0x7f160c030940 <code_gen_buffer+198931>, cpu=0x55dff34fbe70) at ../accel/tcg/cpu-exec.c:908 + insns_left = <optimized out> + __PRETTY_FUNCTION__ = "cpu_loop_exec_tb" + insns_left = <optimized out> + _a15 = <optimized out> + _b16 = <optimized out> +#9 cpu_exec_loop (cpu=cpu@entry=0x55dff34fbe70, sc=sc@entry=0x7f1652dff2c0) at ../accel/tcg/cpu-exec.c:1022 + tb = 0x7f160c030940 <code_gen_buffer+198931> + flags = <optimized out> + cflags = 4278321152 + pc = <optimized out> + cs_base = <optimized out> + last_tb = <optimized out> + tb_exit = 1 + ret = <optimized out> +#10 0x000055dfca97a6fd in cpu_exec_setjmp (cpu=cpu@entry=0x55dff34fbe70, sc=sc@entry=0x7f1652dff2c0) at ../accel/tcg/cpu-exec.c:1039 +No locals. +#11 0x000055dfca97ae79 in cpu_exec (cpu=cpu@entry=0x55dff34fbe70) at ../accel/tcg/cpu-exec.c:1065 + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0} + _rcu_read_auto = 0x1 +#12 0x000055dfca9a35af in tcg_cpu_exec (cpu=cpu@entry=0x55dff34fbe70) at ../accel/tcg/tcg-accel-ops.c:78 +--Type <RET> for more, q to quit, c to continue without paging--c + ret = <optimized out> + __PRETTY_FUNCTION__ = "tcg_cpu_exec" +#13 0x000055dfca9a3703 in mttcg_cpu_thread_fn (arg=arg@entry=0x55dff34fbe70) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 + r = <optimized out> + force_rcu = {notifier = {notify = 0x55dfca9a37f0 <mttcg_force_rcu>, node = {le_next = 0x0, le_prev = 0x7f1652e00528}}, cpu = 0x55dff34fbe70} + cpu = 0x55dff34fbe70 + __PRETTY_FUNCTION__ = "mttcg_cpu_thread_fn" + __func__ = "mttcg_cpu_thread_fn" +#14 0x000055dfcab7e898 in qemu_thread_start (args=0x55dff355dd80) at ../util/qemu-thread-posix.c:541 + __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {94420348558720, 3438567870158976394, -1656, 0, 140727865026624, 139734089805824, + 8803266606146106762, 3438582454403577226}, __mask_was_saved = 0}}, __pad = {0x7f1652dff430, 0x0, 0x0, 0x0}} + __cancel_routine = 0x55dfcab7e8f0 <qemu_thread_atexit_notify> + __cancel_arg = <optimized out> + __not_first_call = <optimized out> + qemu_thread_args = <optimized out> + start_routine = 0x55dfca9a3600 <mttcg_cpu_thread_fn> + arg = 0x55dff34fbe70 + r = <optimized out> +#15 0x00007f165e090272 in start_thread () from /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6 +No symbol table info available. +#16 0x00007f165e10bdec in clone3 () from /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6 +No symbol table info available. +``` diff --git a/results/classifier/118/permissions/2563 b/results/classifier/118/permissions/2563 new file mode 100644 index 00000000..ace94de8 --- /dev/null +++ b/results/classifier/118/permissions/2563 @@ -0,0 +1,240 @@ +permissions: 0.927 +virtual: 0.919 +peripherals: 0.912 +user-level: 0.901 +x86: 0.895 +hypervisor: 0.892 +register: 0.882 +vnc: 0.881 +graphic: 0.881 +network: 0.880 +boot: 0.879 +performance: 0.863 +architecture: 0.861 +socket: 0.854 +risc-v: 0.845 +TCG: 0.845 +ppc: 0.841 +PID: 0.840 +files: 0.840 +debug: 0.838 +device: 0.837 +arm: 0.826 +semantic: 0.820 +mistranslation: 0.817 +KVM: 0.816 +assembly: 0.793 +kernel: 0.773 +VMM: 0.733 +i386: 0.495 + +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/118/permissions/2592 b/results/classifier/118/permissions/2592 new file mode 100644 index 00000000..ca54710b --- /dev/null +++ b/results/classifier/118/permissions/2592 @@ -0,0 +1,67 @@ +permissions: 0.859 +semantic: 0.672 +graphic: 0.667 +architecture: 0.653 +device: 0.611 +performance: 0.577 +ppc: 0.557 +user-level: 0.534 +PID: 0.519 +files: 0.512 +mistranslation: 0.490 +TCG: 0.477 +network: 0.448 +socket: 0.434 +hypervisor: 0.431 +vnc: 0.426 +register: 0.403 +debug: 0.399 +risc-v: 0.356 +virtual: 0.341 +VMM: 0.319 +peripherals: 0.312 +boot: 0.287 +kernel: 0.254 +KVM: 0.218 +arm: 0.210 +i386: 0.192 +x86: 0.189 +assembly: 0.173 + +qemu-aarch64 cannot properly support some python functions from the `time` module +Description of problem: +When a function is run in python (for example, `time.time()`), python returns the following error: +``` +Traceback (most recent call last): + File "<string>", line 1, in <module> +OSError: [Errno 0] Error +``` +I am absolutely sure that this problem is related to `qemu-aarch64`, because the same python build works perfectly in aarch64 machine. In addition, python for arm architecture with `qemu-arm` does not have such a problem. +Steps to reproduce: +Note, this instruction specifies the stage of installation of that very python. But since it is compiled for Termux, you will have to use some scripts. +1. Create a simple codespace environment. +2. Run the following commands through the terminal: +``` +git clone https://github.com/termux-pacman/glibc-packages +cd glibc-packages +./get-build-package.sh +sudo mkdir /data +sudo chown codespace /data +sudo chgrp codespace /data +sudo apt update +sudo apt install patchelf +./scripts/setup-cgct.sh +``` +3. Run the following command. Note that the installation phase will start there. You should stop the script when the installation phase is complete. +``` +./build-package.sh -I -w --library glibc gpkg/gobject-introspection +``` +4. Install standard qemu via apt. +5. Run the following command: +``` +qemu-aarch64 /data/data/com.termux/files/usr/glibc/bin/python3.12 -c "import time; time.time()" +``` +Additional information: +- For some reason this error only occurs in the environment from GitHub. On my computer this error does not occur. + - Here is a log of one of the github actions, which shows an attempt to compile packages with python on different architectures - https://github.com/termux-pacman/glibc-packages/actions/runs/11023254502. +For reference, I use qemu for more flexible compilation of packages. And in github actions, qemu is installed here - https://github.com/termux-pacman/glibc-packages/blob/main/.github/workflows/build.yml#L35. diff --git a/results/classifier/118/permissions/2596 b/results/classifier/118/permissions/2596 new file mode 100644 index 00000000..eb90e716 --- /dev/null +++ b/results/classifier/118/permissions/2596 @@ -0,0 +1,31 @@ +permissions: 0.942 +user-level: 0.721 +debug: 0.715 +device: 0.627 +network: 0.474 +boot: 0.332 +mistranslation: 0.308 +arm: 0.220 +ppc: 0.216 +architecture: 0.185 +kernel: 0.184 +graphic: 0.174 +performance: 0.173 +semantic: 0.169 +peripherals: 0.132 +files: 0.128 +TCG: 0.077 +VMM: 0.071 +vnc: 0.071 +register: 0.061 +virtual: 0.061 +i386: 0.050 +socket: 0.034 +PID: 0.032 +risc-v: 0.020 +x86: 0.012 +hypervisor: 0.005 +assembly: 0.005 +KVM: 0.002 + +linux-user elf parsing endianness issue (Invalid note in PT_GNU_PROPERTY) diff --git a/results/classifier/118/permissions/2670 b/results/classifier/118/permissions/2670 new file mode 100644 index 00000000..3aa99bf2 --- /dev/null +++ b/results/classifier/118/permissions/2670 @@ -0,0 +1,74 @@ +permissions: 0.916 +network: 0.911 +architecture: 0.869 +vnc: 0.821 +files: 0.816 +device: 0.812 +kernel: 0.805 +PID: 0.800 +hypervisor: 0.797 +register: 0.766 +performance: 0.754 +ppc: 0.747 +socket: 0.742 +x86: 0.725 +i386: 0.716 +peripherals: 0.715 +boot: 0.712 +mistranslation: 0.703 +graphic: 0.685 +arm: 0.673 +virtual: 0.658 +VMM: 0.637 +risc-v: 0.595 +semantic: 0.590 +TCG: 0.576 +user-level: 0.564 +debug: 0.545 +KVM: 0.439 +assembly: 0.434 + +The virglrenderer depency causes qemu native recipe building to fail for NXP QEMU +Description of problem: +nativesdk-qemu-8.2.2.imx-r0 do_compile: oe_runmake failed +... + [87/4472] Compiling C object libcommon.fa.p/hw_display_virtio-gpu.c.o +| FAILED: libcommon.fa.p/hw_display_virtio-gpu.c.o +... + ../hw/display/virtio-gpu.c:36:10: fatal error: virglrenderer.h: No such file or directory +| 36 | #include <virglrenderer.h> +| | ^~~~~~~~~~~~~~~~~ +| compilation terminated. + +This issue was originally exposed after updating Yocto release to Scarthgap + +https://lists.yoctoproject.org/g/yocto/topic/building_sdk_fails_after/109275322 + +which seems to relate to commit https://github.com/nxp-imx/imx-qemu/commit/628105edbd816458dbf154a128cc3dd3ac809c7e that seemingly induces dependency to virglrenderer.h for virtio_gpu driver. + +Enabling opengl in our Distribution features is not a solution because that pulls in VGA graphics dependencies to our target binaries and we have no graphics hardware on our system. I have tried to disable the virglrenderer through QEMU build configuration but that does not fix the issue. +Steps to reproduce: +1. Clone NXP BSP Scarthgap +``` +$ mkdir nxp-bsp +$ cd nxp-bsp +nxp-bsp$ repo init -u https://github.com/nxp-imx/imx-manifest -b scarthgap -m imx-6.6.36-2.1.0.xml +nxp-bsp$ repo sync +``` + +2. Remove opengl from `fsl-imx-xwayland` DISTRO_FEATURES + +``` +sources/meta-imx/meta-imx-sdk/conf/distro/fsl-imx-wayland.conf: +... ++DISTRO_FEATURES:remove = "opengl " +... +``` + +3. Build qemu-native_8.2.2.imx + +``` +$ bitbake qemu-native_8.2.2.imx +``` +Additional information: + diff --git a/results/classifier/118/permissions/2704 b/results/classifier/118/permissions/2704 new file mode 100644 index 00000000..650b863d --- /dev/null +++ b/results/classifier/118/permissions/2704 @@ -0,0 +1,332 @@ +semantic: 0.940 +permissions: 0.936 +performance: 0.929 +debug: 0.927 +architecture: 0.918 +network: 0.917 +user-level: 0.917 +assembly: 0.916 +register: 0.916 +mistranslation: 0.906 +graphic: 0.905 +peripherals: 0.905 +boot: 0.901 +device: 0.881 +KVM: 0.877 +files: 0.876 +virtual: 0.858 +arm: 0.855 +risc-v: 0.855 +hypervisor: 0.827 +TCG: 0.818 +PID: 0.817 +kernel: 0.793 +VMM: 0.788 +socket: 0.784 +ppc: 0.777 +vnc: 0.740 +x86: 0.578 +i386: 0.343 + +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/118/permissions/2832 b/results/classifier/118/permissions/2832 new file mode 100644 index 00000000..bb3b9ce0 --- /dev/null +++ b/results/classifier/118/permissions/2832 @@ -0,0 +1,129 @@ +permissions: 0.937 +performance: 0.925 +semantic: 0.915 +PID: 0.911 +device: 0.909 +hypervisor: 0.905 +user-level: 0.903 +register: 0.899 +graphic: 0.899 +assembly: 0.890 +peripherals: 0.889 +architecture: 0.884 +debug: 0.867 +ppc: 0.854 +files: 0.846 +kernel: 0.844 +x86: 0.833 +boot: 0.830 +virtual: 0.822 +socket: 0.815 +mistranslation: 0.815 +arm: 0.809 +KVM: 0.808 +risc-v: 0.800 +network: 0.768 +TCG: 0.757 +vnc: 0.676 +VMM: 0.622 +i386: 0.502 + +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/118/permissions/342 b/results/classifier/118/permissions/342 new file mode 100644 index 00000000..907b97e7 --- /dev/null +++ b/results/classifier/118/permissions/342 @@ -0,0 +1,31 @@ +permissions: 0.971 +mistranslation: 0.952 +performance: 0.881 +device: 0.709 +debug: 0.648 +architecture: 0.625 +graphic: 0.596 +network: 0.581 +arm: 0.564 +semantic: 0.483 +ppc: 0.360 +i386: 0.301 +peripherals: 0.284 +assembly: 0.276 +VMM: 0.259 +risc-v: 0.248 +vnc: 0.244 +boot: 0.231 +TCG: 0.189 +KVM: 0.168 +socket: 0.163 +register: 0.162 +hypervisor: 0.138 +x86: 0.130 +files: 0.104 +user-level: 0.097 +kernel: 0.093 +PID: 0.089 +virtual: 0.066 + +Assertion `child->perm & BLK_PERM_WRITE' failed in bdrv_co_write_req_prepare through atapi diff --git a/results/classifier/118/permissions/35170175 b/results/classifier/118/permissions/35170175 new file mode 100644 index 00000000..5f129e48 --- /dev/null +++ b/results/classifier/118/permissions/35170175 @@ -0,0 +1,546 @@ +permissions: 0.870 +graphic: 0.844 +debug: 0.830 +virtual: 0.820 +performance: 0.818 +register: 0.808 +semantic: 0.798 +device: 0.787 +architecture: 0.783 +assembly: 0.767 +arm: 0.754 +boot: 0.719 +KVM: 0.709 +files: 0.706 +PID: 0.699 +x86: 0.698 +peripherals: 0.685 +socket: 0.681 +kernel: 0.679 +risc-v: 0.678 +user-level: 0.671 +network: 0.666 +hypervisor: 0.656 +mistranslation: 0.641 +vnc: 0.633 +TCG: 0.624 +VMM: 0.618 +ppc: 0.585 +i386: 0.545 + +[Qemu-devel] [BUG] QEMU crashes with dpdk virtio pmd + +Qemu crashes, with pre-condition: +vm xml config with multiqueue, and the vm's driver virtio-net support +multi-queue + +reproduce steps: +i. start dpdk testpmd in VM with the virtio nic +ii. stop testpmd +iii. reboot the VM + +This commit "f9d6dbf0 remove virtio queues if the guest doesn't support +multiqueue" is introduced. + +Qemu version: QEMU emulator version 2.9.50 (v2.9.0-137-g32c7e0a) +VM DPDK version: DPDK-1.6.1 + +Call Trace: +#0 0x00007f60881fe5d7 in raise () from /usr/lib64/libc.so.6 +#1 0x00007f60881ffcc8 in abort () from /usr/lib64/libc.so.6 +#2 0x00007f608823e2f7 in __libc_message () from /usr/lib64/libc.so.6 +#3 0x00007f60882456d3 in _int_free () from /usr/lib64/libc.so.6 +#4 0x00007f608900158f in g_free () from /usr/lib64/libglib-2.0.so.0 +#5 0x00007f6088fea32c in iter_remove_or_steal () from +/usr/lib64/libglib-2.0.so.0 +#6 0x00007f608edc0986 in object_property_del_all (obj=0x7f6091e74800) at +qom/object.c:410 +#7 object_finalize (data=0x7f6091e74800) at qom/object.c:467 +#8 object_unref (address@hidden) at qom/object.c:903 +#9 0x00007f608eaf1fd3 in phys_section_destroy (mr=0x7f6091e74800) at +git/qemu/exec.c:1154 +#10 phys_sections_free (map=0x7f6090b72bb0) at git/qemu/exec.c:1163 +#11 address_space_dispatch_free (d=0x7f6090b72b90) at git/qemu/exec.c:2514 +#12 0x00007f608ee91ace in call_rcu_thread (opaque=<optimized out>) at +util/rcu.c:272 +#13 0x00007f6089b0ddc5 in start_thread () from /usr/lib64/libpthread.so.0 +#14 0x00007f60882bf71d in clone () from /usr/lib64/libc.so.6 + +Call Trace: +#0 0x00007fdccaeb9790 in ?? () +#1 0x00007fdcd82d09fc in object_property_del_all (obj=0x7fdcdb8acf60) at +qom/object.c:405 +#2 object_finalize (data=0x7fdcdb8acf60) at qom/object.c:467 +#3 object_unref (address@hidden) at qom/object.c:903 +#4 0x00007fdcd8001fd3 in phys_section_destroy (mr=0x7fdcdb8acf60) at +git/qemu/exec.c:1154 +#5 phys_sections_free (map=0x7fdcdc86aa00) at git/qemu/exec.c:1163 +#6 address_space_dispatch_free (d=0x7fdcdc86a9e0) at git/qemu/exec.c:2514 +#7 0x00007fdcd83a1ace in call_rcu_thread (opaque=<optimized out>) at +util/rcu.c:272 +#8 0x00007fdcd301ddc5 in start_thread () from /usr/lib64/libpthread.so.0 +#9 0x00007fdcd17cf71d in clone () from /usr/lib64/libc.so.6 + +The q->tx_bh will free in virtio_net_del_queue() function, when remove virtio +queues +if the guest doesn't support multiqueue. But it might be still referenced by +others (eg . virtio_net_set_status()), +which need so set NULL. + +diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c +index 7d091c9..98bd683 100644 +--- a/hw/net/virtio-net.c ++++ b/hw/net/virtio-net.c +@@ -1522,9 +1522,12 @@ static void virtio_net_del_queue(VirtIONet *n, int index) + if (q->tx_timer) { + timer_del(q->tx_timer); + timer_free(q->tx_timer); ++ q->tx_timer = NULL; + } else { + qemu_bh_delete(q->tx_bh); ++ q->tx_bh = NULL; + } ++ q->tx_waiting = 0; + virtio_del_queue(vdev, index * 2 + 1); + } + +From: wangyunjian +Sent: Monday, April 24, 2017 6:10 PM +To: address@hidden; Michael S. Tsirkin <address@hidden>; 'Jason Wang' +<address@hidden> +Cc: wangyunjian <address@hidden>; caihe <address@hidden> +Subject: [Qemu-devel][BUG] QEMU crashes with dpdk virtio pmd + +Qemu crashes, with pre-condition: +vm xml config with multiqueue, and the vm's driver virtio-net support +multi-queue + +reproduce steps: +i. start dpdk testpmd in VM with the virtio nic +ii. stop testpmd +iii. reboot the VM + +This commit "f9d6dbf0 remove virtio queues if the guest doesn't support +multiqueue" is introduced. + +Qemu version: QEMU emulator version 2.9.50 (v2.9.0-137-g32c7e0a) +VM DPDK version:  DPDK-1.6.1 + +Call Trace: +#0 0x00007f60881fe5d7 in raise () from /usr/lib64/libc.so.6 +#1 0x00007f60881ffcc8 in abort () from /usr/lib64/libc.so.6 +#2 0x00007f608823e2f7 in __libc_message () from /usr/lib64/libc.so.6 +#3 0x00007f60882456d3 in _int_free () from /usr/lib64/libc.so.6 +#4 0x00007f608900158f in g_free () from /usr/lib64/libglib-2.0.so.0 +#5 0x00007f6088fea32c in iter_remove_or_steal () from +/usr/lib64/libglib-2.0.so.0 +#6 0x00007f608edc0986 in object_property_del_all (obj=0x7f6091e74800) at +qom/object.c:410 +#7 object_finalize (data=0x7f6091e74800) at qom/object.c:467 +#8 object_unref (address@hidden) at qom/object.c:903 +#9 0x00007f608eaf1fd3 in phys_section_destroy (mr=0x7f6091e74800) at +git/qemu/exec.c:1154 +#10 phys_sections_free (map=0x7f6090b72bb0) at git/qemu/exec.c:1163 +#11 address_space_dispatch_free (d=0x7f6090b72b90) at git/qemu/exec.c:2514 +#12 0x00007f608ee91ace in call_rcu_thread (opaque=<optimized out>) at +util/rcu.c:272 +#13 0x00007f6089b0ddc5 in start_thread () from /usr/lib64/libpthread.so.0 +#14 0x00007f60882bf71d in clone () from /usr/lib64/libc.so.6 + +Call Trace: +#0 0x00007fdccaeb9790 in ?? () +#1 0x00007fdcd82d09fc in object_property_del_all (obj=0x7fdcdb8acf60) at +qom/object.c:405 +#2 object_finalize (data=0x7fdcdb8acf60) at qom/object.c:467 +#3 object_unref (address@hidden) at qom/object.c:903 +#4 0x00007fdcd8001fd3 in phys_section_destroy (mr=0x7fdcdb8acf60) at +git/qemu/exec.c:1154 +#5 phys_sections_free (map=0x7fdcdc86aa00) at git/qemu/exec.c:1163 +#6 address_space_dispatch_free (d=0x7fdcdc86a9e0) at git/qemu/exec.c:2514 +#7 0x00007fdcd83a1ace in call_rcu_thread (opaque=<optimized out>) at +util/rcu.c:272 +#8 0x00007fdcd301ddc5 in start_thread () from /usr/lib64/libpthread.so.0 +#9 0x00007fdcd17cf71d in clone () from /usr/lib64/libc.so.6 + +On 2017å¹´04æ25æ¥ 19:37, wangyunjian wrote: +The q->tx_bh will free in virtio_net_del_queue() function, when remove virtio +queues +if the guest doesn't support multiqueue. But it might be still referenced by +others (eg . virtio_net_set_status()), +which need so set NULL. + +diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c +index 7d091c9..98bd683 100644 +--- a/hw/net/virtio-net.c ++++ b/hw/net/virtio-net.c +@@ -1522,9 +1522,12 @@ static void virtio_net_del_queue(VirtIONet *n, int index) + if (q->tx_timer) { + timer_del(q->tx_timer); + timer_free(q->tx_timer); ++ q->tx_timer = NULL; + } else { + qemu_bh_delete(q->tx_bh); ++ q->tx_bh = NULL; + } ++ q->tx_waiting = 0; + virtio_del_queue(vdev, index * 2 + 1); + } +Thanks a lot for the fix. + +Two questions: +- If virtio_net_set_status() is the only function that may access tx_bh, +it looks like setting tx_waiting to zero is sufficient? +- Can you post a formal patch for this? + +Thanks +From: wangyunjian +Sent: Monday, April 24, 2017 6:10 PM +To: address@hidden; Michael S. Tsirkin <address@hidden>; 'Jason Wang' +<address@hidden> +Cc: wangyunjian <address@hidden>; caihe <address@hidden> +Subject: [Qemu-devel][BUG] QEMU crashes with dpdk virtio pmd + +Qemu crashes, with pre-condition: +vm xml config with multiqueue, and the vm's driver virtio-net support +multi-queue + +reproduce steps: +i. start dpdk testpmd in VM with the virtio nic +ii. stop testpmd +iii. reboot the VM + +This commit "f9d6dbf0 remove virtio queues if the guest doesn't support +multiqueue" is introduced. + +Qemu version: QEMU emulator version 2.9.50 (v2.9.0-137-g32c7e0a) +VM DPDK version: DPDK-1.6.1 + +Call Trace: +#0 0x00007f60881fe5d7 in raise () from /usr/lib64/libc.so.6 +#1 0x00007f60881ffcc8 in abort () from /usr/lib64/libc.so.6 +#2 0x00007f608823e2f7 in __libc_message () from /usr/lib64/libc.so.6 +#3 0x00007f60882456d3 in _int_free () from /usr/lib64/libc.so.6 +#4 0x00007f608900158f in g_free () from /usr/lib64/libglib-2.0.so.0 +#5 0x00007f6088fea32c in iter_remove_or_steal () from +/usr/lib64/libglib-2.0.so.0 +#6 0x00007f608edc0986 in object_property_del_all (obj=0x7f6091e74800) at +qom/object.c:410 +#7 object_finalize (data=0x7f6091e74800) at qom/object.c:467 +#8 object_unref (address@hidden) at qom/object.c:903 +#9 0x00007f608eaf1fd3 in phys_section_destroy (mr=0x7f6091e74800) at +git/qemu/exec.c:1154 +#10 phys_sections_free (map=0x7f6090b72bb0) at git/qemu/exec.c:1163 +#11 address_space_dispatch_free (d=0x7f6090b72b90) at git/qemu/exec.c:2514 +#12 0x00007f608ee91ace in call_rcu_thread (opaque=<optimized out>) at +util/rcu.c:272 +#13 0x00007f6089b0ddc5 in start_thread () from /usr/lib64/libpthread.so.0 +#14 0x00007f60882bf71d in clone () from /usr/lib64/libc.so.6 + +Call Trace: +#0 0x00007fdccaeb9790 in ?? () +#1 0x00007fdcd82d09fc in object_property_del_all (obj=0x7fdcdb8acf60) at +qom/object.c:405 +#2 object_finalize (data=0x7fdcdb8acf60) at qom/object.c:467 +#3 object_unref (address@hidden) at qom/object.c:903 +#4 0x00007fdcd8001fd3 in phys_section_destroy (mr=0x7fdcdb8acf60) at +git/qemu/exec.c:1154 +#5 phys_sections_free (map=0x7fdcdc86aa00) at git/qemu/exec.c:1163 +#6 address_space_dispatch_free (d=0x7fdcdc86a9e0) at git/qemu/exec.c:2514 +#7 0x00007fdcd83a1ace in call_rcu_thread (opaque=<optimized out>) at +util/rcu.c:272 +#8 0x00007fdcd301ddc5 in start_thread () from /usr/lib64/libpthread.so.0 +#9 0x00007fdcd17cf71d in clone () from /usr/lib64/libc.so.6 + +CCing Paolo and Stefan, since it has a relationship with bh in Qemu. + +> +-----Original Message----- +> +From: Jason Wang [ +mailto:address@hidden +> +> +> +On 2017å¹´04æ25æ¥ 19:37, wangyunjian wrote: +> +> The q->tx_bh will free in virtio_net_del_queue() function, when remove +> +> virtio +> +queues +> +> if the guest doesn't support multiqueue. But it might be still referenced by +> +others (eg . virtio_net_set_status()), +> +> which need so set NULL. +> +> +> +> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c +> +> index 7d091c9..98bd683 100644 +> +> --- a/hw/net/virtio-net.c +> +> +++ b/hw/net/virtio-net.c +> +> @@ -1522,9 +1522,12 @@ static void virtio_net_del_queue(VirtIONet *n, +> +int index) +> +> if (q->tx_timer) { +> +> timer_del(q->tx_timer); +> +> timer_free(q->tx_timer); +> +> + q->tx_timer = NULL; +> +> } else { +> +> qemu_bh_delete(q->tx_bh); +> +> + q->tx_bh = NULL; +> +> } +> +> + q->tx_waiting = 0; +> +> virtio_del_queue(vdev, index * 2 + 1); +> +> } +> +> +Thanks a lot for the fix. +> +> +Two questions: +> +> +- If virtio_net_set_status() is the only function that may access tx_bh, +> +it looks like setting tx_waiting to zero is sufficient? +Currently yes, but we don't assure that it works for all scenarios, so +we set the tx_bh and tx_timer to NULL to avoid to possibly access wild pointer, +which is the common method for usage of bh in Qemu. + +I have another question about the root cause of this issure. + +This below trace is the path of setting tx_waiting to one in +virtio_net_handle_tx_bh() : + +Breakpoint 1, virtio_net_handle_tx_bh (vdev=0x0, vq=0x7f335ad13900) at +/data/wyj/git/qemu/hw/net/virtio-net.c:1398 +1398 { +(gdb) bt +#0 virtio_net_handle_tx_bh (vdev=0x0, vq=0x7f335ad13900) at +/data/wyj/git/qemu/hw/net/virtio-net.c:1398 +#1 0x00007f3357bddf9c in virtio_bus_set_host_notifier (bus=<optimized out>, +address@hidden, address@hidden) at hw/virtio/virtio-bus.c:297 +#2 0x00007f3357a0055d in vhost_dev_disable_notifiers (address@hidden, +address@hidden) at /data/wyj/git/qemu/hw/virtio/vhost.c:1422 +#3 0x00007f33579e3373 in vhost_net_stop_one (net=0x7f335ad84dc0, +dev=0x7f335c6f5f90) at /data/wyj/git/qemu/hw/net/vhost_net.c:289 +#4 0x00007f33579e385b in vhost_net_stop (address@hidden, ncs=<optimized out>, +address@hidden) at /data/wyj/git/qemu/hw/net/vhost_net.c:367 +#5 0x00007f33579e15de in virtio_net_vhost_status (status=<optimized out>, +n=0x7f335c6f5f90) at /data/wyj/git/qemu/hw/net/virtio-net.c:176 +#6 virtio_net_set_status (vdev=0x7f335c6f5f90, status=0 '\000') at +/data/wyj/git/qemu/hw/net/virtio-net.c:250 +#7 0x00007f33579f8dc6 in virtio_set_status (address@hidden, address@hidden +'\000') at /data/wyj/git/qemu/hw/virtio/virtio.c:1146 +#8 0x00007f3357bdd3cc in virtio_ioport_write (val=0, addr=18, +opaque=0x7f335c6eda80) at hw/virtio/virtio-pci.c:387 +#9 virtio_pci_config_write (opaque=0x7f335c6eda80, addr=18, val=0, +size=<optimized out>) at hw/virtio/virtio-pci.c:511 +#10 0x00007f33579b2155 in memory_region_write_accessor (mr=0x7f335c6ee470, +addr=18, value=<optimized out>, size=1, shift=<optimized out>, mask=<optimized +out>, attrs=...) at /data/wyj/git/qemu/memory.c:526 +#11 0x00007f33579af2e9 in access_with_adjusted_size (address@hidden, +address@hidden, address@hidden, access_size_min=<optimized out>, +access_size_max=<optimized out>, address@hidden + 0x7f33579b20f0 <memory_region_write_accessor>, address@hidden, +address@hidden) at /data/wyj/git/qemu/memory.c:592 +#12 0x00007f33579b2e15 in memory_region_dispatch_write (address@hidden, +address@hidden, data=0, address@hidden, address@hidden) at +/data/wyj/git/qemu/memory.c:1319 +#13 0x00007f335796cd93 in address_space_write_continue (mr=0x7f335c6ee470, l=1, +addr1=18, len=1, buf=0x7f335773d000 "", attrs=..., addr=49170, +as=0x7f3358317060 <address_space_io>) at /data/wyj/git/qemu/exec.c:2834 +#14 address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., +buf=<optimized out>, len=<optimized out>) at /data/wyj/git/qemu/exec.c:2879 +#15 0x00007f335796d3ad in address_space_rw (as=<optimized out>, address@hidden, +attrs=..., address@hidden, buf=<optimized out>, address@hidden, address@hidden) +at /data/wyj/git/qemu/exec.c:2981 +#16 0x00007f33579ae226 in kvm_handle_io (count=1, size=1, direction=<optimized +out>, data=<optimized out>, attrs=..., port=49170) at +/data/wyj/git/qemu/kvm-all.c:1803 +#17 kvm_cpu_exec (address@hidden) at /data/wyj/git/qemu/kvm-all.c:2032 +#18 0x00007f335799b632 in qemu_kvm_cpu_thread_fn (arg=0x7f335ae82070) at +/data/wyj/git/qemu/cpus.c:1118 +#19 0x00007f3352983dc5 in start_thread () from /usr/lib64/libpthread.so.0 +#20 0x00007f335113571d in clone () from /usr/lib64/libc.so.6 + +It calls qemu_bh_schedule(q->tx_bh) at the bottom of virtio_net_handle_tx_bh(), +I don't know why virtio_net_tx_bh() doesn't be invoked, so that the +q->tx_waiting is not zero. +[ps: we added logs in virtio_net_tx_bh() to verify that] + +Some other information: + +It won't crash if we don't use vhost-net. + + +Thanks, +-Gonglei + +> +- Can you post a formal patch for this? +> +> +Thanks +> +> +> From: wangyunjian +> +> Sent: Monday, April 24, 2017 6:10 PM +> +> To: address@hidden; Michael S. Tsirkin <address@hidden>; 'Jason +> +Wang' <address@hidden> +> +> Cc: wangyunjian <address@hidden>; caihe <address@hidden> +> +> Subject: [Qemu-devel][BUG] QEMU crashes with dpdk virtio pmd +> +> +> +> Qemu crashes, with pre-condition: +> +> vm xml config with multiqueue, and the vm's driver virtio-net support +> +multi-queue +> +> +> +> reproduce steps: +> +> i. start dpdk testpmd in VM with the virtio nic +> +> ii. stop testpmd +> +> iii. reboot the VM +> +> +> +> This commit "f9d6dbf0 remove virtio queues if the guest doesn't support +> +multiqueue" is introduced. +> +> +> +> Qemu version: QEMU emulator version 2.9.50 (v2.9.0-137-g32c7e0a) +> +> VM DPDK version: DPDK-1.6.1 +> +> +> +> Call Trace: +> +> #0 0x00007f60881fe5d7 in raise () from /usr/lib64/libc.so.6 +> +> #1 0x00007f60881ffcc8 in abort () from /usr/lib64/libc.so.6 +> +> #2 0x00007f608823e2f7 in __libc_message () from /usr/lib64/libc.so.6 +> +> #3 0x00007f60882456d3 in _int_free () from /usr/lib64/libc.so.6 +> +> #4 0x00007f608900158f in g_free () from /usr/lib64/libglib-2.0.so.0 +> +> #5 0x00007f6088fea32c in iter_remove_or_steal () from +> +/usr/lib64/libglib-2.0.so.0 +> +> #6 0x00007f608edc0986 in object_property_del_all (obj=0x7f6091e74800) +> +at qom/object.c:410 +> +> #7 object_finalize (data=0x7f6091e74800) at qom/object.c:467 +> +> #8 object_unref (address@hidden) at qom/object.c:903 +> +> #9 0x00007f608eaf1fd3 in phys_section_destroy (mr=0x7f6091e74800) at +> +git/qemu/exec.c:1154 +> +> #10 phys_sections_free (map=0x7f6090b72bb0) at git/qemu/exec.c:1163 +> +> #11 address_space_dispatch_free (d=0x7f6090b72b90) at +> +git/qemu/exec.c:2514 +> +> #12 0x00007f608ee91ace in call_rcu_thread (opaque=<optimized out>) at +> +util/rcu.c:272 +> +> #13 0x00007f6089b0ddc5 in start_thread () from /usr/lib64/libpthread.so.0 +> +> #14 0x00007f60882bf71d in clone () from /usr/lib64/libc.so.6 +> +> +> +> Call Trace: +> +> #0 0x00007fdccaeb9790 in ?? () +> +> #1 0x00007fdcd82d09fc in object_property_del_all (obj=0x7fdcdb8acf60) at +> +qom/object.c:405 +> +> #2 object_finalize (data=0x7fdcdb8acf60) at qom/object.c:467 +> +> #3 object_unref (address@hidden) at qom/object.c:903 +> +> #4 0x00007fdcd8001fd3 in phys_section_destroy (mr=0x7fdcdb8acf60) at +> +git/qemu/exec.c:1154 +> +> #5 phys_sections_free (map=0x7fdcdc86aa00) at git/qemu/exec.c:1163 +> +> #6 address_space_dispatch_free (d=0x7fdcdc86a9e0) at +> +git/qemu/exec.c:2514 +> +> #7 0x00007fdcd83a1ace in call_rcu_thread (opaque=<optimized out>) at +> +util/rcu.c:272 +> +> #8 0x00007fdcd301ddc5 in start_thread () from /usr/lib64/libpthread.so.0 +> +> #9 0x00007fdcd17cf71d in clone () from /usr/lib64/libc.so.6 +> +> +> +> + +On 25/04/2017 14:02, Jason Wang wrote: +> +> +Thanks a lot for the fix. +> +> +Two questions: +> +> +- If virtio_net_set_status() is the only function that may access tx_bh, +> +it looks like setting tx_waiting to zero is sufficient? +I think clearing tx_bh is better anyway, as leaving a dangling pointer +is not very hygienic. + +Paolo + +> +- Can you post a formal patch for this? + diff --git a/results/classifier/118/permissions/355410 b/results/classifier/118/permissions/355410 new file mode 100644 index 00000000..18009fe1 --- /dev/null +++ b/results/classifier/118/permissions/355410 @@ -0,0 +1,110 @@ +permissions: 0.886 +peripherals: 0.868 +device: 0.862 +architecture: 0.851 +TCG: 0.844 +graphic: 0.838 +semantic: 0.830 +socket: 0.829 +hypervisor: 0.828 +network: 0.825 +KVM: 0.816 +vnc: 0.813 +register: 0.808 +kernel: 0.805 +user-level: 0.801 +mistranslation: 0.799 +files: 0.797 +ppc: 0.795 +PID: 0.795 +debug: 0.789 +arm: 0.755 +boot: 0.748 +i386: 0.730 +VMM: 0.728 +risc-v: 0.719 +performance: 0.703 +virtual: 0.689 +x86: 0.658 +assembly: 0.578 + +kvm crashed with SIGSEGV in malloc_consolidate() + +Binary package hint: kvm + +See Bug #355401. Oddly enough, when Windows tries to install drivers for a WDM device (a W380a on USB), kvm crashes. + +ProblemType: Crash +Architecture: amd64 +DistroRelease: Ubuntu 9.04 +ExecutablePath: /usr/bin/kvm +KvmCmdLine: Error: command ['ps', '-p', '5036', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: ASUSTeK Computer Inc. F3Sa +NonfreeKernelModules: fglrx +Package: kvm 1:84+dfsg-0ubuntu10 +ProcCmdLine: root=UUID=1b4d3e6f-e7de-4dda-a22b-4ee8d3da378d ro splash +ProcCmdline: kvm -snapshot -net nic,model=ne2k_pci -net user -soundhw es1370 -usb -usbdevice tablet -m 256 winXP.SP3-IE7-20081018.qcow -usbdevice host:0fce:d0b5 -smb /home/username/temp/Unlock_Sony_Ericsson/ +ProcEnviron: + PATH=(custom, user) + LANG=en_CA.UTF-8 + SHELL=/bin/bash +ProcVersionSignature: Ubuntu 2.6.28-11.40-generic +Signal: 11 +SourcePackage: kvm +StacktraceTop: + malloc_consolidate (av=0x7fe3b0607a00) at malloc.c:4897 + _int_malloc (av=0x7fe3b0607a00, bytes=2128) + *__GI___libc_malloc (bytes=2128) at malloc.c:3551 + ?? () + ?? () +Title: kvm crashed with SIGSEGV in malloc_consolidate() +UserGroups: adm admin audio cdrom dialout dip disk fax fuse kvm lpadmin netdev plugdev sambashare scanner tape video + + + +Hi, thanks for the report. + +Can you give me any hints about what's going on when you see this issue? + +I see you're doing USB passthrough, which can be a little be tricky. Can you reproduce the problem without USB passthrough? + +:-Dustin + +The specific USB device used is conditional on reproducing this bug. As such, I can't just reproduce this without the device. + +Right, sorry about that. I realized that just after I typed my +response. My bad... + +:-Dustin + +This could fix it. + +commit c4c0e236beabb9de5ff472f77aeb811ec5484615 +Author: Jim Paris <email address hidden> +Date: Mon Aug 24 14:56:12 2009 -0400 + + +This should be qemu-0.11.0 which should be released soon. + +Marking triaged, against the qemu-kvm project. Upstream QEMU has a pending fix for this (or at least something very, very similar). + +As soon as this lands in qemu-kvm-0.11, we should get this in Karmic. + +:-Dustin + +We should be getting qemu-0.11 GA into Karmic early next week. + +I'll ping here once it's uploaded. + +:-Dustin + +Can you please re-test this? + +We strongly suspect that this is fixed in Karmic now. + +Please re-open the bug, if you can still reproduce it. + +:-Dustin + +Commit c4c0e236beabb9de5ff mentioned in comment #5 has been included long ago, so setting this ticket to "Fix released" now. + diff --git a/results/classifier/118/permissions/401 b/results/classifier/118/permissions/401 new file mode 100644 index 00000000..b712409f --- /dev/null +++ b/results/classifier/118/permissions/401 @@ -0,0 +1,31 @@ +permissions: 0.929 +network: 0.863 +semantic: 0.824 +device: 0.814 +mistranslation: 0.642 +performance: 0.620 +architecture: 0.542 +VMM: 0.448 +graphic: 0.447 +virtual: 0.360 +register: 0.277 +peripherals: 0.274 +assembly: 0.267 +vnc: 0.256 +hypervisor: 0.246 +files: 0.188 +user-level: 0.142 +arm: 0.093 +boot: 0.093 +ppc: 0.062 +TCG: 0.054 +x86: 0.053 +KVM: 0.048 +socket: 0.046 +debug: 0.040 +kernel: 0.039 +PID: 0.035 +i386: 0.023 +risc-v: 0.013 + +Wishlist: nvme-ns: allow specifying eui-64 diff --git a/results/classifier/118/permissions/453617 b/results/classifier/118/permissions/453617 new file mode 100644 index 00000000..32683cfe --- /dev/null +++ b/results/classifier/118/permissions/453617 @@ -0,0 +1,129 @@ +permissions: 0.902 +PID: 0.894 +register: 0.893 +debug: 0.890 +architecture: 0.884 +assembly: 0.882 +socket: 0.875 +performance: 0.872 +virtual: 0.864 +kernel: 0.846 +device: 0.845 +KVM: 0.842 +graphic: 0.824 +semantic: 0.823 +network: 0.820 +user-level: 0.812 +arm: 0.811 +risc-v: 0.800 +ppc: 0.792 +boot: 0.785 +files: 0.785 +VMM: 0.685 +peripherals: 0.663 +hypervisor: 0.661 +TCG: 0.657 +vnc: 0.583 +i386: 0.454 +x86: 0.439 +mistranslation: 0.383 + +kvm hangs at 100% cpu when connecting to forwarded ports (when listed incorrectly on the command line) + +Binary package hint: qemu-kvm + +If kvm is started using two separate "-net user,hostfwd=<forwarding rule>" arguments to forward ports from the host to the client, it won't complain, but will return a connection refused error and hang at 100% cpu when trying to connect to either forwarded port. + +However, if kvm is started with the hostfwd rules combined together into a single "-net user" argument, it works fine. + +As an example, this command line doesn't generate any warnings or errors, but causes kvm to hang for me: + +kvm -net nic -net user,hostfwd=tcp:127.0.0.1:8888-:80 -net user,hostfwd=tcp:127.0.0.1:2222-:22 -m 128 -smp 1 -drive file=disk0.qcow2 + +... but this command line works fine: + +kvm -net nic -net user,hostfwd=tcp:127.0.0.1:8888-:80,hostfwd=tcp:127.0.0.1:2222-:22 -m 128 -smp 1 -drive file=disk0.qcow2 + +ProblemType: Bug +Architecture: amd64 +Date: Fri Oct 16 17:19:59 2009 +DistroRelease: Ubuntu 9.10 +KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: Sony Corporation VGN-SZ650N +NonfreeKernelModules: nvidia +Package: kvm (not installed) +PccardctlIdent: + Socket 0: + no product info available +PccardctlStatus: + Socket 0: + no card +ProcCmdLine: root=UUID=3ee4953e-48f0-497c-ae78-18cbb18cfef8 ro quiet splash +ProcEnviron: + LANGUAGE=en_US.UTF-8 + PATH=(custom, user) + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcVersionSignature: Ubuntu 2.6.31-14.47-generic +SourcePackage: qemu-kvm +Uname: Linux 2.6.31-14-generic x86_64 +dmi.bios.date: 07/12/2007 +dmi.bios.vendor: Phoenix Technologies LTD +dmi.bios.version: R0081S5 +dmi.board.asset.tag: N/A +dmi.board.name: VAIO +dmi.board.vendor: Sony Corporation +dmi.board.version: N/A +dmi.chassis.type: 10 +dmi.chassis.vendor: Sony Corporation +dmi.chassis.version: N/A +dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrR0081S5:bd07/12/2007:svnSonyCorporation:pnVGN-SZ650N:pvrJ002VXGP:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A: +dmi.product.name: VGN-SZ650N +dmi.product.version: J002VXGP +dmi.sys.vendor: Sony Corporation + + + +On Lucid alpha 3 an error is reported and kvm stops: + +$ sudo kvm -net nic -net user,hostfwd=tcp:127.0.0.1:8888-:80 -net user,hostfwd=tcp:127.0.0.1:2222-:22 -m 128 -smp 1 -drive file=disk0.qcow2kvm -net nic -net user,hostfwd=tcp:127.0.0.1:8888-:80 -net user,hostfwd=tcp:127.0.0.1:2222-:22 -m 128 -smp 1 -drive file=lucid.qcow2 +could not set up host forwarding rule 'tcp:127.0.0.1:8888-:80' + +qemu-kvm Version: 0.12.3-0ubuntu2 + + +Torsten- + +Check your command line. Looks like you double-pasted the faulty command. + +Jesse- + +I can actually confirm this in Lucid's qemu-kvm 0.12.3. I ran your exact two lines and it seems to lock my kvm process and eat a bunch of cpu. + +The symptoms look very similar to Bug #474968. + +Anthony, can we have a look at this? + +At the very least, the manpage needs to be updated, as the "hostfwd=[tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport" section says: "This option can be given multiple times." + +The documentation aspect of this bug should be fix along with Bug #474969. + +This bug was fixed in the package qemu-kvm - 0.12.3-0ubuntu6 + +--------------- +qemu-kvm (0.12.3-0ubuntu6) lucid; urgency=low + + [ Dustin Kirkland ] + * debian/postinst: clean up jaunty-era conffiles on upgrade, LP: #455411 + * debian/links, debian/qemu-kvm-extras.links: install non-x86 arch + manpages in the qemu-kvm-extras package, LP: #478552 + + [ Brian Thomason ] + * debian/patches/better_describe_-net_options.patch: improve port + forwarding documentation, LP: #474969, LP: #453617 + -- Dustin Kirkland <email address hidden> Fri, 05 Mar 2010 18:39:19 -0600 + +Is there still an issue left here with upstream QEMU? + +There hasn't been any comment about upstream QEMU within the last months, so I assume this has been fixed there, too. Closing... + diff --git a/results/classifier/118/permissions/470 b/results/classifier/118/permissions/470 new file mode 100644 index 00000000..154cca9f --- /dev/null +++ b/results/classifier/118/permissions/470 @@ -0,0 +1,31 @@ +user-level: 0.963 +mistranslation: 0.962 +permissions: 0.950 +peripherals: 0.778 +device: 0.771 +architecture: 0.752 +performance: 0.647 +semantic: 0.442 +network: 0.403 +graphic: 0.357 +boot: 0.335 +kernel: 0.295 +register: 0.283 +PID: 0.216 +VMM: 0.209 +debug: 0.196 +i386: 0.181 +arm: 0.169 +files: 0.165 +virtual: 0.153 +socket: 0.149 +vnc: 0.090 +x86: 0.054 +TCG: 0.045 +risc-v: 0.043 +ppc: 0.039 +hypervisor: 0.034 +assembly: 0.016 +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/118/permissions/498035 b/results/classifier/118/permissions/498035 new file mode 100644 index 00000000..51d009fd --- /dev/null +++ b/results/classifier/118/permissions/498035 @@ -0,0 +1,116 @@ +permissions: 0.943 +register: 0.936 +peripherals: 0.924 +architecture: 0.919 +user-level: 0.918 +network: 0.910 +debug: 0.910 +semantic: 0.904 +graphic: 0.896 +assembly: 0.895 +device: 0.893 +performance: 0.892 +socket: 0.890 +virtual: 0.889 +vnc: 0.881 +arm: 0.871 +boot: 0.866 +risc-v: 0.852 +mistranslation: 0.850 +PID: 0.849 +TCG: 0.840 +hypervisor: 0.837 +VMM: 0.837 +ppc: 0.813 +files: 0.792 +x86: 0.756 +KVM: 0.739 +kernel: 0.719 +i386: 0.532 + +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/118/permissions/50773216 b/results/classifier/118/permissions/50773216 new file mode 100644 index 00000000..bb9d9096 --- /dev/null +++ b/results/classifier/118/permissions/50773216 @@ -0,0 +1,135 @@ +permissions: 0.813 +risc-v: 0.813 +kernel: 0.791 +architecture: 0.788 +hypervisor: 0.768 +device: 0.764 +ppc: 0.760 +arm: 0.758 +register: 0.751 +peripherals: 0.729 +graphic: 0.723 +user-level: 0.713 +semantic: 0.669 +files: 0.666 +debug: 0.659 +vnc: 0.656 +socket: 0.652 +mistranslation: 0.652 +boot: 0.637 +PID: 0.636 +VMM: 0.633 +performance: 0.628 +assembly: 0.623 +network: 0.606 +KVM: 0.601 +TCG: 0.571 +virtual: 0.560 +i386: 0.546 +x86: 0.510 + +[Qemu-devel] Can I have someone's feedback on [bug 1809075] Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel + +Hi everyone. +Can I please have someone's feedback on this bug? +https://bugs.launchpad.net/qemu/+bug/1809075 +Briefly, guest OS loses characters sent to it via vnc. And I spot the +bug in relation to ps2 driver. +I'm thinking of possible fixes and I might want to use a memory barrier. +But I would really like to have some suggestion from a qemu developer +first. For example, can we brutally drop capslock LED key events in ps2 +queue? +It is actually relevant to openQA, an automated QA tool for openSUSE. +And this bug blocks a few test cases for us. +Thank you in advance! + +Kind regards, +Gao Zhiyuan + +Cc'ing Marc-André & Gerd. + +On 12/19/18 10:31 AM, Gao Zhiyuan wrote: +> +Hi everyone. +> +> +Can I please have someone's feedback on this bug? +> +https://bugs.launchpad.net/qemu/+bug/1809075 +> +Briefly, guest OS loses characters sent to it via vnc. And I spot the +> +bug in relation to ps2 driver. +> +> +I'm thinking of possible fixes and I might want to use a memory barrier. +> +But I would really like to have some suggestion from a qemu developer +> +first. For example, can we brutally drop capslock LED key events in ps2 +> +queue? +> +> +It is actually relevant to openQA, an automated QA tool for openSUSE. +> +And this bug blocks a few test cases for us. +> +> +Thank you in advance! +> +> +Kind regards, +> +Gao Zhiyuan +> + +On Thu, Jan 03, 2019 at 12:05:54PM +0100, Philippe Mathieu-Daudé wrote: +> +Cc'ing Marc-André & Gerd. +> +> +On 12/19/18 10:31 AM, Gao Zhiyuan wrote: +> +> Hi everyone. +> +> +> +> Can I please have someone's feedback on this bug? +> +> +https://bugs.launchpad.net/qemu/+bug/1809075 +> +> Briefly, guest OS loses characters sent to it via vnc. And I spot the +> +> bug in relation to ps2 driver. +> +> +> +> I'm thinking of possible fixes and I might want to use a memory barrier. +> +> But I would really like to have some suggestion from a qemu developer +> +> first. For example, can we brutally drop capslock LED key events in ps2 +> +> queue? +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. + +cheers, + Gerd + diff --git a/results/classifier/118/permissions/515 b/results/classifier/118/permissions/515 new file mode 100644 index 00000000..b63b26a5 --- /dev/null +++ b/results/classifier/118/permissions/515 @@ -0,0 +1,61 @@ +permissions: 0.821 +peripherals: 0.756 +graphic: 0.751 +debug: 0.732 +register: 0.665 +ppc: 0.639 +files: 0.633 +arm: 0.631 +device: 0.626 +network: 0.623 +risc-v: 0.617 +VMM: 0.587 +socket: 0.584 +performance: 0.576 +user-level: 0.575 +semantic: 0.574 +PID: 0.565 +assembly: 0.561 +architecture: 0.558 +vnc: 0.552 +hypervisor: 0.518 +mistranslation: 0.513 +virtual: 0.505 +TCG: 0.448 +kernel: 0.428 +x86: 0.408 +boot: 0.393 +KVM: 0.364 +i386: 0.327 + +qemu-system-x86_64 fails to run with regular user after following arch wiki article +Description of problem: +When `qemu-system-x86_64` binary is run with a regular user, it fails with no output. No matter if it's run with `--help`, `--version` or any other parameter. By checking the resulting error code (`echo $?`) it is possible to see that it finished with error code 1. + +After seeing this [post](https://www.reddit.com/r/archlinux/comments/b9emxp/qemusystemx86_64_does_not_execute_how_can_i/ek47btb/) on reddit, it became clear that the reason was that my `/etc` directory had a subdirectory qemu, in which my regular user did not have access to. That is, qemu binary looks for `/etc/qemu/qemu.conf` and if it can't determine if the file is there or not, it fails. + +Here goes the logic: +strace showed the permission error (even though there was no output to indicate that). + +``` +$ strace /usr/bin/qemu-system-x86_64 +… +mmap(NULL, 4928, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0) = 0x7f4d01e6e000 +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_POPULATE, 3, 0x10000000) = 0x7f4d01e6c000 +eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 4 +sysinfo({uptime=92539, loads=[109952, 80640, 118144], totalram=16643309568, freeram=5314445312, sharedram=2590158848, bufferram=1301561344, totalswap=20479733760, freeswap=19551150080, procs=1202, totalhigh=0, freehigh=0, mem_unit=1}) = 0 +rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f4d01ad7960}, NULL, 8) = 0 +openat(AT_FDCWD, "/etc/qemu/qemu.conf", O_RDONLY) = -1 EACCES (Permission denied) +exit_group(1) = ? ++++ exited with 1 +++ +``` + +The thing was that initially that folder did not exist, and I created it to make the qemu bridges work, like indicated in this arch wiki [article](https://wiki.archlinux.org/title/QEMU#Bridged_networking_using_qemu-bridge-helper). I will be suggesting modifications to that article. + +When the directory did not exit, qemu noticed that the folder didn't exist and moved on, once it was created, in case the regular user had no access to it, it fails with no warning. + +I just gave access to the folder ant it worked again (if you delete the folder it works too). + +If you use libvirt, by using virsh for example, you may not notice this issue as it may be running as system (by setting the following system variable `export LIBVIRT_DEFAULT_URI='qemu:///system'`) + +So, to fix this issue, in my opinion a warning should be printed out to the stderr. Otherwise, qemu could move on if it doens't have access to `/etc/qemu/qemu.conf`. diff --git a/results/classifier/118/permissions/568228 b/results/classifier/118/permissions/568228 new file mode 100644 index 00000000..d1032501 --- /dev/null +++ b/results/classifier/118/permissions/568228 @@ -0,0 +1,1423 @@ +permissions: 0.927 +architecture: 0.882 +device: 0.855 +socket: 0.838 +register: 0.826 +boot: 0.823 +PID: 0.819 +semantic: 0.813 +performance: 0.809 +network: 0.808 +kernel: 0.802 +peripherals: 0.799 +user-level: 0.747 +arm: 0.744 +assembly: 0.744 +ppc: 0.743 +TCG: 0.738 +virtual: 0.722 +graphic: 0.707 +VMM: 0.681 +files: 0.668 +debug: 0.655 +risc-v: 0.624 +KVM: 0.612 +hypervisor: 0.603 +vnc: 0.486 +x86: 0.424 +i386: 0.415 +mistranslation: 0.380 + +/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/118/permissions/57231878 b/results/classifier/118/permissions/57231878 new file mode 100644 index 00000000..69936a45 --- /dev/null +++ b/results/classifier/118/permissions/57231878 @@ -0,0 +1,267 @@ +permissions: 0.856 +virtual: 0.832 +device: 0.818 +register: 0.783 +semantic: 0.774 +graphic: 0.751 +assembly: 0.745 +debug: 0.732 +kernel: 0.725 +mistranslation: 0.719 +arm: 0.713 +x86: 0.713 +KVM: 0.708 +user-level: 0.707 +hypervisor: 0.691 +TCG: 0.689 +ppc: 0.684 +PID: 0.684 +architecture: 0.678 +network: 0.659 +performance: 0.644 +vnc: 0.640 +peripherals: 0.624 +socket: 0.624 +VMM: 0.613 +risc-v: 0.611 +boot: 0.609 +files: 0.587 +i386: 0.318 + +[Qemu-devel] [BUG] qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed. + +Hello all, +I wanted to submit a bug report in the tracker, but it seem to require +an Ubuntu One account, which I'm having trouble with, so I'll just +give it here and hopefully somebody can make use of it. The issue +seems to be in an experimental format, so it's likely not very +consequential anyway. + +For the sake of anyone else simply googling for a workaround, I'll +just paste in the (cleaned up) brief IRC conversation about my issue +from the official channel: +<quy> I'm using QEMU version 2.12.0 on an x86_64 host (Arch Linux, +Kernel v4.17.2), and I'm trying to create an x86_64 virtual machine +(FreeBSD-11.1). The VM always aborts at the same point in the +installation (downloading 'ports.tgz') with the following error +message: +"qemu-system-x86_64: /build/qemu/src/qemu-2.12.0/block/qed.c:1197: +qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed. +zsh: abort (core dumped) qemu-system-x86_64 -smp 2 -m 4096 +-enable-kvm -hda freebsd/freebsd.qed -devic" +The commands I ran to create the machine are as follows: +"qemu-img create -f qed freebsd/freebsd.qed 16G" +"qemu-system-x86_64 -smp 2 -m 4096 -enable-kvm -hda +freebsd/freebsd.qed -device e1000,netdev=net0 -netdev user,id=net0 +-cdrom FreeBSD-11.1-RELEASE-amd64-bootonly.iso -boot order=d" +I tried adding logging options with the -d flag, but I didn't get +anything that seemed relevant, since I'm not sure what to look for. +<stsquad> ohh what's a qed device? +<stsquad> quy: it might be a workaround to use a qcow2 image for now +<stsquad> ahh the wiki has a statement "It is not recommended to use +QED for any new images. " +<danpb> 'qed' was an experimental disk image format created by IBM +before qcow2 v3 came along +<danpb> honestly nothing should ever use QED these days +<danpb> the good ideas from QED became qcow2v3 +<stsquad> danpb: sounds like we should put a warning on the option to +remind users of that fact +<danpb> quy: sounds like qed driver is simply broken - please do file +a bug against qemu bug tracker +<danpb> quy: but you should also really switch to qcow2 +<quy> I see; some people need to update their wikis then. I don't +remember where which guide I read when I first learned what little +QEMU I know, but I remember it specifically remember it saying QED was +the newest and most optimal format. +<stsquad> quy: we can only be responsible for our own wiki I'm afraid... +<danpb> if you remember where you saw that please let us know so we +can try to get it fixed +<quy> Thank you very much for the info; I will switch to QCOW. +Unfortunately, I'm not sure if I will be able to file any bug reports +in the tracker as I can't seem to log Launchpad, which it seems to +require. +<danpb> quy: an email to the mailing list would suffice too if you +can't deal with launchpad +<danpb> kwolf: ^^^ in case you're interested in possible QED +assertions from 2.12 + +If any more info is needed, feel free to email me; I'm not actually +subscribed to this list though. +Thank you, +Quytelda Kahja + +CC Qemu Block; looks like QED is a bit busted. + +On 06/27/2018 10:25 AM, Quytelda Kahja wrote: +> +Hello all, +> +I wanted to submit a bug report in the tracker, but it seem to require +> +an Ubuntu One account, which I'm having trouble with, so I'll just +> +give it here and hopefully somebody can make use of it. The issue +> +seems to be in an experimental format, so it's likely not very +> +consequential anyway. +> +> +For the sake of anyone else simply googling for a workaround, I'll +> +just paste in the (cleaned up) brief IRC conversation about my issue +> +from the official channel: +> +<quy> I'm using QEMU version 2.12.0 on an x86_64 host (Arch Linux, +> +Kernel v4.17.2), and I'm trying to create an x86_64 virtual machine +> +(FreeBSD-11.1). The VM always aborts at the same point in the +> +installation (downloading 'ports.tgz') with the following error +> +message: +> +"qemu-system-x86_64: /build/qemu/src/qemu-2.12.0/block/qed.c:1197: +> +qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed. +> +zsh: abort (core dumped) qemu-system-x86_64 -smp 2 -m 4096 +> +-enable-kvm -hda freebsd/freebsd.qed -devic" +> +The commands I ran to create the machine are as follows: +> +"qemu-img create -f qed freebsd/freebsd.qed 16G" +> +"qemu-system-x86_64 -smp 2 -m 4096 -enable-kvm -hda +> +freebsd/freebsd.qed -device e1000,netdev=net0 -netdev user,id=net0 +> +-cdrom FreeBSD-11.1-RELEASE-amd64-bootonly.iso -boot order=d" +> +I tried adding logging options with the -d flag, but I didn't get +> +anything that seemed relevant, since I'm not sure what to look for. +> +<stsquad> ohh what's a qed device? +> +<stsquad> quy: it might be a workaround to use a qcow2 image for now +> +<stsquad> ahh the wiki has a statement "It is not recommended to use +> +QED for any new images. " +> +<danpb> 'qed' was an experimental disk image format created by IBM +> +before qcow2 v3 came along +> +<danpb> honestly nothing should ever use QED these days +> +<danpb> the good ideas from QED became qcow2v3 +> +<stsquad> danpb: sounds like we should put a warning on the option to +> +remind users of that fact +> +<danpb> quy: sounds like qed driver is simply broken - please do file +> +a bug against qemu bug tracker +> +<danpb> quy: but you should also really switch to qcow2 +> +<quy> I see; some people need to update their wikis then. I don't +> +remember where which guide I read when I first learned what little +> +QEMU I know, but I remember it specifically remember it saying QED was +> +the newest and most optimal format. +> +<stsquad> quy: we can only be responsible for our own wiki I'm afraid... +> +<danpb> if you remember where you saw that please let us know so we +> +can try to get it fixed +> +<quy> Thank you very much for the info; I will switch to QCOW. +> +Unfortunately, I'm not sure if I will be able to file any bug reports +> +in the tracker as I can't seem to log Launchpad, which it seems to +> +require. +> +<danpb> quy: an email to the mailing list would suffice too if you +> +can't deal with launchpad +> +<danpb> kwolf: ^^^ in case you're interested in possible QED +> +assertions from 2.12 +> +> +If any more info is needed, feel free to email me; I'm not actually +> +subscribed to this list though. +> +Thank you, +> +Quytelda Kahja +> + +On 06/29/2018 03:07 PM, John Snow wrote: +CC Qemu Block; looks like QED is a bit busted. + +On 06/27/2018 10:25 AM, Quytelda Kahja wrote: +Hello all, +I wanted to submit a bug report in the tracker, but it seem to require +an Ubuntu One account, which I'm having trouble with, so I'll just +give it here and hopefully somebody can make use of it. The issue +seems to be in an experimental format, so it's likely not very +consequential anyway. +Analysis in another thread may be relevant: +https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08963.html +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + +Am 29.06.2018 um 22:16 hat Eric Blake geschrieben: +> +On 06/29/2018 03:07 PM, John Snow wrote: +> +> CC Qemu Block; looks like QED is a bit busted. +> +> +> +> On 06/27/2018 10:25 AM, Quytelda Kahja wrote: +> +> > Hello all, +> +> > I wanted to submit a bug report in the tracker, but it seem to require +> +> > an Ubuntu One account, which I'm having trouble with, so I'll just +> +> > give it here and hopefully somebody can make use of it. The issue +> +> > seems to be in an experimental format, so it's likely not very +> +> > consequential anyway. +> +> +Analysis in another thread may be relevant: +> +> +https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08963.html +The assertion there was: + +qemu-system-x86_64: block.c:3434: bdrv_replace_node: Assertion +`!atomic_read(&to->in_flight)' failed. + +Which quite clearly pointed to a drain bug. This one, however, doesn't +seem to be related to drain, so I think it's probably a different bug. + +Kevin + diff --git a/results/classifier/118/permissions/614958 b/results/classifier/118/permissions/614958 new file mode 100644 index 00000000..fe0bd52f --- /dev/null +++ b/results/classifier/118/permissions/614958 @@ -0,0 +1,137 @@ +permissions: 0.935 +user-level: 0.928 +graphic: 0.908 +assembly: 0.903 +register: 0.901 +risc-v: 0.898 +virtual: 0.884 +PID: 0.882 +semantic: 0.877 +mistranslation: 0.874 +device: 0.869 +arm: 0.868 +hypervisor: 0.838 +architecture: 0.834 +socket: 0.833 +files: 0.830 +peripherals: 0.819 +ppc: 0.807 +KVM: 0.803 +network: 0.800 +boot: 0.793 +VMM: 0.793 +vnc: 0.773 +TCG: 0.769 +performance: 0.768 +debug: 0.656 +x86: 0.602 +kernel: 0.490 +i386: 0.481 + +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/118/permissions/634 b/results/classifier/118/permissions/634 new file mode 100644 index 00000000..6b5207d9 --- /dev/null +++ b/results/classifier/118/permissions/634 @@ -0,0 +1,111 @@ +permissions: 0.857 +virtual: 0.845 +KVM: 0.833 +peripherals: 0.818 +performance: 0.811 +register: 0.811 +device: 0.811 +hypervisor: 0.805 +VMM: 0.805 +TCG: 0.798 +risc-v: 0.797 +debug: 0.789 +user-level: 0.784 +socket: 0.780 +graphic: 0.772 +architecture: 0.759 +ppc: 0.756 +semantic: 0.755 +mistranslation: 0.752 +assembly: 0.731 +arm: 0.727 +vnc: 0.725 +network: 0.720 +PID: 0.679 +x86: 0.665 +boot: 0.663 +kernel: 0.652 +files: 0.593 +i386: 0.483 + +usbredir: assertion failure after suspend/resume when stopped +Description of problem: +Accessing a USB smart card ([Yubikey 5 NFC](https://www.yubico.com/product/yubikey-5-nfc/)) from the guest after host suspend/resume while the guest is stopped and the device is redirected causes QEMU to crash with "Segmentation fault" (with master) or the assertion failure (with Debian 1:6.1+dfsg-5): + + qemu-system-x86_64: ../../hw/usb/core.c:470: usb_packet_complete_one: Assertion `p->stream || QTAILQ_FIRST(&ep->queue) == p' failed. +Steps to reproduce: +1. Run `qemu-system-x86_64` with command line listed above. +2. Run `remote-viewer spice://localhost:3001` in another terminal. +3. Redirect the smart card to the guest in remote-viewer. +4. Run `gpg --card-status` in the guest. +5. Run `stop` in the QEMU monitor. +6. Run `rtcwake --mode mem --seconds 1` as root to suspend the host to S3, then resume. (or `ehco mem >/sys/power/state` or `systemctl suspend` then wake manually) +7. Run `cont` in QEMU monitor to resume the guest. +8. Stop redirecting the smart card to the guest in remote-viewer. +9. Start redirecting the smart card to the guest in remote-viewer. +10. Run `gpg --card-status` in the guest. Repeat if necessary. + +Note that after step 7 the train has left the rails. Executing `gpg --card-status` in the guest at this point would print: + + gpg: selecting card failed: no such device + gpg: OpenPGP card not available: no such device + +However, stopping and resuming redirection appears to be necessary to trigger the assertion failure. + +Also note that on Windows, it's not necessary to execute any `gpg` commands. QEMU will hit the assertion failure after step 9. +Additional information: +<details> +<summary>backtrace with version built from 2c3e83f92d</summary> + + Program terminated with signal SIGSEGV, Segmentation fault. + #0 0x00005623c09a5754 in usb_handle_packet + (dev=0x5623c3592500, p=p@entry=0x7f92e43c81c8) at ../hw/usb/core.c:441 + #1 0x00005623c09be239 in xhci_submit + (epctx=<optimized out>, xfer=<optimized out>, xhci=<optimized out>) + at ../hw/usb/hcd-xhci.c:1783 + #2 xhci_fire_transfer + (epctx=<optimized out>, xfer=<optimized out>, xhci=<optimized out>) + at ../hw/usb/hcd-xhci.c:1792 + #3 xhci_kick_epctx (epctx=0x7f92e43c7c30, streamid=0) + at ../hw/usb/hcd-xhci.c:1951 + #4 0x00005623c09bea1b in xhci_kick_ep + (xhci=<optimized out>, slotid=<optimized out>, epid=<optimized out>, streamid=<optimized out>) at ../hw/usb/hcd-xhci.c:1817 + #5 0x00005623c09bebd8 in xhci_doorbell_write + (ptr=0x7f92ec137970, reg=1, val=4, size=<optimized out>) + at ../hw/usb/hcd-xhci.c:3118 + #6 0x00005623c0abbc7f in memory_region_write_accessor + (mr=mr@entry=0x7f92ec137ed0, addr=4, value=value@entry=0x7f92eda403e8, size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...) + at ../softmmu/memory.c:492 + #7 0x00005623c0ab953e in access_with_adjusted_size + (addr=addr@entry=4, value=value@entry=0x7f92eda403e8, size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn= + 0x5623c0abbc00 <memory_region_write_accessor>, mr=0x7f92ec137ed0, attrs=...) at ../softmmu/memory.c:554 + #8 0x00005623c0abd650 in memory_region_dispatch_write + (mr=mr@entry=0x7f92ec137ed0, addr=4, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../softmmu/memory.c:1511 + #9 0x00005623c0aad417 in flatview_write_continue + (fv=fv@entry=0x7f92e43c7140, addr=addr@entry=4227932164, attrs=attrs@entry=..., ptr=ptr@entry=0x7f92ef17f028, len=len@entry=4, addr1=<optimized out>, l=<optimized out>, mr=0x7f92ec137ed0) + at /home/kevin/tmp/qemu/include/qemu/host-utils.h:165 + #10 0x00005623c0ab09db in flatview_write + (len=4, buf=0x7f92ef17f028, attrs=..., addr=4227932164, fv=0x7f92e43c7140) + at ../softmmu/physmem.c:2820 + #11 address_space_write + (as=<optimized out>, addr=4227932164, attrs=..., buf=buf@entry=0x7f92ef17f028, len=4) at ../softmmu/physmem.c:2912 + #12 0x00005623c0ab0a9f in address_space_rw + (as=<optimized out>, addr=<optimized out>, attrs=..., + attrs@entry=..., buf=buf@entry=0x7f92ef17f028, len=<optimized out>, is_write=<optimized out>) at ../softmmu/physmem.c:2922 + #13 0x00005623c0ba2890 in kvm_cpu_exec (cpu=cpu@entry=0x5623c2729bc0) + at ../accel/kvm/kvm-all.c:2893 + #14 0x00005623c0ba3bbd in kvm_vcpu_thread_fn (arg=arg@entry=0x5623c2729bc0) + at ../accel/kvm/kvm-accel-ops.c:49 + #15 0x00005623c0d0a959 in qemu_thread_start (args=0x7f92eda40610) + at ../util/qemu-thread-posix.c:557 + #16 0x00007f92fd431eae in start_thread (arg=0x7f92eda45640) + at pthread_create.c:463 + #17 0x00007f92fca2fa5f in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +</details> + +Let me know if there are any additional logs or information that would be useful. + +Thanks,\ +Kevin diff --git a/results/classifier/118/permissions/639651 b/results/classifier/118/permissions/639651 new file mode 100644 index 00000000..f432bcfd --- /dev/null +++ b/results/classifier/118/permissions/639651 @@ -0,0 +1,273 @@ +permissions: 0.910 +semantic: 0.904 +register: 0.900 +device: 0.897 +assembly: 0.896 +performance: 0.893 +graphic: 0.870 +debug: 0.869 +boot: 0.868 +vnc: 0.857 +arm: 0.856 +socket: 0.849 +PID: 0.848 +risc-v: 0.836 +virtual: 0.832 +architecture: 0.829 +user-level: 0.827 +peripherals: 0.826 +KVM: 0.816 +mistranslation: 0.808 +VMM: 0.808 +kernel: 0.808 +network: 0.804 +hypervisor: 0.797 +ppc: 0.783 +TCG: 0.782 +files: 0.735 +x86: 0.630 +i386: 0.562 + +DRIVER_IRQL_NOT_LESS_OR_EQUAL booting WIndows XP with Synaptics driver installed + +Positng the issue here since I did not get any reply on the ML. + +I was trying to update some windows XP (SP3) images in kvm. + +It worked fine several times but last time I added mass storage +drivers to sysprep and now on the second boot after reseal (the first +is mini-setup) I get a BSOD with message +DRIVER_IRQL_NOT_LESS_OR_EQUAL. I can post the screenshot if somebody +thinks it is interesting enough. + +The same image works on hardware (which has controllers different from +the qemu PIIX3) and in VirtualBox (with the default PIIX4 as well as +PIIX3) so long as IO apic is enabled). + +I am not sure if this is an error with the MS drivers or how they are +used in sysprep in this particular case or if his is some strange +error in qemu emulation in the PIIX3 controller or elsewhere. + +The image is originally created on hardware with MP acpi (not virtualization). + + + +Note that most of the section is generated by sysprep (the drivers referencing C:\windows), only small part at the end is generated by my script for additional drivers (references C:\drivers). + +The previous images that did not have this section worked only on controllers compatible with the MS generic PCI IDE driver (and also on KVM). + +Just to be sure, you are not using the virtio-blk driver for Windows here? + +I have seen similar crashes with the older version of virtio-blk when used on +recent versions of KVM. + + +On 7 October 2010 11:05, Jes Sorensen <email address hidden> wrote: +> Just to be sure, you are not using the virtio-blk driver for Windows +> here? +> +> I have seen similar crashes with the older version of virtio-blk when used on +> recent versions of KVM. +> +> -- +> DRIVER_IRQL_NOT_LESS_OR_EQUAL booting WIndows XP with Synaptics driver installed +> https://bugs.launchpad.net/bugs/639651 +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> +> Status in QEMU: New +> Status in Debian GNU/Linux: New +> +> Bug description: +> Positng the issue here since I did not get any reply on the ML. +> +> I was trying to update some windows XP (SP3) images in kvm. +> +> It worked fine several times but last time I added mass storage +> drivers to sysprep and now on the second boot after reseal (the first +> is mini-setup) I get a BSOD with message +> DRIVER_IRQL_NOT_LESS_OR_EQUAL. +> +> It turns out that the error is unrelated to storage drivers. It is triggered by Synaptics driver installing for the PS2 mouse in kvm (which does not happen in VirtualBox or on real hardware). +> +> The image is originally created on hardware with MP acpi (not virtualization). +> +> qemu-kvm 0.12.5+dfsg-2 +> +Actually the issue is caused by the Synaptics touchpad driver binding +to the PS/2 mouse device in qemu. + +I have no idea how PS/2 devices are detected but the one present in +qemu is misdetected as a synaptics touchapd by the Synaptics driver +for Windows. + +As a workaround I have patched my qemu to not enable the PS/2 mouse device. + +Thanks + +Michal + +On 10/07/10 11:51, Michal Suchanek wrote: +> Actually the issue is caused by the Synaptics touchpad driver binding +> to the PS/2 mouse device in qemu. +> +> I have no idea how PS/2 devices are detected but the one present in +> qemu is misdetected as a synaptics touchapd by the Synaptics driver +> for Windows. +> +> As a workaround I have patched my qemu to not enable the PS/2 mouse device. + +Hi Michal, + +If you have the time to look, it would be interesting to see what +actually goes over the wire to/from the PS/2 driver in QEMU just prior +to the crash. It would be good to get this fixed. + +Cheers, +Jes + +I have no idea how to log the data. + +I looked at the qemu man page but it does not even mention the PS/2 +mouse as a chardev nor offers an option to log traffic of chardevs +without attaching them to a file and thus detaching them from the +emulated device. + +Thanks + +Michal + +On 10/07/10 12:17, Michal Suchanek wrote: +> I have no idea how to log the data. +> +> I looked at the qemu man page but it does not even mention the PS/2 +> mouse as a chardev nor offers an option to log traffic of chardevs +> without attaching them to a file and thus detaching them from the +> emulated device. + +I would attack it by hacking hw/ps.c a bit to monitor the transactions +in ps2_queue() and ps2_read_data(). + +Cheers, +Jes + + +Attaching logged PS/2 port communication. + +For reference attaching the patch used for obtaining the log. + +I guess the problem here is that qemu emulates some very basic mouse (reported as PS/2 compatible mouse in Windows) whereas real hardware usually has a fancy mouse (reported as MS Explorer compatible mouse in Windows). + +I don't know how PS/2 mice are detected but due to different mice being detected differently there is obviously some detection mechanism. + +The Windos device IDs in a Touchpad driver that does not exhibit the problem (synaptics v8) + +[SynMfg] +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010D +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010E +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010F +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0110 +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0111 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0112 +%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*SYN0113 +%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*SYN0114 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0115 +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0116 +%PS2.SynDeviceDesc% = HP_GROUP1_PS2_Inst,*SYN0117 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0118 +%PS2.SynDeviceDesc% = HP_GROUP5_PS2_Inst,*SYN0119 +%PS2.SynDeviceDesc% = HP_GROUP6_PS2_Inst,*SYN011A +%PS2.SynDeviceDesc% = HP_GROUP4_PS2_Inst,*SYN011B +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN011C +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN011D +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN011E +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN011F +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0120 +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0121 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0122 +%PS2.SynDeviceDesc% = HP_GROUP7_PS2_Inst,*SYN0123 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0124 +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0125 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0126 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0127 +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0128 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0129 +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN012A +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN012B +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN012C + +and in drivers that do exhibit the problem (note the first device): + +Synaptics v9 +[SynMfg] +%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*PNP0F13 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010D +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010E +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010F +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0110 +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0111 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0112 +%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*SYN0113 +%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*SYN0114 +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0115 +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0116 +%PS2.SynDeviceDesc% = HP_GROUP1_PS2_Inst,*SYN0117 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0118 +%PS2.SynDeviceDesc% = HP_GROUP5_PS2_Inst,*SYN0119 +%PS2.SynDeviceDesc% = HP_GROUP6_PS2_Inst,*SYN011A +%PS2.SynDeviceDesc% = HP_GROUP4_PS2_Inst,*SYN011B +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN011C +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN011D +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN011E +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN011F +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0120 +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0121 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0122 +%PS2.SynDeviceDesc% = HP_GROUP7_PS2_Inst,*SYN0123 +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0124 +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0125 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0126 +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0127 +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0128 +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0129 +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN012A +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN012B +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN012C +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN012D +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN012E +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN012F +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0130 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0131 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0132 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0133 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0134 +%PS2.SynDeviceDesc% = HP_GROUP10_PS2_Inst,*SYN0135 +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0136 +%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0137 +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0138 +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0139 +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN013A +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN013B +%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN013C +%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN013D +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN013E +%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN013F + +Syanptics v14 +[SynMfg] +%PS2.DeviceDesc% = DEFAULT__0000__PS2_Inst,*PNP0F13,*PNP0F0E,*PNP0F03,*PNP0F12 ; Std PS/2 mouse +%PS2.SynDeviceDesc% = DEFAULT__0000__PS2_Inst,*SYN0002 ; Synaptics PS2 TouchPad + +Either of the synaptics drivers v9 and v14 would bind to the qemu mouse and crash the system when installed. + +QEMU 0.12 is pretty much outdated nowadays ... can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays? + +Does qemu allow to disable the PS/2 port now? + +If so then there is easy workaround in case something similar ever happens. + + +Hmm, I'm not aware of a way to disable the PS2 mouse in QEMU yet. Looking at your other related bug (https://bugs.launchpad.net/qemu/+bug/813546), I think you might need to discuss that patch on the qemu-devel mailing list. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/67821138 b/results/classifier/118/permissions/67821138 new file mode 100644 index 00000000..3e516a2c --- /dev/null +++ b/results/classifier/118/permissions/67821138 @@ -0,0 +1,224 @@ +architecture: 0.939 +permissions: 0.935 +user-level: 0.917 +device: 0.916 +assembly: 0.915 +risc-v: 0.914 +PID: 0.909 +register: 0.891 +boot: 0.881 +arm: 0.872 +debug: 0.870 +kernel: 0.865 +performance: 0.845 +semantic: 0.843 +peripherals: 0.836 +graphic: 0.826 +files: 0.824 +KVM: 0.822 +virtual: 0.799 +mistranslation: 0.768 +ppc: 0.745 +vnc: 0.734 +network: 0.718 +hypervisor: 0.702 +socket: 0.699 +x86: 0.540 +TCG: 0.498 +i386: 0.432 +VMM: 0.407 + +[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/118/permissions/696094 b/results/classifier/118/permissions/696094 new file mode 100644 index 00000000..69ab7de2 --- /dev/null +++ b/results/classifier/118/permissions/696094 @@ -0,0 +1,174 @@ +permissions: 0.887 +hypervisor: 0.886 +semantic: 0.868 +debug: 0.867 +graphic: 0.864 +files: 0.849 +peripherals: 0.843 +architecture: 0.841 +assembly: 0.841 +virtual: 0.840 +TCG: 0.837 +user-level: 0.834 +device: 0.828 +register: 0.827 +performance: 0.824 +PID: 0.823 +mistranslation: 0.821 +arm: 0.821 +kernel: 0.814 +vnc: 0.812 +network: 0.786 +boot: 0.786 +ppc: 0.782 +i386: 0.774 +VMM: 0.768 +socket: 0.765 +risc-v: 0.734 +KVM: 0.730 +x86: 0.646 + +TI Stellaris lm3s811evb (ARM Cortex-M3) : Systick interrupt not working + +I've tried to create a small project that uses the CMSIS as base library. +The problem is that the SysTick_interrupt_handler() doesn't get executed when the systick event is detected in QEMU. Furthermore, it seems asif QEMU gets stuck in an endless loop. QEMU doesn't respond to Ctrl-C on the command line and the GDB session also stalls. 'kill -9' is the only way to stop QEMU. + +It seems asif the initialisation of the NVIC works fine. I've traced the function calls in QEMU as follows: +stellaris.c: stellaris_init() - Perform generic armv7 init: armv7m_init() + armv7m.c: armv7m_init() - Create and init the nvic: + nvic = qdev_create(NULL, "armv7m_nvic"); + env->nvic = nvic; + qdev_init_nofail(nvic); + - Configure the programmable interrupt controller: + Call: arm_pic_init_cpu() + qemu_allocate_irqs(arm_pic_cpu_handler) + - Initialise 64 interrupt structures. + +The following call sequence is observed when the systick event occur: +armv7m_nvic.c: systick_timer_tick(): set pending interrupt +armv7m_nvic.c: armv7m_nvic_set_pending() for irq:15 + arm_gic.c: gic_set_pending_private(): GIC_SET_PENDING(15,) + arm_gic.c: gic_update() - Raise IRQ with qemu_set_irq() + irq.c: eqmu_set_irq() - Call the irq->handler + -- I assume the irq handler is 'arm_pic_cpu_handler()', + since that was passed as the parameter when + qemu_allocate_irqs() was called in ... + arm_pic.c: arm_pic_cpu_handler() - After evaluation, call cpu_interrupt() + exec.c: cpu_interrupt() is called. + +The tools that were used during the testing of this project: + GCC: Codesourcery ARM eabi 2010q3 + QEMU: Checked out on 31/12/2010 - Last commit: 0fcec41eec0432c77645b4a407d3a3e030c4abc4 +The project files are attached, for reproducing of the errors. + Note: The CMSIS wants to perform byte accesses to the NVIC. For the Cortex-M3, unaligned 8 bit and 16 bit accesses are allowed. The current QEMU implementation doesn't yet cater for it. As a work around, updated versions of +arm_gic.c armv7m_nvic.h armv7m_nvic.c is also included. + +Launch project with: go_gdb.sh +Attach debugger with: arm-none-eabi-gdbtui --command=gdbCommands_tui +(s = step, n = next, c = continue, Ctrl-C = stop, print <variable> to look at variable contents) + + + +I also faced the same problem. I emulated cortex m3 in qemu ( $qemu-system-arm -M lm3s811evb -monitor stdio -kernel out.elf -s -S -gdb tcp::53333 ) and arm-none-linux-gnueabi-gdb --command=./gdbinit + +and my gdbinit is below +set verbose on +set solib-absolute-prefix nonexistantpath +set solib-search-path /root/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib +file out.elf +target remote localhost:53333 +set remote exec-file out.elf + +I didn't use any standard library. Instead I wrote a simple code referring the cortex-m3 manual. The bug section is given below. + +/**** code part *****/ +#define SysTick ( (SysTickTemplate*) 0xE000E010 ) // as in the datasheet + + +typedef struct { + + volatile unsigned int CTRL; + + volatile unsigned int LOAD; + + volatile unsigned int VAL; + + volatile unsigned int CALIB; + +} SysTickTemplate; + + +init() +{ + SysTick->CTRL = 0x4; + + SysTick->LOAD = 8000000; /* Frequency of 1 Hz */ + + SysTick->CTRL |= 1; /* Enable counter */ + + SysTick->CTRL |= 2; /* Enable interrupts */ + + /* here it hangs, even ctrl+C wont work here */ + + int c = 0; + + /* codes....*/ +} + +The same program I used to port into LPC1343 with a SysTickHandler() to toggle an LED and there it worked. + +Any help is appreciated, + +Arun + +I think the problem is line 53 in qemu-linaro/hw/armv7m_nvic.c: +int system_clock_scale; + +This variable is initialized under some conditions from the Stellaris peripheral emulation code, but apparently your code does not trigger this initialization. It then uses the default value of 0, and gets into an infinite loop. + +I suggest that the line be changed to: +int system_clock_scale = 1; + +This not only prevents the crash, but has a side benefit of being able to use the SysTick timer even without other peripherals, like this: +qemu-system-arm -cpu cortex-m3 -nographic -monitor null -serial null -semihosting -kernel test.elf +-device armv7m_nvic -icount 1 + +I still get hangs by messing around with the -icount parameter, but it is a different bug - ctrl-C gets you out of those hangs. + +ssys_reset() should be calling ssys_calculate_system_clock(). (We should probably use a saner default value, though. Or treat system_clock_scale == 0 as "this board doesn't provide an external clock reference". And do we really have the sense right on the SYSTICKX_CLKSOURCE flag?) + +> qemu-system-arm -cpu cortex-m3 -nographic -monitor null -serial null -semihosting -kernel test.elf -device armv7m_nvic -icount 1 + +This is a nonsensical command line since it will try to instantiate an Integrator board model with a Cortex-M3 CPU. It's not possible to correctly wire up the armv7m_nvic device from the command line, in fact, so any qemu command line that tries to do so is inherently broken; to the extent that it works this will be purely by fluke. + + +NB: the attached project fails for me like this: +qemu: hardware error: gic_dist_writeb: Bad offset d23 + +CPU #0: +R00=ffffffff R01=e000ed00 R02=000000e0 R03=e000ed0b +R04=00000000 R05=00000000 R06=00000000 R07=200004bb +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=200004bb R14=000003bd R15=00000338 +PSR=80000173 N--- T svc32 + +This is because we don't support byte wide accesses to the SHPR* registers. (The error message refers to the GIC because we currently map the whole of that area of address space as part of the GIC and then have it redirect some areas to code in arm7m_nvic.c. That should probably be cleaned up.) + + +http://<email address hidden>/msg90256.html has some patches from Sebastian Huber which let him run the RTEMS real time system on the TI Stellaris LM3S6965 with a working system tick. As he notes, some of them are hacks and not suitable for applying to qemu, but they give a reasonable list of problems needing fixing: + +(1) SHPR* (and some other) system registers need to be byte and halfword accessible +(2) GIC priority mask feature not correct for v7M? [actually this looks to be wrong for A profile too, at least as far as the reset value goes: 11MPCore had a reset value of 0xf0 but A9 has reset value of 0.] +(3) BASEPRI and BASEPRI_MAX are totally ignored at the moment +(4) not very much RAM and it's not configurable from command line + +(2) and (3) add up to "we don't implement the M profile execution priority and exception model properly"; I strongly suspect there are further bugs in this area. (I'm not convinced that sharing code between the A profile GIC and the M profile NVIC is worthwhile, incidentally.) + + +I've just retested with the project attached to the bug (had to hack it a little bit to build with a recent gcc, but nothing affecting the timer code), and with current head-of-git QEMU we execute it OK and putting a breakpoint on the SysTick_Handler function shows that it is being invoked once a second, as expected. + +From my comment #6, we've fixed SHPR byte/halfword accessibility, and rewritten the NVIC handling so it gets priority masking, BASEPRI, etc right. The stellaris boards having not much RAM is unavoidable, but we do now have the mps2 boards if you need a basic M profile system with more memory. + +So I'm going to close this bug as fix-committed, as it should be fixed in 2.11. (It might have been fixed already in 2.10, but 2.11 will definitely be OK.) + + diff --git a/results/classifier/118/permissions/721659 b/results/classifier/118/permissions/721659 new file mode 100644 index 00000000..6190da1c --- /dev/null +++ b/results/classifier/118/permissions/721659 @@ -0,0 +1,70 @@ +permissions: 0.942 +virtual: 0.885 +KVM: 0.875 +device: 0.833 +peripherals: 0.804 +socket: 0.789 +kernel: 0.745 +mistranslation: 0.712 +hypervisor: 0.709 +user-level: 0.704 +debug: 0.695 +graphic: 0.692 +semantic: 0.668 +PID: 0.621 +ppc: 0.602 +architecture: 0.599 +performance: 0.538 +network: 0.529 +assembly: 0.524 +register: 0.509 +boot: 0.471 +vnc: 0.434 +VMM: 0.411 +x86: 0.382 +arm: 0.377 +files: 0.293 +i386: 0.290 +risc-v: 0.282 +TCG: 0.182 + +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/118/permissions/785668 b/results/classifier/118/permissions/785668 new file mode 100644 index 00000000..59a35941 --- /dev/null +++ b/results/classifier/118/permissions/785668 @@ -0,0 +1,437 @@ +permissions: 0.897 +KVM: 0.892 +register: 0.880 +architecture: 0.859 +assembly: 0.850 +performance: 0.839 +VMM: 0.828 +user-level: 0.827 +arm: 0.825 +kernel: 0.822 +virtual: 0.818 +ppc: 0.817 +graphic: 0.811 +PID: 0.810 +hypervisor: 0.794 +device: 0.791 +network: 0.774 +debug: 0.757 +risc-v: 0.751 +TCG: 0.729 +vnc: 0.719 +semantic: 0.692 +peripherals: 0.687 +mistranslation: 0.687 +boot: 0.687 +files: 0.661 +socket: 0.649 +x86: 0.621 +i386: 0.249 + +bonding inside a bridge does not update ARP correctly when bridged net accessed from within a VM + +Binary package hint: qemu-kvm + +Description: Ubuntu 10.4.2 +Release: 10.04 + + +When setting a KVM host with a bond0 interface made of eth0 and eth1 and using this bond0 interface for a bridge to KVM VMs, the ARP tables do not get updated correctly and + +Reproducible: 100%, with any of the load balancing mode + +How to reproduce the problem + +- Prerequisites: +1 One KVM system with 10.04.02 server, configured as a virtual host is needed. The following /etc/network/interfaces was used for the test : + +# grep -v ^# /etc/network/interfaces +auto lo +iface lo inet loopback + + +auto bond0 +iface bond0 inet manual + post-up ifconfig $IFACE up + pre-down ifconfig $IFACE down + bond-slaves none + bond_mode balance-rr + bond-downdelay 250 + bond-updelay 120 +auto eth0 +allow-bond0 eth0 +iface eth0 inet manual + bond-master bond0 +auto eth1 +allow-bond0 eth1 +iface eth1 inet manual + bond-master bond0 + +auto br0 +iface br0 inet dhcp + # dns-* options are implemented by the resolvconf package, if installed + bridge-ports bond0 + bridge-stp off + bridge-fd 9 + bridge-hello 2 + bridge-maxage 12 + bridge_max_wait 0 + +One VM running Maverick 10.10 server, standard installation, using the following /etc/network/interfaces file : + +grep -v ^# /etc/network/interfaces + +auto lo +iface lo inet loopback + +auto eth0 +iface eth0 inet static + address 10.153.107.92 + netmask 255.255.255.0 + network 10.153.107.0 + broadcast 10.153.107.255 + +-------------- +On a remote bridged network system : +$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 + +On KVMhost +$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +On VM +$ arp -an +? (10.153.107.61) at <incomplete> on eth0 + +1) Test #1 : ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) : + +- On remote bridged network system : +caribou@marvin:~$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 + +- On KVMhost +ubuntu@VMhost:~$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +ubuntu@vm1:~$ ping 10.153.107.80 +PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data. +From 10.153.107.92 icmp_seq=1 Destination Host Unreachable +From 10.153.107.92 icmp_seq=2 Destination Host Unreachable +From 10.153.107.92 icmp_seq=3 Destination Host Unreachable +^C +--- 10.153.107.80 ping statistics --- +4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3010ms +pipe 3 +ubuntu@vm1:~$ arp -an +? (10.153.107.61) at <incomplete> on eth0 +? (10.153.107.80) at <incomplete> on eth0 + +2) Test #2 : ping from remote bridged network system (10.153.107.80) to VM (10.153.107.92) : + +- On remote bridged network system : +$ ping 10.153.107.92 +PING 10.153.107.92 (10.153.107.92) 56(84) bytes of data. +64 bytes from 10.153.107.92: icmp_req=1 ttl=64 time=327 ms +64 bytes from 10.153.107.92: icmp_req=2 ttl=64 time=158 ms +64 bytes from 10.153.107.92: icmp_req=3 ttl=64 time=157 ms +^C +--- 10.153.107.92 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2003ms +rtt min/avg/max/mdev = 157.289/214.500/327.396/79.831 ms +caribou@marvin:~$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 +? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0 + +- On KVMhost +$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +arp -an +? (10.153.107.61) at <incomplete> on eth0 +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on eth0 + + +3) Test #3 : New ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) : +- On remote bridged network system : +$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 +? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0 + +- On KVMhost +ubuntu@VMhost:~$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +ubuntu@vm1:~$ ping 10.153.107.80 +PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data. +64 bytes from 10.153.107.80: icmp_req=1 ttl=64 time=154 ms +64 bytes from 10.153.107.80: icmp_req=2 ttl=64 time=170 ms +64 bytes from 10.153.107.80: icmp_req=3 ttl=64 time=154 ms +^C +--- 10.153.107.80 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2003ms +rtt min/avg/max/mdev = 154.072/159.465/170.058/7.504 ms + +tcpdump traces are available for those tests. Test system is available upon request. + +Workaround: + +Use the bonded device in "active-backup" mode + +ProblemType: Bug +DistroRelease: Ubuntu 10.04.02 +Package: qemu-kvm-0.12.3+noroms-0ubuntu9.6 +Uname: Linux 2.6.35-25-serverr x86_64 +Architecture: amd64 + +Thanks for reporting this bug and the detailed reproduction instructions. I would mark it high, but since you offer a workaround I'll mark it medium instead. + +What does your /etc/modprobe.d/bonding show? + +I've not used this combination myself, but from those who have, a few things do appear fragile, namely: + +1. if you are using 802.3ad, you need trunking enabled on the physical switch + +2. some people find that turning stp on helps (http://www.linuxquestions.org/questions/linux-networking-3/bridging-a-bond-802-3ad-only-works-when-stp-is-enabled-741640/) + +But I'm actually wondering whether this patch: + +http://permalink.gmane.org/gmane.linux.network/159403 + +may be needed. If so, then even the natty kernel does not yet have that fix. + +I am marking this as affecting the kernel, since I believe that is where the bug lies. + + +Actually, I may be wrong about this being a kernel issue. + +Are you always able to ping the remote host from the kvm host, even when you can't do so from the VM? + +In addition to kvmhost's /etc/modprove.d/bonding.conf, can you also please provide the configuration info for the KVM vm? (If a libvirt host, then the network-related (or just all) xml info, or else the 'ps -ef | grep kvm' output). Also the network configuration insid the KVM VM. In particular, if the KVM VM has a bridge, that one would need to have stp turned on, but I doubt you have that. + +Yup, I can reproduce this 100%. + +I'm setting up networking as described above, and then starting virtual machines with: + +sudo tunctl -u 1000 -g 1000 -t tap0 +sudo /sbin/ifconfig $1 0.0.0.0 up +sudo brctl addif br0 tap0 + +kvm -drive file=disk.img,if=virtio,cache=none,boot=on -m 1024 -vnc :1 -net nic,model=virtio -net tap,script=no,ifname=tap0,downscript=no + +With mode=balance-rr, I can't run dhclient from the guest. With either +bond0 as active-backup, or without bond0 (with eth0 directly in br0), +I can. + + +Following the advice toward the bottom of + +http://forum.proxmox.com/archive/index.php/t-2676.html?s=e8a9cfc9a128659e4a61efec0b758d3e + +I was able to get this to work with balance-rr by changing a few bridge properties. The following was my /etc/network/interfaces: + +# This file describes the network interfaces available on your system +# and how to activate them. For more information, see interfaces(5). + +# The loopback network interface +auto lo +iface lo inet loopback + +auto bond0 +iface bond0 inet manual + post-up ifconfig $IFACE up + pre-down ifconfig $IFACE down + bond-slaves none + bond_mode active-rr + bond-downdelay 250 + bond-updelay 120 +auto eth0 +allow-bond0 eth0 +iface eth0 inet manual + bond-master bond0 +auto eth1 +allow-bond0 eth1 +iface eth1 inet manual + bond-master bond0 + +auto br0 +iface br0 inet dhcp + # dns-* options are implemented by the resolvconf package, if installed + bridge-ports bond0 +# bridge-stp off +# bridge-fd 9 +# bridge-hello 2 +# bridge-maxage 12 +# bridge_max_wait 0 + bridge_stp on + bridge_maxwait 0 + bridge_maxage 0 + bridge_fd 0 + bridge_ageing 0 + +I don't know if this is acceptable to you since stp is on. If not, is using balance-alb (which did also work for me) acceptable? + +Following your suggestions, I modified my /etc/network/interfaces & added the STP options to my test environment. Following that, I am now able to ping to the remote system using the following bonding modes : + +* 802.3ad (4) +* tlb (5) +* alb (6) + +For unknown reasons, I'm still unable to use balance-rr unlike your setup. But that might not be much of an issue as those modes listed above might be sufficient. I must go & check that. And now, the two VMs are able to ping each other. + +One thing regarding your listed /etc/network/interfaces : I think that there is a typo as 'bond_mode active-rr' is not a support bonding mode. + +Regarding your request for /etc/modprove.d/bonding.conf, there is no such file on my test system. Let me know if you still require the xml dump of the VM. + +Quoting Louis Bouchard (<email address hidden>): +> Regarding your request for /etc/modprove.d/bonding.conf, there is no +> such file on my test system. + +Right, sorry, that's obsolete as of hardy, sorry. + +> Let me know if you still require the xml +> dump of the VM. + +Thanks, no, as I'm able to reproduce that won't be necessary. + + +I can reproduce this just using lxc, which simply attaches an endpoint of a veth tunnel to the bridge. With balance-rr mode, i can't dhcp in the guest. With balance-alb, I can. + +That means this is not actually qemu-kvm, but a bug in the kernel or (unlikely) ifenslave. + +My next steps will be to test on maverick and natty, look through linux-2.6/drivers/net/bonding and linux-2.6/net/bridge/ and perhaps go to the https://lists.linux-foundation.org/pipermail/bridge/2011-May/thread.html list to ask for help if it is still broken in natty. + +Maverick gives me the same result. (Except I don't seem able, in maverick, to auto-setup the bond+bridge setup with /etc/network/interfaces, keep having to do it by hand. Hoping I did something wrong myself,a nd it's not a maverick bug) + +Natty is still affected. + +Since qemu isn't needed to show the bug, you can now trivially test this inside a natty kvm container by giving it two NICs, setting up /etc/network interfaces as shown above, and using lxc as follows: + + apt-get install lxc debootstrap + mkdir /cgroup + mount -t cgroup cgroup /cgroup + cat > /etc/lxc.conf << EOF + lxc.network.type=veth + lxc.network.link=br0 + lxc.network.flags=up + EOF + lxc-create -t natty -n lxc -f /etc/lxc.conf + lxc-start -n lxc + +When not using balance-rr, the container's network is fine. When using balance-rr, it can't get a dhcp address. + +Next step is probably to look at the hwaddr handling in the kernel source, and talk to upstream. + + +I sent an email to bonding-devel, and got this response: + +http://sourceforge.net/mailarchive/forum.php?thread_name=21866.1306527811%40death&forum_name=bonding-devel + +Assuming that your switch is in fact set up for Etherchannel, can you go ahead and gather the tcpdump data? + +I read the mail and did a first round of test before I could check the setting of the switch. Here are the transcript of the test with balance-rr. + +Container : LXC container with fixed IP +VMhost : The host where the LXC container runs. configured with br0 & bond0 +remote_host : another host on the same bridged subnet + +Container : date;ping xxx.xxx.xxx.87 +Mon May 30 15:40:49 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +^C--- xxx.xxx.xxx.87 ping statistics --- +4 packets transmitted, 0 packets received, 100% packet loss + + +VMhost : date;ping xxx.xxx.xxx.92 +Mon May 30 15:41:14 EDT 2011 +PING xxx.xxx.xxx.92 (xxx.xxx.xxx.92) 56(84) bytes of data. +64 bytes from xxx.xxx.xxx.92: icmp_req=9 ttl=64 time=10.1 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=10 ttl=64 time=0.087 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=11 ttl=64 time=0.076 ms +^C +--- xxx.xxx.xxx.92 ping statistics --- +11 packets transmitted, 3 received, 72% packet loss, time 10004ms +rtt min/avg/max/mdev = 0.076/3.423/10.108/4.727 ms + + +Container : date;ping xxx.xxx.xxx.87 +Mon May 30 15:41:41 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +^C--- xxx.xxx.xxx.87 ping statistics --- +4 packets transmitted, 0 packets received, 100% packet loss + + +remote_host : date;ping xxx.xxx.xxx.92 +lundi 30 mai 2011, 15:42:03 (UTC+0200) +PING xxx.xxx.xxx.92 (xxx.xxx.xxx.92) 56(84) bytes of data. +64 bytes from xxx.xxx.xxx.92: icmp_req=1 ttl=64 time=284 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=2 ttl=64 time=125 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=3 ttl=64 time=134 ms +^C +--- xxx.xxx.xxx.92 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2002ms +rtt min/avg/max/mdev = 125.282/181.561/284.952/73.204 ms + + +Container : Mon May 30 15:42:24 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +56 bytes from xxx.xxx.xxx.87: icmp_seq=0 ttl=64 time=141.506 ms +56 bytes from xxx.xxx.xxx.87: icmp_seq=1 ttl=64 time=153.311 ms +56 bytes from xxx.xxx.xxx.87: icmp_seq=2 ttl=64 time=124.973 ms +^C--- xxx.xxx.xxx.87 ping statistics --- +3 packets transmitted, 3 packets received, 0% packet loss +round-trip min/avg/max/stddev = 124.973/139.930/153.311/11.622 ms + +I will send you the dump data directly. Now that I have full access to our switch, I will do more tests tomorrow. As far as I know, the switch is doing automatic trunking so the switch should not be an issue. + + +Hello, + +Now I am dazed and confused (and trying to continue) + +I have tested most of the combination of bonding modes with appropriate switch settings and here is what I get : + +Bonding mode switch configuration result(ping from Container) With STP +============ ==================== ====== ======== +balance-rr two port trunked OK +balance-rr No trunking NOK OK +balance-alb No trunking OK +balance-tlb No trunking OK +802.3ad LACP dynamic trunk OK +balance-xor two port trunked OK +balance-xor No trunking NOK NOK + +I could swear that I had tested -alb and -tlb with negative results. So apparently, the STP workaround is not required with proper switch configuration. + +It looks like this has been fixed upstream. I will close it. If the problem still occurs, please reopen it. + + diff --git a/results/classifier/118/permissions/811683 b/results/classifier/118/permissions/811683 new file mode 100644 index 00000000..02705e46 --- /dev/null +++ b/results/classifier/118/permissions/811683 @@ -0,0 +1,336 @@ +permissions: 0.952 +PID: 0.920 +debug: 0.919 +assembly: 0.912 +semantic: 0.906 +register: 0.905 +device: 0.904 +arm: 0.900 +performance: 0.896 +architecture: 0.896 +kernel: 0.894 +files: 0.892 +graphic: 0.891 +socket: 0.887 +user-level: 0.887 +ppc: 0.876 +risc-v: 0.858 +virtual: 0.854 +boot: 0.848 +KVM: 0.846 +mistranslation: 0.842 +vnc: 0.841 +network: 0.832 +hypervisor: 0.832 +peripherals: 0.819 +VMM: 0.804 +TCG: 0.792 +i386: 0.683 +x86: 0.680 + +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/118/permissions/878 b/results/classifier/118/permissions/878 new file mode 100644 index 00000000..eaeb433b --- /dev/null +++ b/results/classifier/118/permissions/878 @@ -0,0 +1,72 @@ +permissions: 0.946 +user-level: 0.926 +mistranslation: 0.909 +register: 0.907 +debug: 0.903 +graphic: 0.901 +assembly: 0.889 +kernel: 0.885 +architecture: 0.881 +semantic: 0.878 +device: 0.876 +files: 0.872 +peripherals: 0.865 +virtual: 0.855 +arm: 0.854 +performance: 0.850 +x86: 0.850 +hypervisor: 0.850 +risc-v: 0.842 +ppc: 0.818 +VMM: 0.808 +network: 0.799 +PID: 0.799 +KVM: 0.793 +TCG: 0.778 +i386: 0.778 +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/118/permissions/907063 b/results/classifier/118/permissions/907063 new file mode 100644 index 00000000..35233a8c --- /dev/null +++ b/results/classifier/118/permissions/907063 @@ -0,0 +1,89 @@ +permissions: 0.818 +peripherals: 0.730 +semantic: 0.687 +user-level: 0.666 +graphic: 0.623 +assembly: 0.608 +hypervisor: 0.607 +arm: 0.568 +debug: 0.567 +device: 0.565 +register: 0.548 +risc-v: 0.527 +virtual: 0.520 +ppc: 0.500 +VMM: 0.492 +mistranslation: 0.490 +network: 0.489 +PID: 0.470 +performance: 0.459 +vnc: 0.438 +architecture: 0.416 +boot: 0.402 +x86: 0.401 +KVM: 0.401 +kernel: 0.397 +i386: 0.379 +socket: 0.378 +TCG: 0.340 +files: 0.338 + +Error reading VMDK4 with footer instead of header + +VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END +"). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file. + +I have regression-tested this with various OVAs exported from VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were unable to import any compressed VMDKs with a footer. It now works on all the ones I have. + +bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ *before* rgd_offset. I was only able to get VMDK conversion to work by switching the order back to that specified by VMWare and previously used by QEMU. I don't know what VMDK this commit is referring to, so I can't test to see if I've broken it. :( + +I will submit this patch to the mailing list if I get a chance, but I'm also uploading it here so I don't lose it. + + + +On Tue, Dec 20, 2011 at 8:53 PM, bbgordonn <email address hidden> wrote: +> Public bug reported: +> +> VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END +> "). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file. +> +> I have regression-tested this with various OVAs exported from +> VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were +> unable to import any compressed VMDKs with a footer. It now works on all +> the ones I have. +> +> bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset +> and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec +> from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ +> *before* rgd_offset. I was only able to get VMDK conversion to work by +> switching the order back to that specified by VMWare and previously used +> by QEMU. I don't know what VMDK this commit is referring to, so I can't +> test to see if I've broken it. :( +> +> I will submit this patch to the mailing list if I get a chance, but I'm +> also uploading it here so I don't lose it. +> +> ** 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/907063 + +Thanks for reporting this. I have CCed Fam who worked on VMDK this summer. + +Please submit patches to the mailing list according to the guidelines here: + +http://wiki.qemu.org/Contribute/SubmitAPatch + +Stefan + + +Looks like something similar has been commited here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=65bd155c7356d448ffee7 +So is this problem fixed nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/permissions/944 b/results/classifier/118/permissions/944 new file mode 100644 index 00000000..0030d76c --- /dev/null +++ b/results/classifier/118/permissions/944 @@ -0,0 +1,58 @@ +permissions: 0.976 +device: 0.943 +user-level: 0.916 +performance: 0.876 +files: 0.874 +graphic: 0.871 +network: 0.807 +debug: 0.704 +socket: 0.663 +architecture: 0.661 +semantic: 0.647 +peripherals: 0.643 +kernel: 0.619 +PID: 0.576 +ppc: 0.573 +hypervisor: 0.530 +assembly: 0.480 +register: 0.451 +vnc: 0.433 +boot: 0.390 +arm: 0.372 +x86: 0.363 +mistranslation: 0.362 +VMM: 0.356 +risc-v: 0.333 +virtual: 0.275 +TCG: 0.223 +i386: 0.135 +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/118/permissions/951 b/results/classifier/118/permissions/951 new file mode 100644 index 00000000..f2814d17 --- /dev/null +++ b/results/classifier/118/permissions/951 @@ -0,0 +1,225 @@ +permissions: 0.815 +peripherals: 0.792 +virtual: 0.784 +architecture: 0.713 +hypervisor: 0.689 +assembly: 0.686 +performance: 0.681 +debug: 0.675 +graphic: 0.674 +files: 0.669 +semantic: 0.658 +device: 0.651 +register: 0.646 +KVM: 0.639 +TCG: 0.629 +user-level: 0.627 +risc-v: 0.602 +arm: 0.592 +ppc: 0.589 +socket: 0.581 +mistranslation: 0.549 +boot: 0.538 +x86: 0.513 +PID: 0.509 +kernel: 0.491 +network: 0.488 +vnc: 0.413 +i386: 0.358 +VMM: 0.354 + +Build error +Description of problem: +``` +changing dir to build for make ""... +make[1]: Entering directory '/qemu-git/qemu/build' + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp +[1/1037] Generating ar with a custom command +[2/1037] Generating bepo with a custom command +[3/1037] Generating cz with a custom command +[4/1037] Generating da with a custom command +[5/1037] Generating de with a custom command +[6/1037] Generating de-ch with a custom command +[7/1037] Generating en-gb with a custom command +[8/1037] Generating en-us with a custom command +[9/1037] Generating es with a custom command +[10/1037] Generating et with a custom command +[11/1037] Generating fi with a custom command +[12/1037] Generating fo with a custom command +[13/1037] Generating fr-be with a custom command +[14/1037] Generating fr with a custom command +[15/1037] Generating fr-ca with a custom command +[16/1037] Generating fr-ch with a custom command +[17/1037] Generating hr with a custom command +[18/1037] Generating hu with a custom command +[19/1037] Generating is with a custom command +[20/1037] Generating it with a custom command +[21/1037] Generating ja with a custom command +[22/1037] Generating lt with a custom command +[23/1037] Generating mk with a custom command +[24/1037] Generating lv with a custom command +[25/1037] Generating nl with a custom command +[26/1037] Generating no with a custom command +[27/1037] Generating pt with a custom command +[28/1037] Generating pl with a custom command +[29/1037] Generating ru with a custom command +[30/1037] Generating pt-br with a custom command +[31/1037] Generating th with a custom command +[32/1037] Generating tr with a custom command +[33/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_i64.c.o +[34/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_common.c.o +[35/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_ui32.c.o +[36/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_random.c.o +[37/1037] Generating Test QAPI files with a custom command +[38/1037] Generating QAPI test (include) with a custom command +[39/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_uint128.c.o +[40/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_functions_common.c.o +[41/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_extF80.c.o +[42/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_functionInfos.c.o +[43/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_ui64.c.o +[44/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f16.c.o +[45/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_i32.c.o +[46/1037] Generating edk2-i386-vars.fd with a custom command (wrapped by meson to capture output) +[47/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_uint128_inline.c.o +[48/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_standardFunctionInfos.c.o +[49/1037] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_fail.c.o +[50/1037] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +[51/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f32.c.o +[52/1034] Compiling C object tests/fp/libsoftfloat.a.p/berkeley-softfloat-3_source_s_eq128.c.o +[53/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_writeTestsTotal.c.o +[54/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f64.c.o +[55/1034] Generating edk2-x86_64-code.fd with a custom command (wrapped by meson to capture output) +[56/1034] Compiling C object tests/fp/libtestfloat.a.p/berkeley-testfloat-3_source_genCases_f128.c.o +[57/1034] Generating edk2-x86_64-secure-code.fd with a custom command (wrapped by meson to capture output) +[58/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-iova-tree.c.o +[59/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-shadow-virtqueue.c.o +[60/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o +FAILED: libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o +cc -m64 -mcx16 -Ilibqemu-x86_64-softmmu.fa.p -I. -I.. -Itarget/i386 -I../target/i386 -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /qemu-git/qemu/linux-headers -isystem linux-headers -iquote . -iquote /qemu-git/qemu -iquote /qemu-git/qemu/include -iquote /qemu-git/qemu/disas/libvixl -iquote /qemu-git/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="x86_64-softmmu-config-target.h"' '-DCONFIG_DEVICES="x86_64-softmmu-config-devices.h"' -MD -MQ libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -MF libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o.d -o libqemu-x86_64-softmmu.fa.p/hw_vfio_pci-quirks.c.o -c ../hw/vfio/pci-quirks.c +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_gtt_max’: +../hw/vfio/pci-quirks.c:1356:55: error: ‘IGD_GMCH’ undeclared (first use in this function) + 1356 | uint32_t gmch = vfio_pci_read_config(&vdev->pdev, IGD_GMCH, sizeof(gmch)); + | ^~~~~~~~ +../hw/vfio/pci-quirks.c:1356:55: note: each undeclared identifier is reported only once for each function it appears in +../hw/vfio/pci-quirks.c:1357:21: error: implicit declaration of function ‘igd_gen’ [-Werror=implicit-function-declaration] + 1357 | int ggms, gen = igd_gen(vdev); + | ^~~~~~~ +../hw/vfio/pci-quirks.c:1357:21: error: nested extern declaration of ‘igd_gen’ [-Werror=nested-externs] +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_data_read’: +../hw/vfio/pci-quirks.c:1384:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1384 | VFIOIGDQuirk *igd = opaque; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1385:30: error: request for member ‘vdev’ in something not a structure or union + 1385 | VFIOPCIDevice *vdev = igd->vdev; + | ^~ +../hw/vfio/pci-quirks.c:1387:8: error: request for member ‘index’ in something not a structure or union + 1387 | igd->index = ~0; + | ^~ +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_data_write’: +../hw/vfio/pci-quirks.c:1395:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1395 | VFIOIGDQuirk *igd = opaque; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1396:30: error: request for member ‘vdev’ in something not a structure or union + 1396 | VFIOPCIDevice *vdev = igd->vdev; + | ^~ +../hw/vfio/pci-quirks.c:1414:13: error: request for member ‘index’ in something not a structure or union + 1414 | if ((igd->index % 4 == 1) && igd->index < vfio_igd_gtt_max(vdev)) { + | ^~ +../hw/vfio/pci-quirks.c:1414:37: error: request for member ‘index’ in something not a structure or union + 1414 | if ((igd->index % 4 == 1) && igd->index < vfio_igd_gtt_max(vdev)) { + | ^~ +../hw/vfio/pci-quirks.c:1415:28: error: request for member ‘index’ in something not a structure or union + 1415 | if (gen < 8 || (igd->index % 8 == 1)) { + | ^~ +../hw/vfio/pci-quirks.c:1418:53: error: ‘IGD_BDSM’ undeclared (first use in this function) + 1418 | base = pci_get_long(vdev->pdev.config + IGD_BDSM); + | ^~~~~~~~ +../hw/vfio/pci-quirks.c:1420:17: error: implicit declaration of function ‘hw_error’; did you mean ‘herror’? [-Werror=implicit-function-declaration] + 1420 | hw_error("vfio-igd: Guest attempted to program IGD GTT before " + | ^~~~~~~~ + | herror +../hw/vfio/pci-quirks.c:1420:17: error: nested extern declaration of ‘hw_error’ [-Werror=nested-externs] +../hw/vfio/pci-quirks.c:1424:29: error: request for member ‘bdsm’ in something not a structure or union + 1424 | val = data - igd->bdsm + base; + | ^~ +../hw/vfio/pci-quirks.c:1430:42: error: request for member ‘index’ in something not a structure or union + 1430 | igd->index, data, val); + | ^~ +../hw/vfio/pci-quirks.c:1435:8: error: request for member ‘index’ in something not a structure or union + 1435 | igd->index = ~0; + | ^~ +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_index_read’: +../hw/vfio/pci-quirks.c:1447:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1447 | VFIOIGDQuirk *igd = opaque; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1448:30: error: request for member ‘vdev’ in something not a structure or union + 1448 | VFIOPCIDevice *vdev = igd->vdev; + | ^~ +../hw/vfio/pci-quirks.c:1450:8: error: request for member ‘index’ in something not a structure or union + 1450 | igd->index = ~0; + | ^~ +../hw/vfio/pci-quirks.c: In function ‘vfio_igd_quirk_index_write’: +../hw/vfio/pci-quirks.c:1458:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1458 | VFIOIGDQuirk *igd = opaque; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1459:30: error: request for member ‘vdev’ in something not a structure or union + 1459 | VFIOPCIDevice *vdev = igd->vdev; + | ^~ +../hw/vfio/pci-quirks.c:1461:8: error: request for member ‘index’ in something not a structure or union + 1461 | igd->index = data; + | ^~ +../hw/vfio/pci-quirks.c: At top level: +../hw/vfio/pci-quirks.c:1472:13: error: static declaration of ‘vfio_probe_igd_bar4_quirk’ follows non-static declaration + 1472 | static void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr) + | ^~~~~~~~~~~~~~~~~~~~~~~~~ +In file included from ../hw/vfio/pci-quirks.c:27: +../hw/vfio/pci.h:211:6: note: previous declaration of ‘vfio_probe_igd_bar4_quirk’ was here + 211 | void vfio_probe_igd_bar4_quirk(VFIOPCIDevice *vdev, int nr); + | ^~~~~~~~~~~~~~~~~~~~~~~~~ +../hw/vfio/pci-quirks.c: In function ‘vfio_probe_igd_bar4_quirk’: +../hw/vfio/pci-quirks.c:1477:5: error: unknown type name ‘VFIOIGDQuirk’; did you mean ‘VFIOQuirk’? + 1477 | VFIOIGDQuirk *igd; + | ^~~~~~~~~~~~ + | VFIOQuirk +../hw/vfio/pci-quirks.c:1511:46: error: ‘IGD_GMCH’ undeclared (first use in this function) + 1511 | gmch = vfio_pci_read_config(&vdev->pdev, IGD_GMCH, 4); + | ^~~~~~~~ +../hw/vfio/pci-quirks.c:1603:32: error: ‘ERR_PREFIX’ undeclared (first use in this function) + 1603 | error_reportf_err(err, ERR_PREFIX, vdev->vbasedev.name); + | ^~~~~~~~~~ +../hw/vfio/pci-quirks.c:1638:8: error: request for member ‘vdev’ in something not a structure or union + 1638 | igd->vdev = vdev; + | ^~ +../hw/vfio/pci-quirks.c:1639:8: error: request for member ‘index’ in something not a structure or union + 1639 | igd->index = ~0; + | ^~ +../hw/vfio/pci-quirks.c:1640:8: error: request for member ‘bdsm’ in something not a structure or union + 1640 | igd->bdsm = vfio_pci_read_config(&vdev->pdev, IGD_BDSM, 4); + | ^~ +../hw/vfio/pci-quirks.c:1640:51: error: ‘IGD_BDSM’ undeclared (first use in this function) + 1640 | igd->bdsm = vfio_pci_read_config(&vdev->pdev, IGD_BDSM, 4); + | ^~~~~~~~ +../hw/vfio/pci-quirks.c:1641:8: error: request for member ‘bdsm’ in something not a structure or union + 1641 | igd->bdsm &= ~((1 << 20) - 1); /* 1MB aligned */ + | ^~ +cc1: all warnings being treated as errors +[61/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-crypto-pci.c.o +[62/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-crypto.c.o +[63/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user-fs.c.o +[64/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user-fs-pci.c.o +[65/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-vdpa.c.o +[66/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_virtio-balloon.c.o +[67/1034] Compiling C object libqemu-x86_64-softmmu.fa.p/hw_virtio_vhost-user.c.o +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:163: run-ninja] Error 1 +make[1]: Leaving directory '/qemu-git/qemu/build' +make: *** [GNUmakefile:11: all] Error 2 +``` +Steps to reproduce: +1. git clone git://git.qemu.org/qemu.git +2. ./configure --prefix=/usr \--target-list=x86_64-softmmu +3. make -j8 diff --git a/results/classifier/118/permissions/952 b/results/classifier/118/permissions/952 new file mode 100644 index 00000000..f1037810 --- /dev/null +++ b/results/classifier/118/permissions/952 @@ -0,0 +1,127 @@ +permissions: 0.977 +graphic: 0.972 +semantic: 0.954 +debug: 0.943 +PID: 0.926 +risc-v: 0.922 +virtual: 0.922 +device: 0.915 +performance: 0.915 +register: 0.914 +peripherals: 0.895 +arm: 0.892 +assembly: 0.889 +architecture: 0.878 +user-level: 0.875 +TCG: 0.862 +ppc: 0.852 +vnc: 0.834 +files: 0.822 +boot: 0.807 +hypervisor: 0.800 +kernel: 0.777 +mistranslation: 0.768 +VMM: 0.765 +socket: 0.740 +network: 0.686 +x86: 0.633 +KVM: 0.593 +i386: 0.542 + +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/118/permissions/955379 b/results/classifier/118/permissions/955379 new file mode 100644 index 00000000..5138168e --- /dev/null +++ b/results/classifier/118/permissions/955379 @@ -0,0 +1,453 @@ +permissions: 0.921 +device: 0.918 +boot: 0.916 +register: 0.907 +kernel: 0.906 +peripherals: 0.904 +user-level: 0.903 +architecture: 0.894 +arm: 0.890 +performance: 0.881 +semantic: 0.879 +virtual: 0.879 +debug: 0.869 +VMM: 0.864 +PID: 0.862 +mistranslation: 0.852 +risc-v: 0.849 +vnc: 0.842 +ppc: 0.840 +assembly: 0.839 +files: 0.830 +socket: 0.829 +TCG: 0.826 +network: 0.826 +KVM: 0.808 +i386: 0.803 +hypervisor: 0.802 +graphic: 0.802 +x86: 0.603 + +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/118/permissions/99674399 b/results/classifier/118/permissions/99674399 new file mode 100644 index 00000000..334c4476 --- /dev/null +++ b/results/classifier/118/permissions/99674399 @@ -0,0 +1,173 @@ +permissions: 0.896 +device: 0.886 +debug: 0.857 +virtual: 0.848 +performance: 0.845 +mistranslation: 0.843 +assembly: 0.843 +user-level: 0.841 +register: 0.841 +architecture: 0.834 +arm: 0.829 +kernel: 0.824 +semantic: 0.822 +boot: 0.822 +PID: 0.812 +risc-v: 0.800 +graphic: 0.794 +files: 0.787 +socket: 0.747 +ppc: 0.731 +x86: 0.731 +VMM: 0.726 +network: 0.711 +peripherals: 0.705 +KVM: 0.698 +TCG: 0.686 +vnc: 0.673 +i386: 0.670 +hypervisor: 0.592 + +[BUG] qemu crashes on assertion in cpu_asidx_from_attrs when cpu is in smm mode + +Hi all! + +First, I see this issue: +https://gitlab.com/qemu-project/qemu/-/issues/1198 +. +where some kvm/hardware failure leads to guest crash, and finally to this +assertion: + + cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. + +But in the ticket the talk is about the guest crash and fixing the kernel, not +about the final QEMU assertion (which definitely show that something should be +fixed in QEMU code too). + + +We've faced same stack one time: + +(gdb) bt +#0 raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#3 __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 +#4 cpu_asidx_from_attrs at ../hw/core/cpu-sysemu.c:76 +#5 cpu_memory_rw_debug at ../softmmu/physmem.c:3529 +#6 x86_cpu_dump_state at ../target/i386/cpu-dump.c:560 +#7 kvm_cpu_exec at ../accel/kvm/kvm-all.c:3000 +#8 kvm_vcpu_thread_fn at ../accel/kvm/kvm-accel-ops.c:51 +#9 qemu_thread_start at ../util/qemu-thread-posix.c:505 +#10 start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 +#11 clone () from /lib/x86_64-linux-gnu/libc.so.6 + + +And what I see: + +static inline int x86_asidx_from_attrs(CPUState *cs, MemTxAttrs attrs) +{ + return !!attrs.secure; +} + +int cpu_asidx_from_attrs(CPUState *cpu, MemTxAttrs attrs) +{ + int ret = 0; + + if (cpu->cc->sysemu_ops->asidx_from_attrs) { + ret = cpu->cc->sysemu_ops->asidx_from_attrs(cpu, attrs); + assert(ret < cpu->num_ases && ret >= 0); <<<<<<<<<<<<<<<<< + } + return ret; +} + +(gdb) p cpu->num_ases +$3 = 1 + +(gdb) fr 5 +#5 0x00005578c8814ba3 in cpu_memory_rw_debug (cpu=c... +(gdb) p attrs +$6 = {unspecified = 0, secure = 1, user = 0, memory = 0, requester_id = 0, +byte_swap = 0, target_tlb_bit0 = 0, target_tlb_bit1 = 0, target_tlb_bit2 = 0} + +so .secure is 1, therefore ret is 1, in the same time num_ases is 1 too and +assertion fails. + + + +Where is .secure from? + +static inline MemTxAttrs cpu_get_mem_attrs(CPUX86State *env) +{ + return ((MemTxAttrs) { .secure = (env->hflags & HF_SMM_MASK) != 0 }); +} + +Ok, it means we in SMM mode. + + + +On the other hand, it seems that num_ases seems to be always 1 for x86: + +vsementsov@vsementsov-lin:~/work/src/qemu/yc-7.2$ git grep 'num_ases = ' +cpu.c: cpu->num_ases = 0; +softmmu/cpus.c: cpu->num_ases = 1; +target/arm/cpu.c: cs->num_ases = 3 + has_secure; +target/arm/cpu.c: cs->num_ases = 1 + has_secure; +target/i386/tcg/sysemu/tcg-cpu.c: cs->num_ases = 2; + + +So, something is wrong around cpu->num_ases and x86_asidx_from_attrs() which +may return more in SMM mode. + + +The stack starts in +//7 0x00005578c882f539 in kvm_cpu_exec (cpu=cpu@entry=0x5578ca2eb340) at +../accel/kvm/kvm-all.c:3000 + if (ret < 0) { + cpu_dump_state(cpu, stderr, CPU_DUMP_CODE); + vm_stop(RUN_STATE_INTERNAL_ERROR); + } + +So that was some kvm error, and we decided to call cpu_dump_state(). And it +crashes. cpu_dump_state() is also called from hmp_info_registers, so I can +reproduce the crash with a tiny patch to master (as only CPU_DUMP_CODE path +calls cpu_memory_rw_debug(), as it is in kvm_cpu_exec()): + +diff --git a/monitor/hmp-cmds-target.c b/monitor/hmp-cmds-target.c +index ff01cf9d8d..dcf0189048 100644 +--- a/monitor/hmp-cmds-target.c ++++ b/monitor/hmp-cmds-target.c +@@ -116,7 +116,7 @@ void hmp_info_registers(Monitor *mon, const QDict *qdict) + } + + monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index); +- cpu_dump_state(cs, NULL, CPU_DUMP_FPU); ++ cpu_dump_state(cs, NULL, CPU_DUMP_CODE); + } + } + + +Than run + +yes "info registers" | ./build/qemu-system-x86_64 -accel kvm -monitor stdio \ + -global driver=cfi.pflash01,property=secure,value=on \ + -blockdev "{'driver': 'file', 'filename': +'/usr/share/OVMF/OVMF_CODE_4M.secboot.fd', 'node-name': 'ovmf-code', 'read-only': +true}" \ + -blockdev "{'driver': 'file', 'filename': '/usr/share/OVMF/OVMF_VARS_4M.fd', +'node-name': 'ovmf-vars', 'read-only': true}" \ + -machine q35,smm=on,pflash0=ovmf-code,pflash1=ovmf-vars -m 2G -nodefaults + +And after some time (less than 20 seconds for me) it leads to + +qemu-system-x86_64: ../hw/core/cpu-sysemu.c:76: cpu_asidx_from_attrs: Assertion `ret < +cpu->num_ases && ret >= 0' failed. +Aborted (core dumped) + + +I've no idea how to correctly fix this bug, but I hope that my reproducer and +investigation will help a bit. + +-- +Best regards, +Vladimir + |