On Wed, 30 Jan 2008, Robin Holt wrote: > I think I need to straighten this discussion out in my head a little bit. > Am I correct in assuming Andrea's original patch set did not have any SMP > race conditions for KVM? If so, then we need to start looking at how to > implement Christoph's and my changes in a safe fashion. Andrea, I agree > complete that our introduction of the range callouts have introduced > SMP races.
The original patch drew the clearing of the sptes into ptep_clear_flush(). So the invalidate_page was called for each page regardless if we had been doing an invalidate range before or not. It seems that the the invalidate_range() was just there for optimization. > The three issues we need to simultaneously solve is revoking the remote > page table/tlb information while still in a sleepable context and not > having the remote faulters become out of sync with the granting process. > Currently, I don't see a way to do that cleanly with a single callout. You could use the invalidate_page callouts to set a flag that no additional rmap entries may be added until the invalidate_range has occurred? We could add back all the original invalidate_pages() and pass a flag that specifies that an invalidate range will follow. The notifier can then decide what to do with that information. If its okay to defer then do nothing and wait for the range_invalidate. XPmem could stop allowing external references to be established until the invalidate_range was successful. Jack had a concern that multiple callouts for the same pte could cause problems. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
