On Fri, Aug 24, 2012 at 07:29:53PM +1000, Paul Mackerras wrote: > On Thu, Aug 23, 2012 at 10:55:37AM -0300, Marcelo Tosatti wrote: > > > There are a number of options to consider: > > > > 1) Merge the current patchset from Paul, which has two downsides: > > 1-1) It contains an unfixable race. > > The race being that new HTPEs using the old base address could get > inserted after we flush the old HPTEs and before we update the memslot > array? Yes. That race, for the slot deletion case, is fixed by RCU assignment of memslot marked with KVM_MEMSLOT_INVALID. For the base change case, x86 flushes all translations via the kvm_arch_flush_shadow() at the of __kvm_set_memory. Which is not enough for PPC since you need to flush _before_ new memslot is visible. > I think we could solve that one by temporarily marking the memslot > invalid for changes of base_gfn as well as for memslot deletions. Can > you see any problem with that? It means that guest accesses to the > old memslot addresses would trap or fail, but if the guest is trying > to access a device while its BAR is being changed, then I think it > deserves that. No, i don't see any problem with that. Sent a patchset. -- 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
