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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
