From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50170 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMTQX-0006x7-GH for qemu-devel@nongnu.org; Wed, 09 Jun 2010 18:07:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMTQV-0002i1-3T for qemu-devel@nongnu.org; Wed, 09 Jun 2010 18:07:13 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:45743) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMTQU-0002hu-Uh for qemu-devel@nongnu.org; Wed, 09 Jun 2010 18:07:11 -0400 Received: by gyd5 with SMTP id 5so4469561gyd.4 for ; Wed, 09 Jun 2010 15:07:10 -0700 (PDT) MIME-Version: 1.0 Sender: tamura.yoshiaki@gmail.com In-Reply-To: References: Date: Thu, 10 Jun 2010 07:07:10 +0900 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events From: Yoshiaki Tamura Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org 2010/6/10 Juan Quintela : > Yoshiaki Tamura wrote: >> Hi Juan, >> > >> I don't know I have addressed the problem correctly, but here is my >> try to get "info migrate" on incoming side. >> >> http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00417.html > > I saw it, haven't had the time to look at it yet. > >> Apart from that I have a concern on relation between newly introduced >> QMP Migration events and existing MIG_STATE_*. =A0Are they supposed to >> be 1 to 1 mapping? > > Good question. =A0In my tree I had info migrate being the same on > source and destination, but I didn't have async migration. =A0I have to > check with yours. > >> If so, instead of calling >> monitor_protocol_event() everywhere, how about introducing a common >> function in migration that sets s->mig_state and emits QMP Migration >> events at once? > > I did that locally, just that this is in the middle of a big cleanup. > > I am not sure that is still enough. =A0We have: > > - qemu status: running/stopped > - we have another state "incoming" migration that needs to be same level > =A0than running/stopped > - I think MIG_STATE_* should also be promotted to this level, but > =A0haven't fully thought how to do it. I think this problem isn't limited to migration. We need an central table that contains the relation between states in qemu and corresponding QMP events that must be emitted. Otherwise, we can get into troubles like missing to emit necessary QMP events, or duplicated QMP events. Thanks, Yoshi > > Later, Juan. > >