Rusty Russell wrote: > How odd! Do you have any idea why? > Nope, but part of the reason I did this was I recalled a similar discussion relating to kqemu and why it used /dev/shm. I thought it was only an issue with older kernels but apparently not.
>> /dev/shm is not really for general use. I think we'll want to have our >> own tmpfs mount that we use to create VM images. >> > > If we're going to mod the kernel, how about a "mmap this part of their > address > space" and having the kernel keep the mappings in sync. But I think that if > we want to get speed, we should probably be doing the copy between address > spaces in-kernel so we can do lightweight exits. > I don't think lightweight exits help the situation very much. The difference between a light weight and heavy weight exit is only 3-4k cycles or so. in-kernel doesn't make the situation much easier. You have to map pages in from a different task. It's a lot easier if you have both guest mapped in userspace. >> I also prefer to use a >> unix socket for communication, unlink the file immediately after open, >> and then pass the fd via SCM_RIGHTS to the other process. >> > > Yeah, I shied away from that because cred passing kills whole litters of > puppies. It makes for better encapsulation tho, so I'd do it that way in a > serious implementation. > I'm working on an implementation for KVM at the moment. Instead of just supporting two guests, I'm looking to support N-guests and provide a simple switch. I'll have patches soon. Regards, Anthony Liguori > Cheers, > Rusty. > ------------------------------------------------------------------------- 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
