[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 5da5f4: linux-user/ppc: Fix padding in mconte

From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 5da5f4: linux-user/ppc: Fix padding in mcontext_t for ppc64
Date: Mon, 20 Apr 2020 14:30:27 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 5da5f47e6c65eda83e5433bd905c4df03be98596
  Author: Richard Henderson <address@hidden>
  Date:   2020-04-17 (Fri, 17 Apr 2020)

  Changed paths:
    M linux-user/ppc/signal.c

  Log Message:
  linux-user/ppc: Fix padding in mcontext_t for ppc64

The padding that was added in 95cda4c44ee was added to a union,
and so it had no effect.  This fixes misalignment errors detected
by clang sanitizers for ppc64 and ppc64le.

In addition, only ppc64 allocates space for VSX registers, so do
not save them for ppc32.  The kernel only has references to
CONFIG_SPE in signal_32.c, so do not attempt to save them for ppc64.

Fixes: 95cda4c44ee
Signed-off-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>
Acked-by: Laurent Vivier <address@hidden>
Signed-off-by: David Gibson <address@hidden>

  Commit: 211a7784b9a80e42841223d8ea5252567ebe0e9e
  Author: Ganesh Goudar <address@hidden>
  Date:   2020-04-17 (Fri, 17 Apr 2020)

  Changed paths:
    M target/ppc/kvm.c

  Log Message:
  target/ppc: Fix wrong interpretation of the disposition flag.

Bitwise AND with kvm_run->flags to evaluate if we recovered from
MCE or not is not correct, As disposition in kvm_run->flags is a
two-bit integer value and not a bit map, So check for equality
instead of bitwise AND.

Without the fix qemu treats any unrecoverable mce error as recoverable
and ends up in a mce loop inside the guest, Below are the MCE logs before
and after the fix.

Before fix:

[   66.775757] MCE: CPU0: Initiator CPU
[   66.775891] MCE: CPU0: Unknown
[   66.776587] MCE: CPU0: machine check (Harmless) Host UE Indeterminate 
[   66.776857] MCE: CPU0: NIP: [c0080000000e00b8] mcetest_tlbie+0xb0/0x128 

After fix:

[ 20.650577] CPU: 0 PID: 1415 Comm: insmod Tainted: G M O 5.6.0-fwnmi-arv+ #11
[ 20.650618] NIP: c0080000023a00e8 LR: c0080000023a00d8 CTR: c000000000021fe0
[ 20.650660] REGS: c0000001fffd3d70 TRAP: 0200 Tainted: G M O (5.6.0-fwnmi-arv+)
[ 20.650708] MSR: 8000000002a0b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 
42000222 XER: 20040000
[ 20.650758] CFAR: c00000000000b940 DAR: c0080000025e00e0 DSISR: 00000200 
[ 20.650758] GPR00: c0080000023a00d8 c0000001fddd79a0 c0080000023a8500 
[ 20.650758] GPR04: 0000000000000001 0000000000000000 0000000000000000 
[ 20.650758] GPR08: 0000000000000007 c0080000025e00e0 0000000000000000 
[ 20.650758] GPR12: 0000000000000000 c000000001900000 c00000000101f398 
[ 20.650758] GPR16: 00000000000003a8 c0080000025c0000 c0000001fddd7d70 
[ 20.650758] GPR20: 000000000000fff1 c000000000f72c28 c0080000025a0988 
[ 20.650758] GPR24: 0000000000000100 c0080000023a05d0 c0000000001f1d70 
[ 20.650758] GPR28: c0000001fde20000 c0000001fd02b2e0 c0080000023a0000 
[ 20.651178] NIP [c0080000023a00e8] mcetest_tlbie+0xe8/0xf0 [mcetest_tlbie]
[ 20.651220] LR [c0080000023a00d8] mcetest_tlbie+0xd8/0xf0 [mcetest_tlbie]
[ 20.651262] Call Trace:
[ 20.651280] [c0000001fddd79a0] [c0080000023a00d8] mcetest_tlbie+0xd8/0xf0 
[mcetest_tlbie] (unreliable)
[ 20.651340] [c0000001fddd7a10] [c00000000001091c] do_one_initcall+0x6c/0x2c0
[ 20.651390] [c0000001fddd7af0] [c0000000001f7998] do_init_module+0x90/0x298
[ 20.651433] [c0000001fddd7b80] [c0000000001f61a8] load_module+0x1f58/0x27a0
[ 20.651476] [c0000001fddd7d40] [c0000000001f6c70] 
[ 20.651526] [c0000001fddd7e20] [c00000000000b9d0] system_call+0x5c/0x68
[ 20.651567] Instruction dump:
[ 20.651594] e8410018 3c620000 e8638020 480000cd e8410018 3c620000 e8638028 
[ 20.651646] e8410018 7be904e4 39400000 612900e0 <7d434a64> 4bffff74 3c4c0001 
[ 20.651699] ---[ end trace 4c40897f016b4340 ]---
[ 20.653310]
Bus error
[ 20.655575] MCE: CPU0: machine check (Harmless) Host UE Indeterminate [Not 
[ 20.655575] MCE: CPU0: NIP: [c0080000023a00e8] mcetest_tlbie+0xe8/0xf0 
[ 20.655576] MCE: CPU0: Initiator CPU
[ 20.655576] MCE: CPU0: Unknown

Signed-off-by: Ganesh Goudar <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>

  Commit: 5ed195065cc6895f61b9d59bfa0a0536ed5ed51e
  Author: Nicholas Piggin <address@hidden>
  Date:   2020-04-17 (Fri, 17 Apr 2020)

  Changed paths:
    M target/ppc/translate.c

  Log Message:
  target/ppc: Fix mtmsr(d) L=1 variant that loses interrupts

If mtmsr L=1 sets MSR[EE] while there is a maskable exception pending,
it does not cause an interrupt. This causes the test case to hang:


More recently, Linux reduced the occurance of operations (e.g., rfi)
which stop translation and allow pending interrupts to be processed.
This started causing hangs in Linux boot in long-running kernel tests,
running with '-d int' shows the decrementer stops firing despite DEC
wrapping and MSR[EE]=1.


The cause is the broken mtmsr L=1 behaviour, which is contrary to the
architecture. From Power ISA v3.0B, p.977, Move To Machine State Register,
Programming Note states:

    If MSR[EE]=0 and an External, Decrementer, or Performance Monitor
    exception is pending, executing an mtmsrd instruction that sets
    MSR[EE] to 1 will cause the interrupt to occur before the next
    instruction is executed, if no higher priority exception exists

Fix this by handling L=1 exactly the same way as L=0, modulo the MSR
bits altered.

The confusion arises from L=0 being "context synchronizing" whereas L=1
is "execution synchronizing", which is a weaker semantic. However this
is not a relaxation of the requirement that these exceptions cause
interrupts when MSR[EE]=1 (e.g., when mtmsr executes to completion as
TCG is doing here), rather it specifies how a pipelined processor can
have multiple instructions in flight where one may influence how another

Cc: address@hidden
Reported-by: Anton Blanchard <address@hidden>
Reported-by: Nathan Chancellor <address@hidden>
Tested-by: Nathan Chancellor <address@hidden>
Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Tested-by: Cédric Le Goater <address@hidden>
Signed-off-by: David Gibson <address@hidden>

  Commit: 5b4273e462515ae2f14cb57954d99416ae1778d9
  Author: Peter Maydell <address@hidden>
  Date:   2020-04-20 (Mon, 20 Apr 2020)

  Changed paths:
    M linux-user/ppc/signal.c
    M target/ppc/kvm.c
    M target/ppc/translate.c

  Log Message:
  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200417' into 

ppc patch queue for 2020-04-17

Here are a few late bugfixes for qemu-5.0 in the ppc target code.
Unless some really nasty last minute bug shows up, I expect this to be
the last ppc pull request for qemu-5.0.

# gpg: Signature made Fri 17 Apr 2020 06:02:13 BST
# gpg:                using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>" [full]
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>" [full]
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>" [full]
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>" 
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-5.0-20200417:
  target/ppc: Fix mtmsr(d) L=1 variant that loses interrupts
  target/ppc: Fix wrong interpretation of the disposition flag.
  linux-user/ppc: Fix padding in mcontext_t for ppc64

Signed-off-by: Peter Maydell <address@hidden>

Compare: https://github.com/qemu/qemu/compare/d5232d8b0600...5b4273e46251

reply via email to

[Prev in Thread] Current Thread [Next in Thread]