On Mon, Aug 13, 2012 at 01:34:11PM -0300, Marcelo Tosatti wrote: > On Sat, Aug 11, 2012 at 10:37:54AM +1000, Paul Mackerras wrote: > > In fact I need to remove any translations in the old range *before* > > the new memslot gets committed, whereas this happens after that. > > This is why I was doing the flush in kvm_arch_prepare_memory_region. > > I see. The problem with that is, given that the fault path (reader > of memslots) is protected only by SRCU, the following window is open: > > A) kvm_arch_prepare_memory_region > B) rcu_assign_pointer(kvm->memslots, slots) > C) kvm_arch_commit_memory_region > > The window between A and B where a guest pagefault can instantiate a new > translation using the old memslot information (while you already removed > any translations in the old range). Yes, good point. > Avi, Gleb, Alex, do you know why it is necessary to support change of > GPA base again? > > Without taking into consideration backwards compatibility, userspace > can first delete the slot and later create a new one. I like this approach. :) > > If the new memslot got committed while there were still some > > translations left in the hardware page table, it's possible that the > > guest could ask to remove one of those hardware PTEs. As part of that > > process, I get the GPA that the HPTE referred to, look up which > > memslot it belongs to, and use the offset from the base_gfn of the > > memslot to index into the memslot's rmap array. If the base_gfn has > > been changed then I will hit the wrong rmap entry, or possibly not > > find the memslot at all, and bad things will happen. > > So, that notification before-commit-of-new-memslot is only necessary for > base change, correct? That is, you don't need that pre notification for > entirely new memslots in a previously unpopulated range. Correct. Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
