diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1906 | 49 | ||||
| -rw-r--r-- | results/classifier/108/other/1906156 | 70 | ||||
| -rw-r--r-- | results/classifier/108/other/1906180 | 51 | ||||
| -rw-r--r-- | results/classifier/108/other/1906184 | 76 | ||||
| -rw-r--r-- | results/classifier/108/other/1906295 | 39 | ||||
| -rw-r--r-- | results/classifier/108/other/1906463 | 38 | ||||
| -rw-r--r-- | results/classifier/108/other/1906516 | 139 | ||||
| -rw-r--r-- | results/classifier/108/other/1906536 | 145 | ||||
| -rw-r--r-- | results/classifier/108/other/1906608 | 65 | ||||
| -rw-r--r-- | results/classifier/108/other/1906905 | 400 | ||||
| -rw-r--r-- | results/classifier/108/other/1906948 | 75 |
11 files changed, 1147 insertions, 0 deletions
diff --git a/results/classifier/108/other/1906 b/results/classifier/108/other/1906 new file mode 100644 index 00000000..4c478486 --- /dev/null +++ b/results/classifier/108/other/1906 @@ -0,0 +1,49 @@ +KVM: 0.631 +vnc: 0.589 +graphic: 0.542 +files: 0.537 +device: 0.518 +PID: 0.514 +network: 0.513 +socket: 0.508 +permissions: 0.504 +debug: 0.492 +performance: 0.488 +other: 0.484 +semantic: 0.475 +boot: 0.452 + +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/108/other/1906156 b/results/classifier/108/other/1906156 new file mode 100644 index 00000000..5e019eac --- /dev/null +++ b/results/classifier/108/other/1906156 @@ -0,0 +1,70 @@ +semantic: 0.830 +debug: 0.758 +PID: 0.755 +performance: 0.745 +permissions: 0.732 +device: 0.730 +boot: 0.689 +other: 0.671 +graphic: 0.635 +socket: 0.607 +files: 0.559 +vnc: 0.531 +KVM: 0.521 +network: 0.423 + +Host OS Reboot Required, for Guest kext to Load (Fully) + +Hi, + +Finding this one a bit odd, but I am loading a driver (kext) in a macOS guest ... and it works, on the first VM (domain) startup after a full / clean host OS boot (or reboot). However, if I even reboot the guest OS, then the driver load fails => can be "corrected" by a full host OS reboot (which seems very extreme). + +Is this a known issue, and/or is there a workaround? + +FYI, running, +QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.1) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +This is for a macOS guest, on a Linux host. + +Thanks! + +Hi! Seems like you're using the QEMU from your distro, so should this be a bug report against Ubuntu's QEMU instead? Otherwise, can you please try again with the latest upstream version of QEMU (currently an RC of v5.2)? You certainly also need to provide more information, e.g. what kind of error message do you see, how often did you try (maybe it's just an intermittent problem and it sometimes also works without rebooting the host), etc. + +Sure, will do (upstream version). Is there a preferred way to do it? Meaning ... build locally, or install from some repository? + +Thanks! + +The QEMU project only provides the source tarballs, so builing locally is certainly the preferred way to test. + +That makes sense, no issue at all. So I cloned from git (v5.2.0-rc3), built, installed. All good so far :-). But then I tried to modify the "emulator" in virt-manager, point to this build => I get the error, + +Error changing VM configuration: internal error: Failed to start QEMU binary /usr/local/bin/qemu-system-x86_64 for probing: libvirt: error : cannot execute binary /usr/local/bin/qemu-system-x86_64: Permission denied + +Thoughts? I have run into this before (without finding a fix sadly) - thinking it's apparmor related somehow? + +Thanks! + +Sorry for the delay on updating this - but pulling my hair out (and I'm short enough of that already ... LOL). I can't get Ubuntu to let me run the custom qemu executable. Really is looking like apparmor. Fighting with that, but struggling to have it let me run it :-(. + +Thanks. + +My apologies, but I'm somewhat stuck here :-(. Trying to run the latest (upstream) version of QEMU, but no luck getting it to execute. I even tried setting securit_driver = "none", as captured here, +https://gitlab.com/apparmor/apparmor/-/wikis/Libvirt + +But no luck. Open to any suggestions. + +Thanks! + +OK, found my issue! :-). Still a bit odd, but virt-manager complaints about the custom QEMU executable => but virsh still works. So I did get the VM running, with, +QEMU emulator version 5.1.93 (v5.2.0-rc3) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +But it still performed the same. I also checked the xml file (VM definition), and made sure to change the machine to the most current version (pc-q35-5.2), but also no improvement. + +Other things to try? + +Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1906180 b/results/classifier/108/other/1906180 new file mode 100644 index 00000000..29dbf3f6 --- /dev/null +++ b/results/classifier/108/other/1906180 @@ -0,0 +1,51 @@ +graphic: 0.757 +device: 0.739 +other: 0.601 +boot: 0.559 +KVM: 0.437 +files: 0.400 +semantic: 0.380 +permissions: 0.368 +network: 0.367 +socket: 0.367 +performance: 0.352 +vnc: 0.310 +PID: 0.286 +debug: 0.259 + +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/108/other/1906184 b/results/classifier/108/other/1906184 new file mode 100644 index 00000000..d06e0449 --- /dev/null +++ b/results/classifier/108/other/1906184 @@ -0,0 +1,76 @@ +graphic: 0.897 +other: 0.869 +socket: 0.853 +KVM: 0.851 +network: 0.831 +device: 0.821 +PID: 0.793 +boot: 0.774 +vnc: 0.759 +performance: 0.747 +permissions: 0.740 +files: 0.713 +semantic: 0.700 +debug: 0.689 + +Lots of stuttering/crackling in guest sound + +When listening to music (e.g. with VLC) or watching Youtube on the guest, there's lots of stuttering and crackling in the sound. + + +Tested with the following QEMU start commands: + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda -display sdl,gl=on + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display sdl + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display gtk + + +If I use the following command (QXL graphics, "remote" access via SPICE over unix socket), stuttering is not completely gone but MUCH less annoying: + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing + +and this command for accessing the VM: +remote-viewer spice+unix:///tmp/vm_spice.socket + + + +Guest: Kubuntu 20.04 64-bit (live), but occurs with many other as well +Host: Arch Linux, with KDE desktop +CPU: Intel Xeon E3-1230v2 (4 cores + hyperthreading) +RAM: 16 GB +GPU: Nvidia GTX 980 Ti + +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/108/other/1906295 b/results/classifier/108/other/1906295 new file mode 100644 index 00000000..639deffc --- /dev/null +++ b/results/classifier/108/other/1906295 @@ -0,0 +1,39 @@ +other: 0.882 +device: 0.861 +performance: 0.703 +semantic: 0.675 +graphic: 0.646 +debug: 0.624 +network: 0.587 +permissions: 0.581 +PID: 0.565 +vnc: 0.538 +files: 0.534 +socket: 0.516 +KVM: 0.440 +boot: 0.402 + +Implementation of exclusive monitor in ARM + +Hi + +I refer to the implementation of exclusive monitor in ARM32. For instruction like STREX Rx,Ry,[Rz], we need to check whether the address [Rz] is in exclusive state. If not, we set the value Rx as 1 without doing the store operation. However, I noticed that QEMU will not check whether the address that Rz points to is a legal address or not. If the value of Rz is 0x0 but it is not in exclusive state. QEMU will set Rx as 1 and continue to execute the following instructions. + +However, physical devices will check the value of Rz. If Rz is an illegal address (e.g., 0x0), a SIGSEGV signal will be raised even the address is not in exclusive state. I searched many documentation about ARM and it seems that manual of ARM specification does not specify the implementation of exclusive monitor in detail. I am not sure which one is the right behavior. +Should QEMU add this check? This might not be a mistake. However, should it be better if QEMU has the same behavior as a physical device? Feel free if you need a testcase. Many thanks + +Regards +Muhui + +QEMU's load/store exclusive implementation is known to not be architecturally compliant. Most notably, it works on virtual addresses and the architecture specifies that exclusives are supposed to work on physical addresses. We provide a "good enough for what real code (not weird test cases) needs" implementation. + +However, in this specific case, we're within the architectural requirements. In the ARMv8A Arm ARM (DDI0487F.c) the pseudocode AArch32.ExclusiveMonitorsPass() function has this comment: + +// It is IMPLEMENTATION DEFINED whether the detection of memory aborts happens +// before or after the check on the local Exclusives monitor. As a result a failure +// of the local monitor can occur on some implementations even if the memory +// access would give a memory about. + +In other words, it's up to the implementation whether it detects and reports the invalid address first. QEMU's implementation chooses not to. + + diff --git a/results/classifier/108/other/1906463 b/results/classifier/108/other/1906463 new file mode 100644 index 00000000..caf8592f --- /dev/null +++ b/results/classifier/108/other/1906463 @@ -0,0 +1,38 @@ +device: 0.792 +semantic: 0.558 +graphic: 0.434 +other: 0.433 +performance: 0.423 +network: 0.413 +socket: 0.369 +vnc: 0.345 +PID: 0.316 +boot: 0.306 +debug: 0.280 +permissions: 0.174 +KVM: 0.117 +files: 0.062 + +"-device help" does not report all devices + +-device help doesn't report all devices. +E.g., devices that are instantiated by a board don't get printed in part because they don't exist when "-device help" is processed. As an experiment I deferred processing of "-device help" as long as possible and some devices were still not printed, so there's more going on here. + +QEMU commit hash: 944fdc5e27a5b5adbb765891e8e70e88ba9a00ec + +Repro: +$ configure --target-list=arm-softmmu +$ make +$ ./qemu-system-arm -device help | grep npcm7xx +<empty> + +I'd expect to see things like npcm7xx-rng in the output. + +I can imagine enumerating board-provided devices is a challenge. +Still, it'd be really nice if "-device help" printed them, and having +"-device $driver,help" work as well. + +This works as intended, see Markus' reply here: +https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg00337.html + + diff --git a/results/classifier/108/other/1906516 b/results/classifier/108/other/1906516 new file mode 100644 index 00000000..1c6ea98b --- /dev/null +++ b/results/classifier/108/other/1906516 @@ -0,0 +1,139 @@ +vnc: 0.799 +permissions: 0.697 +KVM: 0.667 +graphic: 0.629 +performance: 0.610 +files: 0.591 +PID: 0.591 +socket: 0.577 +debug: 0.573 +other: 0.567 +network: 0.530 +device: 0.529 +semantic: 0.492 +boot: 0.455 + +[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/108/other/1906536 b/results/classifier/108/other/1906536 new file mode 100644 index 00000000..816bd143 --- /dev/null +++ b/results/classifier/108/other/1906536 @@ -0,0 +1,145 @@ +graphic: 0.647 +PID: 0.487 +other: 0.457 +permissions: 0.455 +debug: 0.408 +KVM: 0.407 +device: 0.401 +semantic: 0.385 +vnc: 0.371 +files: 0.342 +performance: 0.335 +socket: 0.330 +network: 0.297 +boot: 0.272 + +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/108/other/1906608 b/results/classifier/108/other/1906608 new file mode 100644 index 00000000..52596ac1 --- /dev/null +++ b/results/classifier/108/other/1906608 @@ -0,0 +1,65 @@ +device: 0.855 +other: 0.831 +performance: 0.826 +graphic: 0.783 +PID: 0.721 +semantic: 0.697 +permissions: 0.661 +files: 0.625 +network: 0.620 +socket: 0.504 +debug: 0.498 +vnc: 0.483 +boot: 0.369 +KVM: 0.354 + + [Feature request]For some ehci controller, qemu should implement using portsc[26-27] to detect the speed of device. + +for some ehci controller ,for example ehci controller on fsl_imx6,it using portsc[26-27] to decide a full speed device or high speed device was connected, hub-ehci.c should set the portsc[26-27] to return the right speed. + +line:1001 in hub-ehci.c + if (dev && dev->attached && (dev->speedmask & USB_SPEED_MASK_HIGH)) { + val |= PORTSC_PED; + } + +below is the spec for fsl_imx6 USB PART. +PORTSC:27–26 :PSPD +Port Speed - Read Only. +This register field indicates the speed at which the port is operating. +00 Full Speed +01 Low Speed +10 High Speed +11 Undefined + +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/108/other/1906905 b/results/classifier/108/other/1906905 new file mode 100644 index 00000000..96c0e508 --- /dev/null +++ b/results/classifier/108/other/1906905 @@ -0,0 +1,400 @@ +graphic: 0.899 +other: 0.882 +permissions: 0.870 +debug: 0.859 +semantic: 0.844 +vnc: 0.837 +device: 0.835 +KVM: 0.831 +performance: 0.826 +boot: 0.816 +PID: 0.787 +network: 0.769 +socket: 0.750 +files: 0.691 + +qemu-system-sparc stucked while booting using ss20_v2.25_rom + +I cannot boot up OBP using the current (5.1) version of qemu with ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However using the previous version from 2015 I can successfully both up the OBP. + +qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic + +Power-ON Reset + +(*hang) + +regards +Yap KV + +I have just compiled a few version from source code: + +4.1.1 worked: able to boot up with -bios ss20_v2.25.rom +5.0.0 worked: able to boot up with -bios ss20_v2.25.rom +5.1.0 not working. Stuck after "Power-On Reset" + +SS5.bin worked for 5.1.0 + + +Per the "NCR89C105 Chip Specification" referenced in the header: + + Chip-level Address Map + + ------------------------------------------------------------------ + | 1D0 0000 -> | Counter/Timers | W,D | + | 1DF FFFF | | | + ... + + The address map indicated the allowed accesses at each address. + [...] W indicates a word access, and D indicates a double-word + access. + +The SLAVIO timer controller is implemented expecting 32-bit accesses. +Commit a3d12d073e1 restricted the memory accesses to 32-bit, while +the device allows 64-bit accesses. + +This was not an issue until commit 5d971f9e67 which reverted +("memory: accept mismatching sizes in memory_region_access_valid"). + +Fix by renaming .valid MemoryRegionOps as .impl, and add the valid +access range (W -> 4, D -> 8). + +Since commit 21786c7e598 ("memory: Log invalid memory accesses") +this class of bug can be quickly debugged displaying 'guest_errors' +accesses, as: + + $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors + + Power-ON Reset + Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4) + + $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S + (qemu) info mtree + address-space: memory + 0000000000000000-ffffffffffffffff (prio 0, i/o): system + ... + 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1 + ^^^^^^^^^ ^^^^^^^ + \ memory region base address and name / + + (qemu) info qtree + bus: main-system-bus + dev: slavio_timer, id "" <-- device type name + gpio-out "sysbus-irq" 17 + num_cpus = 1 (0x1) + mmio 0000000ff1310000/0000000000000014 + mmio 0000000ff1300000/0000000000000010 <--- base address + mmio 0000000ff1301000/0000000000000010 + mmio 0000000ff1302000/0000000000000010 + ... + +Reported-by: Yap KV <email address hidden> +Buglink: https://bugs.launchpad.net/bugs/1906905 +Fixes: a3d12d073e1 ("slavio_timer: convert to memory API") +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Cc: Benoit Canet <email address hidden> +Cc: <email address hidden> +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- + hw/timer/slavio_timer.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c +index 5b2d20cb6a5..03e33fc5926 100644 +--- a/hw/timer/slavio_timer.c ++++ b/hw/timer/slavio_timer.c +@@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = { + .write = slavio_timer_mem_writel, + .endianness = DEVICE_NATIVE_ENDIAN, + .valid = { ++ .min_access_size = 4, ++ .max_access_size = 8, ++ }, ++ .impl = { + .min_access_size = 4, + .max_access_size = 4, + }, +-- +2.26.2 + + + +On 05/12/2020 15:09, Philippe Mathieu-Daudé wrote: + +> Per the "NCR89C105 Chip Specification" referenced in the header: +> +> Chip-level Address Map +> +> ------------------------------------------------------------------ +> | 1D0 0000 -> | Counter/Timers | W,D | +> | 1DF FFFF | | | +> ... +> +> The address map indicated the allowed accesses at each address. +> [...] W indicates a word access, and D indicates a double-word +> access. +> +> The SLAVIO timer controller is implemented expecting 32-bit accesses. +> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while +> the device allows 64-bit accesses. +> +> This was not an issue until commit 5d971f9e67 which reverted +> ("memory: accept mismatching sizes in memory_region_access_valid"). +> +> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid +> access range (W -> 4, D -> 8). +> +> Since commit 21786c7e598 ("memory: Log invalid memory accesses") +> this class of bug can be quickly debugged displaying 'guest_errors' +> accesses, as: +> +> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors +> +> Power-ON Reset +> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4) +> +> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S +> (qemu) info mtree +> address-space: memory +> 0000000000000000-ffffffffffffffff (prio 0, i/o): system +> ... +> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1 +> ^^^^^^^^^ ^^^^^^^ +> \ memory region base address and name / +> +> (qemu) info qtree +> bus: main-system-bus +> dev: slavio_timer, id "" <-- device type name +> gpio-out "sysbus-irq" 17 +> num_cpus = 1 (0x1) +> mmio 0000000ff1310000/0000000000000014 +> mmio 0000000ff1300000/0000000000000010 <--- base address +> mmio 0000000ff1301000/0000000000000010 +> mmio 0000000ff1302000/0000000000000010 +> ... +> +> Reported-by: Yap KV <email address hidden> +> Buglink: https://bugs.launchpad.net/bugs/1906905 +> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API") +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> Cc: Benoit Canet <email address hidden> +> Cc: <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> hw/timer/slavio_timer.c | 4 ++++ +> 1 file changed, 4 insertions(+) +> +> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c +> index 5b2d20cb6a5..03e33fc5926 100644 +> --- a/hw/timer/slavio_timer.c +> +++ b/hw/timer/slavio_timer.c +> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = { +> .write = slavio_timer_mem_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, + +I don't really use the proprietary Sun ROMs here, but the fix looks good to me: + +Reviewed-by: Mark Cave-Ayland <email address hidden> + +It's probably also worth a CC to qemu-stable to try and also get this into 5.1.1 to +accompany the related TCX issues. + + +ATB, + +Mark. + + +ping? + +On 12/5/20 4:09 PM, Philippe Mathieu-Daudé wrote: +> Per the "NCR89C105 Chip Specification" referenced in the header: +> +> Chip-level Address Map +> +> ------------------------------------------------------------------ +> | 1D0 0000 -> | Counter/Timers | W,D | +> | 1DF FFFF | | | +> ... +> +> The address map indicated the allowed accesses at each address. +> [...] W indicates a word access, and D indicates a double-word +> access. +> +> The SLAVIO timer controller is implemented expecting 32-bit accesses. +> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while +> the device allows 64-bit accesses. +> +> This was not an issue until commit 5d971f9e67 which reverted +> ("memory: accept mismatching sizes in memory_region_access_valid"). +> +> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid +> access range (W -> 4, D -> 8). +> +> Since commit 21786c7e598 ("memory: Log invalid memory accesses") +> this class of bug can be quickly debugged displaying 'guest_errors' +> accesses, as: +> +> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors +> +> Power-ON Reset +> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4) +> +> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S +> (qemu) info mtree +> address-space: memory +> 0000000000000000-ffffffffffffffff (prio 0, i/o): system +> ... +> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1 +> ^^^^^^^^^ ^^^^^^^ +> \ memory region base address and name / +> +> (qemu) info qtree +> bus: main-system-bus +> dev: slavio_timer, id "" <-- device type name +> gpio-out "sysbus-irq" 17 +> num_cpus = 1 (0x1) +> mmio 0000000ff1310000/0000000000000014 +> mmio 0000000ff1300000/0000000000000010 <--- base address +> mmio 0000000ff1301000/0000000000000010 +> mmio 0000000ff1302000/0000000000000010 +> ... +> +> Reported-by: Yap KV <email address hidden> +> Buglink: https://bugs.launchpad.net/bugs/1906905 +> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API") +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> Cc: Benoit Canet <email address hidden> +> Cc: <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> hw/timer/slavio_timer.c | 4 ++++ +> 1 file changed, 4 insertions(+) +> +> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c +> index 5b2d20cb6a5..03e33fc5926 100644 +> --- a/hw/timer/slavio_timer.c +> +++ b/hw/timer/slavio_timer.c +> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = { +> .write = slavio_timer_mem_writel, +> .endianness = DEVICE_NATIVE_ENDIAN, +> .valid = { +> + .min_access_size = 4, +> + .max_access_size = 8, +> + }, +> + .impl = { +> .min_access_size = 4, +> .max_access_size = 4, +> }, +> + + +On 05/01/2021 11:06, Philippe Mathieu-Daudé wrote: + +> ping? +> +> On 12/5/20 4:09 PM, Philippe Mathieu-Daudé wrote: +>> Per the "NCR89C105 Chip Specification" referenced in the header: +>> +>> Chip-level Address Map +>> +>> ------------------------------------------------------------------ +>> | 1D0 0000 -> | Counter/Timers | W,D | +>> | 1DF FFFF | | | +>> ... +>> +>> The address map indicated the allowed accesses at each address. +>> [...] W indicates a word access, and D indicates a double-word +>> access. +>> +>> The SLAVIO timer controller is implemented expecting 32-bit accesses. +>> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while +>> the device allows 64-bit accesses. +>> +>> This was not an issue until commit 5d971f9e67 which reverted +>> ("memory: accept mismatching sizes in memory_region_access_valid"). +>> +>> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid +>> access range (W -> 4, D -> 8). +>> +>> Since commit 21786c7e598 ("memory: Log invalid memory accesses") +>> this class of bug can be quickly debugged displaying 'guest_errors' +>> accesses, as: +>> +>> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors +>> +>> Power-ON Reset +>> Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4) +>> +>> $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S +>> (qemu) info mtree +>> address-space: memory +>> 0000000000000000-ffffffffffffffff (prio 0, i/o): system +>> ... +>> 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1 +>> ^^^^^^^^^ ^^^^^^^ +>> \ memory region base address and name / +>> +>> (qemu) info qtree +>> bus: main-system-bus +>> dev: slavio_timer, id "" <-- device type name +>> gpio-out "sysbus-irq" 17 +>> num_cpus = 1 (0x1) +>> mmio 0000000ff1310000/0000000000000014 +>> mmio 0000000ff1300000/0000000000000010 <--- base address +>> mmio 0000000ff1301000/0000000000000010 +>> mmio 0000000ff1302000/0000000000000010 +>> ... +>> +>> Reported-by: Yap KV <email address hidden> +>> Buglink: https://bugs.launchpad.net/bugs/1906905 +>> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API") +>> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +>> --- +>> Cc: Benoit Canet <email address hidden> +>> Cc: <email address hidden> +>> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +>> --- +>> hw/timer/slavio_timer.c | 4 ++++ +>> 1 file changed, 4 insertions(+) +>> +>> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c +>> index 5b2d20cb6a5..03e33fc5926 100644 +>> --- a/hw/timer/slavio_timer.c +>> +++ b/hw/timer/slavio_timer.c +>> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = { +>> .write = slavio_timer_mem_writel, +>> .endianness = DEVICE_NATIVE_ENDIAN, +>> .valid = { +>> + .min_access_size = 4, +>> + .max_access_size = 8, +>> + }, +>> + .impl = { +>> .min_access_size = 4, +>> .max_access_size = 4, +>> }, + +Looks like I did queue this to my local qemu-sparc branch, but was waiting to see if +there was feedback on the other outstanding SPARC patches before sending a PR. The +patches are all fairly minor, however I would prefer an Ack for the outstanding LEON +patchset first. I'll go chase that one up now. + + +ATB, + +Mark. + + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/62a9b228b5fefe0f9e364d + diff --git a/results/classifier/108/other/1906948 b/results/classifier/108/other/1906948 new file mode 100644 index 00000000..97e3f595 --- /dev/null +++ b/results/classifier/108/other/1906948 @@ -0,0 +1,75 @@ +socket: 0.800 +PID: 0.760 +device: 0.722 +boot: 0.712 +graphic: 0.682 +semantic: 0.568 +permissions: 0.474 +KVM: 0.452 +files: 0.452 +other: 0.439 +performance: 0.419 +network: 0.393 +vnc: 0.381 +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 + + |