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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
