From patchwork Wed Aug 21 07:02:39 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Graf X-Patchwork-Id: 268690 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id ED50F2C0105 for ; Wed, 21 Aug 2013 17:02:52 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752364Ab3HUHCp (ORCPT ); Wed, 21 Aug 2013 03:02:45 -0400 Received: from cantor2.suse.de ([195.135.220.15]:55056 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752359Ab3HUHCn convert rfc822-to-8bit (ORCPT ); Wed, 21 Aug 2013 03:02:43 -0400 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E81BDA52BF; Wed, 21 Aug 2013 09:02:41 +0200 (CEST) Subject: Re: [PATCH] target-ppc: Update slb array with correct index values. Mime-Version: 1.0 (Apple Message framework v1278) From: Alexander Graf In-Reply-To: <87wqngjwi7.fsf@linux.vnet.ibm.com> Date: Wed, 21 Aug 2013 08:02:39 +0100 Cc: kvm-ppc@vger.kernel.org, "kvm@vger.kernel.org list" Message-Id: References: <1376245011-20008-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <8810AF54-BB64-4313-AD32-C42608527B38@suse.de> <874nam5ei5.fsf@linux.vnet.ibm.com> <87wqngjwi7.fsf@linux.vnet.ibm.com> To: "Aneesh Kumar K.V" X-Mailer: Apple Mail (2.1278) Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org On 20.08.2013, at 14:57, Aneesh Kumar K.V wrote: > Alexander Graf writes: > >> On 19.08.2013, at 09:25, Aneesh Kumar K.V wrote: >> >>> Alexander Graf writes: >>> >>>> On 11.08.2013, at 20:16, Aneesh Kumar K.V wrote: >>>> >>>>> From: "Aneesh Kumar K.V" >>>>> >>>>> Without this, a value of rb=0 and rs=0, result in us replacing the 0th index >>>>> >>>>> Signed-off-by: Aneesh Kumar K.V >>>> >>>> Wrong mailing list again ;). >>> >>> Will post the series again with updated commit message to the qemu list. >>> >>>> >>>>> --- >>>>> target-ppc/kvm.c | 14 ++++++++++++-- >>>>> 1 file changed, 12 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c >>>>> index 30a870e..5d4e613 100644 >>>>> --- a/target-ppc/kvm.c >>>>> +++ b/target-ppc/kvm.c >>>>> @@ -1034,8 +1034,18 @@ int kvm_arch_get_registers(CPUState *cs) >>>>> /* Sync SLB */ >>>>> #ifdef TARGET_PPC64 >>>>> 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; >>>>> + /* >>>>> + * KVM_GET_SREGS doesn't retun slb entry with slot information >>>>> + * same as index. So don't depend on the slot information in >>>>> + * the returned value. >>>> >>>> This is the generating code in book3s_pr.c: >>>> >>>> if (vcpu->arch.hflags & BOOK3S_HFLAG_SLB) { >>>> for (i = 0; i < 64; i++) { >>>> sregs->u.s.ppc64.slb[i].slbe = vcpu->arch.slb[i].orige | i; >>>> sregs->u.s.ppc64.slb[i].slbv = vcpu->arch.slb[i].origv; >>>> } >>>> >>>> Where exactly did you see broken slbe entries? >>>> >>> >>> I noticed this when adding support for guest memory dumping via qemu gdb >>> server. Now the array we get would look like below >>> >>> slbe0 slbv0 >>> slbe1 slbv1 >>> 0000 00000 >>> 0000 00000 >> >> Ok, so that's where the problem lies. Why are the entries 0 here? >> Either we try to fetch more entries than we should, we populate >> entries incorrectly or the kernel simply returns invalid SLB entry >> values for invalid entries. > > > The ioctl zero out the sregs, and fill only slb_max entries. So we find > 0 filled entries above slb_max. Also we don't pass slb_max to user > space. So userspace have to look at all the 64 entries. We do pass slb_max, it's just called differently and calculated implicitly :). How about something like this: > > >> >> Are you seeing this with PR KVM or HV KVM? >> > > HV KVM If the above didn't help, could you please dig out how HV KVM assembles its SLB information and just paste it here? :) Alex --- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index 30a870e..29a2ec3 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -818,6 +818,8 @@ int kvm_arch_put_registers(CPUState *cs, int level) /* Sync SLB */ #ifdef TARGET_PPC64 + /* We need to loop through all entries to give them potentially + valid values */ for (i = 0; i < 64; i++) { sregs.u.s.ppc64.slb[i].slbe = env->slb[i].esid; sregs.u.s.ppc64.slb[i].slbv = env->slb[i].vsid; @@ -1033,7 +1035,7 @@ int kvm_arch_get_registers(CPUState *cs) /* Sync SLB */ #ifdef TARGET_PPC64 - for (i = 0; i < 64; i++) { + for (i = 0; i < env->slb_nr; i++) { ppc_store_slb(env, sregs.u.s.ppc64.slb[i].slbe, sregs.u.s.ppc64.slb[i].slbv); }