diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/166 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1660599 | 28 | ||||
| -rw-r--r-- | results/classifier/108/other/1660946 | 268 | ||||
| -rw-r--r-- | results/classifier/108/other/1661758 | 142 | ||||
| -rw-r--r-- | results/classifier/108/other/1661815 | 58 | ||||
| -rw-r--r-- | results/classifier/108/other/1662050 | 375 | ||||
| -rw-r--r-- | results/classifier/108/other/1662468 | 75 | ||||
| -rw-r--r-- | results/classifier/108/other/1662600 | 53 | ||||
| -rw-r--r-- | results/classifier/108/other/1663287 | 128 | ||||
| -rw-r--r-- | results/classifier/108/other/1664 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1665 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1665344 | 28 | ||||
| -rw-r--r-- | results/classifier/108/other/1665389 | 229 | ||||
| -rw-r--r-- | results/classifier/108/other/1666 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1667 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1667401 | 87 | ||||
| -rw-r--r-- | results/classifier/108/other/1668 | 60 | ||||
| -rw-r--r-- | results/classifier/108/other/1668041 | 104 | ||||
| -rw-r--r-- | results/classifier/108/other/1668360 | 22 | ||||
| -rw-r--r-- | results/classifier/108/other/1669 | 26 |
20 files changed, 1763 insertions, 0 deletions
diff --git a/results/classifier/108/other/166 b/results/classifier/108/other/166 new file mode 100644 index 000000000..0300754f6 --- /dev/null +++ b/results/classifier/108/other/166 @@ -0,0 +1,16 @@ +semantic: 0.899 +device: 0.600 +performance: 0.521 +graphic: 0.513 +other: 0.357 +network: 0.283 +debug: 0.085 +permissions: 0.078 +vnc: 0.068 +PID: 0.055 +KVM: 0.016 +boot: 0.013 +files: 0.009 +socket: 0.008 + +qemu-bridge-helper failure but qemu not exit diff --git a/results/classifier/108/other/1660599 b/results/classifier/108/other/1660599 new file mode 100644 index 000000000..596cb04f3 --- /dev/null +++ b/results/classifier/108/other/1660599 @@ -0,0 +1,28 @@ +graphic: 0.789 +device: 0.705 +semantic: 0.624 +other: 0.473 +network: 0.414 +performance: 0.374 +PID: 0.306 +vnc: 0.284 +socket: 0.272 +debug: 0.267 +boot: 0.194 +files: 0.167 +permissions: 0.164 +KVM: 0.019 + +v2.8.0 won't compile if g++ compiler doesn't understand "-fstack-protector-strong" + +For example, Ubuntu Trusty (LTS 14.04) uses g++ v4.8.5. +Compilation fails with a syntax error saying that the ""-fstack-protector-strong" option in g++ is unrecognized. +Instead, under Ubuntu Xenial (LTS 16.04), the g++ compiler is v5.4.0 and the compilation goes on smoothly. + +Could you provide the command you've used? +I tried `CC=gcc-4.8 ./configure --enable-stack-protector && make` in Ubuntu 14.04 and qemu v2.8.0. It didn't set `-fstack-protector-strong` flag, only `-fstack-protector-all`. + +Which version of gcc (i.e. normal C-compiler, not g++) did you use here? Can you still reproduce this issue with the latest release of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1660946 b/results/classifier/108/other/1660946 new file mode 100644 index 000000000..c51c7d48d --- /dev/null +++ b/results/classifier/108/other/1660946 @@ -0,0 +1,268 @@ +graphic: 0.801 +other: 0.777 +debug: 0.767 +device: 0.738 +permissions: 0.732 +semantic: 0.719 +PID: 0.714 +performance: 0.701 +files: 0.700 +vnc: 0.689 +boot: 0.671 +socket: 0.642 +network: 0.625 +KVM: 0.544 + +[nested] virt-install falls to SLOF + + +[nested] virt-install falls to SLOF: after starting installer (ISO/CDROM), it crashes w/ a kernel panic due to an HTM (Hardware Transactional Memory) exception. + +Scenario: +Host=Ubuntu 16.04 Xenial (Ubuntu KVM ppc64el POWER8E 8247-22L) +Guest=Ubuntu 16.04 Xenial (Ubuntu Xenial Cloud Image QCOW2) +Nested=Ubuntu 16.04 Xenial (Ubuntu Xenial Server ISO *or* NetInstall mini.iso) + +Inside Guest (1st level), run virt-install as shown below to reproduce the bug. + +Facts: + * ISO images (from both Server or netinstall mini.iso) fail to boot on xenial/yakkety + * Cloud image (xenial/yakkety/zesty) on nested virt boots fine, the login prompt is seen. + * Reproducible with Xenial and Yakkety + * NOT reproducible with Zesty (Installer menu starts just normally) + * virtio-scsi, virtio-net and virtio-blk modules are seen in zesty. Only virtio-scsi is seen on xenial/yakkety (-net and -blk are built-in modules?) + * kvm-pr is loaded for all tested scenarios + * This patch[1] rings a bell, however, it doesn't explain how cloud images boot just fine and don't hit the bug, since the kernel used in the cloud images also enable HTM[2]. + +[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-April/141292.html + +[2] grep TRANSA /boot/config-4.8.0-26-generic +CONFIG_PPC_TRANSACTIONAL_MEM=y + + +# cat virt-inst.sh +virt-install --virt-type=kvm --cpu=host --name=nested-xenial --controller type=scsi,model=virtio-scsi --graphics none --console pty,target_type=serial --disk path=/home/nested-xenial.qcow2,size=20 --vcpus=4 --ram=4096 --os-type=linux --os-variant ubuntu16.04 --network bridge=virbr0,model=virtio --cdrom=$1 + + +# ./virt-inst.sh ubuntu-16.04-server-ppc64el.iso +WARNING CDROM media does not print to the text console by default, so you likely will not see text install output. You might want to use --location. See the man page for examples of using --location with CDROM media + +Starting install... +Creating domain... | 0 B 00:00:00 +Connected to domain nested-xenial +Escape character is ^] +Populating /vdevice methods +Populating /vdevice/vty@30000000 +Populating /vdevice/nvram@71000000 +Populating /pci@800000020000000 + 00 2800 (D) : 1af4 1002 unknown-legacy-device* + 00 2000 (D) : 1af4 1001 virtio [ block ] + 00 1800 (D) : 106b 003f serial bus [ usb-ohci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" + 00 0800 (D) : 10ec 8139 network [ ethernet ] +No NVRAM common partition, re-initializing... +Scanning USB + OHCI: initializing +Using default console: /vdevice/vty@30000000 + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 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: /pci@800000020000000/scsi@2/disk@100000000000000 ... Successfully loaded + + GNU GRUB version 2.02~beta2-36ubuntu3 + + +----------------------------------------------------------------------------+ + |*Install | + | Rescue mode | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + +----------------------------------------------------------------------------+ + + Use the ^ and v keys to select which entry is highlighted. + Press enter to boot the selected OS, `e' to edit the commands + before booting or `c' for a command-line. + + +OF stdout device is: /vdevice/vty@30000000 +Preparing to boot Linux version 4.4.0-21-generic (buildd@bos01-ppc64el-017) (gcc version 5.3.1 20160413 (Ubuntu/IBM 5.3.1-14ubuntu2) ) #37-Ubuntu SMP Mon Apr 18 18:30:22 UTC 2016 (Ubuntu 4.4.0-21.37-generic 4.4.6) +Detected machine type: 0000000000000101 +Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) +Calling ibm,client-architecture-support... done +command line: BOOT_IMAGE=/install/vmlinux tasks=standard pkgsel/language-pack-patterns= pkgsel/install-language-support=false --- quiet +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 0000000004640000 + alloc_top : 0000000030000000 + alloc_top_hi : 0000000100000000 + rmo_top : 0000000030000000 + ram_top : 0000000100000000 +instantiating rtas at 0x000000002fff0000... done +prom_hold_cpus: skipped +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x0000000004650000 -> 0x0000000004650a5b +Device tree struct 0x0000000004660000 -> 0x0000000004670000 +Quiescing Open Firmware ... +Booting Linux via __start() ... + -> smp_release_cpus() +spinning_secondaries = 3 + <- smp_release_cpus() + <- setup_system() +Linux ppc64le +#37-Ubuntu SMP M[ 2.155665] Facility 'TM' unavailable, exception at 0x3fff9f3d8644, MSR=b00000014280f033 +[ 2.161582] Facility 'TM' unavailable, exception at 0x3fff8a488644, MSR=b00000014280f033 +[ 2.168973] Facility 'TM' unavailable, exception at 0x3fffb2df8644, MSR=b00000014280f033 +[ 2.174818] Facility 'TM' unavailable, exception at 0x3fff902f8644, MSR=b00000014280f033 +[ 2.180887] Facility 'TM' unavailable, exception at 0x3fff84728644, MSR=b00000014280f033 +[ 2.186023] Facility 'TM' unavailable, exception at 0x3fff8f1f8644, MSR=b00000014280f033 +[ 2.193073] Facility 'TM' unavailable, exception at 0x3fffa8ecfe30, MSR=b00000014280f033 +[ 2.193697] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 +[ 2.193697] +[ 2.193751] CPU: 3 PID: 1 Comm: init Not tainted 4.4.0-21-generic #37-Ubuntu +[ 2.193788] Call Trace: +[ 2.193826] [c0000000fea83a50] [c000000000aedc1c] dump_stack+0xb0/0xf0 (unreliable) +[ 2.193868] [c0000000fea83a90] [c000000000ae9e50] panic+0x100/0x2c0 +[ 2.193914] [c0000000fea83b20] [c0000000000bd474] do_exit+0xc24/0xc30 +[ 2.193945] [c0000000fea83be0] [c0000000000bd564] do_group_exit+0x64/0x100 +[ 2.193979] [c0000000fea83c20] [c0000000000ce9cc] get_signal+0x55c/0x7b0 +[ 2.194012] [c0000000fea83d10] [c000000000017424] do_signal+0x54/0x2b0 +[ 2.194043] [c0000000fea83e00] [c00000000001787c] do_notify_resume+0xbc/0xd0 +[ 2.194072] [c0000000fea83e30] [c000000000009838] ret_from_except_lite+0x64/0x68 + +Domain creation completed. +Restarting guest. +Connected to domain nested-xenial +Escape character is ^] +Populating /vdevice methods +Populating /vdevice/vty@30000000 +Populating /vdevice/nvram@71000000 +Populating /pci@800000020000000 + 00 2800 (D) : 1af4 1002 unknown-legacy-device* + 00 2000 (D) : 1af4 1001 virtio [ block ] + 00 1800 (D) : 106b 003f serial bus [ usb-ohci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" + 00 0800 (D) : 10ec 8139 network [ ethernet ] +No NVRAM common partition, re-initializing... +Scanning USB + OHCI: initializing +Using default console: /vdevice/vty@30000000 + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 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: /pci@800000020000000/scsi@4 ... +E3404: Not a bootable device! +Trying to load: from: HALT ... +E3405: No such device + +E3407: Load failed + + ..`. .. ....... .. ...... ....... + ..`...`''.`'. .''``````..''. .`''```''`. `''`````` + .`` .:' ': `''..... .''. ''` .''..''....... + ``.':.';. ``````''`.''. .''. ''``''`````'` + ``.':':` .....`''.`'`...... `'`.....`''.`'` + .`.`'`` .'`'`````. ``'''''' ``''`'''`. `'` + Type 'boot' and press return to continue booting the system. + Type 'reset-all' and press return to reboot the system. + + +Ready! +0 > + +Sounds like your problem only occurs on older versions of Ubuntu, so moving this to the QEMU-Ubuntu bug tracker. + +Hi, +I mostly run with cloud-images so I haven't seen this yet (I always prefer uvtool-libvirt to virt-install). + +Thank you already for your good summary! + + +After going the wrong direction for a while I see the almost hidden, yet so important words - "in nested only" ! +That also explains the kvm-pr I wondered about, as I'd have expected kvm-hv if in 1st level. + + +I tried as you instructed - on first stage it worked (Host to lvl 1) + +Command: +$virt-install --virt-type=kvm --cpu=host --name=nested-xenial --controller type=scsi,model=virtio-scsi --graphics none --console pty,target_type=serial --disk path=/home/ubuntu/cpaelzer/test-xenial-virt-inst.qcow2,size=20 --vcpus=4 --ram=4096 --os-type=linux --os-variant ubuntu16.04 --network bridge=virbr0,model=virtio --cdrom=ubuntu-16.04-server-ppc64el.iso + +On a Xenial system with: +ii libvirt-bin 1.3.1-1ubuntu10.6 +ii qemu-kvm 1:2.5+dfsg-5ubuntu10.6 +ii virtinst 1:1.3.2-3ubuntu1.16.04.3 + +And HW: +POWER8E - PowerNV 8247-22L + + + +Now the same in 2nd level: +1. install all packages for kvm +2. ensure kvm_pr is loaded correctly +3. make sure libvirt default network can start in 2nd level +3. wget http://cdimage.ubuntu.com/releases/xenial/release/ubuntu-16.04-server-ppc64el.iso +4. virt-install as above, yet shrinked down to fit (5G disk) + +With that I can confirm your issue. + +I'm not entirely sure if kvm_pr (or more defined "the TM feature inside kvm_pr") is meant to be fully supported by IBM owning power in general. + +Subscribing / pinging them for their expertise on this. + +kvm_pr is not "officially/fully/formally" supported for production use, but this mode is extensively used by OpenStack Continuous Integration and it is the testing ground for many other projects. This statement of "not supported" has been changing and Power ecosystem depends on kvm_pr for platform enablement efforts. + + +The fix you referred to also is not upstream yet - although it is unclear to me why. +The discussion somehow just stalled +https://patchwork.kernel.org/patch/8740001/ + +As mentioned I was reaching out to IBM and they likely take a look at that patch once more now. + +Yep, for some reason, the discussion stalled. +Thanks for working on this bug. HTM bits should be cleared on nested virt, anyway. +Also, HTM is causing other components to fail on nested virt like rtas_errd daemon, which does PCI Hotplug. + +FYI, the pa_features[24] setting has been fixed in upstream in a slightly different way: +http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=bac3bf287ab60e264b6 + +Christian, + +I checked with Breno and while nested virtualization is not something that they encourage use of in a production environment, it is used for testing purposes. They would like to have this working with Ubuntu and have stated it only requires a small fix to qemu. If possible, could you please look at pulling in the fix. + +Thanks. + + Michael + +Thanks Thomas for pointing out the upstream fix. +IBM has opened a bug that I dup this one on. + +There not only one but three patches are suggested. +It would be great if you could take a look there as the patches are all yours - see the dup bug 1664622 + diff --git a/results/classifier/108/other/1661758 b/results/classifier/108/other/1661758 new file mode 100644 index 000000000..89b17d6ec --- /dev/null +++ b/results/classifier/108/other/1661758 @@ -0,0 +1,142 @@ +performance: 0.889 +device: 0.871 +graphic: 0.853 +permissions: 0.832 +debug: 0.815 +PID: 0.786 +semantic: 0.775 +files: 0.769 +socket: 0.755 +network: 0.754 +vnc: 0.744 +boot: 0.728 +other: 0.725 +KVM: 0.717 + +qemu-nbd causes data corruption in VDI-format disk images + +Hi, + +This is a duplicate of #1422307. I can't figure out a way to re-open +it--the status of "Fix Released" is changeable only by a project +maintainer or bug supervisor--so I'm opening a new bug to make sure +this gets looked at again. + +qemu-nbd will sometimes corrupt VDI disk images. The bug was thought +to be fixed in commit f0ab6f109630940146cbaf47d0cd99993ddba824, but +I'm able to reproduce it in both that commit and in the latest commit +(a951316b8a5c3c63254f20a826afeed940dd4cba). I just needed to run more +iterations of the test. It's possible that it was partially fixed, or +that the added serialization made it harder to catch this +non-deterministic bug, but the same symptoms persist: data corruption +of VDI-format disk images. + +This affects at least qemu-nbd. I haven't tried reproducing the issue +with qemu proper or qemu-img, but the original bug report suggests +that the bug in the common VDI backend may corrupt data written by +those programs. + +Please let me know if I can provide any further information or help +with testing. Thank you very much for looking into this! + +Test procedure +************** + +The procedure used is the one given by Max Reitz (xanclic) in the +original bug report, comment 3 +(https://bugs.launchpad.net/qemu/+bug/1422307/comments/3), in the +section "VDI and NBD over /dev/nbd0", but with up to 1000 iterations +instead of 10: + + $ cd ~/qemu-origfix-f0ab6f1/bin + $ dd if=/dev/urandom of=blob.raw bs=1M count=64 + 64+0 records in + 64+0 records out + 67108864 bytes (67 MB) copied, 4.36475 s, 15.4 MB/s + $ sudo sh -c 'for i in $(seq 0 999); do ./qemu-img create -f vdi test.vdi 64M > /dev/null; ./qemu-nbd -c /dev/nbd0 test.vdi; sleep 1; ./qemu-img convert -n blob.raw /dev/nbd0; ./qemu-img convert /dev/nbd0 test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert /dev/nbd0 test2.raw; ./qemu-nbd -d /dev/nbd0 > /dev/null; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo "done"' +27a66c3a8ac2cf06f2c925968ea9e964 test1.raw +2da9bf169041a7c2bd144c4ab3a29aea test2.raw +64 failed +done + +I've run this process a handful of times, and I've seen it take as +little as 10 iterations and as many as 161 (taking 32 minutes in the +latter case). Please be patient. Putting the images on tmpfs will +probably help it go faster, and I have successfully reproduced the +issue on tmpfs in addition to ext4. + +Nothing different was needed to reproduce the issue in a directory +containing a build of the latest commit. It still takes somewhere +around 1-200 iterations to find, in my testing. + +Build procedure +*************** + + $ git clone git://git.qemu-project.org/qemu.git + [omitted] + $ git clone qemu qemu-origfix-f0ab6f1 + Cloning into 'qemu-origfix-f0ab6f1'... + done. + $ cd qemu-origfix-f0ab6f1 + $ git checkout f0ab6f109630940146cbaf47d0cd99993ddba824 + Note: checking out 'f0ab6f109630940146cbaf47d0cd99993ddba824'. + + You are in 'detached HEAD' state. You can look around, make experimental + changes and commit them, and you can discard any commits you make in this + state without impacting any branches by performing another checkout. + + If you want to create a new branch to retain commits you create, you may + do so (now or later) by using -b with the checkout command again. Example: + + git checkout -b new_branch_name + + HEAD is now at f0ab6f1... block/vdi: Add locking for parallel requests + $ mkdir bin + $ cd bin + $ script -c'time (../configure --enable-debug --target-list=x86_64-softmmu && make -j6; echo "result: $?")' + Script started, file is typescript + [omitted; the build typescript is attached separately] + LINK x86_64-softmmu/qemu-system-x86_64 + result: 0 + + real 1m5.733s + user 2m3.904s + sys 0m13.828s + Script done, file is typescript + +Nothing different was done when building the latest commit (besides +cloning to a different directory, and not running `git checkout`). + +Environment +*********** + + * Machine: x86_64 + + * Hypervisor: Xen 4.4 (Debian package xen-hypervisor-4.4-amd64, + version 4.4.1-9+deb8u8) + + * A Xen domU (guest) for building QEMU and reproducing the issue. + All testing was done within the virtual machine for convenience + and access to better hardware than what I have for my development + machine (I expected the build to take much longer than it really + does). + + - x86_64 architecture with six VCPUs and 1.2 GiB RAM allocated, + operating in HVM (fully virtualized) mode. + + - Distribution: Debian 8.7 Jessie amd64 + + - Kernel: Linux 3.16.0 x86_64 (Debian package + linux-image-3.16.0-4-amd64, version 3.16.39-1) + + - Compiler: GCC 4.9.2 (Debian package gcc-4.9, version 4.9.2-10) + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1661815 b/results/classifier/108/other/1661815 new file mode 100644 index 000000000..5668d1d14 --- /dev/null +++ b/results/classifier/108/other/1661815 @@ -0,0 +1,58 @@ +vnc: 0.749 +graphic: 0.734 +performance: 0.728 +device: 0.725 +other: 0.708 +network: 0.677 +permissions: 0.661 +debug: 0.656 +PID: 0.623 +files: 0.617 +socket: 0.557 +semantic: 0.542 +KVM: 0.451 +boot: 0.368 + +Stack address is returned from function translate_one + +The vulnerable version is qemu-2.8.0, and the vulnerable function is in "target-s390x/translate.c". + +The code snippet is as following. + +static ExitStatus translate_one(CPUS390XState *env, DisasContext *s) +{ + const DisasInsn *insn; + ExitStatus ret = NO_EXIT; + DisasFields f; + ... + s->fields = &f; + ... + s->pc = s->next_pc; + return ret; +} + +A stack address, i.e. the address of local variable "f" is returned from current function through the output parameter "s->fields" as a side effect. + +This issue is one kind of undefined behaviors, according the C Standard, 6.2.4 [ISO/IEC 9899:2011] (https://www.securecoding.cert.org/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations) + +This dangerous defect may lead to an exploitable vulnerability. +We suggest sanitizing "s->fields" as null before return. + +Note that this issue is reported by shqking and Zhenwei Zou together. + +The calling function never uses "->fields", so I do not see a real vulnerability here, is there? Did you use a code analyser for this, or how did you come across this issue? + +Thanks for your reply. + +Inspired by this issue in apache httpd (https://bz.apache.org/bugzilla/show_bug.cgi?id=59844#c0), +we customized a checker based on the Clang Static Analyzer to detect such undefined behavior. + +Yes. +After examining the code carefully, we didn't find any place where the "->fields" is accessed, either. However, we think this kind of defect seems like a 'time bomb' and we'd better fix it just to be on the safe side. + +I've finally posted a patch for this: +https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05204.html + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=344a7f656e8d211cdd6e + diff --git a/results/classifier/108/other/1662050 b/results/classifier/108/other/1662050 new file mode 100644 index 000000000..2c0079803 --- /dev/null +++ b/results/classifier/108/other/1662050 @@ -0,0 +1,375 @@ +permissions: 0.846 +socket: 0.841 +other: 0.830 +device: 0.806 +semantic: 0.800 +graphic: 0.800 +debug: 0.781 +PID: 0.777 +performance: 0.773 +KVM: 0.739 +files: 0.739 +boot: 0.693 +network: 0.645 +vnc: 0.587 + +qemu-img convert a overlay qcow2 image into a entire image + +I have a base image file "base.qcow2" and a delta qcow2 image file "delta.qcow2" whose backing file is "base.qcow2". + +Now I use qemu-img to convert "delta.qcow2" and will get a new image file "new.qcow2" which is complete and equivalent to combination of "base.qcow2" and "delta.qcow2". + +In fact, i just want to convert the delta qcow2 image file and get a new delta overlay qcow2 image file. So the "new.qcow2" is not what i want. I have to admit that this is not bug. Could you please take this as a new feature and enable qemu-img to convert images in-place? + +On 02/05/2017 09:19 PM, wayen wrote: +> +> I have a base image file "base.qcow2" and a delta qcow2 image file +> "delta.qcow2" whose backing file is "base.qcow2". +> +> Now I use qemu-img to convert "delta.qcow2" and will get a new image +> + file "new.qcow2" which is entire and equivalent to combination of +> "base.qcow2" and "delta.qcow2". +> +> In fact, i just want to convert the delta qcow2 image file and get a new +> delta overlay qcow2 image file. So the "new.qcow2" is not what i want. I +> have to admit that this is not bug. Could you please take this as a new +> feature and enable qemu-img to convert images in-place? + +This feature already exists. Use: + +qemu-img rebase -F $backing_fmt -b '' -f qcow2 delta.qcow2 + +and now delta.qcow2 will be a complete image. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +@Eric Blake, Thanks very much for your help. In your way, I have verified that this feature already exists. + +@Eric Blake. Sorry, I didn't make it clear. In fact, I don't want to get a complete image. I just want to convert qcow2 overlay and get a new qcow2 overlay. Maybe you think my intention is meaningless， but this is what I want. + +Can't you simply do a "cp delta.qcow2 new.qcow2" ? + +@Thomas Huth, when we use qemu-img to convert a image "A" and will get a new image "B" which is equivalent to "A" . But "B" may be a lot different from "A",such as file size. The file size of "B" is usually less than "A" and this is very valuable to me. So I can't simply do a "cp delta.qcow2 new.qcow2" ? + +I meant to copy B, not A ... but I likely just haven't really understood what you're really trying to do here, so never mind. + +@Thomas Huth, I just want to reduce the file size of qcow2 overlay image by this conversion. + +On 02/08/2017 02:16 AM, wayen wrote: +> @Thomas Huth, I just want to reduce the file size of qcow2 overlay image +> by this conversion. + +Are you merely trying to sparsify the file (punch holes on the portion +of the file that is not mapped to disk), so that the apparent file size +is unchanged, but the actual disk usage is minimized? That's probably +already possible (virt-sparsify from libguestfs seems to be able to do +it; look at what steps it uses). + +Or are you asking for a way to defragment the file, so that the apparent +size shrinks because all occupied clusters are now contiguous, so that +there are no longer any need for holes? The end result is the same +amount of disk usage, but right now, the only way to defragment is to +convert from one image to a copy; we don't support in-place +defragmentation yet. So far, no one has come up with a compelling +reason why it is needed, or a patch to implement it, but there's no +technical reason why it can't be done. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +@Eric Blake, I used virt-sparsify to sparsify the qcow2 overlay image. As you said, the actual disk usage is minimized and the apparent file size is unchanged.It is very valuable for me, because it means that my disk can hold more files. + +But we need to be careful when transfer the sparse qcow2 overlays. Because some tools do not support sparse file and will convert it into a common file,for example, scp. And I doubt what will happen when transfer sparse files between different file systems. + +So I want to use qemu-img to convert the sparse qcow2 overlay into common file. If this was feasible, the holes in the sparse overlay will be removed and the above problems will disappear. + +On Thu, Feb 09, 2017 at 02:05:54AM -0000, wayen wrote: +> @Eric Blake, I used virt-sparsify to sparsify the qcow2 overlay image. +> As you said, the actual disk usage is minimized and the apparent file +> size is unchanged.It is very valuable for me, because it means that my +> disk can hold more files. +> +> But we need to be careful when transfer the sparse qcow2 overlays. +> Because some tools do not support sparse file and will convert it into a +> common file,for example, scp. And I doubt what will happen when transfer +> sparse files between different file systems. +> +> So I want to use qemu-img to convert the sparse qcow2 overlay into +> common file. If this was feasible, the holes in the sparse overlay will +> be removed and the above problems will disappear. + +You can use the drive_mirror HMP command or drive-mirror QMP command on +a running QEMU instance to copy the data to a new file and switch to the +new file. + +I'm curious what exactly is being optimized by copying out a fresh qcow2 +image. + +Please post the output of: + + $ stat delta.qcow2 + $ qemu-img map delta.qcow2 + $ stat new.qcow2 + $ qemu-img map new.qcow2 + +This will allow us to see the size and data layout differences. + +Maybe a new command should be added to QEMU to do the optimization +in-place. This would avoid the disk space overhead associated with +drive-mirror, cp, qemu-img convert, etc. + +Stefan + + + + + + + + + + +On Tue, Feb 14, 2017 at 02:17:16AM -0000, wayen wrote: +> ** Attachment added: "qemu-img map new.qcow2 output" +> https://bugs.launchpad.net/qemu/+bug/1662050/+attachment/4818564/+files/qemu_img_map_new_qcow2.txt + +Thanks for posting the attachments. + +I ran a script to find unallocated clusters in the delta.qcow2 host +file. Most are actually qcow2 metadata (L1/L2 tables, refcount blocks). + +This output shows that any image file size reduction you are hoping to +achieve can only come from zero clusters. + +There are no holes in the files that would result in significant image +file size reduction if a new image were written out. + +Just wanted to share this info in case anyone else is thinking about how +to optimize qcow2 files. I still think rewriting images sequentially +can be useful - if internal snapshots were used and deleted then COW can +result in holes. + +Hole at 0 size 5.0 clusters +Hole at 393216 size 1.0 clusters +Hole at 589824 size 1.0 clusters +Hole at 1114112 size 1.0 clusters +Hole at 1310720 size 1.0 clusters +Hole at 1507328 size 1.0 clusters +Hole at 1703936 size 1.0 clusters +Hole at 2293760 size 1.0 clusters +Hole at 2621440 size 1.0 clusters +Hole at 3080192 size 1.0 clusters +Hole at 5111808 size 1.0 clusters +Hole at 6291456 size 1.0 clusters +Hole at 30408704 size 1.0 clusters +Hole at 47906816 size 1.0 clusters +Hole at 142671872 size 1.0 clusters +Hole at 219545600 size 1.0 clusters +Hole at 667090944 size 1.0 clusters +Hole at 853868544 size 1.0 clusters +Hole at 1562640384 size 1.0 clusters +Hole at 2147483648 size 1.0 clusters +Hole at 2617180160 size 1.0 clusters +Hole at 3411148800 size 1.0 clusters +Hole at 4107075584 size 1.0 clusters +Hole at 4294967296 size 1.0 clusters +Hole at 4452646912 size 1.0 clusters +Hole at 4792057856 size 1.0 clusters +Hole at 5494865920 size 1.0 clusters +Hole at 5645271040 size 1.0 clusters +Hole at 5702483968 size 1.0 clusters +Hole at 6187188224 size 1.0 clusters +Hole at 6442450944 size 1.0 clusters +Hole at 6862995456 size 1.0 clusters +Hole at 6987317248 size 1.0 clusters +Hole at 7567245312 size 1.0 clusters +Hole at 8135245824 size 1.0 clusters +Hole at 8590589952 size 1.0 clusters +Hole at 8613462016 size 1.0 clusters +Hole at 9055436800 size 1.0 clusters +Hole at 9703522304 size 1.0 clusters +Hole at 10279321600 size 1.0 clusters +Hole at 10737418240 size 3.0 clusters +Hole at 10844372992 size 1.0 clusters +Hole at 11167858688 size 1.0 clusters +Hole at 11209605120 size 1.0 clusters +Hole at 11209801728 size 1.0 clusters +Hole at 11730944000 size 1.0 clusters +Hole at 12183207936 size 1.0 clusters +Hole at 12705464320 size 1.0 clusters +Hole at 12884901888 size 1.0 clusters +Hole at 13444120576 size 1.0 clusters +Hole at 13910016000 size 1.0 clusters +Hole at 14182711296 size 1.0 clusters +Hole at 15025635328 size 1.0 clusters +Hole at 15032385536 size 1.0 clusters + +The following script draws the allocated clusters and holes in the image +file. I took your qemu-img map output, filtered out any lines with +base.qcow2, and sorted using sort -k3 -g to sort on the "Mapped to" +field. Then I ran ./qcow2-map-svg.py <filtered.txt >output.svg. + +#!/usr/bin/python3 +import sys +import io + +COLOR_ALLOCATED = '#ffaaaa' +COLOR_HOLE = '#999999' + +def svg_percentage(value, total): + return '{0}%'.format(100.0 * value / total) + +def svg_rect(x, width, color): + print('<rect x="{0}" y="0" width="{1}" height="40" fill="{2}" stroke="none" />'.format(x, width, color), file=out) + +def svg_text(x, y, text): + print('<text x="{0}" y="{1}">{2}</text>'.format(x, y, text), file=out) + +out = io.StringIO() + +print('''<?xml version="1.0" encoding="UTF-8" ?> +<svg xmlns="http://www.w3.org/2000/svg" version="1.1">''', file=out) + +file_map = [] +header = True +for line in sys.stdin: + if header: + header = False + continue + + offset, length, mapped, filename = line.split() + offset = int(offset, 16) + length = int(length, 16) + mapped = int(mapped, 16) + + file_map.append((offset, length, mapped, filename)) + +file_size = file_map[-1][2] + file_map[-1][1] +last_mapped = 0 +for _, length, mapped, _ in file_map: + if mapped > last_mapped: +# if mapped - last_mapped: +# print('Hole at {0} size {1} clusters'.format(last_mapped, (mapped - last_mapped) / 65536)) + svg_rect(svg_percentage(last_mapped, file_size), + svg_percentage(mapped - last_mapped, file_size), + COLOR_HOLE) + + svg_rect(svg_percentage(mapped, file_size), + svg_percentage(length, file_size), + COLOR_ALLOCATED) + last_mapped = mapped + length +if last_mapped < file_size: + svg_rect(svg_percentage(last_mapped, file_size), + svg_percentage(file_size - last_mapped, file_size), + COLOR_HOLE) + +for i in range(10): + svg_text(svg_percentage(i, 10), 60, svg_percentage(i, 10)) + +print('</svg>', file=out) + +print(out.getvalue()) + + +Is there any way to remove holes from qcow2 overlay images? It's very important to me. I am looking forward to your reply. + +Is there any way to remove holes from sparse qcow2 overlay? It's very important to me. I am looking forward to your reply. + +Hi wayen: + Which version are you used? + I also find this problem on old version qemu, and i write a patch +for it. It works. + I'm not sure the mainline version have solve this problem. + what command are you used? + +On Mon, Apr 10, 2017 at 10:14 AM, wayen <email address hidden> wrote: +> Is there any way to remove holes from qcow2 overlay images? It's very +> important to me. I am looking forward to your reply. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1662050 +> +> Title: +> qemu-img convert a overlay qcow2 image into a entire image +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> I have a base image file "base.qcow2" and a delta qcow2 image file +> "delta.qcow2" whose backing file is "base.qcow2". +> +> Now I use qemu-img to convert "delta.qcow2" and will get a new image +> file "new.qcow2" which is entire and equivalent to combination of +> "base.qcow2" and "delta.qcow2". +> +> In fact,I don't want to get a complete image.I just want to convert +> delta qcow2 image file "A" to a New delta overlay qcow2 image "B" +> which is equivalent to "A". So the "new.qcow2" is not what i want. I +> have to admit that this is not bug. Could you please take this as a +> new feature and enable qemu-img to convert qcow2 overlay itself? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1662050/+subscriptions +> + + +Hi Lidong Chen: + I used QEMU 2.0.0 on Ubuntu 14.04. + Do you mean your patch can make qemu-img convert qcow2 overlay into a new overlay? + + +On Mon, Apr 10, 2017 at 1:07 PM, wayen <email address hidden> wrote: +> Hi Lidong Chen: +> I used QEMU 2.0.0 on Ubuntu 14.04. +> Do you mean your patch can make qemu-img convert qcow2 overlay into a new overlay? + +yes. but i find it already fixed in 2.0.0. +do you add the -o backing_file= option in the command? + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1662050 +> +> Title: +> qemu-img convert a overlay qcow2 image into a entire image +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> I have a base image file "base.qcow2" and a delta qcow2 image file +> "delta.qcow2" whose backing file is "base.qcow2". +> +> Now I use qemu-img to convert "delta.qcow2" and will get a new image +> file "new.qcow2" which is entire and equivalent to combination of +> "base.qcow2" and "delta.qcow2". +> +> In fact,I don't want to get a complete image.I just want to convert +> delta qcow2 image file "A" to a New delta overlay qcow2 image "B" +> which is equivalent to "A". So the "new.qcow2" is not what i want. I +> have to admit that this is not bug. Could you please take this as a +> new feature and enable qemu-img to convert qcow2 overlay itself? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1662050/+subscriptions +> + + +Hi Lidong Chen: + + I forgot to use this option.I think the way you said is effective.I will try it.Thank you very much for your help + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1662468 b/results/classifier/108/other/1662468 new file mode 100644 index 000000000..39b849995 --- /dev/null +++ b/results/classifier/108/other/1662468 @@ -0,0 +1,75 @@ +semantic: 0.725 +graphic: 0.641 +performance: 0.603 +device: 0.476 +socket: 0.400 +other: 0.348 +network: 0.320 +PID: 0.320 +debug: 0.320 +vnc: 0.284 +files: 0.276 +permissions: 0.236 +boot: 0.192 +KVM: 0.188 + +[feature request] qemu-img convert should respond to control-T like dd + +Since qemu-img convert is a long-running operation, it would be nice if it reported progress in response to control-T (SIGINFO) to show progress information, much like dd, fsck, dump, cp, etc. + +That should be simple enough to implement considering we have this behavior already on SIGUSR1. Unfortunately, I wouldn't be able to test it because Linux apparently doesn't implement SIGINFO... + +Max + + +PS: By the way, thanks for the information. I didn't know about SIGINFO at all. Well, now I have mapped Ctrl-T to SIGUSR1 in my terminal emulator so I don't have to feel quite as inferior... + +On 02/08/17 00:22, Max Reitz wrote: +> That should be simple enough to implement considering we have this +> behavior already on SIGUSR1. Unfortunately, I wouldn't be able to test +> it because Linux apparently doesn't implement SIGINFO... +> +> Max +> +> +> PS: By the way, thanks for the information. I didn't know about SIGINFO at all. Well, now I have mapped Ctrl-T to SIGUSR1 in my terminal emulator so I don't have to feel quite as inferior... +> + +By that you may have lost the following Readline action: + + transpose-chars (C-t) + Drag the character before point forward over the charac- + ter at point, moving point forward as well. If point is + at the end of the line, then this transposes the two + characters before point. Negative arguments have no + effect. + +I'm sure you've been using that all the time... ;) + +Laszlo + + +On Tue, Feb 07, 2017 at 11:22:26PM -0000, Max Reitz wrote: +> That should be simple enough to implement considering we have this +> behavior already on SIGUSR1. Unfortunately, I wouldn't be able to test +> it because Linux apparently doesn't implement SIGINFO... +> +> Max +> +> +> PS: By the way, thanks for the information. I didn't know about SIGINFO at all. Well, now I have mapped Ctrl-T to SIGUSR1 in my terminal emulator so I don't have to feel quite as inferior... + +Christophe: In case you hadn't seen what Max is referring to on the +qemu-img man page: + + -p display progress bar (compare, convert and rebase commands + only). If the -p option is not used for a command that supports + it, the progress is reported when the process receives a + "SIGUSR1" signal. + +Does this do what you want? + + +Fix has been included in v2.10.0: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=262fbae692722d5c8b + diff --git a/results/classifier/108/other/1662600 b/results/classifier/108/other/1662600 new file mode 100644 index 000000000..c25e681bf --- /dev/null +++ b/results/classifier/108/other/1662600 @@ -0,0 +1,53 @@ +graphic: 0.788 +other: 0.755 +performance: 0.688 +semantic: 0.687 +network: 0.684 +device: 0.682 +files: 0.659 +PID: 0.631 +permissions: 0.627 +socket: 0.601 +vnc: 0.596 +debug: 0.542 +KVM: 0.432 +boot: 0.417 + +error while building from source on Ubuntu 16.04 + +I'm trying to build Qemu from source (from git) as specified here: http://www.qemu-project.org/download/#source + +Here is the git commit hash for the source: 7d2c6c95511e42dffe2b263275e09957723d0ff4 + +During the 'make' step, I get the following error: + +migration/rdma.c: In function ‘qemu_rdma_dump_id’: +migration/rdma.c:749:21: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:750:22: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:750:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) +migration/rdma.c:750:37: note: each undeclared identifier is reported only once for each function it appears in +migration/rdma.c:751:24: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:751:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) +migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’: +migration/rdma.c:850:26: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:850:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) +migration/rdma.c:852:33: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +migration/rdma.c:852:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) +migration/rdma.c:891:18: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ +make: *** [migration/rdma.o] Error 1 + +I searched around a bit, my problem seems related to this: https://patchwork.kernel.org/patch/992952/ + +That issue makes me think my libibverbs may be out of date, but I checked and I have libibverbs-dev installed. Is that the correct version? + +FYI, I installed libibverbs-dev as suggested here: http://wiki.qemu-project.org/index.php/Hosts/Linux#Recommended_additional_packages + +Since libibverbs was optional, I uninstalled it. After doing so, my build seems to have progressed past this error. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1663287 b/results/classifier/108/other/1663287 new file mode 100644 index 000000000..7a2231f53 --- /dev/null +++ b/results/classifier/108/other/1663287 @@ -0,0 +1,128 @@ +KVM: 0.809 +other: 0.796 +vnc: 0.790 +device: 0.782 +permissions: 0.780 +boot: 0.768 +debug: 0.733 +performance: 0.728 +semantic: 0.709 +graphic: 0.686 +PID: 0.675 +network: 0.647 +socket: 0.624 +files: 0.601 + +Illegal delay slot code causes abort on mips64 + +During some randomised testing of an experimental MIPS implementation I found an instruction sequence that also causes aborts on mainline qemu's MIPS support. The problem is triggered by an MSA branch instruction appearing in a delay slot when emulating a processor without MSA support. + +For example, with the current repository HEAD (f073cd3a2bf1054135271b837c58a7da650dd84b) configured for mips64-softmmu, if I run the attached binary using + + mips64-softmmu/qemu-system-mips64 -bios ../abort2.bin -machine mipssim -nographic + +it will report + + unknown branch 0x13000 + Aborted (core dumped) + +The binary contains the following two instructions: + + 00200008 jr at + 47081e61 bz.b w8,0xffffffffbfc0798c + +The jr sets up a jump, and hflags is set accordingly in gen_compute_branch (in target/mips/translate.c). When processing the bz.b, check_insn generates an exception because the instruction isn't support, but gen_msa_branch skips the usual delay slot check for the same reason, and sets more bits in hflags, leading to an abort in gen_branch because the hflags are now invalid. + +I suspect the best fix is to remove the instruction set condition from the delay slot check in gen_msa_branch. + + + +I've just found the same problem with gen_compute_branch1, + +00200008 jr at +4540563a bc1any4f $fcc0,0xffffffffbfc158ec + +The cause is the same - if the instruction set is wrong then the delay slot check is skipped. + +Thanks for reporting this issue. +In fact, branches in a delay slot is "undefined" in the pre-Release 6 architecture. +MIPS architectre release 6 defines to signal Reserved Instruction exceptions for such cases. +However as it was undefined, it is better to signal RI and carry on rather than stopping simulation. +Hence I've made a patch for the msa case. +I will have a look into the other case. (sorry I've missed in the first place.) + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=075a1fe788d36b271ec2 + +Thanks for that fix. I've just noticed that the second part, in gen_compute_branch1, wasn't included, though. Could you take a look at it? + +I found the exact same bug. Tested on several hosts and qemu releases. The newest one I tested was on FreeBSD 12.1 host and qemu-4.1.1_1 built from ports. + +Instructions: + 4000d0: 0320f809 jalr t9 + 4000d4: 45454545 0x45454545 # bc1any4t $fcc1,0x800101f8 + +I was running qemu-mips as: + +qemu-system-mipsel -s -m 1024 -M malta \ + -kernel vmlinux-3.16.0-6-4kc-malta -initrd initrd.img-3.16.0-6-4kc-malta \ + -device virtio-blk-pci,drive=hd0 -drive if=none,id=hd0,format=qcow2,file=debian_wheezy_mipsel_standard.qcow2 \ + -append "root=/dev/vda1" \ + -device virtio-net-pci,netdev=net0 \ + -netdev user,id=net0,hostfwd=tcp::1666-:22,ipv6=off \ + -curses + +abort() was in target/mips/translate.c:12945, in gen_branch(). + +Doesn't really matter if the instruction is supported on given CPU, user can crash the qemu within guest. + +Hi Brian, + +You try to execute a CP1 instruction in a delay slot, +which triggers a Reserved Instruction exception. +Per the ISA the processor operation is UNPREDICTABLE in such case. + +What is the behavior on real hardware? +An assertion() seems appropriate. + +Your compiler might be buggy, or you are not compiling for the correct CPU +(or you are not using the correct QEMU cpu). + +I don't know how Brian go to his state. + +I should've mentioned though I was using custom binary (shellcode) that triggered this behavior. This code was not generated by compiler. + +However, I wanted to point out that user can crash the qemu host by running custom code from userspace. + +Unfortunately I can't test this behavior on real HW right now. + +Yeah, QEMU crashing is definitely a bug that we should fix. (NB that it's not a 'security' bug, though -- we make no guarantee that malicious code run under QEMU with TCG emulation is unable to escape from it: there's too much unaudited and old code for us to be able to safely make that guarantee.) + + +When I reread the thread I see Brian was doing some testing/fuzzing, that's why he found that out. + +I managed to get my old router running. It's BCM5354 (BCM3302 v2.9) running on Linux 2.4.35. +I used the following code (gnu as compiled but replaced the nop after branch with the branch instruction above): + + 4000d0: 10000003 b 4000e0 <__start+0x10> + 4000d4: 45454545 0x45454545 + ... + 4000e0: 2404002a li a0,42 + 4000e4: 24020fa1 li v0,4001 + 4000e8: 0000000c syscall + 4000ec: 00000000 nop + +Program was terminated with the trap Illegal instruction. + + +If my memory is correct, this problem doesn't need qemu to execute the code, it only needs it to translate the code. In the original test case the invalid instructions were actually dead code but still managed to crash qemu. + +I suggest following Yongbok Kim's approach and signalling Reserved Instruction in the same way R6 does. I think that's architecturally allowed, although I admit that it's ages since I looked at this. + + +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/63 + + diff --git a/results/classifier/108/other/1664 b/results/classifier/108/other/1664 new file mode 100644 index 000000000..ead4c631e --- /dev/null +++ b/results/classifier/108/other/1664 @@ -0,0 +1,16 @@ +device: 0.730 +debug: 0.555 +network: 0.518 +performance: 0.412 +graphic: 0.382 +semantic: 0.373 +PID: 0.361 +files: 0.350 +boot: 0.262 +vnc: 0.212 +other: 0.200 +permissions: 0.164 +socket: 0.155 +KVM: 0.011 + +mingw64 cross compile: libslirp from subproject fails to link, undefined reference to WinMain diff --git a/results/classifier/108/other/1665 b/results/classifier/108/other/1665 new file mode 100644 index 000000000..3c92ee20f --- /dev/null +++ b/results/classifier/108/other/1665 @@ -0,0 +1,16 @@ +device: 0.807 +KVM: 0.714 +performance: 0.479 +network: 0.407 +files: 0.350 +permissions: 0.321 +PID: 0.318 +graphic: 0.316 +semantic: 0.282 +other: 0.191 +boot: 0.185 +debug: 0.135 +vnc: 0.063 +socket: 0.044 + +When using the"yum install qemu-kvm" command in in rhel 9 , it is not possible to proceed past the "Windows Installer Select Disk" page by iso install diff --git a/results/classifier/108/other/1665344 b/results/classifier/108/other/1665344 new file mode 100644 index 000000000..90aeb3610 --- /dev/null +++ b/results/classifier/108/other/1665344 @@ -0,0 +1,28 @@ +device: 0.905 +graphic: 0.892 +network: 0.803 +socket: 0.771 +files: 0.768 +vnc: 0.741 +semantic: 0.661 +boot: 0.626 +performance: 0.557 +permissions: 0.537 +other: 0.467 +PID: 0.444 +KVM: 0.402 +debug: 0.363 + +documentation error:404 not found + +In http://wiki.qemu-project.org/Outreachy_2017_MayAugust the urls + http://www.qemu-project.org/images/4/4e/Q35.pdf and http://www.qemu-project.org/images/f/f6/PCIvsPCIe.pdf on opening displays: + + + + Not Found + +The requested URL /images/4/4e/Q35.pdf was not found on this server. + +Thanks for letting us know. The links have been updated on the wiki page. + diff --git a/results/classifier/108/other/1665389 b/results/classifier/108/other/1665389 new file mode 100644 index 000000000..9ff28b5da --- /dev/null +++ b/results/classifier/108/other/1665389 @@ -0,0 +1,229 @@ +other: 0.886 +debug: 0.876 +permissions: 0.862 +performance: 0.854 +semantic: 0.842 +vnc: 0.841 +device: 0.838 +graphic: 0.829 +files: 0.828 +KVM: 0.826 +socket: 0.809 +boot: 0.804 +PID: 0.801 +network: 0.800 + +Nested kvm guest fails to start on a emulated Westmere CPU guest under a Broadwell CPU host + +Using latest master(5dae13), qemu fails to start any nested guest in a Westmere emulated guest(layer 1), under a Broadwell host(layer 0), with the error: + +qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +The qemu command used(though other CPUs didn't work either): +/usr/bin/qemu-custom -name guest=12ed9230-vm-el73,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-12ed9230-vm-el73/master-key.aes -machine pc-i440fx-2.9,accel=kvm,usb=off -cpu Westmere,+vmx -m 512 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid f4ce4eba-985f-42a3-94c4-6e4a8a530347 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-12ed9230-vm-el73/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/root/lago/.lago/default/images/vm-el73_root.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,serial=1,discard=unmap -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:c0:a7:c8:02,bus=pci.0,addr=0x2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-12ed9230-vm-el73/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x9 -msg timestamp=on +2017-02-16T15:14:45.840412Z qemu-custom: -chardev pty,id=charserial0: char device redirected to /dev/pts/2 (label charserial0) +qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + + +The CPU flags in the Westmere guest: +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc rep_good nopl pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm arat tpr_shadow vnmi flexpriority ept vpid + +The guest kernel is 3.10.0-514.2.2.el7.x86_64. + +The CPU flags of the host(Broadwell): +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 aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp + +qemu command on the host - Broadwell(which works): +/usr/bin/qemu-kvm -name 4ffcd448-vm-el73,debug-threads=on -S -machine pc-i440fx-2.6,accel=kvm,usb=off -cpu Westmere,+x2apic,+vmx,+vme -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid 8cc0a2cf-d25a-4014-acdb-f159c376a532 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-4ffcd448-vm-el73/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/home/ngoldin/src/nvgoldin.github.com/lago-init-files/.lago/flags-tests/default/images/vm-el73_root.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,serial=1,discard=unmap -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/ngoldin/src/nvgoldin.github.com/lago-init-files/.lago/flags-tests/default/images/vm-el73_additonal.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,serial=2,discard=unmap -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 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:c0:a8:c9:02,bus=pci.0,addr=0x2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-4-4ffcd448-vm-el73/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x9 -msg timestamp=on + +On the Broadwell host I'm using a distribution package if it matters(qemu-kvm-2.6.2-5.fc24.x86_64 and 4.8.15-200.fc24.x86_64) + +As the error indicates, I think this assertion was put in: +commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +Author: Paolo Bonzini <email address hidden> +Date: Wed Mar 30 22:55:29 2016 +0200 + + target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs + + This would have caught the bug in the previous patch. + + Signed-off-by: Paolo Bonzini <email address hidden> + +I tried going back one commit before to 273c515, and then the error is gone and the nested guest comes up as expected. If I try to run with head at the above commit(48e145c) the error output is slightly different, though it looks the same: +/root/qemu/target-i386/kvm.c:1713: kvm_put_msrs: Assertion `ret == n' failed. + +Hi Nadav, + Can you clarify what the host and L1 kernels are please? + +This error means that qemu tried to write some msrs but one of the msr writes failed; we need to figure out which one to understand what's going on. + +1) Edit kvm_msr_entry_add in target/i386/kvm.c to something like: + + assert((void *)(entry + 1) <= limit); + fprintf(stderr,"kvm_msr_entry_add: @%d index=%x value=%lx\n", msrs->nmsrs, index, value); + entry->index = index; + +2) edit kvm_put_msrs near the bottom: + + fprintf(stderr,"kvm_put_msrs: ret=%d expected=%d\n", ret, cpu->kvm_msr_buf->nmsrs); + assert(ret == cpu->kvm_msr_buf->nmsrs); + +Now with any luck the 'ret' value will tell you the entry which is bad, and you can match +that to the @%d value (or maybe it's the entry before that one which failed?) then we get the index, look it up in the intel docs and figure out which MSR it's complaining about. + +Also, does the problem go away if you remove the +x2apic on the top level qemu? + +Dave + +Hi Dave, thanks for looking into this. + +> Can you clarify what the host and L1 kernels are please? + +Host - 4.8.15-200.fc24.x86_64 +Guest - 3.10.0-514.2.2.el7.x86_64 + +Results of adding the debug messages and running a simpler command(with master again - 5dae13): + +[root@vm-el73 ~]# /usr/bin/qemu-custom -s -machine pc,accel=kvm,usb=off -cpu Westmere +kvm_msr_entry_add: @0 index=174 value=0 +kvm_msr_entry_add: @1 index=175 value=0 +kvm_msr_entry_add: @2 index=176 value=0 +kvm_msr_entry_add: @3 index=277 value=7040600070406 +kvm_msr_entry_add: @4 index=c0000081 value=0 +kvm_msr_entry_add: @5 index=c0010117 value=0 +kvm_msr_entry_add: @6 index=3b value=0 +kvm_msr_entry_add: @7 index=1a0 value=1 +kvm_msr_entry_add: @8 index=9e value=30000 +kvm_msr_entry_add: @9 index=d90 value=0 +kvm_msr_entry_add: @10 index=c0000083 value=0 +kvm_msr_entry_add: @11 index=c0000102 value=0 +kvm_msr_entry_add: @12 index=c0000084 value=0 +kvm_msr_entry_add: @13 index=c0000082 value=0 +kvm_msr_entry_add: @14 index=10 value=0 +kvm_msr_entry_add: @15 index=12 value=0 +kvm_msr_entry_add: @16 index=11 value=0 +kvm_msr_entry_add: @17 index=4b564d02 value=0 +kvm_msr_entry_add: @18 index=4b564d04 value=0 +kvm_msr_entry_add: @19 index=4b564d03 value=0 +kvm_msr_entry_add: @20 index=2ff value=0 +kvm_msr_entry_add: @21 index=250 value=0 +kvm_msr_entry_add: @22 index=258 value=0 +kvm_msr_entry_add: @23 index=259 value=0 +kvm_msr_entry_add: @24 index=268 value=0 +kvm_msr_entry_add: @25 index=269 value=0 +kvm_msr_entry_add: @26 index=26a value=0 +kvm_msr_entry_add: @27 index=26b value=0 +kvm_msr_entry_add: @28 index=26c value=0 +kvm_msr_entry_add: @29 index=26d value=0 +kvm_msr_entry_add: @30 index=26e value=0 +kvm_msr_entry_add: @31 index=26f value=0 +kvm_msr_entry_add: @32 index=200 value=0 +kvm_msr_entry_add: @33 index=201 value=0 +kvm_msr_entry_add: @34 index=202 value=0 +kvm_msr_entry_add: @35 index=203 value=0 +kvm_msr_entry_add: @36 index=204 value=0 +kvm_msr_entry_add: @37 index=205 value=0 +kvm_msr_entry_add: @38 index=206 value=0 +kvm_msr_entry_add: @39 index=207 value=0 +kvm_msr_entry_add: @40 index=208 value=0 +kvm_msr_entry_add: @41 index=209 value=0 +kvm_msr_entry_add: @42 index=20a value=0 +kvm_msr_entry_add: @43 index=20b value=0 +kvm_msr_entry_add: @44 index=20c value=0 +kvm_msr_entry_add: @45 index=20d value=0 +kvm_msr_entry_add: @46 index=20e value=0 +kvm_msr_entry_add: @47 index=20f value=0 +kvm_msr_entry_add: @48 index=17a value=0 +kvm_msr_entry_add: @49 index=17b value=ffffffffffffffff +kvm_msr_entry_add: @50 index=400 value=ffffffffffffffff +kvm_msr_entry_add: @51 index=401 value=0 +kvm_msr_entry_add: @52 index=402 value=0 +kvm_msr_entry_add: @53 index=403 value=0 +kvm_msr_entry_add: @54 index=404 value=ffffffffffffffff +kvm_msr_entry_add: @55 index=405 value=0 +kvm_msr_entry_add: @56 index=406 value=0 +kvm_msr_entry_add: @57 index=407 value=0 +kvm_msr_entry_add: @58 index=408 value=ffffffffffffffff +kvm_msr_entry_add: @59 index=409 value=0 +kvm_msr_entry_add: @60 index=40a value=0 +kvm_msr_entry_add: @61 index=40b value=0 +kvm_msr_entry_add: @62 index=40c value=ffffffffffffffff +kvm_msr_entry_add: @63 index=40d value=0 +kvm_msr_entry_add: @64 index=40e value=0 +kvm_msr_entry_add: @65 index=40f value=0 +kvm_msr_entry_add: @66 index=410 value=ffffffffffffffff +kvm_msr_entry_add: @67 index=411 value=0 +kvm_msr_entry_add: @68 index=412 value=0 +kvm_msr_entry_add: @69 index=413 value=0 +kvm_msr_entry_add: @70 index=414 value=ffffffffffffffff +kvm_msr_entry_add: @71 index=415 value=0 +kvm_msr_entry_add: @72 index=416 value=0 +kvm_msr_entry_add: @73 index=417 value=0 +kvm_msr_entry_add: @74 index=418 value=ffffffffffffffff +kvm_msr_entry_add: @75 index=419 value=0 +kvm_msr_entry_add: @76 index=41a value=0 +kvm_msr_entry_add: @77 index=41b value=0 +kvm_msr_entry_add: @78 index=41c value=ffffffffffffffff +kvm_msr_entry_add: @79 index=41d value=0 +kvm_msr_entry_add: @80 index=41e value=0 +kvm_msr_entry_add: @81 index=41f value=0 +kvm_msr_entry_add: @82 index=420 value=ffffffffffffffff +kvm_msr_entry_add: @83 index=421 value=0 +kvm_msr_entry_add: @84 index=422 value=0 +kvm_msr_entry_add: @85 index=423 value=0 +kvm_msr_entry_add: @86 index=424 value=ffffffffffffffff +kvm_msr_entry_add: @87 index=425 value=0 +kvm_msr_entry_add: @88 index=426 value=0 +kvm_msr_entry_add: @89 index=427 value=0 +kvm_put_msrs: ret=9 expected=90 +qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +Aborted + +> Also, does the problem go away if you remove the +x2apic on the top level qemu? + +Don't think so, I actually added it because I thought it would solve something. I can re-try with out it if needed(with the debug messages). + + + + + + kvm_msr_entry_add: @8 index=9e value=30000 + kvm_msr_entry_add: @9 index=d90 value=0 + kvm_msr_entry_add: @10 index=c0000083 value=0 + + kvm_put_msrs: ret=9 expected=90 + +OK, 9... so that's probably the d90; + $ ag d90: + 418:#define MSR_IA32_BNDCFGS 0x00000d90 + +The Intel book says 'IA32_BNDCFGS Supervisor State of MPX Configuration' which I think is pretty new, so I don't know what it's doing trying to do it on a Westmere; ccing in Eduardo and Paolo. + + + > Also, does the problem go away if you remove the +x2apic on the top level qemu? + + Don't think so, I actually added it because I thought it would solve something + I can re-try with out it if needed(with the debug messages). + +Worth a go, but if it's that MPX stuff I doubt it. + +Dave + +Nested is currently supported only with -cpu host. Kernel 4.9 has the necessary support but QEMU doesn't. + +> Nested is currently supported only with -cpu host. Kernel 4.9 has the necessary support but QEMU doesn't. + +1. Just to be sure, you mean '-cpu host' in the bare metal host right? +2. Until it is officially supported in qemu, is there any easy way to work around this? as this setup seemed to have work in earlier versions(prior to v2.6.0 I think). + +Yes, I mean '-cpu host' in the bare metal. There is no workaround; it worked by chance and it triggered other hard to find bugs. + +> Yes, I mean '-cpu host' in the bare metal. There is no workaround; it worked by chance and it triggered other hard to find bugs. + +alright, thanks for clarifying that. + + +Can you still reproduce this issue with the latest version of QEMU (v4.2)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1666 b/results/classifier/108/other/1666 new file mode 100644 index 000000000..95dbcc9ef --- /dev/null +++ b/results/classifier/108/other/1666 @@ -0,0 +1,16 @@ +other: 0.710 +semantic: 0.559 +PID: 0.345 +vnc: 0.258 +KVM: 0.245 +device: 0.200 +graphic: 0.200 +permissions: 0.164 +boot: 0.148 +socket: 0.086 +network: 0.063 +performance: 0.039 +files: 0.029 +debug: 0.013 + +About the develop environment diff --git a/results/classifier/108/other/1667 b/results/classifier/108/other/1667 new file mode 100644 index 000000000..c6a588dac --- /dev/null +++ b/results/classifier/108/other/1667 @@ -0,0 +1,16 @@ +graphic: 0.798 +device: 0.638 +semantic: 0.417 +performance: 0.394 +permissions: 0.372 +vnc: 0.228 +debug: 0.181 +network: 0.172 +other: 0.123 +boot: 0.117 +socket: 0.061 +PID: 0.060 +KVM: 0.047 +files: 0.039 + +Tricore: missing a few TC1.6.2 instruction set diff --git a/results/classifier/108/other/1667401 b/results/classifier/108/other/1667401 new file mode 100644 index 000000000..7d003fccb --- /dev/null +++ b/results/classifier/108/other/1667401 @@ -0,0 +1,87 @@ +other: 0.738 +debug: 0.724 +graphic: 0.717 +semantic: 0.710 +KVM: 0.705 +permissions: 0.701 +performance: 0.698 +device: 0.694 +PID: 0.689 +vnc: 0.673 +files: 0.661 +socket: 0.641 +boot: 0.627 +network: 0.587 + +qemu-ppc segfaults(SIGSEGV) on pthread_create + +qemu-ppc running on x86-64 hardware leads to a segfault when running the +attached program (test.c). It simply creates a pthread, joins it and exits. + +It was compiled as follows on a Debian testing system: +> powerpc-linux-gnuspe-gcc-6 -static -Wall -g -o test -pthread test.c + +Sample execution (expected output is "Hello - World!"): +> qemu-ppc -cpu e500 ./test +[...output...] +Hello - qemu-ppc: /build/qemu-_M2UL5/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-ppc: /build/qemu-_M2UL5/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +[1] 25747 segmentation fault qemu-ppc -cpu e500 test +[...end output...] + +The same behavior is observed when running on a PPC 604: + +> powerpc-linux-gnu-gcc -Wall -g -o test -pthread test.c +> qemu-ppc ./test +[... as above ...] + +Version information: +powerpc-linux-gnu-gcc -v => gcc version 6.3.0 20170124 (Debian 6.3.0-5) +qemu-ppc -version => qemu-ppc version 2.8.0(Debian 1:2.8+dfsg-2) + +The same experiment was conducted again using qemu from the git repository (commit: 796b288f7be875045670f963ce99991b3c8e96ac): +~/tools/qemu/build/ppc-linux-user/qemu-ppc -version => qemu-ppc version 2.8.50 (v2.8.0-1417-g796b288f7b-dirty) +[...output...] +Hello - qemu-ppc: [...redacted...]/tools/qemu/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-ppc: [...redacted...]/tools/qemu/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +[1] 25996 segmentation fault ~/tools/qemu/build/ppc-linux-user/qemu-ppc -cpu e500 test +[...end output...] + + +Executing with -strace option yields a surprising entry (see second clone() syscall below): +[...] +26007 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0xf67fde60,parent_tidptr=0xf67fe368,tls=0xf68057d0,child_tidptr=0xf67fe368) = 26009 +26007 clone(0,child_stack=0xf67fde60,parent_tidptr=0xf67fe368,tls=0xf68057d0,child_tidptr=0xf67fe368) = -1 errno=22 (Invalid argument) + + +test.c works just fine if the pthread_create & pthread_join calls are removed +(i.e. when compiled with -DNO_PTHREAD_CREATE). + +At first glance, the issue seems specific to PPC because compiling and running +for x86_64 using qemu-x86_64 works fine. + + +Additional info: +> lddtree =qemu-ppc +qemu-ppc => /usr/bin/qemu-ppc (interpreter => /lib64/ld-linux-x86-64.so.2) + libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 + libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 + ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 + libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 + libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 + librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 + libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 + libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 + libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 + libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 + +> /lib/x86_64-linux-gnu/libc.so.6 +GNU C Library (Debian GLIBC 2.24-9) stable release version 2.24, by Roland McGrath et al. + +> uname -a +Linux [...redacted...] 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux + + + +Fixed by commit 2635531f2006bfb0f943ad25b41e176709b79b37 (available in 2.9.0rc0) + diff --git a/results/classifier/108/other/1668 b/results/classifier/108/other/1668 new file mode 100644 index 000000000..840f8b26e --- /dev/null +++ b/results/classifier/108/other/1668 @@ -0,0 +1,60 @@ +files: 0.900 +device: 0.850 +graphic: 0.825 +PID: 0.815 +vnc: 0.704 +network: 0.667 +socket: 0.655 +performance: 0.647 +semantic: 0.646 +debug: 0.610 +permissions: 0.607 +boot: 0.513 +other: 0.441 +KVM: 0.241 + +Fedora 38 build of clang 16 fails when run under s390x emulation (both system & linux-user) +Description of problem: +Spawn a Fedora 38 container using `s390x` linux-user based emulation + +``` +$ podman run -it --platform linux/s390x fedora:latest +``` + +Install clang inside it + +``` +sh-5.2# dnf -y install clang +``` + +Try to run clang + +``` +sh-5.2# clang --version +clang version 16.0.4 (Fedora 16.0.4-1.fc38) +Target: s390x-redhat-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +sh-5.2# clang --help +clang-16: error: unsupported option '--help'; did you mean '--help'? +clang-16: error: no input files +``` + +Notice the nonsense error message when requesting `--help`. With Fedora 37 build of clang 15 (compiled with gcc 12), under s390x emulation, `--help` will correctly print the help. In fact all options except for `--version` appear to be broken: + +``` +sh-5.2# echo "void foo(void) {}" > foo.c +sh-5.2# clang -c foo.c +clang-16: error: unknown argument: '-c' +``` + + +IOW, there appears to be something in the clang 16 (compiled with gcc 13) in Fedora 38 that is tripping up s390x emulation. + +It is unclear whether the trigger was from building clang 16 with a newer gcc 13, or whether something changed from clang 15 -> 16. + +Originally reported with qemu-user-static-7.2.1-1.fc38.x86_64, but I've reproduced with QEMU upstream 7.1.0 release and QEMU upstream git master (v8.0.0-394-gc2b7158455) + +This was originally reported in Fedora at + + https://bugzilla.redhat.com/show_bug.cgi?id=2209635 diff --git a/results/classifier/108/other/1668041 b/results/classifier/108/other/1668041 new file mode 100644 index 000000000..0eb8ec02f --- /dev/null +++ b/results/classifier/108/other/1668041 @@ -0,0 +1,104 @@ +PID: 0.848 +device: 0.847 +other: 0.844 +permissions: 0.823 +network: 0.812 +graphic: 0.802 +debug: 0.801 +semantic: 0.777 +performance: 0.765 +files: 0.749 +boot: 0.712 +KVM: 0.675 +vnc: 0.620 +socket: 0.544 + +x86 Floating point exceptions - incorrect support? + +It seems that qemu does not correctly emulate the x86 support for optionally causing a floating-point exception (#FP) when, for example, dividing by zero. Reports such as: + +https://github.com/cloudius-systems/osv/issues/855 +http://stackoverflow.com/questions/15134189/qemu-div-by-zero-mxcsr-register + +suggest that setting the exception mask in the fpu cw or mxcsr (e.g., using a function like feenableexcept() in the guest OS) does not generate floating point exceptions on divide by zero. The problem only happens on pure QEMU - when a QEMU/KVM combination is used, the actual hardware does the floating point work, and does throw the exception on divide by zero if so requested. + +Looking at the qemu (2.8.0) source code, it seems to me it really lacks support for generating fpu exceptions: For example, helper_fdiv() in target-i386/fpu_helper.c, when it notices the divisor is zero, seems to set the divide-by-zero exception bit, but doesn't seem to check whether it needs to trigger an exception (when the right bits on the x87 or SSE control words are enabled). + +Hi, + +This problem still exists on QEMU 5.0.0 both for i386 and x86_64; +floating-point zero division is not trapped at all, while integer +one is trapped correctly. + +This seriously affects NetBSD project, which carries out periodic +regression tests on QEMU: + +https://releng.netbsd.org/test-results.html + +Tests including floating-point zero division are falling on QEMU, +while they are successfully passing on real hardwares. + +HOW TO REPEAT: + +Compile and run this program on Unix like operating systems: + +--- +#include <fenv.h> +#include <stdlib.h> +#include <unistd.h> + +int +main(void) +{ + volatile double a = getpid(); + volatile double b = atoi("0"); + + feenableexcept(FE_ALL_EXCEPT); + + usleep((int)(a / b)); + + return 0; +} +--- + +It crashes by SIGFPE on real hardware, but normally exits on QEMU. + +I ran this program on NetBSD 9.0 for x86_64 and i386 on QEMU 5.0.0: + +(1) Obtain NetBSD 9.0 release from here: + +For x86_64: +http://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-amd64.iso + +For i386: +http://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-i386.iso + +(2) Install it for disk image. + +(3) qemu-system-x86_64 NetBSD.qcow2 or qemu-system-i386 NetBSD.qcow2 + +(4) Compile and run the test program above: + +# cc fpe.c -lm -o fpe +# ./fpe + +(5) Then, it exits normally, while it should abort due to SIGFPE. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +Bug still present as of commit 7fbd7e710323c8f4c (just before 5.2 release); tested with a Linux guest in system emulation and with Linux usermode. + +The underlying problem is that we don't properly implement trapping FP exceptions; see the final paragraph in the commit message for commit 418b0f93d12a1589d50. + + + +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/215 + + diff --git a/results/classifier/108/other/1668360 b/results/classifier/108/other/1668360 new file mode 100644 index 000000000..ff5c580b5 --- /dev/null +++ b/results/classifier/108/other/1668360 @@ -0,0 +1,22 @@ +graphic: 0.786 +device: 0.768 +KVM: 0.718 +semantic: 0.677 +network: 0.568 +files: 0.555 +vnc: 0.544 +other: 0.485 +socket: 0.465 +PID: 0.321 +boot: 0.314 +permissions: 0.202 +debug: 0.190 +performance: 0.170 + +Documentation error :404 not found + +In http://wiki.qemu-project.org/Documentation/GettingStartedDevelopers the url http://www.linux-kvm.org/wiki/images/1/17/2010-forum-qmp-status-talk.pp.pdf displays a 404 NOt found error. + +Thanks for the report; the right URL is https://www.linux-kvm.org/images/1/17/2010-forum-qmp-status-talk.pp.pdf and I have updated the wiki page. + + diff --git a/results/classifier/108/other/1669 b/results/classifier/108/other/1669 new file mode 100644 index 000000000..cfe57ca97 --- /dev/null +++ b/results/classifier/108/other/1669 @@ -0,0 +1,26 @@ +device: 0.835 +vnc: 0.818 +debug: 0.633 +graphic: 0.550 +PID: 0.525 +boot: 0.523 +semantic: 0.517 +socket: 0.497 +permissions: 0.479 +other: 0.410 +network: 0.311 +files: 0.299 +KVM: 0.289 +performance: 0.231 + +In the ARM environment, using pci-ohci with specific OS (CentOS-8-aarch64-1905-dvd1.iso) to start a virtual machine, will cause the memory leak +Description of problem: + +Steps to reproduce: +1.Using the pci-ohci as the USB controller to start the VM; + +2.install the OS using the CentOS-8-aarch64-1905-dvd1.iso ; + +3.The QEMU process is taking up more and more memory, which looks like Memory leak +Additional information: + |