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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
