On 09/25/2013 05:41 PM, Aneesh Kumar K.V wrote:
Hi Alex,
Any update on this ?
The patch itself never made it to the qemu-devel mailing list which I
pull things off of (through patchworks). Please resend.
Alex
-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