diff options
Diffstat (limited to 'results/classifier/105/device/1824744')
| -rw-r--r-- | results/classifier/105/device/1824744 | 29 |
1 files changed, 29 insertions, 0 deletions
diff --git a/results/classifier/105/device/1824744 b/results/classifier/105/device/1824744 new file mode 100644 index 000000000..480a95197 --- /dev/null +++ b/results/classifier/105/device/1824744 @@ -0,0 +1,29 @@ +device: 0.833 +vnc: 0.621 +instruction: 0.570 +graphic: 0.568 +network: 0.469 +semantic: 0.351 +boot: 0.333 +other: 0.320 +mistranslation: 0.222 +socket: 0.199 +assembly: 0.031 +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 + + |