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

[Avi Kivity <avi@redhat.com>]

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