From: "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> Without this, a value of rb=0 and rs=0 results in replacing the 0th index. This can be observed when using gdb remote debugging support.
(gdb) x/10i do_fork 0xc000000000085330 <do_fork>: Cannot access memory at address 0xc000000000085330 (gdb) This is because when we do the slb sync via kvm_cpu_synchronize_state, we overwrite the slb entry (0th entry) for 0xc000000000085330 Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com> Signed-off-by: Alexander Graf <ag...@suse.de> --- target-ppc/kvm.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index 0b5d391..e2f8b03 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -1033,9 +1033,22 @@ int kvm_arch_get_registers(CPUState *cs) /* Sync SLB */ #ifdef TARGET_PPC64 + /* + * The packed SLB array we get from KVM_GET_SREGS only contains + * information about valid entries. So we flush our internal + * copy to get rid of stale ones, then put all valid SLB entries + * back in. + */ + memset(env->slb, 0, sizeof(env->slb)); for (i = 0; i < 64; i++) { - ppc_store_slb(env, sregs.u.s.ppc64.slb[i].slbe, - sregs.u.s.ppc64.slb[i].slbv); + target_ulong rb = sregs.u.s.ppc64.slb[i].slbe; + target_ulong rs = sregs.u.s.ppc64.slb[i].slbv; + /* + * Only restore valid entries + */ + if (rb & SLB_ESID_V) { + ppc_store_slb(env, rb, rs); + } } #endif -- 1.8.1.4