4 files changed, 328 insertions, 0 deletions
diff --git a/results/classifier/118/semantic-ppc/1038 b/results/classifier/118/semantic-ppc/1038
new file mode 100644
index 00000000..9c075618
--- /dev/null
+++ b/results/classifier/118/semantic-ppc/1038
@@ -0,0 +1,71 @@
+ppc: 0.993
+semantic: 0.944
+architecture: 0.876
+TCG: 0.851
+KVM: 0.827
+device: 0.819
+performance: 0.799
+graphic: 0.780
+PID: 0.753
+mistranslation: 0.736
+kernel: 0.617
+vnc: 0.617
+network: 0.606
+register: 0.592
+files: 0.526
+arm: 0.526
+risc-v: 0.452
+socket: 0.430
+boot: 0.429
+permissions: 0.407
+hypervisor: 0.399
+debug: 0.389
+x86: 0.384
+i386: 0.361
+user-level: 0.314
+assembly: 0.306
+peripherals: 0.292
+VMM: 0.244
+virtual: 0.232
+--------------------
+ppc: 0.999
+semantic: 0.668
+hypervisor: 0.563
+virtual: 0.450
+architecture: 0.167
+kernel: 0.119
+register: 0.058
+debug: 0.033
+PID: 0.021
+device: 0.021
+files: 0.020
+user-level: 0.019
+performance: 0.016
+socket: 0.012
+TCG: 0.009
+assembly: 0.007
+peripherals: 0.006
+VMM: 0.005
+risc-v: 0.004
+boot: 0.004
+permissions: 0.003
+network: 0.002
+graphic: 0.002
+KVM: 0.002
+vnc: 0.002
+mistranslation: 0.001
+arm: 0.000
+x86: 0.000
+i386: 0.000
+
+ppc 'max' CPU model is unlike the other targets 'max' CPU model
+Description of problem:
+On most targets the 'max' CPU model is either equivalent to 'host' (for KVM) or equivalent to all available CPU features (for TCG).
+
+On PPC64, however, this is not the case. Instead the 'max' model is an alias of the old '7400_v2.9' and simply doesn't work.
+
+This is confusing. At the very least the 'max' model alias should be deleted. Ideally a proper replacement would be introduced that matches semantics on other arches.
+Steps to reproduce:
+1. qemu-system-ppc64 -cpu max
+
+should be equiv to '-cpu host' or should expose all TCG features.
diff --git a/results/classifier/118/semantic-ppc/1681404 b/results/classifier/118/semantic-ppc/1681404
new file mode 100644
index 00000000..7473559e
--- /dev/null
+++ b/results/classifier/118/semantic-ppc/1681404
@@ -0,0 +1,86 @@
+ppc: 0.947
+device: 0.907
+VMM: 0.832
+semantic: 0.814
+graphic: 0.792
+PID: 0.725
+performance: 0.723
+vnc: 0.634
+kernel: 0.633
+files: 0.619
+network: 0.614
+peripherals: 0.609
+register: 0.575
+architecture: 0.548
+TCG: 0.537
+socket: 0.521
+boot: 0.510
+hypervisor: 0.452
+mistranslation: 0.452
+risc-v: 0.431
+arm: 0.414
+permissions: 0.376
+virtual: 0.353
+user-level: 0.345
+debug: 0.315
+assembly: 0.301
+i386: 0.216
+x86: 0.205
+KVM: 0.130
+--------------------
+ppc: 0.984
+debug: 0.933
+TCG: 0.865
+boot: 0.411
+device: 0.405
+register: 0.382
+PID: 0.313
+files: 0.234
+VMM: 0.177
+semantic: 0.091
+assembly: 0.086
+permissions: 0.086
+hypervisor: 0.079
+virtual: 0.053
+kernel: 0.038
+performance: 0.037
+architecture: 0.027
+graphic: 0.014
+socket: 0.014
+KVM: 0.010
+user-level: 0.008
+mistranslation: 0.007
+vnc: 0.007
+peripherals: 0.005
+network: 0.004
+x86: 0.003
+risc-v: 0.002
+i386: 0.000
+arm: 0.000
+
+hw/ppc: Aborted (core dumped)
+
+Reproducable:
+$ ./ppc64-softmmu/qemu-system-ppc64 -S -machine ppce500,accel=tcg -device spapr-pci-host-bridge
+
+
+qemu/hw/ppc/spapr_pci.c:1567:spapr_phb_realize: Object 0x55bda99744a0 is not an instance of type spapr-machine
+Aborted (core dumped)
+
+This is addressed by commit:
+
+"f7d6bfc spapr_pci: fail gracefully with non-pseries machine types"
+
+
+$ ./v2.11.0-1421-g7d84845/bin/qemu-system-ppc64 -S -machine ppce500,accel=tcg -device spapr-pci-host-bridge
+qemu-system-ppc64: -device spapr-pci-host-bridge: spapr-pci-host-bridge needs a pseries machine
+
+$ git tag --contains f7d6bfc
+v2.11.0
+
+
+1- https://git.qemu.org/?p=qemu.git;a=commit;h=f7d6bfcdc0fe49040aac3ac131a319cb5427957e
+
+As noted in the previous comment, this bug was fixed in the 2.11 release.
+
+
diff --git a/results/classifier/118/semantic-ppc/2378 b/results/classifier/118/semantic-ppc/2378
new file mode 100644
index 00000000..aab30749
--- /dev/null
+++ b/results/classifier/118/semantic-ppc/2378
@@ -0,0 +1,88 @@
+semantic: 0.891
+graphic: 0.883
+user-level: 0.841
+ppc: 0.808
+architecture: 0.804
+performance: 0.786
+device: 0.757
+hypervisor: 0.738
+permissions: 0.733
+network: 0.690
+PID: 0.684
+vnc: 0.675
+kernel: 0.645
+peripherals: 0.634
+files: 0.612
+TCG: 0.595
+VMM: 0.585
+x86: 0.581
+mistranslation: 0.581
+register: 0.559
+i386: 0.555
+socket: 0.548
+virtual: 0.512
+KVM: 0.493
+risc-v: 0.487
+assembly: 0.430
+debug: 0.379
+boot: 0.373
+arm: 0.332
+--------------------
+user-level: 0.855
+hypervisor: 0.848
+x86: 0.529
+TCG: 0.127
+files: 0.064
+register: 0.023
+debug: 0.019
+PID: 0.013
+i386: 0.013
+kernel: 0.009
+network: 0.007
+VMM: 0.006
+virtual: 0.006
+arm: 0.004
+socket: 0.004
+semantic: 0.004
+device: 0.003
+architecture: 0.003
+assembly: 0.003
+performance: 0.003
+vnc: 0.002
+permissions: 0.001
+boot: 0.001
+peripherals: 0.001
+ppc: 0.001
+graphic: 0.001
+risc-v: 0.001
+KVM: 0.001
+mistranslation: 0.000
+
+make install (meson?) removes needed RPATH for libslirp, making build on CentOS 9 difficult
+Description of problem:
+make install appears to remove need RPATH attributes from the binary, making it difficult if not impossible to install Qemu 9.0.0 on a CentOS 9 machine.
+
+I'm trying to build Qemu 9.0.0 on a CentOS 9 Stream machine where I do not have root.
+The system ships with libslirp-4.4.0-7.el9.src.rpm which is libslirp 4.4.0, which is too old for Qemu.
+
+I checked out https://gitlab.freedesktop.org/slirp/libslirp.git which is 2 commits more recent than
+libslirp 4.8.0.  I installed this version in a separate directory.
+
+When I configure Qemu using PKG_CONFIG_PATH, it builds the correct executable with the correct RPATH.
+readelf -d shows:
+
+ 0x000000000000000f (RPATH)              Library rpath: [/web/courses/cs4284/pintostools/lib64]
+
+which is the correct directory where the proper version of libslirp is located.
+
+However, when I run "make install" the RPATH attribute is removed. Thus, Qemu resorts to the system version, which is version 4.4 (with which Qemu won't run.)
+
+Meson's propensity to strip necessary RPATHs appears to be well-known, see, for instance,
+
+https://github.com/mesonbuild/meson/issues/4027
+
+(There is a fix for at least some of the problems in 0.55.0 of Meson
+https://mesonbuild.com/Release-notes-for-0-55-0.html
+Qemu 9.0.0 appears to use Meson 1.2.3., but yet it still fails.)
+
+Work-around: don't use make install, copy it directly from the build directory to the destination directory.
diff --git a/results/classifier/118/semantic-ppc/833658 b/results/classifier/118/semantic-ppc/833658
new file mode 100644
index 00000000..d5c5d584
--- /dev/null
+++ b/results/classifier/118/semantic-ppc/833658
@@ -0,0 +1,83 @@
+ppc: 0.910
+graphic: 0.841
+semantic: 0.821
+architecture: 0.816
+kernel: 0.809
+performance: 0.785
+user-level: 0.778
+virtual: 0.768
+peripherals: 0.763
+register: 0.744
+device: 0.740
+hypervisor: 0.692
+PID: 0.680
+files: 0.667
+boot: 0.659
+permissions: 0.629
+socket: 0.624
+x86: 0.621
+network: 0.609
+mistranslation: 0.578
+debug: 0.578
+VMM: 0.567
+vnc: 0.553
+arm: 0.542
+i386: 0.533
+KVM: 0.512
+TCG: 0.491
+risc-v: 0.472
+assembly: 0.450
+--------------------
+virtual: 0.982
+ppc: 0.974
+user-level: 0.879
+debug: 0.111
+boot: 0.095
+network: 0.057
+files: 0.047
+kernel: 0.027
+hypervisor: 0.023
+socket: 0.015
+register: 0.012
+PID: 0.010
+performance: 0.006
+device: 0.005
+semantic: 0.004
+vnc: 0.004
+graphic: 0.003
+peripherals: 0.003
+VMM: 0.003
+architecture: 0.003
+TCG: 0.002
+assembly: 0.001
+permissions: 0.001
+risc-v: 0.001
+x86: 0.001
+KVM: 0.001
+mistranslation: 0.000
+arm: 0.000
+i386: 0.000
+
+Qemu ppc does not boot Debian 3.1r8
+
+I tried booting the official image debian-31r8-powerpc-binary-1.iso with the following commandline:
+qemu-system-ppc -boot d -cdrom ../debian-31r8-powerpc-binary-1.iso -hda hd.img. The booting process stops with CPU at 100%. I can choose to boot "install-2.4" or "install" which both hangs with the last output being "Loading ramdisk". I have also tried using the git-tree which crashes qemu with the message "qemu/memory.c:1183: memory_region_add_subregion_common: Assertion `!subregion->parent' failed." before even showing anything.
+
+Additionally, qemu 0.14.1 shows the same behaviour but qemu 0.13 and 0.12.5 can boot beyond the "Loading ramdisk" message but stops immediatly afterwards with a messed up console window (letters are pushed into another, which makes them barely readable) when using "install". Also "install-2.4" boots with 0.13 and 0.12.5 beyond the "Loading ramdisk" message but stops with the last message being now "returning 0x01400000 from prom_init".
+
+Hi,
+
+this might be related to this upstream bug report: http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02929.html.
+
+Since it seems to be an issue with the mapping of the video memory, I have tried changing the graphics adapter. After changing it from "vga" to "cirrus", the virtual machine in my case would boot again.
+
+Adrian
+
+I just accidentially came across this bug report ... I did not find debian-31r8-powerpc-binary-1.iso anymore in the internet, but debian-31r8-powerpc-netinst.iso is still available, so I gave it a try: There is no output of grub in the VGA window with this ISO, but if I simply press return when the screen turns black, the kernel seems to boot and work fine with the latest version of QEMU (2.6.0). So I think this problem has likely been fixed and we can close this bug now.
+
+Just to add here: from my local tests with other older images, the text is there on the black screen but just extremely faint. My guess is that it's an endian-related bug in OpenBIOS programming the VGA registers but haven't had much time to dig into it.
+
+
+FWIW the text becomes visible again if you switch QEMU to 8-bit mode rather than 32-bit mode, e.g. adding -g 800x600x8 to the command line.
+
+