From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48632 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBqpg-0001I6-N8 for qemu-devel@nongnu.org; Tue, 11 May 2010 10:53:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBqpe-0002Qd-VN for qemu-devel@nongnu.org; Tue, 11 May 2010 10:53:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15448) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBqpe-0002QM-Mf for qemu-devel@nongnu.org; Tue, 11 May 2010 10:53:14 -0400 Message-ID: <4BE96F50.1040506@redhat.com> Date: Tue, 11 May 2010 17:53:04 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1271872408-22842-1-git-send-email-cam@cs.ualberta.ca> <4BE82623.4000905@redhat.com> <4BE82877.1040408@codemonkey.ws> <4BE83B69.4040904@redhat.com> <4BE84172.9080305@codemonkey.ws> <4BE847CB.7050503@codemonkey.ws> <4BE90E6D.7070007@redhat.com> <4BE9572B.3010104@codemonkey.ws> <4BE963C9.9090308@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cam Macdonell Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org On 05/11/2010 05:17 PM, Cam Macdonell wrote: > >> The master is the shared memory area. It's a completely separate entity >> that is represented by the backing file (or shared memory server handing out >> the fd to mmap). It can exists independently of any guest. >> > I think the master/peer idea would be necessary if we were sharing > guest memory (sharing guest A's memory with guest B). Then if the > master (guest A) dies, perhaps something needs to happen to preserve > the memory contents. Definitely. But we aren't... > But since we're sharing host memory, the > applications in the guests can race to determine the master by > grabbing a lock at offset 0 or by using lowest VM ID. > > Looking at it another way, it is the applications using shared memory > that may or may not need a master, the Qemu processes don't need the > concept of a master since the memory belongs to the host. > Exactly. Furthermore, even in a master/slave relationship, there will be different masters for different sub-areas, it would be a pity to expose all this in the hardware abstraction. This way we have an external device, and PCI HBAs which connect to it - just like a multi-tailed SCSI disk. -- error compiling committee.c: too many arguments to function