Re: [RFC PATCH 1/5] lguest: mmap backing file

[Anthony Liguori <anthony@codemonkey.ws>]

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/