diff options
Diffstat (limited to 'results/classifier/118/ppc')
36 files changed, 2404 insertions, 0 deletions
diff --git a/results/classifier/118/ppc/1063807 b/results/classifier/118/ppc/1063807 new file mode 100644 index 00000000..0456b42d --- /dev/null +++ b/results/classifier/118/ppc/1063807 @@ -0,0 +1,103 @@ +ppc: 0.874 +KVM: 0.843 +permissions: 0.842 +vnc: 0.832 +graphic: 0.818 +debug: 0.813 +x86: 0.794 +TCG: 0.791 +boot: 0.773 +register: 0.773 +device: 0.772 +virtual: 0.772 +files: 0.767 +mistranslation: 0.762 +PID: 0.746 +peripherals: 0.746 +assembly: 0.746 +arm: 0.729 +semantic: 0.727 +performance: 0.726 +risc-v: 0.724 +kernel: 0.714 +architecture: 0.712 +user-level: 0.699 +network: 0.684 +VMM: 0.680 +hypervisor: 0.673 +socket: 0.630 +i386: 0.317 + +KVM crashes when booting a PointSec encrypted Windows 7 + +Hi all, + +KVM crashes each time the VM boots after installing PointSec. + +Steps to reproduce are: +1) install win7 64bits +2) install PointSec FDE (Full Disk Encryption => http://www.checkpoint.com/products/full-disk-encryption/index.html) +3) regardless any other qemu parameters, one gets a "KVM internal error. Suberror: 1 / emulation failure" error message and a qemu dump like this one: + +KVM internal error. Suberror: 1 +emulation failure +EAX=00000130 EBX=00000000 ECX=00014000 EDX=00050000 +ESI=00000000 EDI=00000000 EBP=00008e3f ESP=0001802d +EIP=000006d3 EFL=00017087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0048 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =25a1 00025a10 0000ffff 00009b00 DPL=0 CS16 [-RA] +SS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0130 00300000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 00028050 00001dd8 +IDT= 00029e40 00000188 +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 8e c0 b8 30 01 8e e0 66 b9 00 00 00 00 66 ba 00 00 00 00 <66> 26 67 8b 9a 00 00 05 00 66 64 67 89 1a 66 83 c2 04 66 41 66 81 f9 00 80 01 00 75 e3 0f + + +My system info: +root@RJZ-LNX:/home/rjz# cat /proc/cpuinfo | tail -24 +cpu family : 6 +model : 37 +model name : Intel(R) Core(TM) i5 CPU M 480 @ 2.67GHz +stepping : 5 +microcode : 0x2 +cpu MHz : 1199.000 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 2 +cpu cores : 2 +apicid : 5 +initial apicid : 5 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid +bogomips : 5319.72 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + + + +and qemu (Ubuntu distribution) info is: + +root@RJZ-LNX:/home/rjz# qemu-system-x86_64 --version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + + + +Best regards, +Rolando. + +Since this is very likely rather a KVM kernel bug than a QEMU userspace bug, could you please report it to the KVM mailing list / bug tracker instead (see http://www.linux-kvm.org/page/Bugs)? Thanks! + diff --git a/results/classifier/118/ppc/1128 b/results/classifier/118/ppc/1128 new file mode 100644 index 00000000..24f50f50 --- /dev/null +++ b/results/classifier/118/ppc/1128 @@ -0,0 +1,54 @@ +ppc: 0.896 +graphic: 0.887 +debug: 0.762 +device: 0.733 +TCG: 0.726 +performance: 0.677 +semantic: 0.632 +i386: 0.560 +x86: 0.554 +architecture: 0.524 +assembly: 0.512 +kernel: 0.510 +vnc: 0.499 +PID: 0.483 +risc-v: 0.469 +files: 0.448 +network: 0.436 +socket: 0.432 +KVM: 0.423 +peripherals: 0.397 +permissions: 0.396 +register: 0.388 +VMM: 0.385 +hypervisor: 0.349 +boot: 0.346 +arm: 0.263 +user-level: 0.252 +mistranslation: 0.215 +virtual: 0.202 + +PPC: `spr_write_xer` doesn't set flag bits in `cpu_xer` +Description of problem: +`spr_write_xer()` does not set the `ca`, `ov`, `so`, `ca32`, `ov32` etc. flag bits in the `cpu_xer` variable. + +In fact it copies all bits from the source `GPR` and _excludes_ each flag bit. + +This is not a problem for execution since `spr_read_xer()` gets the flag bits from `cpu_ca/ov/so...` and not from `cpu_xer`. + +Nonetheless it is problem for tools which trace the execution in QEMU (e.g. https://github.com/BinaryAnalysisPlatform/qemu). + +A fix would be to remove the `~` in https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L481 +Steps to reproduce: +Haven't found out yet how to debug QEMU so the TCGv values can be investigated. But in general one need to: + +- Execute a binary which executes something like: +``` +r4 = 0xffffffffffffffff +mtxer r4 +``` +and check the `cpu_xer` value after the `xer` write. + +Checking the debug logs (`in_asm,cpu`) doesn't work, since the `xer` value in the logs is not taken directly from `cpu_xer`. +Additional information: +Code ref: https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L480-L483 diff --git a/results/classifier/118/ppc/1268671 b/results/classifier/118/ppc/1268671 new file mode 100644 index 00000000..6f47b13f --- /dev/null +++ b/results/classifier/118/ppc/1268671 @@ -0,0 +1,83 @@ +ppc: 0.826 +PID: 0.769 +device: 0.722 +graphic: 0.666 +kernel: 0.630 +semantic: 0.615 +architecture: 0.607 +files: 0.586 +vnc: 0.568 +performance: 0.562 +network: 0.555 +hypervisor: 0.535 +risc-v: 0.524 +arm: 0.496 +KVM: 0.492 +socket: 0.488 +register: 0.465 +x86: 0.443 +boot: 0.397 +debug: 0.384 +permissions: 0.365 +TCG: 0.353 +VMM: 0.349 +mistranslation: 0.319 +virtual: 0.299 +user-level: 0.297 +peripherals: 0.247 +i386: 0.222 +assembly: 0.164 + +CentOS guest crashing due to assertion failure in qemu-char.c + +Here is the log in /var/log/libvirt/qemu/centos_heavy.log + +qemu-kvm: /builddir/build/BUILD/qemu-kvm-0.12.1.2/qemu-char.c:630: io_watch_poll_finalize: Assertion `iwp->src == ((void *)0)' failed. +2014-01-13 16:50:31.576+0000: shutting down + +The code it's failing the assertion on has an interesting comment: + + static void io_watch_poll_finalize(GSource *source) + { + /* Due to a glib bug, removing the last reference to a source + * inside a finalize callback causes recursive locking (and a + * deadlock). This is not a problem inside other callbacks, + * including dispatch callbacks, so we call io_remove_watch_poll + * to remove this source. A t this point, iwp->src must + * be NULL, or we would leak it. + * + * This would be solved much more elegantly by child sources, + * but we support older glib versions that do not have them. + */ + IOWatchPoll *iwp = io_watch_poll_from_source(source); + assert(iwp->src == NULL); + } + +------ +CPU Info: + +http://pastebin.com/U7MrzFxK + +-------- + +Relevant RPM versions: + +qemu-kvm-0.12.1.2-2.415.el6_5.3.x86_64 +libvirt-0.10.2-29.el6_5.2.x86_64 + +-------- + +Domain config: + +http://pastebin.com/Nf2VsER8 + +(Note the use of the vmchannels; I believe this is playing a part in this crash) + + + +QEMU 0.12 is completely outdated nowadays ... can you still reproduce this problem with the latest version of QEMU? + +It's a glib bug. It's fixed in RHEL 6.9 beta and in due time the fix will get to CentOS. + +https://bugzilla.redhat.com/show_bug.cgi?id=1212722 + diff --git a/results/classifier/118/ppc/1368791 b/results/classifier/118/ppc/1368791 new file mode 100644 index 00000000..3b54f416 --- /dev/null +++ b/results/classifier/118/ppc/1368791 @@ -0,0 +1,45 @@ +ppc: 0.851 +device: 0.758 +graphic: 0.754 +vnc: 0.590 +semantic: 0.546 +mistranslation: 0.509 +files: 0.475 +socket: 0.466 +i386: 0.463 +PID: 0.461 +architecture: 0.430 +network: 0.411 +arm: 0.375 +TCG: 0.317 +x86: 0.313 +performance: 0.312 +boot: 0.310 +debug: 0.287 +register: 0.285 +risc-v: 0.234 +VMM: 0.231 +peripherals: 0.174 +virtual: 0.162 +user-level: 0.158 +assembly: 0.129 +permissions: 0.101 +hypervisor: 0.096 +KVM: 0.086 +kernel: 0.080 + +qemu build fails on Ubuntu 10.04 LTS since recent pixman changes + +Since commit 0dfa7e30126364c434a48cb37a1a41119e536c2a, the qemu git mainline no longer builds on Ubuntu 10.04 LTS. The build fails with: + + CC ui/input.o +ui/qemu-pixman.c: In function 'qemu_pixelformat_from_pixman': +ui/qemu-pixman.c:42: error: 'PIXMAN_TYPE_RGBA' undeclared (first use in this function) +ui/qemu-pixman.c:42: error: (Each undeclared identifier is reported only once +ui/qemu-pixman.c:42: error: for each function it appears in.) +make: *** [ui/qemu-pixman.o] Error 1 + +Andreas Gustafsson, <email address hidden> + +Since 10.04 is already end-of-life, I'm closing this bug now. If you still have problems with newer versions of Ubuntu, please open a new bug instead. + diff --git a/results/classifier/118/ppc/1579565 b/results/classifier/118/ppc/1579565 new file mode 100644 index 00000000..cebd8c02 --- /dev/null +++ b/results/classifier/118/ppc/1579565 @@ -0,0 +1,116 @@ +ppc: 0.824 +permissions: 0.819 +debug: 0.808 +graphic: 0.806 +virtual: 0.800 +socket: 0.785 +arm: 0.785 +files: 0.780 +semantic: 0.768 +register: 0.761 +peripherals: 0.761 +PID: 0.760 +device: 0.747 +user-level: 0.732 +performance: 0.731 +TCG: 0.731 +vnc: 0.726 +architecture: 0.716 +kernel: 0.706 +risc-v: 0.703 +boot: 0.702 +hypervisor: 0.697 +network: 0.693 +mistranslation: 0.687 +assembly: 0.667 +KVM: 0.662 +VMM: 0.644 +x86: 0.498 +i386: 0.372 + +ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T. + +cont build from last 2.6 rc4 + +~/Downloads/qemu-2.6.0-rc4$ ./configure + +ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T. + You probably need to set PKG_CONFIG_LIBDIR + to point to the right pkg-config files for your + build target + +Os Ubuntu Mate 16.04 PPC64 + +Please try this patch: http://patchwork.ozlabs.org/patch/616440/ + +The problem could also be that your build environment is broken in the way the warning is trying to diagnose (for instance that you have the 32-bit PPC glib development packages installed and not the 64-bit ones.) + + +thanks for the infos +Stefan i will check tomorrow and report. +Peter, yes this is an issue of the powerpc64 of ubuntu/debian the ppc64 libraries are half ported usually i fix changing in the makefile -m32 where -m64 is call i will try to force the flags on configure of qemu too. i will report if success or not. + +Peter just try forcing the cpp flagas with -m32 without success. +On this rc configure dont start build .. +CPPFLAGS="-m32" CFLAGS="-g -O2 -mcpu=e5500 -mno-altivec -mtune=e5500" CXXFLAGS="-m32 -g -O2 -mcpu=e5500 -mno-altivec -mtune=e5500" ./configure --disable-werror + +ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T. + You probably need to set PKG_CONFIG_LIBDIR + to point to the right pkg-config files for your + build target + +will check Stefan parch if something change and reports. + +Thanks + +If you can still see the bug after applying Stefan's patch, please attach the config.log file generated by configure + +Ok Daniel, will check and report. +note usually on PPC we use ad default compiler GCC (5.3.1 now). +I been installed clang 3.8 and will check report if all will right. + +Thanks + +Hi guys, did the patch but same error appear. +i attached the config.log. + + + +Ok so the log message associated with the failure is this: + +cc -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1 -I/usr/local/include -I/usr/include/libpng12 -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnu/glib-2.0/include -g -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m32 -g -lgthread-2.0 -pthread -lglib-2.0 -lz +In file included from /usr/include/glib-2.0/glib.h:79:0, + from config-temp/qemu-conf.c:1: +/usr/include/glib-2.0/glib/gstrfuncs.h:301:2: error: #endif without #if + #endif /* __G_STRFUNCS_H__ */ + + +Which rather suggests your glib header files are broken. + +Hi Daniel i dont know +from this last i have this issue other versions was building right . +im affraid i deleted the rc3 i just make a test with 2.5.1 and you can see configure work, like was working in past. + + + + +rc5 same issue + +./configure + +ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T. + You probably need to set PKG_CONFIG_LIBDIR + to point to the right pkg-config files for your + build target + +thanks + +I think Daniel is right -- your glib headers are broken, and we just weren't diagnosing it before. You need to fix your glib install. + + +Hi Perter, +probalby ... i found something wrongs inside my ppc64 library , im clearing and reinstall the glib . report it soon + +Yes Fixed guys. +configure reply right . can close this bug , that was not a qemu bug. + diff --git a/results/classifier/118/ppc/1587535 b/results/classifier/118/ppc/1587535 new file mode 100644 index 00000000..c3bd58c2 --- /dev/null +++ b/results/classifier/118/ppc/1587535 @@ -0,0 +1,69 @@ +ppc: 0.957 +boot: 0.860 +semantic: 0.774 +register: 0.765 +performance: 0.761 +graphic: 0.759 +device: 0.758 +architecture: 0.748 +mistranslation: 0.724 +PID: 0.714 +peripherals: 0.709 +network: 0.668 +socket: 0.667 +files: 0.645 +kernel: 0.642 +hypervisor: 0.628 +debug: 0.612 +permissions: 0.595 +assembly: 0.579 +arm: 0.565 +VMM: 0.557 +risc-v: 0.540 +user-level: 0.519 +x86: 0.518 +TCG: 0.507 +vnc: 0.499 +i386: 0.498 +KVM: 0.486 +virtual: 0.324 + +Incorrect MAS1_TSIZE_SHIFT in ppce500_spin.c causes incorrectly sized TLB. + +When e500 PPC is booted multi-core, the non-boot cores are started via +the spin table. ppce500_spin.c:spin_kick() calls +mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but +the created TLB entry is only 256KB. + +The root cause is that the function computing the size of the TLB +entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined +by latter PPC cores, specifically n to the power of FOUR * 1KB. The +result is then used by mmubooke_create_initial_mapping using +MAS1_TSIZE_SHIFT, but MAS1_TSIZE_SHIFT is defined assuming TLB entries +are n to the power of TWO * 1KB. I.e., a difference of shift=7 or +shift=8. + +Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since +the macro is used elsewhere. + +Removing the ">>1" from: + +> static inline hwaddr booke206_page_size_to_tlb(uint64_t size) +> { +> return ctz32(size >> 10) >> 1; + +and adding an appropriate comment is what I used as a work around: + +> static inline hwaddr booke206_page_size_to_tlb(uint64_t size) +> { +> // resulting size is based on MAS1_TSIZE_SHIFT=7 TLB size. +> return ctz32(size >> 10); + +Patch accepted. + +Commit title is: + +Eliminate redundant and incorrect function booke206_page_size_to_tlb + +Patch had been released with QEMU 2.7 + diff --git a/results/classifier/118/ppc/1623998 b/results/classifier/118/ppc/1623998 new file mode 100644 index 00000000..d93631d0 --- /dev/null +++ b/results/classifier/118/ppc/1623998 @@ -0,0 +1,100 @@ +ppc: 0.850 +device: 0.786 +mistranslation: 0.758 +performance: 0.736 +arm: 0.733 +peripherals: 0.708 +semantic: 0.698 +graphic: 0.636 +PID: 0.633 +x86: 0.628 +debug: 0.593 +user-level: 0.531 +risc-v: 0.465 +architecture: 0.465 +socket: 0.463 +vnc: 0.435 +assembly: 0.434 +permissions: 0.433 +VMM: 0.428 +register: 0.427 +boot: 0.405 +i386: 0.380 +hypervisor: 0.358 +network: 0.340 +virtual: 0.292 +TCG: 0.290 +KVM: 0.233 +files: 0.208 +kernel: 0.205 + +pulseaudio Invalid argument error + +When using qemu-system-ppc on Ubuntu Mate 15 with the usb audio card, I see these error messages: + +pulseaudio: set_sink_input_volume() failed +pulseaudio: Reason: Invalid argument +pulseaudio: set_sink_input_mute() failed +pulseaudio: Reason: Invalid argument + +No audio plays. When an attempt is made, QEMU seems to freeze for a moment. + +I use "-device usb-audio" to add the usb sound card. This issue is present in both emulation and KVM mode. + +Triaging old bug tickets ... Can you still reproduce this issue with the latest version of QEMU (currently 4.1)? Or could we close this ticket nowadays? + +I tried using "-device usb-audio"and the guest was able to detect the USB audio card, but for some reason no audio would play. I did not see any messages in the terminal about pulseaudio. + +What output do you get when you run "qemu-system-x86_64 -audio-help" ? Could you provide your full command line, please? + +Here is the output. I assumed you meant qemu-system-ppc. + +$ ./ppc-softmmu/qemu-system-ppc -audio-help +Environment variable based configuration deprecated. +Please use the new -audiodev option. + +Equivalent -audiodev to your current environment variables: +(Since you didn't specify QEMU_AUDIO_DRV, I'll list all possibilities) +-audiodev id=oss,driver=oss +-audiodev id=none,driver=none + +> On Oct 7, 2019, at 3:44 AM, Thomas Huth <email address hidden> wrote: +> +> What output do you get when you run "qemu-system-x86_64 -audio-help" ? +> Could you provide your full command line, please? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1623998 +> +> Title: +> pulseaudio Invalid argument error +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> When using qemu-system-ppc on Ubuntu Mate 15 with the usb audio card, +> I see these error messages: +> +> pulseaudio: set_sink_input_volume() failed +> pulseaudio: Reason: Invalid argument +> pulseaudio: set_sink_input_mute() failed +> pulseaudio: Reason: Invalid argument +> +> No audio plays. When an attempt is made, QEMU seems to freeze for a +> moment. +> +> I use "-device usb-audio" to add the usb sound card. This issue is +> present in both emulation and KVM mode. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1623998/+subscriptions + + + +Looks like your current QEMU now only contains the audio backend for OSS, but not for pulseaudio anymore. Please make sure that the right pulse-audio development package (e.g. "pulseaudio-libs-devel") is installed before running the "configure" script of QEMU. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/ppc/1624896 b/results/classifier/118/ppc/1624896 new file mode 100644 index 00000000..1e7852db --- /dev/null +++ b/results/classifier/118/ppc/1624896 @@ -0,0 +1,58 @@ +ppc: 0.806 +architecture: 0.793 +graphic: 0.722 +device: 0.669 +boot: 0.664 +debug: 0.663 +semantic: 0.536 +kernel: 0.526 +vnc: 0.418 +performance: 0.378 +mistranslation: 0.298 +register: 0.273 +user-level: 0.233 +virtual: 0.228 +socket: 0.203 +PID: 0.200 +peripherals: 0.169 +permissions: 0.151 +files: 0.135 +risc-v: 0.106 +network: 0.094 +arm: 0.074 +hypervisor: 0.072 +assembly: 0.068 +TCG: 0.059 +VMM: 0.053 +x86: 0.018 +i386: 0.009 +KVM: 0.004 + +[PPC] SegFault due to Stack Overflow in E500 + + +I am getting a Segmentation Fault while simulating a PowerPC e500. I've tried to debug the problem and I've found that it occurs when you have a 0 value decrementer. The function trace is the following: + +1) __cpu_ppc_store_decr (ppc.c) is called with value = 0 and raise_excp=booke_decr_cb; +2) Since value < 3, booke_decr_cb is called; +3) booke_decr_cb then calls booke_update_irq() and cpu_ppc_store_decr(); +4) cpu_ppc_store_decr calls __cpu_ppc_store_decr + +You're stuck on this infinite cycle until your stack overflows eventually. + +Command Line: +qemu-system-ppc -cpu e500v2 -d guest_errors,unimp -m 2048 -M ppce500 -nographic -bios ../cc/share/qem +u/u-boot.e500 -kernel XKYAPP.exe + +Platform where the bug occured: Bash ubuntu on Windows; + +Revision where the bug was found: e3571ae30cd26d19efd4554c25e32ef64d6a36b3 (16 Set 2016) + + + +Thanks! + +Do you know what the DECAR SPR contains at that point in time? I guess it's 0 ... but what does that mean here? Should the decrementer be stopped? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/ppc/1643537 b/results/classifier/118/ppc/1643537 new file mode 100644 index 00000000..ccb2883e --- /dev/null +++ b/results/classifier/118/ppc/1643537 @@ -0,0 +1,62 @@ +ppc: 0.889 +architecture: 0.792 +arm: 0.732 +semantic: 0.714 +files: 0.702 +graphic: 0.699 +device: 0.693 +kernel: 0.649 +network: 0.640 +socket: 0.622 +assembly: 0.604 +performance: 0.572 +vnc: 0.547 +permissions: 0.538 +x86: 0.519 +mistranslation: 0.506 +risc-v: 0.493 +boot: 0.473 +i386: 0.471 +register: 0.471 +PID: 0.469 +debug: 0.441 +virtual: 0.396 +TCG: 0.380 +peripherals: 0.367 +hypervisor: 0.367 +KVM: 0.363 +VMM: 0.350 +user-level: 0.333 + +target-ppc/int_helper.c: 2 * bad array index + +1. + +[qemu/target-ppc/int_helper.c:2575]: (error) Array 'reg.u16[8]' accessed at index 8, which is out of bounds. + +Source code is + + return reg->u16[8 - n]; + +and + +qemu/target-ppc/cpu.h: uint16_t u16[8]; + +but at least once, n is zero, for example line 2725 in the int_helper.c file: + + uint16_t sgnb = get_national_digit(b, 0); + +2. + +[qemu/target-ppc/int_helper.c:2584]: (error) Array 'reg.u16[8]' accessed at index 8, which is out of bounds. + +Duplicate + +Thanks for the bug report! Jose posted a patch: +marc.info/?<email address hidden> + +Fix has been committed: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a813fe73621e1221a09 + +Released with version 2.8 + diff --git a/results/classifier/118/ppc/1661815 b/results/classifier/118/ppc/1661815 new file mode 100644 index 00000000..4c52e8a7 --- /dev/null +++ b/results/classifier/118/ppc/1661815 @@ -0,0 +1,73 @@ +ppc: 0.816 +vnc: 0.749 +graphic: 0.734 +performance: 0.728 +device: 0.725 +architecture: 0.705 +user-level: 0.695 +network: 0.677 +permissions: 0.661 +debug: 0.656 +hypervisor: 0.631 +PID: 0.623 +files: 0.617 +peripherals: 0.598 +TCG: 0.578 +register: 0.569 +socket: 0.557 +kernel: 0.556 +semantic: 0.542 +VMM: 0.515 +x86: 0.474 +i386: 0.473 +virtual: 0.454 +KVM: 0.451 +assembly: 0.446 +risc-v: 0.383 +boot: 0.368 +arm: 0.362 +mistranslation: 0.251 + +Stack address is returned from function translate_one + +The vulnerable version is qemu-2.8.0, and the vulnerable function is in "target-s390x/translate.c". + +The code snippet is as following. + +static ExitStatus translate_one(CPUS390XState *env, DisasContext *s) +{ + const DisasInsn *insn; + ExitStatus ret = NO_EXIT; + DisasFields f; + ... + s->fields = &f; + ... + s->pc = s->next_pc; + return ret; +} + +A stack address, i.e. the address of local variable "f" is returned from current function through the output parameter "s->fields" as a side effect. + +This issue is one kind of undefined behaviors, according the C Standard, 6.2.4 [ISO/IEC 9899:2011] (https://www.securecoding.cert.org/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations) + +This dangerous defect may lead to an exploitable vulnerability. +We suggest sanitizing "s->fields" as null before return. + +Note that this issue is reported by shqking and Zhenwei Zou together. + +The calling function never uses "->fields", so I do not see a real vulnerability here, is there? Did you use a code analyser for this, or how did you come across this issue? + +Thanks for your reply. + +Inspired by this issue in apache httpd (https://bz.apache.org/bugzilla/show_bug.cgi?id=59844#c0), +we customized a checker based on the Clang Static Analyzer to detect such undefined behavior. + +Yes. +After examining the code carefully, we didn't find any place where the "->fields" is accessed, either. However, we think this kind of defect seems like a 'time bomb' and we'd better fix it just to be on the safe side. + +I've finally posted a patch for this: +https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05204.html + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=344a7f656e8d211cdd6e + diff --git a/results/classifier/118/ppc/1706825 b/results/classifier/118/ppc/1706825 new file mode 100644 index 00000000..f6aff833 --- /dev/null +++ b/results/classifier/118/ppc/1706825 @@ -0,0 +1,48 @@ +ppc: 0.904 +i386: 0.795 +device: 0.716 +user-level: 0.667 +performance: 0.649 +graphic: 0.617 +files: 0.599 +PID: 0.517 +semantic: 0.508 +permissions: 0.484 +vnc: 0.478 +network: 0.463 +register: 0.455 +mistranslation: 0.441 +architecture: 0.430 +debug: 0.416 +socket: 0.380 +arm: 0.362 +boot: 0.325 +peripherals: 0.315 +VMM: 0.216 +hypervisor: 0.211 +risc-v: 0.206 +virtual: 0.203 +TCG: 0.182 +kernel: 0.163 +x86: 0.088 +assembly: 0.067 +KVM: 0.024 + +qemu-user fails to run wineserver on ppc64el host + +When attempting to run wineserver on a 64-bit ppc64el host via QEMU's user-mode i386 emulation, a file locking operation fails. + +Command line: +qemu-i386-static /usr/lib/wine-development/wineserver32 + +Output: +wineserver: fcntl /tmp/.wine-0/server-17-14d21bf/lock: Invalid argument + +Relevant portion of strace: +fcntl(6, F_SETLK64, 0x3fffe8802218) = -1 EINVAL (Invalid argument) + +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". 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/ppc/1710 b/results/classifier/118/ppc/1710 new file mode 100644 index 00000000..2e127998 --- /dev/null +++ b/results/classifier/118/ppc/1710 @@ -0,0 +1,81 @@ +ppc: 0.916 +device: 0.835 +PID: 0.776 +mistranslation: 0.722 +semantic: 0.645 +files: 0.619 +graphic: 0.565 +socket: 0.530 +arm: 0.503 +network: 0.466 +peripherals: 0.449 +debug: 0.430 +hypervisor: 0.396 +vnc: 0.369 +architecture: 0.353 +boot: 0.338 +performance: 0.336 +assembly: 0.322 +register: 0.310 +user-level: 0.294 +kernel: 0.289 +risc-v: 0.285 +permissions: 0.284 +virtual: 0.205 +VMM: 0.185 +TCG: 0.177 +x86: 0.176 +i386: 0.144 +KVM: 0.109 + +contrib/plugins/Makefile is not crossplatform +Description of problem: +Currently `contrib/plugins/Makefile` makes multiple assumptions about paths used, compiler flags available, and library extension +Steps to reproduce: +1. Compile QEMU from sources on macOS or Windows +2. Enter `contrib/plugins` +3. Type `make` and become sad. +Additional information: +As the rest of QEMU switched to Meson, maybe it's a good idea to do the same for plugins as well? + +This is what I come with myself: + +`meson.build`: +```meson +project('qemu-plugins', 'c', meson_version: '>=0.50.0') + +qemu_src = get_option('qemu_path') +if qemu_src == '' + qemu_src = '../..' +endif + +qemu_include = qemu_src + '/include/qemu' +incdir = include_directories(qemu_include) + +plugins = [ + 'execlog', + 'hotblocks', + 'hotpages', + 'howvec', + 'lockstep', + 'hwprofile', + 'cache', + 'drcov', +] + +th = dependency('threads', required: true) +glib = dependency('glib-2.0', required: true) + +foreach p: plugins + library(p, p + '.c', + include_directories: incdir, + dependencies: [th, glib], + override_options: ['b_lundef=false'] + ) +endforeach +``` + +`meson_options.txt`: +``` +option('qemu_path', type : 'string', value : '', description : 'Full path to the QEMU sources to build the plugin for') +``` diff --git a/results/classifier/118/ppc/1728325 b/results/classifier/118/ppc/1728325 new file mode 100644 index 00000000..b3d92778 --- /dev/null +++ b/results/classifier/118/ppc/1728325 @@ -0,0 +1,107 @@ +ppc: 0.872 +architecture: 0.757 +mistranslation: 0.743 +user-level: 0.715 +graphic: 0.704 +assembly: 0.699 +device: 0.695 +performance: 0.686 +PID: 0.632 +arm: 0.627 +peripherals: 0.603 +vnc: 0.596 +debug: 0.589 +semantic: 0.587 +risc-v: 0.585 +permissions: 0.583 +kernel: 0.578 +files: 0.577 +hypervisor: 0.516 +network: 0.477 +boot: 0.464 +socket: 0.462 +x86: 0.450 +virtual: 0.428 +register: 0.396 +i386: 0.379 +TCG: 0.319 +VMM: 0.312 +KVM: 0.246 + +POWER8: Wrong behaviour with float-to-int punning + +Building a reduced test program with 'gcc -O2 -fno-inline -mcpu=power8' produces wrong results at runtime. I don't think gcc is at fault here. + +--- +#include <stdio.h> + +int getWord(const float x) +{ + return *(int*)&x; +} + +void main() +{ + int foo = getWord(+123.456f); + int bar = getWord(-123.456f); + + printf("%d\n", foo); + printf("%d\n", bar); + return; +} +--- + +This prints: +--- +0 +0 +--- + +Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the expected result: +--- +1123477881 +-1024005767 +--- + + +The different between the two programs is: + +--- power7.s ++++ power8.s +@@ -6,9 +6,9 @@ + .globl getWord + .type getWord, @function + getWord: +- stfs 1,-16(1) +- ori 2,2,0 +- lwa 3,-16(1) ++ xscvdpspn 0,1 ++ mfvsrwz 3,0 ++ extsw 3,3 + blr + .long 0 + .byte 0,0,0,0,0,0,0,0 + .size getWord,.-getWord + + +Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly. + +https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40 +https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1 + +I am running: + +qemu-ppc64le-static -L /usr/powerpc64le-linux-gnu ./a.out + +This is buggy C. + +https://gcc.gnu.org/bugs/#nonbugs_c + +The original code used a union. It generates the same assembler all the same. + +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/ppc/1735 b/results/classifier/118/ppc/1735 new file mode 100644 index 00000000..6b37d99b --- /dev/null +++ b/results/classifier/118/ppc/1735 @@ -0,0 +1,59 @@ +ppc: 0.897 +permissions: 0.894 +risc-v: 0.892 +peripherals: 0.682 +mistranslation: 0.657 +vnc: 0.643 +PID: 0.609 +register: 0.466 +kernel: 0.448 +network: 0.415 +device: 0.391 +performance: 0.377 +TCG: 0.365 +graphic: 0.338 +assembly: 0.330 +arm: 0.294 +socket: 0.293 +KVM: 0.288 +VMM: 0.273 +hypervisor: 0.229 +i386: 0.225 +boot: 0.219 +debug: 0.216 +files: 0.214 +semantic: 0.168 +architecture: 0.142 +user-level: 0.136 +virtual: 0.103 +x86: 0.100 + +[riscv-pmp] Pmp_hart_has_privs local variable name easily misunderstood +Additional information: +```c +// int => bool +static int pmp_is_in_range(CPURISCVState *env, int pmp_index, + target_ulong addr); + +bool pmp_hart_has_privs(CPURISCVState *env, target_ulong addr, + target_ulong size, pmp_priv_t privs, + pmp_priv_t *allowed_privs, target_ulong mode) +{ + int i = 0; + int pmp_size = 0; + // easily misunderstood local variable + target_ulong s = 0; + target_ulong e = 0; + + for (i = 0; i < MAX_RISCV_PMPS; i++) { + s = pmp_is_in_range(env, i, addr); + e = pmp_is_in_range(env, i, addr + pmp_size - 1); + + /* partially inside */ + if ((s + e) == 1) { + + } + + /* fully inside */ + if ((s + e) == 2) { +``` diff --git a/results/classifier/118/ppc/1811499 b/results/classifier/118/ppc/1811499 new file mode 100644 index 00000000..e2875a24 --- /dev/null +++ b/results/classifier/118/ppc/1811499 @@ -0,0 +1,64 @@ +ppc: 0.820 +device: 0.785 +network: 0.767 +socket: 0.744 +mistranslation: 0.737 +files: 0.734 +register: 0.722 +kernel: 0.674 +vnc: 0.661 +arm: 0.582 +graphic: 0.565 +semantic: 0.564 +user-level: 0.545 +x86: 0.543 +PID: 0.531 +architecture: 0.500 +performance: 0.486 +risc-v: 0.480 +boot: 0.470 +hypervisor: 0.468 +assembly: 0.468 +i386: 0.454 +debug: 0.440 +VMM: 0.438 +KVM: 0.433 +peripherals: 0.428 +permissions: 0.421 +virtual: 0.402 +TCG: 0.322 + +qemu/net/colo-compare.c:288: possible pointless code duplication ? + +qemu/net/colo-compare.c:288] -> [qemu/net/colo-compare.c:296]: (style) The if condition is the same as the previous if condition + +Source code is + + if (ppkt->tcp_seq == spkt->tcp_seq && ppkt->seq_end == spkt->seq_end) { + if (colo_compare_packet_payload(ppkt, spkt, + ppkt->header_size, spkt->header_size, + ppkt->payload_size)) { + *mark = COLO_COMPARE_FREE_SECONDARY | COLO_COMPARE_FREE_PRIMARY; + return true; + } + } + if (ppkt->tcp_seq == spkt->tcp_seq && ppkt->seq_end == spkt->seq_end) { + if (colo_compare_packet_payload(ppkt, spkt, + ppkt->header_size, spkt->header_size, + ppkt->payload_size)) { + *mark = COLO_COMPARE_FREE_SECONDARY | COLO_COMPARE_FREE_PRIMARY; + return true; + } + } + +Maybe the second block was supposed to be different ? + +Have fixed in this patch. +https://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg02859.html + +Thanks +Zhang Chen + +The fix is now in master as commit 6d3aaa5b255ffc55a0561 and will be in QEMU 4.0. + + diff --git a/results/classifier/118/ppc/1824744 b/results/classifier/118/ppc/1824744 new file mode 100644 index 00000000..d09d8fa6 --- /dev/null +++ b/results/classifier/118/ppc/1824744 @@ -0,0 +1,46 @@ +ppc: 0.902 +device: 0.833 +register: 0.758 +vnc: 0.621 +graphic: 0.568 +peripherals: 0.519 +network: 0.469 +semantic: 0.351 +files: 0.338 +boot: 0.333 +performance: 0.303 +debug: 0.264 +architecture: 0.261 +risc-v: 0.240 +mistranslation: 0.222 +arm: 0.202 +socket: 0.199 +TCG: 0.199 +VMM: 0.179 +PID: 0.157 +permissions: 0.145 +x86: 0.135 +virtual: 0.122 +user-level: 0.089 +kernel: 0.061 +hypervisor: 0.035 +assembly: 0.031 +i386: 0.020 +KVM: 0.004 + +ivshmem PCI device exposes wrong endianness on ppc64le + +On a ppc64le host with a ppc64le guest running on QEMU 3.1.0 when an ivshmem device is used, the ivshmem device appears to expose the wrong endianness for the values in BAR 0. + +For example, when the guest is assigned an ivshmem device ID of 1, the IVPosition register (u32, offset 8 in BAR 0) returns 0x1000000 instead of 0x1. I tested on an x86_64 machine and the IVPosition reads 0x1 as expected. + +It seems possible that there's a ppc64*==bigendian assumption somewhere that is erroneously affecting ppc64le. + + +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/168 + + diff --git a/results/classifier/118/ppc/1837094 b/results/classifier/118/ppc/1837094 new file mode 100644 index 00000000..9dc222d5 --- /dev/null +++ b/results/classifier/118/ppc/1837094 @@ -0,0 +1,63 @@ +ppc: 0.839 +device: 0.780 +network: 0.733 +semantic: 0.679 +graphic: 0.677 +user-level: 0.652 +risc-v: 0.644 +hypervisor: 0.627 +socket: 0.620 +PID: 0.620 +register: 0.605 +debug: 0.553 +files: 0.544 +i386: 0.544 +kernel: 0.544 +permissions: 0.542 +VMM: 0.540 +x86: 0.538 +vnc: 0.531 +KVM: 0.530 +arm: 0.515 +boot: 0.492 +architecture: 0.481 +mistranslation: 0.463 +TCG: 0.446 +virtual: 0.442 +peripherals: 0.440 +performance: 0.380 +assembly: 0.356 + +UndefinedBehaviorSanitizer crash around slirp::ip_reass() + +tag: v4.1.0-rc1 + +./configure --enable-sanitizers --extra-cflags=-O1 + +==26130==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000008 (pc 0x00000046d588 bp 0x7fff6ee9f940 sp 0x7fff6ee9f8e8 T26130) +==26130==The signal is caused by a WRITE memory access. +==26130==Hint: address points to the zero page. + #0 0x0000561ad346d587 in ip_deq() at slirp/src/ip_input.c:411:55 + #1 0x0000561ad346cffb in ip_reass() at slirp/src/ip_input.c:304:9 + #2 0x0000561ad346cb6f in ip_input() at slirp/src/ip_input.c:184:18 + +I only had access to the last packet which isn't the culprit, I'm now seeing how to log the network traffic of the guest to provide more useful information. + +Recent libslirp patch 126c04ac (explained in e0be8043) changed ip_reass(), so this bug might be fixed. + +https://gitlab.freedesktop.org/slirp/libslirp/commit/126c04ac +https://gitlab.freedesktop.org/slirp/libslirp/commit/e0be8043 + +And + +https://gitlab.freedesktop.org/slirp/libslirp/commit/d203c81b + +I apologize for not understanding this bug was a security issue, and not insisting on it. + +It has been fixed in SLiRP by "Fix use-afte-free in ip_reass() (CVE-2020-1983)": +https://gitlab.freedesktop.org/slirp/libslirp/commit/9bd6c591 + +And in QEMU by commit 7769c23774 "slirp: update to fix CVE-2020-1983". + +Fixed in QEMU release v5.0.0 + diff --git a/results/classifier/118/ppc/1885720 b/results/classifier/118/ppc/1885720 new file mode 100644 index 00000000..7e2b02a7 --- /dev/null +++ b/results/classifier/118/ppc/1885720 @@ -0,0 +1,52 @@ +ppc: 0.879 +socket: 0.753 +device: 0.727 +files: 0.719 +network: 0.680 +semantic: 0.658 +mistranslation: 0.651 +graphic: 0.635 +vnc: 0.628 +debug: 0.550 +PID: 0.543 +permissions: 0.470 +kernel: 0.368 +i386: 0.361 +VMM: 0.353 +TCG: 0.348 +architecture: 0.344 +risc-v: 0.323 +arm: 0.313 +x86: 0.294 +performance: 0.286 +KVM: 0.279 +boot: 0.269 +user-level: 0.219 +hypervisor: 0.215 +assembly: 0.190 +register: 0.185 +virtual: 0.185 +peripherals: 0.146 + +qemu/migration/postcopy-ram.c:387: bad return expression ? + +qemu/migration/postcopy-ram.c:387:9: style: Non-boolean value returned from function returning bool [returnNonBoolInBooleanFunction] + +Source code is + + return -1; + +but + +bool postcopy_ram_supported_by_host( + +That looks like a bug, indeed! + +Yes, I think a goto out; there makes sense; nearly 5 years old that error :-) + +Posted: +migration: postcopy take proper error return + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=617a32f5295ee4e + diff --git a/results/classifier/118/ppc/1887745 b/results/classifier/118/ppc/1887745 new file mode 100644 index 00000000..54b74cd0 --- /dev/null +++ b/results/classifier/118/ppc/1887745 @@ -0,0 +1,56 @@ +ppc: 0.943 +graphic: 0.858 +boot: 0.835 +device: 0.826 +performance: 0.812 +architecture: 0.731 +mistranslation: 0.728 +PID: 0.709 +user-level: 0.706 +vnc: 0.704 +debug: 0.696 +TCG: 0.655 +semantic: 0.635 +peripherals: 0.614 +register: 0.592 +permissions: 0.523 +network: 0.469 +arm: 0.441 +socket: 0.416 +files: 0.353 +hypervisor: 0.341 +virtual: 0.320 +risc-v: 0.308 +VMM: 0.303 +kernel: 0.263 +assembly: 0.253 +x86: 0.115 +KVM: 0.054 +i386: 0.012 + +call-method block-size failed with error ffffffdf + +I start Debian 10 PowerPC version in QEMU with this command : + +/usr/bin/qemu-system-ppc -monitor stdio -M mac99 -k fr -machine accel=tcg -m 512 -cdrom /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -hda /home/david/Documents/Informatique et téléphone/Documentation informatique/Macintosh/Debian_10_LXDE -virtfs local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name "Debian + LXDE sur iMac G3" -M mac99 + +GRUB menu appears. Then, I choose "Default install", the screen is cleaned and "Loading..." appears. But after, nothing happens and I've got this error message : + +C>> annot manage 'undefined' PCI device type '<NULL>': +>> 1af4 1009 (0 2 0) + +>> ============================================================= +>> OpenBIOS 1.1 [Mar 12 2020 14:02] +>> Configuration device id QEMU version 1 machine id 1 +>> CPUs: 1 +>> Memory: 512M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,G4 +milliseconds isn't unique. +>> switching to new context: +>> call-method block-size failed with error ffffffdf +>> call-method block-size failed with error ffffffdf + + +I found this post, I don't know if it could help... : https://lists.gnu.org/archive/html/grub ... 00001.html + diff --git a/results/classifier/118/ppc/2108 b/results/classifier/118/ppc/2108 new file mode 100644 index 00000000..c0b5f43d --- /dev/null +++ b/results/classifier/118/ppc/2108 @@ -0,0 +1,31 @@ +ppc: 0.987 +device: 0.809 +performance: 0.723 +architecture: 0.649 +graphic: 0.606 +files: 0.442 +debug: 0.422 +arm: 0.248 +boot: 0.223 +VMM: 0.163 +hypervisor: 0.161 +semantic: 0.159 +mistranslation: 0.110 +network: 0.097 +register: 0.089 +permissions: 0.079 +kernel: 0.068 +virtual: 0.065 +peripherals: 0.065 +risc-v: 0.057 +vnc: 0.051 +PID: 0.047 +assembly: 0.042 +TCG: 0.042 +socket: 0.023 +x86: 0.015 +user-level: 0.008 +KVM: 0.006 +i386: 0.002 + +ppc64 POWER10 machine-check caused by ifetch crashes qemu diff --git a/results/classifier/118/ppc/2208 b/results/classifier/118/ppc/2208 new file mode 100644 index 00000000..ea4ee431 --- /dev/null +++ b/results/classifier/118/ppc/2208 @@ -0,0 +1,118 @@ +ppc: 0.813 +user-level: 0.795 +risc-v: 0.777 +TCG: 0.764 +hypervisor: 0.746 +register: 0.734 +performance: 0.733 +arm: 0.733 +i386: 0.732 +KVM: 0.731 +peripherals: 0.726 +graphic: 0.711 +mistranslation: 0.709 +vnc: 0.707 +device: 0.698 +semantic: 0.697 +debug: 0.691 +network: 0.682 +architecture: 0.680 +PID: 0.678 +boot: 0.675 +assembly: 0.670 +virtual: 0.670 +permissions: 0.666 +socket: 0.658 +VMM: 0.658 +kernel: 0.648 +files: 0.639 +x86: 0.592 + +PC is not updated for each instruction in TCG plugins +Description of problem: +I have checkout the `master` branch (the latest available commit on my machine is *7d4e29ef80*) to test the new functions that allow plugins to read registers. See https://gitlab.com/qemu-project/qemu/-/issues/1706 that has been closed last Friday. + +I am using a simple hello-world binary for ARM for my tests: + +```bash +% ./qemu-aarch64 hello-world.out +Hello World! +``` + +I run this binary with the *execlog* plugin enabled, and with the `-one-insn-per-tb` option: + +```bash +% ./qemu-aarch64 -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=pc -one-insn-per-tb hello-world.out +``` + +Here is the end of the execution: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478", pc -> 0x00000000000040e474 +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0, pc -> 0x00000000000040d390 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f635a9e7f28, pc -> 0x00000000000040d394 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8, pc -> 0x00000000000040d398 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1", pc -> 0x00000000000040d39c +0, 0x40d39c, 0xd2800001, "movz x1, #0", pc -> 0x00000000000040d3a0 +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25", pc -> 0x00000000000040d3a8 +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f635a9e7ea0, pc -> 0x00000000000040d3ac +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f635a9e7eb0, pc -> 0x00000000000040d3b0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f635a9e7ec0, pc -> 0x00000000000040d3b4 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f635a9e7ed0, pc -> 0x00000000000040d3b8 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f635a9e7e90, pc -> 0x00000000000040d3bc +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19", pc -> 0x000000000000405d84 +0, 0x405d84, 0x91000694, "add x20, x20, #1", pc -> 0x000000000000405d88 +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23", pc -> 0x000000000000405d90 +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0", pc -> 0x000000000000418e14 +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000", pc -> 0x000000000000418e18 +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0, pc -> 0x000000000000418e1c +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0", pc -> 0x000000000000418e20 +0, 0x418e20, 0xaa0203e0, "mov x0, x2", pc -> 0x000000000000418e24 +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e", pc -> 0x000000000000418e28 +0, 0x418e28, 0xd4000001, "svc #0" +``` + +Now, here is the same part of the execution but without the `-one-insn-per-tb` option: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478" +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f4d42108f28 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1" +0, 0x40d39c, 0xd2800001, "movz x1, #0" +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25" +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f4d42108ea0 +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f4d42108eb0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f4d42108ec0 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f4d42108ed0 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f4d42108e90 +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19" +0, 0x405d84, 0x91000694, "add x20, x20, #1" +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23" +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0" +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000" +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0 +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0" +0, 0x418e20, 0xaa0203e0, "mov x0, x2" +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e" +0, 0x418e28, 0xd4000001, "svc #0" +``` + +The [documentation](https://www.qemu.org/docs/master/devel/tcg-plugins.html) says: + +> This plugin can also dump registers when they change value. Specify the name of the registers with multiple reg options. + +The `pc` register changes for each instruction. I would expect the plugin to produce the same output with or without the `-one-insn-per-tb` option. +Additional information: +The code that prints "pc -> 0x......" is in `insn_check_regs()` in `contrib/plugins/execlog.c`. It uses the new `qemu_plugin_read_register()` function and compares the new value to the previous value. The code seems OK. It means that the implementation of `qemu_plugin_read_register()` gets the same value several times in a row, instead of a new value each time. diff --git a/results/classifier/118/ppc/2246 b/results/classifier/118/ppc/2246 new file mode 100644 index 00000000..f578ef54 --- /dev/null +++ b/results/classifier/118/ppc/2246 @@ -0,0 +1,31 @@ +ppc: 0.932 +hypervisor: 0.915 +device: 0.684 +vnc: 0.585 +performance: 0.515 +virtual: 0.423 +arm: 0.379 +network: 0.371 +VMM: 0.338 +architecture: 0.292 +risc-v: 0.279 +TCG: 0.260 +boot: 0.246 +graphic: 0.233 +i386: 0.229 +PID: 0.224 +socket: 0.177 +semantic: 0.171 +register: 0.164 +x86: 0.160 +files: 0.159 +kernel: 0.157 +KVM: 0.157 +mistranslation: 0.120 +debug: 0.103 +permissions: 0.087 +peripherals: 0.067 +user-level: 0.035 +assembly: 0.027 + +ppc_hv_tests.py:HypervisorTest.test_hv_pseries test fails if xorriso is not present rather than skipping diff --git a/results/classifier/118/ppc/2298 b/results/classifier/118/ppc/2298 new file mode 100644 index 00000000..1c538e25 --- /dev/null +++ b/results/classifier/118/ppc/2298 @@ -0,0 +1,42 @@ +ppc: 0.806 +graphic: 0.543 +semantic: 0.444 +device: 0.213 +vnc: 0.193 +socket: 0.168 +network: 0.139 +register: 0.136 +performance: 0.126 +x86: 0.108 +i386: 0.102 +boot: 0.087 +files: 0.085 +virtual: 0.075 +peripherals: 0.074 +architecture: 0.072 +VMM: 0.065 +hypervisor: 0.065 +mistranslation: 0.056 +KVM: 0.052 +user-level: 0.050 +permissions: 0.046 +kernel: 0.043 +debug: 0.033 +PID: 0.027 +arm: 0.026 +assembly: 0.022 +TCG: 0.019 +risc-v: 0.018 + +Invariant result in opts-visitor.c +Description of problem: +Expressions: +1) val2 <= INT64_MAX +2) INT64_MIN <= val2 +in line [431](https://github.com/qemu/qemu/blob/62dbe54c24dbf77051bafe1039c31ddc8f37602d/qapi/opts-visitor.c#L431) are always true. + +Seems like this checks are redundant. + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Burke. diff --git a/results/classifier/118/ppc/2334 b/results/classifier/118/ppc/2334 new file mode 100644 index 00000000..704c018b --- /dev/null +++ b/results/classifier/118/ppc/2334 @@ -0,0 +1,282 @@ +ppc: 0.801 +KVM: 0.794 +VMM: 0.789 +hypervisor: 0.740 +peripherals: 0.706 +user-level: 0.702 +TCG: 0.661 +vnc: 0.649 +permissions: 0.631 +x86: 0.630 +graphic: 0.618 +mistranslation: 0.567 +register: 0.536 +risc-v: 0.530 +device: 0.515 +virtual: 0.499 +arm: 0.467 +boot: 0.449 +i386: 0.441 +assembly: 0.436 +debug: 0.435 +architecture: 0.392 +semantic: 0.383 +PID: 0.349 +performance: 0.313 +socket: 0.307 +kernel: 0.271 +network: 0.256 +files: 0.243 + +[9.0.0] qemu breaks mac os vm +Description of problem: +Mac OS Monterey vm not able to boot after upgrading qemu to v. 9.0.0; no issue with qemu 8.2.2. +This vm is booted with opencore latest version. +The vm is not able to boot, apple logo is displayed on the screen for a bit, then the vm shutdowns, this is quite strange. +I can't see anything useful in the logs. +Changing machine type from q35-9.0 back to 8.2 doesn't solve the issue. +The vm is booted via libvirt (latest version) and it's not a quite "base" vm, it has multiple passthroughs and other things. +Before testing into details and starting to run base vms to see if it boots,maybe someone can see something wrong or maybe someone has the same issue. +Reverting back to qemu 8.2.2 fixes all the issues and the vm is able to boot again. +No issues with a windows 11 vm and with a kali vm. +I can say that it's not a DSDT issue (a problem I was having in the past was related with DSTD), because injecting the DSDT of the vm started from v 8.2.2 doesn't boot it. + +This is the xml of the vm: + +``` +<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <name>Monterey</name> + <memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>33554432</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static' current='28'>32</vcpu> + <vcpus> + <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> + <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/> + <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/> + <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/> + <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/> + <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/> + <vcpu id='6' enabled='yes' hotpluggable='yes' order='7'/> + <vcpu id='7' enabled='yes' hotpluggable='yes' order='8'/> + <vcpu id='8' enabled='yes' hotpluggable='yes' order='9'/> + <vcpu id='9' enabled='yes' hotpluggable='yes' order='10'/> + <vcpu id='10' enabled='yes' hotpluggable='yes' order='11'/> + <vcpu id='11' enabled='yes' hotpluggable='yes' order='12'/> + <vcpu id='12' enabled='yes' hotpluggable='yes' order='13'/> + <vcpu id='13' enabled='yes' hotpluggable='yes' order='14'/> + <vcpu id='14' enabled='yes' hotpluggable='yes' order='15'/> + <vcpu id='15' enabled='yes' hotpluggable='yes' order='16'/> + <vcpu id='16' enabled='yes' hotpluggable='yes' order='17'/> + <vcpu id='17' enabled='yes' hotpluggable='yes' order='18'/> + <vcpu id='18' enabled='yes' hotpluggable='yes' order='19'/> + <vcpu id='19' enabled='yes' hotpluggable='yes' order='20'/> + <vcpu id='20' enabled='yes' hotpluggable='yes' order='21'/> + <vcpu id='21' enabled='yes' hotpluggable='yes' order='22'/> + <vcpu id='22' enabled='yes' hotpluggable='yes' order='23'/> + <vcpu id='23' enabled='yes' hotpluggable='yes' order='24'/> + <vcpu id='24' enabled='yes' hotpluggable='yes' order='25'/> + <vcpu id='25' enabled='yes' hotpluggable='yes' order='26'/> + <vcpu id='26' enabled='yes' hotpluggable='yes' order='27'/> + <vcpu id='27' enabled='yes' hotpluggable='yes' order='28'/> + <vcpu id='28' enabled='no' hotpluggable='yes'/> + <vcpu id='29' enabled='no' hotpluggable='yes'/> + <vcpu id='30' enabled='no' hotpluggable='yes'/> + <vcpu id='31' enabled='no' hotpluggable='yes'/> + </vcpus> + <iothreads>2</iothreads> + <iothreadids> + <iothread id='1'/> + <iothread id='2'/> + </iothreadids> + <cputune> + <vcpupin vcpu='0' cpuset='1'/> + <vcpupin vcpu='1' cpuset='2'/> + <vcpupin vcpu='2' cpuset='3'/> + <vcpupin vcpu='3' cpuset='4'/> + <vcpupin vcpu='4' cpuset='5'/> + <vcpupin vcpu='5' cpuset='6'/> + <vcpupin vcpu='6' cpuset='7'/> + <vcpupin vcpu='7' cpuset='9'/> + <vcpupin vcpu='8' cpuset='10'/> + <vcpupin vcpu='9' cpuset='11'/> + <vcpupin vcpu='10' cpuset='12'/> + <vcpupin vcpu='11' cpuset='13'/> + <vcpupin vcpu='12' cpuset='14'/> + <vcpupin vcpu='13' cpuset='15'/> + <vcpupin vcpu='14' cpuset='17'/> + <vcpupin vcpu='15' cpuset='18'/> + <vcpupin vcpu='16' cpuset='19'/> + <vcpupin vcpu='17' cpuset='20'/> + <vcpupin vcpu='18' cpuset='21'/> + <vcpupin vcpu='19' cpuset='22'/> + <vcpupin vcpu='20' cpuset='23'/> + <vcpupin vcpu='21' cpuset='25'/> + <vcpupin vcpu='22' cpuset='26'/> + <vcpupin vcpu='23' cpuset='27'/> + <vcpupin vcpu='24' cpuset='28'/> + <vcpupin vcpu='25' cpuset='29'/> + <vcpupin vcpu='26' cpuset='30'/> + <vcpupin vcpu='27' cpuset='31'/> + <emulatorpin cpuset='0,8,16,24'/> + </cputune> + <os> + <type arch='x86_64' machine='pc-q35-8.2'>hvm</type> + <loader readonly='yes' type='pflash'>/opt/macos/AUDK_CODE.fd</loader> + <nvram>/opt/macos/AUDK_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'> + <topology sockets='2' dies='1' clusters='1' cores='8' threads='2'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x8' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x9' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0xc' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='c8:2a:14:66:2c:a1'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </interface> + <interface type='bridge'> + <mac address='c8:2a:14:31:32:e2'/> + <source bridge='br1'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='keyboard' bus='ps2'/> + <input type='mouse' bus='ps2'/> + <audio id='1' type='none'/> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </source> + <rom file='/opt/gpu-bios/6900xt.rom'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/> + </source> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x046d'/> + <product id='0x0892'/> + </source> + <address type='usb' bus='0' port='2'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x148f'/> + <product id='0x3070'/> + </source> + <address type='usb' bus='0' port='1'/> + </hostdev> + <watchdog model='itco' action='reset'/> + <memballoon model='none'/> + </devices> + <qemu:commandline> + <qemu:arg value='-smbios'/> + <qemu:arg value='type=2'/> + <qemu:arg value='-global'/> + <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-speed=8'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-width=16'/> + <qemu:arg value='-cpu'/> + <qemu:arg value='host,+hypervisor,migratable=no,-erms,kvm=on,+invtsc,+topoext,+avx,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+arat,+pclmuldq,+pdpe1gb,+rdtscp,+vme,+umip,check'/> + </qemu:commandline> +</domain> +``` + +06:00.0/1 --> gpu +00:1b.0 --> audio +0c:00.0 --> sata controller +84:00.0 --> usb controller +0x046d 0x0892 --> usb webcam +0x148f 0x3070 --> usb wifi diff --git a/results/classifier/118/ppc/2522 b/results/classifier/118/ppc/2522 new file mode 100644 index 00000000..8cb1dbdd --- /dev/null +++ b/results/classifier/118/ppc/2522 @@ -0,0 +1,47 @@ +ppc: 0.914 +files: 0.816 +device: 0.745 +vnc: 0.721 +graphic: 0.690 +permissions: 0.605 +architecture: 0.584 +network: 0.573 +performance: 0.515 +PID: 0.501 +semantic: 0.486 +kernel: 0.455 +VMM: 0.388 +socket: 0.383 +i386: 0.377 +arm: 0.368 +boot: 0.366 +x86: 0.351 +hypervisor: 0.346 +TCG: 0.345 +KVM: 0.300 +register: 0.269 +risc-v: 0.238 +peripherals: 0.232 +debug: 0.229 +virtual: 0.181 +user-level: 0.151 +assembly: 0.109 +mistranslation: 0.039 + +[9.0.2] PPC: incorrect name filed in vmstate_tlbemb_entry, broken snapshot replay +Description of problem: +Fix commit: a90db15 +When using the Record/replay feature on ppc emulation (qemu-system-ppc binary), an error occurred during loading: +``` +qemu-system-ppc: Missing section footer for cpu +qemu-system-ppc: Error -22 while loading VM state +qemu-system-ppc: Could not load snapshot for icount replay +``` +I found a typo that led to this error + +more info in https://lists.nongnu.org/archive/html/qemu-devel/2024-08/msg02951.html +Steps to reproduce: +1. Run bare metal example from the attachment with the first command-line to create snapshot. +2. Run bare metal example from the attachment with the second command-line to replay snapshot. +Additional information: +Use this example [ppc-e500.zip](/uploads/04e47528c74ed9a564c212a17c480a1d/ppc-e500.zip) diff --git a/results/classifier/118/ppc/2662 b/results/classifier/118/ppc/2662 new file mode 100644 index 00000000..d5c1e9be --- /dev/null +++ b/results/classifier/118/ppc/2662 @@ -0,0 +1,41 @@ +ppc: 0.915 +architecture: 0.764 +device: 0.692 +semantic: 0.503 +graphic: 0.441 +mistranslation: 0.348 +files: 0.324 +network: 0.311 +permissions: 0.208 +user-level: 0.200 +register: 0.196 +i386: 0.189 +risc-v: 0.185 +socket: 0.173 +boot: 0.155 +peripherals: 0.151 +vnc: 0.151 +x86: 0.125 +performance: 0.123 +debug: 0.109 +kernel: 0.106 +PID: 0.090 +virtual: 0.088 +TCG: 0.073 +VMM: 0.065 +arm: 0.056 +assembly: 0.054 +hypervisor: 0.051 +KVM: 0.025 + +powerpc: MSR_ILE bit must not be restored in rfi +Description of problem: +On processors that implement the MSR_ILE bit (that is, G4 and prior), the MSR_ILE bit is not restored by the `rfi` instruction. + +qemu, however, does restore this bit from `srr1`. + +Some ppcel operating systems rely on MSR_ILE not being restored by `rfi`, for example, Windows NT when taking a syscall. +Additional information: +Patch provided: [rfi_msr_ile.patch](/uploads/aa661fc8bcbb47585ff63f8e4ebb38ba/rfi_msr_ile.patch) + +The correct behaviour for G4 and prior is performed for later processors too. Given PPC970 and later have that bit documented as reserved, this should not be a problem. diff --git a/results/classifier/118/ppc/327 b/results/classifier/118/ppc/327 new file mode 100644 index 00000000..eae604d2 --- /dev/null +++ b/results/classifier/118/ppc/327 @@ -0,0 +1,31 @@ +ppc: 0.872 +TCG: 0.590 +risc-v: 0.526 +files: 0.487 +VMM: 0.427 +vnc: 0.368 +PID: 0.335 +i386: 0.326 +graphic: 0.320 +device: 0.281 +boot: 0.280 +performance: 0.250 +KVM: 0.149 +x86: 0.108 +mistranslation: 0.099 +register: 0.060 +debug: 0.058 +semantic: 0.055 +arm: 0.043 +user-level: 0.039 +kernel: 0.030 +virtual: 0.020 +permissions: 0.015 +assembly: 0.006 +socket: 0.005 +peripherals: 0.001 +architecture: 0.001 +network: 0.001 +hypervisor: 0.000 + +Storage | Two decimal digits precision diff --git a/results/classifier/118/ppc/533613 b/results/classifier/118/ppc/533613 new file mode 100644 index 00000000..ae60c4ec --- /dev/null +++ b/results/classifier/118/ppc/533613 @@ -0,0 +1,96 @@ +ppc: 0.819 +device: 0.770 +kernel: 0.733 +network: 0.717 +socket: 0.705 +performance: 0.702 +hypervisor: 0.696 +peripherals: 0.691 +permissions: 0.683 +graphic: 0.679 +vnc: 0.676 +register: 0.674 +architecture: 0.672 +PID: 0.647 +KVM: 0.638 +files: 0.632 +boot: 0.607 +i386: 0.585 +debug: 0.551 +arm: 0.540 +TCG: 0.537 +VMM: 0.530 +risc-v: 0.528 +user-level: 0.526 +virtual: 0.509 +semantic: 0.430 +x86: 0.408 +assembly: 0.281 +mistranslation: 0.265 + +fr-ca keymap is wrong + +The fr-ca keymap has tons of wrong keys in it, it affects other projects using Qemu/KVM like Xen. +Documentation about how to make a keymap is too vague to allow me to make something useful to send a patch, I was however able to make something which at least allows me to use important keys like dot and slash, I will attach it for reference. + + + +Cc: <email address hidden> +Cc: Thomas Huth <email address hidden> +Suggested-by: Jérôme Poulin +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + pc-bios/keymaps/fr-ca | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +diff --git a/pc-bios/keymaps/fr-ca b/pc-bios/keymaps/fr-ca +index 030f56a78e..2e540d596c 100644 +--- a/pc-bios/keymaps/fr-ca ++++ b/pc-bios/keymaps/fr-ca +@@ -3,6 +3,8 @@ + include common + map 0xc0c + ++numbersign 0x29 ++bar 0x29 + backslash 0x29 altgr + plusminus 0x2 altgr + at 0x3 altgr +@@ -10,7 +12,6 @@ sterling 0x4 altgr + cent 0x5 altgr + currency 0x6 altgr + notsign 0x7 altgr +-bar 0x29 shift + twosuperior 0x9 altgr + threesuperior 0xa altgr + onequarter 0xb altgr +@@ -38,6 +39,10 @@ dead_cedilla 0x1b + dead_diaeresis 0x1b shift + exclam 0x2 shift + quotedbl 0x3 shift ++comma 0x33 ++apostrophe 0x33 shift ++period 0x34 ++period 0x34 shift + slash 0x4 shift + dollar 0x5 shift + percent 0x6 shift +@@ -48,5 +53,8 @@ parenleft 0xa shift + parenright 0xb shift + underscore 0xc shift + plus 0xd shift +-minus 0xc +-equal 0xd ++minus 0x0c ++underscore 0x0c shift ++equal 0x0d ++semicolon 0x27 ++colon 0x27 shift +-- +2.9.3 + + + +Patch has finally been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=b02cf99b9d998b3ec23dae8 + diff --git a/results/classifier/118/ppc/572 b/results/classifier/118/ppc/572 new file mode 100644 index 00000000..3d993d4f --- /dev/null +++ b/results/classifier/118/ppc/572 @@ -0,0 +1,31 @@ +ppc: 0.807 +mistranslation: 0.791 +graphic: 0.762 +device: 0.748 +performance: 0.745 +semantic: 0.607 +PID: 0.511 +register: 0.507 +arm: 0.497 +debug: 0.445 +socket: 0.434 +network: 0.421 +vnc: 0.393 +assembly: 0.384 +boot: 0.383 +files: 0.365 +VMM: 0.342 +TCG: 0.303 +kernel: 0.284 +permissions: 0.249 +risc-v: 0.150 +peripherals: 0.143 +user-level: 0.124 +virtual: 0.090 +architecture: 0.084 +hypervisor: 0.072 +KVM: 0.036 +i386: 0.016 +x86: 0.012 + +s390-pci-bus.h:85: warning: "PAGE_SIZE" redefined diff --git a/results/classifier/118/ppc/625 b/results/classifier/118/ppc/625 new file mode 100644 index 00000000..8ab3ea37 --- /dev/null +++ b/results/classifier/118/ppc/625 @@ -0,0 +1,53 @@ +ppc: 0.824 +graphic: 0.799 +device: 0.746 +permissions: 0.581 +performance: 0.578 +x86: 0.468 +i386: 0.461 +architecture: 0.458 +mistranslation: 0.424 +PID: 0.390 +vnc: 0.371 +semantic: 0.360 +user-level: 0.290 +assembly: 0.279 +files: 0.275 +VMM: 0.264 +TCG: 0.246 +arm: 0.239 +debug: 0.224 +kernel: 0.217 +boot: 0.198 +network: 0.176 +risc-v: 0.167 +socket: 0.152 +KVM: 0.149 +virtual: 0.132 +hypervisor: 0.091 +register: 0.060 +peripherals: 0.033 + +qemu-hppa floating point POWER function is incorrect +Description of problem: +The floating point power function produces incorrect values, and possibly stack misshapes as well. +Steps to reproduce: +1. $ hppa1.1-unknown-linux-gnu-gcc pow.c -o pow -lm -static +2. $ qemu-hppa pow +3. the expected result is 10.0 ^ 6.0 = 6000000.0, instead of 403.45 +Additional information: +Example C source to reproduce, pow.c: +``` +#include <stdio.h> +#include <math.h> +int main() +{ + double base, expo, res; + base=10.0; + expo=6.0; + // res sould be 1e+6 + res = pow(base, expo); + printf("%.1lf^%.1lf = %.2lf\n", base, expo, res); + return 0; +} +``` diff --git a/results/classifier/118/ppc/681613 b/results/classifier/118/ppc/681613 new file mode 100644 index 00000000..fa3b433a --- /dev/null +++ b/results/classifier/118/ppc/681613 @@ -0,0 +1,58 @@ +ppc: 0.870 +graphic: 0.685 +device: 0.659 +performance: 0.630 +architecture: 0.616 +files: 0.583 +socket: 0.562 +semantic: 0.554 +network: 0.550 +permissions: 0.536 +PID: 0.535 +register: 0.520 +user-level: 0.506 +kernel: 0.446 +VMM: 0.445 +arm: 0.434 +vnc: 0.407 +debug: 0.399 +boot: 0.396 +risc-v: 0.396 +virtual: 0.387 +hypervisor: 0.384 +mistranslation: 0.369 +x86: 0.357 +peripherals: 0.354 +i386: 0.351 +TCG: 0.309 +assembly: 0.261 +KVM: 0.243 + +Failed to convert vmdk on MacOSX ppc + +qemu-img -O vmdk raw-file.dd vmdk-file.vmdk +will failed with error. +This issue will be occured on all big endian environment. + + + +Oops, there seems to be something wrong with my patch. I'll do additional fix. + +On Fri, Nov 26, 2010 at 7:33 AM, Masaki Muranaka +<email address hidden> wrote: +> Oops, there seems to be something wrong with my patch. I'll do +> additional fix. + +Please send the patch to <email address hidden> instead of uploading it +to launchpad, it'll get more developer attention. + +The standard patch email format is an inline patch (not an attachment) +as sent by git-send-email(1). That makes it easiest to review and +quickest to merge. + +Stefan + +Looks like this had been fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=16372ff03d71c7ed3283 +==> Fix released. + diff --git a/results/classifier/118/ppc/727134 b/results/classifier/118/ppc/727134 new file mode 100644 index 00000000..d383d4f8 --- /dev/null +++ b/results/classifier/118/ppc/727134 @@ -0,0 +1,38 @@ +ppc: 0.830 +mistranslation: 0.781 +device: 0.694 +socket: 0.681 +register: 0.657 +KVM: 0.597 +network: 0.585 +PID: 0.579 +kernel: 0.549 +architecture: 0.539 +arm: 0.529 +graphic: 0.521 +vnc: 0.478 +hypervisor: 0.459 +semantic: 0.435 +files: 0.397 +debug: 0.373 +boot: 0.363 +TCG: 0.359 +virtual: 0.359 +VMM: 0.333 +user-level: 0.289 +i386: 0.286 +x86: 0.285 +risc-v: 0.276 +permissions: 0.230 +peripherals: 0.204 +assembly: 0.194 +performance: 0.162 + +pci-stub.o: In function `do_pci_info':0.14.0 compile problem + +Please see this build log. I didn't compile thq qemu-kvm on Mandriva Cooker and haven't any idea. I'm the qemu maintainer on Mandriva. + + + +QEMU 0.14.0 is quite outdated - and I assume that compilation is working fine again with the latest version, so I'm closing this bug ticket now. If you still have problems with the latest version of QEMU, feel free to open it again (or create a new bug ticket instead). + diff --git a/results/classifier/118/ppc/744 b/results/classifier/118/ppc/744 new file mode 100644 index 00000000..49bc30da --- /dev/null +++ b/results/classifier/118/ppc/744 @@ -0,0 +1,33 @@ +ppc: 0.973 +graphic: 0.796 +device: 0.786 +socket: 0.707 +files: 0.700 +vnc: 0.665 +arm: 0.654 +network: 0.630 +risc-v: 0.601 +assembly: 0.593 +boot: 0.509 +register: 0.488 +architecture: 0.441 +permissions: 0.410 +semantic: 0.394 +mistranslation: 0.299 +performance: 0.272 +kernel: 0.256 +VMM: 0.255 +TCG: 0.238 +peripherals: 0.228 +PID: 0.199 +hypervisor: 0.197 +debug: 0.123 +virtual: 0.108 +user-level: 0.106 +KVM: 0.081 +x86: 0.024 +i386: 0.009 + +ppc64: Implement the remaining PowerISA v3.1 instructions +Additional information: +[PowerISA_public.v3.1.pdf](https://wiki.raptorcs.com/w/images/f/f5/PowerISA_public.v3.1.pdf) diff --git a/results/classifier/118/ppc/812398 b/results/classifier/118/ppc/812398 new file mode 100644 index 00000000..bf24dcc3 --- /dev/null +++ b/results/classifier/118/ppc/812398 @@ -0,0 +1,55 @@ +ppc: 0.884 +device: 0.792 +architecture: 0.634 +vnc: 0.601 +graphic: 0.525 +mistranslation: 0.519 +socket: 0.510 +network: 0.458 +register: 0.454 +semantic: 0.448 +performance: 0.440 +kernel: 0.438 +PID: 0.430 +files: 0.420 +risc-v: 0.386 +boot: 0.382 +x86: 0.373 +peripherals: 0.364 +i386: 0.346 +VMM: 0.342 +permissions: 0.326 +arm: 0.322 +TCG: 0.308 +hypervisor: 0.273 +user-level: 0.238 +virtual: 0.230 +debug: 0.192 +assembly: 0.160 +KVM: 0.125 + +powerpc 7450 MMU initialization broken + +The 7540 family of PPCs' MMU can update TLBs using hardware search (like a 604 or 7400) but also using a software algorithm. The mechanism used is defined by HID0[STEN]. + +By default (CPU reset) HID0 is set to 0x80000000 (BTW; another small bug, qemu doesn't set the hardwired MSB), hence +the software-table lookup feature is *disabled*. However, the default (and immutable) 'mmu_model' for this CPU family is POWERC_MMU_SOFT_74XX which choses the soft TLB replacement scheme. + +To fix this: + +1) the initial mmu_model for the 7450 family (includes 7441, 7445, 7451, 7455, 7457, 7447, 7448) should be: POWERPC_MMU_32B +2) when HID0[STEN] is written then the mmu_model should be changed accordingly (I'm not familiar enough with the qemu internal state to judge if any cached state would have to be updated). + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +From looking at the source code of 5.1.0-rc3 (target/ppc/translate_init.inc.c) it seems that this is still an issue. + + +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/86 + + diff --git a/results/classifier/118/ppc/818 b/results/classifier/118/ppc/818 new file mode 100644 index 00000000..91c6af10 --- /dev/null +++ b/results/classifier/118/ppc/818 @@ -0,0 +1,35 @@ +ppc: 0.874 +device: 0.837 +network: 0.546 +graphic: 0.431 +vnc: 0.415 +debug: 0.391 +performance: 0.381 +architecture: 0.341 +register: 0.303 +VMM: 0.295 +i386: 0.237 +TCG: 0.221 +boot: 0.166 +x86: 0.166 +semantic: 0.166 +arm: 0.158 +PID: 0.151 +permissions: 0.142 +mistranslation: 0.138 +files: 0.133 +socket: 0.133 +hypervisor: 0.127 +peripherals: 0.124 +kernel: 0.091 +user-level: 0.045 +virtual: 0.038 +risc-v: 0.026 +KVM: 0.020 +assembly: 0.009 + +qemu with invalid arg will cause monitor error +Steps to reproduce: +``` +qemu-system-ppc.exe -m 1024M -monitor +``` diff --git a/results/classifier/118/ppc/842 b/results/classifier/118/ppc/842 new file mode 100644 index 00000000..ffef3e78 --- /dev/null +++ b/results/classifier/118/ppc/842 @@ -0,0 +1,43 @@ +ppc: 0.903 +peripherals: 0.849 +kernel: 0.766 +graphic: 0.761 +device: 0.736 +debug: 0.667 +semantic: 0.654 +architecture: 0.569 +performance: 0.503 +files: 0.502 +vnc: 0.490 +risc-v: 0.443 +register: 0.432 +boot: 0.395 +permissions: 0.369 +PID: 0.329 +TCG: 0.317 +socket: 0.284 +network: 0.276 +user-level: 0.206 +VMM: 0.192 +x86: 0.172 +virtual: 0.163 +i386: 0.146 +arm: 0.132 +assembly: 0.130 +mistranslation: 0.124 +hypervisor: 0.121 +KVM: 0.036 + +ppc64: hard lockup / hang in Linux kernel v5.17-rc1 +Description of problem: +The kernel deterministically triggers a hard lockup / hang under QEMU since v5.17-rc1 (upgrading from v5.16). + +Bisecting points to the kernel's [0faf20a1ad16](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0faf20a1ad1647c0fc0f5a367c71e5e84deaf899) ("powerpc/64s/interrupt: Don't enable MSR[EE] in irq handlers unless perf is in use"). Reverting it on top of v5.17-rc1 fixes the issue. + +Reported to [linuxppc-dev](https://lore.kernel.org/linuxppc-dev/CANiq72n_FmDx=r-o9J8gYc6LpwRL5EGmhM6Xzwv27Xc7h1TNDw@mail.gmail.com/). Confirmed. Suspected QEMU modeling issue by Cédric Le Goater. +Steps to reproduce: +1. Build kernel v5.17-rc1 or commit 0faf20a1ad16 for ppc64le with the attached config (either GCC or Clang). +2. Run it under QEMU with at least `-smp 2`. +Additional information: +[qemu-and-dmesg.log](/uploads/7cb5ce1cb70e06262800c16f4c800157/qemu-and-dmesg.log) +[kernel.config](/uploads/327e9cec48a731abc9e44cb40db67de9/kernel.config) |