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

2012-01-12 Thread Avi Kivity 
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

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

2012-01-03 Thread Isaku Yamahata 
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)

thanks,
-- 
yamahata

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

2011-12-29 Thread Avi Kivity 
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.

  

-- 
error compiling committee.c: too many arguments to function