From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Pavel Fedin <p.fedin@samsung.com>
Cc: peter.maydell@linaro.org, quintela@redhat.com,
marc.zyngier@arm.com, 'QEMU' <qemu-devel@nongnu.org>,
amit.shah@redhat.com, kvmarm@lists.cs.columbia.edu,
christoffer.dall@linaro.org
Subject: Re: Live migration sequence
Date: Fri, 16 Oct 2015 18:11:00 +0100 [thread overview]
Message-ID: <20151016171100.GJ2622@work-vm> (raw)
In-Reply-To: <00b201d107e3$ac36acd0$04a40670$@samsung.com>
* Pavel Fedin (p.fedin@samsung.com) wrote:
> Hello!
>
> > Some thoughts:
> > a) There is a migration state notifier list - see add_migration_state_change_notifier (spice
> > calls it)
> > - but I don't think it's called in the right places for your needs; we
> > could add some more places that gets called.
>
> I am now trying to add one more state, something like MIGRATION_STATUS_FINISHING. It would mean that CPUs are stopped.
> Can you explain me migration code a bit? Where is iteration loop, and where are CPUs stopped? I am looking at migration.c but
> cannot say that i understand some good portion of it. :)
The outgoing side of migration comes into migrate_fd_connect which does
all the setup and then starts 'migration_thread'. The big while loop in there does
most of the work, and on each loop normally ends up calling either
qemu_savevm_state_iterate
or
migration_completion
migration_completion calls vm_stop_force_state to stop the CPU,
and then qemu_savevm_state_complete to save all the remaining devices
out.
Dave
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Pavel Fedin <p.fedin@samsung.com>
Cc: peter.maydell@linaro.org, quintela@redhat.com,
marc.zyngier@arm.com, 'QEMU' <qemu-devel@nongnu.org>,
amit.shah@redhat.com, kvmarm@lists.cs.columbia.edu,
christoffer.dall@linaro.org
Subject: Re: [Qemu-devel] Live migration sequence
Date: Fri, 16 Oct 2015 18:11:00 +0100 [thread overview]
Message-ID: <20151016171100.GJ2622@work-vm> (raw)
In-Reply-To: <00b201d107e3$ac36acd0$04a40670$@samsung.com>
* Pavel Fedin (p.fedin@samsung.com) wrote:
> Hello!
>
> > Some thoughts:
> > a) There is a migration state notifier list - see add_migration_state_change_notifier (spice
> > calls it)
> > - but I don't think it's called in the right places for your needs; we
> > could add some more places that gets called.
>
> I am now trying to add one more state, something like MIGRATION_STATUS_FINISHING. It would mean that CPUs are stopped.
> Can you explain me migration code a bit? Where is iteration loop, and where are CPUs stopped? I am looking at migration.c but
> cannot say that i understand some good portion of it. :)
The outgoing side of migration comes into migrate_fd_connect which does
all the setup and then starts 'migration_thread'. The big while loop in there does
most of the work, and on each loop normally ends up calling either
qemu_savevm_state_iterate
or
migration_completion
migration_completion calls vm_stop_force_state to stop the CPU,
and then qemu_savevm_state_complete to save all the remaining devices
out.
Dave
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2015-10-16 17:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-08 11:39 [Qemu-devel] Live migration sequence Pavel Fedin
2015-10-09 15:29 ` Dr. David Alan Gilbert
2015-10-13 10:06 ` Pavel Fedin
2015-10-13 11:05 ` Dr. David Alan Gilbert
2015-10-13 11:05 ` [Qemu-devel] " Dr. David Alan Gilbert
2015-10-13 12:02 ` Pavel Fedin
2015-10-13 12:02 ` Pavel Fedin
2015-10-13 12:04 ` Peter Maydell
2015-10-13 12:04 ` Peter Maydell
2015-10-13 12:41 ` Pavel Fedin
2015-10-13 12:41 ` Pavel Fedin
2015-10-16 7:24 ` Pavel Fedin
2015-10-16 7:24 ` Pavel Fedin
2015-10-16 17:11 ` Dr. David Alan Gilbert [this message]
2015-10-16 17:11 ` Dr. David Alan Gilbert
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=20151016171100.GJ2622@work-vm \
--to=dgilbert@redhat.com \
--cc=amit.shah@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=marc.zyngier@arm.com \
--cc=p.fedin@samsung.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.