|
|
9bac43 |
From 43f0b133d1312d042fb31bf7f63bb31a642eef26 Mon Sep 17 00:00:00 2001
|
|
|
9bac43 |
From: Laurent Vivier <lvivier@redhat.com>
|
|
|
9bac43 |
Date: Thu, 23 Nov 2017 16:14:21 +0100
|
|
|
9bac43 |
Subject: [PATCH 3/7] ppc: fix VTB migration
|
|
|
9bac43 |
|
|
|
9bac43 |
RH-Author: Laurent Vivier <lvivier@redhat.com>
|
|
|
9bac43 |
Message-id: <20171123161421.30320-1-lvivier@redhat.com>
|
|
|
9bac43 |
Patchwork-id: 77796
|
|
|
9bac43 |
O-Subject: [RHV7.5 qemu-kvm-rhev PATCH] ppc: fix VTB migration
|
|
|
9bac43 |
Bugzilla: 1506882
|
|
|
9bac43 |
RH-Acked-by: Serhii Popovych <spopovyc@redhat.com>
|
|
|
9bac43 |
RH-Acked-by: David Gibson <dgibson@redhat.com>
|
|
|
9bac43 |
RH-Acked-by: Thomas Huth <thuth@redhat.com>
|
|
|
9bac43 |
|
|
|
9bac43 |
Migration of a system under stress (for example, with
|
|
|
9bac43 |
"stress-ng --numa 2") triggers on the destination
|
|
|
9bac43 |
some kernel watchdog messages like:
|
|
|
9bac43 |
|
|
|
9bac43 |
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 3489660870s!
|
|
|
9bac43 |
NMI watchdog: BUG: soft lockup - CPU#1 stuck for 3489660884s!
|
|
|
9bac43 |
|
|
|
9bac43 |
This problem appears with the changes introduced by
|
|
|
9bac43 |
42043e4 spapr: clock should count only if vm is running
|
|
|
9bac43 |
|
|
|
9bac43 |
I think this commit only triggers the problem.
|
|
|
9bac43 |
|
|
|
9bac43 |
Kernel computes the soft lockup duration using the
|
|
|
9bac43 |
Virtual Timebase register (VTB), not using the Timebase
|
|
|
9bac43 |
Register (TBR, the one 42043e4 stops).
|
|
|
9bac43 |
|
|
|
9bac43 |
It appears VTB is not migrated, so this patch adds it in
|
|
|
9bac43 |
the list of the SPRs to migrate, and fixes the problem.
|
|
|
9bac43 |
|
|
|
9bac43 |
For the migration, I've tested a migration from qemu-2.8.0 and
|
|
|
9bac43 |
pseries-2.8.0 to a patched master (qemu-2.11.0-rc1). The received
|
|
|
9bac43 |
VTB is 0 (as is it not initialized by qemu-2.8.0), but the value
|
|
|
9bac43 |
seems to be ignored by KVM and a non zero VTB is used by the kernel.
|
|
|
9bac43 |
I have no explanation for that, but as the original problem appears
|
|
|
9bac43 |
only with SMP system under stress I suspect some problems in KVM
|
|
|
9bac43 |
(I think because VTB is shared by all threads of a core).
|
|
|
9bac43 |
|
|
|
9bac43 |
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
|
|
|
9bac43 |
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
|
|
9bac43 |
(cherry picked from commit 6dd836f5d32b989e18c6dda655a26f4d73a52f6a)
|
|
|
9bac43 |
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
|
|
|
9bac43 |
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
|
|
|
9bac43 |
---
|
|
|
9bac43 |
target/ppc/translate_init.c | 4 ++--
|
|
|
9bac43 |
1 file changed, 2 insertions(+), 2 deletions(-)
|
|
|
9bac43 |
|
|
|
9bac43 |
diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c
|
|
|
9bac43 |
index 371bbae..9d38882 100644
|
|
|
9bac43 |
--- a/target/ppc/translate_init.c
|
|
|
9bac43 |
+++ b/target/ppc/translate_init.c
|
|
|
9bac43 |
@@ -8168,10 +8168,10 @@ static void gen_spr_power8_ebb(CPUPPCState *env)
|
|
|
9bac43 |
/* Virtual Time Base */
|
|
|
9bac43 |
static void gen_spr_vtb(CPUPPCState *env)
|
|
|
9bac43 |
{
|
|
|
9bac43 |
- spr_register(env, SPR_VTB, "VTB",
|
|
|
9bac43 |
+ spr_register_kvm(env, SPR_VTB, "VTB",
|
|
|
9bac43 |
SPR_NOACCESS, SPR_NOACCESS,
|
|
|
9bac43 |
&spr_read_tbl, SPR_NOACCESS,
|
|
|
9bac43 |
- 0x00000000);
|
|
|
9bac43 |
+ KVM_REG_PPC_VTB, 0x00000000);
|
|
|
9bac43 |
}
|
|
|
9bac43 |
|
|
|
9bac43 |
static void gen_spr_power8_fscr(CPUPPCState *env)
|
|
|
9bac43 |
--
|
|
|
9bac43 |
1.8.3.1
|
|
|
9bac43 |
|