Boot the VM with a rhel8 image: $ exec env -i \ LC_ALL=C \ QEMU_AUDIO_DRV=none \ /usr/bin/qemu-system-ppc64 \ -m 3G \ -no-user-config \ -nodefaults \ -no-reboot \ -display none \ \ -machine pseries-3.1,accel=tcg,usb=off,dump-guest-core=off \ \ -drive file=32gb_RHEL8_ready_for_kernel_build.qcow2,format=qcow2,if=none,id=drive-virtio-disk1,cache=none \ -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on \ \ -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x2 \ -chardev stdio,signal=off,id=charserial0 \ -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ In VM: [root@rhel8kbuild ~]# rpm --verify kernel-4.18.0-80.3.el8.src.rpm error: kernel-4.18.0-80.3.el8.src.rpm: Header SHA256 digest: BAD (Expected 23cfbb388221e8c75c1b60b6eb2d30ad74cecd17e7c3261f8e48e3f8e896c1cc != 33b0dde2289b28a877e42cf9a8a165682226c36e9cd78629dc2dc9e06d593f54) error: kernel-4.18.0-80.3.el8.src.rpm: not an rpm package (or package manifest) [root@rhel8kbuild ~]# rpm --verify kernel-4.18.0-80.3.el8.src.rpm error: kernel-4.18.0-80.3.el8.src.rpm: Header SHA256 digest: BAD (Expected 23cfbb388221e8c75c1b60b6eb2d30ad74cecd17e7c3261f8e48e3f8e896c1cc != fe21cd15616a137795043a36da9162b484ac91fbd2a3904a1f73c49621b77f1e) error: kernel-4.18.0-80.3.el8.src.rpm: not an rpm package (or package manifest) [root@rhel8kbuild ~]# rpm --verify kernel-4.18.0-80.3.el8.src.rpm error: kernel-4.18.0-80.3.el8.src.rpm: Header SHA256 digest: BAD (Expected 23cfbb388221e8c75c1b60b6eb2d30ad74cecd17e7c3261f8e48e3f8e896c1cc != cbeead04257a06b90cc90414284177ea6927a049f1eedf280c38fbdcfcd1c337) error: kernel-4.18.0-80.3.el8.src.rpm: not an rpm package (or package manifest) Note that calculated hash does not stay the same. Both these versions show this behavior: Fedora Rawhide's binary: # /usr/bin/qemu-system-ppc64 --version QEMU emulator version 4.0.0 (qemu-4.0.0-2.fc31) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers Binary built from current git: # ./qemu-system-ppc64 --version QEMU emulator version 4.0.50 (v4.0.0-990-ge1961cbc57) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers Older, pre-4.0 version in Fedora (QEMU emulator version 3.1.0 (qemu-3.1.0-4.fc30.1)) does not show this behavior with the exactly the same disk image.
CCing some qemu ppc guys, sounds like a possible target-ppc regression with qemu 4.0.0
Bisected to v4.0.0-rc0: commit 8b3b2d75c7c0481544e277dad226223245e058eb (refs/bisect/bad) Author: Mark Cave-Ayland <mark.cave-ayland.uk> Date: Wed Jan 2 09:14:19 2019 +0000 target/ppc: introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() helpers for VSR register access These helpers allow us to move VSR register values to/from the specified TCG v_i64 argument. To prevent VSX helpers accessing the cpu_vsr array directly, add extra TCG temporaries as required. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland.uk> Reviewed-by: Richard Henderson <richard.henderson> Acked-by: David Gibson <david.id.au> Signed-off-by: David Gibson <david.id.au>
We have a fix for that patch upstream as 77bd8937c03dd55e57cc257951ad07c185303c3e "target/ppc: Fix xvabs[sd]p, xvnabs[sd]p, xvneg[sd]p, xvcpsgn[sd]p". I suspect that will address the problem. We might need to push it to the stable stream.
(In reply to David Gibson from comment #3) > We have a fix for that patch upstream as > 77bd8937c03dd55e57cc257951ad07c185303c3e "target/ppc: Fix xvabs[sd]p, > xvnabs[sd]p, xvneg[sd]p, xvcpsgn[sd]p". > > I suspect that will address the problem. > > We might need to push it to the stable stream. No, this patch doesn't fix the problem. I did all the tests with upstream (ad88e4252f09 Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-1-2019' into staging). I'm not able to reproduce the problem with qemu-linux-user and the same binaries.
(In reply to Laurent Vivier from comment #4) ... > > I'm not able to reproduce the problem with qemu-linux-user and the same > binaries. I'm able to reproduce it with linux-user by enabling the same feature bits in AT_HWCAP/AT_HWCAP2 I have with the 4.18 kernel and POWER8.
OK the buggy instruction is triggered by PPC_FEATURE2_VEC_CRYPTO in hwcaps. It corrupts all crypto tools, like sha256sum: chroot ~/Disks/rootfs sha256sum /root/kernel-4.18.0-80.4.1.el8_0.src.rpm 8482a6cb09a91920ac52467c59db5ff3c9c46829fd8f74733fbe5d175e6650cf /root/kernel-4.18.0-80.4.1.el8_0.src.rpm sha256sum ~/Disks/rootfs/root/kernel-4.18.0-80.4.1.el8_0.src.rpm c5f15e50000494a223ca6061aa75236db09e6af79ad41105b4400d1969e9e07a ~/Disks/rootfs/root/kernel-4.18.0-80.4.1.el8_0.src.rpm We have also some errors in the kernel boot logs (4.18.0-80.el8.ppc64le): [ 167.880075] alg: skcipher: Test 1 failed (invalid result) on encryption for p8_aes_xts [ 167.882358] 00000000: 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92 [ 167.882655] 00000010: 98 10 35 57 5e dc 36 1e 9a f7 bc ba 39 f2 5c eb [ 167.883324] crypto_register_alg 'xts(aes)' = 0 [ 168.096247] alg: hash: Test 2 failed for p8_ghash [ 168.096452] 00000000: 5f 89 ab f7 20 57 20 57 20 57 20 57 20 57 20 57
The following patch form David's branch ppc-for-4.1 solves the problem for me: commit ab24e27716fd0ebe871090aa450af745e6e8c18c Author: Anton Blanchard <anton> Date: Fri May 24 07:53:45 2019 +0100 target/ppc: Fix lxvw4x, lxvh8x and lxvb16x During the conversion these instructions were incorrectly treated as stores. We need to use set_cpu_vsr* and not get_cpu_vsr*. Fixes: 8b3b2d75c7c0 ("introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() helpers for VSR register access") Signed-off-by: Anton Blanchard <anton> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland.uk> Tested-by: Greg Kurz <groug> Reviewed-by: Greg Kurz <groug> Message-Id: <20190524065345.25591-1-mark.cave-ayland.uk> Signed-off-by: David Gibson <david.id.au> diff --git a/target/ppc/translate/vsx-impl.inc.c b/target/ppc/translate/vsx-impl.inc.c index 199d22da97..cdb44b8b70 100644 --- a/target/ppc/translate/vsx-impl.inc.c +++ b/target/ppc/translate/vsx-impl.inc.c @@ -102,8 +102,7 @@ static void gen_lxvw4x(DisasContext *ctx) } xth = tcg_temp_new_i64(); xtl = tcg_temp_new_i64(); - get_cpu_vsrh(xth, xT(ctx->opcode)); - get_cpu_vsrl(xtl, xT(ctx->opcode)); + gen_set_access_type(ctx, ACCESS_INT); EA = tcg_temp_new(); @@ -126,6 +125,8 @@ static void gen_lxvw4x(DisasContext *ctx) tcg_gen_addi_tl(EA, EA, 8); tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_BEQ); } + set_cpu_vsrh(xT(ctx->opcode), xth); + set_cpu_vsrl(xT(ctx->opcode), xtl); tcg_temp_free(EA); tcg_temp_free_i64(xth); tcg_temp_free_i64(xtl); @@ -185,8 +186,6 @@ static void gen_lxvh8x(DisasContext *ctx) } xth = tcg_temp_new_i64(); xtl = tcg_temp_new_i64(); - get_cpu_vsrh(xth, xT(ctx->opcode)); - get_cpu_vsrl(xtl, xT(ctx->opcode)); gen_set_access_type(ctx, ACCESS_INT); EA = tcg_temp_new(); @@ -197,6 +196,8 @@ static void gen_lxvh8x(DisasContext *ctx) if (ctx->le_mode) { gen_bswap16x8(xth, xtl, xth, xtl); } + set_cpu_vsrh(xT(ctx->opcode), xth); + set_cpu_vsrl(xT(ctx->opcode), xtl); tcg_temp_free(EA); tcg_temp_free_i64(xth); tcg_temp_free_i64(xtl); @@ -214,14 +215,14 @@ static void gen_lxvb16x(DisasContext *ctx) } xth = tcg_temp_new_i64(); xtl = tcg_temp_new_i64(); - get_cpu_vsrh(xth, xT(ctx->opcode)); - get_cpu_vsrl(xtl, xT(ctx->opcode)); gen_set_access_type(ctx, ACCESS_INT); EA = tcg_temp_new(); gen_addr_reg_index(ctx, EA); tcg_gen_qemu_ld_i64(xth, EA, ctx->mem_idx, MO_BEQ); tcg_gen_addi_tl(EA, EA, 8); tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_BEQ); + set_cpu_vsrh(xT(ctx->opcode), xth); + set_cpu_vsrl(xT(ctx->opcode), xtl); tcg_temp_free(EA); tcg_temp_free_i64(xth); tcg_temp_free_i64(xtl);
I confirm that the bug is gone with this patch.
Fixed in qemu-4.0.0-4.fc31