On Tue, Sep 26, 2017 at 03:24:05PM +1000, Michael Ellerman wrote: > David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> writes: > > > On Fri, Sep 22, 2017 at 11:34:29AM +0200, Greg Kurz wrote: > >> Userland passes an array of 64 SLB descriptors to KVM_SET_SREGS, > >> some of which are valid (ie, SLB_ESID_V is set) and the rest are > >> likely all-zeroes (with QEMU at least). > >> > >> Each of them is then passed to kvmppc_mmu_book3s_64_slbmte(), which > >> assumes to find the SLB index in the 3 lower bits of its rb argument. > >> When passed zeroed arguments, it happily overwrites the 0th SLB entry > >> with zeroes. This is exactly what happens while doing live migration > >> with QEMU when the destination pushes the incoming SLB descriptors to > >> KVM PR. When reloading the SLBs at the next synchronization, QEMU first > >> clears its SLB array and only restore valid ones, but the 0th one is > >> now gone and we cannot access the corresponding memory anymore: > >> > >> (qemu) x/x $pc > >> c0000000000b742c: Cannot access memory > >> > >> To avoid this, let's filter out non-valid SLB entries, like we > >> already do for Book3S HV. > >> > >> Signed-off-by: Greg Kurz <groug@xxxxxxxx> > > > > This seems like a good idea, but to make it fully correct, don't we > > also need to fully flush the SLB before inserting the new entries. > > We would need to do that yeah. > > But I don't think I like this patch, it would mean userspace has no way > of programming an invalid SLB entry. It's true that in general that > isn't something we care about doing, but the API should allow it. > > For example the kernel could leave invalid entries in place and flip the > valid bit when it wanted to make them valid, and this patch would > prevent that state being successfully migrated IIUIC. If I remember correctly, the architecture says that slbmfee/slbmfev return all zeroes for an invalid entry, so there would be no way for the guest kernel to do what you suggest. Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
