From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 21/21] postcopy: implement postcopy livemigration Date: Thu, 12 Jan 2012 16:15:42 +0200 Message-ID: <4F0EEB0E.6080308@redhat.com> References: <4EFC8FF2.4050702@redhat.com> <20120104032934.GM19274@valinux.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, t.hirofuchi@aist.go.jp, satoshi.itoh@aist.go.jp To: Isaku Yamahata Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35415 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753559Ab2ALOPw (ORCPT ); Thu, 12 Jan 2012 09:15:52 -0500 In-Reply-To: <20120104032934.GM19274@valinux.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 01/04/2012 05:29 AM, Isaku Yamahata wrote: > On Thu, Dec 29, 2011 at 06:06:10PM +0200, Avi Kivity wrote: > > On 12/29/2011 03:26 AM, Isaku Yamahata wrote: > > > This patch implements postcopy livemigration. > > > > > > > > > +/* RAM is allocated via umem for postcopy incoming mode */ > > > +#define RAM_POSTCOPY_UMEM_MASK (1 << 1) > > > + > > > typedef struct RAMBlock { > > > uint8_t *host; > > > ram_addr_t offset; > > > @@ -485,6 +488,10 @@ typedef struct RAMBlock { > > > #if defined(__linux__) && !defined(TARGET_S390X) > > > int fd; > > > #endif > > > + > > > +#ifdef CONFIG_POSTCOPY > > > + UMem *umem; /* for incoming postcopy mode */ > > > +#endif > > > } RAMBlock; > > > > Is it possible to implement this via the MemoryListener API (which > > replaces CPUPhysMemoryClient)? This is how kvm, vhost, and xen manage > > their memory tables. > > I'm afraid no. Those three you listed above are for outgoing part, > but this case is for incoming part. The requirement is quite different > from those three. What is needed is > - get the corresponding RAMBlock and UMem from (id, idlen) > - hook ram_alloc/ram_free (or RAM api corresponding) > Okay. We'll need more hooks then. Xen already hooks qemu_ram_alloc(), so there's more than one user. But don't spend time on this; this area is in flux due to the memory API, so any effort will be wasted. I'll look at adding those hooks, either before or after postcopy is merged. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlLRY-0002VK-3y for qemu-devel@nongnu.org; Thu, 12 Jan 2012 09:15:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RlLRX-0008Rb-0E for qemu-devel@nongnu.org; Thu, 12 Jan 2012 09:15:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:14212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlLRW-0008RS-Pp for qemu-devel@nongnu.org; Thu, 12 Jan 2012 09:15:50 -0500 Message-ID: <4F0EEB0E.6080308@redhat.com> Date: Thu, 12 Jan 2012 16:15:42 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4EFC8FF2.4050702@redhat.com> <20120104032934.GM19274@valinux.co.jp> In-Reply-To: <20120104032934.GM19274@valinux.co.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 21/21] postcopy: implement postcopy livemigration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Isaku Yamahata Cc: t.hirofuchi@aist.go.jp, qemu-devel@nongnu.org, kvm@vger.kernel.org, satoshi.itoh@aist.go.jp On 01/04/2012 05:29 AM, Isaku Yamahata wrote: > On Thu, Dec 29, 2011 at 06:06:10PM +0200, Avi Kivity wrote: > > On 12/29/2011 03:26 AM, Isaku Yamahata wrote: > > > This patch implements postcopy livemigration. > > > > > > > > > +/* RAM is allocated via umem for postcopy incoming mode */ > > > +#define RAM_POSTCOPY_UMEM_MASK (1 << 1) > > > + > > > typedef struct RAMBlock { > > > uint8_t *host; > > > ram_addr_t offset; > > > @@ -485,6 +488,10 @@ typedef struct RAMBlock { > > > #if defined(__linux__) && !defined(TARGET_S390X) > > > int fd; > > > #endif > > > + > > > +#ifdef CONFIG_POSTCOPY > > > + UMem *umem; /* for incoming postcopy mode */ > > > +#endif > > > } RAMBlock; > > > > Is it possible to implement this via the MemoryListener API (which > > replaces CPUPhysMemoryClient)? This is how kvm, vhost, and xen manage > > their memory tables. > > I'm afraid no. Those three you listed above are for outgoing part, > but this case is for incoming part. The requirement is quite different > from those three. What is needed is > - get the corresponding RAMBlock and UMem from (id, idlen) > - hook ram_alloc/ram_free (or RAM api corresponding) > Okay. We'll need more hooks then. Xen already hooks qemu_ram_alloc(), so there's more than one user. But don't spend time on this; this area is in flux due to the memory API, so any effort will be wasted. I'll look at adding those hooks, either before or after postcopy is merged. -- error compiling committee.c: too many arguments to function