diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1591 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1591611 | 110 | ||||
| -rw-r--r-- | results/classifier/108/other/1591628 | 195 | ||||
| -rw-r--r-- | results/classifier/108/other/1591724 | 69 |
4 files changed, 390 insertions, 0 deletions
diff --git a/results/classifier/108/other/1591 b/results/classifier/108/other/1591 new file mode 100644 index 000000000..165db4db0 --- /dev/null +++ b/results/classifier/108/other/1591 @@ -0,0 +1,16 @@ +performance: 0.752 +device: 0.741 +network: 0.510 +graphic: 0.438 +semantic: 0.203 +other: 0.197 +PID: 0.191 +boot: 0.162 +files: 0.098 +vnc: 0.079 +permissions: 0.064 +debug: 0.044 +socket: 0.041 +KVM: 0.018 + +test-mmap (4096 byte pages) on arm fails on ppc64le host diff --git a/results/classifier/108/other/1591611 b/results/classifier/108/other/1591611 new file mode 100644 index 000000000..91789e590 --- /dev/null +++ b/results/classifier/108/other/1591611 @@ -0,0 +1,110 @@ +other: 0.922 +semantic: 0.913 +graphic: 0.905 +debug: 0.874 +vnc: 0.871 +permissions: 0.854 +KVM: 0.840 +performance: 0.837 +PID: 0.836 +device: 0.832 +socket: 0.788 +network: 0.779 +files: 0.770 +boot: 0.763 + +chroot using qemu-x86_64-static fails on ppc64el + +When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error. /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel. + +Sample output illustrating the problem, as well as bash builtins working: + +# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash +# ls +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +setup_frame: not implemented +setup_frame: not implemented +# echo TEST +TEST +# cat test +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +It is currently unknown if other host architectures (e.g. aarch64) are also affected. + +We don't have an implementation of the target-specific signal handling code for the x86-64 guest. Anything that cares about signals therefore won't work with this target. + +In general the x86-64 guest support for linux-user isn't very good; ARM or AArch64 guest should behave rather better. + + +Are there any plans to implement these signal handlers? + +I don't know of any plans to do so. They would not be difficult to implement (500 lines of code or so at most I guess), but on the other hand they've been unimplemented for some years. They fall into the category of "nobody who wants them has cared enough to write the code yet", I'm afraid. + + +Can you point me to the correct location in the codebase / any available resources on these handlers? I might be able to tackle this at a later date, but am not currently familiar with qemu's codebase. + +linux-user/signal.c has a collection of functions for creating a signal frame on the stack before taking a signal, and then reading the data out of it on return from a signal. The four entry points from the rest of QEMU are setup_frame(), setup_rt_frame(), do_sigreturn() and do_rt_sigreturn(). We have implementations for a lot of target architectures, but for TARGET_I386 we only have the case of TARGET_ABI_BITS==32 (ie i386), not the x86-64 case. + +What these functions have to do is architecture dependent and generally not documented -- you'll need to look in the corresponding Linux kernel source code to identify the structures and data layouts. + + +By the way there is probably a bug in what we're doing with fork/clone that's causing the initial assertion, as well as the missing signal handling problem. + + +Yes, I saw that -- implementing the signal handlers fixed the hang and a few other problems, but the assertion and subsequent SIGABORT/SIGSEGV are still present. Currently attempting to track down the fork() issues. + +If you've got working code for the signal handlers you can submit those as patches now if you like. (http://wiki.qemu.org/Contribute/SubmitAPatch has info on the formatting hoops.) We have a feature freeze for QEMU 2.7 coming up on the 28th June, so before then would be ideal. + +Judging by the assertion, something is going wrong with libc's attempt to set the child tidptr via the ctid argument to clone and the CLONE_CHILD_SETTID flag. + + +OK, the fundamental problem is that do_fork() uses put_user_u32() on child_tidptr, but child_tidptr appears to be a host pointer. Treating it as a host pointer (direct assignment) allows fork to proceed, but this seems a bit odd to say the least. + +Still investigating. + +On closer inspection maybe it's not that odd...the parent and child tid pointers are in abi, not target, space. I'm going to assume direct assignment is correct (using __put_user()) and proceed from there. + +No, put_user_u32() is correct and __put_user() would be wrong. child_tidptr is a value passed directly from the guest in a register, so it is a guest pointer, not a host pointer. + + +qemu can locate the guest page with that address but it has a flags field of all zero (no access, invalid). Any ideas? + +So after some further debugging effort it turns out while the page allocator is unaware of the mapping (looks like the x86_64 NPTL implementation never maps the thread ID memory?), g2h() does work on the address, and in this case they map to the same value. I'll probably submit a patch using g2h in case anyone else might have a better idea on how to handle this. + +Finally figured it out! + +It's the page size. qemu user mode does NOT support a host page that is greater than 4k on x86/x86_64 systems, despite some claims to the contrary on older documentation pages. + +I'll be updating the patch to print a clear warning on failure instead of allowing corrupt data and the resultant cryptic target messages. + +Patch series sent to mailing list here: +http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05334.html + +In particular, this patch handles the original signal handler problem: +http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05335.html + +I tried QEMU with these patches [qemu-x86_64 version 2.6.94 (v2.7.0-rc4-dirty)] but found the same errors as before: + +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `THREAD_GETMEM (self, tid) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +setup_frame: not implemented +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `THREAD_GETMEM (self, tid) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +So does this patch set form a complete solution or if some more fixes expected? + +Thanks, +Atul. + +This bug has been moved to "Fix committed" before v2.9.0 has been release ... so could we move this to "Fix released" now? Or is there still something left to do here? + +Nope, looks good here. As a note to other commenters, this won't work unless you are using a kernel compiled with the 4k page size -- default for PPC64 is 64k. + diff --git a/results/classifier/108/other/1591628 b/results/classifier/108/other/1591628 new file mode 100644 index 000000000..a68bef4e9 --- /dev/null +++ b/results/classifier/108/other/1591628 @@ -0,0 +1,195 @@ +KVM: 0.716 +permissions: 0.663 +performance: 0.624 +semantic: 0.618 +device: 0.614 +vnc: 0.606 +PID: 0.603 +other: 0.598 +network: 0.586 +debug: 0.564 +boot: 0.563 +graphic: 0.527 +socket: 0.517 +files: 0.494 + +2.6.0 hangs linux vm using vfio for pci passthrough of graphics card + +Not a duplicate of my old bug 1488363 + +qemu version 2.5.1 works fine +qemu version 2.6.0 fails + +seabios 1.9.2-1 + +using kernel 4.5.5 with grsecurity + +I built using the arch packaging tools, but commented out all the patch code, so it should be vanilla. + +The problem is just that I start a Linux vm using either my radeon R7 260x or radeon HD 6770, and with qemu 2.6.0, it looks normal until after the grub menu, and then the screen looks broken (with mostly black, and some pixely junk spread horizontally in a few places on the screen... first we thought maybe the monitor died). I'm not sure if it's before or only at the moment where the screen resolution changes (I could check that or record it on request). Also, the VM is not pingable and does not respond to "system_powerdown" on qemu monitor. + +However, the same setup works fine with windows 8. And it works fine without graphics cards passed through. A usb controller passed through works fine too. + + +And then I ran a bisect... + + 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 is the first bad commit + commit 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 + Author: Alex Williamson <email address hidden> + Date: Thu Mar 10 09:39:08 2016 -0700 + + vfio/pci: Convert all MemoryRegion to dynamic alloc and consistent functions + + Match common vfio code with setup, exit, and finalize functions for + BAR, quirk, and VGA management. VGA is also changed to dynamic + allocation to match the other MemoryRegions. + + Signed-off-by: Alex Williamson <email address hidden> + + :040000 040000 0acfd49b6ecae780b6f52a34080ecec6b3ec3672 e0cfdadede08f553463c0b23931eda81107f41b8 M hw + +then confirm it by reverting that commit + git checkout v2.6.0 + git revert 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 + git mergetool -t kdiff3 + "select all from C", save + not sure if this is the right way to do this...but it compiles and works (bug fixed) + git commit -m "revert 2d82f8a3cdb276bc3cb92d6f01bf8f66bf328d62 resolve conflicts" + +And that 2.6.0 build with that one patch reverted works fine. + +And here's the qemu command (missing \ at the end of the lines) + + +qemu-system-x86_64 + -enable-kvm + -M q35 + -m 3584 + -cpu host + -boot c + -smp 8,sockets=1,cores=8,threads=1 + -vga none + -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 + -device vfio-pci,host=05:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=/mnt/archive/software/vgarom/Sapphire.HD6770.1024/Sapphire.HD6770.1024.120105.rom + -device vfio-pci,host=00:13.0,bus=pcie.0 + -device vfio-pci,host=00:13.2,bus=pcie.0 + -usb + -device ahci,bus=pcie.0,id=ahci + -drive file=/dev/ssd/manjaro-a,id=disk1,format=raw,if=virtio,index=0,media=disk,discard=on + -drive file=/mnt/archive/software/manjaro/manjaro-net-0.8.12-openrc-x86_64.iso,id=isocd1,index=2,media=cdrom + -drive file=,id=isocd2,index=3,media=cdrom + -drive media=cdrom,id=cdrom,index=5,media=cdrom + -netdev type=tap,id=net0,ifname=tap-7a + -device virtio-net-pci,netdev=net0,mac=00:01:02:03:04:05 + -monitor stdio + -boot menu=on + -vnc :12 + + +I'm not able to reproduce. Testing with an HD8570 and the following commandline: + +/usr/local/bin/qemu-system-x86_64 -enable-kvm -M q35 -m 4G -cpu host -smp 8 -vga none -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 -device vfio-pci,host=2:00.0,bus=root.1,x-vga=on,addr=0.0 -usb -device ahci,bus=pcie.0,id=ahci -drive file=/mnt/ISOs/Fedora-Live-Cinnamon-x86_64-23-10.iso,id=iso,index=0,media=cdrom -net none -nographic -monitor stdio -boot menu=on -serial none -parallel none -device usb-host,hostbus=3,hostaddr=7 + +(where the passthrough usb device is composite mouse/kbd for a kvm) Same results with Fedora virt-preview provided qemu-kvm binary (qemu-system-x86-2.6.0-3.fc23.x86_64) + +Please try to reduce to the minimum commandline to reproduce, take a picture of the symptoms you're describing, and if possible get a dmesg log from the guest. + +(changed your command with a different iso, and without the usb-host, and with a pci passthrough of a usb controller, and with a vgarom for my gpu otherwise I find it hangs if I repeatedly reboot a VM) + +If I try with your command with an iso it works. If I replace the iso with the VM's disk, it fails (see photo). + +I'm not sure what is special about the VM. I tried a grsecurity kernel 4.1.6, and vanilla kernel 3.18.35, which both hang. And I tried single user mode. I figured maybe it's something in grub. So I cleared out my grub.cfg other than memtest86+ (grub.cfg attached)... and it still fails, but this time it's a black screen except for the manjaro logo in the bottom right (attached). + + + + + + + +Attached is a 4.7 MB xz image of a 20 MB disk image that triggers the problem. It contains a grub2 (2.02~beta2) bootloader, /boot with memtest86+, and no rootfs. + +If I load that as is, it hangs. + +If I comment out the "load_video" line, it works. (memtest doesn't run properly, but auto-reboots, but that's not the issue) + + + +Ran as: + +# /usr/local/bin/qemu-system-x86_64 -enable-kvm -M q35 -m 4G -cpu host -smp 8 \ + -vga none -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 \ + -device vfio-pci,host=02:00.0,bus=root.1,x-vga=on,addr=0.0,romfile=/root/HD8570.rom \ + -device ahci,bus=pcie.0,id=ahci \ + -drive file=/root/qemutest2.img,id=iso,index=0,media=disk,format=raw \ + -net none -nographic -monitor stdio -serial none -parallel none + +Works fine, memtest86+ works fine too. Are you on an AMD or Intel host? Can you try with a recent, stock (non-grsecurity) kernel? Can you reproduce without the assigned USB devices? + +It's an AMD FX(tm)-8150 with a GA-990FXA-UD5 board bios version F11. I also tested without the usb controllers, such as with your suggested commands. And again below. + +root@peter:~ # uname -a +Linux peter 4.6.2-1-MANJARO #1 SMP PREEMPT Wed Jun 8 11:00:08 UTC 2016 x86_64 GNU/Linux + +root@peter:~ # cat /proc/cmdline +BOOT_IMAGE=/boot/vmlinuz-4.6-x86_64 root=UUID=dc395127-6336-448f-a950-137c100420c9 rw pcie_acs_override=downstream apparmor=1 security=apparmor vfio-pci.pci-ids=00:13.0,00:13.2,00:14.2,00:16.0,00:16.2,01:00.1,04:00.0,04:00.1,05:00.0,05:00.1 + +the vfio-pci.pci-ids=... is for a mkinitcpio hook I wrote that binds vfio-pci early so X has no chance to touch the GPUs and risk hanging the system; it runs before the radeon driver is loaded; it does 3 steps: unbind on each listed, then vfio-pci bind which annoyingly takes non-unique device:vendor rather than pci address, then unbind anything not listed to solve the non-unique problem (relevant since the host also has the same GPU device:vendor id, and usb controllers) + +and you can ignore the apparmor stuff since this stock kernel has no apparmor support + +Testing with my full command or your command, with minimal changes (pci id, path to romfile, my disk is lvm rather than file) +... + instead of a black screen/manjaro logo, I get a screen more like the first photo with colored pixel mess. + And a new error (that plus the non-black screen are possibly because I waited longer rather than changing the test): + + root@peter:~/kvm # qemu-system-x86_64 -enable-kvm -M q35 -m 4G -cpu host -smp 8 \ + > -vga none -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 \ + > -device vfio-pci,host=05:00.0,bus=root.1,x-vga=on,addr=0.0,romfile=/mnt/archive/software/vgarom/Sapphire.HD6770.1024/Sapphire.HD6770.1024.120105.rom \ + > -device ahci,bus=pcie.0,id=ahci \ + > -drive file=/dev/data/qemutest2,id=iso,index=0,media=disk,format=raw \ + > -net none -nographic -monitor stdio -serial none -parallel none + QEMU 2.6.0 monitor - type 'help' for more information + (qemu) KVM internal error. Suberror: 1 + emulation failure + EAX=b0000000 EBX=00000000 ECX=000f80f2 EDX=7f729950 + ESI=005a3c00 EDI=7feb82e0 EBP=0007fe1c ESP=0007fe14 + EIP=0000cd12 EFL=00000017 [----APC] CPL=0 II=0 A20=1 SMM=0 HLT=0 + ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] + SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT + TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy + GDT= 00008280 00000027 + IDT= 00000000 00000000 + CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 + DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 + DR6=00000000ffff0ff0 DR7=0000000000000400 + EFER=0000000000000000 + Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +and here's without the acs thing + vfio: No available IOMMU models + vfio: failed to setup container for group 20 + + ummm I though this worked in the past and this acs thing was only needed for my onboard sound to pass through correctly. Not sure what to do. + + If you want me to try another setting for pcie_acs_override=downstream, feel free to suggest. + + + +FYI I tried my grsec kernel (which also has some =m changed to =y so maybe I only forgot a modprobe command before) without acs_override=downstream which works with the revert build, and hangs without. + +Please test the patch in the link below and send your email address (privately if preferred) so I can provide proper attributes for Reported-by. Thanks. + +https://paste.fedoraproject.org/381971/46638926/ + +It works. :) Thanks a bunch. + +I tested linux it originally crashed with, plus the memtest86+ (still auto rebooted though), and no sign of a problem. + +Fix has been included in QEMU v2.7.0: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d3fc4fdc6857e33346e + diff --git a/results/classifier/108/other/1591724 b/results/classifier/108/other/1591724 new file mode 100644 index 000000000..890b8b7e7 --- /dev/null +++ b/results/classifier/108/other/1591724 @@ -0,0 +1,69 @@ +permissions: 0.796 +other: 0.753 +graphic: 0.748 +device: 0.745 +boot: 0.739 +PID: 0.718 +files: 0.705 +socket: 0.690 +vnc: 0.666 +debug: 0.659 +network: 0.651 +semantic: 0.640 +performance: 0.638 +KVM: 0.462 + +Windows 7 installation DVD can't boot in qemu 2.6.0/OVMF + +With Qemu 2.5.50 (compiled from git some time ago) I can boot Windows 7 x64 installation DVD as follows: +~/code/qemu-v2/bin/slic-v2/native/x86_64-softmmu/qemu-system-x86_64 \ + -machine type=pc,accel=kvm \ + -enable-kvm \ + -cpu host \ + -m 2048 \ + -vga cirrus \ + -boot d \ + -drive if=pflash,file=/vms/ovmf_x64_firstrun.bin,format=raw \ + -cdrom /vms/win7_sp1.iso \ + -monitor stdio + +This bug suggests different vga options https://bugs.launchpad.net/qemu/+bug/1581936. Here's the behaviours I'm getting with 2.6.0: + +std - "Starting Windows" with wavering flag hangs indefinitely +cirrus - at "Starting Windows" wasps of light freeze before assembling into a flag +qxl - "Starting Windows" with wavering flag hangs indefinitely +virtio - "Starting Windows" with wavering flag hangs indefinitely + +supposed to be fixed by <http://git.qemu.org/?p=qemu.git;a=commit;h=94ef4f337fb614f18b765a8e0e878a4c23cdedcd>, please confirm + +Running on latest git code a93c1bdf0bd4689287094ddb2aae3dc907da3535, DVD loads installation screen on everything except cirrus (same symptom). I don't really need cirrus, but I can test patches if you want. + +The following combination: + +- OVMF without the SeaBIOS CSM ("pure EFI" in Gerd's RPMs) +- Cirrus video card +- Windows 7 installer in the guest + +has never been supported. The VBE Shim in OVMF works on stdvga and QXL only. This is documented; please refer to OvmfPkg/README, section "UEFI Windows 7 & Windows 2008 Server". + +According to your results, stuff works on latest QEMU, in all configurations that are expected to be functional. Gerd CC'd <email address hidden> on his patch referenced above, so I guess it will be part of 2.6.1, whenever it is released. I'm closing this with fix committed. Thanks. + +The same thing. Qemu 2.5 and no possibility to install Windows 7 on OVMF, no possibility to install Windows 7 with QXL video. This is something terrible. Several hours I'm trying to install it but only on BIOS and with Cirrus video. What Qemu version will be fixed? + +@Gannet I've built latest qemu from git just to get through installation, after that everything runs fine on 2.6.0. It's easy enough http://wiki.qemu.org/Hosts/Linux#Simple_build_and_test + +Fails on my machine, even with the HEAD of master as of today (5d3217340adcb6c4f0e4af5d2b865331eb2ff63d). + +Simplest configuration: + + cp $MY_BIOS $MY_BIOS_TMP; ./qemu-system-x86_64 \ + -drive if=pflash,format=raw,readonly,file=$MY_BIOS \ + -drive if=pflash,format=raw,file=$MY_BIOS_TMP \ + -enable-kvm \ + -m 3072 \ + -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ + -cdrom $MY_WINDOWS_CD + ; + +Hangs on "Starting Windows". + |