Re: KVM: MMU: add KVM_ZAP_GFN ioctl

[Marcelo Tosatti <marcelo@kvack.org>]

On Fri, Mar 21, 2008 at 12:42:14PM +0100, Andrea Arcangeli wrote:
> On Thu, Mar 20, 2008 at 02:09:15PM +0200, Avi Kivity wrote:
> > Marcelo Tosatti wrote:
> > > Add an ioctl to zap all mappings to a given gfn. This allows userspace
> > > remove the QEMU process mappings and the page without causing
> > > inconsistency.
> > >
> > >   
> > 
> > I'm thinking of comitting rmap_nuke() to kvm.git, and the rest to the 
> > external module, since this is only needed on kernels without mmu notifiers.
> > 
> > Andrea, is rmap_nuke() suitable for the mmu notifiers pte clear callback?
> 
> There's the usual smp race condition. The tlb must be flushed before
> the final put_page in rmap_remove. And it can't be safe to call this
> ioctl before sys_munmap(), so this would be the final put_page.
> 
> My kvm_unmap_hva takes care of that.

This is not the final put_page().

Remote TLB's are flushed here, after rmap_remove:

+       if (nuked)
+               kvm_flush_remote_tlbs(kvm);

This ioctl is called before zap_page_range() is executed through
sys_madvise(MADV_DONTNEED) to remove the page in question.

We know that the guest will not attempt to fault in the gfn because
the virtio balloon driver is synchronous (it will only attempt to
release that page back to the guest OS once rmap_nuke+zap_page_range has
finished).

Can you be more verbose?

By the way, I don't see invalidate_begin/invalidate_end hooks in the KVM 
part of MMU notifiers V9 patch? (meaning that zap_page_range will not zap
the spte's for the pages in question).

Thanks

-------------------------------------------------------------------------
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/