[Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device

[Avi Kivity]

On 05/10/2010 06:38 PM, Anthony Liguori wrote:
> > > Otherwise, if the BAR is allocated during initialization, I would have
> > > to use MAP_FIXED to mmap the memory.  This is what I did before the
> > > qemu_ram_mmap() function was added.
> >
> > What would happen to any data written to the BAR before the the 
> > handshake completed?  I think it would disappear.
>
> You don't have to do MAP_FIXED.  You can allocate a ram area and map 
> that in when disconnected.  When you connect, you create another ram 
> area and memcpy() the previous ram area to the new one.  You then map 
> the second ram area in.

But it's a shared memory area.  Other peers could have connected and 
written some data in.  The memcpy() would destroy their data.

> From the guest's perspective, it's totally transparent.  For the 
> backend, I'd suggest having an explicit "initialized" ack or something 
> so that it knows that the data is now mapped to the guest.

From the peers' perspective, it's non-transparent :(

Also it doubles the transient memory requirement.

> If you're doing just a ring queue in shared memory, it should allow 
> disconnect/reconnect during live migration asynchronously to the 
> actual qemu live migration.

Live migration of guests using shared memory is interesting.  You'd need 
to freeze all peers on one node, disconnect, reconnect, and restart them 
on the other node.

--
error compiling committee.c: too many arguments to function