qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device
Date: Tue, 11 May 2010 10:55:28 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

On 05/10/2010 08:25 PM, Anthony Liguori wrote:
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?

(presuming you mean multiple writers?)

This is a surprising take. What's the use of a single master shared memory area?

Most uses of shared memory among processes or threads are multi-master. One use case can be a shared cache among the various guests.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]