.
- Michael
On 05/09/2013 06:45 PM, Michael R. Hines wrote:
Some more followup questions below to help me debug before I start
digging in...
On 05/09/2013 06:20 PM, Chegu Vinod wrote:
Setting aside the mlock() freezes for the moment, let's first fix your
crashing
problem on the destination
OK, this looks excellent. I think we're ready for a PULL request now - I
will submit to Juan - I've already got a signed-off from Paolo Eric.
I think we've got sufficient testing now.
I'm expecting to get access to a big machine in the next week or two
(256G machine) - and I should be able
I don't think my presence on the call is necessary,
but I would appreciate it you put RDMA on the agenda.
The patches have been thoroughly bug-tested and reviewed.
- Michael
On 06/11/2013 11:52 AM, Juan Quintela wrote:
Hi
Now we have moved to one call each other week.
Please, send any topic
On 10/08/2013 12:05 PM, Paolo Bonzini wrote:
Il 08/10/2013 16:49, Eric Blake ha scritto:
You are now returning a state that older libvirt versions are not
expecting. Obviously, we can patch newer libvirt to make migration work
again, but should we be thinking about damage control by stating
);
if (ret 0) {
fprintf(stderr, rdma migration: polling error! %d\n, ret);
goto err;
Reviewed-by: Michael R. Hines mrhi...@us.ibm.com
On 10/15/2013 03:26 AM, Jules Wang wrote:
v2 - v3:
* add documentation of new option in qapi-schema.
* long option name: ft - fault-tolerant
v1 - v2:
* cmdline: migrate curling:tcp:address:port
- migrate -f tcp:address:port
* sender: use QEMU_VM_FILE_MAGIC_FT as the header of the
On 10/15/2013 03:26 AM, Jules Wang wrote:
v2 - v3:
* add documentation of new option in qapi-schema.
* long option name: ft - fault-tolerant
v1 - v2:
* cmdline: migrate curling:tcp:address:port
- migrate -f tcp:address:port
* sender: use QEMU_VM_FILE_MAGIC_FT as the header of the
On 10/22/2013 04:20 PM, Eric Blake wrote:
On 10/22/2013 05:59 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As far as we can tell, all known bugs have been fixed,
there as been very good participation in testing and running.
1. Parallel RDMA migrations
On 10/23/2013 02:25 AM, Paolo Bonzini wrote:
Il 22/10/2013 21:20, Eric Blake ha scritto:
-# @x-rdma-pin-all: Controls whether or not the entire VM memory footprint is
+# @rdma-pin-all: Controls whether or not the entire VM memory footprint is
# mlock()'d on demand or all at once.
On 10/25/2013 11:14 AM, Paolo Bonzini wrote:
Il 25/10/2013 16:03, Michael R. Hines ha scritto:
Well, I tried posting libvirt support with this naming scheme,
but they didn't accepted.
Their reason (Daniel, I think) is valid: experimental implies that it
shouldn't be exposed in the management
On 09/18/2013 06:07 AM, Isaku Yamahata wrote:
ram_handle_compressed() should be aware size TARGET_PAGE_SIZE
migration-rdma can call it with larger size.
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
arch_init.c | 21 ++---
1 file changed, 14 insertions(+),
On 09/03/2013 10:32 PM, Isaku Yamahata wrote:
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/migration-rdma.c b/migration-rdma.c
index e71c10a..db5a908 100644
--- a/migration-rdma.c
On 09/03/2013 10:32 PM, Isaku Yamahata wrote:
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/migration-rdma.c b/migration-rdma.c
index db5a908..941c07e 100644
---
On 09/20/2013 03:51 AM, Isaku Yamahata wrote:
ram_handle_compressed() should be aware of size TARGET_PAGE_SIZE.
migration-rdma can call it with larger size.
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
changes v1 - v2:
- don't loop
---
arch_init.c | 11 ++-
1
On 09/20/2013 03:55 AM, Isaku Yamahata wrote:
On Wed, Sep 18, 2013 at 10:28:51AM -0400, Michael R. Hines wrote:
On 09/03/2013 10:32 PM, Isaku Yamahata wrote:
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c |8 +---
1 file changed, 5 insertions(+), 3
On 09/20/2013 12:59 PM, Isaku Yamahata wrote:
On Wed, Sep 18, 2013 at 11:01:16AM -0400, Michael R. Hines wrote:
The value of chunk_end changes based on whether or not the value of
block-is_ram_block is true of false.
When is block-is_ram_block set to false?
Looking at __qemu_rdma_add_block
On 09/24/2013 12:36 PM, Juan Quintela wrote:
Michael R. Hines mrhi...@linux.vnet.ibm.com wrote:
On 09/20/2013 03:55 AM, Isaku Yamahata wrote:
On Wed, Sep 18, 2013 at 10:28:51AM -0400, Michael R. Hines wrote:
On 09/03/2013 10:32 PM, Isaku Yamahata wrote:
Signed-off-by: Isaku Yamahata yamah
On 09/24/2013 01:38 PM, Juan Quintela wrote:
Michael R. Hines mrhi...@linux.vnet.ibm.com wrote:
On 09/24/2013 12:36 PM, Juan Quintela wrote:
Michael R. Hines mrhi...@linux.vnet.ibm.com wrote:
On 09/20/2013 03:55 AM, Isaku Yamahata wrote:
On Wed, Sep 18, 2013 at 10:28:51AM -0400, Michael R
+2512,7 @@ static void *qemu_rdma_data_init(const char *host_port,
Error **errp)
}
}
+qapi_free_InetSocketAddress(addr);
return rdma;
}
Reviewed-by: Michael R. Hines mrhi...@us.ibm.com
On 09/04/2013 04:10 AM, Frank Yang wrote:
On 2013-9-3 13:03, Lei Li wrote:
Hi Frank,
I failed to apply this patch. Please make sure to use git-send-email, otherwise
it's a little hard to review. :)
On 08/30/2013 08:39 PM, Frank Yang wrote:
When several VMs migrate with RDMA at the same time,
On 07/26/2013 10:30 PM, Andreas Färber wrote:
Am 27.07.2013 04:23, schrieb mrhi...@linux.vnet.ibm.com:
From: Michael R. Hines mrhi...@us.ibm.com
When testing with libvirt, a simple IPv6 migration test failed
because we were not using getaddrinfo() properly.
This makes IPv6 migration over RDMA
this
using migration_is_active(). Spice is now notified with
MIG_STATE_SETUP and migration_is_active() no longer works.
Replace migration_is_active() with migration_in_setup() to fix spice
migration.
Cc: Michael R. Hines mrhi...@us.ibm.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
On 07/29/2013 11:01 AM, Stefan Hajnoczi wrote:
On Mon, Jul 29, 2013 at 10:46:50AM -0400, Michael R. Hines wrote:
On 07/29/2013 09:01 AM, Stefan Hajnoczi wrote:
Commit 29ae8a4133082e16970c9d4be09f4b6a15034617 (rdma: introduce
MIG_STATE_NONE and change MIG_STATE_SETUP state transition) changed
On 07/30/2013 04:14 AM, Orit Wasserman wrote:
On 07/27/2013 05:23 AM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
When testing with libvirt, a simple IPv6 migration test failed
because we were not using getaddrinfo() properly.
This makes IPv6 migration over RDMA
On 07/30/2013 11:31 AM, Orit Wasserman wrote:
On 07/30/2013 05:57 PM, Michael R. Hines wrote:
On 07/30/2013 04:14 AM, Orit Wasserman wrote:
On 07/27/2013 05:23 AM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
When testing with libvirt, a simple IPv6 migration
On 08/01/2013 11:56 PM, Isaku Yamahata wrote:
Cc: Michael R. Hines mrhi...@us.ibm.com
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/migration-rdma.c b
On 08/01/2013 11:56 PM, Isaku Yamahata wrote:
Cc: Michael R. Hines mrhi...@us.ibm.com
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/migration-rdma.c b/migration-rdma.c
index 67069d2
On 08/01/2013 11:56 PM, Isaku Yamahata wrote:
RDMA_WRID_CONTROL should be used. And remove related work around.
Cc: Michael R. Hines mrhi...@us.ibm.com
Signed-off-by: Isaku Yamahata yamah...@private.email.ne.jp
---
migration-rdma.c | 12 ++--
1 file changed, 6 insertions(+), 6
On 08/01/2013 11:56 PM, Isaku Yamahata wrote:
Small fixes/clean up to rdma. found through code review.
Isaku Yamahata (3):
rdma: don't use negative index to array
rdma: qemu_rdma_post_send_control uses wrongly RDMA_WRID_MAX
rdma: use RDMA_WRID_READY
migration-rdma.c | 43
On 06/16/2013 12:04 PM, Anthony Liguori wrote:
Lei Li li...@linux.vnet.ibm.com writes:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
arch_init.c | 13 +
include/migration/migration.h |3 +++
2 files changed, 16 insertions(+), 0 deletions(-)
diff
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
arch_init.c | 58 ++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index a8b91ee..a418071 100644
---
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
arch_init.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index a418071..7eeb52f 100644
--- a/arch_init.c
+++
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
arch_init.c |1 +
include/migration/vmstate.h |2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 7eeb52f..5c25005 100644
---
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
Makefile.objs |1 +
include/migration/migration.h | 15
migration-local.c | 158 +
migration-unix.c | 13
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
qemu-options.hx |9 +
vl.c| 14 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 8355f9b..a975e83 100644
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
hmp-commands.hx | 17 +
hmp.c | 13 +
hmp.h |1 +
3 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx
On 07/25/2013 04:18 PM, Lei Li wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
include/sysemu/sysemu.h |1 +
savevm.c| 55 +++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/include/sysemu/sysemu.h
On 08/03/2013 09:24 PM, Isaku Yamahata wrote:
On Fri, Aug 02, 2013 at 09:40:58AM -0400,
Michael R. Hines mrhi...@linux.vnet.ibm.com wrote:
On 08/01/2013 11:56 PM, Isaku Yamahata wrote:
Small fixes/clean up to rdma. found through code review.
Isaku Yamahata (3):
rdma: don't use negative
On 08/07/2013 04:39 AM, Orit Wasserman wrote:
On 08/04/2013 05:54 AM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
RDMA does not use sockets, so we cannot use many of the socket
helper functions, but we *do* use inet_parse() which gives
RDMA all the necessary
On 08/06/2013 10:26 PM, Isaku Yamahata wrote:
RDMAControlHeader::len is remote-provided. So validate the value before use.
Isaku Yamahata (3):
rdma: use resp.len after validation in qemu_rdma_registration_stop
rdma: validate RDMAControlHeader::len
rdma: check if RDMAControlHeader::len
On 08/08/2013 02:12 AM, Orit Wasserman wrote:
On 08/07/2013 07:05 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
getaddrinfo() already knows what it's doing,
wqand can potentially return multiple addresses.
Signed-off-by: Michael R. Hines mrhi...@us.ibm.com
On 08/08/2013 02:41 PM, Eric Blake wrote:
On 08/08/2013 11:05 AM, Orit Wasserman wrote:
ram is present also when migration completes.
expected-downtime, total-time and downtime are no longer part of ram data.
Signed-off-by: Orit Wasserman owass...@redhat.com
---
qmp-commands.hx | 20
On 08/09/2013 04:26 PM, Eric Blake wrote:
On 08/09/2013 02:05 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
Was missing 'setup-time' in some of the QMP documentation...
Signed-off-by: Michael R. Hines mrhi...@us.ibm.com
---
qmp-commands.hx | 10
,
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
The capability allows management software to throttle the MC frequency
during VM application transience.
The qemu-file savevm() functions inform the destination that the incoming
traffic is MC-specific traffic
On 10/23/2013 01:23 AM, Jules wrote:
On 2013-10-22 17:00 -0400，Michael R. Hines wrote：
On 10/15/2013 03:26 AM, Jules Wang wrote:
v2 - v3:
* add documentation of new option in qapi-schema.
* long option name: ft - fault-tolerant
v1 - v2:
* cmdline: migrate curling:tcp:address:port
On 11/05/2013 05:19 PM, Eric Blake wrote:
On 10/26/2013 02:03 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As far as we can tell, all known bugs have been fixed:
1. Parallel RDMA migrations are working
2. IPv6 migration is working
3. Libvirt patches
On 11/15/2013 12:06 PM, Daniel P. Berrange wrote:
On Wed, Nov 06, 2013 at 01:59:14PM -0500, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As far as we can tell, all known bugs have been fixed:
[snip]
3. Libvirt patches are ready
[snip]
Objections
On 11/15/2013 02:25 PM, Eric Blake wrote:
On 11/15/2013 10:40 AM, Michael R. Hines wrote:
This is unrelated to RDMA - accessing the /dev/infiniband
device nodes is already supported by libvirt my modifying
the configuration file in /etc and that works just fine.
http://wiki.qemu.org/Features
On 11/23/2013 12:37 AM, Daniel P. Berrange wrote:
On Sat, Nov 23, 2013 at 12:29:51AM +0800, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As far as we can tell, all known bugs have been fixed:
3. Libvirt patches are ready
Please stop claiming this. A proof
On 11/06/2013 09:04 PM, Juan Quintela wrote:
Hi
[v2]
In this version:
- fixed all the comments from last versions (thanks Eric)
- kvm migration bitmap is synchronized using bitmap operations
- qemu bitmap - migration bitmap is synchronized using bitmap operations
If bitmaps are not properly
On 11/06/2013 11:49 PM, Paolo Bonzini wrote:
Il 06/11/2013 15:37, Gerd Hoffmann ha scritto:
- vga ram by default is not aligned in a page number multiple of
64,
it could be optimized. Kraxel? It syncs the kvm bitmap at least
1 a second or so? bitmap is only 2048 pages (16MB by default). We
On 11/25/2013 02:15 PM, Michael R. Hines wrote:
On 11/06/2013 09:04 PM, Juan Quintela wrote:
Hi
[v2]
In this version:
- fixed all the comments from last versions (thanks Eric)
- kvm migration bitmap is synchronized using bitmap operations
- qemu bitmap - migration bitmap is synchronized using
On 07/01/2013 08:04 AM, Paolo Bonzini wrote:
Il 28/06/2013 21:59, mrhi...@linux.vnet.ibm.com ha scritto:
+/*
+ * Perform a non-optimized memory unregistration after every transfer
+ * for demonsration purposes, only if pin-all is not requested.
+ *
+ * Potential optimizations:
+ * 1. Start a
On 07/12/2013 01:09 PM, Eric Blake wrote:
On 07/12/2013 08:40 AM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As requested, the protocol now includes memory unpinning support.
This has been implemented in a non-optimized manner, in such a way
that one could
On 07/12/2013 01:39 PM, Eric Blake wrote:
On 07/12/2013 11:26 AM, Michael R. Hines wrote:
On 07/12/2013 01:09 PM, Eric Blake wrote:
On 07/12/2013 08:40 AM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As requested, the protocol now includes memory unpinning
On 07/18/2013 03:30 AM, Marcel Apfelbaum wrote:
On Tue, 2013-07-16 at 12:48 -0400, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@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
On 06/13/2013 09:50 AM, Chegu Vinod wrote:
Attempted to migrate a smaller guest 10Vcpu/64GB (the guest was just
idle) with the pin-all option.
It took ~20 sec to do the pin of the guest's RAM (this is the time
when the guest is frozen) and then the actual migration started...
and took
On 06/13/2013 10:26 AM, Chegu Vinod wrote:
1. start QEMU with the lock option *first*
2. Then enable x-rdma-pin-all
3. Then perform the migration
What happens here? Does pinning in advance help you?
Yes it does help by avoiding the freeze time at the start of the
pin-all migration.
I
On 06/13/2013 04:06 PM, Paolo Bonzini wrote:
(CC-ing qemu-devel).
OK, that's good to know. This means that we need to bringup the mlock()
problem as a larger issue in the linux community instead of the QEMU
community.
In the meantime, how about I make update to the RDMA patch which does
the
Chegu,
I believe I've fixed all the pinning / freezing issues per Paolo's
recommendations.
I've re-submitted as v8 - Can you git pull from github and re-test?
Thanks,
- Michael
On 06/13/2013 05:40 PM, Paolo Bonzini wrote:
Il 13/06/2013 17:17, Michael R. Hines ha scritto:
On 06/13/2013 04:06 PM, Paolo Bonzini wrote:
Regarding the timestamp problem, it should be fixed in the RDMA code.
You did find a bug, but xyz_start_outgoing_migration should be
asynchronous
Reviewed-By: =)
- Michael
On 06/14/2013 02:30 AM, Michael R. Hines wrote:
Chegu,
I believe I've fixed all the pinning / freezing issues per Paolo's
recommendations.
I've re-submitted as v8 - Can you git pull from github and re-test?
Thanks,
- Michael
On 06/15/2013 05:05 AM, Eric Blake wrote:
On 06/14/2013 09:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
This capability allows you to disable dynamic chunk registration
for better throughput on high-performance links.
+++ b/qapi-schema.json
@@ -608,10
On 06/15/2013 05:09 AM, Eric Blake wrote:
On 06/14/2013 09:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
This exposes throughput (in megabits/sec) through QMP.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Michael R. Hines mrhi
On 06/15/2013 05:06 AM, Eric Blake wrote:
On 06/14/2013 09:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
For very large virtual machines, pinning can take a long time.
While this does not affect the migration's *actual* time itself,
it is still important
On 06/15/2013 01:32 PM, Paolo Bonzini wrote:
Il 15/06/2013 05:06, Eric Blake ha scritto:
On 06/14/2013 09:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
For very large virtual machines, pinning can take a long time.
While this does not affect
On 06/15/2013 06:51 PM, Chegu Vinod wrote:
On 6/14/2013 1:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
Changes since v8:
For very large virtual machines, pinning can take a long time.
While this does not affect the migration's *actual* time
to the wiki?
On 6/14/2013 1:38 PM, Michael R. Hines wrote:
Chegu,
I sent a V9 to the mailing list:
The version goes even further, by explicitly timing the pinning
latency and
pushing the value out to QMP so the user clearly knows which component
of total migration time is consumed by pinning
On 06/16/2013 02:37 PM, Chegu Vinod wrote:
On 6/14/2013 1:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
For very large virtual machines, pinning can take a long time.
While this does not affect the migration's *actual* time itself,
it is still important
On 06/24/2013 09:51 AM, Paolo Bonzini wrote:
Il 24/06/2013 15:46, mrhi...@linux.vnet.ibm.com ha scritto:
From: Michael R. Hines mrhi...@us.ibm.com
For very large virtual machines, pinning can take a long time.
While this does not affect the migration's *actual* time itself,
it is still
On 06/24/2013 10:02 AM, Paolo Bonzini wrote:
Il 24/06/2013 15:55, Michael R. Hines ha scritto:
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Please stop inventing Reviewed-by tags, or I will stop reviewing your
patches.
Paolo
Inventing? I don't understand.
I accumulated all of those tags
On 06/24/2013 10:41 AM, Anthony Liguori wrote:
Michael R. Hines mrhi...@linux.vnet.ibm.com writes:
On 06/24/2013 09:51 AM, Paolo Bonzini wrote:
Il 24/06/2013 15:46, mrhi...@linux.vnet.ibm.com ha scritto:
From: Michael R. Hines mrhi...@us.ibm.com
For very large virtual machines, pinning can
On 06/25/2013 05:27 AM, Juan Quintela wrote:
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
This exposes throughput (in megabits/sec) through QMP.
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Chegu Vinod chegu_vi...@hp.com
Tested-by: Chegu Vinod
On 06/25/2013 07:51 AM, Juan Quintela wrote:
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@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
On 06/25/2013 05:49 AM, Juan Quintela wrote:
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@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
On 06/25/2013 08:05 AM, Juan Quintela wrote:
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@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
On 06/25/2013 06:13 AM, Paolo Bonzini wrote:
Il 25/06/2013 11:49, Juan Quintela ha scritto:
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@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
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
On 06/25/2013 10:17 AM, Juan Quintela wrote:
Michael R. Hines mrhi...@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:
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As described
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
On 06/25/2013 12:31 PM, Vasilis Liaskovitis wrote:
Hi,
On Mon, Jun 24, 2013 at 09:58:01PM -0400, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
[...]
+/*
+ * Put in the log file which RDMA device was opened and the details
+ * associated with that device
On 06/25/2013 10:17 AM, Juan Quintela wrote:
Michael R. Hines mrhi...@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:
mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As described
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
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
Changes since v11:
- Minor state transition fix
- Fixed localhost migration
- Fixed 0.0.0.0 migration
- Drop invalid hunk
- Updated tags
Michael R. Hines (15):
rdma: add documentation
rdma: introduce qemu_update_position()
rdma: export yield_until_fd_readable()
rdma: export throughput w
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
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
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
On 06/27/2013 03:20 PM, Peter Maydell wrote:
On 27 June 2013 11:37, Juan Quintela quint...@redhat.com wrote:
Anthony, please pull.
- improve error message (Alon)
- Make zero pages to work again (Peter Lieven)
- First 10 patches of RDMA support
Hi; could you adjust your pullrequest scripts to
On 06/27/2013 03:24 PM, Peter Maydell wrote:
On 26 June 2013 02:35, mrhi...@linux.vnet.ibm.com wrote:
--- 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
On 06/27/2013 03:53 PM, Peter Maydell wrote:
Fix compilation failures for linux-user targets following recent
migration related commits bd2fa51fcd and 43487c67.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Longer term we should probably try to disentangle migration
from user-mode
On 06/27/2013 06:41 PM, Eric Blake wrote:
On 06/25/2013 07:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
docs/rdma.txt contains full documentation,
wiki links, github url and contact information.
Reviewed-by: Juan Quintela quint...@redhat.com
Reviewed
On 06/27/2013 07:02 PM, Eric Blake wrote:
On 06/25/2013 07:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
This exposes throughput (in megabits/sec) through QMP.
Reviewed-by: Juan Quintela quint...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
On 06/27/2013 06:58 PM, Eric Blake wrote:
On 06/25/2013 07:35 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@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.
Reviewed
Quintela quint...@redhat.com Signed-off-by:
Michael R. Hines mrhi...@us.ibm.com
Usually, Reviewed-by lines are listed _after_ S-o-b lines -
signature lines are typically chronological, but the patch has to
be signed before a review can have any weight at getting the patch
into a pull request :)
Hmm
On 06/27/2013 07:09 PM, Eric Blake wrote:
On 06/27/2013 04:44 PM, mrhi...@linux.vnet.ibm.com wrote:
From: Michael R. Hines mrhi...@us.ibm.com
As requested, the protocol now includes memory unpinning support.
This has been implemented in a non-optimized manner, in such a way
that one could
On 06/27/2013 07:16 PM, Peter Maydell wrote:
On 27 June 2013 23:44, mrhi...@linux.vnet.ibm.com wrote:
+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
Do you
On 06/28/2013 09:28 AM, Peter Maydell wrote:
On 28 June 2013 14:23, Michael R. Hines mrhi...@linux.vnet.ibm.com wrote:
I assume from the PACKED annotations (do we really need both,
incidentally) that this is shared with either the guest or
with another instance of QEMU. Are there definitely
On 06/28/2013 03:33 AM, Paolo Bonzini wrote:
Il 28/06/2013 00:44, mrhi...@linux.vnet.ibm.com ha scritto:
+ *
+ * This will have a terrible impact on migration performance, so until future
+ * workload information or LRU information is available, do not attempt to use
+ * this feature except for
On 06/28/2013 10:07 AM, Peter Maydell wrote:
On 28 June 2013 15:00, Michael R. Hines mrhi...@linux.vnet.ibm.com wrote:
On 06/28/2013 09:28 AM, Peter Maydell wrote:
Is endianess for the data a big issue when you are assume the migration
is happening across identical CPU architectures?
Well
1 - 100 of 404 matches
Mail list logo
