On 02/23/2011 11:46 PM, Alex Williamson wrote:
> > But kvm_arch_flush_shadow() takes mmu_lock currently, so that needs > fixing. Hmm, I tried to follow the example in the !npages path just above this that does: rcu_assign_pointer() synchronize_srcu_expedited() kvm_arch_flush_shadow() Do we have an existing issue there with mmu_lock? Thanks,
It's the issue I pointed out - after rcu_assign_pointer and before kvm_arch_flush_shadow() we can still get shadow pages created, so we have a mix of direct and indirect bitmap. Either my solution (recording whether the bitmap is direct or not in kvm_mmu_page) or Marcelo's (preventing shadow instantiation during this period) should work.
Hmm, your patch dereferences kvm->memslots without rcu_dereference(). That's a mortal (as in oops) sin. Note that sticking an rcu_dereference() blindly may or may not work - we might end up using information from two different generations of kvm->memslots, and using inconsistent data.
-- error compiling committee.c: too many arguments to function -- 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
