[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and ch

From: Michael R. Hines
Subject: Re: [Qemu-devel] [PATCH v11 14/15] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition
Date: Tue, 25 Jun 2013 09:44:38 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

On 06/25/2013 06:13 AM, Paolo Bonzini wrote:
Il 25/06/2013 11:49, Juan Quintela ha scritto:
address@hidden wrote:
From: "Michael R. Hines" <address@hidden>

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 
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 <address@hidden>
Signed-off-by: Michael R. Hines <address@hidden>
@@ -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?


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]