qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: ChenLiang <chenliang88@huawei.com>
To: Sanidhya Kashyap <sanidhya.iiith@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	dgilbert@redhat.com, "quintela@redhat.com" <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/6] Obtain dirty bitmap via VM logging
Date: Thu, 22 May 2014 20:57:57 +0800	[thread overview]
Message-ID: <537DF455.4070401@huawei.com> (raw)
In-Reply-To: <CAAUTuqA2tCyN4F64+3Bw07pzZ=LUK+fUYoRCCpcZsjWkMiTX2g@mail.gmail.com>

On 2014/5/22 19:21, Sanidhya Kashyap wrote:

> On Wed, May 21, 2014 at 12:15 PM, ChenLiang <chenliang88@huawei.com> wrote:
>> On 2014/5/21 12:56, Sanidhya Kashyap wrote:
>>
>>> On Wed, May 21, 2014 at 9:43 AM, ChenLiang <chenliang88@huawei.com> wrote:
>>>> Hi,
>>>> Nice job. We should avoid running migration_thread and bitmap_logging_thread simultaneously.
>>>>
>>> Any particular suggestion to avoid running simultaneous execution of
>>> the threads?
>>>
>>
>> We can do it like this:
>> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg02185.html
>>
> 
> Hi Chen,
> 
> I have some questions which I wanted  to get clarified before
> implementing the above part of avoiding the simultaneous execution.
> 
> As the migration process is going on, the RUN_STATE_RUNNING state is
> being used, which is the same case in bitmap dump process. In order to
> use the concept of RUN_STATE_* states, should I create two new states
> as RUN_STATE_LOGBITMAP AND RUN_STATE_OUTMIGRATE? The
> RUN_STATE_OUTMIGRATE state will have all the transitions that
> RUN_STATE_RUNNING supports except the ones being used by migration.
> Similarly, RUN_STATE_MIGRATE will support all the transitions of
> RUN_STATE_RUNNING except RUN_STATE_LOGBITMAP.
> 
> We might also have to update the runstate_is_running function, since
> RUN_STATE_LOGBITMAP and RUN_STATE_MIGRATE are almost similar in nature
> to the RUN_STATE_RUNNING. What is your opinion about that?
> 
> Is it the only approach to do it or are there any simple and efficient
> approaches?
> 
> Thanks,
> Sanidhya
> 
>


Hmm, I think we need the two flags. Although it is little hard to do it. Because the vm can't
do something like hotplug vcpu or device during migrate. But for now qemu don't guarantee it(in my reading).
So we should change the vm state  RUN_STATE_RUNNING to RUN_STATE_MIGRATE when migrate.
BTW, it is not your patches problem.

cc:  Juan

Best regards
ChenLiang

  reply	other threads:[~2014-05-22 13:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-20 17:47 [Qemu-devel] [PATCH 0/6] Obtain dirty bitmap via VM logging Sanidhya Kashyap
2014-05-20 17:47 ` [Qemu-devel] [PATCH 1/6] split dirty bitmap into four for dumping the bitmaps Sanidhya Kashyap
2014-05-20 17:47 ` [Qemu-devel] [PATCH 2/6] bitmap dump code via QAPI framework Sanidhya Kashyap
2014-05-20 19:03   ` Eric Blake
2014-05-20 19:25     ` Sanidhya Kashyap
2014-05-20 17:47 ` [Qemu-devel] [PATCH 3/6] hmp interface for dirty bitmap dump Sanidhya Kashyap
2014-05-20 17:47 ` [Qemu-devel] [PATCH 4/6] cancel mechanism for an already running dump bitmap process Sanidhya Kashyap
2014-05-20 19:34   ` Eric Blake
2014-05-20 17:47 ` [Qemu-devel] [PATCH 5/6] set the frequency of the " Sanidhya Kashyap
2014-05-20 19:36   ` Eric Blake
2014-05-20 17:47 ` [Qemu-devel] [PATCH 6/6] python script for extracting bitmap from a binary file Sanidhya Kashyap
2014-05-20 19:38   ` Eric Blake
2014-05-20 19:39     ` Eric Blake
2014-05-21  0:43       ` Sanidhya Kashyap
2014-05-21  4:13 ` [Qemu-devel] [PATCH 0/6] Obtain dirty bitmap via VM logging ChenLiang
2014-05-21  4:56   ` Sanidhya Kashyap
2014-05-21  6:45     ` ChenLiang
2014-05-21  6:55       ` Sanidhya Kashyap
2014-05-22 11:21       ` Sanidhya Kashyap
2014-05-22 12:57         ` ChenLiang [this message]
2014-05-23  2:30           ` Sanidhya Kashyap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=537DF455.4070401@huawei.com \
    --to=chenliang88@huawei.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=sanidhya.iiith@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).