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

[Anthony Liguori]

On 05/10/2010 11:59 AM, Avi Kivity wrote:
> 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.

Why try to attempt to support multi-master shared memory?  What's the 
use-case?

Regards,

Anthony Liguori

> > 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.