mirror of
https://github.com/qemu/qemu.git
synced 2024-12-04 09:13:39 +08:00
ppc: fix VTB migration
Migration of a system under stress (for example, with "stress-ng --numa 2") triggers on the destination some kernel watchdog messages like: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 3489660870s! NMI watchdog: BUG: soft lockup - CPU#1 stuck for 3489660884s! This problem appears with the changes introduced by42043e4
spapr: clock should count only if vm is running I think this commit only triggers the problem. Kernel computes the soft lockup duration using the Virtual Timebase register (VTB), not using the Timebase Register (TBR, the one42043e4
stops). It appears VTB is not migrated, so this patch adds it in the list of the SPRs to migrate, and fixes the problem. For the migration, I've tested a migration from qemu-2.8.0 and pseries-2.8.0 to a patched master (qemu-2.11.0-rc1). The received VTB is 0 (as is it not initialized by qemu-2.8.0), but the value seems to be ignored by KVM and a non zero VTB is used by the kernel. I have no explanation for that, but as the original problem appears only with SMP system under stress I suspect some problems in KVM (I think because VTB is shared by all threads of a core). Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This commit is contained in:
parent
6c3bc244d3
commit
6dd836f5d3
@ -8081,10 +8081,10 @@ static void gen_spr_power8_ebb(CPUPPCState *env)
|
||||
/* Virtual Time Base */
|
||||
static void gen_spr_vtb(CPUPPCState *env)
|
||||
{
|
||||
spr_register(env, SPR_VTB, "VTB",
|
||||
spr_register_kvm(env, SPR_VTB, "VTB",
|
||||
SPR_NOACCESS, SPR_NOACCESS,
|
||||
&spr_read_tbl, SPR_NOACCESS,
|
||||
0x00000000);
|
||||
KVM_REG_PPC_VTB, 0x00000000);
|
||||
}
|
||||
|
||||
static void gen_spr_power8_fscr(CPUPPCState *env)
|
||||
|
Loading…
Reference in New Issue
Block a user