diff options
Diffstat (limited to 'results/classifier/118/user-level-ppc')
| -rw-r--r-- | results/classifier/118/user-level-ppc/1245724 | 131 | ||||
| -rw-r--r-- | results/classifier/118/user-level-ppc/1674925 | 357 | ||||
| -rw-r--r-- | results/classifier/118/user-level-ppc/1841491 | 118 | ||||
| -rw-r--r-- | results/classifier/118/user-level-ppc/834 | 119 | ||||
| -rw-r--r-- | results/classifier/118/user-level-ppc/927 | 92 |
5 files changed, 817 insertions, 0 deletions
diff --git a/results/classifier/118/user-level-ppc/1245724 b/results/classifier/118/user-level-ppc/1245724 new file mode 100644 index 000000000..f89c5f96a --- /dev/null +++ b/results/classifier/118/user-level-ppc/1245724 @@ -0,0 +1,131 @@ +user-level: 0.924 +mistranslation: 0.885 +semantic: 0.864 +kernel: 0.848 +performance: 0.829 +KVM: 0.826 +architecture: 0.812 +debug: 0.811 +ppc: 0.809 +PID: 0.784 +files: 0.779 +device: 0.750 +permissions: 0.739 +graphic: 0.725 +hypervisor: 0.722 +peripherals: 0.709 +x86: 0.697 +network: 0.690 +register: 0.678 +assembly: 0.676 +vnc: 0.660 +arm: 0.651 +risc-v: 0.649 +VMM: 0.628 +TCG: 0.623 +socket: 0.609 +i386: 0.583 +boot: 0.507 +virtual: 0.453 +-------------------- +debug: 0.977 +user-level: 0.941 +x86: 0.731 +hypervisor: 0.154 +network: 0.117 +files: 0.113 +i386: 0.086 +PID: 0.081 +TCG: 0.077 +kernel: 0.052 +register: 0.049 +virtual: 0.048 +device: 0.035 +performance: 0.035 +architecture: 0.023 +socket: 0.022 +KVM: 0.022 +semantic: 0.021 +vnc: 0.020 +peripherals: 0.020 +arm: 0.016 +boot: 0.013 +permissions: 0.005 +assembly: 0.004 +ppc: 0.004 +VMM: 0.003 +mistranslation: 0.003 +graphic: 0.003 +risc-v: 0.001 + +libfdt.a git compilation fail + +I don't know the commit tags but I checked out dtc on the 28 of october at 20:27 in the tree of qemu (also git checkout out tonight). The compilation fail at line 234 in qemu/dtc/Makefile so I inserted that line: + +@$ /usr/bin/strace -o /usr/src/qemu_build/error.log.txt /usr/bin/ar $@ + +into the makefile at position 234 to see what is the exact problem but the strace log is inconclusive. + +for the error: /usr/bin/ar: deux operations différentes spécifiées + +liberal translation is: two different operation specified. + +the distribution is arch linux with binutils 2.23.2, gcc 4.8.2 and kernel kvm-3.12.0-rc5 from git. + + + +Which version of make are you using? Recently, a bug with make 4.0 has been discovered, please see this thread for a description and a work-around: + +http://<email address hidden>/msg198719.html + + +I am indeed using make v4.0. Thanks you very much for the email thread, I will try to compile qemu again. + +Alain + +-----Message d'origine----- +De : <email address hidden> [mailto:<email address hidden>] De la part de thh +Envoyé : 29 octobre 2013 04:32 +À : <email address hidden> +Objet : [Bug 1245724] Re: libfdt.a git compilation fail + +Which version of make are you using? Recently, a bug with make 4.0 has been discovered, please see this thread for a description and a work- +around: + +http://<email address hidden>/msg198719.html + +-- +You received this bug notification because you are subscribed to the bug report. +https://bugs.launchpad.net/bugs/1245724 + +Title: + libfdt.a git compilation fail + +Status in QEMU: + New + +Bug description: + I don't know the commit tags but I checked out dtc on the 28 of + october at 20:27 in the tree of qemu (also git checkout out tonight). + The compilation fail at line 234 in qemu/dtc/Makefile so I inserted + that line: + + @$ /usr/bin/strace -o /usr/src/qemu_build/error.log.txt /usr/bin/ar $@ + + into the makefile at position 234 to see what is the exact problem but + the strace log is inconclusive. + + for the error: /usr/bin/ar: deux operations différentes spécifiées + + liberal translation is: two different operation specified. + + the distribution is arch linux with binutils 2.23.2, gcc 4.8.2 and + kernel kvm-3.12.0-rc5 from git. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1245724/+subscriptions + + + +This should be working fine again with recent versions of QEMU, so I'm closing the bug. If you still have problems, feel free to open it again. + diff --git a/results/classifier/118/user-level-ppc/1674925 b/results/classifier/118/user-level-ppc/1674925 new file mode 100644 index 000000000..a845168b4 --- /dev/null +++ b/results/classifier/118/user-level-ppc/1674925 @@ -0,0 +1,357 @@ +user-level: 0.881 +peripherals: 0.873 +semantic: 0.870 +device: 0.866 +virtual: 0.865 +assembly: 0.859 +mistranslation: 0.855 +register: 0.841 +socket: 0.841 +debug: 0.835 +ppc: 0.832 +network: 0.818 +PID: 0.818 +arm: 0.815 +files: 0.815 +kernel: 0.812 +performance: 0.810 +KVM: 0.809 +architecture: 0.806 +graphic: 0.801 +risc-v: 0.800 +permissions: 0.791 +VMM: 0.790 +vnc: 0.782 +hypervisor: 0.766 +boot: 0.750 +TCG: 0.740 +i386: 0.613 +x86: 0.459 +-------------------- +ppc: 0.959 +hypervisor: 0.816 +virtual: 0.684 +KVM: 0.289 +debug: 0.042 +TCG: 0.036 +register: 0.026 +files: 0.026 +user-level: 0.020 +VMM: 0.019 +graphic: 0.014 +boot: 0.013 +PID: 0.012 +device: 0.011 +socket: 0.010 +vnc: 0.008 +risc-v: 0.007 +kernel: 0.006 +network: 0.005 +semantic: 0.005 +assembly: 0.003 +performance: 0.003 +peripherals: 0.002 +architecture: 0.002 +arm: 0.001 +permissions: 0.001 +mistranslation: 0.001 +x86: 0.001 +i386: 0.000 + +Qemu PPC64 kvm no display if --device virtio-gpu-pci is selected + +Hi, +i did many tests on qemu 2.8 on my BE machines and i found an issue that i think was need to be reported + +Test Machines BE 970MP + +if i setup qemu with + +qemu-system-ppc64 -M 1024 --display sdl(or gtk),gl=on --device virtio-gpu-pci,virgl --enable-kvm and so and so + +result is doubled window one is vga other is virtio-gpu-pci without any start of the VM . pratically i dont have any output of openbios and on the virtual serial output + +the same issue i found is if i select: +qemu-system-ppc64 -M 1024 --display gtk(or sdl) --device virtio-gpu-pci --enable-kvm and so and so + + +i had been try to change all the -M types of all kind of pseries without any positive result. + +Ciao +Luigi + +Hi! I think unless you use "-vga none" or "-nodefaults", QEMU will always start your guest with a VGA card by default, so if you add an additional "--device virtio-gpu-pci", you'll end up with a guest that has two video cards, one VGA and one virtio-gpu. +Also there is a known bug in the SLOF version that has been shipped with QEMU 2.8, which causes trouble with virtio-gpu: +http://git.qemu-project.org/?p=SLOF.git;a=commitdiff;h=38bf852e73ce6f0ac801dfe8ef1545c4cd0b5ddb +Please try again with the latest release candidate of QEMU 2.9, it should be fixed there. +(But please note that SLOF does not contain a driver for virtio-gpu, so you won't see any output from the firmware when starting your guest ... i.e. you'll just see some output once Linux has been started) + +Hi Thomas, thanks for your reply i will test and report my experience ASAP + +Ciao +Luigi + +Hi Thomas with 2.9 rc1 i have this with --enable-kvm + +emu-system-ppc64 --enable-kvm +qemu-system-ppc64: KVM and IRQ_XICS capability must be present for in-kernel XICS + +and the qemu dont run. + +Ciao +Luigi + +Hi Thomas, + +just exit like it is an error with a wrong option. +the output is only this qemu-system-ppc64: KVM and IRQ_XICS capability must be present for in-kernel XICS +Same is if i add all the options i have the seme error. +look like qemu need for run in kvm a kernel with XICS option enabled and XICS is present only from ibm power 5 to up if i remember good. +After work i can test it if needed on Qoriq e5500 too for check if there is the same issue on an emb ppc64 processor. + +Ciao +Luigi + + + +On 22.03.2017 14:35, luigiburdo wrote: +> Hi Thomas with 2.9 rc1 i have this with --enable-kvm +> +> emu-system-ppc64 --enable-kvm +> qemu-system-ppc64: KVM and IRQ_XICS capability must be present for in-kernel XICS +> +> and the qemu dont run. + +Does it exit, or just hang afterwards? Was this with or without --device +virtio-gpu-pci option? Do you get any output if you run QEMU with +"-nographic" instead? + + Thomas + + + + +Hi Cédric, + +i have the 4.11 rc1 . on fedora 25 ppc 64 on both machine Qoriq and on G5 Quad. + +On the 2.8 this issue isnt present but +I did the test o Qoriq e5500 a book3e processor and on 2.8 if i made: + +qemu-system-ppc64 --enable-kvm the true result is: +qemu-system-ppc64: Unable to find CPU definition: host + +on qemu 2.9 rc1 + +./qemu-system-ppc64 --enable-kvm i have : +qemu-system-ppc64: KVM and IRQ_XICS capability must be present for in-kernel XICS + +On Qoriq if i pass the -cpu e500 (normal thing) all is working right qemu 2.9rc1 all boot and so and so. + +On G5 the -cpu variable dont fix the issue. + +I can build a new kernel release , usually mine dont have xics enabled because G5 dont have that feature, if needed i can enable it for testing. + + +Hope my english is understandable. + +ciao + +Luigi + +________________________________ +Da: Qemu-ppc <email address hidden> per conto di Cédric Le Goater <email address hidden> +Inviato: mercoledì 22 marzo 2017 18.29 +A: Thomas Huth; Bug 1674925; <email address hidden> +Cc: <email address hidden> +Oggetto: Re: [Qemu-ppc] [Qemu-devel] [Bug 1674925] Re: Qemu PPC64 kvm no display if --device virtio-gpu-pci is selected + +On 03/22/2017 03:15 PM, Thomas Huth wrote: +> On 22.03.2017 14:35, luigiburdo wrote: +>> Hi Thomas with 2.9 rc1 i have this with --enable-kvm +>> +>> emu-system-ppc64 --enable-kvm +>> qemu-system-ppc64: KVM and IRQ_XICS capability must be present for in-kernel XICS +>> +>> and the qemu dont run. +> +> Does it exit, or just hang afterwards? Was this with or without --device +> virtio-gpu-pci option? Do you get any output if you run QEMU with +> "-nographic" instead? + +I guess this is an issue with the host kernel. Which one are you running ? + +C. + + + + + + +Hello Cédric, + +with your last message you made me think about and make more test. + +>The default machine for qemu-system-ppc64 is pseries. +yes usually with 2.8 i boot the VM without issue on G5 Quad with the option -M pseries from 2.1 to 2.5 with kvm-pr enabled. +i did the tests and with all pseries now on 2.9 i have the same issue. +example: +qemu-system-ppc64 --enable-kvm -cpu 970fx_v2.0 -m 1024 -M pseries-2.1 +qemu-system-ppc64: KVM and IRQ_XICS capability must be present for in-kernel XICS + +but no issue if i run with -M mac99 before 2.9 was not possible use it on qemu-system-ppc64 +It means it will no possible anymore in future release of qemu use open firmware on powermacs any moore? + + +>I admit the message is not very clear, but the host kernel is +>using a dev config. + +Im so sorry, i learn English by my self reading ml and on irc chatting is too difficult where no one speak English around. + +>> On Qoriq if i pass the -cpu e500 (normal thing) all is working right qemu 2.9rc1 +>> all boot and so and so. +>but you must be changing the machine right ? +not on Qoriq because it is book3e and is not so flexible like the G5 Quad who is book3s machine. +i can run qemu kvm only with emb hardware on Qoriq + +>>On G5 the -cpu variable dont fix the issue. +>with which machine ? +On PowerMac G5 Quad 970MP it have similar hardware configuration of IBM intellistation power 285 + +> >I can build a new kernel release , usually mine dont have xics enabled because G5 +>> dont have that feature, if needed i can enable it for testing.** +>Yes that would be interesting. + +I will do ASAP just the time to build it . + +Thank you really much for your time and patience. +Luigi +________________________________ + + +Hi Cèdric, + +first of all thanks for your relpy. + + + +>I have some difficulty sorting out what is going on and what +>could be considered a regression :/ you are reporting many +>issues at the same time with a home made kernel. + +>Could you please use the kernel shipped with the distro to +>start with ? + +I can do it and report. + +> yes usually with 2.8 i boot the VM without issue on G5 Quad with the option +> -M pseries from 2.1 to 2.5 with kvm-pr enabled. +> i did the tests and with all pseries now on 2.9 i have the same issue. +> example: +> qemu-system-ppc64 --enable-kvm -cpu 970fx_v2.0 -m 1024 -M pseries-2.1 +> qemu-system-ppc64: KVM and IRQ_XICS capability must be present for in-kernel XICS + +>This error message is because your host kernel lacks in-kernel XICS, +>but you are saying that was not an issue with QEMU-2.8. Correct ? + +Exactly i have the same on Qoriq too. + +>Here is the command line I used on a 17.04 host : +>qemu-system-ppc64 -M pseries-2.[1-8],accel=kvm,kvm-type=PR -cpu 970fx_v2.0 -m 1024 -nographic + +I will try your same command line and see what will exit on me. +I cant use qemu on 17.04 host because there is no more support for PPC32, PPC64 dead line is 16.10 and last working version +of qemu on PPC is 2.6.1 i dint try 2.9 there if needed i can do i have ubuntu mate 17.04 installed too. + +>Did we introduce a regression in compatibility in QEMU 2.9 ? or +Im facing many issue on this last update im try to help how i can before all come upstream. +i like really much qemu. i can help in testing on PPC64 Be if need with my hw. +>was it bogus before ? That needs a little digging. I did not work +>on that part. +dont worry you did much + +Thanks +Luigi + + + + + +Hi Cèdric, + +i had been build the kernel with the Xics option enabled and all work on G5 970MP on Mate 17.04 + +i will test the same kernel of Fedora server PPC64 and see if there will work too. + +but it is strange thing, because the option was not needed (by the kernel default) + +on PowerMacs and was not need to be enabled on Qemu 2.8. + +I suggest to add this in the user faq PowerPC. + + +I will test it on Qoriq too if kernel build with this option enabled and if all work ok there too + +in case i will report as usual. + + +I will warn all the PowerPc comunity about if the qemu devs will need to have Xics turned on as default in the kernel + +Thanks for your support +Luigi + +________________________________ + + +Hi, + +now i understand . xics have to be build in kernel and is needed by qemu 2.9 with kvm. +if is not present in the kernel have the issue that i been reported about xics. +I make a test on ubuntu 16.10 and on 17.04. the two distro are ppc 32 and generic. +i had build the stable kernel 4.10.5 two times with the same config the only parameter that i had change was the xics one was yes and the other was no. + +On the two ubuntu version when i run kernel without xics i had the issue reported. if i run the kernel with xics enabled qemu 2.9 is working and was gave no issue. +but ... +on Fedora server 25 ppc64 if xics is present in the kernel the system (fedora) not run and freeze after the kernel bootstrap. + + + +Hope all is understandable + +Thanks +Luigi + + + +When you use "-vga none" or "-nodefaults" with that kernel where you've enabled xics, do you now get some output in the windows once Linux has booted? + +hi thomas on Qoriq Xics isnt present and cant be selected and i dont have video output too +this is a shot of the kernel config. +On G5 Quad i will made a shoot too i thinks screenshots is better then may english knowledge :P + + +attched the booted mate 16.10 Qemu system ppc64 --kvm on Qoriq without video initialized +only way i have to see something is with --serial stdio + +here i post the log of Qemu-system-ppc64 i filed a new bug about https://bugs.launchpad.net/qemu/+bug/1677247 + +soon the G5 Quad shots + +Hi thomas, +this is the quad G5 shot on ubuntu mate 17.04 with last stable kernel 4.10.7 with xics builded inside +you can see i have the same result i have on Qoriq on fedora ppc64 . the only way for see something is use -serial stdio option + +sorry for the extra comment on g5 quad i use this options +gigi@gigi-desktop:~/qemu-2.9.0-rc1/ppc64-softmmu$ sudo ./qemu-system-ppc64 -enable-kvm -m 1024 -display sdl,gl=on -device virtio-gpu-pci,virgl --nodefaults -vga none -M pseries-2.5 -smp 2 -serial stdio + +for no serial + +sudo ./qemu-system-ppc64 -enable-kvm -m 1024 -display sdl,gl=on -device virtio-gpu-pci,virgl --nodefaults -vga none -M pseries-2.5 -smp 2 -serial stdio . +you can see i dont have any output on the virtio-gpu-pci . itry with virgl and without and i try with -device virtio-vga too .. all gave the same result changing the pseries too. + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/user-level-ppc/1841491 b/results/classifier/118/user-level-ppc/1841491 new file mode 100644 index 000000000..055635e61 --- /dev/null +++ b/results/classifier/118/user-level-ppc/1841491 @@ -0,0 +1,118 @@ +ppc: 0.969 +x86: 0.937 +user-level: 0.919 +graphic: 0.916 +architecture: 0.906 +semantic: 0.899 +performance: 0.893 +debug: 0.839 +device: 0.807 +mistranslation: 0.801 +vnc: 0.760 +kernel: 0.733 +virtual: 0.721 +PID: 0.717 +files: 0.714 +socket: 0.701 +assembly: 0.693 +boot: 0.689 +KVM: 0.683 +network: 0.669 +permissions: 0.669 +risc-v: 0.668 +VMM: 0.661 +TCG: 0.649 +hypervisor: 0.647 +peripherals: 0.640 +arm: 0.602 +register: 0.601 +i386: 0.589 +-------------------- +ppc: 0.871 +performance: 0.053 +assembly: 0.045 +debug: 0.043 +files: 0.028 +semantic: 0.020 +TCG: 0.020 +register: 0.015 +virtual: 0.007 +user-level: 0.006 +PID: 0.006 +architecture: 0.005 +kernel: 0.004 +hypervisor: 0.003 +device: 0.003 +network: 0.002 +boot: 0.002 +socket: 0.002 +VMM: 0.001 +risc-v: 0.001 +vnc: 0.001 +graphic: 0.001 +x86: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +KVM: 0.000 +arm: 0.000 +i386: 0.000 + +floating point emulation can fail to set FE_UNDERFLOW + +Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. + +This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. + +On ppc64le native: +-- +$ gcc -c -O2 fma.c +$ gcc -O2 test-fma.c fma.o -lm -o test-fma +$ ./test-fma $(./test-fma) +fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022) +0x0 + +0xa000000 +FE_INEXACT FE_UNDERFLOW +0x1p-1022 +-- + +On qemu-system-ppc64: +-- +$ ./test-fma $(./test-fma) +fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022) +0x0 + +0x2000000 +FE_INEXACT +0x1p-1022 +-- + +QEMU versions vary, but not too much, and are pretty close to git HEAD: +- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging +- 864ab31 Update version for v4.1.0-rc4 release + +There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. + + + + + +Responding to the patch https://lists.nongnu.org/archive/html/qemu-ppc/2019-08/msg00404.html, it seems to work for "double", but not for "float". Test case attached. + + + +The float test failure is part of a larger problem for target/powerpc in which all float routines are implemented incorrectly. They are all implemented as double operations with rounding to float as a second step. Which not only produces incorrect exceptions, as in this case, but incorrect numerical results from the double rounding. + +This should probably be split to a separate bug... + +A patch for this bug has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cbc65a8f22b29680f3 +... can we close this ticket now or is there more to do? + +Comment #5 suggested splitting the "float" issue to a separate bug, which was done some time ago (bug #1841592). + +I think this ticket can be closed. + +Ok, thanks for the pointer to the other bug! So I'm closing this one now. + diff --git a/results/classifier/118/user-level-ppc/834 b/results/classifier/118/user-level-ppc/834 new file mode 100644 index 000000000..6db8fdd2d --- /dev/null +++ b/results/classifier/118/user-level-ppc/834 @@ -0,0 +1,119 @@ +user-level: 0.931 +graphic: 0.900 +performance: 0.870 +ppc: 0.824 +kernel: 0.813 +mistranslation: 0.726 +device: 0.724 +semantic: 0.717 +x86: 0.692 +architecture: 0.669 +risc-v: 0.657 +vnc: 0.642 +peripherals: 0.623 +network: 0.621 +assembly: 0.619 +socket: 0.613 +hypervisor: 0.608 +arm: 0.605 +PID: 0.566 +debug: 0.556 +files: 0.540 +permissions: 0.538 +KVM: 0.525 +i386: 0.465 +boot: 0.459 +VMM: 0.448 +register: 0.432 +TCG: 0.430 +virtual: 0.280 +-------------------- +user-level: 0.868 +kernel: 0.655 +x86: 0.152 +hypervisor: 0.142 +debug: 0.073 +virtual: 0.058 +PID: 0.024 +files: 0.019 +TCG: 0.015 +semantic: 0.010 +register: 0.007 +architecture: 0.004 +performance: 0.003 +device: 0.003 +ppc: 0.002 +i386: 0.002 +network: 0.002 +KVM: 0.002 +peripherals: 0.002 +socket: 0.001 +boot: 0.001 +VMM: 0.001 +permissions: 0.001 +graphic: 0.001 +mistranslation: 0.000 +assembly: 0.000 +vnc: 0.000 +risc-v: 0.000 +arm: 0.000 + +linux-user: fails to deliver signals raised during pselect +Description of problem: +When run via qemu a program which blocks signals but unmasks them during `pselect` does not catch these signals when returning from `pselect`. + +Used as reference on expected behavior: [The new pselect() system call](https://lwn.net/Articles/176911/) +Steps to reproduce: +A minimal test case below mimics behavior as encountered in the test suite of `p11-kit` ([link](https://github.com/p11-glue/p11-kit)) (which attempts to catch `SIGTERM` in a similar way and results in lingering processes after running the test suite). + +```C +#include <stdio.h> +#include <unistd.h> +#include <signal.h> +#include <sys/select.h> + +static void handler(int sig) +{ + puts("SIGNAL"); +} + +int main(int argc, char *argv[]) +{ + struct sigaction sa; + + fd_set rfds; + sigset_t emptyset, blockset; + + sigemptyset (&blockset); + sigemptyset (&emptyset); + sigaddset (&blockset, SIGUSR1); + + sa.sa_handler = handler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + sigaction(SIGUSR1, &sa, NULL); + + sigprocmask (SIG_BLOCK, &blockset, NULL); + + FD_ZERO(&rfds); + + while(1) { + pselect(0, &rfds, NULL, NULL, NULL, &emptyset); + } + + return 0; +} +``` + +Running this without qemu should print _SIGNAL_ when sent `SIGUSR1`: + +``` +$ ./a.out & +[1] 1683587 +$ kill -USR1 %1 +$ SIGNAL +``` + +When run with `qemu-x86_64` however, it does not (also qemu's `-strace` confirms the signal isn't received whereas a strace of qemu shows it's in fact delivered). + +The pselect call itself _is_ interrupted, but the signal goes missing. diff --git a/results/classifier/118/user-level-ppc/927 b/results/classifier/118/user-level-ppc/927 new file mode 100644 index 000000000..fdf0ed419 --- /dev/null +++ b/results/classifier/118/user-level-ppc/927 @@ -0,0 +1,92 @@ +ppc: 0.875 +user-level: 0.816 +x86: 0.800 +architecture: 0.741 +graphic: 0.708 +device: 0.635 +peripherals: 0.591 +virtual: 0.534 +kernel: 0.527 +performance: 0.508 +arm: 0.504 +semantic: 0.493 +debug: 0.488 +PID: 0.407 +vnc: 0.388 +files: 0.370 +register: 0.312 +permissions: 0.285 +network: 0.231 +TCG: 0.190 +socket: 0.181 +mistranslation: 0.166 +VMM: 0.159 +hypervisor: 0.142 +risc-v: 0.127 +assembly: 0.124 +boot: 0.120 +i386: 0.092 +KVM: 0.042 +-------------------- +user-level: 0.972 +x86: 0.649 +debug: 0.562 +virtual: 0.521 +files: 0.074 +TCG: 0.049 +PID: 0.020 +register: 0.016 +arm: 0.014 +kernel: 0.013 +network: 0.008 +permissions: 0.007 +semantic: 0.007 +hypervisor: 0.006 +performance: 0.005 +device: 0.005 +architecture: 0.004 +VMM: 0.004 +ppc: 0.004 +boot: 0.003 +socket: 0.002 +peripherals: 0.002 +graphic: 0.001 +i386: 0.001 +assembly: 0.001 +vnc: 0.001 +KVM: 0.000 +mistranslation: 0.000 +risc-v: 0.000 + +linux-user: openat on /proc/self/exe can return a closed file descriptor +Description of problem: +`open("/proc/self/exe", ...)` returns a closed file descriptor if qemu-user was executed as an interpreter, passing a file descriptor in the `AT_EXECFD` auxval. + +When the `AT_EXECFD` auxval is nonzero the user program is loaded through `load_elf_binary()` (in `linux-user/elfload.c`) which ultimately calls `load_elf_image()` with that same file descriptor, and `load_elf_image()` closes the file descriptor before returning. + +`do_openat` in `linux-user/syscall.c` will return that file descriptor to the user if the opened path satisfies `is_proc_myself(pathname, "exe")`, which is obviously wrong both in that the file descriptor is closed as part of the initialization process of qemu itself, and that the user program would then close that file descriptor and thus the next invocation of `open` would have the same problem. +Steps to reproduce: +This program prints `3 3` in a x86_64 docker container on my machine (arm64 macos, which docker desktop handles by running containers in a native linux VM under qemu-user). + +```c +#include <fcntl.h> +#include <stdio.h> + +int main(int argc, char **argv) { + int selfexe = open("/proc/self/exe", O_RDONLY | O_CLOEXEC); + if (selfexe < 0) { + perror("open self"); + return 1; + } + + int devnull = open("/dev/null", O_WRONLY | O_CLOEXEC); + if (devnull < 0) { + perror("open devnull"); + return 1; + } + + printf("%d %d\n", selfexe, devnull); +} +``` +Additional information: +Thanks to @pm215 for helping me pinpoint the exact issue I was encountering. |