Paul Mackerras <paulus@xxxxxxxxxx> writes: > 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. You're right it does. We have code in xmon that reads entries and then checks for SLB_ESID_V, but I guess that's just overly pessimistic. cheers -- 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
