diff options
Diffstat (limited to 'results/classifier/zero-shot/118/user-level-x86')
8 files changed, 1024 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/user-level-x86/1219234 b/results/classifier/zero-shot/118/user-level-x86/1219234 new file mode 100644 index 000000000..39d35abce --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-x86/1219234 @@ -0,0 +1,83 @@ +x86: 0.907 +device: 0.855 +user-level: 0.841 +semantic: 0.828 +debug: 0.809 +files: 0.728 +graphic: 0.727 +performance: 0.699 +PID: 0.660 +mistranslation: 0.637 +ppc: 0.614 +assembly: 0.606 +architecture: 0.585 +socket: 0.555 +peripherals: 0.532 +permissions: 0.522 +register: 0.497 +kernel: 0.489 +boot: 0.482 +hypervisor: 0.477 +i386: 0.472 +arm: 0.438 +virtual: 0.419 +network: 0.419 +risc-v: 0.415 +vnc: 0.399 +VMM: 0.207 +TCG: 0.149 +KVM: 0.102 +-------------------- +x86: 0.936 +device: 0.493 +virtual: 0.194 +TCG: 0.104 +debug: 0.099 +files: 0.092 +hypervisor: 0.047 +user-level: 0.035 +PID: 0.033 +register: 0.020 +peripherals: 0.013 +architecture: 0.013 +semantic: 0.012 +boot: 0.007 +socket: 0.006 +kernel: 0.005 +VMM: 0.005 +assembly: 0.005 +performance: 0.005 +ppc: 0.004 +network: 0.004 +vnc: 0.003 +risc-v: 0.003 +permissions: 0.002 +graphic: 0.002 +KVM: 0.001 +mistranslation: 0.001 +i386: 0.001 +arm: 0.001 + +-device ide-hd will assign bus with with no free units + +Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1000118 + +./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device ide-hd,drive=aa -device ide-hd,drive=bb +qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus supports only 1 units +qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed. +qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be initialized + +If a bus isn't specified for -device ide-hd, it just uses the first bus it finds, not taking into account if that bus was already assigned for another device. So users are forced to do -device ide-hd,bus=ide.0 -device ide-hd,bus=ide.1, etc. + +This isn't specific to -device ahci, but it's worse there since there isn't any -drive if=IDE or -hda convenience option, which both seem to get the logic correct. + +I know -device is the 'build it yourself' approach so I understand if this is WONTFIX. + +Is somebody still planning to fix this, or should this be closed as WONTFIX? + +I'll re-investigate. I definitely fixed some of this (there is if=IDE for AHCI now), but I recall Markus mentioning recently that there are a lot of weird things quite broken with AHCI and bus assignment. + +I'm working on several other IDE fixes for the next release, so we can add this one to the pile. I will leave it as "incomplete" for now since I need to re-assess. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/118/user-level-x86/1755912 b/results/classifier/zero-shot/118/user-level-x86/1755912 new file mode 100644 index 000000000..09125ba72 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-x86/1755912 @@ -0,0 +1,393 @@ +user-level: 0.894 +x86: 0.864 +virtual: 0.858 +hypervisor: 0.853 +architecture: 0.842 +device: 0.839 +files: 0.837 +network: 0.836 +permissions: 0.836 +KVM: 0.827 +graphic: 0.826 +boot: 0.825 +mistranslation: 0.822 +register: 0.820 +PID: 0.811 +ppc: 0.804 +socket: 0.801 +performance: 0.801 +TCG: 0.775 +risc-v: 0.774 +peripherals: 0.772 +arm: 0.770 +assembly: 0.761 +debug: 0.755 +vnc: 0.754 +kernel: 0.743 +semantic: 0.708 +VMM: 0.660 +i386: 0.521 +-------------------- +user-level: 0.869 +x86: 0.769 +hypervisor: 0.738 +debug: 0.612 +virtual: 0.431 +PID: 0.358 +risc-v: 0.066 +TCG: 0.044 +semantic: 0.044 +register: 0.039 +kernel: 0.020 +files: 0.019 +performance: 0.015 +ppc: 0.011 +KVM: 0.011 +socket: 0.009 +device: 0.007 +graphic: 0.005 +network: 0.005 +assembly: 0.004 +boot: 0.004 +architecture: 0.003 +permissions: 0.002 +VMM: 0.002 +peripherals: 0.002 +vnc: 0.002 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl + +When using qemu-system-x86_64 with the option -vga qxl, it crashes. The easiest way to crash it is by trying to change the guest's resolution. However, the system may randomly crash too, not happening only when changing resolution. Here is the terminal output of one of these random crashes: + +-------- + +$ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device virtio-net-pci,id=net0,netdev=hostnet0 +WARNING: Image format was not specified for '/dev/sdb' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +(process:21313): Spice-WARNING **: 16:01:45.759: display-channel.c:2431:display_channel_validate_surface: canvas address is 0x7f8eb948ab18 for 0 (and is NULL) + + +(process:21313): Spice-WARNING **: 16:01:45.759: display-channel.c:2432:display_channel_validate_surface: failed on 0 + +(process:21313): Spice-CRITICAL **: 16:01:45.759: display-channel.c:2035:display_channel_update: condition `display_channel_validate_surface(display, surface_id)' failed +Abortado (imagem do núcleo gravada) + +-------- + +I was running QEMU as a normal user which is on the groups kvm and disk. Initially I supposed the problem was because I was running QEMU as root, but as a normal user this happens too. + +I have tested with guests with different Ubuntu version: 18.04, 17.10 and 16.04. It is happening with them all. + +ProblemType: Crash +DistroRelease: Ubuntu 18.04 +Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4 +ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 +Uname: Linux 4.15.0-10-generic x86_64 +ApportVersion: 2.20.8-0ubuntu10 +Architecture: amd64 +CurrentDesktop: XFCE +Date: Wed Mar 14 17:13:52 2018 +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2017-06-13 (273 days ago) +InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) +KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND +MachineType: LENOVO 80UG +ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm -cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device virtio-net-pci,id=net0,netdev=hostnet0 +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet +Signal: 6 +SourcePackage: qemu +StacktraceTop: + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +Title: qemu-system-x86_64 crashed with SIGABRT +UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago) +UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev plugdev sambashare sudo +dmi.bios.date: 07/10/2017 +dmi.bios.vendor: LENOVO +dmi.bios.version: 0XCN43WW +dmi.board.asset.tag: NO Asset Tag +dmi.board.name: Toronto 4A2 +dmi.board.vendor: LENOVO +dmi.board.version: SDK0J40679 WIN +dmi.chassis.asset.tag: NO Asset Tag +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Lenovo ideapad 310-14ISK +dmi.modalias: dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK: +dmi.product.family: IDEAPAD +dmi.product.name: 80UG +dmi.product.version: Lenovo ideapad 310-14ISK +dmi.sys.vendor: LENOVO + + + +StacktraceTop: + spice_logv (log_domain=0x7fb001524195 "Spice", args=0x7fafbf9fe600, format=0x7fb001525015 "condition `%s' failed", function=0x7fb001527ef0 <__func__.47520> "display_channel_update", strloc=0x7fb001527c0f "display-channel.c:2035", log_level=G_LOG_LEVEL_CRITICAL) at log.c:183 + spice_log (log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x7fb001527c0f "display-channel.c:2035", function=function@entry=0x7fb001527ef0 <__func__.47520> "display_channel_update", format=format@entry=0x7fb001525015 "condition `%s' failed") at log.c:196 + display_channel_update (display=0x56421590aa30, surface_id=0, area=area@entry=0x56421590ee1c, clear_dirty=1, qxl_dirty_rects=qxl_dirty_rects@entry=0x7fafbf9fe770, num_dirty_rects=num_dirty_rects@entry=0x7fafbf9fe76c) at display-channel.c:2035 + handle_dev_update_async (opaque=0x56421590ebe0, payload=0x56421590ee10) at red-worker.c:428 + dispatcher_handle_single_read (dispatcher=0x56421590e080) at dispatcher.c:284 + + + + + + + + +Subscribed Christian Ehrhardt, who might have an idea. + +Hmm, +I have no good idea unfortunately. +I tried it a few times (18.04 desktop guest 8 resolution changes) - showed no issue for me. +Is this depending on the type of guests that you run? + +I drive ti through libvirt, which adds quite some variables in the new format. +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 +You might experiment if some of them set would mitigate your issue. + +Looking at the warnings - they are from display_channel_validate_surface but they are "safe" which means they check, detect it is null and then skips. +But maybe later on something else crashes on the same canvas being Null maybe? + +Are the warnings like: +Spice-WARNING **: 16:01:45.759: display-channel.c:2431:display_channel_validate_surface: canvas address is 0x7f8eb948ab18 for 0 (and is NULL) +appearing right before the crash or when you start? + +The crash itself seems to be: +display_channel_update -> display_channel_validate_surface (which emits the warnings) -> spice_warning -> spice_log -> spice_logv +This crashes if >= a certain log level - the warning above triggers it. +So the question is why is the canvas Null? + +2429 if (!display->priv->surfaces[surface_id].context.canvas) { +2430 spice_warning("canvas address is %p for %d (and is NULL)\n", +2431 &(display->priv->surfaces[surface_id].context.canvas), surface_id); +2432 spice_warning("failed on %d", surface_id); +2433 return FALSE; +2434 } + +handle_dev_update_async gets that value indirectly via + RedWorker *worker = opaque; + ... + display_channel_update(worker->display_channel, +So the update that kills the pointer might be anywhere in between in this async paths. +I'm not a subject matter expert on this async UI updating :-/ + +If this really affects all releases way back including the latest we should try to build you the latest from source and if it affects this as well open the bug against upstream as well. As there we need a fix/discussion first then. +Can you compile qemu from source for yourself for this check or do you need help with that. + +I was able to build it from source. In the first try I was unable to test because it hadn't the spice protocol enabled. + +The interface QEMU is using is different, as it has a menu bar with "Machine" and "View" with some options, but I could test and I could reproduce the crash. To clarify, I have recorded the VMs crashing. + +Please note I have the notebook screen and a external monitor, so the resolution is a bit strange. + +With the command: ./qemu-system-x86_64 -hda ~/Downloads/xubuntu-bionic-desktop-amd64-2018-04-22.iso -m 1536 -vga qxl -enable-kvm -cpu host -smp cpus=2 + +https://mega.nz/#!98ZiHY5b!ZOaNjb1OaZVj0V80GRjkqafOAL2UinVlAEiTP9aazdk + +With the command: ./qemu-system-x86_64 -hda ~/Downloads/xubuntu-bionic-desktop-amd64-2018-04-22.iso -m 1536 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x3 -enable-kvm -cpu host -smp cpus=2 + +https://mega.nz/#!lwRDRA7I!no-6S6cWxmRf8Q8cjSWfN269PM9DISjLmN7QM6LYBC4 + +The examples are with Live ISOs, Using -cdrom (the most correct option) instead of -hda still have the same crashes. I can reproduce with a installed VM and with a physical system started in QEMU. + +Additional effects I've seen are the guests freezing instead of crashing and a significant RAM memory peak when starting the VM using libvirt. If high amounts of memory are being used in the moment the VM is started, approximately 128 MB of memory goes to SWAP that is never freed. The only way to freed it is to umount the SWAP partition (I tested until SWAP had 658 MB of memory). + +What I meant is that with a Bionic host, the guests crash regardless of what the guest is. For now I've tested only with Ubuntu and its derivatives, from 12.04 to 18.04 and they consistently have the issue. I'm downloading CentOS but the download is slow, so it will take some time. I will add the CentOS guest test results after I test it. + +The download of CentOS 7 was finished and I downloaded Fedora Workstation 27 later. With both as guests the VM still crash, so it's not a issue exclusive to Ubuntu guests. + +The crash may happen after 8 resolution changes (CentOS) or in the first one (Fedora 27) or if the system is running and suddenly crashes (Xubuntu 17.10 in a external HDD). + +Thanks Leonardo, with that confirmed: +- not dependent on the guest distribution +- affecting latest upstream +- good logs on the crash + +The videos are not needed but nice to proove your case (just as my pre-analysis of the code path is nice but likely not useful to a developer that regularly works on that code sections). + +Overall this should really be ready for upstreams attention, I added a Qemu task which will auto mirror this to the Mailing list. + +The bug traces so far had no private information, so I opened up the state to be visible to everyone. + +QEMU from git apparently is fixed, but Ubuntu's version is still problematic. + +Using an Xubuntu 18.04 guest, it's possible to reproduce the crash using: + +while true ; do xrandr --output Virtual-0 --mode 640x480 ; sleep 1 ; xrandr --output Virtual-0 --mode 1280x720 ; sleep 1 ; xrandr --output Virtual-0 --mode 1920x1080 ; sleep 1 ; done + +In less than 20 seconds the guest crash with: + +(process:16447): Spice-CRITICAL **: 15:34:52.047: display-channel.c:2035:display_channel_update: condition `display_channel_validate_surface(display, surface_id)' failed +Abortado (imagem do núcleo gravada) + +Very interesting, Still not triggering for me :-/ +Could you check if the PPA in [1] (with qemu 2.12 planned for Cosmic) already fixes it for you? + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3306/+packages + +Link is better as https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3306 + +Unfortunately it did not work, the error is still the same although it used the GTK interface this time. The command I used was: + +$ qemu-system-x86_64 -vga qxl -enable-kvm -cpu host -smp cores=2,threads=2 -m 2048 -cdrom xubuntu-18.04-desktop-amd64.iso + +I have noticed Ubuntu's QEMU and this QEMU don't have the OpenGL option enabled, may this be related to the issue? + +Yeah we switched to gtk. +With OpenGL which do you mean - the virtgl based support or some other config option? + +Since it still fails to reproduce for me, but you already have a self build qemu that is good. +Could you based on this build 2.12 from source as well and confirm that it fails. +If it does you could bisect from 2.12 to master what fixed it so that we can consider that patch. +Otherwise if 2.12 from source in your own build works lets take a look at the build options that you mentioned. + +I meant the option --enable-opengl and, for old versions, --enable-gtk-gl. I know it is required to use virtual machines using Intel GVT-g with dma-buf, and is a option strangely absent from QEMU configuration from Ubuntu's build. Without it, virgl fails too, making virt-manager have an option that does not work (under Spice Display, OpenGL option does not work). + +The 2.12 build does crash when tested. That while loop is pretty efficient to trigger it. The git version can keep running it for hours straight with no problem, while the problematic versions crash in seconds. + +As QEMU configuration is a result mixed between packages found automatically and those manually set by me, here is the configure command and its results from my QEMU build: https://paste.ubuntu.com/p/z9vnFdTnkD/ + +Please note that I had no need to build other targets for my use, so the configuration is much smaller than the one used by Ubuntu's QEMU. + +The bisect is done and this is the result: + +5bd5c27c7d284d01477c5cc022ce22438c46bf9f is the first new commit +commit 5bd5c27c7d284d01477c5cc022ce22438c46bf9f +Author: Gerd Hoffmann <email address hidden> +Date: Fri Apr 27 13:55:28 2018 +0200 + + qxl: fix local renderer crash + + Make sure we only ask the spice local renderer for display updates in + case we have a valid primary surface. Without that spice is confused + and throws errors in case a display update request (triggered by + screendump for example) happens in parallel to a mode switch and hits + the race window where the old primary surface is gone and the new isn't + establisted yet. + + Cc: <email address hidden> + Fixes: https://bugzilla.redhat.com//show_bug.cgi?id=1567733 + Signed-off-by: Gerd Hoffmann <email address hidden> + Reviewed-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + +:040000 040000 ed86f864314483660b3c2abe045361ae7c98a5dc f0d55b3e98dd0864d6686fba052d83ae5545d007 M hw + + +Nice, thanks Leonardo for the Bisect - lets call upstream Fixed Committed then (as there is no 2.13 released yet). + +For the separate gl discussion feel free to subscribe/chime in on bug 1657409 + +Currently 2.12 is on its way into Cosmic. +I'll add and test that patch afterwards, it looks small and safe to me. + +This bug was fixed in the package qemu - 1:2.12+dfsg-3ubuntu3 + +--------------- +qemu (1:2.12+dfsg-3ubuntu3) cosmic; urgency=medium + + * d/p/lp-1755912-qxl-fix-local-renderer-crash.patch: Fix an issue triggered + by migrations with UI frontends or frequent guest resolution changes + (LP: #1755912) + + -- Christian Ehrhardt <email address hidden> Thu, 19 Jul 2018 08:26:52 +0200 + +Working on Bionic SRu prep in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3367/+packages + +Hello Leonardo, or anyone else affected, + +Accepted qemu into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.11+dfsg-1ubuntu7.5 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Thank you for the effort to backport this bug fix, I have tested the proposed version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5) and the crash when changing resolution is no longer happening. Unfortunately, after some time (about 10 minutes, much longer than without this fix), the guest freezes. + +I reported that in https://bugs.launchpad.net/qemu/+bug/1787070 + +I'll change the tag to verification-done-bionic, as this particular issue was corrected. The other issue still exists in QEMU upstream. + +Note: The code change already passed the general regression checks on the identical content against a PPA (Also on the weekend prior to the full maturing period I'll have another automated run on proposed). + +Running the Bionic ISO like: +$ qemu-system-x86_64 -cpu host -smp cores=4,threads=2 -boot d -m 2048 -enable-kvm -vga qxl -vnc :21 -cdrom ubuntu-18.04-desktop-amd64.iso + +Attaching like: +$ vncviewer FullColor=1 AutoSelect=0 10.245.168.42:5921 +(alternatives on tigervnc) +Well for me it had "-k de" as well :-) + +Then boot into the "try Ubuntu" live CD mode. +There opened a terminal to loop on xrandr. + +Running the loop of above in that guest to crash it after a while. + + + +Upgrade to proposed: +$ sudo apt install qemu-system-x86=1:2.11+dfsg-1ubuntu7.5 +Reading package lists... Done +Building dependency tree +Reading state information... Done +Suggested packages: + samba vde2 qemu-block-extra sgabios ovmf +The following packages will be upgraded: + qemu-system-x86 +1 upgraded, 0 newly installed, 0 to remove and 16 not upgraded. +Need to get 5.168 kB of archives. +After this operation, 0 B of additional disk space will be used. +Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 qemu-system-x86 amd64 1:2.11+dfsg-1ubuntu7.5 [5.168 kB] +Fetched 5.168 kB in 1s (7.666 kB/s) +(Reading database ... 127990 files and directories currently installed.) +Preparing to unpack .../qemu-system-x86_1%3a2.11+dfsg-1ubuntu7.5_amd64.deb ... +Unpacking qemu-system-x86 (1:2.11+dfsg-1ubuntu7.5) over (1:2.11+dfsg-1ubuntu7.4) ... +Setting up qemu-system-x86 (1:2.11+dfsg-1ubuntu7.5) ... +Processing triggers for man-db (2.8.3-2ubuntu0.1) ... + + +Running the loop again with the same setup - no crash in 15 minutes - assume that means good now. +I'd be glad about someone else checking the result as well, best someone formerly affected by it. +(and having a tick in the eye for seeing my right screen change sizes and flicker all the time) + +Setting verified + +Thanks Leonardo for your check as well! +I agree that this particular issue here is fixed as we hoped. +The other one with the freeze did not occur for me, you might open another bug if you have any pointers how we could go on on this. + +Arr reading is hard today, you had the other bug open already ... grml :-) + +Never the less - This bug here is fixed in the proposed version and for now that is the important part. + +Subscribed there as well now to stay on top of it if upstream gets to a conclusion. + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.5 + +--------------- +qemu (1:2.11+dfsg-1ubuntu7.5) bionic; urgency=medium + + [Christian Ehrhardt] + * d/p/lp-1755912-qxl-fix-local-renderer-crash.patch: Fix an issue triggered + by migrations with UI frontends or frequent guest resolution changes + (LP: #1755912) + + [ Murilo Opsfelder Araujo ] + * d/p/ubuntu/target-ppc-extend-eieio-for-POWER9.patch: Backport to + extend eieio for POWER9 emulation (LP: #1787408). + + -- Christian Ehrhardt <email address hidden> Tue, 21 Aug 2018 11:25:45 +0200 + diff --git a/results/classifier/zero-shot/118/user-level-x86/1893010 b/results/classifier/zero-shot/118/user-level-x86/1893010 new file mode 100644 index 000000000..6e5bddf98 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-x86/1893010 @@ -0,0 +1,85 @@ +x86: 0.935 +user-level: 0.930 +performance: 0.880 +files: 0.878 +device: 0.837 +ppc: 0.829 +semantic: 0.820 +architecture: 0.809 +network: 0.791 +graphic: 0.776 +peripherals: 0.769 +kernel: 0.753 +PID: 0.744 +permissions: 0.700 +mistranslation: 0.690 +register: 0.684 +hypervisor: 0.683 +i386: 0.682 +risc-v: 0.668 +debug: 0.660 +arm: 0.658 +socket: 0.651 +boot: 0.625 +virtual: 0.619 +TCG: 0.607 +vnc: 0.580 +VMM: 0.576 +KVM: 0.491 +assembly: 0.370 +-------------------- +user-level: 0.908 +kernel: 0.668 +hypervisor: 0.398 +ppc: 0.150 +virtual: 0.054 +debug: 0.053 +TCG: 0.037 +files: 0.024 +PID: 0.020 +register: 0.016 +device: 0.005 +x86: 0.004 +semantic: 0.003 +VMM: 0.003 +network: 0.002 +socket: 0.002 +architecture: 0.002 +performance: 0.002 +boot: 0.001 +vnc: 0.001 +risc-v: 0.001 +permissions: 0.001 +assembly: 0.000 +KVM: 0.000 +peripherals: 0.000 +graphic: 0.000 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +qemu linux-user doesn't support OFD fcntl locks + +"Open file description locks (non-POSIX)", as they are described in fcntl(2) man page, aren't supported by qemu-user and attempting to use those results in EINVAL. I'm on Gentoo with latest QEMU version currently available (5.0.0-r2), and trying to emulate ppc64 and s390x on x86_64. + +Looking at linux-user/syscall.c, I'm guessing the issue is in (at least) `target_to_host_fcntl_cmd` where switch reaches the default clause as there're no cases for F_OFD_SETLK / F_OFD_SETLKW / F_OFD_GETLK. + +The attached patch fixes the issue for me. + +New patch version: fix target_to_host_fcntl_cmd mapping, avoid do_fcntl code duplication. + +Please check qemu-5.1.0. + +This has been fixed by: + + 2d92c6827ca0 ("linux-user: implement OFD locks") + https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2d92c6827ca0 + +perhaps you can send a patch to the qemu-devel ML to add the strace part. + +Thanks, the changes in 5.1.0 seem to work indeed. + +> perhaps you can send a patch to the qemu-devel ML to add the strace part + +Done. + diff --git a/results/classifier/zero-shot/118/user-level-x86/1899728 b/results/classifier/zero-shot/118/user-level-x86/1899728 new file mode 100644 index 000000000..1affd48e3 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-x86/1899728 @@ -0,0 +1,100 @@ +x86: 0.948 +user-level: 0.818 +device: 0.762 +semantic: 0.740 +VMM: 0.708 +graphic: 0.706 +mistranslation: 0.703 +PID: 0.663 +performance: 0.662 +register: 0.648 +architecture: 0.629 +permissions: 0.627 +network: 0.600 +arm: 0.576 +vnc: 0.573 +ppc: 0.559 +debug: 0.481 +kernel: 0.480 +risc-v: 0.470 +hypervisor: 0.469 +socket: 0.465 +files: 0.445 +boot: 0.433 +KVM: 0.393 +TCG: 0.354 +i386: 0.308 +assembly: 0.255 +peripherals: 0.250 +virtual: 0.201 +-------------------- +x86: 0.857 +hypervisor: 0.818 +user-level: 0.330 +TCG: 0.074 +files: 0.035 +network: 0.017 +register: 0.013 +ppc: 0.013 +semantic: 0.011 +virtual: 0.009 +PID: 0.009 +kernel: 0.006 +device: 0.005 +debug: 0.004 +KVM: 0.004 +VMM: 0.004 +socket: 0.003 +risc-v: 0.003 +assembly: 0.002 +performance: 0.002 +architecture: 0.002 +arm: 0.002 +boot: 0.001 +graphic: 0.001 +permissions: 0.001 +vnc: 0.001 +i386: 0.001 +peripherals: 0.001 +mistranslation: 0.000 + +Qemu-5.1.0 build from source man entry not found + +Hello together, + +i build qemu-5.1.0 from source on centos 8 withe the following command: + +../configure --prefix=/usr --target-list=x86_64-softmmu,x86_64-linux-user + +make -j4 + +make install + +The build and the installation finished successfully. But when i try the command + +man qemu-system-x86_64 + +i got the message "No manual entry found". What i do wrong ? + +Best regards +Damian + +You probably don't have the necessary dependencies to build the manual pages. Since 5.0 we have required Sphinx to be installed to build the docs (see https://wiki.qemu.org/ChangeLog/5.0#Build_Dependencies). + +Pass --enable-docs to configure if you want to force the docs to be built (and then configure will stop with an error if Sphinx or another required tool is missing); otherwise configure will default to "build docs if possible, skip if required tools are missing". + + +There is only one shared man-page for all qemu-system-xxx binaries ... have you tried to simply run "man qemu" ? + +Hello together, + +build with enable-docs and install the required packages now it works with man qemu. + +Many thanks for you help + +Problem resolved :-) + +Best regards +Damian + + diff --git a/results/classifier/zero-shot/118/user-level-x86/1921280 b/results/classifier/zero-shot/118/user-level-x86/1921280 new file mode 100644 index 000000000..e55aef792 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-x86/1921280 @@ -0,0 +1,100 @@ +x86: 0.904 +boot: 0.902 +user-level: 0.845 +graphic: 0.823 +performance: 0.787 +device: 0.785 +PID: 0.706 +hypervisor: 0.694 +mistranslation: 0.661 +arm: 0.657 +ppc: 0.647 +files: 0.622 +architecture: 0.621 +semantic: 0.617 +network: 0.581 +permissions: 0.577 +debug: 0.557 +vnc: 0.552 +peripherals: 0.534 +register: 0.505 +kernel: 0.499 +TCG: 0.480 +socket: 0.445 +i386: 0.418 +VMM: 0.399 +virtual: 0.392 +risc-v: 0.341 +assembly: 0.307 +KVM: 0.277 +-------------------- +x86: 0.984 +boot: 0.802 +virtual: 0.776 +user-level: 0.756 +TCG: 0.148 +hypervisor: 0.061 +debug: 0.039 +files: 0.034 +semantic: 0.026 +PID: 0.013 +performance: 0.013 +device: 0.009 +network: 0.007 +i386: 0.003 +kernel: 0.003 +socket: 0.002 +architecture: 0.002 +ppc: 0.002 +register: 0.002 +assembly: 0.002 +graphic: 0.001 +peripherals: 0.001 +permissions: 0.001 +risc-v: 0.001 +vnc: 0.001 +arm: 0.001 +VMM: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +OpenIndiana stuck in boot loop when using hvf + +I'm using QEMU version 5.2.0 on macOS, and running the "OpenIndiana Hipster 2020.10 Text Install DVD (64-bit x86)" ISO: + +qemu-system-x86_64 -cdrom ~/Downloads/OI-hipster-text-20201031.iso -m 2048 -accel hvf -cpu host + +It gets to "Booting...", stays there for a bit, and then restarts. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/118/user-level-x86/2274 b/results/classifier/zero-shot/118/user-level-x86/2274 new file mode 100644 index 000000000..8fc869389 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-x86/2274 @@ -0,0 +1,103 @@ +x86: 0.965 +graphic: 0.884 +user-level: 0.802 +device: 0.734 +performance: 0.730 +ppc: 0.658 +kernel: 0.638 +semantic: 0.620 +debug: 0.591 +hypervisor: 0.582 +PID: 0.558 +architecture: 0.558 +peripherals: 0.540 +boot: 0.534 +vnc: 0.528 +mistranslation: 0.467 +network: 0.464 +arm: 0.437 +socket: 0.436 +TCG: 0.360 +files: 0.349 +VMM: 0.346 +risc-v: 0.344 +permissions: 0.341 +register: 0.335 +virtual: 0.313 +KVM: 0.296 +i386: 0.271 +assembly: 0.250 +-------------------- +x86: 0.984 +hypervisor: 0.640 +kernel: 0.610 +virtual: 0.560 +debug: 0.542 +performance: 0.124 +assembly: 0.119 +files: 0.061 +PID: 0.049 +register: 0.045 +TCG: 0.041 +KVM: 0.038 +semantic: 0.027 +device: 0.027 +user-level: 0.011 +VMM: 0.011 +architecture: 0.010 +network: 0.007 +socket: 0.006 +boot: 0.004 +ppc: 0.003 +graphic: 0.002 +risc-v: 0.002 +peripherals: 0.002 +permissions: 0.002 +vnc: 0.001 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +Assertion failuer in cryptodev_builtin_close_session() +Description of problem: +In the function _cryptodev_builtin_close_session(),_ an assertation happened: + +``` +qemu-fuzz-x86_64: qemu/backends/cryptodev-builtin.c:430: int cryptodev_builtin_close_session(CryptoDevBackend *, uint64_t, uint32_t, CryptoDevCompletionFunc, void *): Assertion `session_id < MAX_NUM_SESSIONS && builtin->sessions[session_id]' failed. +==1256139== ERROR: libFuzzer: deadly signal + #9 0x71acb8c2871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x71acb8c39e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x5af7f624b12b in cryptodev_builtin_close_session qemu/backends/cryptodev-builtin.c:430:5 + #12 0x5af7f60b2860 in virtio_crypto_handle_close_session qemu/hw/virtio/virtio-crypto.c:262:12 + #13 0x5af7f60b2860 in virtio_crypto_handle_ctrl qemu/hw/virtio/virtio-crypto.c:423:19 +``` + +The user could send an invalid session_id to trigger this assertion. +Steps to reproduce: +Here's a simple PoC: + +``` +cat << EOF | qemu-system-x86_64 -display none\ + -machine accel=qtest -m 512M -machine q35 -nodefaults -object \ +cryptodev-backend-builtin,id=cryptodev0 -device \ +virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -qtest stdio +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +outl 0xcf8 0x80000820 +outl 0xcfc 0xe0008000 +write 0x10800e 0x1 0x01 +write 0xe0008016 0x1 0x01 +write 0xe0008020 0x4 0x00801000 +write 0xe0008028 0x4 0x00c01000 +write 0xe000801c 0x1 0x01 +write 0x110000 0x1 0x05 +write 0x110001 0x1 0x04 +write 0x108002 0x1 0x11 +write 0x108008 0x1 0x48 +write 0x10800c 0x1 0x01 +write 0x108018 0x1 0x10 +write 0x10801c 0x1 0x02 +write 0x10c002 0x1 0x01 +write 0xe000b005 0x1 0x00 +EOF +``` diff --git a/results/classifier/zero-shot/118/user-level-x86/2583 b/results/classifier/zero-shot/118/user-level-x86/2583 new file mode 100644 index 000000000..3a07ce013 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-x86/2583 @@ -0,0 +1,85 @@ +x86: 0.926 +user-level: 0.887 +device: 0.863 +graphic: 0.846 +ppc: 0.845 +boot: 0.840 +PID: 0.827 +i386: 0.811 +risc-v: 0.808 +vnc: 0.803 +KVM: 0.759 +hypervisor: 0.757 +performance: 0.755 +socket: 0.717 +debug: 0.701 +VMM: 0.700 +architecture: 0.667 +kernel: 0.660 +semantic: 0.657 +TCG: 0.640 +network: 0.599 +arm: 0.576 +register: 0.562 +permissions: 0.553 +files: 0.553 +peripherals: 0.495 +assembly: 0.459 +virtual: 0.393 +mistranslation: 0.366 +-------------------- +x86: 0.953 +files: 0.498 +TCG: 0.420 +hypervisor: 0.387 +register: 0.175 +debug: 0.164 +ppc: 0.149 +kernel: 0.068 +virtual: 0.040 +VMM: 0.028 +PID: 0.026 +boot: 0.017 +risc-v: 0.016 +i386: 0.015 +device: 0.012 +semantic: 0.012 +network: 0.005 +socket: 0.004 +performance: 0.004 +KVM: 0.004 +architecture: 0.004 +permissions: 0.003 +arm: 0.003 +user-level: 0.003 +assembly: 0.003 +peripherals: 0.002 +graphic: 0.002 +vnc: 0.002 +mistranslation: 0.000 + +libvfio-user.so.0 missing in /lib/x86_64-linux-gnu/ in fresh install of 9.1.50 +Description of problem: +Library libvfio-user.so.0 is missing from /lib/x86_64-linux-gnu. qemu-system-x86_64 does not start due to missing library. + +```` +root@jpbdeb:~# ls -al /usr/local/bin/qemu-system-x86_64 +-rwxr-xr-x 1 root root 81734576 Sep 21 21:48 /usr/local/bin/qemu-system-x86_64 +root@jpbdeb:~# ldd /usr/local/bin/qemu-system-x86_64 + linux-vdso.so.1 (0x00007fff511de000) + libvfio-user.so.0 => not found + libslirp.so.0 => /lib/x86_64-linux-gnu/libslirp.so.0 (0x00007f73eba33000) + libxenctrl.so.4.17 => /lib/x86_64-linux-gnu/libxenctrl.so.4.17 (0x00007f73eba09000) + libxenstore.so.4 => /lib/x86_64-linux-gnu/libxenstore.so.4 (0x00007f73eb9fe000) + libxenforeignmemory.so.1 => /lib/x86_64-linux-gnu/libxenforeignmemory.so.1 (0x00007f73eb9f9000) + ... +```` +Steps to reproduce: +1. Fresh OS install, including all packages necessary to build from source. +2. Download source from gitlab and proceed with documented build instructions. +3. make install +4. Attempt to run /usr/local/bin/qemu-system-x86_64 fails, due to missing library. +Additional information: +Adding the link to the library that exists in /usr/lib/x86_64-linux-gnu resolves the issue: + +(as root) ln -s /usr/local/lib/x86_64-linux-gnu/libvfio-user.so.0 /lib/x86_64-linux-gnu/libvfio-user.so.0 diff --git a/results/classifier/zero-shot/118/user-level-x86/2924 b/results/classifier/zero-shot/118/user-level-x86/2924 new file mode 100644 index 000000000..37b7c6271 --- /dev/null +++ b/results/classifier/zero-shot/118/user-level-x86/2924 @@ -0,0 +1,75 @@ +x86: 0.948 +device: 0.899 +graphic: 0.874 +user-level: 0.850 +debug: 0.769 +semantic: 0.700 +performance: 0.637 +mistranslation: 0.599 +network: 0.562 +architecture: 0.526 +permissions: 0.485 +PID: 0.475 +i386: 0.467 +register: 0.364 +vnc: 0.362 +socket: 0.354 +ppc: 0.281 +peripherals: 0.197 +TCG: 0.192 +VMM: 0.185 +risc-v: 0.180 +files: 0.175 +kernel: 0.172 +virtual: 0.169 +boot: 0.167 +hypervisor: 0.149 +arm: 0.098 +KVM: 0.084 +assembly: 0.075 +-------------------- +x86: 0.975 +debug: 0.957 +user-level: 0.745 +TCG: 0.257 +virtual: 0.249 +hypervisor: 0.036 +PID: 0.028 +files: 0.028 +register: 0.024 +network: 0.020 +performance: 0.018 +semantic: 0.016 +ppc: 0.015 +device: 0.009 +socket: 0.007 +assembly: 0.007 +graphic: 0.004 +kernel: 0.004 +peripherals: 0.003 +architecture: 0.003 +i386: 0.003 +boot: 0.003 +risc-v: 0.002 +permissions: 0.002 +VMM: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.001 +KVM: 0.000 + +qemu-user not responding to Ctrl-C from gdb +Description of problem: +When attached to qemu-x84_64's gdbserver via gdb, it is not possible to interrupt the binary being emulated. Usually, Ctrl-C will interrupt a running binary from gdb and I believe (though have not tested) it works in qemu-system. + +First Ctrl-C will do nothing and second will prompt to stop debugging. +``` +(gdb) c +Continuing. +^C^CThe target is not responding to interrupt requests. +Stop debugging it? (y or n) +``` +Steps to reproduce: +1. Run `./qemu-x86_64 -g 1234 ~/Downloads/base64-x64_64-static` or any static binary that will pause/hang +2. Connect from gdb `(gdb) target remote :1234` +3. Ctrl-C in gdb |