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

Anthony Liguori
2008-03-20T23:46:39Z

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.