[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 21/21] postcopy: implement postcopy livemigratio
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PATCH 21/21] postcopy: implement postcopy livemigration |
Date: |
Thu, 12 Jan 2012 16:15:42 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 |
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