[lkml]   [2008]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 2/6] mmu_notifier: Callbacks to invalidate address ranges
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

 \ /
  Last update: 2008-01-30 20:37    [W:0.176 / U:4.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site