From: Paolo Bonzini <pbonzini@redhat.com>
To: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com,
mark.burton@greensocs.com, real@ispras.ru, batuzovk@ispras.ru,
"maria.klimushenkova@ispras.ru" <maria.klimushenkova@ispras.ru>,
afaerber@suse.de, fred.konrad@greensocs.com
Subject: Re: [Qemu-devel] [RFC PATCH v3 07/49] kvmapic: fixing loading vmstate
Date: Thu, 31 Jul 2014 17:43:04 +0200 [thread overview]
Message-ID: <53DA6408.4060608@redhat.com> (raw)
In-Reply-To: <y76kb6db0fom2jl45wn6nk5b.1406819897500@email.android.com>
Il 31/07/2014 17:21, Pavel Dovgalyuk ha scritto:
> Pre load is necessary, because we switched off resetting VM while
> loading in the replay mode.
Then you should not add it now, but rather when you add replay. Treat
this part of the series as merely fixing migration bugs. In fact, I
suggest that you start by progressively refining these patches. You can
also post the other patches that I mentioned were good to go in my
review of v1. Then pass to the next steps (in the meanwhile, Fred's
icount reverse-exec patches might get merged too).
Related to this: do _not_ assume that people review the entire series.
It's normal to notice that the initial part should stand on its own
legs, and then review it as if the remaining patches do not exist! It's
up to _you_, in the commit messages, to annotate things that you do now
for the sake of future patches.
> Calling reset handlers generates irqs, that
> make loading process non-deterministic.
What irqs are these, and why do they make the loading process
non-deterministic? Is it important that they not be generated, as long
as the final state is deterministic?
Have you audited all subsections and add a pre-load function there?
Where do you do this in the series? These non-mechanical, sweeping
changes suggest to me that you find a way to keep resets during load.
Compare for example the patches at
http://lists.gnu.org/archive/html/qemu-devel/2013-09/msg00477.html
with the series at
http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg02652.html
http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg03934.html
The former adds 230 lines of code and adds code to 40-odd files.
The latter includes a preparatory part that is complicated but only
touches 4 files, handling of the odd cases that touches about 10 files,
and the final sweeping change that is mechanical and hardly requires
review. Overall it adds ~20 lines of code, and adds actual
functionality in addition to fixing the same bug as the first!
Paolo
next prev parent reply other threads:[~2014-07-31 15:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 15:21 [Qemu-devel] [RFC PATCH v3 07/49] kvmapic: fixing loading vmstate Pavel Dovgalyuk
2014-07-31 15:43 ` Paolo Bonzini [this message]
2014-08-25 11:40 ` Pavel Dovgaluk
2014-08-25 11:41 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2014-07-31 12:53 [Qemu-devel] [RFC PATCH v3 00/49] Deterministic replay and reverse execution Pavel Dovgalyuk
2014-07-31 12:54 ` [Qemu-devel] [RFC PATCH v3 07/49] kvmapic: fixing loading vmstate Pavel Dovgalyuk
2014-07-31 13:01 ` Paolo Bonzini
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=53DA6408.4060608@redhat.com \
--to=pbonzini@redhat.com \
--cc=afaerber@suse.de \
--cc=batuzovk@ispras.ru \
--cc=fred.konrad@greensocs.com \
--cc=maria.klimushenkova@ispras.ru \
--cc=mark.burton@greensocs.com \
--cc=pavel.dovgaluk@ispras.ru \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=real@ispras.ru \
/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).