diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/118/none/1906 | 64 | ||||
| -rw-r--r-- | results/classifier/118/none/1906180 | 66 | ||||
| -rw-r--r-- | results/classifier/118/none/1906516 | 154 | ||||
| -rw-r--r-- | results/classifier/118/none/1906536 | 160 | ||||
| -rw-r--r-- | results/classifier/118/none/1906948 | 90 |
5 files changed, 534 insertions, 0 deletions
diff --git a/results/classifier/118/none/1906 b/results/classifier/118/none/1906 new file mode 100644 index 00000000..3ccb9872 --- /dev/null +++ b/results/classifier/118/none/1906 @@ -0,0 +1,64 @@ +VMM: 0.642 +KVM: 0.631 +user-level: 0.616 +TCG: 0.609 +ppc: 0.592 +vnc: 0.589 +mistranslation: 0.588 +risc-v: 0.561 +virtual: 0.558 +peripherals: 0.554 +graphic: 0.542 +files: 0.537 +hypervisor: 0.537 +device: 0.518 +architecture: 0.517 +PID: 0.514 +network: 0.513 +arm: 0.511 +socket: 0.508 +x86: 0.506 +permissions: 0.504 +register: 0.503 +debug: 0.492 +performance: 0.488 +assembly: 0.476 +kernel: 0.476 +semantic: 0.475 +boot: 0.452 +i386: 0.451 + +Failed to compile QEMU 7.0.0 source code. recipe for target 'run-ninja' failed. +Description of problem: +Failed to compiling the download QEMU 7.0.0 source code. It seems to be due to something wrong with ninja. +The followings are error logs after executing command "make -j$(nproc)": + +changing dir to build for make ""... +make[1]: Entering directory '/home/liangke/os-env/qemu-7.0.0/build' +/usr/bin/ninja build.ninja && touch build.ninja.stamp +**ninja: no work to do.** +... +... +... +[1350/2396] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o +**FAILED: libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o** +cc -m64 -mcx16 -Ilibqemu-riscv64-softmmu.fa.p -I. -I.. -Itarget/riscv -I../target/riscv -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/liangke/os-env/qemu-7.0.0/linux-headers -isystem linux-headers -iquote . -iquote /home/liangke/os-env/qemu-7.0.0 -iquote /home/liangke/os-env/qemu-7.0.0/include -iquote /home/liangke/os-env/qemu-7.0.0/disas/libvixl -iquote /home/liangke/os-env/qemu-7.0.0/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="riscv64-softmmu-config-target.h"' '-DCONFIG_DEVICES="riscv64-softmmu-config-devices.h"' -MD -MQ libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o -MF libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o.d -o libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o -c ../target/riscv/translate.c +**cc: fatal error: Killed signal terminated program cc1** +**compilation terminated.** +**ninja: build stopped: subcommand failed.** +**Makefile:163: recipe for target 'run-ninja' failed** +**make[1]: *** [run-ninja] Error 1** +make[1]: Leaving directory '/home/liangke/os-env/qemu-7.0.0/build' +**GNUmakefile:10: recipe for target 'all' failed** +**make: *** [all] Error 2** +Steps to reproduce: +1. cd qemu-7.0.0 source code folder; +2. ./configure --target-list=riscv64-softmmu,riscv64-linux-user; +3. make -j$(nproc) +Additional information: +1. I downloaded the source code from https://download.qemu.org/qemu-7.0.0.tar.xz. +2. my compiling prerequisites: +sudo apt install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev \ + gawk build-essential bison flex texinfo gperf libtool patchutils bc ninja-build \ + zlib1g-dev libexpat-dev pkg-config libglib2.0-dev libpixman-1-dev git tmux python3 +3. Found ninja-1.8.2 at /usr/bin/ninja diff --git a/results/classifier/118/none/1906180 b/results/classifier/118/none/1906180 new file mode 100644 index 00000000..22546b5e --- /dev/null +++ b/results/classifier/118/none/1906180 @@ -0,0 +1,66 @@ +graphic: 0.757 +device: 0.739 +x86: 0.731 +boot: 0.559 +user-level: 0.535 +architecture: 0.533 +peripherals: 0.494 +kernel: 0.438 +KVM: 0.437 +i386: 0.436 +risc-v: 0.427 +files: 0.400 +semantic: 0.380 +permissions: 0.368 +network: 0.367 +socket: 0.367 +performance: 0.352 +ppc: 0.335 +register: 0.321 +vnc: 0.310 +arm: 0.294 +PID: 0.286 +mistranslation: 0.270 +debug: 0.259 +TCG: 0.217 +VMM: 0.200 +virtual: 0.161 +hypervisor: 0.156 +assembly: 0.077 + +Keyboard keys get stuck + +Keyboard keys get "stuck" quite often, on certain Linux guests at least, and start repeating themselves until another key is pressed. This is especially noticeable with key combinations like Ctrl+V for pasting. When it happens, you get the pasted text and vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv... + +This bug has been present for quite some time but I don't remember any specific version that had it first. + + +QEMU version: 5.1.0 +Guest: Debian stable 64-bit (live), with Gnome desktop (may occur with other Linux guests too) +Host: Arch Linux with KDE desktop (X11, wayland not tested); both default and hardened kernel tested + +QEMU start command: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom debian.iso -boot d -vga std + +Which user interface do you use? SDL? GTK? VNC? + +I've encountered this with GTK interface. I'll test if this occurs with SDL too. + +Can you confirm whether you are executing QEMU on your local desktop/laptop machine, or remotely over SSH with X11-forwarding, or over a remote VNC server, etc ? In the remote cases stuck keys is somewhat of a known problem especially if latency is bad + +I'm running it on local desktop. + +I've been testing this with SDL interface but haven't yet encountered this bug. So this might be specific to the GTK interface. + +[Expired for QEMU because there has been no activity for 60 days.] + +This might be less common in 5.2.0 but I have still had some strange issues with keyboard. + + +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/294 + + diff --git a/results/classifier/118/none/1906516 b/results/classifier/118/none/1906516 new file mode 100644 index 00000000..334bc5b4 --- /dev/null +++ b/results/classifier/118/none/1906516 @@ -0,0 +1,154 @@ +vnc: 0.799 +VMM: 0.761 +ppc: 0.735 +TCG: 0.724 +architecture: 0.712 +permissions: 0.697 +risc-v: 0.690 +assembly: 0.675 +KVM: 0.667 +peripherals: 0.658 +user-level: 0.648 +virtual: 0.635 +graphic: 0.629 +performance: 0.610 +files: 0.591 +PID: 0.591 +arm: 0.590 +socket: 0.577 +debug: 0.573 +hypervisor: 0.571 +mistranslation: 0.563 +network: 0.530 +device: 0.529 +register: 0.525 +semantic: 0.492 +kernel: 0.465 +boot: 0.455 +x86: 0.435 +i386: 0.312 + +[RISCV] sfence.vma need to end the translation block + +QEMU emulator version 5.0.0 + +sfence.vma will flush the tlb, so after this instruction, the translation block should be end. The following code will only work in single step mode: +``` +relocate: + li a0, OFFSET + + la t0, 1f + add t0, t0, a0 + csrw stvec, t0 + + la t0, early_pgtbl + srl t0, t0, PAGE_SHIFT + li t1, SATP_SV39 + or t0, t1, t0 + + csrw satp, t0 +1: + sfence.vma + la t0, trap_s + csrw stvec, t0 + ret +``` + +In this code, I want to relocate pc to virtual address with the OFFSET prefix, before writing to satp, pc run at physic address, stvec has been set a label 1 with a virtual prefix and virtual address has been mapping in early_pgtbl, after writing satp, there will throw a page fault, and pc will set to virtual address of label 1. + +The problem is that, in this situation, the translation block will not end after sfence.vma, and stvec will be set to trap_s, + +``` +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000dc: 00a080b3 add ra,ra,a0 +0x00000000800000e0: 00007297 auipc t0,28672 # 0x800070e0 +0x00000000800000e4: f2028293 addi t0,t0,-224 +0x00000000800000e8: 00c2d293 srli t0,t0,12 +0x00000000800000ec: fff0031b addiw t1,zero,-1 +0x00000000800000f0: 03f31313 slli t1,t1,63 +0x00000000800000f4: 005362b3 or t0,t1,t0 +0x00000000800000f8: 18029073 csrrw zero,satp,t0 + +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000fc: 12000073 sfence.vma zero,zero +0x0000000080000100: 00000297 auipc t0,0 # 0x80000100 +0x0000000080000104: 1c828293 addi t0,t0,456 +0x0000000080000108: 10529073 csrrw zero,stvec,t0 + +riscv_raise_exception: 12 +riscv_raise_exception: 12 +riscv_raise_exception: 12 +riscv_raise_exception: 12 +... +``` + +So, the program will crash, and the program will work in single step mode: +``` +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000f8: 18029073 csrrw zero,satp,t0 + +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000fc: 12000073 sfence.vma zero,zero + +riscv_raise_exception: 12 +---------------- +IN: +Priv: 1; Virt: 0 +0xffffffff800000fc: 12000073 sfence.vma zero,zero + +---------------- +IN: +Priv: 1; Virt: 0 +0xffffffff80000100: 00000297 auipc t0,0 # 0xffffffff80000100 + +``` +The pc will set to label 1, instead of trap_s. + +I try to patch the code in fence.i in trans_rvi.inc.c to sfence.vma: +``` + tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn); + exit_tb(ctx); + ctx->base.is_jmp = DISAS_NORETURN; +``` +This codes can help to end the tranlate block, since I'm not a qemu guy, I'm not sure if this is a corret method. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/none/1906536 b/results/classifier/118/none/1906536 new file mode 100644 index 00000000..edd3b806 --- /dev/null +++ b/results/classifier/118/none/1906536 @@ -0,0 +1,160 @@ +graphic: 0.647 +user-level: 0.499 +PID: 0.487 +register: 0.486 +mistranslation: 0.458 +permissions: 0.455 +TCG: 0.449 +VMM: 0.428 +kernel: 0.426 +hypervisor: 0.423 +debug: 0.408 +KVM: 0.407 +risc-v: 0.402 +device: 0.401 +arm: 0.393 +semantic: 0.385 +vnc: 0.371 +architecture: 0.370 +assembly: 0.363 +files: 0.342 +performance: 0.335 +socket: 0.330 +ppc: 0.321 +virtual: 0.303 +network: 0.297 +peripherals: 0.286 +boot: 0.272 +x86: 0.242 +i386: 0.077 + +Unable to set SVE VL to 1024 bits or above since 7b6a2198 + +Prior to 7b6a2198e71794c851f39ac7a92d39692c786820, the QEMU option sve-max-vq could be used to set the vector length of the implementation. This is useful (among other reasons) for testing software compiled with a fixed SVE vector length. Since this commit, the vector length is capped at 512 bits. + +To reproduce the issue: + +$ cat rdvl.s +.global _start +_start: + rdvl x0, #1 + asr x0, x0, #4 + mov x8, #93 // exit + svc #0 +$ aarch64-linux-gnu-as -march=armv8.2-a+sve rdvl.s -o rdvl.o +$ aarch64-linux-gnu-ld rdvl.o +$ for vl in 1 2 4 8 16; do ../build-qemu/aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=$vl a.out; echo $?; done +1 +2 +4 +4 +4 + +For a QEMU built prior to the above revision, we get the output: +1 +2 +4 +8 +16 + +as expected. It seems that either the old behavior should be restored, or there should be an option to force a higher vector length? + +Hi Alex, + +This commit mentions: + + The Linux kernel chooses the default of 64 bytes for SVE registers on + the basis that it is the largest size on known hardware that won't + grow the signal frame. We still honour the sve-max-vq property and + userspace can expand the number of lanes by calling PR_SVE_SET_VL. + +Expand the number of lanes by calling PR_SVE_SET_VL works for me: + + .global _start +_start: + mov x0, 50 // PR_SVE_SET_VL + mov x1, 256 // 16 lanes + mov x8, #167 // prctl + svc #0 + + rdvl x0, #1 + asr x0, x0, #4 + mov x8, #93 // exit + svc #0 + +$ for vl in 1 2 4 8 16; do qemu-aarch64 -strace -cpu max,sve-max-vq=$vl a.out; echo $?; done +1383321 prctl(50,256,0,0,0,0) = 16 +1383321 exit(1) +1 +1383323 prctl(50,256,0,0,0,0) = 32 +1383323 exit(2) +2 +1383325 prctl(50,256,0,0,0,0) = 64 +1383325 exit(4) +4 +1383327 prctl(50,256,0,0,0,0) = 128 +1383327 exit(8) +8 +1383329 prctl(50,256,0,0,0,0) = 256 +1383329 exit(16) +16 + +Hi Philippe, + +I'm aware of the prctl workaround. + +It seems to me that this is clearly a regression in functionality. Prior to the change, I could test any executable with any vector length without having to modify the executable. Now I have to insert a prctl to test with 1024 or 2048-bit SVE vectors? + +Moreover, with this change, it's no longer possible to have the wider VL inherited across exec() to another QEMU instance. + +Yes, we should by default do what the Linux kernel does, but we should also provide a mechanism for allowing guest software to use a higher vector length than that kernel default. On a real kernel you can do that by either setting the /proc/sys/abi/sve_default_vector_length, or by having process A make the prctl() to change vector length and then exec process B that inherits that increased vector length. Neither of those mechanisms work for QEMU linux-user, so we should provide some other mechanism instead. + + +Are there any other examples of where linux-user tries to preserve execution environment details over an execve? + +I don't think we currently do have anything else we try to preserve over execve-to-maybe-another-QEMU-emulated-process, no. The other approach of "provide a config knob equivalent to /proc/sys/abi/sve_default_vector_length" is probably simpler. + + +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.] + +Whoops, this shouldn't have got expired. + + + +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/482 + + diff --git a/results/classifier/118/none/1906948 b/results/classifier/118/none/1906948 new file mode 100644 index 00000000..572b942d --- /dev/null +++ b/results/classifier/118/none/1906948 @@ -0,0 +1,90 @@ +socket: 0.800 +x86: 0.789 +PID: 0.760 +architecture: 0.741 +device: 0.722 +boot: 0.712 +graphic: 0.682 +arm: 0.643 +peripherals: 0.624 +ppc: 0.573 +semantic: 0.568 +user-level: 0.551 +i386: 0.497 +hypervisor: 0.489 +permissions: 0.474 +risc-v: 0.468 +KVM: 0.452 +files: 0.452 +register: 0.428 +performance: 0.419 +kernel: 0.399 +network: 0.393 +vnc: 0.381 +assembly: 0.356 +virtual: 0.344 +mistranslation: 0.314 +VMM: 0.295 +TCG: 0.293 +debug: 0.232 + +Enabling OpenGL for GUI doesn't work on old laptop + +QEMU start command is: + +qemu-system-x86_64 -enable-kvm -m 2G -cpu host -smp 2 -cdrom ./linuxmint-20-mate-64bit.iso -boot d -vga virtio -soundhw hda -display gtk,gl=on + + +and QEMU crashes immediately on startup and gives these error messages: + + +qemu_gl_create_compile_shader: compile vertex error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile fragment error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile vertex error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile fragment error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + + +If I remove "gl=on" it will boot. Does this just mean that this hardware is too old to run QEMU with OpenGL enabled in GUI, or is this a bug? + +Host OS is Debian 10, computer is a Lenovo laptop with Core i5-520M CPU and its integrated Intel HD graphics GPU. + +QEMU version is 3.1.0 from Debian repositories. + +The QEMU project does not support version 3.1 anymore. Can you either please report this to the Debian bug tracker instead, or check whether the problem is still reproducible with the latest version of QEMU (v5.2 will be likely released tomorrow)? + +I installed Qemu 5.0.0 from Debian Buster backports and I still get this error. + + + +qemu_gl_create_compile_shader: compile vertex error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile fragment error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile vertex error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + +qemu_gl_create_compile_shader: compile fragment error +0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES + + +[Expired for QEMU because there has been no activity for 60 days.] + +Still happens in 5.2.0 (Debian 1:5.2+dfsg-3~bpo10+1). Is this just due to hardware which is too old? + + +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/296 + + |