Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm

[Anthony Liguori]

On 05/25/2010 09:01 AM, Avi Kivity wrote:
> On 05/25/2010 04:55 PM, Anthony Liguori wrote:
> > On 05/25/2010 08:38 AM, Avi Kivity wrote:
> > > On 05/25/2010 04:35 PM, Anthony Liguori wrote:
> > > > On 05/25/2010 08:31 AM, Avi Kivity wrote:
> > > > > > A protocol based mechanism has the advantage of being more robust 
> > > > > > in the face of poorly written block backends so if it's possible 
> > > > > > to make it perform as well as a plugin, it's a preferable approach.
> > > > >
> > > > > May be hard due to difficulty of exposing guest memory.
> > > >
> > > > If someone did a series to add plugins, I would expect a very 
> > > > strong argument as to why a shared memory mechanism was not 
> > > > possible or at least plausible.
> > > >
> > > > I'm not sure I understand why shared memory is such a bad thing wrt 
> > > > KVM.  Can you elaborate?  Is it simply a matter of fork()?
> > >
> > > fork() doesn't work in the with of memory hotplug.  What else is there?
> >
> > Is it that fork() doesn't work or is it that fork() is very expensive?
>
> It doesn't work, fork() is done at block device creation time, which 
> freezes the child memory map, while guest memory is allocated at 
> hotplug time.

Now I'm confused.  I thought you were saying shared memory somehow 
affects fork().  If you're talking about shared memory inheritance via 
fork(), that's less important.  You can also pass /dev/shm fd's via 
SCM_RIGHTs to establish shared memory segments dynamically.

Regards,

Anthony Liguori

> fork() actually isn't very expensive since we use MADV_DONTFORK 
> (probably fast enough for everything except realtime).
>
> It may be possible to do a processfd() which can be mmap()ed by 
> another process to export anonymous memory using mmu notifiers, not 
> sure how easy or mergeable that is.