From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53010 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OEQ7y-0004Ii-Bv for qemu-devel@nongnu.org; Tue, 18 May 2010 12:58:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OEQ7t-0003Hw-U1 for qemu-devel@nongnu.org; Tue, 18 May 2010 12:58:46 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:65342) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OEQ7t-0003HP-Qe for qemu-devel@nongnu.org; Tue, 18 May 2010 12:58:41 -0400 Received: by vws1 with SMTP id 1so1983491vws.4 for ; Tue, 18 May 2010 09:58:39 -0700 (PDT) MIME-Version: 1.0 Sender: camm@ualberta.ca In-Reply-To: <4BE839BD.1060502@codemonkey.ws> References: <1271872408-22842-1-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-3-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-4-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-5-git-send-email-cam@cs.ualberta.ca> <4BE7F517.5010707@redhat.com> <4BE82623.4000905@redhat.com> <4BE82877.1040408@codemonkey.ws> <4BE839BD.1060502@codemonkey.ws> Date: Tue, 18 May 2010 10:58:39 -0600 Message-ID: From: Cam Macdonell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Anthony Liguori Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On Mon, May 10, 2010 at 10:52 AM, Anthony Liguori w= rote: >> Yes, I think the ack is the way to go, so the guest has to be aware of >> it. =A0Would setting a flag in the driver-specific config space be an >> acceptable ack that the shared region is now mapped? >> > > You know it's mapped because it's mapped when the pci map function return= s. > =A0You don't need the guest to explicitly tell you. > I've been playing with migration. It appears that the memory is preserved on migration in the default case which makes sense as it is part of the qemu memory allocation. In my current implementation, I "map" the shared memory in by calling cpu_register_physical_memory() with the offset returned from qemu_ram_map(). My question is how to I unregister the physical memory so it is not copied on migration (for the role=3Dpeer case). There isn't a cpu_unregister_physical_memory(). Cam