Bug 1715017
Summary: | qemu-4.0.0-2.fc31 ppc64le: rpm hash calculation buggy | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Denys Vlasenko <dvlasenk> |
Component: | qemu | Assignee: | Fedora Virtualization Maintainers <virt-maint> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | rawhide | CC: | amit, berrange, cfergeau, crobinso, dgibson, dwmw2, itamar, lvivier, pbonzini, rjones, thuth, virt-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-06-21 00:19:48 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Denys Vlasenko
2019-05-29 11:39:12 UTC
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 |