Re: [Qemu-devel] [PATCH 21/21] postcopy: implement postcopy livemigration

[Avi Kivity <avi@redhat.com>]

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