1 files changed, 46 insertions, 0 deletions
diff --git a/results/classifier/118/ppc/1824744 b/results/classifier/118/ppc/1824744
new file mode 100644
index 000000000..d09d8fa6f
--- /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
+
+