Bug 1715017

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

Fixed in qemu-4.0.0-4.fc31