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

[Anthony Liguori <anthony@codemonkey.ws>]

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