[Qemu-devel] [PATCH v11 00/15] rdma: migration support

[Qemu-devel] [PATCH v11 00/15] rdma: migration support

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

Changes since v10: Detailed breakout of required state machine changes

- Fix tags. Only #13, 14, and 15 need reviews. Rest are completed.
- Patch #13: allow state transitions between other states besides ACTIVE
- Patch #14: introduce MIG_STATE_NONE and change MIG_STATE_SETUP transition
- Patch #15: account for the time spent in MIG_STATE_SETUP through QMP

Wiki: http://wiki.qemu.org/Features/RDMALiveMigration
Github: git@github.com:hinesmr/qemu.git

Here is a brief summary of total migration time and downtime using RDMA:

Using a 40gbps infiniband link performing a worst-case stress test,
using an 8GB RAM virtual machine:
Using the following command:

$ apt-get install stress
$ stress --vm-bytes 7500M --vm 1 --vm-keep

RESULTS:

1. Migration throughput: 26 gigabits/second.
2. Downtime (stop time) varies between 15 and 100 milliseconds.

EFFECTS of memory registration on bulk phase round:

For example, in the same 8GB RAM example with all 8GB of memory in 
active use and the VM itself is completely idle using the same 40 gbps 
infiniband link:

1. x-rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
2. x-rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps

These numbers would of course scale up to whatever size virtual machine
you have to migrate using RDMA.

Enabling this feature does *not* have any measurable affect on 
migration *downtime*. This is because, without this feature, all of the 
memory will have already been registered already in advance during
the bulk round and does not need to be re-registered during the successive
iteration rounds.

----------------------------------------------------------------
Michael R. Hines (15):
  rdma: add documentation
  rdma: introduce qemu_update_position()
  rdma: export yield_until_fd_readable()
  rdma: export throughput w/ MigrationStats QMP
  rdma: introduce qemu_file_mode_is_not_valid()
  rdma: export qemu_fflush()
  rdma: introduce ram_handle_compressed()
  rdma: introduce qemu_ram_foreach_block()
  rdma: new QEMUFileOps hooks
  rdma: introduce capability x-rdma-pin-all
  rdma: core logic
  rdma: send pc.ram
  rdma: allow state transitions between other states besides ACTIVE
  rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state
    transition
  rdma: account for the time spent in MIG_STATE_SETUP through QMP

 Makefile.objs                 |    1 +
 arch_init.c                   |   69 +-
 configure                     |   29 +
 docs/rdma.txt                 |  415 ++++++
 exec.c                        |    9 +
 hmp.c                         |   12 +-
 include/block/coroutine.h     |    6 +
 include/exec/cpu-common.h     |    5 +
 include/migration/migration.h |   32 +
 include/migration/qemu-file.h |   32 +
 migration-rdma.c              | 2819 +++++++++++++++++++++++++++++++++++++++++
 migration.c                   |   64 +-
 qapi-schema.json              |   21 +-
 qemu-coroutine-io.c           |   23 +
 savevm.c                      |  114 +-
 15 files changed, 3589 insertions(+), 62 deletions(-)
 create mode 100644 docs/rdma.txt
 create mode 100644 migration-rdma.c

-- 
1.7.10.4

[Qemu-devel] [PATCH v11 01/15] rdma: add documentation

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

docs/rdma.txt contains full documentation,
wiki links, github url and contact information.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 docs/rdma.txt |  415 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 415 insertions(+)
 create mode 100644 docs/rdma.txt

diff --git a/docs/rdma.txt b/docs/rdma.txt
new file mode 100644
index 0000000..09d36ef
--- /dev/null
+++ b/docs/rdma.txt
@@ -0,0 +1,415 @@
+(RDMA: Remote Direct Memory Access)
+RDMA Live Migration Specification, Version # 1
+==============================================
+Wiki: http://wiki.qemu.org/Features/RDMALiveMigration
+Github: git@github.com:hinesmr/qemu.git, 'rdma' branch
+
+Copyright (C) 2013 Michael R. Hines <mrhines@us.ibm.com>
+
+An *exhaustive* paper (2010) shows additional performance details
+linked on the QEMU wiki above.
+
+Contents:
+=========
+* Introduction
+* Before running
+* Running
+* Performance
+* RDMA Migration Protocol Description
+* Versioning and Capabilities
+* QEMUFileRDMA Interface
+* Migration of pc.ram
+* Error handling
+* TODO
+
+Introduction:
+=============
+
+RDMA helps make your migration more deterministic under heavy load because
+of the significantly lower latency and higher throughput over TCP/IP. This is
+because the RDMA I/O architecture reduces the number of interrupts and
+data copies by bypassing the host networking stack. In particular, a TCP-based
+migration, under certain types of memory-bound workloads, may take a more
+unpredicatable amount of time to complete the migration if the amount of
+memory tracked during each live migration iteration round cannot keep pace
+with the rate of dirty memory produced by the workload.
+
+RDMA currently comes in two flavors: both Ethernet based (RoCE, or RDMA
+over Convered Ethernet) as well as Infiniband-based. This implementation of
+migration using RDMA is capable of using both technologies because of
+the use of the OpenFabrics OFED software stack that abstracts out the
+programming model irrespective of the underlying hardware.
+
+Refer to openfabrics.org or your respective RDMA hardware vendor for
+an understanding on how to verify that you have the OFED software stack
+installed in your environment. You should be able to successfully link
+against the "librdmacm" and "libibverbs" libraries and development headers
+for a working build of QEMU to run successfully using RDMA Migration.
+
+BEFORE RUNNING:
+===============
+
+Use of RDMA during migration requires pinning and registering memory
+with the hardware. This means that memory must be physically resident
+before the hardware can transmit that memory to another machine.
+If this is not acceptable for your application or product, then the use
+of RDMA migration may in fact be harmful to co-located VMs or other
+software on the machine if there is not sufficient memory available to
+relocate the entire footprint of the virtual machine. If so, then the
+use of RDMA is discouraged and it is recommended to use standard TCP migration.
+
+Experimental: Next, decide if you want dynamic page registration.
+For example, if you have an 8GB RAM virtual machine, but only 1GB
+is in active use, then enabling this feature will cause all 8GB to
+be pinned and resident in memory. This feature mostly affects the
+bulk-phase round of the migration and can be enabled for extremely
+high-performance RDMA hardware using the following command:
+
+QEMU Monitor Command:
+$ migrate_set_capability x-rdma-pin-all on # disabled by default
+
+Performing this action will cause all 8GB to be pinned, so if that's
+not what you want, then please ignore this step altogether.
+
+On the other hand, this will also significantly speed up the bulk round
+of the migration, which can greatly reduce the "total" time of your migration.
+Example performance of this using an idle VM in the previous example
+can be found in the "Performance" section.
+
+Note: for very large virtual machines (hundreds of GBs), pinning all 
+*all* of the memory of your virtual machine in the kernel is very expensive 
+may extend the initial bulk iteration time by many seconds,
+and thus extending the total migration time. However, this will not
+affect the determinism or predictability of your migration you will
+still gain from the benefits of advanced pinning with RDMA.
+
+RUNNING:
+========
+
+First, set the migration speed to match your hardware's capabilities:
+
+QEMU Monitor Command:
+$ migrate_set_speed 40g # or whatever is the MAX of your RDMA device
+
+Next, on the destination machine, add the following to the QEMU command line:
+
+qemu ..... -incoming x-rdma:host:port
+
+Finally, perform the actual migration on the source machine:
+
+QEMU Monitor Command:
+$ migrate -d x-rdma:host:port
+
+PERFORMANCE
+===========
+
+Here is a brief summary of total migration time and downtime using RDMA:
+Using a 40gbps infiniband link performing a worst-case stress test,
+using an 8GB RAM virtual machine:
+
+Using the following command:
+$ apt-get install stress
+$ stress --vm-bytes 7500M --vm 1 --vm-keep
+
+1. Migration throughput: 26 gigabits/second.
+2. Downtime (stop time) varies between 15 and 100 milliseconds.
+
+EFFECTS of memory registration on bulk phase round:
+
+For example, in the same 8GB RAM example with all 8GB of memory in
+active use and the VM itself is completely idle using the same 40 gbps
+infiniband link:
+
+1. x-rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
+2. x-rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps
+
+These numbers would of course scale up to whatever size virtual machine
+you have to migrate using RDMA.
+
+Enabling this feature does *not* have any measurable affect on
+migration *downtime*. This is because, without this feature, all of the
+memory will have already been registered already in advance during
+the bulk round and does not need to be re-registered during the successive
+iteration rounds.
+
+RDMA Protocol Description:
+==========================
+
+Migration with RDMA is separated into two parts:
+
+1. The transmission of the pages using RDMA
+2. Everything else (a control channel is introduced)
+
+"Everything else" is transmitted using a formal
+protocol now, consisting of infiniband SEND messages.
+
+An infiniband SEND message is the standard ibverbs
+message used by applications of infiniband hardware.
+The only difference between a SEND message and an RDMA
+message is that SEND messages cause notifications
+to be posted to the completion queue (CQ) on the
+infiniband receiver side, whereas RDMA messages (used
+for pc.ram) do not (to behave like an actual DMA).
+
+Messages in infiniband require two things:
+
+1. registration of the memory that will be transmitted
+2. (SEND only) work requests to be posted on both
+   sides of the network before the actual transmission
+   can occur.
+
+RDMA messages are much easier to deal with. Once the memory
+on the receiver side is registered and pinned, we're
+basically done. All that is required is for the sender
+side to start dumping bytes onto the link.
+
+(Memory is not released from pinning until the migration
+completes, given that RDMA migrations are very fast.)
+
+SEND messages require more coordination because the
+receiver must have reserved space (using a receive
+work request) on the receive queue (RQ) before QEMUFileRDMA
+can start using them to carry all the bytes as
+a control transport for migration of device state.
+
+To begin the migration, the initial connection setup is
+as follows (migration-rdma.c):
+
+1. Receiver and Sender are started (command line or libvirt):
+2. Both sides post two RQ work requests
+3. Receiver does listen()
+4. Sender does connect()
+5. Receiver accept()
+6. Check versioning and capabilities (described later)
+
+At this point, we define a control channel on top of SEND messages
+which is described by a formal protocol. Each SEND message has a
+header portion and a data portion (but together are transmitted
+as a single SEND message).
+
+Header:
+    * Length  (of the data portion, uint32, network byte order)
+    * Type    (what command to perform, uint32, network byte order)
+    * Repeat  (Number of commands in data portion, same type only)
+
+The 'Repeat' field is here to support future multiple page registrations
+in a single message without any need to change the protocol itself
+so that the protocol is compatible against multiple versions of QEMU.
+Version #1 requires that all server implementations of the protocol must
+check this field and register all requests found in the array of commands located
+in the data portion and return an equal number of results in the response.
+The maximum number of repeats is hard-coded to 4096. This is a conservative
+limit based on the maximum size of a SEND message along with emperical
+observations on the maximum future benefit of simultaneous page registrations.
+
+The 'type' field has 10 different command values:
+    1. Unused
+    2. Error              (sent to the source during bad things)
+    3. Ready              (control-channel is available)
+    4. QEMU File          (for sending non-live device state)
+    5. RAM Blocks request (used right after connection setup)
+    6. RAM Blocks result  (used right after connection setup)
+    7. Compress page      (zap zero page and skip registration)
+    8. Register request   (dynamic chunk registration)
+    9. Register result    ('rkey' to be used by sender)
+    10. Register finished  (registration for current iteration finished)
+
+A single control message, as hinted above, can contain within the data
+portion an array of many commands of the same type. If there is more than
+one command, then the 'repeat' field will be greater than 1.
+
+After connection setup, message 5 & 6 are used to exchange ram block
+information and optionally pin all the memory if requested by the user.
+
+After ram block exchange is completed, we have two protocol-level
+functions, responsible for communicating control-channel commands
+using the above list of values:
+
+Logically:
+
+qemu_rdma_exchange_recv(header, expected command type)
+
+1. We transmit a READY command to let the sender know that
+   we are *ready* to receive some data bytes on the control channel.
+2. Before attempting to receive the expected command, we post another
+   RQ work request to replace the one we just used up.
+3. Block on a CQ event channel and wait for the SEND to arrive.
+4. When the send arrives, librdmacm will unblock us.
+5. Verify that the command-type and version received matches the one we expected.
+
+qemu_rdma_exchange_send(header, data, optional response header & data):
+
+1. Block on the CQ event channel waiting for a READY command
+   from the receiver to tell us that the receiver
+   is *ready* for us to transmit some new bytes.
+2. Optionally: if we are expecting a response from the command
+   (that we have no yet transmitted), let's post an RQ
+   work request to receive that data a few moments later.
+3. When the READY arrives, librdmacm will
+   unblock us and we immediately post a RQ work request
+   to replace the one we just used up.
+4. Now, we can actually post the work request to SEND
+   the requested command type of the header we were asked for.
+5. Optionally, if we are expecting a response (as before),
+   we block again and wait for that response using the additional
+   work request we previously posted. (This is used to carry
+   'Register result' commands #6 back to the sender which
+   hold the rkey need to perform RDMA. Note that the virtual address
+   corresponding to this rkey was already exchanged at the beginning
+   of the connection (described below).
+
+All of the remaining command types (not including 'ready')
+described above all use the aformentioned two functions to do the hard work:
+
+1. After connection setup, RAMBlock information is exchanged using
+   this protocol before the actual migration begins. This information includes
+   a description of each RAMBlock on the server side as well as the virtual addresses
+   and lengths of each RAMBlock. This is used by the client to determine the
+   start and stop locations of chunks and how to register them dynamically
+   before performing the RDMA operations.
+2. During runtime, once a 'chunk' becomes full of pages ready to
+   be sent with RDMA, the registration commands are used to ask the
+   other side to register the memory for this chunk and respond
+   with the result (rkey) of the registration.
+3. Also, the QEMUFile interfaces also call these functions (described below)
+   when transmitting non-live state, such as devices or to send
+   its own protocol information during the migration process.
+4. Finally, zero pages are only checked if a page has not yet been registered
+   using chunk registration (or not checked at all and unconditionally
+   written if chunk registration is disabled. This is accomplished using
+   the "Compress" command listed above. If the page *has* been registered
+   then we check the entire chunk for zero. Only if the entire chunk is
+   zero, then we send a compress command to zap the page on the other side.
+
+Versioning and Capabilities
+===========================
+Current version of the protocol is version #1.
+
+The same version applies to both for protocol traffic and capabilities
+negotiation. (i.e. There is only one version number that is referred to
+by all communication).
+
+librdmacm provides the user with a 'private data' area to be exchanged
+at connection-setup time before any infiniband traffic is generated.
+
+Header:
+    * Version (protocol version validated before send/recv occurs), uint32, network byte order
+    * Flags   (bitwise OR of each capability), uint32, network byte order
+
+There is no data portion of this header right now, so there is
+no length field. The maximum size of the 'private data' section
+is only 192 bytes per the Infiniband specification, so it's not
+very useful for data anyway. This structure needs to remain small.
+
+This private data area is a convenient place to check for protocol
+versioning because the user does not need to register memory to
+transmit a few bytes of version information.
+
+This is also a convenient place to negotiate capabilities
+(like dynamic page registration).
+
+If the version is invalid, we throw an error.
+
+If the version is new, we only negotiate the capabilities that the
+requested version is able to perform and ignore the rest.
+
+Currently there is only *one* capability in Version #1: dynamic page registration
+
+Finally: Negotiation happens with the Flags field: If the primary-VM
+sets a flag, but the destination does not support this capability, it
+will return a zero-bit for that flag and the primary-VM will understand
+that as not being an available capability and will thus disable that
+capability on the primary-VM side.
+
+QEMUFileRDMA Interface:
+=======================
+
+QEMUFileRDMA introduces a couple of new functions:
+
+1. qemu_rdma_get_buffer()  (QEMUFileOps rdma_read_ops)
+2. qemu_rdma_put_buffer()  (QEMUFileOps rdma_write_ops)
+
+These two functions are very short and simply use the protocol
+describe above to deliver bytes without changing the upper-level
+users of QEMUFile that depend on a bytestream abstraction.
+
+Finally, how do we handoff the actual bytes to get_buffer()?
+
+Again, because we're trying to "fake" a bytestream abstraction
+using an analogy not unlike individual UDP frames, we have
+to hold on to the bytes received from control-channel's SEND
+messages in memory.
+
+Each time we receive a complete "QEMU File" control-channel
+message, the bytes from SEND are copied into a small local holding area.
+
+Then, we return the number of bytes requested by get_buffer()
+and leave the remaining bytes in the holding area until get_buffer()
+comes around for another pass.
+
+If the buffer is empty, then we follow the same steps
+listed above and issue another "QEMU File" protocol command,
+asking for a new SEND message to re-fill the buffer.
+
+Migration of pc.ram:
+====================
+
+At the beginning of the migration, (migration-rdma.c),
+the sender and the receiver populate the list of RAMBlocks
+to be registered with each other into a structure.
+Then, using the aforementioned protocol, they exchange a
+description of these blocks with each other, to be used later
+during the iteration of main memory. This description includes
+a list of all the RAMBlocks, their offsets and lengths, virtual
+addresses and possibly includes pre-registered RDMA keys in case dynamic
+page registration was disabled on the server-side, otherwise not.
+
+Main memory is not migrated with the aforementioned protocol,
+but is instead migrated with normal RDMA Write operations.
+
+Pages are migrated in "chunks" (hard-coded to 1 Megabyte right now).
+Chunk size is not dynamic, but it could be in a future implementation.
+There's nothing to indicate that this is useful right now.
+
+When a chunk is full (or a flush() occurs), the memory backed by
+the chunk is registered with librdmacm is pinned in memory on
+both sides using the aforementioned protocol.
+After pinning, an RDMA Write is generated and transmitted
+for the entire chunk.
+
+Chunks are also transmitted in batches: This means that we
+do not request that the hardware signal the completion queue
+for the completion of *every* chunk. The current batch size
+is about 64 chunks (corresponding to 64 MB of memory).
+Only the last chunk in a batch must be signaled.
+This helps keep everything as asynchronous as possible
+and helps keep the hardware busy performing RDMA operations.
+
+Error-handling:
+===============
+
+Infiniband has what is called a "Reliable, Connected"
+link (one of 4 choices). This is the mode in which
+we use for RDMA migration.
+
+If a *single* message fails,
+the decision is to abort the migration entirely and
+cleanup all the RDMA descriptors and unregister all
+the memory.
+
+After cleanup, the Virtual Machine is returned to normal
+operation the same way that would happen if the TCP
+socket is broken during a non-RDMA based migration.
+
+TODO:
+=====
+1. 'migrate x-rdma:host:port' and '-incoming x-rdma' options will be
+   renamed to 'rdma' after the experimental phase of this work has
+   completed upstream.
+2. Currently, 'ulimit -l' mlock() limits as well as cgroups swap limits
+   are not compatible with infinband memory pinning and will result in
+   an aborted migration (but with the source VM left unaffected).
+3. Use of the recent /proc/<pid>/pagemap would likely speed up
+   the use of KSM and ballooning while using RDMA.
+4. Also, some form of balloon-device usage tracking would also
+   help alleviate some issues.
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 01/15] rdma: add documentation

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> docs/rdma.txt contains full documentation,
> wiki links, github url and contact information.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[Qemu-devel] [PATCH v11 02/15] rdma: introduce qemu_update_position()

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

RDMA writes happen asynchronously, and thus the performance accounting
also needs to be able to occur asynchronously. This allows anybody
to call into savevm.c to update both f->pos as well as into arch_init.c
to update the acct_info structure with up-to-date values when
the RDMA transfer actually completes.

Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 arch_init.c                   |   12 ++++++++++++
 include/migration/migration.h |    2 ++
 include/migration/qemu-file.h |    1 +
 savevm.c                      |    5 +++++
 4 files changed, 20 insertions(+)

diff --git a/arch_init.c b/arch_init.c
index a8b91ee..494a14f 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -498,6 +498,18 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
 
 static uint64_t bytes_transferred;
 
+void acct_update_position(QEMUFile *f, size_t size, bool zero)
+{
+    uint64_t pages = size / TARGET_PAGE_SIZE;
+    if (zero) {
+        acct_info.dup_pages += pages;
+    } else {
+        acct_info.norm_pages += pages;
+        bytes_transferred += size;
+        qemu_update_position(f, size);
+    }
+}
+
 static ram_addr_t ram_save_remaining(void)
 {
     return migration_dirty_pages;
diff --git a/include/migration/migration.h b/include/migration/migration.h
index e2acec6..0be28a2 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -92,6 +92,8 @@ uint64_t ram_bytes_remaining(void);
 uint64_t ram_bytes_transferred(void);
 uint64_t ram_bytes_total(void);
 
+void acct_update_position(QEMUFile *f, size_t size, bool zero);
+
 extern SaveVMHandlers savevm_ram_handlers;
 
 uint64_t dup_mig_bytes_transferred(void);
diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
index 7519464..8fab0dd 100644
--- a/include/migration/qemu-file.h
+++ b/include/migration/qemu-file.h
@@ -93,6 +93,7 @@ void qemu_put_be32(QEMUFile *f, unsigned int v);
 void qemu_put_be64(QEMUFile *f, uint64_t v);
 int qemu_get_buffer(QEMUFile *f, uint8_t *buf, int size);
 int qemu_get_byte(QEMUFile *f);
+void qemu_update_position(QEMUFile *f, size_t size);
 
 static inline unsigned int qemu_get_ubyte(QEMUFile *f)
 {
diff --git a/savevm.c b/savevm.c
index 48cc2a9..9b5577e 100644
--- a/savevm.c
+++ b/savevm.c
@@ -671,6 +671,11 @@ int qemu_get_fd(QEMUFile *f)
     return -1;
 }
 
+void qemu_update_position(QEMUFile *f, size_t size)
+{
+    f->pos += size;
+}
+
 /** Closes the file
  *
  * Returns negative error value if any error happened on previous operations or
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 02/15] rdma: introduce qemu_update_position()

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> RDMA writes happen asynchronously, and thus the performance accounting
> also needs to be able to occur asynchronously. This allows anybody
> to call into savevm.c to update both f->pos as well as into arch_init.c
> to update the acct_info structure with up-to-date values when
> the RDMA transfer actually completes.
>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>
 

[Qemu-devel] [PATCH v11 03/15] rdma: export yield_until_fd_readable()

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

The RDMA event channel can be made non-blocking just like a TCP
socket. Exporting this function allows us to yield so that the
QEMU monitor remains available.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 include/block/coroutine.h |    6 ++++++
 qemu-coroutine-io.c       |   23 +++++++++++++++++++++++
 savevm.c                  |   28 ----------------------------
 3 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/include/block/coroutine.h b/include/block/coroutine.h
index a978162..377805a 100644
--- a/include/block/coroutine.h
+++ b/include/block/coroutine.h
@@ -209,4 +209,10 @@ void qemu_co_rwlock_unlock(CoRwlock *lock);
  */
 void coroutine_fn co_sleep_ns(QEMUClock *clock, int64_t ns);
 
+/**
+ * Yield until a file descriptor becomes readable
+ *
+ * Note that this function clobbers the handlers for the file descriptor.
+ */
+void coroutine_fn yield_until_fd_readable(int fd);
 #endif /* QEMU_COROUTINE_H */
diff --git a/qemu-coroutine-io.c b/qemu-coroutine-io.c
index e8ad1a4..c4df35a 100644
--- a/qemu-coroutine-io.c
+++ b/qemu-coroutine-io.c
@@ -63,3 +63,26 @@ qemu_co_send_recv(int sockfd, void *buf, size_t bytes, bool do_send)
     struct iovec iov = { .iov_base = buf, .iov_len = bytes };
     return qemu_co_sendv_recvv(sockfd, &iov, 1, 0, bytes, do_send);
 }
+
+typedef struct {
+    Coroutine *co;
+    int fd;
+} FDYieldUntilData;
+
+static void fd_coroutine_enter(void *opaque)
+{
+    FDYieldUntilData *data = opaque;
+    qemu_set_fd_handler(data->fd, NULL, NULL, NULL);
+    qemu_coroutine_enter(data->co, NULL);
+}
+
+void coroutine_fn yield_until_fd_readable(int fd)
+{
+    FDYieldUntilData data;
+
+    assert(qemu_in_coroutine());
+    data.co = qemu_coroutine_self();
+    data.fd = fd;
+    qemu_set_fd_handler(fd, fd_coroutine_enter, NULL, &data);
+    qemu_coroutine_yield();
+}
diff --git a/savevm.c b/savevm.c
index 9b5577e..e35c7a4 100644
--- a/savevm.c
+++ b/savevm.c
@@ -149,34 +149,6 @@ typedef struct QEMUFileSocket
     QEMUFile *file;
 } QEMUFileSocket;
 
-typedef struct {
-    Coroutine *co;
-    int fd;
-} FDYieldUntilData;
-
-static void fd_coroutine_enter(void *opaque)
-{
-    FDYieldUntilData *data = opaque;
-    qemu_set_fd_handler(data->fd, NULL, NULL, NULL);
-    qemu_coroutine_enter(data->co, NULL);
-}
-
-/**
- * Yield until a file descriptor becomes readable
- *
- * Note that this function clobbers the handlers for the file descriptor.
- */
-static void coroutine_fn yield_until_fd_readable(int fd)
-{
-    FDYieldUntilData data;
-
-    assert(qemu_in_coroutine());
-    data.co = qemu_coroutine_self();
-    data.fd = fd;
-    qemu_set_fd_handler(fd, fd_coroutine_enter, NULL, &data);
-    qemu_coroutine_yield();
-}
-
 static ssize_t socket_writev_buffer(void *opaque, struct iovec *iov, int iovcnt,
                                     int64_t pos)
 {
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 03/15] rdma: export yield_until_fd_readable()

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> The RDMA event channel can be made non-blocking just like a TCP
> socket. Exporting this function allows us to yield so that the
> QEMU monitor remains available.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[Qemu-devel] [PATCH v11 04/15] rdma: export throughput w/ MigrationStats QMP

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

This exposes throughput (in megabits/sec) through QMP.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 hmp.c                         |    8 ++++++--
 include/migration/migration.h |    1 +
 migration.c                   |    6 ++++++
 qapi-schema.json              |    5 ++++-
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/hmp.c b/hmp.c
index 494a9aa..a3c6b55 100644
--- a/hmp.c
+++ b/hmp.c
@@ -154,8 +154,10 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
 
     if (info->has_status) {
         monitor_printf(mon, "Migration status: %s\n", info->status);
-        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
-                       info->total_time);
+        if (info->has_total_time) {
+            monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
+                           info->total_time);
+        }
         if (info->has_expected_downtime) {
             monitor_printf(mon, "expected downtime: %" PRIu64 " milliseconds\n",
                            info->expected_downtime);
@@ -169,6 +171,8 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
     if (info->has_ram) {
         monitor_printf(mon, "transferred ram: %" PRIu64 " kbytes\n",
                        info->ram->transferred >> 10);
+        monitor_printf(mon, "throughput: %0.2f mbps\n",
+                       info->ram->mbps);
         monitor_printf(mon, "remaining ram: %" PRIu64 " kbytes\n",
                        info->ram->remaining >> 10);
         monitor_printf(mon, "total ram: %" PRIu64 " kbytes\n",
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 0be28a2..535e844 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -40,6 +40,7 @@ struct MigrationState
 
     int state;
     MigrationParams params;
+    double mbps;
     int64_t total_time;
     int64_t downtime;
     int64_t expected_downtime;
diff --git a/migration.c b/migration.c
index 058f9e6..441a3b2 100644
--- a/migration.c
+++ b/migration.c
@@ -66,6 +66,7 @@ MigrationState *migrate_get_current(void)
         .state = MIG_STATE_SETUP,
         .bandwidth_limit = MAX_THROTTLE,
         .xbzrle_cache_size = DEFAULT_MIGRATE_CACHE_SIZE,
+        .mbps = -1,
     };
 
     return &current_migration;
@@ -201,6 +202,7 @@ MigrationInfo *qmp_query_migrate(Error **errp)
         info->ram->normal = norm_mig_pages_transferred();
         info->ram->normal_bytes = norm_mig_bytes_transferred();
         info->ram->dirty_pages_rate = s->dirty_pages_rate;
+        info->ram->mbps = s->mbps;
 
         if (blk_mig_active()) {
             info->has_disk = true;
@@ -230,6 +232,7 @@ MigrationInfo *qmp_query_migrate(Error **errp)
         info->ram->skipped = skipped_mig_pages_transferred();
         info->ram->normal = norm_mig_pages_transferred();
         info->ram->normal_bytes = norm_mig_bytes_transferred();
+        info->ram->mbps = s->mbps;
         break;
     case MIG_STATE_ERROR:
         info->has_status = true;
@@ -543,6 +546,9 @@ static void *migration_thread(void *opaque)
             double bandwidth = transferred_bytes / time_spent;
             max_size = bandwidth * migrate_max_downtime() / 1000000;
 
+            s->mbps = time_spent ? (((double) transferred_bytes * 8.0) /
+                    ((double) time_spent / 1000.0)) / 1000.0 / 1000.0 : -1;
+
             DPRINTF("transferred %" PRIu64 " time_spent %" PRIu64
                     " bandwidth %g max_size %" PRId64 "\n",
                     transferred_bytes, time_spent, bandwidth, max_size);
diff --git a/qapi-schema.json b/qapi-schema.json
index 6cc07c2..78da557 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -513,12 +513,15 @@
 # @dirty-pages-rate: number of pages dirtied by second by the
 #        guest (since 1.3)
 #
+# @mbps: throughput in megabits/sec. (since 1.6)
+#
 # Since: 0.14.0
 ##
 { 'type': 'MigrationStats',
   'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
            'duplicate': 'int', 'skipped': 'int', 'normal': 'int',
-           'normal-bytes': 'int', 'dirty-pages-rate' : 'int' } }
+           'normal-bytes': 'int', 'dirty-pages-rate' : 'int',
+           'mbps' : 'number' } }
 
 ##
 # @XBZRLECacheStats
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 04/15] rdma: export throughput w/ MigrationStats QMP

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> This exposes throughput (in megabits/sec) through QMP.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
> @@ -154,8 +154,10 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
>  
>      if (info->has_status) {
>          monitor_printf(mon, "Migration status: %s\n", info->status);
> -        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
> -                       info->total_time);
> +        if (info->has_total_time) {
> +            monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
> +                           info->total_time);
> +        }
>          if (info->has_expected_downtime) {
>              monitor_printf(mon, "expected downtime: %" PRIu64 " milliseconds\n",
>                             info->expected_downtime);

This chunk don't belong to this patch.

for the rest:

Reviewed-by: Juan Quintela <quintela@redhat.com>

Re: [Qemu-devel] [PATCH v11 04/15] rdma: export throughput w/ MigrationStats QMP

[Michael R. Hines]

On 06/25/2013 05:27 AM, Juan Quintela wrote:
> mrhines@linux.vnet.ibm.com wrote:
>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>
>> This exposes throughput (in megabits/sec) through QMP.
>>
>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
>> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
>> @@ -154,8 +154,10 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
>>   
>>       if (info->has_status) {
>>           monitor_printf(mon, "Migration status: %s\n", info->status);
>> -        monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
>> -                       info->total_time);
>> +        if (info->has_total_time) {
>> +            monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
>> +                           info->total_time);
>> +        }
>>           if (info->has_expected_downtime) {
>>               monitor_printf(mon, "expected downtime: %" PRIu64 " milliseconds\n",
>>                              info->expected_downtime);
> This chunk don't belong to this patch.
>
> for the rest:
>
> Reviewed-by: Juan Quintela <quintela@redhat.com>
>

Acknowledged - will drop the hunk in the next version.

- Michael

[Qemu-devel] [PATCH v11 05/15] rdma: introduce qemu_file_mode_is_not_valid()

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

QEMUFileRDMA also has read and write modes. This function is now
shared to reduce code duplication.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 include/migration/qemu-file.h |    1 +
 savevm.c                      |   20 +++++++++++++-------
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
index 8fab0dd..dd3fd51 100644
--- a/include/migration/qemu-file.h
+++ b/include/migration/qemu-file.h
@@ -80,6 +80,7 @@ void qemu_put_byte(QEMUFile *f, int v);
  * The buffer should be available till it is sent asynchronously.
  */
 void qemu_put_buffer_async(QEMUFile *f, const uint8_t *buf, int size);
+bool qemu_file_mode_is_not_valid(const char *mode);
 
 static inline void qemu_put_ubyte(QEMUFile *f, unsigned int v)
 {
diff --git a/savevm.c b/savevm.c
index e35c7a4..67ddf06 100644
--- a/savevm.c
+++ b/savevm.c
@@ -449,14 +449,23 @@ static const QEMUFileOps socket_write_ops = {
     .close =      socket_close
 };
 
-QEMUFile *qemu_fopen_socket(int fd, const char *mode)
+bool qemu_file_mode_is_not_valid(const char *mode)
 {
-    QEMUFileSocket *s;
-
     if (mode == NULL ||
         (mode[0] != 'r' && mode[0] != 'w') ||
         mode[1] != 'b' || mode[2] != 0) {
         fprintf(stderr, "qemu_fopen: Argument validity check failed\n");
+        return true;
+    }
+
+    return false;
+}
+
+QEMUFile *qemu_fopen_socket(int fd, const char *mode)
+{
+    QEMUFileSocket *s;
+
+    if (qemu_file_mode_is_not_valid(mode)) {
         return NULL;
     }
 
@@ -475,10 +484,7 @@ QEMUFile *qemu_fopen(const char *filename, const char *mode)
 {
     QEMUFileStdio *s;
 
-    if (mode == NULL ||
-	(mode[0] != 'r' && mode[0] != 'w') ||
-	mode[1] != 'b' || mode[2] != 0) {
-        fprintf(stderr, "qemu_fopen: Argument validity check failed\n");
+    if (qemu_file_mode_is_not_valid(mode)) {
         return NULL;
     }
 
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 05/15] rdma: introduce qemu_file_mode_is_not_valid()

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> QEMUFileRDMA also has read and write modes. This function is now
> shared to reduce code duplication.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[Qemu-devel] [PATCH v11 06/15] rdma: export qemu_fflush()

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

RDMA uses this to flush the control channel before sending its
own message to handle page registrations.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 include/migration/qemu-file.h |    1 +
 savevm.c                      |    2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
index dd3fd51..37d1604 100644
--- a/include/migration/qemu-file.h
+++ b/include/migration/qemu-file.h
@@ -112,6 +112,7 @@ void qemu_file_reset_rate_limit(QEMUFile *f);
 void qemu_file_set_rate_limit(QEMUFile *f, int64_t new_rate);
 int64_t qemu_file_get_rate_limit(QEMUFile *f);
 int qemu_file_get_error(QEMUFile *f);
+void qemu_fflush(QEMUFile *f);
 
 static inline void qemu_put_be64s(QEMUFile *f, const uint64_t *pv)
 {
diff --git a/savevm.c b/savevm.c
index 67ddf06..26d5607 100644
--- a/savevm.c
+++ b/savevm.c
@@ -589,7 +589,7 @@ static inline bool qemu_file_is_writable(QEMUFile *f)
  * If there is writev_buffer QEMUFileOps it uses it otherwise uses
  * put_buffer ops.
  */
-static void qemu_fflush(QEMUFile *f)
+void qemu_fflush(QEMUFile *f)
 {
     ssize_t ret = 0;
 
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 06/15] rdma: export qemu_fflush()

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> RDMA uses this to flush the control channel before sending its
> own message to handle page registrations.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[Qemu-devel] [PATCH v11 07/15] rdma: introduce ram_handle_compressed()

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

This gives RDMA shared access to madvise() on the destination side
when an entire chunk is found to be zero.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 arch_init.c                   |   24 ++++++++++++++++--------
 include/migration/migration.h |    2 ++
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 494a14f..00bc3a9 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -782,6 +782,21 @@ static inline void *host_from_stream_offset(QEMUFile *f,
     return NULL;
 }
 
+/*
+ * If a page (or a whole RDMA chunk) has been
+ * determined to be zero, then zap it.
+ */
+void ram_handle_compressed(void *host, uint8_t ch, uint64_t size)
+{
+    memset(host, ch, TARGET_PAGE_SIZE);
+#ifndef _WIN32
+    if (ch == 0 && (!kvm_enabled() || kvm_has_sync_mmu()) &&
+                            getpagesize() <= TARGET_PAGE_SIZE) {
+        qemu_madvise(host, size, QEMU_MADV_DONTNEED);
+    }
+#endif
+}
+
 static int ram_load(QEMUFile *f, void *opaque, int version_id)
 {
     ram_addr_t addr;
@@ -849,14 +864,7 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
             }
 
             ch = qemu_get_byte(f);
-            memset(host, ch, TARGET_PAGE_SIZE);
-#ifndef _WIN32
-            if (ch == 0 &&
-                (!kvm_enabled() || kvm_has_sync_mmu()) &&
-                getpagesize() <= TARGET_PAGE_SIZE) {
-                qemu_madvise(host, TARGET_PAGE_SIZE, QEMU_MADV_DONTNEED);
-            }
-#endif
+            ram_handle_compressed(host, ch, TARGET_PAGE_SIZE);
         } else if (flags & RAM_SAVE_FLAG_PAGE) {
             void *host;
 
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 535e844..8d9cbd1 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -108,6 +108,8 @@ uint64_t xbzrle_mig_pages_transferred(void);
 uint64_t xbzrle_mig_pages_overflow(void);
 uint64_t xbzrle_mig_pages_cache_miss(void);
 
+void ram_handle_compressed(void *host, uint8_t ch, uint64_t size);
+
 /**
  * @migrate_add_blocker - prevent migration from proceeding
  *
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 07/15] rdma: introduce ram_handle_compressed()

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> This gives RDMA shared access to madvise() on the destination side
> when an entire chunk is found to be zero.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[Qemu-devel] [PATCH v11 08/15] rdma: introduce qemu_ram_foreach_block()

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

This is used during RDMA initialization in order to
transmit a description of all the RAM blocks to the
peer for later dynamic chunk registration purposes.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 exec.c                    |    9 +++++++++
 include/exec/cpu-common.h |    5 +++++
 2 files changed, 14 insertions(+)

diff --git a/exec.c b/exec.c
index 0b0118b..2e6fc00 100644
--- a/exec.c
+++ b/exec.c
@@ -2630,3 +2630,12 @@ bool cpu_physical_memory_is_io(hwaddr phys_addr)
              memory_region_is_romd(mr));
 }
 #endif
+
+void qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque)
+{
+    RAMBlock *block;
+
+    QTAILQ_FOREACH(block, &ram_list.blocks, next) {
+        func(block->host, block->offset, block->length, opaque);
+    }
+}
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index e061e21..92a4223 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -113,6 +113,11 @@ void cpu_physical_memory_write_rom(hwaddr addr,
 extern struct MemoryRegion io_mem_rom;
 extern struct MemoryRegion io_mem_notdirty;
 
+typedef void (RAMBlockIterFunc)(void *host_addr,
+    ram_addr_t offset, ram_addr_t length, void *opaque);
+
+void qemu_ram_foreach_block(RAMBlockIterFunc func, void *opaque);
+
 #endif
 
 #endif /* !CPU_COMMON_H */
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 08/15] rdma: introduce qemu_ram_foreach_block()

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> This is used during RDMA initialization in order to
> transmit a description of all the RAM blocks to the
> peer for later dynamic chunk registration purposes.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[Qemu-devel] [PATCH v11 09/15] rdma: new QEMUFileOps hooks

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

These are the prototypes and implementation of new hooks that
RDMA takes advantage of to perform dynamic page registration.

An optional hook is also introduced for a custom function
to be able to override the default save_page function.

Also included are the prototypes and accessor methods used by
arch_init.c which invoke funtions inside savevm.c to call out
to the hooks that may or may not have been overridden
inside of QEMUFileOps.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 include/migration/migration.h |   20 ++++++++++++++
 include/migration/qemu-file.h |   29 ++++++++++++++++++++
 savevm.c                      |   59 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 108 insertions(+)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 8d9cbd1..7b153d7 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -21,6 +21,7 @@
 #include "qapi/error.h"
 #include "migration/vmstate.h"
 #include "qapi-types.h"
+#include "exec/cpu-common.h"
 
 struct MigrationParams {
     bool blk;
@@ -132,4 +133,23 @@ int migrate_use_xbzrle(void);
 int64_t migrate_xbzrle_cache_size(void);
 
 int64_t xbzrle_cache_resize(int64_t new_size);
+
+void ram_control_before_iterate(QEMUFile *f, uint64_t flags);
+void ram_control_after_iterate(QEMUFile *f, uint64_t flags);
+void ram_control_load_hook(QEMUFile *f, uint64_t flags);
+
+/* Whenever this is found in the data stream, the flags
+ * will be passed to ram_control_load_hook in the incoming-migration
+ * side. This lets before_ram_iterate/after_ram_iterate add
+ * transport-specific sections to the RAM migration data.
+ */
+#define RAM_SAVE_FLAG_HOOK     0x80
+
+#define RAM_SAVE_CONTROL_NOT_SUPP -1000
+#define RAM_SAVE_CONTROL_DELAYED  -2000
+
+size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset,
+                             ram_addr_t offset, size_t size,
+                             int *bytes_sent);
+
 #endif
diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
index 37d1604..0f757fb 100644
--- a/include/migration/qemu-file.h
+++ b/include/migration/qemu-file.h
@@ -23,6 +23,7 @@
  */
 #ifndef QEMU_FILE_H
 #define QEMU_FILE_H 1
+#include "exec/cpu-common.h"
 
 /* This function writes a chunk of data to a file at the given position.
  * The pos argument can be ignored if the file is only being used for
@@ -57,12 +58,40 @@ typedef int (QEMUFileGetFD)(void *opaque);
 typedef ssize_t (QEMUFileWritevBufferFunc)(void *opaque, struct iovec *iov,
                                            int iovcnt, int64_t pos);
 
+/*
+ * This function provides hooks around different
+ * stages of RAM migration.
+ */
+typedef int (QEMURamHookFunc)(QEMUFile *f, void *opaque, uint64_t flags);
+
+/*
+ * Constants used by ram_control_* hooks
+ */
+#define RAM_CONTROL_SETUP    0
+#define RAM_CONTROL_ROUND    1
+#define RAM_CONTROL_HOOK     2
+#define RAM_CONTROL_FINISH   3
+
+/*
+ * This function allows override of where the RAM page
+ * is saved (such as RDMA, for example.)
+ */
+typedef size_t (QEMURamSaveFunc)(QEMUFile *f, void *opaque,
+                               ram_addr_t block_offset,
+                               ram_addr_t offset,
+                               size_t size,
+                               int *bytes_sent);
+
 typedef struct QEMUFileOps {
     QEMUFilePutBufferFunc *put_buffer;
     QEMUFileGetBufferFunc *get_buffer;
     QEMUFileCloseFunc *close;
     QEMUFileGetFD *get_fd;
     QEMUFileWritevBufferFunc *writev_buffer;
+    QEMURamHookFunc *before_ram_iterate;
+    QEMURamHookFunc *after_ram_iterate;
+    QEMURamHookFunc *hook_ram_load;
+    QEMURamSaveFunc *save_page;
 } QEMUFileOps;
 
 QEMUFile *qemu_fopen_ops(void *opaque, const QEMUFileOps *ops);
diff --git a/savevm.c b/savevm.c
index 26d5607..e0491e7 100644
--- a/savevm.c
+++ b/savevm.c
@@ -616,6 +616,65 @@ void qemu_fflush(QEMUFile *f)
     }
 }
 
+void ram_control_before_iterate(QEMUFile *f, uint64_t flags)
+{
+    int ret = 0;
+
+    if (f->ops->before_ram_iterate) {
+        ret = f->ops->before_ram_iterate(f, f->opaque, flags);
+        if (ret < 0) {
+            qemu_file_set_error(f, ret);
+        }
+    }
+}
+
+void ram_control_after_iterate(QEMUFile *f, uint64_t flags)
+{
+    int ret = 0;
+
+    if (f->ops->after_ram_iterate) {
+        ret = f->ops->after_ram_iterate(f, f->opaque, flags);
+        if (ret < 0) {
+            qemu_file_set_error(f, ret);
+        }
+    }
+}
+
+void ram_control_load_hook(QEMUFile *f, uint64_t flags)
+{
+    int ret = 0;
+
+    if (f->ops->hook_ram_load) {
+        ret = f->ops->hook_ram_load(f, f->opaque, flags);
+        if (ret < 0) {
+            qemu_file_set_error(f, ret);
+        }
+    } else {
+        qemu_file_set_error(f, ret);
+    }
+}
+
+size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset,
+                         ram_addr_t offset, size_t size, int *bytes_sent)
+{
+    if (f->ops->save_page) {
+        int ret = f->ops->save_page(f, f->opaque, block_offset,
+                                    offset, size, bytes_sent);
+
+        if (ret != RAM_SAVE_CONTROL_DELAYED) {
+            if (*bytes_sent > 0) {
+                qemu_update_position(f, *bytes_sent);
+            } else if (ret < 0) {
+                qemu_file_set_error(f, ret);
+            }
+        }
+
+        return ret;
+    }
+
+    return RAM_SAVE_CONTROL_NOT_SUPP;
+}
+
 static void qemu_fill_buffer(QEMUFile *f)
 {
     int len;
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 09/15] rdma: new QEMUFileOps hooks

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> These are the prototypes and implementation of new hooks that
> RDMA takes advantage of to perform dynamic page registration.
>
> An optional hook is also introduced for a custom function
> to be able to override the default save_page function.
>
> Also included are the prototypes and accessor methods used by
> arch_init.c which invoke funtions inside savevm.c to call out
> to the hooks that may or may not have been overridden
> inside of QEMUFileOps.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Hi


> +void ram_control_before_iterate(QEMUFile *f, uint64_t flags)
> +{
> +    int ret = 0;
> +
> +    if (f->ops->before_ram_iterate) {
> +        ret = f->ops->before_ram_iterate(f, f->opaque, flags);
> +        if (ret < 0) {
> +            qemu_file_set_error(f, ret);
> +        }
> +    }
> +}
> +
> +void ram_control_after_iterate(QEMUFile *f, uint64_t flags)
> +{
> +    int ret = 0;
> +
> +    if (f->ops->after_ram_iterate) {
> +        ret = f->ops->after_ram_iterate(f, f->opaque, flags);
> +        if (ret < 0) {
> +            qemu_file_set_error(f, ret);
> +        }
> +    }
> +}
> +
> +void ram_control_load_hook(QEMUFile *f, uint64_t flags)
> +{
> +    int ret = 0;
> +
> +    if (f->ops->hook_ram_load) {
> +        ret = f->ops->hook_ram_load(f, f->opaque, flags);
> +        if (ret < 0) {
> +            qemu_file_set_error(f, ret);
> +        }
> +    } else {
> +        qemu_file_set_error(f, ret);
> +    }
> +}
> +
> +size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset,
> +                         ram_addr_t offset, size_t size, int *bytes_sent)
> +{
> +    if (f->ops->save_page) {
> +        int ret = f->ops->save_page(f, f->opaque, block_offset,
> +                                    offset, size, bytes_sent);
> +
> +        if (ret != RAM_SAVE_CONTROL_DELAYED) {
> +            if (*bytes_sent > 0) {
> +                qemu_update_position(f, *bytes_sent);
> +            } else if (ret < 0) {
> +                qemu_file_set_error(f, ret);
> +            }
> +        }
> +
> +        return ret;
> +    }
> +
> +    return RAM_SAVE_CONTROL_NOT_SUPP;
> +}
> +
>  static void qemu_fill_buffer(QEMUFile *f)
>  {
>      int len;

I wou0ld clame that the calls to this functions belong to this patch.
Not that it makes a lot of difference though.

Later,  Juan.

Re: [Qemu-devel] [PATCH v11 09/15] rdma: new QEMUFileOps hooks

[Michael R. Hines]

On 06/25/2013 07:51 AM, Juan Quintela wrote:
> mrhines@linux.vnet.ibm.com wrote:
>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>
>> These are the prototypes and implementation of new hooks that
>> RDMA takes advantage of to perform dynamic page registration.
>>
>> An optional hook is also introduced for a custom function
>> to be able to override the default save_page function.
>>
>> Also included are the prototypes and accessor methods used by
>> arch_init.c which invoke funtions inside savevm.c to call out
>> to the hooks that may or may not have been overridden
>> inside of QEMUFileOps.
>>
>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
>> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
> Hi
>
>
>> +void ram_control_before_iterate(QEMUFile *f, uint64_t flags)
>> +{
>> +    int ret = 0;
>> +
>> +    if (f->ops->before_ram_iterate) {
>> +        ret = f->ops->before_ram_iterate(f, f->opaque, flags);
>> +        if (ret < 0) {
>> +            qemu_file_set_error(f, ret);
>> +        }
>> +    }
>> +}
>> +
>> +void ram_control_after_iterate(QEMUFile *f, uint64_t flags)
>> +{
>> +    int ret = 0;
>> +
>> +    if (f->ops->after_ram_iterate) {
>> +        ret = f->ops->after_ram_iterate(f, f->opaque, flags);
>> +        if (ret < 0) {
>> +            qemu_file_set_error(f, ret);
>> +        }
>> +    }
>> +}
>> +
>> +void ram_control_load_hook(QEMUFile *f, uint64_t flags)
>> +{
>> +    int ret = 0;
>> +
>> +    if (f->ops->hook_ram_load) {
>> +        ret = f->ops->hook_ram_load(f, f->opaque, flags);
>> +        if (ret < 0) {
>> +            qemu_file_set_error(f, ret);
>> +        }
>> +    } else {
>> +        qemu_file_set_error(f, ret);
>> +    }
>> +}
>> +
>> +size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset,
>> +                         ram_addr_t offset, size_t size, int *bytes_sent)
>> +{
>> +    if (f->ops->save_page) {
>> +        int ret = f->ops->save_page(f, f->opaque, block_offset,
>> +                                    offset, size, bytes_sent);
>> +
>> +        if (ret != RAM_SAVE_CONTROL_DELAYED) {
>> +            if (*bytes_sent > 0) {
>> +                qemu_update_position(f, *bytes_sent);
>> +            } else if (ret < 0) {
>> +                qemu_file_set_error(f, ret);
>> +            }
>> +        }
>> +
>> +        return ret;
>> +    }
>> +
>> +    return RAM_SAVE_CONTROL_NOT_SUPP;
>> +}
>> +
>>   static void qemu_fill_buffer(QEMUFile *f)
>>   {
>>       int len;
> I wou0ld clame that the calls to this functions belong to this patch.
> Not that it makes a lot of difference though.
>
> Later,  Juan.
>

I'll avoid rebasing if there's no strong objection - as this ordering 
was suggested by Paolo.

- Michael

Re: [Qemu-devel] [PATCH v11 09/15] rdma: new QEMUFileOps hooks

[Paolo Bonzini]

Il 25/06/2013 15:38, Michael R. Hines ha scritto:
> On 06/25/2013 07:51 AM, Juan Quintela wrote:
>> mrhines@linux.vnet.ibm.com wrote:
>>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>>
>>> These are the prototypes and implementation of new hooks that
>>> RDMA takes advantage of to perform dynamic page registration.
>>>
>>> An optional hook is also introduced for a custom function
>>> to be able to override the default save_page function.
>>>
>>> Also included are the prototypes and accessor methods used by
>>> arch_init.c which invoke funtions inside savevm.c to call out
>>> to the hooks that may or may not have been overridden
>>> inside of QEMUFileOps.
>>>
>>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>>> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
>>> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
>>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
>> Hi
>>
>>
>>> +void ram_control_before_iterate(QEMUFile *f, uint64_t flags)
>>> +{
>>> +    int ret = 0;
>>> +
>>> +    if (f->ops->before_ram_iterate) {
>>> +        ret = f->ops->before_ram_iterate(f, f->opaque, flags);
>>> +        if (ret < 0) {
>>> +            qemu_file_set_error(f, ret);
>>> +        }
>>> +    }
>>> +}
>>> +
>>> +void ram_control_after_iterate(QEMUFile *f, uint64_t flags)
>>> +{
>>> +    int ret = 0;
>>> +
>>> +    if (f->ops->after_ram_iterate) {
>>> +        ret = f->ops->after_ram_iterate(f, f->opaque, flags);
>>> +        if (ret < 0) {
>>> +            qemu_file_set_error(f, ret);
>>> +        }
>>> +    }
>>> +}
>>> +
>>> +void ram_control_load_hook(QEMUFile *f, uint64_t flags)
>>> +{
>>> +    int ret = 0;
>>> +
>>> +    if (f->ops->hook_ram_load) {
>>> +        ret = f->ops->hook_ram_load(f, f->opaque, flags);
>>> +        if (ret < 0) {
>>> +            qemu_file_set_error(f, ret);
>>> +        }
>>> +    } else {
>>> +        qemu_file_set_error(f, ret);
>>> +    }
>>> +}
>>> +
>>> +size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset,
>>> +                         ram_addr_t offset, size_t size, int
>>> *bytes_sent)
>>> +{
>>> +    if (f->ops->save_page) {
>>> +        int ret = f->ops->save_page(f, f->opaque, block_offset,
>>> +                                    offset, size, bytes_sent);
>>> +
>>> +        if (ret != RAM_SAVE_CONTROL_DELAYED) {
>>> +            if (*bytes_sent > 0) {
>>> +                qemu_update_position(f, *bytes_sent);
>>> +            } else if (ret < 0) {
>>> +                qemu_file_set_error(f, ret);
>>> +            }
>>> +        }
>>> +
>>> +        return ret;
>>> +    }
>>> +
>>> +    return RAM_SAVE_CONTROL_NOT_SUPP;
>>> +}
>>> +
>>>   static void qemu_fill_buffer(QEMUFile *f)
>>>   {
>>>       int len;
>> I wou0ld clame that the calls to this functions belong to this patch.
>> Not that it makes a lot of difference though.
>>
>> Later,  Juan.
>>
> 
> I'll avoid rebasing if there's no strong objection - as this ordering
> was suggested by Paolo.

Indeed, it made my review a bit easier.

Paolo

[Qemu-devel] [PATCH v11 10/15] rdma: introduce capability x-rdma-pin-all

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

This capability allows you to disable dynamic chunk registration
for better throughput on high-performance links.

For example, using an 8GB RAM virtual machine with all 8GB of memory in
active use and the VM itself is completely idle using a 40 gbps infiniband link:

1. x-rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
2. x-rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps

These numbers would of course scale up to whatever size virtual machine
you have to migrate using RDMA.

Enabling this feature does *not* have any measurable affect on
migration *downtime*. This is because, without this feature, all of the
memory will have already been registered already in advance during
the bulk round and does not need to be re-registered during the successive
iteration rounds.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 include/migration/migration.h |    2 ++
 migration.c                   |    9 +++++++++
 qapi-schema.json              |    7 ++++++-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index 7b153d7..9d3cc85 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -125,6 +125,8 @@ void migrate_add_blocker(Error *reason);
  */
 void migrate_del_blocker(Error *reason);
 
+bool migrate_rdma_pin_all(void);
+
 int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t *new_buf, int slen,
                          uint8_t *dst, int dlen);
 int xbzrle_decode_buffer(uint8_t *src, int slen, uint8_t *dst, int dlen);
diff --git a/migration.c b/migration.c
index 441a3b2..a704d48 100644
--- a/migration.c
+++ b/migration.c
@@ -476,6 +476,15 @@ void qmp_migrate_set_downtime(double value, Error **errp)
     max_downtime = (uint64_t)value;
 }
 
+bool migrate_rdma_pin_all(void)
+{
+    MigrationState *s;
+
+    s = migrate_get_current();
+
+    return s->enabled_capabilities[MIGRATION_CAPABILITY_X_RDMA_PIN_ALL];
+}
+
 int migrate_use_xbzrle(void)
 {
     MigrationState *s;
diff --git a/qapi-schema.json b/qapi-schema.json
index 78da557..a30a728 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -608,10 +608,15 @@
 #          This feature allows us to minimize migration traffic for certain work
 #          loads, by sending compressed difference of the pages
 #
+# @x-rdma-pin-all: Controls whether or not the entire VM memory footprint is
+#          mlock()'d on demand or all at once. Refer to docs/rdma.txt for usage.
+#          Disabled by default. Experimental: may (or may not) be renamed after
+#          further testing is complete. (since 1.6)
+#
 # Since: 1.2
 ##
 { 'enum': 'MigrationCapability',
-  'data': ['xbzrle'] }
+  'data': ['xbzrle', 'x-rdma-pin-all'] }
 
 ##
 # @MigrationCapabilityStatus
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 10/15] rdma: introduce capability x-rdma-pin-all

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> This capability allows you to disable dynamic chunk registration
> for better throughput on high-performance links.
>
> For example, using an 8GB RAM virtual machine with all 8GB of memory in
> active use and the VM itself is completely idle using a 40 gbps infiniband link:
>
> 1. x-rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
> 2. x-rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps
>
> These numbers would of course scale up to whatever size virtual machine
> you have to migrate using RDMA.
>
> Enabling this feature does *not* have any measurable affect on
> migration *downtime*. This is because, without this feature, all of the
> memory will have already been registered already in advance during
> the bulk round and does not need to be re-registered during the successive
> iteration rounds.
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[Qemu-devel] [PATCH v11 11/15] rdma: core logic

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

Code that does need to be visible is kept
well contained inside this file and this is the only
new additional file to the entire patch.

This file includes the entire protocol and interfaces
required to perform RDMA migration.

Also, the configure and Makefile modifications to link
this file are included.

Full documentation is in docs/rdma.txt

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 Makefile.objs                 |    1 +
 configure                     |   29 +
 include/migration/migration.h |    4 +
 migration-rdma.c              | 2819 +++++++++++++++++++++++++++++++++++++++++
 migration.c                   |    8 +
 5 files changed, 2861 insertions(+)
 create mode 100644 migration-rdma.c

diff --git a/Makefile.objs b/Makefile.objs
index 5b288ba..9928542 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -51,6 +51,7 @@ common-obj-$(CONFIG_POSIX) += os-posix.o
 common-obj-$(CONFIG_LINUX) += fsdev/
 
 common-obj-y += migration.o migration-tcp.o
+common-obj-$(CONFIG_RDMA) += migration-rdma.o
 common-obj-y += qemu-char.o #aio.o
 common-obj-y += block-migration.o
 common-obj-y += page_cache.o xbzrle.o
diff --git a/configure b/configure
index 0e0adde..958e7b8 100755
--- a/configure
+++ b/configure
@@ -180,6 +180,7 @@ xfs=""
 vhost_net="no"
 vhost_scsi="no"
 kvm="no"
+rdma=""
 gprof="no"
 debug_tcg="no"
 debug="no"
@@ -936,6 +937,10 @@ for opt do
   ;;
   --enable-gtk) gtk="yes"
   ;;
+  --enable-rdma) rdma="yes"
+  ;;
+  --disable-rdma) rdma="no"
+  ;;
   --with-gtkabi=*) gtkabi="$optarg"
   ;;
   --enable-tpm) tpm="yes"
@@ -1094,6 +1099,8 @@ echo "  --enable-bluez           enable bluez stack connectivity"
 echo "  --disable-slirp          disable SLIRP userspace network connectivity"
 echo "  --disable-kvm            disable KVM acceleration support"
 echo "  --enable-kvm             enable KVM acceleration support"
+echo "  --disable-rdma           disable RDMA-based migration support"
+echo "  --enable-rdma            enable RDMA-based migration support"
 echo "  --enable-tcg-interpreter enable TCG with bytecode interpreter (TCI)"
 echo "  --disable-nptl           disable usermode NPTL support"
 echo "  --enable-nptl            enable usermode NPTL support"
@@ -1796,6 +1803,23 @@ EOF
   libs_softmmu="$sdl_libs $libs_softmmu"
 fi
 
+if test "$rdma" != "no" ; then
+  cat > $TMPC <<EOF
+#include <rdma/rdma_cma.h>
+int main(void) { return 0; }
+EOF
+  rdma_libs="-lrdmacm -libverbs"
+  if compile_prog "-Werror" "$rdma_libs" ; then
+    rdma="yes"
+    libs_softmmu="$libs_softmmu $rdma_libs"
+  else
+    if test "$rdma" = "yes" ; then
+      feature_not_found "rdma"
+    fi
+    rdma="no"
+  fi
+fi
+
 ##########################################
 # VNC TLS/WS detection
 if test "$vnc" = "yes" -a \( "$vnc_tls" != "no" -o "$vnc_ws" != "no" \) ; then
@@ -3525,6 +3549,7 @@ echo "Linux AIO support $linux_aio"
 echo "ATTR/XATTR support $attr"
 echo "Install blobs     $blobs"
 echo "KVM support       $kvm"
+echo "RDMA support      $rdma"
 echo "TCG interpreter   $tcg_interpreter"
 echo "fdt support       $fdt"
 echo "preadv support    $preadv"
@@ -4464,6 +4489,10 @@ if [ "$pixman" = "internal" ]; then
   echo "config-host.h: subdir-pixman" >> $config_host_mak
 fi
 
+if test "$rdma" = "yes" ; then
+echo "CONFIG_RDMA=y" >> $config_host_mak
+fi
+
 if [ "$dtc_internal" = "yes" ]; then
   echo "config-host.h: subdir-dtc" >> $config_host_mak
 fi
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 9d3cc85..b5e413a 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -77,6 +77,10 @@ void fd_start_incoming_migration(const char *path, Error **errp);
 
 void fd_start_outgoing_migration(MigrationState *s, const char *fdname, Error **errp);
 
+void rdma_start_outgoing_migration(void *opaque, const char *host_port, Error **errp);
+
+void rdma_start_incoming_migration(const char *host_port, Error **errp);
+
 void migrate_fd_error(MigrationState *s);
 
 void migrate_fd_connect(MigrationState *s);
diff --git a/migration-rdma.c b/migration-rdma.c
new file mode 100644
index 0000000..165297e
--- /dev/null
+++ b/migration-rdma.c
@@ -0,0 +1,2819 @@
+/*
+ * RDMA protocol and interfaces
+ *
+ * Copyright IBM, Corp. 2010-2013
+ *
+ * Authors:
+ *  Michael R. Hines <mrhines@us.ibm.com>
+ *  Jiuxing Liu <jl@us.ibm.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later.  See the COPYING file in the top-level directory.
+ *
+ */
+#include "qemu-common.h"
+#include "migration/migration.h"
+#include "migration/qemu-file.h"
+#include "exec/cpu-common.h"
+#include "qemu/main-loop.h"
+#include "qemu/sockets.h"
+#include "block/coroutine.h"
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <netdb.h>
+#include <arpa/inet.h>
+#include <string.h>
+#include <rdma/rdma_cma.h>
+
+//#define DEBUG_RDMA
+//#define DEBUG_RDMA_VERBOSE
+//#define DEBUG_RDMA_REALLY_VERBOSE
+
+#ifdef DEBUG_RDMA
+#define DPRINTF(fmt, ...) \
+    do { printf("rdma: " fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+    do { } while (0)
+#endif
+
+#ifdef DEBUG_RDMA_VERBOSE
+#define DDPRINTF(fmt, ...) \
+    do { printf("rdma: " fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DDPRINTF(fmt, ...) \
+    do { } while (0)
+#endif
+
+#ifdef DEBUG_RDMA_REALLY_VERBOSE
+#define DDDPRINTF(fmt, ...) \
+    do { printf("rdma: " fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DDDPRINTF(fmt, ...) \
+    do { } while (0)
+#endif
+
+/*
+ * Print and error on both the Monitor and the Log file.
+ */
+#define ERROR(errp, fmt, ...) \
+    do { \
+        fprintf(stderr, "RDMA ERROR: " fmt, ## __VA_ARGS__); \
+        if (errp && (*(errp) == NULL)) { \
+            error_setg(errp, "RDMA ERROR: " fmt, ## __VA_ARGS__); \
+        } \
+    } while (0)
+
+#define RDMA_RESOLVE_TIMEOUT_MS 10000
+
+/* Do not merge data if larger than this. */
+#define RDMA_MERGE_MAX (2 * 1024 * 1024)
+#define RDMA_SIGNALED_SEND_MAX (RDMA_MERGE_MAX / 4096)
+
+#define RDMA_REG_CHUNK_SHIFT 20 /* 1 MB */
+
+/*
+ * This is only for non-live state being migrated.
+ * Instead of RDMA_WRITE messages, we use RDMA_SEND
+ * messages for that state, which requires a different
+ * delivery design than main memory.
+ */
+#define RDMA_SEND_INCREMENT 32768
+
+/*
+ * Maximum size infiniband SEND message
+ */
+#define RDMA_CONTROL_MAX_BUFFER (512 * 1024)
+#define RDMA_CONTROL_MAX_WR 2
+#define RDMA_CONTROL_MAX_COMMANDS_PER_MESSAGE 4096
+
+/*
+ * Capabilities for negotiation.
+ */
+#define RDMA_CAPABILITY_PIN_ALL 0x01
+
+/*
+ * Add the other flags above to this list of known capabilities
+ * as they are introduced.
+ */
+static uint32_t known_capabilities = RDMA_CAPABILITY_PIN_ALL;
+
+#define CHECK_ERROR_STATE() \
+    do { \
+        if (rdma->error_state) { \
+            if (!rdma->error_reported) { \
+                fprintf(stderr, "RDMA is in an error state waiting migration" \
+                                " to abort!\n"); \
+                rdma->error_reported = 1; \
+            } \
+            return rdma->error_state; \
+        } \
+    } while (0);
+/*
+ * RDMA migration protocol:
+ * 1. RDMA Writes (data messages, i.e. RAM)
+ * 2. IB Send/Recv (control channel messages)
+ */
+#define RDMA_WRITE_START 1
+#define RDMA_SEND_CONTROL 20000
+#define RDMA_RECV_CONTROL 40000
+
+enum {
+    RDMA_WRID_NONE = 0,
+    RDMA_WRID_RDMA_WRITE_START = RDMA_WRITE_START,
+    RDMA_WRID_SEND_CONTROL = RDMA_SEND_CONTROL,
+    RDMA_WRID_RECV_CONTROL = RDMA_RECV_CONTROL,
+};
+
+#define RDMA_WRID_RDMA_WRITE_STOP \
+    (RDMA_WRITE_START + (RDMA_SIGNALED_SEND_MAX - 1))
+
+#if RDMA_WRID_RDMA_WRITE_STOP >= RDMA_SEND_CONTROL
+#error "RDMA Compile Error: RDMA_SIGNALED_SEND_MAX is too large."
+#endif
+
+const char *wrid_desc[] = {
+        [RDMA_WRID_NONE] = "NONE",
+        [RDMA_WRID_RDMA_WRITE_START] = "WRITE RDMA",
+        [RDMA_WRID_SEND_CONTROL] = "CONTROL SEND",
+        [RDMA_WRID_RECV_CONTROL] = "CONTROL RECV",
+};
+
+/*
+ * SEND/RECV IB Control Messages.
+ */
+enum {
+    RDMA_CONTROL_NONE = 0,
+    RDMA_CONTROL_ERROR,
+    RDMA_CONTROL_READY,              /* ready to receive */
+    RDMA_CONTROL_QEMU_FILE,          /* QEMUFile-transmitted bytes */
+    RDMA_CONTROL_RAM_BLOCKS_REQUEST, /* RAMBlock synchronization */
+    RDMA_CONTROL_RAM_BLOCKS_RESULT,  /* RAMBlock synchronization */
+    RDMA_CONTROL_COMPRESS,           /* page contains repeat values */
+    RDMA_CONTROL_REGISTER_REQUEST,   /* dynamic page registration */
+    RDMA_CONTROL_REGISTER_RESULT,    /* key to use after registration */
+    RDMA_CONTROL_REGISTER_FINISHED,  /* current iteration finished */
+};
+
+const char *control_desc[] = {
+        [RDMA_CONTROL_NONE] = "NONE",
+        [RDMA_CONTROL_ERROR] = "ERROR",
+        [RDMA_CONTROL_READY] = "READY",
+        [RDMA_CONTROL_QEMU_FILE] = "QEMU FILE",
+        [RDMA_CONTROL_RAM_BLOCKS_REQUEST] = "RAM BLOCKS REQUEST",
+        [RDMA_CONTROL_RAM_BLOCKS_RESULT] = "RAM BLOCKS RESULT",
+        [RDMA_CONTROL_COMPRESS] = "COMPRESS",
+        [RDMA_CONTROL_REGISTER_REQUEST] = "REGISTER REQUEST",
+        [RDMA_CONTROL_REGISTER_RESULT] = "REGISTER RESULT",
+        [RDMA_CONTROL_REGISTER_FINISHED] = "REGISTER FINISHED",
+};
+
+/*
+ * Memory and MR structures used to represent an IB Send/Recv work request.
+ * This is *not* used for RDMA, only IB Send/Recv.
+ */
+typedef struct {
+    uint8_t  control[RDMA_CONTROL_MAX_BUFFER]; /* actual buffer to register */
+    struct   ibv_mr *control_mr;               /* registration metadata */
+    size_t   control_len;                      /* length of the message */
+    uint8_t *control_curr;                     /* start of unconsumed bytes */
+} RDMAWorkRequestData;
+
+/*
+ * Negotiate RDMA capabilities during connection-setup time.
+ */
+typedef struct {
+    uint32_t version;
+    uint32_t flags;
+} RDMACapabilities;
+
+static void caps_to_network(RDMACapabilities *cap)
+{
+    cap->version = htonl(cap->version);
+    cap->flags = htonl(cap->flags);
+}
+
+static void network_to_caps(RDMACapabilities *cap)
+{
+    cap->version = ntohl(cap->version);
+    cap->flags = ntohl(cap->flags);
+}
+
+/*
+ * Representation of a RAMBlock from an RDMA perspective.
+ * This is not transmitted, only local.
+ * This and subsequent structures cannot be linked lists
+ * because we're using a single IB message to transmit
+ * the information. It's small anyway, so a list is overkill.
+ */
+typedef struct RDMALocalBlock {
+    uint8_t  *local_host_addr; /* local virtual address */
+    uint64_t remote_host_addr; /* remote virtual address */
+    uint64_t offset;
+    uint64_t length;
+    struct   ibv_mr **pmr;     /* MRs for chunk-level registration */
+    struct   ibv_mr *mr;       /* MR for non-chunk-level registration */
+    uint32_t *remote_keys;     /* rkeys for chunk-level registration */
+    uint32_t remote_rkey;      /* rkeys for non-chunk-level registration */
+    int      index;            /* which block are we */
+} RDMALocalBlock;
+
+/*
+ * Also represents a RAMblock, but only on the dest.
+ * This gets transmitted by the dest during connection-time
+ * to the source / primary VM and then is used to populate the
+ * corresponding RDMALocalBlock with
+ * the information needed to perform the actual RDMA.
+ */
+typedef struct QEMU_PACKED RDMARemoteBlock {
+    uint64_t remote_host_addr;
+    uint64_t offset;
+    uint64_t length;
+    uint32_t remote_rkey;
+    uint32_t padding;
+} QEMU_PACKED RDMARemoteBlock;
+
+/*
+ * Virtual address of the above structures used for transmitting
+ * the RAMBlock descriptions at connection-time.
+ * This structure is *not* transmitted.
+ */
+typedef struct RDMALocalBlocks {
+    int num_blocks;
+    RDMALocalBlock *block;
+} RDMALocalBlocks;
+
+typedef struct RDMATransit {
+    uintptr_t addr;
+    int64_t len;
+} RDMATransit;
+
+/*
+ * Main data structure for RDMA state.
+ * While there is only one copy of this structure being allocated right now,
+ * this is the place where one would start if you wanted to consider
+ * having more than one RDMA connection open at the same time.
+ */
+typedef struct RDMAContext {
+    char *host;
+    int port;
+
+    /* This is used by the migration protocol to transmit
+     * control messages (such as device state and registration commands)
+     *
+     * WR #0 is for control channel ready messages from the destination.
+     * WR #1 is for control channel data messages from the destination.
+     * WR #2 is for control channel send messages.
+     *
+     * We could use more WRs, but we have enough for now.
+     */
+    RDMAWorkRequestData wr_data[RDMA_CONTROL_MAX_WR + 1];
+
+    /*
+     * This is used by *_exchange_send() to figure out whether or not
+     * the initial "READY" message has already been received or not.
+     * This is because other functions may potentially poll() and detect
+     * the READY message before send() does, in which case we need to
+     * know if it completed.
+     */
+    int control_ready_expected;
+
+    /* number of outstanding signaled send */
+    int num_signaled_send;
+
+    /* store info about current buffer so that we can
+       merge it with future sends */
+    uint64_t current_offset;
+    uint64_t current_length;
+    /* index of ram block the current buffer belongs to */
+    int current_index;
+    /* index of the chunk in the current ram block */
+    int current_chunk;
+
+    bool pin_all;
+
+    /*
+     * infiniband-specific variables for opening the device
+     * and maintaining connection state and so forth.
+     *
+     * cm_id also has ibv_context, rdma_event_channel, and ibv_qp in
+     * cm_id->verbs, cm_id->channel, and cm_id->qp.
+     */
+    struct rdma_cm_id *cm_id;               /* connection manager ID */
+    struct rdma_cm_id *listen_id;
+
+    struct ibv_context *verbs;
+    struct rdma_event_channel *channel;
+    struct ibv_qp *qp;                      /* queue pair */
+    struct ibv_comp_channel *comp_channel;  /* completion channel */
+    struct ibv_pd *pd;                      /* protection domain */
+    struct ibv_cq *cq;                      /* completion queue */
+
+    /*
+     * If a previous write failed (perhaps because of a failed
+     * memory registration, then do not attempt any future work
+     * and remember the error state.
+     */
+    int error_state;
+    int error_reported;
+
+    /*
+     * Description of ram blocks used throughout the code.
+     */
+    RDMALocalBlocks local_ram_blocks;
+    RDMARemoteBlock *block;
+
+    /*
+     * Migration on *destination* started.
+     * Then use coroutine yield function.
+     * Source runs in a thread, so we don't care.
+     */
+    int migration_started_on_destination;
+
+    int total_registrations;
+
+    /*
+     * Circular array holding outsanding signaled work requests
+     * used to detect whether or not a chunk is "in transit"
+     * for an RDMA operation. Since RDMA operations can happen
+     * out of order, we cannot issue a new operation unless a previous
+     * operation for the same chunk start address has already completed.
+     */
+    RDMATransit in_transit[RDMA_SIGNALED_SEND_MAX];
+    int nb_transit;
+} RDMAContext;
+
+/*
+ * Interface to the rest of the migration call stack.
+ */
+typedef struct QEMUFileRDMA {
+    RDMAContext *rdma;
+    size_t len;
+    void *file;
+} QEMUFileRDMA;
+
+#define RDMA_CONTROL_VERSION_CURRENT 1
+
+/*
+ * Main structure for IB Send/Recv control messages.
+ * This gets prepended at the beginning of every Send/Recv.
+ */
+typedef struct QEMU_PACKED {
+    uint32_t len;     /* Total length of data portion */
+    uint32_t type;    /* which control command to perform */
+    uint32_t repeat;  /* number of commands in data portion of same type */
+    uint32_t padding;
+} QEMU_PACKED RDMAControlHeader;
+
+static void control_to_network(RDMAControlHeader *control)
+{
+    control->type = htonl(control->type);
+    control->len = htonl(control->len);
+    control->repeat = htonl(control->repeat);
+}
+
+static void network_to_control(RDMAControlHeader *control)
+{
+    control->type = ntohl(control->type);
+    control->len = ntohl(control->len);
+    control->repeat = ntohl(control->repeat);
+}
+
+/*
+ * Register a single Chunk.
+ * Information sent by the primary VM to inform the dest
+ * to register an single chunk of memory before we can perform
+ * the actual RDMA operation.
+ */
+typedef struct QEMU_PACKED {
+    uint32_t len;           /* length of the chunk to be registered */
+    uint32_t current_index; /* which ramblock the chunk belongs to */
+    uint64_t offset;        /* offset into the ramblock of the chunk */
+} QEMU_PACKED RDMARegister;
+
+typedef struct QEMU_PACKED {
+    uint32_t value;     /* if zero, we will madvise() */
+    uint32_t block_idx; /* which ram block index */
+    uint64_t offset;    /* where in the remote ramblock this chunk */
+    uint64_t length;    /* length of the chunk */
+} QEMU_PACKED RDMACompress;
+
+/*
+ * The result of the dest's memory registration produces an "rkey"
+ * which the primary VM must reference in order to perform
+ * the RDMA operation.
+ */
+typedef struct QEMU_PACKED {
+    uint32_t rkey;
+    uint32_t padding;
+} QEMU_PACKED RDMARegisterResult;
+
+static inline uint64_t ram_chunk_index(uint8_t *start, uint8_t *host)
+{
+    return ((uintptr_t) host - (uintptr_t) start) >> RDMA_REG_CHUNK_SHIFT;
+}
+
+static inline uint64_t ram_chunk_count(RDMALocalBlock *rdma_ram_block)
+{
+    return ram_chunk_index(rdma_ram_block->local_host_addr,
+        rdma_ram_block->local_host_addr + rdma_ram_block->length) + 1UL;
+}
+
+static inline uint8_t *ram_chunk_start(RDMALocalBlock *rdma_ram_block,
+                                       uint64_t i)
+{
+    return (uint8_t *) (((uintptr_t) rdma_ram_block->local_host_addr)
+                                    + (i << RDMA_REG_CHUNK_SHIFT));
+}
+
+static inline uint8_t *ram_chunk_end(RDMALocalBlock *rdma_ram_block, uint64_t i)
+{
+    uint8_t *result = ram_chunk_start(rdma_ram_block, i) +
+                                         (1UL << RDMA_REG_CHUNK_SHIFT);
+
+    if (result > (rdma_ram_block->local_host_addr + rdma_ram_block->length)) {
+        result = rdma_ram_block->local_host_addr + rdma_ram_block->length;
+    }
+
+    return result;
+}
+
+
+/*
+ * Memory regions need to be registered with the device and queue pairs setup
+ * in advanced before the migration starts. This tells us where the RAM blocks
+ * are so that we can register them individually.
+ */
+static void qemu_rdma_init_one_block(void *host_addr,
+    ram_addr_t offset, ram_addr_t length, void *opaque)
+{
+    RDMALocalBlocks *rdma_local_ram_blocks = opaque;
+    int num_blocks = rdma_local_ram_blocks->num_blocks;
+
+    rdma_local_ram_blocks->block[num_blocks].local_host_addr = host_addr;
+    rdma_local_ram_blocks->block[num_blocks].offset = (uint64_t)offset;
+    rdma_local_ram_blocks->block[num_blocks].length = (uint64_t)length;
+    rdma_local_ram_blocks->block[num_blocks].index = num_blocks;
+
+    DPRINTF("Block: %d, addr: %" PRIu64 ", offset: %" PRIu64
+           " length: %" PRIu64 " end: %" PRIu64 "\n",
+            num_blocks, (uint64_t) host_addr, offset, length,
+            (uint64_t) (host_addr + length));
+
+    rdma_local_ram_blocks->num_blocks++;
+
+}
+
+static void qemu_rdma_ram_block_counter(void *host_addr,
+            ram_addr_t offset, ram_addr_t length, void *opaque)
+{
+    int *num_blocks = opaque;
+    *num_blocks = *num_blocks + 1;
+}
+
+/*
+ * Identify the RAMBlocks and their quantity. They will be references to
+ * identify chunk boundaries inside each RAMBlock and also be referenced
+ * during dynamic page registration.
+ */
+static int qemu_rdma_init_ram_blocks(RDMALocalBlocks *rdma_local_ram_blocks)
+{
+    int num_blocks = 0;
+
+    qemu_ram_foreach_block(qemu_rdma_ram_block_counter, &num_blocks);
+
+    memset(rdma_local_ram_blocks, 0, sizeof *rdma_local_ram_blocks);
+    rdma_local_ram_blocks->block = g_malloc0(sizeof(RDMALocalBlock) *
+                                    num_blocks);
+
+    rdma_local_ram_blocks->num_blocks = 0;
+    qemu_ram_foreach_block(qemu_rdma_init_one_block, rdma_local_ram_blocks);
+
+    DPRINTF("Allocated %d local ram block structures\n",
+                    rdma_local_ram_blocks->num_blocks);
+    return 0;
+}
+
+/*
+ * Put in the log file which RDMA device was opened and the details
+ * associated with that device.
+ */
+static void qemu_rdma_dump_id(const char *who, struct ibv_context *verbs)
+{
+    printf("%s RDMA Device opened: kernel name %s "
+           "uverbs device name %s, "
+           "infiniband_verbs class device path %s,"
+           " infiniband class device path %s\n",
+                who,
+                verbs->device->name,
+                verbs->device->dev_name,
+                verbs->device->dev_path,
+                verbs->device->ibdev_path);
+}
+
+/*
+ * Put in the log file the RDMA gid addressing information,
+ * useful for folks who have trouble understanding the
+ * RDMA device hierarchy in the kernel.
+ */
+static void qemu_rdma_dump_gid(const char *who, struct rdma_cm_id *id)
+{
+    char sgid[33];
+    char dgid[33];
+    inet_ntop(AF_INET6, &id->route.addr.addr.ibaddr.sgid, sgid, sizeof sgid);
+    inet_ntop(AF_INET6, &id->route.addr.addr.ibaddr.dgid, dgid, sizeof dgid);
+    DPRINTF("%s Source GID: %s, Dest GID: %s\n", who, sgid, dgid);
+}
+
+/*
+ * Figure out which RDMA device corresponds to the requested IP hostname
+ * Also create the initial connection manager identifiers for opening
+ * the connection.
+ */
+static int qemu_rdma_resolve_host(RDMAContext *rdma, Error **errp)
+{
+    int ret;
+    struct addrinfo *res;
+    char port_str[16];
+    struct rdma_cm_event *cm_event;
+    char ip[40] = "unknown";
+
+    if (rdma->host == NULL || !strcmp(rdma->host, "")) {
+        ERROR(errp, "RDMA hostname has not been set\n");
+        return -1;
+    }
+
+    /* create CM channel */
+    rdma->channel = rdma_create_event_channel();
+    if (!rdma->channel) {
+        ERROR(errp, "could not create CM channel\n");
+        return -1;
+    }
+
+    /* create CM id */
+    ret = rdma_create_id(rdma->channel, &rdma->cm_id, NULL, RDMA_PS_TCP);
+    if (ret) {
+        ERROR(errp, "could not create channel id\n");
+        goto err_resolve_create_id;
+    }
+
+    snprintf(port_str, 16, "%d", rdma->port);
+    port_str[15] = '\0';
+
+    ret = getaddrinfo(rdma->host, port_str, NULL, &res);
+    if (ret < 0) {
+        ERROR(errp, "could not getaddrinfo address %s\n", rdma->host);
+        goto err_resolve_get_addr;
+    }
+
+    inet_ntop(AF_INET, &((struct sockaddr_in *) res->ai_addr)->sin_addr,
+                                ip, sizeof ip);
+    DPRINTF("%s => %s\n", rdma->host, ip);
+
+    /* resolve the first address */
+    ret = rdma_resolve_addr(rdma->cm_id, NULL, res->ai_addr,
+            RDMA_RESOLVE_TIMEOUT_MS);
+    if (ret) {
+        ERROR(errp, "could not resolve address %s\n", rdma->host);
+        goto err_resolve_get_addr;
+    }
+
+    qemu_rdma_dump_gid("source_resolve_addr", rdma->cm_id);
+
+    ret = rdma_get_cm_event(rdma->channel, &cm_event);
+    if (ret) {
+        ERROR(errp, "could not perform event_addr_resolved\n");
+        goto err_resolve_get_addr;
+    }
+
+    if (cm_event->event != RDMA_CM_EVENT_ADDR_RESOLVED) {
+        ERROR(errp, "result not equal to event_addr_resolved %s\n",
+                rdma_event_str(cm_event->event));
+        perror("rdma_resolve_addr");
+        goto err_resolve_get_addr;
+    }
+    rdma_ack_cm_event(cm_event);
+
+    /* resolve route */
+    ret = rdma_resolve_route(rdma->cm_id, RDMA_RESOLVE_TIMEOUT_MS);
+    if (ret) {
+        ERROR(errp, "could not resolve rdma route\n");
+        goto err_resolve_get_addr;
+    }
+
+    ret = rdma_get_cm_event(rdma->channel, &cm_event);
+    if (ret) {
+        ERROR(errp, "could not perform event_route_resolved\n");
+        goto err_resolve_get_addr;
+    }
+    if (cm_event->event != RDMA_CM_EVENT_ROUTE_RESOLVED) {
+        ERROR(errp, "result not equal to event_route_resolved: %s\n",
+                        rdma_event_str(cm_event->event));
+        rdma_ack_cm_event(cm_event);
+        goto err_resolve_get_addr;
+    }
+    rdma_ack_cm_event(cm_event);
+    rdma->verbs = rdma->cm_id->verbs;
+    qemu_rdma_dump_id("source_resolve_host", rdma->cm_id->verbs);
+    qemu_rdma_dump_gid("source_resolve_host", rdma->cm_id);
+    return 0;
+
+err_resolve_get_addr:
+    rdma_destroy_id(rdma->cm_id);
+    rdma->cm_id = 0;
+err_resolve_create_id:
+    rdma_destroy_event_channel(rdma->channel);
+    rdma->channel = NULL;
+
+    return -1;
+}
+
+/*
+ * Create protection domain and completion queues
+ */
+static int qemu_rdma_alloc_pd_cq(RDMAContext *rdma)
+{
+    /* allocate pd */
+    rdma->pd = ibv_alloc_pd(rdma->verbs);
+    if (!rdma->pd) {
+        fprintf(stderr, "failed to allocate protection domain\n");
+        return -1;
+    }
+
+    /* create completion channel */
+    rdma->comp_channel = ibv_create_comp_channel(rdma->verbs);
+    if (!rdma->comp_channel) {
+        fprintf(stderr, "failed to allocate completion channel\n");
+        goto err_alloc_pd_cq;
+    }
+
+    /*
+     * Completion queue can be filled by both read and write work requests,
+     * so must reflect the sum of both possible queue sizes.
+     */
+    rdma->cq = ibv_create_cq(rdma->verbs, (RDMA_SIGNALED_SEND_MAX * 3),
+            NULL, rdma->comp_channel, 0);
+    if (!rdma->cq) {
+        fprintf(stderr, "failed to allocate completion queue\n");
+        goto err_alloc_pd_cq;
+    }
+
+    return 0;
+
+err_alloc_pd_cq:
+    if (rdma->pd) {
+        ibv_dealloc_pd(rdma->pd);
+    }
+    if (rdma->comp_channel) {
+        ibv_destroy_comp_channel(rdma->comp_channel);
+    }
+    rdma->pd = NULL;
+    rdma->comp_channel = NULL;
+    return -1;
+
+}
+
+/*
+ * Create queue pairs.
+ */
+static int qemu_rdma_alloc_qp(RDMAContext *rdma)
+{
+    struct ibv_qp_init_attr attr = { 0 };
+    int ret;
+
+    attr.cap.max_send_wr = RDMA_SIGNALED_SEND_MAX;
+    attr.cap.max_recv_wr = 3;
+    attr.cap.max_send_sge = 1;
+    attr.cap.max_recv_sge = 1;
+    attr.send_cq = rdma->cq;
+    attr.recv_cq = rdma->cq;
+    attr.qp_type = IBV_QPT_RC;
+
+    ret = rdma_create_qp(rdma->cm_id, rdma->pd, &attr);
+    if (ret) {
+        return -1;
+    }
+
+    rdma->qp = rdma->cm_id->qp;
+    return 0;
+}
+
+static int qemu_rdma_reg_whole_ram_blocks(RDMAContext *rdma)
+{
+    int i;
+    RDMALocalBlocks *rdma_local_ram_blocks = &rdma->local_ram_blocks;
+
+    for (i = 0; i < rdma_local_ram_blocks->num_blocks; i++) {
+        rdma_local_ram_blocks->block[i].mr =
+            ibv_reg_mr(rdma->pd,
+                    rdma_local_ram_blocks->block[i].local_host_addr,
+                    rdma_local_ram_blocks->block[i].length,
+                    IBV_ACCESS_LOCAL_WRITE |
+                    IBV_ACCESS_REMOTE_WRITE
+                    );
+        if (!rdma_local_ram_blocks->block[i].mr) {
+            perror("Failed to register local dest ram block!\n");
+            break;
+        }
+        rdma->total_registrations++;
+    }
+
+    if (i >= rdma_local_ram_blocks->num_blocks) {
+        return 0;
+    }
+
+    for (i--; i >= 0; i--) {
+        ibv_dereg_mr(rdma_local_ram_blocks->block[i].mr);
+        rdma->total_registrations--;
+    }
+
+    return -1;
+
+}
+
+/*
+ * Shutdown and clean things up.
+ */
+static void qemu_rdma_dereg_ram_blocks(RDMAContext *rdma,
+                                       RDMALocalBlocks *rdma_local_ram_blocks)
+{
+    int i, j;
+    for (i = 0; i < rdma_local_ram_blocks->num_blocks; i++) {
+        int num_chunks;
+        if (!rdma_local_ram_blocks->block[i].pmr) {
+            continue;
+        }
+        num_chunks = ram_chunk_count(&(rdma_local_ram_blocks->block[i]));
+        for (j = 0; j < num_chunks; j++) {
+            if (!rdma_local_ram_blocks->block[i].pmr[j]) {
+                continue;
+            }
+            ibv_dereg_mr(rdma_local_ram_blocks->block[i].pmr[j]);
+            rdma->total_registrations--;
+        }
+        g_free(rdma_local_ram_blocks->block[i].pmr);
+        rdma_local_ram_blocks->block[i].pmr = NULL;
+    }
+    for (i = 0; i < rdma_local_ram_blocks->num_blocks; i++) {
+        if (!rdma_local_ram_blocks->block[i].mr) {
+            continue;
+        }
+        ibv_dereg_mr(rdma_local_ram_blocks->block[i].mr);
+        rdma->total_registrations--;
+        rdma_local_ram_blocks->block[i].mr = NULL;
+    }
+}
+
+/*
+ * The protocol uses two different sets of rkeys (mutually exclusive):
+ * 1. One key to represent the virtual address of the entire ram block.
+ *    (dynamic chunk registration disabled - pin everything with one rkey.)
+ * 2. One to represent individual chunks within a ram block.
+ *    (dynamic chunk registration enabled - pin individual chunks.)
+ *
+ * Once the capability is successfully negotiated, the destination transmits
+ * the keys to use (or sends them later) including the virtual addresses
+ * and then propagates the remote ram block descriptions to his local copy.
+ */
+static int qemu_rdma_process_remote_blocks(RDMAContext *rdma, int num_blocks,
+                                           Error **errp)
+{
+    RDMALocalBlocks *local = &rdma->local_ram_blocks;
+    int i, j;
+
+    if (local->num_blocks != num_blocks) {
+        ERROR(errp, "ram blocks mismatch #1! "
+                    "Your QEMU command line parameters are probably "
+                    "not identical on both the source and destination.\n");
+        return -1;
+    }
+
+    for (i = 0; i < num_blocks; i++) {
+        /* search local ram blocks */
+        for (j = 0; j < local->num_blocks; j++) {
+            if (rdma->block[i].offset != local->block[j].offset) {
+                continue;
+            }
+            if (rdma->block[i].length != local->block[j].length) {
+                ERROR(errp, "ram blocks mismatch #2! "
+                            "Your QEMU command line parameters are probably "
+                            "not identical on both the source and destination.\n");
+                return -1;
+            }
+            local->block[j].remote_host_addr =
+                rdma->block[i].remote_host_addr;
+            local->block[j].remote_rkey = rdma->block[i].remote_rkey;
+            break;
+        }
+        if (j >= local->num_blocks) {
+            ERROR(errp, "ram blocks mismatch #3! "
+                        "Your QEMU command line parameters are probably "
+                        "not identical on both the source and destination.\n");
+            return -1;
+        }
+    }
+
+    return 0;
+}
+
+/*
+ * Find the ram block that corresponds to the page requested to be
+ * transmitted by QEMU.
+ *
+ * Once the block is found, also identify which 'chunk' within that
+ * block that the page belongs to.
+ *
+ * This search cannot fail or the migration will fail.
+ */
+static int qemu_rdma_search_ram_block(uint64_t offset, uint64_t length,
+        RDMALocalBlocks *blocks, int *block_index, int *chunk_index)
+{
+    int i;
+    uint8_t *host_addr;
+
+    for (i = 0; i < blocks->num_blocks; i++) {
+        if (offset < blocks->block[i].offset) {
+            continue;
+        }
+        if (offset + length >
+                blocks->block[i].offset + blocks->block[i].length) {
+            continue;
+        }
+
+        *block_index = i;
+        host_addr = blocks->block[i].local_host_addr +
+                (offset - blocks->block[i].offset);
+        *chunk_index = ram_chunk_index(blocks->block[i].local_host_addr,
+                        host_addr);
+        return 0;
+    }
+    return -1;
+}
+
+/*
+ * Register a chunk with IB. If the chunk was already registered
+ * previously, then skip.
+ *
+ * Also return the keys associated with the registration needed
+ * to perform the actual RDMA operation.
+ */
+static int qemu_rdma_register_and_get_keys(RDMAContext *rdma,
+        RDMALocalBlock *block, uint8_t * host_addr,
+        uint32_t *lkey, uint32_t *rkey)
+{
+    int chunk;
+    if (block->mr) {
+        if (lkey) {
+            *lkey = block->mr->lkey;
+        }
+        if (rkey) {
+            *rkey = block->mr->rkey;
+        }
+        return 0;
+    }
+
+    /* allocate memory to store chunk MRs */
+    if (!block->pmr) {
+        int num_chunks = ram_chunk_count(block);
+        block->pmr = g_malloc0(num_chunks *
+                sizeof(struct ibv_mr *));
+        if (!block->pmr) {
+            return -1;
+        }
+    }
+
+    /*
+     * If 'rkey', then we're the destination, so grant access to the source.
+     *
+     * If 'lkey', then we're the primary VM, so grant access only to ourselves.
+     */
+    chunk = ram_chunk_index(block->local_host_addr, host_addr);
+    if (!block->pmr[chunk]) {
+        uint8_t *start_addr = ram_chunk_start(block, chunk);
+        uint8_t *end_addr = ram_chunk_end(block, chunk);
+
+        block->pmr[chunk] = ibv_reg_mr(rdma->pd,
+                start_addr,
+                end_addr - start_addr,
+                (rkey ? (IBV_ACCESS_LOCAL_WRITE |
+                        IBV_ACCESS_REMOTE_WRITE) : 0));
+
+        if (!block->pmr[chunk]) {
+            perror("Failed to register chunk!");
+            fprintf(stderr, "Chunk details: block: %d chunk index %d"
+                            " start %" PRIu64 " end %" PRIu64 " host %" PRIu64
+                            " local %" PRIu64 " registrations: %d\n",
+                            block->index, chunk, (uint64_t) start_addr,
+                            (uint64_t) end_addr, (uint64_t) host_addr,
+                            (uint64_t) block->local_host_addr,
+                            rdma->total_registrations);
+            return -1;
+        }
+        rdma->total_registrations++;
+    }
+
+    if (lkey) {
+        *lkey = block->pmr[chunk]->lkey;
+    }
+    if (rkey) {
+        *rkey = block->pmr[chunk]->rkey;
+    }
+    return 0;
+}
+
+/*
+ * Register (at connection time) the memory used for control
+ * channel messages.
+ */
+static int qemu_rdma_reg_control(RDMAContext *rdma, int idx)
+{
+    rdma->wr_data[idx].control_mr = ibv_reg_mr(rdma->pd,
+            rdma->wr_data[idx].control, RDMA_CONTROL_MAX_BUFFER,
+            IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE);
+    if (rdma->wr_data[idx].control_mr) {
+        rdma->total_registrations++;
+        return 0;
+    }
+    fprintf(stderr, "qemu_rdma_reg_control failed!\n");
+    return -1;
+}
+
+static int qemu_rdma_dereg_control(RDMAContext *rdma, int idx)
+{
+    rdma->total_registrations--;
+    return ibv_dereg_mr(rdma->wr_data[idx].control_mr);
+}
+
+#if defined(DEBUG_RDMA_VERBOSE) && defined(DEBUG_RDMA_REALLY_VERBOSE)
+static const char *print_wrid(int wrid)
+{
+    if (wrid >= RDMA_WRID_RECV_CONTROL) {
+        return wrid_desc[RDMA_WRID_RECV_CONTROL];
+    } else if (wrid >= RDMA_WRID_RDMA_WRITE_START
+                && wrid <= RDMA_WRID_RDMA_WRITE_STOP) {
+        return wrid_desc[RDMA_WRID_RDMA_WRITE_START];
+    }
+    return wrid_desc[wrid];
+}
+#endif
+
+/*
+ * Consult the connection manager to see a work request
+ * (of any kind) has completed.
+ * Return the work request ID that completed.
+ */
+static int qemu_rdma_poll(RDMAContext *rdma)
+{
+    int ret;
+    struct ibv_wc wc;
+
+    ret = ibv_poll_cq(rdma->cq, 1, &wc);
+
+    if (!ret) {
+        return RDMA_WRID_NONE;
+    }
+
+    if (ret < 0) {
+        fprintf(stderr, "ibv_poll_cq return %d!\n", ret);
+        return ret;
+    }
+
+    if (wc.status != IBV_WC_SUCCESS) {
+        fprintf(stderr, "ibv_poll_cq wc.status=%d %s!\n",
+                        wc.status, ibv_wc_status_str(wc.status));
+        fprintf(stderr, "ibv_poll_cq wrid=%s!\n", wrid_desc[wc.wr_id]);
+
+        return -1;
+    }
+
+    if (rdma->control_ready_expected &&
+        (wc.wr_id >= RDMA_WRID_RECV_CONTROL)) {
+        DDDPRINTF("completion %s #%" PRId64 " received (%" PRId64 ")"
+                  " left %d\n", wrid_desc[RDMA_WRID_RECV_CONTROL],
+                  wc.wr_id - RDMA_WRID_RECV_CONTROL, wc.wr_id,
+                  rdma->num_signaled_send);
+        rdma->control_ready_expected = 0;
+    }
+
+    if ((wc.wr_id >= RDMA_WRID_RDMA_WRITE_START) &&
+            (wc.wr_id <= RDMA_WRID_RDMA_WRITE_STOP)) {
+        if (rdma->num_signaled_send > 0) {
+            rdma->num_signaled_send--;
+        }
+
+        DDDPRINTF("completions %s (%" PRId64 ") left %d\n",
+            print_wrid(wc.wr_id), wc.wr_id, rdma->num_signaled_send);
+        rdma->in_transit[wc.wr_id - RDMA_WRID_RDMA_WRITE_START].addr = 0;
+        rdma->in_transit[wc.wr_id - RDMA_WRID_RDMA_WRITE_START].len = 0;
+    } else {
+        DDDPRINTF("other completion %s (%" PRId64 ") received left %d\n",
+            print_wrid(wc.wr_id), wc.wr_id, rdma->num_signaled_send);
+    }
+
+    return  (int)wc.wr_id;
+}
+
+/*
+ * Block until the next work request has completed.
+ *
+ * First poll to see if a work request has already completed,
+ * otherwise block.
+ *
+ * If we encounter completed work requests for IDs other than
+ * the one we're interested in, then that's generally an error.
+ *
+ * The only exception is actual RDMA Write completions. These
+ * completions only need to be recorded, but do not actually
+ * need further processing.
+ */
+static int qemu_rdma_block_for_wrid(RDMAContext *rdma, int wrid_start,
+                                    int wrid_stop)
+{
+    int num_cq_events = 0;
+    int r = RDMA_WRID_NONE;
+    struct ibv_cq *cq;
+    void *cq_ctx;
+
+    if (ibv_req_notify_cq(rdma->cq, 0)) {
+        return -1;
+    }
+    /* poll cq first */
+    while ((r < wrid_start) || ((wrid_stop != -1) && (r > wrid_stop))) {
+        r = qemu_rdma_poll(rdma);
+        if (r < 0) {
+            return r;
+        }
+        if (r == RDMA_WRID_NONE) {
+            break;
+        }
+        if ((r < wrid_start) || ((wrid_stop != -1)
+                                && (r > wrid_stop))) {
+            DDDPRINTF("A Wanted wrid %s (%d, %d) but got %s (%d)\n",
+                print_wrid(wrid_start),
+                        wrid_start, wrid_stop, print_wrid(r), r);
+        }
+    }
+
+    if ((r >= wrid_start) && ((wrid_stop == -1) || (r <= wrid_stop))) {
+        return 0;
+    }
+
+    while (1) {
+        /*
+         * Coroutine doesn't start until process_incoming_migration()
+         * so don't yield unless we know we're running inside of a coroutine.
+         */
+        if (rdma->migration_started_on_destination) {
+            yield_until_fd_readable(rdma->comp_channel->fd);
+        }
+
+        if (ibv_get_cq_event(rdma->comp_channel, &cq, &cq_ctx)) {
+            perror("ibv_get_cq_event");
+            goto err_block_for_wrid;
+        }
+
+        num_cq_events++;
+
+        if (ibv_req_notify_cq(cq, 0)) {
+            goto err_block_for_wrid;
+        }
+
+        while ((r < wrid_start) || ((wrid_stop != -1) && (r > wrid_stop))) {
+            r = qemu_rdma_poll(rdma);
+            if (r < 0) {
+                goto err_block_for_wrid;
+            }
+            if (r == RDMA_WRID_NONE) {
+                break;
+            }
+            if ((r < wrid_start) || ((wrid_stop != -1) && (r > wrid_stop))) {
+                DDDPRINTF("B Wanted wrid %s (%d, %d) but got %s (%d)\n",
+                    print_wrid(wrid_start), wrid_start,
+                                        wrid_stop, print_wrid(r), r);
+            }
+        }
+
+        if ((r >= wrid_start) && ((wrid_stop == -1) || (r <= wrid_stop))) {
+            goto success_block_for_wrid;
+        }
+    }
+
+success_block_for_wrid:
+    if (num_cq_events) {
+        ibv_ack_cq_events(cq, num_cq_events);
+    }
+    return 0;
+
+err_block_for_wrid:
+    if (num_cq_events) {
+        ibv_ack_cq_events(cq, num_cq_events);
+    }
+    return -1;
+}
+
+/*
+ * Post a SEND message work request for the control channel
+ * containing some data and block until the post completes.
+ */
+static int qemu_rdma_post_send_control(RDMAContext *rdma, uint8_t *buf,
+                                       RDMAControlHeader *head)
+{
+    int ret = 0;
+    RDMAWorkRequestData *wr = &rdma->wr_data[RDMA_CONTROL_MAX_WR];
+    struct ibv_send_wr *bad_wr;
+    struct ibv_sge sge = {
+                           .addr = (uint64_t)(wr->control),
+                           .length = head->len + sizeof(RDMAControlHeader),
+                           .lkey = wr->control_mr->lkey,
+                         };
+    struct ibv_send_wr send_wr = {
+                                   .wr_id = RDMA_WRID_SEND_CONTROL,
+                                   .opcode = IBV_WR_SEND,
+                                   .send_flags = IBV_SEND_SIGNALED,
+                                   .sg_list = &sge,
+                                   .num_sge = 1,
+                                };
+
+    DDDPRINTF("CONTROL: sending %s..\n", control_desc[head->type]);
+
+    /*
+     * We don't actually need to do a memcpy() in here if we used
+     * the "sge" properly, but since we're only sending control messages
+     * (not RAM in a performance-critical path), then its OK for now.
+     *
+     * The copy makes the RDMAControlHeader simpler to manipulate
+     * for the time being.
+     */
+    memcpy(wr->control, head, sizeof(RDMAControlHeader));
+    control_to_network((void *) wr->control);
+
+    if (buf) {
+        memcpy(wr->control + sizeof(RDMAControlHeader), buf, head->len);
+    }
+
+
+    if (ibv_post_send(rdma->qp, &send_wr, &bad_wr)) {
+        return -1;
+    }
+
+    if (ret < 0) {
+        fprintf(stderr, "Failed to use post IB SEND for control!\n");
+        return ret;
+    }
+
+    ret = qemu_rdma_block_for_wrid(rdma, RDMA_WRID_SEND_CONTROL, -1);
+    if (ret < 0) {
+        fprintf(stderr, "rdma migration: send polling control error!\n");
+    }
+
+    return ret;
+}
+
+/*
+ * Post a RECV work request in anticipation of some future receipt
+ * of data on the control channel.
+ */
+static int qemu_rdma_post_recv_control(RDMAContext *rdma, int idx)
+{
+    struct ibv_recv_wr *bad_wr;
+    struct ibv_sge sge = {
+                            .addr = (uint64_t)(rdma->wr_data[idx].control),
+                            .length = RDMA_CONTROL_MAX_BUFFER,
+                            .lkey = rdma->wr_data[idx].control_mr->lkey,
+                         };
+
+    struct ibv_recv_wr recv_wr = {
+                                    .wr_id = RDMA_WRID_RECV_CONTROL + idx,
+                                    .sg_list = &sge,
+                                    .num_sge = 1,
+                                 };
+
+
+    if (ibv_post_recv(rdma->qp, &recv_wr, &bad_wr)) {
+        return -1;
+    }
+
+    return 0;
+}
+
+/*
+ * Block and wait for a RECV control channel message to arrive.
+ */
+static int qemu_rdma_exchange_get_response(RDMAContext *rdma,
+                RDMAControlHeader *head, int expecting, int idx)
+{
+    int ret = qemu_rdma_block_for_wrid(rdma, RDMA_WRID_RECV_CONTROL + idx, -1);
+
+    if (ret < 0) {
+        fprintf(stderr, "rdma migration: recv polling control error!\n");
+        return ret;
+    }
+
+    network_to_control((void *) rdma->wr_data[idx].control);
+    memcpy(head, rdma->wr_data[idx].control, sizeof(RDMAControlHeader));
+
+    DDDPRINTF("CONTROL: %s received\n", control_desc[expecting]);
+
+    if ((expecting != RDMA_CONTROL_NONE && head->type != expecting)
+            || head->type == RDMA_CONTROL_ERROR) {
+        fprintf(stderr, "Was expecting a %s (%d) control message"
+                ", but got: %s (%d), length: %d\n",
+                control_desc[expecting], expecting,
+                control_desc[head->type], head->type, head->len);
+        return -EIO;
+    }
+
+    return 0;
+}
+
+/*
+ * When a RECV work request has completed, the work request's
+ * buffer is pointed at the header.
+ *
+ * This will advance the pointer to the data portion
+ * of the control message of the work request's buffer that
+ * was populated after the work request finished.
+ */
+static void qemu_rdma_move_header(RDMAContext *rdma, int idx,
+                                  RDMAControlHeader *head)
+{
+    rdma->wr_data[idx].control_len = head->len;
+    rdma->wr_data[idx].control_curr =
+        rdma->wr_data[idx].control + sizeof(RDMAControlHeader);
+}
+
+/*
+ * This is an 'atomic' high-level operation to deliver a single, unified
+ * control-channel message.
+ *
+ * Additionally, if the user is expecting some kind of reply to this message,
+ * they can request a 'resp' response message be filled in by posting an
+ * additional work request on behalf of the user and waiting for an additional
+ * completion.
+ *
+ * The extra (optional) response is used during registration to us from having
+ * to perform an *additional* exchange of message just to provide a response by
+ * instead piggy-backing on the acknowledgement.
+ */
+static int qemu_rdma_exchange_send(RDMAContext *rdma, RDMAControlHeader *head,
+                                   uint8_t *data, RDMAControlHeader *resp,
+                                   int *resp_idx,
+                                   int (*callback)(RDMAContext *rdma))
+{
+    int ret = 0;
+    int idx = 0;
+
+    /*
+     * Wait until the dest is ready before attempting to deliver the message
+     * by waiting for a READY message.
+     */
+    if (rdma->control_ready_expected) {
+        RDMAControlHeader resp;
+        ret = qemu_rdma_exchange_get_response(rdma,
+                                    &resp, RDMA_CONTROL_READY, idx);
+        if (ret < 0) {
+            return ret;
+        }
+    }
+
+    /*
+     * If the user is expecting a response, post a WR in anticipation of it.
+     */
+    if (resp) {
+        ret = qemu_rdma_post_recv_control(rdma, idx + 1);
+        if (ret) {
+            fprintf(stderr, "rdma migration: error posting"
+                    " extra control recv for anticipated result!");
+            return ret;
+        }
+    }
+
+    /*
+     * Post a WR to replace the one we just consumed for the READY message.
+     */
+    ret = qemu_rdma_post_recv_control(rdma, idx);
+    if (ret) {
+        fprintf(stderr, "rdma migration: error posting first control recv!");
+        return ret;
+    }
+
+    /*
+     * Deliver the control message that was requested.
+     */
+    ret = qemu_rdma_post_send_control(rdma, data, head);
+
+    if (ret < 0) {
+        fprintf(stderr, "Failed to send control buffer!\n");
+        return ret;
+    }
+
+    /*
+     * If we're expecting a response, block and wait for it.
+     */
+    if (resp) {
+        if (callback) {
+            DPRINTF("Issuing callback before receiving response...\n");
+            ret = callback(rdma);
+            if (ret < 0) {
+                return ret;
+            }
+        }
+
+        DDPRINTF("Waiting for response %s\n", control_desc[resp->type]);
+        ret = qemu_rdma_exchange_get_response(rdma, resp, resp->type, idx + 1);
+
+        if (ret < 0) {
+            return ret;
+        }
+
+        qemu_rdma_move_header(rdma, idx + 1, resp);
+        *resp_idx = idx + 1;
+        DDPRINTF("Response %s received.\n", control_desc[resp->type]);
+    }
+
+    rdma->control_ready_expected = 1;
+
+    return 0;
+}
+
+/*
+ * This is an 'atomic' high-level operation to receive a single, unified
+ * control-channel message.
+ */
+static int qemu_rdma_exchange_recv(RDMAContext *rdma, RDMAControlHeader *head,
+                                int expecting)
+{
+    RDMAControlHeader ready = {
+                                .len = 0,
+                                .type = RDMA_CONTROL_READY,
+                                .repeat = 1,
+                              };
+    int ret;
+
+    /*
+     * Inform the source that we're ready to receive a message.
+     */
+    ret = qemu_rdma_post_send_control(rdma, NULL, &ready);
+
+    if (ret < 0) {
+        fprintf(stderr, "Failed to send control buffer!\n");
+        return ret;
+    }
+
+    /*
+     * Block and wait for the message.
+     */
+    ret = qemu_rdma_exchange_get_response(rdma, head, expecting, 0);
+
+    if (ret < 0) {
+        return ret;
+    }
+
+    qemu_rdma_move_header(rdma, 0, head);
+
+    /*
+     * Post a new RECV work request to replace the one we just consumed.
+     */
+    ret = qemu_rdma_post_recv_control(rdma, 0);
+    if (ret) {
+        fprintf(stderr, "rdma migration: error posting second control recv!");
+        return ret;
+    }
+
+    return 0;
+}
+
+/*
+ * Write an actual chunk of memory using RDMA.
+ *
+ * If we're using dynamic registration on the dest-side, we have to
+ * send a registration command first.
+ */
+static int qemu_rdma_write_one(QEMUFile *f, RDMAContext *rdma,
+        int current_index, uint64_t offset, uint64_t length,
+        enum ibv_send_flags flag)
+{
+    struct ibv_sge sge;
+    struct ibv_send_wr send_wr = { 0 };
+    struct ibv_send_wr *bad_wr;
+    RDMALocalBlock *block = &(rdma->local_ram_blocks.block[current_index]);
+    int chunk;
+    int x;
+    RDMARegister reg;
+    RDMARegisterResult *reg_result;
+    int reg_result_idx;
+    RDMAControlHeader resp = { .type = RDMA_CONTROL_REGISTER_RESULT };
+    RDMAControlHeader head = { .len = sizeof(RDMARegister),
+                               .type = RDMA_CONTROL_REGISTER_REQUEST,
+                               .repeat = 1,
+                             };
+    int ret;
+
+    sge.addr = (uint64_t)(block->local_host_addr + (offset - block->offset));
+    sge.length = length;
+
+    /*
+     * Search the existing work request identifiers to make sure the address of
+     * this request (either a zero chunk or a regular chunk) does not overlap
+     * with any of the address ranges outstanding on the wire.
+     */
+    for (x = RDMA_WRID_RDMA_WRITE_START; x < RDMA_WRID_RDMA_WRITE_STOP; x++) {
+        int len = rdma->in_transit[x].len;
+        uintptr_t start = rdma->in_transit[x].addr, end = start + len;
+
+        if (!start && !len) {
+            continue;
+        }
+
+        if ((sge.addr >= start) && (sge.addr < end)) {
+            DPRINTF("Not clobbering: start %" PRIu64 " end %" PRIu64
+                    " len %d current %" PRIu64 " len %" PRIu64 " wrid %d\n",
+                    start, end, len, sge.addr, length, x);
+
+            ret = qemu_rdma_block_for_wrid(rdma, x, -1);
+            if (ret < 0) {
+                fprintf(stderr, "Failed to Wait for previous write to complete "
+                        "start %" PRIu64 " end %" PRIu64
+                        " len %d current %" PRIu64 " len %" PRIu64 " wrid %d\n",
+                        start, end, len, sge.addr, length, x);
+                return ret;
+            }
+        }
+    }
+
+    if (!rdma->pin_all) {
+        chunk = ram_chunk_index(block->local_host_addr, (uint8_t *) sge.addr);
+        if (!block->remote_keys[chunk]) {
+            /*
+             * This page has not yet been registered, so first check to see
+             * if the entire chunk is zero. If so, tell the other size to
+             * memset() + madvise() the entire chunk without RDMA.
+             */
+
+            if (can_use_buffer_find_nonzero_offset((void *)sge.addr, length)
+                   && buffer_find_nonzero_offset((void *)sge.addr,
+                                                    length) == length) {
+                RDMACompress comp = {
+                                        .offset = offset,
+                                        .value = 0,
+                                        .block_idx = current_index,
+                                        .length = length,
+                                    };
+
+                head.len = sizeof(comp);
+                head.type = RDMA_CONTROL_COMPRESS;
+
+                DDPRINTF("Entire chunk is zero, sending compress: %d for %d "
+                    "bytes, index: %d, offset: %" PRId64 "...\n",
+                    chunk, sge.length, current_index, offset);
+
+                ret = qemu_rdma_exchange_send(rdma, &head,
+                                (uint8_t *) &comp, NULL, NULL, NULL);
+
+                if (ret < 0) {
+                    return -EIO;
+                }
+
+                acct_update_position(f, sge.length, true);
+
+                return 1;
+            }
+
+            /*
+             * Otherwise, tell other side to register.
+             */
+            reg.len = sge.length;
+            reg.current_index = current_index;
+            reg.offset = offset;
+
+            DDPRINTF("Sending registration request chunk %d for %d "
+                    "bytes, index: %d, offset: %" PRId64 "...\n",
+                    chunk, sge.length, current_index, offset);
+
+            ret = qemu_rdma_exchange_send(rdma, &head, (uint8_t *) &reg,
+                                    &resp, &reg_result_idx, NULL);
+            if (ret < 0) {
+                return ret;
+            }
+
+            /* try to overlap this single registration with the one we sent. */
+            if (qemu_rdma_register_and_get_keys(rdma, block,
+                                                (uint8_t *) sge.addr,
+                                                &sge.lkey, NULL)) {
+                fprintf(stderr, "cannot get lkey!\n");
+                return -EINVAL;
+            }
+
+            reg_result = (RDMARegisterResult *)
+                    rdma->wr_data[reg_result_idx].control_curr;
+
+            DDPRINTF("Received registration result:"
+                    " my key: %x their key %x, chunk %d\n",
+                    block->remote_keys[chunk], reg_result->rkey, chunk);
+
+            block->remote_keys[chunk] = reg_result->rkey;
+        } else {
+            /* already registered before */
+            if (qemu_rdma_register_and_get_keys(rdma, block,
+                                                (uint8_t *)sge.addr,
+                                                &sge.lkey, NULL)) {
+                fprintf(stderr, "cannot get lkey!\n");
+                return -EINVAL;
+            }
+        }
+
+        send_wr.wr.rdma.rkey = block->remote_keys[chunk];
+    } else {
+        send_wr.wr.rdma.rkey = block->remote_rkey;
+
+        if (qemu_rdma_register_and_get_keys(rdma, block, (uint8_t *)sge.addr,
+                                                     &sge.lkey, NULL)) {
+            fprintf(stderr, "cannot get lkey!\n");
+            return -EINVAL;
+        }
+    }
+
+    /*
+     * Before we select this new work request identifier, make sure there's
+     * enough space available in the available work request ID tracking space
+     * to use this identifier. Otherwise, block.
+     */
+    send_wr.wr_id = RDMA_WRID_RDMA_WRITE_START + rdma->nb_transit;
+
+    if (rdma->in_transit[rdma->nb_transit].addr != 0 &&
+        rdma->in_transit[rdma->nb_transit].len != 0) {
+        DDPRINTF("no slots left! make more %d %" PRIu64 "\n",
+                    rdma->nb_transit, send_wr.wr_id);
+
+        ret = qemu_rdma_block_for_wrid(rdma, send_wr.wr_id, -1);
+        if (ret < 0) {
+            fprintf(stderr, "Slots are full. Failed to "
+                "Wait for previous write to complete... %d %" PRIu64 "\n",
+                rdma->nb_transit, send_wr.wr_id);
+            return ret;
+        }
+    }
+
+    rdma->in_transit[rdma->nb_transit].addr = sge.addr;
+    rdma->in_transit[rdma->nb_transit].len = sge.length;
+
+    rdma->nb_transit++;
+
+    DDPRINTF("Next wrid: %" PRIu64 ", start: %d, max: %d\n", send_wr.wr_id,
+            RDMA_WRID_RDMA_WRITE_START, RDMA_WRID_RDMA_WRITE_STOP);
+
+    if (rdma->nb_transit == (RDMA_SIGNALED_SEND_MAX - 1)) {
+        rdma->nb_transit = 0;
+        DDPRINTF("Resetting nb_transit to zero\n");
+    }
+
+
+    send_wr.opcode = IBV_WR_RDMA_WRITE;
+    send_wr.send_flags = flag;
+    send_wr.sg_list = &sge;
+    send_wr.num_sge = 1;
+    send_wr.wr.rdma.remote_addr = block->remote_host_addr +
+                                    (offset - block->offset);
+
+
+    acct_update_position(f, sge.length, false);
+
+    return ibv_post_send(rdma->qp, &send_wr, &bad_wr);
+}
+
+/*
+ * Push out any unwritten RDMA operations.
+ *
+ * We support sending out multiple chunks at the same time.
+ * Not all of them need to get signaled in the completion queue.
+ */
+static int qemu_rdma_write_flush(QEMUFile *f, RDMAContext *rdma)
+{
+    int ret;
+    enum ibv_send_flags flags = IBV_SEND_SIGNALED;
+
+    if (!rdma->current_length) {
+        return 0;
+    }
+
+retry:
+    ret = qemu_rdma_write_one(f, rdma,
+            rdma->current_index,
+            rdma->current_offset,
+            rdma->current_length,
+            flags);
+
+    if (ret < 0) {
+        if (ret == -ENOMEM) {
+            DDPRINTF("send queue is full. wait a little....\n");
+            ret = qemu_rdma_block_for_wrid(rdma, RDMA_WRID_RDMA_WRITE_START,
+                                       RDMA_WRID_RDMA_WRITE_STOP);
+            if (ret >= 0) {
+                goto retry;
+            }
+            if (ret < 0) {
+                fprintf(stderr, "rdma migration: failed to make "
+                                "room in full send queue! %d\n", ret);
+                return ret;
+            }
+        }
+        perror("write flush error");
+        return ret;
+    }
+
+    if (ret == 0) {
+        rdma->num_signaled_send++;
+        DDDPRINTF("signaled total: %d\n", rdma->num_signaled_send);
+    }
+
+    rdma->current_length = 0;
+    rdma->current_offset = 0;
+
+    return 0;
+}
+
+static inline int qemu_rdma_buffer_mergable(RDMAContext *rdma,
+                    uint64_t offset, uint64_t len)
+{
+    RDMALocalBlock *block =
+        &(rdma->local_ram_blocks.block[rdma->current_index]);
+    uint8_t *host_addr = block->local_host_addr + (offset - block->offset);
+    uint8_t *chunk_end = ram_chunk_end(block, rdma->current_chunk);
+
+    if (rdma->current_length == 0) {
+        return 0;
+    }
+
+    /*
+     * Only merge into chunk sequentially.
+     */
+    if (offset != (rdma->current_offset + rdma->current_length)) {
+        return 0;
+    }
+
+    if (rdma->current_index < 0) {
+        return 0;
+    }
+
+    if (offset < block->offset) {
+        return 0;
+    }
+
+    if ((offset + len) > (block->offset + block->length)) {
+        return 0;
+    }
+
+    if (rdma->current_chunk < 0) {
+        return 0;
+    }
+
+    if ((host_addr + len) > chunk_end) {
+        return 0;
+    }
+
+    return 1;
+}
+
+/*
+ * We're not actually writing here, but doing three things:
+ *
+ * 1. Identify the chunk the buffer belongs to.
+ * 2. If the chunk is full or the buffer doesn't belong to the current
+ *    chunk, then start a new chunk and flush() the old chunk.
+ * 3. To keep the hardware busy, we also group chunks into batches
+ *    and only require that a batch gets acknowledged in the completion
+ *    qeueue instead of each individual chunk.
+ */
+static int qemu_rdma_write(QEMUFile *f, RDMAContext *rdma,
+                           uint64_t offset, uint64_t len)
+{
+    int index = rdma->current_index;
+    int chunk_index = rdma->current_chunk;
+    int ret;
+
+    /* If we cannot merge it, we flush the current buffer first. */
+    if (!qemu_rdma_buffer_mergable(rdma, offset, len)) {
+        ret = qemu_rdma_write_flush(f, rdma);
+        if (ret) {
+            return ret;
+        }
+        rdma->current_length = 0;
+        rdma->current_offset = offset;
+
+        ret = qemu_rdma_search_ram_block(offset, len,
+                    &rdma->local_ram_blocks, &index, &chunk_index);
+        if (ret) {
+            fprintf(stderr, "ram block search failed\n");
+            return ret;
+        }
+        rdma->current_index = index;
+        rdma->current_chunk = chunk_index;
+    }
+
+    /* merge it */
+    rdma->current_length += len;
+
+    /* flush it if buffer is too large */
+    if (rdma->current_length >= RDMA_MERGE_MAX) {
+        return qemu_rdma_write_flush(f, rdma);
+    }
+
+    return 0;
+}
+
+static void qemu_rdma_cleanup(RDMAContext *rdma)
+{
+    struct rdma_cm_event *cm_event;
+    int ret, idx;
+
+    if (rdma->cm_id) {
+        if (rdma->error_state) {
+            RDMAControlHeader head = { .len = 0,
+                                       .type = RDMA_CONTROL_ERROR,
+                                       .repeat = 1,
+                                     };
+            fprintf(stderr, "Early error. Sending error.\n");
+            qemu_rdma_post_send_control(rdma, NULL, &head);
+        }
+
+        ret = rdma_disconnect(rdma->cm_id);
+        if (!ret) {
+            DDPRINTF("waiting for disconnect\n");
+            ret = rdma_get_cm_event(rdma->channel, &cm_event);
+            if (!ret) {
+                rdma_ack_cm_event(cm_event);
+            }
+        }
+        DDPRINTF("Disconnected.\n");
+        rdma->cm_id = 0;
+    }
+
+    g_free(rdma->block);
+    rdma->block = NULL;
+
+    for (idx = 0; idx < (RDMA_CONTROL_MAX_WR + 1); idx++) {
+        if (rdma->wr_data[idx].control_mr) {
+            qemu_rdma_dereg_control(rdma, idx);
+        }
+        rdma->wr_data[idx].control_mr = NULL;
+    }
+
+    if (rdma->local_ram_blocks.block) {
+        qemu_rdma_dereg_ram_blocks(rdma, &rdma->local_ram_blocks);
+
+        if (!rdma->pin_all) {
+            for (idx = 0; idx < rdma->local_ram_blocks.num_blocks; idx++) {
+                RDMALocalBlock *block = &(rdma->local_ram_blocks.block[idx]);
+                g_free(block->remote_keys);
+                block->remote_keys = NULL;
+            }
+        }
+        g_free(rdma->local_ram_blocks.block);
+        rdma->local_ram_blocks.block = NULL;
+    }
+
+    if (rdma->qp) {
+        ibv_destroy_qp(rdma->qp);
+        rdma->qp = NULL;
+    }
+    if (rdma->cq) {
+        ibv_destroy_cq(rdma->cq);
+        rdma->cq = NULL;
+    }
+    if (rdma->comp_channel) {
+        ibv_destroy_comp_channel(rdma->comp_channel);
+        rdma->comp_channel = NULL;
+    }
+    if (rdma->pd) {
+        ibv_dealloc_pd(rdma->pd);
+        rdma->pd = NULL;
+    }
+    if (rdma->listen_id) {
+        rdma_destroy_id(rdma->listen_id);
+        rdma->listen_id = 0;
+    }
+    if (rdma->cm_id) {
+        rdma_destroy_id(rdma->cm_id);
+        rdma->cm_id = 0;
+    }
+    if (rdma->channel) {
+        rdma_destroy_event_channel(rdma->channel);
+        rdma->channel = NULL;
+    }
+
+    rdma->nb_transit = 0;
+}
+
+
+static int qemu_rdma_source_init(RDMAContext *rdma, Error **errp, bool pin_all)
+{
+    int ret, idx;
+    Error *local_err = NULL, **temp = &local_err;
+
+    /*
+     * Will be validated against destination's actual capabilities
+     * after the connect() completes.
+     */
+    rdma->pin_all = pin_all;
+
+    ret = qemu_rdma_resolve_host(rdma, temp);
+    if (ret) {
+        goto err_rdma_source_init;
+    }
+
+    ret = qemu_rdma_alloc_pd_cq(rdma);
+    if (ret) {
+        ERROR(temp, "rdma migration: error allocating pd and cq! Your mlock()"
+                    " limits may be too low. Please check $ ulimit -a # and "
+                    "search for 'ulimit -l' in the output\n");
+        goto err_rdma_source_init;
+    }
+
+    ret = qemu_rdma_alloc_qp(rdma);
+    if (ret) {
+        ERROR(temp, "rdma migration: error allocating qp!\n");
+        goto err_rdma_source_init;
+    }
+
+    ret = qemu_rdma_init_ram_blocks(&rdma->local_ram_blocks);
+    if (ret) {
+        ERROR(temp, "rdma migration: error initializing ram blocks!\n");
+        goto err_rdma_source_init;
+    }
+
+    for (idx = 0; idx < (RDMA_CONTROL_MAX_WR + 1); idx++) {
+        ret = qemu_rdma_reg_control(rdma, idx);
+        if (ret) {
+            ERROR(temp, "rdma migration: error registering %d control!\n",
+                                                            idx);
+            goto err_rdma_source_init;
+        }
+    }
+
+    rdma->block = (RDMARemoteBlock *) g_malloc0(sizeof(RDMARemoteBlock) *
+                        rdma->local_ram_blocks.num_blocks);
+    return 0;
+
+err_rdma_source_init:
+    error_propagate(errp, local_err);
+    qemu_rdma_cleanup(rdma);
+    return -1;
+}
+
+static int qemu_rdma_connect(RDMAContext *rdma, Error **errp)
+{
+    RDMACapabilities cap = {
+                                .version = RDMA_CONTROL_VERSION_CURRENT,
+                                .flags = 0,
+                           };
+    struct rdma_conn_param conn_param = { .initiator_depth = 2,
+                                          .retry_count = 5,
+                                          .private_data = &cap,
+                                          .private_data_len = sizeof(cap),
+                                        };
+    struct rdma_cm_event *cm_event;
+    int ret;
+
+    /*
+     * Only negotiate the capability with destination if the user
+     * on the source first requested the capability.
+     */
+    if (rdma->pin_all) {
+        DPRINTF("Server pin-all memory requested.\n");
+        cap.flags |= RDMA_CAPABILITY_PIN_ALL;
+    }
+
+    caps_to_network(&cap);
+
+    ret = rdma_connect(rdma->cm_id, &conn_param);
+    if (ret) {
+        perror("rdma_connect");
+        ERROR(errp, "connecting to destination!\n");
+        rdma_destroy_id(rdma->cm_id);
+        rdma->cm_id = 0;
+        goto err_rdma_source_connect;
+    }
+
+    ret = rdma_get_cm_event(rdma->channel, &cm_event);
+    if (ret) {
+        perror("rdma_get_cm_event after rdma_connect");
+        ERROR(errp, "connecting to destination!\n");
+        rdma_ack_cm_event(cm_event);
+        rdma_destroy_id(rdma->cm_id);
+        rdma->cm_id = 0;
+        goto err_rdma_source_connect;
+    }
+
+    if (cm_event->event != RDMA_CM_EVENT_ESTABLISHED) {
+        perror("rdma_get_cm_event != EVENT_ESTABLISHED after rdma_connect");
+        ERROR(errp, "connecting to destination!\n");
+        rdma_ack_cm_event(cm_event);
+        rdma_destroy_id(rdma->cm_id);
+        rdma->cm_id = 0;
+        goto err_rdma_source_connect;
+    }
+
+    memcpy(&cap, cm_event->param.conn.private_data, sizeof(cap));
+    network_to_caps(&cap);
+
+    /*
+     * Verify that the *requested* capabilities are supported by the destination
+     * and disable them otherwise.
+     */
+    if (rdma->pin_all && !(cap.flags & RDMA_CAPABILITY_PIN_ALL)) {
+        ERROR(errp, "Server cannot support pinning all memory. "
+                        "Will register memory dynamically.\n");
+        rdma->pin_all = false;
+    }
+
+    DPRINTF("Pin all memory: %s\n", rdma->pin_all ? "enabled" : "disabled");
+
+    rdma_ack_cm_event(cm_event);
+
+    ret = qemu_rdma_post_recv_control(rdma, 0);
+    if (ret) {
+        ERROR(errp, "posting second control recv!\n");
+        goto err_rdma_source_connect;
+    }
+
+    rdma->control_ready_expected = 1;
+    rdma->num_signaled_send = 0;
+    return 0;
+
+err_rdma_source_connect:
+    qemu_rdma_cleanup(rdma);
+    return -1;
+}
+
+static int qemu_rdma_dest_init(RDMAContext *rdma, Error **errp)
+{
+    int ret = -EINVAL, idx;
+    struct sockaddr_in sin;
+    struct rdma_cm_id *listen_id;
+    char ip[40] = "unknown";
+
+    for (idx = 0; idx < RDMA_CONTROL_MAX_WR; idx++) {
+        rdma->wr_data[idx].control_len = 0;
+        rdma->wr_data[idx].control_curr = NULL;
+    }
+
+    if (rdma->host == NULL) {
+        ERROR(errp, "RDMA host is not set!\n");
+        rdma->error_state = -EINVAL;
+        return -1;
+    }
+    /* create CM channel */
+    rdma->channel = rdma_create_event_channel();
+    if (!rdma->channel) {
+        ERROR(errp, "could not create rdma event channel\n");
+        rdma->error_state = -EINVAL;
+        return -1;
+    }
+
+    /* create CM id */
+    ret = rdma_create_id(rdma->channel, &listen_id, NULL, RDMA_PS_TCP);
+    if (ret) {
+        ERROR(errp, "could not create cm_id!\n");
+        goto err_dest_init_create_listen_id;
+    }
+
+    memset(&sin, 0, sizeof(sin));
+    sin.sin_family = AF_INET;
+    sin.sin_port = htons(rdma->port);
+
+    if (rdma->host && strcmp("", rdma->host)) {
+        struct hostent *dest_addr;
+        dest_addr = gethostbyname(rdma->host);
+        if (!dest_addr) {
+            ERROR(errp, "migration could not gethostbyname!\n");
+            ret = -EINVAL;
+            goto err_dest_init_bind_addr;
+        }
+        memcpy(&sin.sin_addr.s_addr, dest_addr->h_addr,
+                dest_addr->h_length);
+        inet_ntop(AF_INET, dest_addr->h_addr, ip, sizeof ip);
+    } else {
+        sin.sin_addr.s_addr = INADDR_ANY;
+    }
+
+    DPRINTF("%s => %s\n", rdma->host, ip);
+
+    ret = rdma_bind_addr(listen_id, (struct sockaddr *)&sin);
+    if (ret) {
+        ERROR(errp, "Error: could not rdma_bind_addr!\n");
+        goto err_dest_init_bind_addr;
+    }
+
+    rdma->listen_id = listen_id;
+    if (listen_id->verbs) {
+        rdma->verbs = listen_id->verbs;
+    }
+    qemu_rdma_dump_id("dest_init", rdma->verbs);
+    qemu_rdma_dump_gid("dest_init", listen_id);
+    return 0;
+
+err_dest_init_bind_addr:
+    rdma_destroy_id(listen_id);
+err_dest_init_create_listen_id:
+    rdma_destroy_event_channel(rdma->channel);
+    rdma->channel = NULL;
+    rdma->error_state = ret;
+    return ret;
+
+}
+
+static int qemu_rdma_dest_prepare(RDMAContext *rdma, Error **errp)
+{
+    int ret;
+    int idx;
+
+    if (!rdma->verbs) {
+        ERROR(errp, "no verbs context!\n");
+        return 0;
+    }
+
+    ret = qemu_rdma_alloc_pd_cq(rdma);
+    if (ret) {
+        ERROR(errp, "allocating pd and cq!\n");
+        goto err_rdma_dest_prepare;
+    }
+
+    ret = qemu_rdma_init_ram_blocks(&rdma->local_ram_blocks);
+    if (ret) {
+        ERROR(errp, "initializing ram blocks!\n");
+        goto err_rdma_dest_prepare;
+    }
+
+    rdma->block = (RDMARemoteBlock *) g_malloc0(sizeof(RDMARemoteBlock) *
+                        rdma->local_ram_blocks.num_blocks);
+
+    /* Extra one for the send buffer */
+    for (idx = 0; idx < (RDMA_CONTROL_MAX_WR + 1); idx++) {
+        ret = qemu_rdma_reg_control(rdma, idx);
+        if (ret) {
+            ERROR(errp, "registering %d control!\n", idx);
+            goto err_rdma_dest_prepare;
+        }
+    }
+
+    ret = rdma_listen(rdma->listen_id, 5);
+    if (ret) {
+        ERROR(errp, "listening on socket!\n");
+        goto err_rdma_dest_prepare;
+    }
+
+    return 0;
+
+err_rdma_dest_prepare:
+    qemu_rdma_cleanup(rdma);
+    return -1;
+}
+
+static void *qemu_rdma_data_init(const char *host_port, Error **errp)
+{
+    RDMAContext *rdma = NULL;
+    InetSocketAddress *addr;
+
+    if (host_port) {
+        rdma = g_malloc0(sizeof(RDMAContext));
+        memset(rdma, 0, sizeof(RDMAContext));
+        rdma->current_index = -1;
+        rdma->current_chunk = -1;
+
+        addr = inet_parse(host_port, NULL);
+        if (addr != NULL) {
+            rdma->port = atoi(addr->port);
+            rdma->host = g_strdup(addr->host);
+        } else {
+            ERROR(errp, "bad RDMA migration address '%s'", host_port);
+            g_free(rdma);
+            return NULL;
+        }
+    }
+
+    return rdma;
+}
+
+/*
+ * QEMUFile interface to the control channel.
+ * SEND messages for control only.
+ * pc.ram is handled with regular RDMA messages.
+ */
+static int qemu_rdma_put_buffer(void *opaque, const uint8_t *buf,
+                                int64_t pos, int size)
+{
+    QEMUFileRDMA *r = opaque;
+    QEMUFile *f = r->file;
+    RDMAContext *rdma = r->rdma;
+    size_t remaining = size;
+    uint8_t * data = (void *) buf;
+    int ret;
+
+    CHECK_ERROR_STATE();
+
+    /*
+     * Push out any writes that
+     * we're queued up for pc.ram.
+     */
+    ret = qemu_rdma_write_flush(f, rdma);
+    if (ret < 0) {
+        rdma->error_state = ret;
+        return ret;
+    }
+
+    while (remaining) {
+        RDMAControlHeader head;
+
+        r->len = MIN(remaining, RDMA_SEND_INCREMENT);
+        remaining -= r->len;
+
+        head.len = r->len;
+        head.type = RDMA_CONTROL_QEMU_FILE;
+
+        ret = qemu_rdma_exchange_send(rdma, &head, data, NULL, NULL, NULL);
+
+        if (ret < 0) {
+            rdma->error_state = ret;
+            return ret;
+        }
+
+        data += r->len;
+    }
+
+    return size;
+}
+
+static size_t qemu_rdma_fill(RDMAContext *rdma, uint8_t *buf,
+                             int size, int idx)
+{
+    size_t len = 0;
+
+    if (rdma->wr_data[idx].control_len) {
+        DDDPRINTF("RDMA %" PRId64 " of %d bytes already in buffer\n",
+                    rdma->wr_data[idx].control_len, size);
+
+        len = MIN(size, rdma->wr_data[idx].control_len);
+        memcpy(buf, rdma->wr_data[idx].control_curr, len);
+        rdma->wr_data[idx].control_curr += len;
+        rdma->wr_data[idx].control_len -= len;
+    }
+
+    return len;
+}
+
+/*
+ * QEMUFile interface to the control channel.
+ * RDMA links don't use bytestreams, so we have to
+ * return bytes to QEMUFile opportunistically.
+ */
+static int qemu_rdma_get_buffer(void *opaque, uint8_t *buf,
+                                int64_t pos, int size)
+{
+    QEMUFileRDMA *r = opaque;
+    RDMAContext *rdma = r->rdma;
+    RDMAControlHeader head;
+    int ret = 0;
+
+    CHECK_ERROR_STATE();
+
+    /*
+     * First, we hold on to the last SEND message we
+     * were given and dish out the bytes until we run
+     * out of bytes.
+     */
+    r->len = qemu_rdma_fill(r->rdma, buf, size, 0);
+    if (r->len) {
+        return r->len;
+    }
+
+    /*
+     * Once we run out, we block and wait for another
+     * SEND message to arrive.
+     */
+    ret = qemu_rdma_exchange_recv(rdma, &head, RDMA_CONTROL_QEMU_FILE);
+
+    if (ret < 0) {
+        rdma->error_state = ret;
+        return ret;
+    }
+
+    /*
+     * SEND was received with new bytes, now try again.
+     */
+    return qemu_rdma_fill(r->rdma, buf, size, 0);
+}
+
+/*
+ * Block until all the outstanding chunks have been delivered by the hardware.
+ */
+static int qemu_rdma_drain_cq(QEMUFile *f, RDMAContext *rdma)
+{
+    int ret;
+
+    if (qemu_rdma_write_flush(f, rdma) < 0) {
+        return -EIO;
+    }
+
+    while (rdma->num_signaled_send) {
+        ret = qemu_rdma_block_for_wrid(rdma, RDMA_WRID_RDMA_WRITE_START,
+                                       RDMA_WRID_RDMA_WRITE_STOP);
+        if (ret < 0) {
+            fprintf(stderr, "rdma migration: complete polling error!\n");
+            return -EIO;
+        }
+    }
+
+    return 0;
+}
+
+static int qemu_rdma_close(void *opaque)
+{
+    DPRINTF("Shutting down connection.\n");
+    QEMUFileRDMA *r = opaque;
+    if (r->rdma) {
+        qemu_rdma_cleanup(r->rdma);
+        g_free(r->rdma);
+    }
+    g_free(r);
+    return 0;
+}
+
+static size_t qemu_rdma_save_page(QEMUFile *f, void *opaque,
+                                  ram_addr_t block_offset, ram_addr_t offset,
+                                  size_t size, int *bytes_sent)
+{
+    ram_addr_t current_addr = block_offset + offset;
+    QEMUFileRDMA *rfile = opaque;
+    RDMAContext *rdma = rfile->rdma;
+    int ret;
+
+    CHECK_ERROR_STATE();
+
+    qemu_fflush(f);
+
+    /*
+     * Add this page to the current 'chunk'. If the chunk
+     * is full, or the page doen't belong to the current chunk,
+     * an actual RDMA write will occur and a new chunk will be formed.
+     */
+    ret = qemu_rdma_write(f, rdma, current_addr, size);
+    if (ret < 0) {
+        rdma->error_state = ret;
+        fprintf(stderr, "rdma migration: write error! %d\n", ret);
+        return ret;
+    }
+
+    /*
+     * Drain the Completion Queue if possible, but do not block,
+     * just poll.
+     *
+     * If nothing to poll, the end of the iteration will do this
+     * again to make sure we don't overflow the request queue.
+     */
+    while (1) {
+        int ret = qemu_rdma_poll(rdma);
+        if (ret == RDMA_WRID_NONE) {
+            break;
+        }
+        if (ret < 0) {
+            rdma->error_state = ret;
+            fprintf(stderr, "rdma migration: polling error! %d\n", ret);
+            return ret;
+        }
+    }
+
+    /*
+     * We always return 0 bytes because the RDMA
+     * protocol is completely asynchronous. We do not yet know whether an
+     * identified chunk is zero or not because we're waiting for other pages to
+     * potentially be merged with the current chunk.
+     * So, we have to call qemu_update_position() later on when the actual write
+     * occurs.
+     */
+    *bytes_sent = 1;
+    return RAM_SAVE_CONTROL_DELAYED;
+}
+
+static int qemu_rdma_accept(RDMAContext *rdma)
+{
+    RDMACapabilities cap;
+    struct rdma_conn_param conn_param = {
+                                            .responder_resources = 2,
+                                            .private_data = &cap,
+                                            .private_data_len = sizeof(cap),
+                                         };
+    struct rdma_cm_event *cm_event;
+    struct ibv_context *verbs;
+    int ret = -EINVAL;
+
+    ret = rdma_get_cm_event(rdma->channel, &cm_event);
+    if (ret) {
+        goto err_rdma_dest_wait;
+    }
+
+    if (cm_event->event != RDMA_CM_EVENT_CONNECT_REQUEST) {
+        rdma_ack_cm_event(cm_event);
+        goto err_rdma_dest_wait;
+    }
+
+    memcpy(&cap, cm_event->param.conn.private_data, sizeof(cap));
+
+    network_to_caps(&cap);
+
+    if (cap.version < 1 || cap.version > RDMA_CONTROL_VERSION_CURRENT) {
+            fprintf(stderr, "Unknown source RDMA version: %d, bailing...\n",
+                            cap.version);
+            rdma_ack_cm_event(cm_event);
+            goto err_rdma_dest_wait;
+    }
+
+    /*
+     * Respond with only the capabilities this version of QEMU knows about.
+     */
+    cap.flags &= known_capabilities;
+
+    /*
+     * Enable the ones that we do know about.
+     * Add other checks here as new ones are introduced.
+     */
+    if (cap.flags & RDMA_CAPABILITY_PIN_ALL) {
+        rdma->pin_all = true;
+    }
+
+    rdma->cm_id = cm_event->id;
+    verbs = cm_event->id->verbs;
+
+    rdma_ack_cm_event(cm_event);
+
+    DPRINTF("Memory pin all: %s\n", rdma->pin_all ? "enabled" : "disabled");
+
+    caps_to_network(&cap);
+
+    DPRINTF("verbs context after listen: %p\n", verbs);
+
+    if (!rdma->verbs) {
+        rdma->verbs = verbs;
+        /*
+         * Cannot propagate errp, as there is no error pointer
+         * to be propagated.
+         */
+        ret = qemu_rdma_dest_prepare(rdma, NULL);
+        if (ret) {
+            fprintf(stderr, "rdma migration: error preparing dest!\n");
+            goto err_rdma_dest_wait;
+        }
+    } else if (rdma->verbs != verbs) {
+            fprintf(stderr, "ibv context not matching %p, %p!\n",
+                    rdma->verbs, verbs);
+            goto err_rdma_dest_wait;
+    }
+
+    qemu_set_fd_handler2(rdma->channel->fd, NULL, NULL, NULL, NULL);
+
+    ret = qemu_rdma_alloc_qp(rdma);
+    if (ret) {
+        fprintf(stderr, "rdma migration: error allocating qp!\n");
+        goto err_rdma_dest_wait;
+    }
+
+    ret = rdma_accept(rdma->cm_id, &conn_param);
+    if (ret) {
+        fprintf(stderr, "rdma_accept returns %d!\n", ret);
+        goto err_rdma_dest_wait;
+    }
+
+    ret = rdma_get_cm_event(rdma->channel, &cm_event);
+    if (ret) {
+        fprintf(stderr, "rdma_accept get_cm_event failed %d!\n", ret);
+        goto err_rdma_dest_wait;
+    }
+
+    if (cm_event->event != RDMA_CM_EVENT_ESTABLISHED) {
+        fprintf(stderr, "rdma_accept not event established!\n");
+        rdma_ack_cm_event(cm_event);
+        goto err_rdma_dest_wait;
+    }
+
+    rdma_ack_cm_event(cm_event);
+
+    ret = qemu_rdma_post_recv_control(rdma, 0);
+    if (ret) {
+        fprintf(stderr, "rdma migration: error posting second control recv!\n");
+        goto err_rdma_dest_wait;
+    }
+
+    qemu_rdma_dump_gid("dest_connect", rdma->cm_id);
+
+    return 0;
+
+err_rdma_dest_wait:
+    rdma->error_state = ret;
+    qemu_rdma_cleanup(rdma);
+    return ret;
+}
+
+/*
+ * During each iteration of the migration, we listen for instructions
+ * by the primary VM to perform dynamic page registrations before they
+ * can perform RDMA operations.
+ *
+ * We respond with the 'rkey'.
+ *
+ * Keep doing this until the primary tells us to stop.
+ */
+static int qemu_rdma_registration_handle(QEMUFile *f, void *opaque,
+                                         uint64_t flags)
+{
+    RDMAControlHeader resp = { .len = sizeof(RDMARegisterResult),
+                               .type = RDMA_CONTROL_REGISTER_RESULT,
+                               .repeat = 0,
+                             };
+    RDMAControlHeader blocks = { .type = RDMA_CONTROL_RAM_BLOCKS_RESULT, .repeat = 1 };
+    QEMUFileRDMA *rfile = opaque;
+    RDMAContext *rdma = rfile->rdma;
+    RDMALocalBlocks *local = &rdma->local_ram_blocks;
+    RDMAControlHeader head;
+    RDMARegister *reg, *registers;
+    RDMACompress *comp;
+    RDMARegisterResult *reg_result;
+    static RDMARegisterResult results[RDMA_CONTROL_MAX_COMMANDS_PER_MESSAGE];
+    RDMALocalBlock *block;
+    void *host_addr;
+    int ret = 0;
+    int idx = 0;
+    int count = 0;
+    int i = 0;
+
+    CHECK_ERROR_STATE();
+
+    do {
+        DDDPRINTF("Waiting for next registration %" PRIu64 "...\n", flags);
+
+        ret = qemu_rdma_exchange_recv(rdma, &head, RDMA_CONTROL_NONE);
+
+        if (ret < 0) {
+            break;
+        }
+
+        if (head.repeat > RDMA_CONTROL_MAX_COMMANDS_PER_MESSAGE) {
+            fprintf(stderr, "Too many requests in this message (%d)."
+                            "Bailing.\n", head.repeat);
+            ret = -EIO;
+            break;
+        }
+
+        switch (head.type) {
+        case RDMA_CONTROL_COMPRESS:
+            comp = (RDMACompress *) rdma->wr_data[idx].control_curr;
+
+            DDPRINTF("Zapping zero chunk: %" PRId64
+                    " bytes, index %d, offset %" PRId64 "\n",
+                    comp->length, comp->block_idx, comp->offset);
+            comp = (RDMACompress *) rdma->wr_data[idx].control_curr;
+            block = &(rdma->local_ram_blocks.block[comp->block_idx]);
+
+            host_addr = block->local_host_addr +
+                            (comp->offset - block->offset);
+
+            ram_handle_compressed(host_addr, comp->value, comp->length);
+            break;
+
+        case RDMA_CONTROL_REGISTER_FINISHED:
+            DDDPRINTF("Current registrations complete.\n");
+            goto out;
+
+        case RDMA_CONTROL_RAM_BLOCKS_REQUEST:
+            DPRINTF("Initial setup info requested.\n");
+
+            if (rdma->pin_all) {
+                ret = qemu_rdma_reg_whole_ram_blocks(rdma);
+                if (ret) {
+                    fprintf(stderr, "rdma migration: error dest "
+                                    "registering ram blocks!\n");
+                    goto out;
+                }
+            }
+
+            /*
+             * Dest uses this to prepare to transmit the RAMBlock descriptions
+             * to the primary VM after connection setup.
+             * Both sides use the "remote" structure to communicate and update
+             * their "local" descriptions with what was sent.
+             */
+            for (i = 0; i < local->num_blocks; i++) {
+                rdma->block[i].remote_host_addr =
+                    (uint64_t)(local->block[i].local_host_addr);
+
+                if (rdma->pin_all) {
+                    rdma->block[i].remote_rkey = local->block[i].mr->rkey;
+                }
+
+                rdma->block[i].offset = local->block[i].offset;
+                rdma->block[i].length = local->block[i].length;
+            }
+
+            blocks.len = rdma->local_ram_blocks.num_blocks 
+                                                * sizeof(RDMARemoteBlock);
+
+            ret = qemu_rdma_post_send_control(rdma, 
+                                        (uint8_t *) rdma->block, &blocks);
+
+            if (ret < 0) {
+                fprintf(stderr, "rdma migration: error sending remote info!\n");
+                goto out;
+            }
+
+            break;
+        case RDMA_CONTROL_REGISTER_REQUEST:
+            DDPRINTF("There are %d registration requests\n", head.repeat);
+
+            resp.repeat = head.repeat;
+            registers = (RDMARegister *) rdma->wr_data[idx].control_curr;
+
+            for (count = 0; count < head.repeat; count++) {
+                reg = &registers[count];
+                reg_result = &results[count];
+
+                DDPRINTF("Registration request (%d): %d"
+                    " bytes, index %d, offset %" PRIu64 "\n",
+                    count, reg->len, reg->current_index, reg->offset);
+
+                block = &(rdma->local_ram_blocks.block[reg->current_index]);
+                host_addr = (block->local_host_addr +
+                            (reg->offset - block->offset));
+                if (qemu_rdma_register_and_get_keys(rdma, block,
+                            (uint8_t *)host_addr, NULL, &reg_result->rkey)) {
+                    fprintf(stderr, "cannot get rkey!\n");
+                    ret = -EINVAL;
+                    goto out;
+                }
+
+                DDPRINTF("Registered rkey for this request: %x\n",
+                                reg_result->rkey);
+            }
+
+            ret = qemu_rdma_post_send_control(rdma,
+                            (uint8_t *) results, &resp);
+
+            if (ret < 0) {
+                fprintf(stderr, "Failed to send control buffer!\n");
+                goto out;
+            }
+            break;
+        case RDMA_CONTROL_REGISTER_RESULT:
+            fprintf(stderr, "Invalid RESULT message at dest.\n");
+            ret = -EIO;
+            goto out;
+        default:
+            fprintf(stderr, "Unknown control message %s\n",
+                                control_desc[head.type]);
+            ret = -EIO;
+            goto out;
+        }
+    } while (1);
+out:
+    if (ret < 0) {
+        rdma->error_state = ret;
+    }
+    return ret;
+}
+
+static int qemu_rdma_registration_start(QEMUFile *f, void *opaque,
+                                        uint64_t flags)
+{
+    QEMUFileRDMA *rfile = opaque;
+    RDMAContext *rdma = rfile->rdma;
+
+    CHECK_ERROR_STATE();
+
+    DDDPRINTF("start section: %" PRIu64 "\n", flags);
+    qemu_put_be64(f, RAM_SAVE_FLAG_HOOK);
+    qemu_fflush(f);
+
+    return 0;
+}
+
+/*
+ * Inform dest that dynamic registrations are done for now.
+ * First, flush writes, if any.
+ */
+static int qemu_rdma_registration_stop(QEMUFile *f, void *opaque,
+                                       uint64_t flags)
+{
+    Error *local_err = NULL, **errp = &local_err;
+    QEMUFileRDMA *rfile = opaque;
+    RDMAContext *rdma = rfile->rdma;
+    RDMAControlHeader head = { .len = 0, .repeat = 1 };
+    RDMAControlHeader resp = {.type = RDMA_CONTROL_RAM_BLOCKS_RESULT };
+    int reg_result_idx;
+    int ret = 0;
+
+    CHECK_ERROR_STATE();
+
+    qemu_fflush(f);
+    ret = qemu_rdma_drain_cq(f, rdma);
+
+    if (ret < 0) {
+        goto err;
+    }
+
+    if (flags == RAM_CONTROL_SETUP) {
+        head.type = RDMA_CONTROL_RAM_BLOCKS_REQUEST;
+        DPRINTF("Sending registration setup for ram blocks...\n");
+
+        /*
+         * Make sure that we parallelize the pinning on both sides.
+         * For very large guests, doing this serially takes a really
+         * long time, so we have to 'interleave' the pinning locally
+         * with the control messages by performing the pinning on this
+         * side before we receive the control response from the other
+         * side that the pinning has completed.
+         */
+        ret = qemu_rdma_exchange_send(rdma, &head, NULL, &resp, 
+                    &reg_result_idx, rdma->pin_all ?
+                    qemu_rdma_reg_whole_ram_blocks : NULL);
+        if (ret < 0) {
+            ERROR(errp, "receiving remote info!\n");
+            return ret;
+        }
+
+        qemu_rdma_move_header(rdma, reg_result_idx, &resp);
+        memcpy(rdma->block, rdma->wr_data[reg_result_idx].control_curr, resp.len);
+
+        ret = qemu_rdma_process_remote_blocks(rdma,
+                        (resp.len / sizeof(RDMARemoteBlock)), errp);
+        if (ret) {
+            ERROR(errp, "processing remote blocks!\n");
+            return ret;
+        }
+
+        if (!rdma->pin_all) {
+            int x = 0;
+            for (x = 0; x < rdma->local_ram_blocks.num_blocks; x++) {
+                RDMALocalBlock *block = &(rdma->local_ram_blocks.block[x]);
+                int num_chunks = ram_chunk_count(block);
+                block->remote_keys = g_malloc0(num_chunks * sizeof(uint32_t));
+            }
+        }
+    }
+
+    DDDPRINTF("Sending registration finish %" PRIu64 "...\n", flags);
+
+    head.type = RDMA_CONTROL_REGISTER_FINISHED;
+    ret = qemu_rdma_exchange_send(rdma, &head, NULL, NULL, NULL, NULL);
+
+    if (ret < 0) {
+        goto err;
+    }
+
+    return 0;
+err:
+    rdma->error_state = ret;
+    return ret;
+}
+
+static int qemu_rdma_get_fd(void *opaque)
+{
+    QEMUFileRDMA *rfile = opaque;
+    RDMAContext *rdma = rfile->rdma;
+
+    return rdma->comp_channel->fd;
+}
+
+const QEMUFileOps rdma_read_ops = {
+    .get_buffer    = qemu_rdma_get_buffer,
+    .get_fd        = qemu_rdma_get_fd,
+    .close         = qemu_rdma_close,
+    .hook_ram_load = qemu_rdma_registration_handle,
+};
+
+const QEMUFileOps rdma_write_ops = {
+    .put_buffer           = qemu_rdma_put_buffer,
+    .close                = qemu_rdma_close,
+    .before_ram_iterate   = qemu_rdma_registration_start,
+    .after_ram_iterate    = qemu_rdma_registration_stop,
+    .save_page            = qemu_rdma_save_page,
+};
+
+static void *qemu_fopen_rdma(RDMAContext *rdma, const char *mode)
+{
+    QEMUFileRDMA *r = g_malloc0(sizeof(QEMUFileRDMA));
+
+    if (qemu_file_mode_is_not_valid(mode)) {
+        return NULL;
+    }
+
+    r->rdma = rdma;
+
+    if (mode[0] == 'w') {
+        r->file = qemu_fopen_ops(r, &rdma_write_ops);
+    } else {
+        r->file = qemu_fopen_ops(r, &rdma_read_ops);
+    }
+
+    return r->file;
+}
+
+static void rdma_accept_incoming_migration(void *opaque)
+{
+    RDMAContext *rdma = opaque;
+    int ret;
+    QEMUFile *f;
+    Error *local_err = NULL, **errp = &local_err;
+
+    DPRINTF("Accepting rdma connection...\n");
+    ret = qemu_rdma_accept(rdma);
+
+    if (ret) {
+        ERROR(errp, "RDMA Migration initialization failed!\n");
+        return;
+    }
+
+    DPRINTF("Accepted migration\n");
+
+    f = qemu_fopen_rdma(rdma, "rb");
+    if (f == NULL) {
+        ERROR(errp, "could not qemu_fopen_rdma!\n");
+        qemu_rdma_cleanup(rdma);
+        return;
+    }
+
+    rdma->migration_started_on_destination = 1;
+    process_incoming_migration(f);
+}
+
+void rdma_start_incoming_migration(const char *host_port, Error **errp)
+{
+    int ret;
+    RDMAContext *rdma;
+    Error *local_err = NULL;
+
+    DPRINTF("Starting RDMA-based incoming migration\n");
+    rdma = qemu_rdma_data_init(host_port, &local_err);
+
+    if (rdma == NULL) {
+        goto err;
+    }
+
+    ret = qemu_rdma_dest_init(rdma, &local_err);
+
+    if (ret) {
+        goto err;
+    }
+
+    DPRINTF("qemu_rdma_dest_init success\n");
+    ret = qemu_rdma_dest_prepare(rdma, &local_err);
+
+    if (ret) {
+        goto err;
+    }
+
+    DPRINTF("qemu_rdma_dest_prepare success\n");
+
+    qemu_set_fd_handler2(rdma->channel->fd, NULL,
+                         rdma_accept_incoming_migration, NULL,
+                            (void *)(intptr_t) rdma);
+    return;
+err:
+    error_propagate(errp, local_err);
+    g_free(rdma);
+}
+
+void rdma_start_outgoing_migration(void *opaque,
+                            const char *host_port, Error **errp)
+{
+    MigrationState *s = opaque;
+    Error *local_err = NULL, **temp = &local_err;
+    RDMAContext *rdma = qemu_rdma_data_init(host_port, &local_err);
+    int ret = 0;
+
+    if (rdma == NULL) {
+        ERROR(temp, "Failed to initialize RDMA data structures! %d\n", ret);
+        goto err;
+    }
+
+    ret = qemu_rdma_source_init(rdma, &local_err,
+        s->enabled_capabilities[MIGRATION_CAPABILITY_X_RDMA_PIN_ALL]);
+
+    if (ret) {
+        goto err;
+    }
+
+    DPRINTF("qemu_rdma_source_init success\n");
+    ret = qemu_rdma_connect(rdma, &local_err);
+
+    if (ret) {
+        goto err;
+    }
+
+    DPRINTF("qemu_rdma_source_connect success\n");
+
+    s->file = qemu_fopen_rdma(rdma, "wb");
+    migrate_fd_connect(s);
+    return;
+err:
+    error_propagate(errp, local_err);
+    g_free(rdma);
+    migrate_fd_error(s);
+}
diff --git a/migration.c b/migration.c
index a704d48..62c6b85 100644
--- a/migration.c
+++ b/migration.c
@@ -78,6 +78,10 @@ void qemu_start_incoming_migration(const char *uri, Error **errp)
 
     if (strstart(uri, "tcp:", &p))
         tcp_start_incoming_migration(p, errp);
+#ifdef CONFIG_RDMA
+    else if (strstart(uri, "x-rdma:", &p))
+        rdma_start_incoming_migration(p, errp);
+#endif
 #if !defined(WIN32)
     else if (strstart(uri, "exec:", &p))
         exec_start_incoming_migration(p, errp);
@@ -407,6 +411,10 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
 
     if (strstart(uri, "tcp:", &p)) {
         tcp_start_outgoing_migration(s, p, &local_err);
+#ifdef CONFIG_RDMA
+    } else if (strstart(uri, "x-rdma:", &p)) {
+        rdma_start_outgoing_migration(s, p, &local_err);
+#endif
 #if !defined(WIN32)
     } else if (strstart(uri, "exec:", &p)) {
         exec_start_outgoing_migration(s, p, &local_err);
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 11/15] rdma: core logic

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> Code that does need to be visible is kept
> well contained inside this file and this is the only
> new additional file to the entire patch.
>
> This file includes the entire protocol and interfaces
> required to perform RDMA migration.
>
> Also, the configure and Makefile modifications to link
> this file are included.
>
> Full documentation is in docs/rdma.txt
>
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com> 

The review part is for the everything except migration-rdma.c.  I am
starting looking at that bits,  but they are really complex and my
knowledge of RDMA is nil (notice that there can be relation between the
two concepts).

Re: [Qemu-devel] [PATCH v11 11/15] rdma: core logic

[Michael R. Hines]

On 06/25/2013 08:05 AM, Juan Quintela wrote:
> mrhines@linux.vnet.ibm.com wrote:
>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>
>> Code that does need to be visible is kept
>> well contained inside this file and this is the only
>> new additional file to the entire patch.
>>
>> This file includes the entire protocol and interfaces
>> required to perform RDMA migration.
>>
>> Also, the configure and Makefile modifications to link
>> this file are included.
>>
>> Full documentation is in docs/rdma.txt
>>
>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>> Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
>> Tested-by: Chegu Vinod <chegu_vinod@hp.com>
>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
> Reviewed-by: Juan Quintela <quintela@redhat.com>
>
> The review part is for the everything except migration-rdma.c.  I am
> starting looking at that bits,  but they are really complex and my
> knowledge of RDMA is nil (notice that there can be relation between the
> two concepts).
>
>
>
Acknowledged.

Re: [Qemu-devel] [PATCH v11 11/15] rdma: core logic

[Vasilis Liaskovitis]

Hi,

On Mon, Jun 24, 2013 at 09:58:01PM -0400, mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
[...]
> +/*
> + * Put in the log file which RDMA device was opened and the details
> + * associated with that device.
> + */
> +static void qemu_rdma_dump_id(const char *who, struct ibv_context *verbs)
> +{
> +    printf("%s RDMA Device opened: kernel name %s "
> +           "uverbs device name %s, "
> +           "infiniband_verbs class device path %s,"
> +           " infiniband class device path %s\n",
> +                who,
> +                verbs->device->name,
> +                verbs->device->dev_name,
> +                verbs->device->dev_path,
> +                verbs->device->ibdev_path);
> +}

see below

> +static int qemu_rdma_dest_init(RDMAContext *rdma, Error **errp)
> +{
> +    int ret = -EINVAL, idx;
> +    struct sockaddr_in sin;
> +    struct rdma_cm_id *listen_id;
> +    char ip[40] = "unknown";
> +
> +    for (idx = 0; idx < RDMA_CONTROL_MAX_WR; idx++) {
> +        rdma->wr_data[idx].control_len = 0;
> +        rdma->wr_data[idx].control_curr = NULL;
> +    }
> +
> +    if (rdma->host == NULL) {
> +        ERROR(errp, "RDMA host is not set!\n");
> +        rdma->error_state = -EINVAL;
> +        return -1;
> +    }
> +    /* create CM channel */
> +    rdma->channel = rdma_create_event_channel();
> +    if (!rdma->channel) {
> +        ERROR(errp, "could not create rdma event channel\n");
> +        rdma->error_state = -EINVAL;
> +        return -1;
> +    }
> +
> +    /* create CM id */
> +    ret = rdma_create_id(rdma->channel, &listen_id, NULL, RDMA_PS_TCP);
> +    if (ret) {
> +        ERROR(errp, "could not create cm_id!\n");
> +        goto err_dest_init_create_listen_id;
> +    }
> +
> +    memset(&sin, 0, sizeof(sin));
> +    sin.sin_family = AF_INET;
> +    sin.sin_port = htons(rdma->port);
> +
> +    if (rdma->host && strcmp("", rdma->host)) {
> +        struct hostent *dest_addr;
> +        dest_addr = gethostbyname(rdma->host);
> +        if (!dest_addr) {
> +            ERROR(errp, "migration could not gethostbyname!\n");
> +            ret = -EINVAL;
> +            goto err_dest_init_bind_addr;
> +        }
> +        memcpy(&sin.sin_addr.s_addr, dest_addr->h_addr,
> +                dest_addr->h_length);
> +        inet_ntop(AF_INET, dest_addr->h_addr, ip, sizeof ip);
> +    } else {
> +        sin.sin_addr.s_addr = INADDR_ANY;
> +    }
> +
> +    DPRINTF("%s => %s\n", rdma->host, ip);
> +
> +    ret = rdma_bind_addr(listen_id, (struct sockaddr *)&sin);
> +    if (ret) {
> +        ERROR(errp, "Error: could not rdma_bind_addr!\n");
> +        goto err_dest_init_bind_addr;
> +    }
> +
> +    rdma->listen_id = listen_id;
> +    if (listen_id->verbs) {
> +        rdma->verbs = listen_id->verbs;
> +    }
> +    qemu_rdma_dump_id("dest_init", rdma->verbs);


I wonder if you have ever hit the case where rdma_bind_addr() does not set the
verbs structure in listen_id because we are binding to the loopback device (also
see linux kernel commit 8523c048).
I keep hitting this case on my destination VM ("incoming x-rdma:host:port)

Then I think qemu_rdma_dump_id can segfault trying to dereference a null verbs
structure. The dump_id function should check for non-NULL verbs argument,
or the dump should be made only in the (verbs != NULL) if clause.

Disabling the dump_id above, I have rdma_resolve_addr() problems on the source
VM side (getting RDMA_CM_EVENT_ADDR_ERROR instead of
RDMA_CM_EVENT_ADDR_RESOLVED).

I assume that is because of the null verbs structure destination problem above.
qemu_rdma_dest_prepare() will always fail with a NULL verbs argument:

> +
> +static int qemu_rdma_dest_prepare(RDMAContext *rdma, Error **errp)
> +{
> +    int ret;
> +    int idx;
> +
> +    if (!rdma->verbs) {
> +        ERROR(errp, "no verbs context!\n");
> +        return 0;
> +    }

It is first called from rdma_start_incoming_migration() and will fail with the
loopback binding case (rdma->verbs == NULL).

however later qemu_rdma_accept() will check against the incoming cm_event
verbs structure and set the RDMAContext's verb struct, calling
qemu_rdma_dest_prepare with that struct:

[...]
> +static int qemu_rdma_accept(RDMAContext *rdma)
[...]
> +    if (!rdma->verbs) {
> +        rdma->verbs = verbs;
> +        /*
> +         * Cannot propagate errp, as there is no error pointer
> +         * to be propagated.
> +         */
> +        ret = qemu_rdma_dest_prepare(rdma, NULL);
> +        if (ret) {
> +            fprintf(stderr, "rdma migration: error preparing dest!\n");
> +            goto err_rdma_dest_wait;
> +        }

Are these two cases intentionally different?

thanks,

- Vasilis

Re: [Qemu-devel] [PATCH v11 11/15] rdma: core logic

[Paolo Bonzini]

Il 25/06/2013 18:31, Vasilis Liaskovitis ha scritto:
> Then I think qemu_rdma_dump_id can segfault trying to dereference a null verbs
> structure. The dump_id function should check for non-NULL verbs argument,
> or the dump should be made only in the (verbs != NULL) if clause.
> 
> Disabling the dump_id above, I have rdma_resolve_addr() problems on the source
> VM side (getting RDMA_CM_EVENT_ADDR_ERROR instead of
> RDMA_CM_EVENT_ADDR_RESOLVED).
> 
> I assume that is because of the null verbs structure destination problem above.
> qemu_rdma_dest_prepare() will always fail with a NULL verbs argument:

FWIW, I don't think this should block merging this patch.  We will
always find one more bug after merging 2500 lines of code.

Paolo

Re: [Qemu-devel] [PATCH v11 11/15] rdma: core logic

[Michael R. Hines]

On 06/25/2013 12:31 PM, Vasilis Liaskovitis wrote:
> Hi,
>
> On Mon, Jun 24, 2013 at 09:58:01PM -0400, mrhines@linux.vnet.ibm.com wrote:
>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>
> [...]
>> +/*
>> + * Put in the log file which RDMA device was opened and the details
>> + * associated with that device.
>> + */
>> +static void qemu_rdma_dump_id(const char *who, struct ibv_context *verbs)
>> +{
>> +    printf("%s RDMA Device opened: kernel name %s "
>> +           "uverbs device name %s, "
>> +           "infiniband_verbs class device path %s,"
>> +           " infiniband class device path %s\n",
>> +                who,
>> +                verbs->device->name,
>> +                verbs->device->dev_name,
>> +                verbs->device->dev_path,
>> +                verbs->device->ibdev_path);
>> +}
> see below
>
>> +static int qemu_rdma_dest_init(RDMAContext *rdma, Error **errp)
>> +{
>> +    int ret = -EINVAL, idx;
>> +    struct sockaddr_in sin;
>> +    struct rdma_cm_id *listen_id;
>> +    char ip[40] = "unknown";
>> +
>> +    for (idx = 0; idx < RDMA_CONTROL_MAX_WR; idx++) {
>> +        rdma->wr_data[idx].control_len = 0;
>> +        rdma->wr_data[idx].control_curr = NULL;
>> +    }
>> +
>> +    if (rdma->host == NULL) {
>> +        ERROR(errp, "RDMA host is not set!\n");
>> +        rdma->error_state = -EINVAL;
>> +        return -1;
>> +    }
>> +    /* create CM channel */
>> +    rdma->channel = rdma_create_event_channel();
>> +    if (!rdma->channel) {
>> +        ERROR(errp, "could not create rdma event channel\n");
>> +        rdma->error_state = -EINVAL;
>> +        return -1;
>> +    }
>> +
>> +    /* create CM id */
>> +    ret = rdma_create_id(rdma->channel, &listen_id, NULL, RDMA_PS_TCP);
>> +    if (ret) {
>> +        ERROR(errp, "could not create cm_id!\n");
>> +        goto err_dest_init_create_listen_id;
>> +    }
>> +
>> +    memset(&sin, 0, sizeof(sin));
>> +    sin.sin_family = AF_INET;
>> +    sin.sin_port = htons(rdma->port);
>> +
>> +    if (rdma->host && strcmp("", rdma->host)) {
>> +        struct hostent *dest_addr;
>> +        dest_addr = gethostbyname(rdma->host);
>> +        if (!dest_addr) {
>> +            ERROR(errp, "migration could not gethostbyname!\n");
>> +            ret = -EINVAL;
>> +            goto err_dest_init_bind_addr;
>> +        }
>> +        memcpy(&sin.sin_addr.s_addr, dest_addr->h_addr,
>> +                dest_addr->h_length);
>> +        inet_ntop(AF_INET, dest_addr->h_addr, ip, sizeof ip);
>> +    } else {
>> +        sin.sin_addr.s_addr = INADDR_ANY;
>> +    }
>> +
>> +    DPRINTF("%s => %s\n", rdma->host, ip);
>> +
>> +    ret = rdma_bind_addr(listen_id, (struct sockaddr *)&sin);
>> +    if (ret) {
>> +        ERROR(errp, "Error: could not rdma_bind_addr!\n");
>> +        goto err_dest_init_bind_addr;
>> +    }
>> +
>> +    rdma->listen_id = listen_id;
>> +    if (listen_id->verbs) {
>> +        rdma->verbs = listen_id->verbs;
>> +    }
>> +    qemu_rdma_dump_id("dest_init", rdma->verbs);
>
> I wonder if you have ever hit the case where rdma_bind_addr() does not set the
> verbs structure in listen_id because we are binding to the loopback device (also
> see linux kernel commit 8523c048).
> I keep hitting this case on my destination VM ("incoming x-rdma:host:port)
>
> Then I think qemu_rdma_dump_id can segfault trying to dereference a null verbs
> structure. The dump_id function should check for non-NULL verbs argument,
> or the dump should be made only in the (verbs != NULL) if clause.
>
> Disabling the dump_id above, I have rdma_resolve_addr() problems on the source
> VM side (getting RDMA_CM_EVENT_ADDR_ERROR instead of
> RDMA_CM_EVENT_ADDR_RESOLVED).
>
> I assume that is because of the null verbs structure destination problem above.
> qemu_rdma_dest_prepare() will always fail with a NULL verbs argument:

Good catch, thank you. I'll fix this immediately in the next version.

I never tried binding to the localhost before......

>> +
>> +static int qemu_rdma_dest_prepare(RDMAContext *rdma, Error **errp)
>> +{
>> +    int ret;
>> +    int idx;
>> +
>> +    if (!rdma->verbs) {
>> +        ERROR(errp, "no verbs context!\n");
>> +        return 0;
>> +    }
> It is first called from rdma_start_incoming_migration() and will fail with the
> loopback binding case (rdma->verbs == NULL).
>
> however later qemu_rdma_accept() will check against the incoming cm_event
> verbs structure and set the RDMAContext's verb struct, calling
> qemu_rdma_dest_prepare with that struct:
>
> [...]
>> +static int qemu_rdma_accept(RDMAContext *rdma)
> [...]
>> +    if (!rdma->verbs) {
>> +        rdma->verbs = verbs;
>> +        /*
>> +         * Cannot propagate errp, as there is no error pointer
>> +         * to be propagated.
>> +         */
>> +        ret = qemu_rdma_dest_prepare(rdma, NULL);
>> +        if (ret) {
>> +            fprintf(stderr, "rdma migration: error preparing dest!\n");
>> +            goto err_rdma_dest_wait;
>> +        }
> Are these two cases intentionally different?

Another good catch. We should definitely allow loopback RDMA without any 
issues.

I will fix this immediately as well in the next version.

- Michael

[Qemu-devel] [PATCH v11 12/15] rdma: send pc.ram

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

This takes advantages of the previous patches:

1. use the new QEMUFileOps hook 'save_page'

2. call out to the right accessor methods to invoke
   the iteration hooks defined in QEMUFileOps

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Chegu Vinod <chegu_vinod@hp.com>
Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 arch_init.c |   33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch_init.c b/arch_init.c
index 00bc3a9..5ea32db 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -115,6 +115,7 @@ const uint32_t arch_type = QEMU_ARCH;
 #define RAM_SAVE_FLAG_EOS      0x10
 #define RAM_SAVE_FLAG_CONTINUE 0x20
 #define RAM_SAVE_FLAG_XBZRLE   0x40
+/* 0x80 is reserved in migration.h start with 0x100 next */
 
 
 static struct defconfig_file {
@@ -447,6 +448,7 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
                 ram_bulk_stage = false;
             }
         } else {
+            int ret;
             uint8_t *p;
             int cont = (block == last_sent_block) ?
                 RAM_SAVE_FLAG_CONTINUE : 0;
@@ -455,7 +457,18 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
 
             /* In doubt sent page as normal */
             bytes_sent = -1;
-            if (is_zero_page(p)) {
+            ret = ram_control_save_page(f, block->offset,
+                               offset, TARGET_PAGE_SIZE, &bytes_sent);
+
+            if (ret != RAM_SAVE_CONTROL_NOT_SUPP) {
+                if (ret != RAM_SAVE_CONTROL_DELAYED) {
+                    if (bytes_sent > 0) {
+                        acct_info.norm_pages++;
+                    } else if (bytes_sent == 0) {
+                        acct_info.dup_pages++;
+                    }
+                }
+            } else if (is_zero_page(p)) {
                 acct_info.dup_pages++;
                 if (!ram_bulk_stage) {
                     bytes_sent = save_block_hdr(f, block, offset, cont,
@@ -610,6 +623,10 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
     }
 
     qemu_mutex_unlock_ramlist();
+
+    ram_control_before_iterate(f, RAM_CONTROL_SETUP);
+    ram_control_after_iterate(f, RAM_CONTROL_SETUP);
+
     qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
 
     return 0;
@@ -628,6 +645,8 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
         reset_ram_globals();
     }
 
+    ram_control_before_iterate(f, RAM_CONTROL_ROUND);
+
     t0 = qemu_get_clock_ns(rt_clock);
     i = 0;
     while ((ret = qemu_file_rate_limit(f)) == 0) {
@@ -658,6 +677,12 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
 
     qemu_mutex_unlock_ramlist();
 
+    /*
+     * Must occur before EOS (or any QEMUFile operation)
+     * because of RDMA protocol.
+     */
+    ram_control_after_iterate(f, RAM_CONTROL_ROUND);
+
     if (ret < 0) {
         bytes_transferred += total_sent;
         return ret;
@@ -675,6 +700,8 @@ static int ram_save_complete(QEMUFile *f, void *opaque)
     qemu_mutex_lock_ramlist();
     migration_bitmap_sync();
 
+    ram_control_before_iterate(f, RAM_CONTROL_FINISH);
+
     /* try transferring iterative blocks of memory */
 
     /* flush all remaining blocks regardless of rate limiting */
@@ -688,6 +715,8 @@ static int ram_save_complete(QEMUFile *f, void *opaque)
         }
         bytes_transferred += bytes_sent;
     }
+
+    ram_control_after_iterate(f, RAM_CONTROL_FINISH);
     migration_end();
 
     qemu_mutex_unlock_ramlist();
@@ -884,6 +913,8 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
                 ret = -EINVAL;
                 goto done;
             }
+        } else if (flags & RAM_SAVE_FLAG_HOOK) {
+            ram_control_load_hook(f, flags);
         }
         error = qemu_file_get_error(f);
         if (error) {
-- 
1.7.10.4

[Qemu-devel] [PATCH v11 13/15] rdma: allow state transitions between other states besides ACTIVE

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

This patch is in preparation for the next ones: Until now the MIG_STATE_SETUP
state was not really a 'formal' state. It has been used as a 'zero' state
and QEMU has been unconditionally transitioning into this state when
the QMP migrate command was called. In preparation for timing this state,
we have to make this state a a 'real' state which actually gets transitioned
from later in the migration_thread() from SETUP => ACTIVE, rather than just
automatically dropping into this state at the beginninig of the migration.

This means that the state transition function (migration_finish_set_state())
needs to be capable of transitioning from valid states _other_ than just
MIG_STATE_ACTIVE.

The function is in fact already capable of doing that, but was not allowing the
old state to be a parameter specified as an input.

This patch fixes that and only makes the transition if the current state
matches the old state that the caller intended to transition from.

Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 migration.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/migration.c b/migration.c
index 62c6b85..dcb99c9 100644
--- a/migration.c
+++ b/migration.c
@@ -295,9 +295,9 @@ static void migrate_fd_cleanup(void *opaque)
     notifier_list_notify(&migration_state_notifiers, s);
 }
 
-static void migrate_finish_set_state(MigrationState *s, int new_state)
+static void migrate_set_state(MigrationState *s, int old_state, int new_state)
 {
-    if (__sync_val_compare_and_swap(&s->state, MIG_STATE_ACTIVE,
+    if (__sync_val_compare_and_swap(&s->state, old_state,
                                     new_state) == new_state) {
         trace_migrate_set_state(new_state);
     }
@@ -316,7 +316,7 @@ static void migrate_fd_cancel(MigrationState *s)
 {
     DPRINTF("cancelling migration\n");
 
-    migrate_finish_set_state(s, MIG_STATE_CANCELLED);
+    migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
 }
 
 void add_migration_state_change_notifier(Notifier *notify)
@@ -546,14 +546,14 @@ static void *migration_thread(void *opaque)
                 qemu_savevm_state_complete(s->file);
                 qemu_mutex_unlock_iothread();
                 if (!qemu_file_get_error(s->file)) {
-                    migrate_finish_set_state(s, MIG_STATE_COMPLETED);
+                    migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_COMPLETED);
                     break;
                 }
             }
         }
 
         if (qemu_file_get_error(s->file)) {
-            migrate_finish_set_state(s, MIG_STATE_ERROR);
+            migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_ERROR);
             break;
         }
         current_time = qemu_get_clock_ms(rt_clock);
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 13/15] rdma: allow state transitions between other states besides ACTIVE

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> This patch is in preparation for the next ones: Until now the MIG_STATE_SETUP
> state was not really a 'formal' state. It has been used as a 'zero' state
> and QEMU has been unconditionally transitioning into this state when
> the QMP migrate command was called. In preparation for timing this state,
> we have to make this state a a 'real' state which actually gets transitioned
> from later in the migration_thread() from SETUP => ACTIVE, rather than just
> automatically dropping into this state at the beginninig of the migration.
>
> This means that the state transition function (migration_finish_set_state())
> needs to be capable of transitioning from valid states _other_ than just
> MIG_STATE_ACTIVE.
>
> The function is in fact already capable of doing that, but was not allowing the
> old state to be a parameter specified as an input.
>
> This patch fixes that and only makes the transition if the current state
> matches the old state that the caller intended to transition from.
>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

[Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

As described in the previous patch, until now, the MIG_STATE_SETUP
state was not really a 'formal' state. It has been used as a 'zero' state
(what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
into this state when the QMP migration command was called. Instead we want to
introduce MIG_STATE_NONE, which is our starting state in the state machine, and
then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
command is issued.

In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
later in the migration_thread(). This is done to be able to timestamp the amount of
time spent in the SETUP state for proper accounting to the user during
an RDMA migration.

Furthermore, the management software, until now, has never been aware of the
existence of the SETUP state whatsoever. This must change, because, timing of this
state implies that the state actually exists.

These two patches cannot be separated because the 'query_migrate' QMP
switch statement needs to know how to handle this new state transition.

Tested-by: Michael R. Hines <mrhines@us.ibm.com>
Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 migration.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/migration.c b/migration.c
index dcb99c9..758d99d 100644
--- a/migration.c
+++ b/migration.c
@@ -36,7 +36,8 @@
 #endif
 
 enum {
-    MIG_STATE_ERROR,
+    MIG_STATE_ERROR = -1,
+    MIG_STATE_NONE,
     MIG_STATE_SETUP,
     MIG_STATE_CANCELLED,
     MIG_STATE_ACTIVE,
@@ -63,7 +64,7 @@ static NotifierList migration_state_notifiers =
 MigrationState *migrate_get_current(void)
 {
     static MigrationState current_migration = {
-        .state = MIG_STATE_SETUP,
+        .state = MIG_STATE_NONE,
         .bandwidth_limit = MAX_THROTTLE,
         .xbzrle_cache_size = DEFAULT_MIGRATE_CACHE_SIZE,
         .mbps = -1,
@@ -184,9 +185,13 @@ MigrationInfo *qmp_query_migrate(Error **errp)
     MigrationState *s = migrate_get_current();
 
     switch (s->state) {
-    case MIG_STATE_SETUP:
+    case MIG_STATE_NONE:
         /* no migration has happened ever */
         break;
+    case MIG_STATE_SETUP:
+        info->has_status = true;
+        info->status = g_strdup("setup");
+        break;
     case MIG_STATE_ACTIVE:
         info->has_status = true;
         info->status = g_strdup("active");
@@ -257,7 +262,7 @@ void qmp_migrate_set_capabilities(MigrationCapabilityStatusList *params,
     MigrationState *s = migrate_get_current();
     MigrationCapabilityStatusList *cap;
 
-    if (s->state == MIG_STATE_ACTIVE) {
+    if (s->state == MIG_STATE_ACTIVE || s->state == MIG_STATE_SETUP) {
         error_set(errp, QERR_MIGRATION_ACTIVE);
         return;
     }
@@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s)
 {
     DPRINTF("cancelling migration\n");
 
+    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED);
     migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
 }
 
@@ -393,7 +399,7 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
     params.blk = blk;
     params.shared = inc;
 
-    if (s->state == MIG_STATE_ACTIVE) {
+    if (s->state == MIG_STATE_ACTIVE || s->state == MIG_STATE_SETUP) {
         error_set(errp, QERR_MIGRATION_ACTIVE);
         return;
     }
@@ -525,6 +531,8 @@ static void *migration_thread(void *opaque)
     DPRINTF("beginning savevm\n");
     qemu_savevm_state_begin(s->file, &s->params);
 
+    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_ACTIVE);
+
     while (s->state == MIG_STATE_ACTIVE) {
         int64_t current_time;
         uint64_t pending_size;
@@ -604,8 +612,8 @@ static void *migration_thread(void *opaque)
 
 void migrate_fd_connect(MigrationState *s)
 {
-    s->state = MIG_STATE_ACTIVE;
-    trace_migrate_set_state(MIG_STATE_ACTIVE);
+    s->state = MIG_STATE_SETUP;
+    trace_migrate_set_state(MIG_STATE_SETUP);
 
     /* This is a best 1st approximation. ns to ms */
     s->expected_downtime = max_downtime/1000000;
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> As described in the previous patch, until now, the MIG_STATE_SETUP
> state was not really a 'formal' state. It has been used as a 'zero' state
> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
> into this state when the QMP migration command was called. Instead we want to
> introduce MIG_STATE_NONE, which is our starting state in the state machine, and
> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
> command is issued.
>
> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
> later in the migration_thread(). This is done to be able to timestamp the amount of
> time spent in the SETUP state for proper accounting to the user during
> an RDMA migration.
>
> Furthermore, the management software, until now, has never been aware of the
> existence of the SETUP state whatsoever. This must change, because, timing of this
> state implies that the state actually exists.
>
> These two patches cannot be separated because the 'query_migrate' QMP
> switch statement needs to know how to handle this new state transition.
>
> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

> @@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s)
>  {
>      DPRINTF("cancelling migration\n");
>  
> +    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED);
>      migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
>  }

This chunk is wrong.

we can call qme_migrate_cancel() at any point,  and it is going to be
called normally from MIG_STATE_ACTIVE.


    migrate_set_satet(s, s->state,  MIG_STATE_CANCELLED)

should do the trick.  Or something like that,  what do you think?

Later,  Juan.

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Paolo Bonzini]

Il 25/06/2013 11:49, Juan Quintela ha scritto:
> mrhines@linux.vnet.ibm.com wrote:
>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>
>> As described in the previous patch, until now, the MIG_STATE_SETUP
>> state was not really a 'formal' state. It has been used as a 'zero' state
>> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
>> into this state when the QMP migration command was called. Instead we want to
>> introduce MIG_STATE_NONE, which is our starting state in the state machine, and
>> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
>> command is issued.
>>
>> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
>> later in the migration_thread(). This is done to be able to timestamp the amount of
>> time spent in the SETUP state for proper accounting to the user during
>> an RDMA migration.
>>
>> Furthermore, the management software, until now, has never been aware of the
>> existence of the SETUP state whatsoever. This must change, because, timing of this
>> state implies that the state actually exists.
>>
>> These two patches cannot be separated because the 'query_migrate' QMP
>> switch statement needs to know how to handle this new state transition.
>>
>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
> 
>> @@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s)
>>  {
>>      DPRINTF("cancelling migration\n");
>>  
>> +    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED);
>>      migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
>>  }
> 
> This chunk is wrong.
> 
> we can call qme_migrate_cancel() at any point,  and it is going to be
> called normally from MIG_STATE_ACTIVE.
> 
>     migrate_set_satet(s, s->state,  MIG_STATE_CANCELLED)
> 
> should do the trick.  Or something like that,  what do you think?

I don't like the three-arguments migrate_set_state, but I don't have any
better idea.

With Juan's modification, it is fine (but not reviewed-by me :)).  While
you resend, the first 13 patches of v10 can be merged (pull request).
You can then rebase the last three on top.

Michael, did you look at the "debugging/getting the protocol ready" mode
where all pages are unpinned?

Paolo

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/25/2013 06:13 AM, Paolo Bonzini wrote:
> Il 25/06/2013 11:49, Juan Quintela ha scritto:
>> mrhines@linux.vnet.ibm.com wrote:
>>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>>
>>> As described in the previous patch, until now, the MIG_STATE_SETUP
>>> state was not really a 'formal' state. It has been used as a 'zero' state
>>> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
>>> into this state when the QMP migration command was called. Instead we want to
>>> introduce MIG_STATE_NONE, which is our starting state in the state machine, and
>>> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
>>> command is issued.
>>>
>>> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
>>> later in the migration_thread(). This is done to be able to timestamp the amount of
>>> time spent in the SETUP state for proper accounting to the user during
>>> an RDMA migration.
>>>
>>> Furthermore, the management software, until now, has never been aware of the
>>> existence of the SETUP state whatsoever. This must change, because, timing of this
>>> state implies that the state actually exists.
>>>
>>> These two patches cannot be separated because the 'query_migrate' QMP
>>> switch statement needs to know how to handle this new state transition.
>>>
>>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
>>> @@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s)
>>>   {
>>>       DPRINTF("cancelling migration\n");
>>>   
>>> +    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED);
>>>       migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
>>>   }
>> This chunk is wrong.
>>
>> we can call qme_migrate_cancel() at any point,  and it is going to be
>> called normally from MIG_STATE_ACTIVE.
>>
>>      migrate_set_satet(s, s->state,  MIG_STATE_CANCELLED)
>>
>> should do the trick.  Or something like that,  what do you think?
> I don't like the three-arguments migrate_set_state, but I don't have any
> better idea.
>
> With Juan's modification, it is fine (but not reviewed-by me :)).  While
> you resend, the first 13 patches of v10 can be merged (pull request).
> You can then rebase the last three on top.

So, I should send a v11 before Juan applies and generates the pull request?

Did I understand correctly?

> Michael, did you look at the "debugging/getting the protocol ready" mode
> where all pages are unpinned?
>
> Paolo
>


We did not come up with a design on how such a mode would be
exposed to the user. Implementing this in migration-rdma.c is
just a few lines of code, but without a clear use case in this patch
series, I've not chosen expose it to the user yet without some kind
of agreement with you guys.

Recommendations?

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Paolo Bonzini]

Il 25/06/2013 15:44, Michael R. Hines ha scritto:
>>>
>> I don't like the three-arguments migrate_set_state, but I don't have any
>> better idea.
>>
>> With Juan's modification, it is fine (but not reviewed-by me :)).  While
>> you resend, the first 13 patches of v10 can be merged (pull request).
>> You can then rebase the last three on top.
> 
> So, I should send a v11 before Juan applies and generates the pull request?
> 
> Did I understand correctly?

Juan found another small nit, so please do send a v12.  He liked (with
the small change in cancellation) your last three patches, so there is
no need to split out patch 13 (as you had it in v10).

>> Michael, did you look at the "debugging/getting the protocol ready" mode
>> where all pages are unpinned?
> 
> We did not come up with a design on how such a mode would be
> exposed to the user. Implementing this in migration-rdma.c is
> just a few lines of code, but without a clear use case in this patch
> series, I've not chosen expose it to the user yet without some kind
> of agreement with you guys.

Do those few lines of code change the protocol?  If yes, I'll go against
all my previous recommendations and suggest a #define.  If no, it is
fine to leave it for later, but I would still suggest posting the patch
on the list just for information.

Paolo

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/25/2013 09:53 AM, Paolo Bonzini wrote:
> Il 25/06/2013 15:44, Michael R. Hines ha scritto:
>>> I don't like the three-arguments migrate_set_state, but I don't have any
>>> better idea.
>>>
>>> With Juan's modification, it is fine (but not reviewed-by me :)).  While
>>> you resend, the first 13 patches of v10 can be merged (pull request).
>>> You can then rebase the last three on top.
>> So, I should send a v11 before Juan applies and generates the pull request?
>>
>> Did I understand correctly?
> Juan found another small nit, so please do send a v12.  He liked (with
> the small change in cancellation) your last three patches, so there is
> no need to split out patch 13 (as you had it in v10).

Acknowledged.

>>> Michael, did you look at the "debugging/getting the protocol ready" mode
>>> where all pages are unpinned?
>> We did not come up with a design on how such a mode would be
>> exposed to the user. Implementing this in migration-rdma.c is
>> just a few lines of code, but without a clear use case in this patch
>> series, I've not chosen expose it to the user yet without some kind
>> of agreement with you guys.
> Do those few lines of code change the protocol?  If yes, I'll go against
> all my previous recommendations and suggest a #define.  If no, it is
> fine to leave it for later, but I would still suggest posting the patch
> on the list just for information.
>
> Paolo
>

Ok, you got it - no it does not change the protocol.
I'll use a #define and send it out with a new version for review.

- Michael

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Paolo Bonzini]

Il 25/06/2013 16:54, Michael R. Hines ha scritto:
>>>
>> Do those few lines of code change the protocol?  If yes, I'll go against
>> all my previous recommendations and suggest a #define.  If no, it is
>> fine to leave it for later, but I would still suggest posting the patch
>> on the list just for information.
> 
> Ok, you got it - no it does not change the protocol.
> I'll use a #define and send it out with a new version for review.

Make sure you send an additional patch on top of these 15.

Paolo

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/25/2013 10:55 AM, Paolo Bonzini wrote:
> Il 25/06/2013 16:54, Michael R. Hines ha scritto:
>>> Do those few lines of code change the protocol?  If yes, I'll go against
>>> all my previous recommendations and suggest a #define.  If no, it is
>>> fine to leave it for later, but I would still suggest posting the patch
>>> on the list just for information.
>> Ok, you got it - no it does not change the protocol.
>> I'll use a #define and send it out with a new version for review.
> Make sure you send an additional patch on top of these 15.
>
> Paolo
>
Understood.

- Michael

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/25/2013 10:55 AM, Paolo Bonzini wrote:
> Il 25/06/2013 16:54, Michael R. Hines ha scritto:
>>> Do those few lines of code change the protocol?  If yes, I'll go against
>>> all my previous recommendations and suggest a #define.  If no, it is
>>> fine to leave it for later, but I would still suggest posting the patch
>>> on the list just for information.
>> Ok, you got it - no it does not change the protocol.
>> I'll use a #define and send it out with a new version for review.
> Make sure you send an additional patch on top of these 15.
>
> Paolo
>
I was wrong - this does require a protocol extension.

This is because the RDMA transfers are asynchronous, and thus
we cannot know in advance that it is safe to unregister the memory
associated with each individual transfer before the transfer actually
completes.

While the destination currently uses the protocol to participate in
*registering* the page, the destination does not participate in the
RDMA transfers themselves, only the source does, and thus would
require a new exchange of messages to block and instruct the
destination to unpin the memory.

- Michael

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Paolo Bonzini]

Il 25/06/2013 22:56, Michael R. Hines ha scritto:
>>
> I was wrong - this does require a protocol extension.
> 
> This is because the RDMA transfers are asynchronous, and thus
> we cannot know in advance that it is safe to unregister the memory
> associated with each individual transfer before the transfer actually
> completes.
> 
> While the destination currently uses the protocol to participate in
> *registering* the page, the destination does not participate in the
> RDMA transfers themselves, only the source does, and thus would
> require a new exchange of messages to block and instruct the
> destination to unpin the memory.

Yes, that's what I recalled too (really what mst told me :)).  Does it
need to be blocking though?  As long as the pinning is blocking, and
messages are processed in order, the source can proceed immediately
after sending an unpin message.  This assumes of course that the chunk
is not being transmitted, and I am not sure how easy the source can
determine that.

Paolo

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/25/2013 05:06 PM, Paolo Bonzini wrote:
> Il 25/06/2013 22:56, Michael R. Hines ha scritto:
>> I was wrong - this does require a protocol extension.
>>
>> This is because the RDMA transfers are asynchronous, and thus
>> we cannot know in advance that it is safe to unregister the memory
>> associated with each individual transfer before the transfer actually
>> completes.
>>
>> While the destination currently uses the protocol to participate in
>> *registering* the page, the destination does not participate in the
>> RDMA transfers themselves, only the source does, and thus would
>> require a new exchange of messages to block and instruct the
>> destination to unpin the memory.
> Yes, that's what I recalled too (really what mst told me :)).  Does it
> need to be blocking though?  As long as the pinning is blocking, and
> messages are processed in order, the source can proceed immediately
> after sending an unpin message.  This assumes of course that the chunk
> is not being transmitted, and I am not sure how easy the source can
> determine that.
>
> Paolo
>

No, they're not processed in order. In fact, not only does the device
write out of order, but also the PCI bus writes out of order.
This was such a problem in fact, that I fixed several bugs as a result
a few weeks ago (v7 of the patch with an in-depth description).

The destination simply cannot assume whatsoever what the ordering
of the writes are - that's really the whole point of using RDMA in the
first place so that the software can get out of the way of the transfer 
process
to lower the latency of each transfer.

The only option is to send a blocking message to the other side to
request the unpinning (in addition to unpinning on the source first upon
completion of the original transfer).

As you can expect, this would be very expensive and we must ensure
that we have *very* good a-priori information that this memory will
not need to be re-registered anytime in the near future.

- Michael

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Paolo Bonzini]

Il 26/06/2013 02:31, Michael R. Hines ha scritto:
> On 06/25/2013 05:06 PM, Paolo Bonzini wrote:
>> Il 25/06/2013 22:56, Michael R. Hines ha scritto:
>>> I was wrong - this does require a protocol extension.
>>>
>>> This is because the RDMA transfers are asynchronous, and thus
>>> we cannot know in advance that it is safe to unregister the memory
>>> associated with each individual transfer before the transfer actually
>>> completes.
>>>
>>> While the destination currently uses the protocol to participate in
>>> *registering* the page, the destination does not participate in the
>>> RDMA transfers themselves, only the source does, and thus would
>>> require a new exchange of messages to block and instruct the
>>> destination to unpin the memory.
>> Yes, that's what I recalled too (really what mst told me :)).  Does it
>> need to be blocking though?  As long as the pinning is blocking, and
>> messages are processed in order, the source can proceed immediately
>> after sending an unpin message.  This assumes of course that the chunk
>> is not being transmitted, and I am not sure how easy the source can
>> determine that.
> 
> No, they're not processed in order. In fact, not only does the device
> write out of order, but also the PCI bus writes out of order.
> This was such a problem in fact, that I fixed several bugs as a result
> a few weeks ago (v7 of the patch with an in-depth description).
> 
> The destination simply cannot assume whatsoever what the ordering
> of the writes are - that's really the whole point of using RDMA in the
> first place so that the software can get out of the way of the transfer
> process to lower the latency of each transfer.

The memory is processed out of order, but what about the messages?
Those must be in order.

Note that I wrote above "This assumes of course that the chunk is not
being transmitted".  Can the source know when an asynchronous transfer
finished, and delay the unpinning until that time?

Paolo

> 
> The only option is to send a blocking message to the other side to
> request the unpinning (in addition to unpinning on the source first upon
> completion of the original transfer).
> 
> As you can expect, this would be very expensive and we must ensure
> that we have *very* good a-priori information that this memory will
> not need to be re-registered anytime in the near future.
> 
> - Michael
> 
> 
> 

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/26/2013 02:37 AM, Paolo Bonzini wrote:
> Il 26/06/2013 02:31, Michael R. Hines ha scritto:
>> On 06/25/2013 05:06 PM, Paolo Bonzini wrote:
>>> Il 25/06/2013 22:56, Michael R. Hines ha scritto:
>>>> I was wrong - this does require a protocol extension.
>>>>
>>>> This is because the RDMA transfers are asynchronous, and thus
>>>> we cannot know in advance that it is safe to unregister the memory
>>>> associated with each individual transfer before the transfer actually
>>>> completes.
>>>>
>>>> While the destination currently uses the protocol to participate in
>>>> *registering* the page, the destination does not participate in the
>>>> RDMA transfers themselves, only the source does, and thus would
>>>> require a new exchange of messages to block and instruct the
>>>> destination to unpin the memory.
>>> Yes, that's what I recalled too (really what mst told me :)).  Does it
>>> need to be blocking though?  As long as the pinning is blocking, and
>>> messages are processed in order, the source can proceed immediately
>>> after sending an unpin message.  This assumes of course that the chunk
>>> is not being transmitted, and I am not sure how easy the source can
>>> determine that.
>> No, they're not processed in order. In fact, not only does the device
>> write out of order, but also the PCI bus writes out of order.
>> This was such a problem in fact, that I fixed several bugs as a result
>> a few weeks ago (v7 of the patch with an in-depth description).
>>
>> The destination simply cannot assume whatsoever what the ordering
>> of the writes are - that's really the whole point of using RDMA in the
>> first place so that the software can get out of the way of the transfer
>> process to lower the latency of each transfer.
> The memory is processed out of order, but what about the messages?
> Those must be in order.
>
> Note that I wrote above "This assumes of course that the chunk is not
> being transmitted".  Can the source know when an asynchronous transfer
> finished, and delay the unpinning until that time?
>
> Paolo

Yes, the source does know. There's no problem unpinning on the source.

But both sides must do the unpinning, not just the source.

Did I misunderstand you? Are you suggesting *only* unpinning on the source?

- Michael

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Paolo Bonzini]

Il 26/06/2013 14:37, Michael R. Hines ha scritto:
> On 06/26/2013 02:37 AM, Paolo Bonzini wrote:
>> Il 26/06/2013 02:31, Michael R. Hines ha scritto:
>>> On 06/25/2013 05:06 PM, Paolo Bonzini wrote:
>>>> Il 25/06/2013 22:56, Michael R. Hines ha scritto:
>>>>> I was wrong - this does require a protocol extension.
>>>>>
>>>>> This is because the RDMA transfers are asynchronous, and thus
>>>>> we cannot know in advance that it is safe to unregister the memory
>>>>> associated with each individual transfer before the transfer actually
>>>>> completes.
>>>>>
>>>>> While the destination currently uses the protocol to participate in
>>>>> *registering* the page, the destination does not participate in the
>>>>> RDMA transfers themselves, only the source does, and thus would
>>>>> require a new exchange of messages to block and instruct the
>>>>> destination to unpin the memory.
>>>> Yes, that's what I recalled too (really what mst told me :)).  Does it
>>>> need to be blocking though?  As long as the pinning is blocking, and
>>>> messages are processed in order, the source can proceed immediately
>>>> after sending an unpin message.  This assumes of course that the chunk
>>>> is not being transmitted, and I am not sure how easy the source can
>>>> determine that.
>>> No, they're not processed in order. In fact, not only does the device
>>> write out of order, but also the PCI bus writes out of order.
>>> This was such a problem in fact, that I fixed several bugs as a result
>>> a few weeks ago (v7 of the patch with an in-depth description).
>>>
>>> The destination simply cannot assume whatsoever what the ordering
>>> of the writes are - that's really the whole point of using RDMA in the
>>> first place so that the software can get out of the way of the transfer
>>> process to lower the latency of each transfer.
>> The memory is processed out of order, but what about the messages?
>> Those must be in order.
>>
>> Note that I wrote above "This assumes of course that the chunk is not
>> being transmitted".  Can the source know when an asynchronous transfer
>> finished, and delay the unpinning until that time?
> 
> Yes, the source does know. There's no problem unpinning on the source.
> 
> But both sides must do the unpinning, not just the source.
> 
> Did I misunderstand you? Are you suggesting *only* unpinning on the source?

I'm suggesting (if possible) that the source only tells the destination
to unpin once it knows it is safe for the destination to do it.  As long
as unpin and pin messages are not reordered, it should be possible to do
it with an asynchronous message from the source to the destination.

Paolo

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

[-- Attachment #1: Type: text/plain, Size: 3796 bytes --]

On 06/26/2013 08:39 AM, Paolo Bonzini wrote:
> Il 26/06/2013 14:37, Michael R. Hines ha scritto:
>> On 06/26/2013 02:37 AM, Paolo Bonzini wrote:
>>> Il 26/06/2013 02:31, Michael R. Hines ha scritto:
>>>> On 06/25/2013 05:06 PM, Paolo Bonzini wrote:
>>>>> Il 25/06/2013 22:56, Michael R. Hines ha scritto:
>>>>>> I was wrong - this does require a protocol extension.
>>>>>>
>>>>>> This is because the RDMA transfers are asynchronous, and thus
>>>>>> we cannot know in advance that it is safe to unregister the memory
>>>>>> associated with each individual transfer before the transfer actually
>>>>>> completes.
>>>>>>
>>>>>> While the destination currently uses the protocol to participate in
>>>>>> *registering* the page, the destination does not participate in the
>>>>>> RDMA transfers themselves, only the source does, and thus would
>>>>>> require a new exchange of messages to block and instruct the
>>>>>> destination to unpin the memory.
>>>>> Yes, that's what I recalled too (really what mst told me :)).  Does it
>>>>> need to be blocking though?  As long as the pinning is blocking, and
>>>>> messages are processed in order, the source can proceed immediately
>>>>> after sending an unpin message.  This assumes of course that the chunk
>>>>> is not being transmitted, and I am not sure how easy the source can
>>>>> determine that.
>>>> No, they're not processed in order. In fact, not only does the device
>>>> write out of order, but also the PCI bus writes out of order.
>>>> This was such a problem in fact, that I fixed several bugs as a result
>>>> a few weeks ago (v7 of the patch with an in-depth description).
>>>>
>>>> The destination simply cannot assume whatsoever what the ordering
>>>> of the writes are - that's really the whole point of using RDMA in the
>>>> first place so that the software can get out of the way of the transfer
>>>> process to lower the latency of each transfer.
>>> The memory is processed out of order, but what about the messages?
>>> Those must be in order.
>>>
>>> Note that I wrote above "This assumes of course that the chunk is not
>>> being transmitted".  Can the source know when an asynchronous transfer
>>> finished, and delay the unpinning until that time?
>> Yes, the source does know. There's no problem unpinning on the source.
>>
>> But both sides must do the unpinning, not just the source.
>>
>> Did I misunderstand you? Are you suggesting *only* unpinning on the source?
> I'm suggesting (if possible) that the source only tells the destination
> to unpin once it knows it is safe for the destination to do it.  As long
> as unpin and pin messages are not reordered, it should be possible to do
> it with an asynchronous message from the source to the destination.
>
> Paolo
>

Oh, certainly. I agree. That's not a trivial patch, though (as we were
originally shooting for).

(I'll list the steps below on the QEMU wiki, for the record).

*This requires some steps:*
1. First, maintain a new data structure: something like
     "These memory ranges are 'being unpinned'" - block all potential writes
     to these addresses until the unpinning completes.
2. Once the source unpin completes, send the asynchronous control 
channel message
     to the other side for unpinning.
2. Mark the data structure and return and allow the migration to continue
     with the next RDMA write.
3. Upon completion of the unpinning on the destination,
     respond to the source that it was finished.
4. Source then clears the data structure for the successfully unpinned 
memory ranges.
5. At this point, one or more writes may (or may not) be blocking on the
     unpinned memory areas and will poll the data structure and find that
     the unpinning has completed.
6. Then issue the new writes and proceed as normal.
7. Repeat step 1.


[-- Attachment #2: Type: text/html, Size: 4718 bytes --]

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Paolo Bonzini]

Il 26/06/2013 16:09, Michael R. Hines ha scritto:
> *This requires some steps:*
> 1. First, maintain a new data structure: something like
>     "These memory ranges are 'being unpinned'" - block all potential writes
>     to these addresses until the unpinning completes.
> 2. Once the source unpin completes, send the asynchronous control
> channel message
>     to the other side for unpinning.
> 2. Mark the data structure and return and allow the migration to continue
>     with the next RDMA write.
> 3. Upon completion of the unpinning on the destination,
>     respond to the source that it was finished.
> 4. Source then clears the data structure for the successfully unpinned
> memory ranges.
> 5. At this point, one or more writes may (or may not) be blocking on the
>     unpinned memory areas and will poll the data structure and find that
>     the unpinning has completed.
> 6. Then issue the new writes and proceed as normal.
> 7. Repeat step 1.

After more discussion on IRC I think I understand this.  It's not
trivial, but not super-complex either...  it would really be nice to add
it to the protocol already in 1.6.

Paolo

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/26/2013 10:57 AM, Paolo Bonzini wrote:
> Il 26/06/2013 16:09, Michael R. Hines ha scritto:
>> *This requires some steps:*
>> 1. First, maintain a new data structure: something like
>>      "These memory ranges are 'being unpinned'" - block all potential writes
>>      to these addresses until the unpinning completes.
>> 2. Once the source unpin completes, send the asynchronous control
>> channel message
>>      to the other side for unpinning.
>> 2. Mark the data structure and return and allow the migration to continue
>>      with the next RDMA write.
>> 3. Upon completion of the unpinning on the destination,
>>      respond to the source that it was finished.
>> 4. Source then clears the data structure for the successfully unpinned
>> memory ranges.
>> 5. At this point, one or more writes may (or may not) be blocking on the
>>      unpinned memory areas and will poll the data structure and find that
>>      the unpinning has completed.
>> 6. Then issue the new writes and proceed as normal.
>> 7. Repeat step 1.
> After more discussion on IRC I think I understand this.  It's not
> trivial, but not super-complex either...  it would really be nice to add
> it to the protocol already in 1.6.
>
> Paolo
>

I will submit this as a brand new patch series. I'm working on it right now.

- Michael

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Juan Quintela]

"Michael R. Hines" <mrhines@linux.vnet.ibm.com> wrote:
> On 06/25/2013 06:13 AM, Paolo Bonzini wrote:
>> Il 25/06/2013 11:49, Juan Quintela ha scritto:
>>> mrhines@linux.vnet.ibm.com wrote:
>>>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>>>
>>>> As described in the previous patch, until now, the MIG_STATE_SETUP
>>>> state was not really a 'formal' state. It has been used as a 'zero' state
>>>> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
>>>> into this state when the QMP migration command was called. Instead we want to
>>>> introduce MIG_STATE_NONE, which is our starting state in the state machine, and
>>>> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
>>>> command is issued.
>>>>
>>>> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
>>>> later in the migration_thread(). This is done to be able to timestamp the amount of
>>>> time spent in the SETUP state for proper accounting to the user during
>>>> an RDMA migration.
>>>>
>>>> Furthermore, the management software, until now, has never been aware of the
>>>> existence of the SETUP state whatsoever. This must change, because, timing of this
>>>> state implies that the state actually exists.
>>>>
>>>> These two patches cannot be separated because the 'query_migrate' QMP
>>>> switch statement needs to know how to handle this new state transition.
>>>>
>>>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>>>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
>>>> @@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s)
>>>>   {
>>>>       DPRINTF("cancelling migration\n");
>>>>   +    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED);
>>>>       migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
>>>>   }
>>> This chunk is wrong.
>>>
>>> we can call qme_migrate_cancel() at any point,  and it is going to be
>>> called normally from MIG_STATE_ACTIVE.
>>>
>>>      migrate_set_satet(s, s->state,  MIG_STATE_CANCELLED)
>>>
>>> should do the trick.  Or something like that,  what do you think?
>> I don't like the three-arguments migrate_set_state, but I don't have any
>> better idea.
>>
>> With Juan's modification, it is fine (but not reviewed-by me :)).  While
>> you resend, the first 13 patches of v10 can be merged (pull request).
>> You can then rebase the last three on top.
>
> So, I should send a v11 before Juan applies and generates the pull request?
>
> Did I understand correctly?
>
>> Michael, did you look at the "debugging/getting the protocol ready" mode
>> where all pages are unpinned?
>>
>> Paolo
>>
>
>
> We did not come up with a design on how such a mode would be
> exposed to the user. Implementing this in migration-rdma.c is
> just a few lines of code, but without a clear use case in this patch
> series, I've not chosen expose it to the user yet without some kind
> of agreement with you guys.
>
> Recommendations?

Dunno.  I have tried to use the thing:

I am using -incoming x-rdma:deus:4444

(qemu) char device redirected to /dev/pts/2 (label serial0)
librdmacm: Warning: couldn't read ABI version.
librdmacm: Warning: assuming: 4
librdmacm: Fatal: unable to get RDMA device list
RDMA ERROR: could not create rdma event channel
-incoming x-rdma:deus:4444: RDMA ERROR: could not create rdma event channel


I also used "0" instead of deus (the machine name).

The only thing that I did appart from intsalling librdmacm-devel was:


# cat /etc/udev/rules.d/80-infinibad.rules
KERNEL="rdma_cm", NAME="infiniband/%k", MODE="0666"

As per README.  Something else I need to do to use the tcp
implementations?

Later,  Juan.

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/25/2013 10:17 AM, Juan Quintela wrote:
> "Michael R. Hines" <mrhines@linux.vnet.ibm.com> wrote:
>> On 06/25/2013 06:13 AM, Paolo Bonzini wrote:
>>> Il 25/06/2013 11:49, Juan Quintela ha scritto:
>>>> mrhines@linux.vnet.ibm.com wrote:
>>>>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>>>>
>>>>> As described in the previous patch, until now, the MIG_STATE_SETUP
>>>>> state was not really a 'formal' state. It has been used as a 'zero' state
>>>>> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
>>>>> into this state when the QMP migration command was called. Instead we want to
>>>>> introduce MIG_STATE_NONE, which is our starting state in the state machine, and
>>>>> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
>>>>> command is issued.
>>>>>
>>>>> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
>>>>> later in the migration_thread(). This is done to be able to timestamp the amount of
>>>>> time spent in the SETUP state for proper accounting to the user during
>>>>> an RDMA migration.
>>>>>
>>>>> Furthermore, the management software, until now, has never been aware of the
>>>>> existence of the SETUP state whatsoever. This must change, because, timing of this
>>>>> state implies that the state actually exists.
>>>>>
>>>>> These two patches cannot be separated because the 'query_migrate' QMP
>>>>> switch statement needs to know how to handle this new state transition.
>>>>>
>>>>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>>>>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
>>>>> @@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s)
>>>>>    {
>>>>>        DPRINTF("cancelling migration\n");
>>>>>    +    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED);
>>>>>        migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
>>>>>    }
>>>> This chunk is wrong.
>>>>
>>>> we can call qme_migrate_cancel() at any point,  and it is going to be
>>>> called normally from MIG_STATE_ACTIVE.
>>>>
>>>>       migrate_set_satet(s, s->state,  MIG_STATE_CANCELLED)
>>>>
>>>> should do the trick.  Or something like that,  what do you think?
>>> I don't like the three-arguments migrate_set_state, but I don't have any
>>> better idea.
>>>
>>> With Juan's modification, it is fine (but not reviewed-by me :)).  While
>>> you resend, the first 13 patches of v10 can be merged (pull request).
>>> You can then rebase the last three on top.
>> So, I should send a v11 before Juan applies and generates the pull request?
>>
>> Did I understand correctly?
>>
>>> Michael, did you look at the "debugging/getting the protocol ready" mode
>>> where all pages are unpinned?
>>>
>>> Paolo
>>>
>>
>> We did not come up with a design on how such a mode would be
>> exposed to the user. Implementing this in migration-rdma.c is
>> just a few lines of code, but without a clear use case in this patch
>> series, I've not chosen expose it to the user yet without some kind
>> of agreement with you guys.
>>
>> Recommendations?
> Dunno.  I have tried to use the thing:
>
> I am using -incoming x-rdma:deus:4444
>
> (qemu) char device redirected to /dev/pts/2 (label serial0)
> librdmacm: Warning: couldn't read ABI version.
> librdmacm: Warning: assuming: 4
> librdmacm: Fatal: unable to get RDMA device list
> RDMA ERROR: could not create rdma event channel
> -incoming x-rdma:deus:4444: RDMA ERROR: could not create rdma event channel
>

This means that your RDMA environment / IB configuration
(outside of QEMU) is not configured properly. There are several
"sanity checks" you can do to make sure it is working:

Run:

$ ibv_devices     <= You should see a list of configured IB devices
$ ibv_devinfo     <= You should see "PORT_ACTIVE" in the output 
somewhere for each IB device
$ ifconfig ib0     <= if using standard infiniband
$ ifconfig eth0   <= if using RDMA over Converged ethernet

Furthermore, there are several latency/throughput utilities that
come along with the OpenFabrics software stack you can run
to make sure your two hosts are communicating with each other:

There's these commands:

$ ucmatose  [args...]
$ ibv_rc_pingpong [args ..]
$ rdma_server/rdma_client [args...]


> I also used "0" instead of deus (the machine name).
>
> The only thing that I did appart from intsalling librdmacm-devel was:
>
>
> # cat /etc/udev/rules.d/80-infinibad.rules
> KERNEL="rdma_cm", NAME="infiniband/%k", MODE="0666"
>
> As per README.  Something else I need to do to use the tcp
> implementations?
>
> Later,  Juan.
>
>
>
>
>

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/25/2013 10:17 AM, Juan Quintela wrote:
> "Michael R. Hines" <mrhines@linux.vnet.ibm.com> wrote:
>> On 06/25/2013 06:13 AM, Paolo Bonzini wrote:
>>> Il 25/06/2013 11:49, Juan Quintela ha scritto:
>>>> mrhines@linux.vnet.ibm.com wrote:
>>>>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>>>>
>>>>> As described in the previous patch, until now, the MIG_STATE_SETUP
>>>>> state was not really a 'formal' state. It has been used as a 'zero' state
>>>>> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
>>>>> into this state when the QMP migration command was called. Instead we want to
>>>>> introduce MIG_STATE_NONE, which is our starting state in the state machine, and
>>>>> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
>>>>> command is issued.
>>>>>
>>>>> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
>>>>> later in the migration_thread(). This is done to be able to timestamp the amount of
>>>>> time spent in the SETUP state for proper accounting to the user during
>>>>> an RDMA migration.
>>>>>
>>>>> Furthermore, the management software, until now, has never been aware of the
>>>>> existence of the SETUP state whatsoever. This must change, because, timing of this
>>>>> state implies that the state actually exists.
>>>>>
>>>>> These two patches cannot be separated because the 'query_migrate' QMP
>>>>> switch statement needs to know how to handle this new state transition.
>>>>>
>>>>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>>>>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
>>>>> @@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s)
>>>>>    {
>>>>>        DPRINTF("cancelling migration\n");
>>>>>    +    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED);
>>>>>        migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
>>>>>    }
>>>> This chunk is wrong.
>>>>
>>>> we can call qme_migrate_cancel() at any point,  and it is going to be
>>>> called normally from MIG_STATE_ACTIVE.
>>>>
>>>>       migrate_set_satet(s, s->state,  MIG_STATE_CANCELLED)
>>>>
>>>> should do the trick.  Or something like that,  what do you think?
>>> I don't like the three-arguments migrate_set_state, but I don't have any
>>> better idea.
>>>
>>> With Juan's modification, it is fine (but not reviewed-by me :)).  While
>>> you resend, the first 13 patches of v10 can be merged (pull request).
>>> You can then rebase the last three on top.
>> So, I should send a v11 before Juan applies and generates the pull request?
>>
>> Did I understand correctly?
>>
>>> Michael, did you look at the "debugging/getting the protocol ready" mode
>>> where all pages are unpinned?
>>>
>>> Paolo
>>>
>>
>> We did not come up with a design on how such a mode would be
>> exposed to the user. Implementing this in migration-rdma.c is
>> just a few lines of code, but without a clear use case in this patch
>> series, I've not chosen expose it to the user yet without some kind
>> of agreement with you guys.
>>
>> Recommendations?
> Dunno.  I have tried to use the thing:
>
> I am using -incoming x-rdma:deus:4444
>
> (qemu) char device redirected to /dev/pts/2 (label serial0)
> librdmacm: Warning: couldn't read ABI version.
> librdmacm: Warning: assuming: 4
> librdmacm: Fatal: unable to get RDMA device list
> RDMA ERROR: could not create rdma event channel
> -incoming x-rdma:deus:4444: RDMA ERROR: could not create rdma event channel
>
>
> I also used "0" instead of deus (the machine name).
>
> The only thing that I did appart from intsalling librdmacm-devel was:
>
>
> # cat /etc/udev/rules.d/80-infinibad.rules
> KERNEL="rdma_cm", NAME="infiniband/%k", MODE="0666"
>
> As per README.  Something else I need to do to use the tcp
> implementations?
>
> Later,  Juan.
>
>

There's a simple bug found by Visilis affecting localhost migration 
which I believe also
affects using '0' as a hostname in the migration.....

Both of these should be fixed in my next version. Will send out today.
(I never tried migrating with 0.0.0.0 until now).

- Michael


>
>

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition

[Michael R. Hines]

On 06/25/2013 05:49 AM, Juan Quintela wrote:
> mrhines@linux.vnet.ibm.com wrote:
>> From: "Michael R. Hines" <mrhines@us.ibm.com>
>>
>> As described in the previous patch, until now, the MIG_STATE_SETUP
>> state was not really a 'formal' state. It has been used as a 'zero' state
>> (what we're calling 'NONE' here) and QEMU has been unconditionally transitioning
>> into this state when the QMP migration command was called. Instead we want to
>> introduce MIG_STATE_NONE, which is our starting state in the state machine, and
>> then immediately transition into the MIG_STATE_SETUP state when the QMP migrate
>> command is issued.
>>
>> In order to do this, we must delay the transition into MIG_STATE_ACTIVE until
>> later in the migration_thread(). This is done to be able to timestamp the amount of
>> time spent in the SETUP state for proper accounting to the user during
>> an RDMA migration.
>>
>> Furthermore, the management software, until now, has never been aware of the
>> existence of the SETUP state whatsoever. This must change, because, timing of this
>> state implies that the state actually exists.
>>
>> These two patches cannot be separated because the 'query_migrate' QMP
>> switch statement needs to know how to handle this new state transition.
>>
>> Tested-by: Michael R. Hines <mrhines@us.ibm.com>
>> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
>> @@ -316,6 +321,7 @@ static void migrate_fd_cancel(MigrationState *s)
>>   {
>>       DPRINTF("cancelling migration\n");
>>   
>> +    migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_CANCELLED);
>>       migrate_set_state(s, MIG_STATE_ACTIVE, MIG_STATE_CANCELLED);
>>   }
> This chunk is wrong.
>
> we can call qme_migrate_cancel() at any point,  and it is going to be
> called normally from MIG_STATE_ACTIVE.
>
>
>      migrate_set_satet(s, s->state,  MIG_STATE_CANCELLED)
>
> should do the trick.  Or something like that,  what do you think?
>
> Later,  Juan.
>
>
>

Great idea, thank you.

- Michael

[Qemu-devel] [PATCH v11 15/15] rdma: account for the time spent in MIG_STATE_SETUP through QMP

[mrhines]

From: "Michael R. Hines" <mrhines@us.ibm.com>

Using the previous patches, we're now able to timestamp the SETUP
state. Once we have this time, let the user know about it in the
schema.

Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>
---
 hmp.c                         |    4 ++++
 include/migration/migration.h |    1 +
 migration.c                   |    9 +++++++++
 qapi-schema.json              |    9 ++++++++-
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/hmp.c b/hmp.c
index a3c6b55..2b75b28 100644
--- a/hmp.c
+++ b/hmp.c
@@ -166,6 +166,10 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
             monitor_printf(mon, "downtime: %" PRIu64 " milliseconds\n",
                            info->downtime);
         }
+        if (info->has_setup_time) {
+            monitor_printf(mon, "setup: %" PRIu64 " milliseconds\n",
+                           info->setup_time);
+        }
     }
 
     if (info->has_ram) {
diff --git a/include/migration/migration.h b/include/migration/migration.h
index b5e413a..e41397e 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -49,6 +49,7 @@ struct MigrationState
     int64_t dirty_bytes_rate;
     bool enabled_capabilities[MIGRATION_CAPABILITY_MAX];
     int64_t xbzrle_cache_size;
+    int64_t setup_time; 
 };
 
 void process_incoming_migration(QEMUFile *f);
diff --git a/migration.c b/migration.c
index 758d99d..bb412df 100644
--- a/migration.c
+++ b/migration.c
@@ -191,6 +191,7 @@ MigrationInfo *qmp_query_migrate(Error **errp)
     case MIG_STATE_SETUP:
         info->has_status = true;
         info->status = g_strdup("setup");
+        info->has_total_time = false;
         break;
     case MIG_STATE_ACTIVE:
         info->has_status = true;
@@ -200,6 +201,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
             - s->total_time;
         info->has_expected_downtime = true;
         info->expected_downtime = s->expected_downtime;
+        info->has_setup_time = true;
+        info->setup_time = s->setup_time;
 
         info->has_ram = true;
         info->ram = g_malloc0(sizeof(*info->ram));
@@ -231,6 +234,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
         info->total_time = s->total_time;
         info->has_downtime = true;
         info->downtime = s->downtime;
+        info->has_setup_time = true;
+        info->setup_time = s->setup_time;
 
         info->has_ram = true;
         info->ram = g_malloc0(sizeof(*info->ram));
@@ -523,6 +528,7 @@ static void *migration_thread(void *opaque)
 {
     MigrationState *s = opaque;
     int64_t initial_time = qemu_get_clock_ms(rt_clock);
+    int64_t setup_start = qemu_get_clock_ms(host_clock);
     int64_t initial_bytes = 0;
     int64_t max_size = 0;
     int64_t start_time = initial_time;
@@ -531,8 +537,11 @@ static void *migration_thread(void *opaque)
     DPRINTF("beginning savevm\n");
     qemu_savevm_state_begin(s->file, &s->params);
 
+    s->setup_time = qemu_get_clock_ms(host_clock) - setup_start;
     migrate_set_state(s, MIG_STATE_SETUP, MIG_STATE_ACTIVE);
 
+    DPRINTF("setup complete\n");
+
     while (s->state == MIG_STATE_ACTIVE) {
         int64_t current_time;
         uint64_t pending_size;
diff --git a/qapi-schema.json b/qapi-schema.json
index a30a728..b5e1e6b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -578,6 +578,12 @@
 #        expected downtime in milliseconds for the guest in last walk
 #        of the dirty bitmap. (since 1.3)
 #
+# @setup-time: #optional amount of setup time spent _before_ the iterations 
+#        begin but _after_ the QMP command is issued. This is designed to
+#        provide an accounting of any activities (such as RDMA pinning) which
+#        may be expensive, but do not actually occur during the iterative
+#        migration rounds themselves. (since 1.6)
+#
 # Since: 0.14.0
 ##
 { 'type': 'MigrationInfo',
@@ -586,7 +592,8 @@
            '*xbzrle-cache': 'XBZRLECacheStats',
            '*total-time': 'int',
            '*expected-downtime': 'int',
-           '*downtime': 'int'} }
+           '*downtime': 'int',
+           '*setup-time' : 'int'} }
 
 ##
 # @query-migrate
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH v11 15/15] rdma: account for the time spent in MIG_STATE_SETUP through QMP

[Juan Quintela]

mrhines@linux.vnet.ibm.com wrote:
> From: "Michael R. Hines" <mrhines@us.ibm.com>
>
> Using the previous patches, we're now able to timestamp the SETUP
> state. Once we have this time, let the user know about it in the
> schema.
>
> Signed-off-by: Michael R. Hines <mrhines@us.ibm.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>