fork() within a VM with MMU notifiers

[Anthony Liguori <aliguori@us.ibm.com>]

Here's my thinking as to why we don't want to destroy the VM in the mmu 
notifiers ->release method.  I don't have a valid use-case for this but 
my argument depends on the fact that this is something that should 
work.  Daemonizing a running VM may be a reasonable use-case.  It's 
useful to wait to daemonize until you are sure that everything is 
working correctly so it's not all that unreasonable to move the 
daemonize until after the VCPUs have been launched.

If you take a running VM, and pause all of the VCPUs, and then issue a 
fork() followed by an immediate exit() in the parent process, the child 
process should be able to unpause all the VCPUs and the guest should 
continue running uninterrupted.

 From KVM's perspective, issuing the fork() will increment the reference 
count of the file descriptor for the VM but otherwise, no real change 
should happen.  The issue would now be that we must completely flush the 
shadow page table cache.  In theory, MMU notifiers should do this for us.

When the parent process exits, this will result in exit_mmap() and will 
destroy the KVM guest.  This leaves the child process with a file 
descriptor that refers to a VM that is no longer valid.

Just avoiding destroying the VM in the ->release() method won't fix this 
use-case I don't think.  In general, I think we need to think a little 
more about how fork() is handled with respect to mmu notifiers.

Regards,

Anthony Liguori

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone