From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Yury Kotov <yury-kotov@yandex-team.ru>
Cc: Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Peter Crosthwaite <crosthwaite.peter@gmail.com>,
Juan Quintela <quintela@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
"wrfsh@yandex-team.ru" <wrfsh@yandex-team.ru>,
Richard Henderson <rth@twiddle.net>,
"clg@kaod.org" <clg@kaod.org>,
jiangshanlai@gmail.com
Subject: Re: [Qemu-devel] [PATCH 0/4] Add ignore-external migration capability
Date: Tue, 22 Jan 2019 18:08:29 +0000 [thread overview]
Message-ID: <20190122180828.GB2241@work-vm> (raw)
In-Reply-To: <3429361548079742@iva8-f16495710718.qloud-c.yandex.net>
* Yury Kotov (yury-kotov@yandex-team.ru) wrote:
> Hi,
>
> Just want to clarify your suggestions.
>
> 1) migrate=off/share=on
>
> I'm not sure that adding new flag 'migrate=off' is a good idea. I think that
> share=on as you suggested at first is enough.
> * It's a new flag which has sense only with share=on
> * It seems to that the meaning of this flag isn't clear. migrate=off isn't
> RAM_MIGRATABLE, it's rather RAM_IGNORABLE. I.e. it means that we don't migrate
> such block only if the capability is enabled.
> If you don't mind, I'll prefer share=on and ignore-shared capability.
Yes, I'm OK with that, just check with Lai Jiangshan (cc'd) that it
meets their requirement as well.
> 2) Keep RAM migration version
>
> It's more complicated question. To validate GPAs for ignored blocks I have to
> change the stream format. I can do this conditionally (if (cap_enabled) { ... })
> but in this case, I want to make sure that the capability is enabled or disabled
> on both source and target. Otherwise, there is an undefined behavior on the
> target side (most likely some error during deserialization).
> To fix that I can add a capability validation feature.
>
> For example, add a new section to vmstate_configuration (not complete):
> +static const VMStateDescription vmstate_capabilites = {
> + .name = "configuration/capabilities",
> + .version_id = 1,
> + .minimum_version_id = 1,
> + .needed = vmstate_capabilites_needed,
> + .fields = (VMStateField[]) {
> + VMSTATE_UINT32_V(caps_count, SaveState, 1),
> + VMSTATE_VARRAY_UINT32_ALLOC(capabilities, SaveState, caps_count, 1,
> + vmstate_info_bool, bool),
> + VMSTATE_END_OF_LIST()
> + }
> +};
> +
> static const VMStateDescription vmstate_configuration = {
> .name = "configuration",
> .version_id = 1,
> @@ -404,6 +456,7 @@ static const VMStateDescription vmstate_configuration = {
> },
> .subsections = (const VMStateDescription*[]) {
> &vmstate_target_page_bits,
> + &vmstate_capabilites,
> NULL
> }
> };
>
> It seems too complicated. If I should change the migration stream anyway, maybe
> it's better to increment the version?
>
> What do you think?
Never break compatibility!
There's three separate things here:
a) Skipping the shared blocks
b) Adding a check that skipped blocks actually match
c) Adding a check for matching capabilities
Lets solve them separately.
I think (a) we've discussed.
(b) If you only enable the checking when your ignore-shared is enabled
then it doesn't break any compatibility. But watch out, if they're
skipped for some other reason then you might not want to check them;
for example some of the things Peter Maydell was talking about for ARM
was that the block may or may not be present, so there's no requirement
it's on the destination.
(c) That's a nice to have; you'd have to create a list of capabilities
you care about including; if they're only new capabilities then you
can just enable the fields when any are set and it doesn't break old
things; if you want to include some other capabilities then tie
it to the machine type and it wont break old setups.
Dave
> Regards,
> Yury
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-01-22 18:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 12:01 [Qemu-devel] [PATCH 0/4] Add ignore-external migration capability Yury Kotov
2019-01-10 12:01 ` [Qemu-devel] [PATCH 1/4] migration: add RAMBlock's offset validation Yury Kotov
2019-01-10 20:14 ` Dr. David Alan Gilbert
2019-01-11 10:06 ` Igor Mammedov
2019-01-11 10:58 ` Dr. David Alan Gilbert
2019-01-11 16:38 ` Yury Kotov
2019-01-11 18:25 ` Dr. David Alan Gilbert
2019-01-14 12:58 ` Yury Kotov
2019-01-10 12:01 ` [Qemu-devel] [PATCH 2/4] exec: add RAM_EXTERNAL flag to mark non-QEMU allocated blocks Yury Kotov
2019-01-10 20:14 ` Dr. David Alan Gilbert
2019-01-10 12:01 ` [Qemu-devel] [PATCH 3/4] migration: introduce ignore-external capability Yury Kotov
2019-01-10 12:01 ` [Qemu-devel] [PATCH 4/4] tests/migration-test: Add a test for " Yury Kotov
2019-01-10 20:11 ` [Qemu-devel] [PATCH 0/4] Add ignore-external migration capability Dr. David Alan Gilbert
2019-01-11 15:49 ` Yury Kotov
2019-01-11 20:09 ` Dr. David Alan Gilbert
2019-01-14 15:16 ` Yury Kotov
2019-01-21 14:09 ` Yury Kotov
2019-01-22 18:08 ` Dr. David Alan Gilbert [this message]
2019-01-11 20:55 ` Eduardo Habkost
2019-01-14 15:31 ` Yury Kotov
2019-01-13 14:37 ` no-reply
2019-01-13 23:57 ` no-reply
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=20190122180828.GB2241@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=clg@kaod.org \
--cc=crosthwaite.peter@gmail.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=jiangshanlai@gmail.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
--cc=wrfsh@yandex-team.ru \
--cc=yury-kotov@yandex-team.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).