Hi Alex,
Any update on this ?
-aneesh
"Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> writes:
> 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>
> ---
> 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 30a870e..1838465 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.2
