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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
