On Wed, Aug 21, 2013 at 08:37:47AM +0100, Alexander Graf wrote: > > On 21.08.2013, at 06:11, Paul Mackerras wrote: > > > On Mon, Aug 19, 2013 at 10:21:09AM +0200, Alexander Graf wrote: > >> > >> On 19.08.2013, at 09:25, Aneesh Kumar K.V wrote: > >>> 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. > >> > >> Are you seeing this with PR KVM or HV KVM? > > > > I suspect this is to do with the fact that PR and HV KVM use the > > vcpu->arch.slb[] array differently. PR stores SLB entry n in > > vcpu->arch.slb[n], whereas HV packs the valid entries down in the > > low-numbered entries and puts the index in the bottom bits of the esid > > field (this is so they can be loaded efficiently with the slbmte > > instruction on guest entry). > > > > Then, kvm_arch_vcpu_ioctl_get_sregs() on PR copies out all 64 entries > > (valid or not) and puts an index value in the bottom bits of the esid, > > whereas on HV it just copies out the valid entries (which already have > > the index in the esid field). > > > > So, the question is, what is the ABI here? It sounds a bit like qemu > > is ignoring the index value in the esid field. Either qemu needs to > > take notice of the index in the esid field or we need to change the HV > > versions of kvm_arch_vcpu_ioctl_get/set_sregs to put entry n in > > sregs->u.s.ppc64.slb[n] like PR does. > > It's the opposite today - QEMU does honor the index value on sregs get. > Aneesh's patch wants to change it to ignore it instead. For sregs set we copy > our internal copy of the slb linearly into the array, so we don't pack it > there. > > Can we safely assume on HV KVM that esid == 0 vsid == 0 is the end of the > list? If so, we can just add a break statement in the get loop and call it a > day. The rest should work just fine.
On HV KVM yes, that would be the end of the list, but PR KVM could give you entry 0 containing esid==0 and vsid==0 followed by valid entries. Perhaps the best approach is to ignore any entries with SLB_ESID_V clear. Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
