qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Peter Xu <peterx@redhat.com>,
	qemu-devel@nongnu.org, Laurent Vivier <lvivier@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/6] migration: objectify MigrationState
Date: Fri, 09 Jun 2017 19:30:32 +0200	[thread overview]
Message-ID: <87lgp183wn.fsf@secure.mitica> (raw)
In-Reply-To: <877f0lgsxu.fsf@dusky.pond.sub.org> (Markus Armbruster's message of "Fri, 09 Jun 2017 16:02:37 +0200")

Markus Armbruster <armbru@redhat.com> wrote:
> Test compile gripes:
>
>     hw/xen/xen-common.c: In function ‘xen_init’:
>     hw/xen/xen-common.c:147:5: warning: implicit declaration of function ‘register_compat_prop’ [-Wimplicit-function-declaration]
>          register_compat_prop("migration", "store-global-state", "off");
>          ^~~~~~~~~~~~~~~~~~~~
>     hw/xen/xen-common.c:147:5: warning: nested extern declaration of ‘register_compat_prop’ [-Wnested-externs]
>
> You might want to install Xen development packages to catch such issues
> earlier.
>
> Test run:
>
>     $ qemu-system-x86_64 -device migration,help
>     migration.skip-section-footer=bool
>     migration.store-global-state=bool
>     migration.only-migratable=bool
>     migration.skip-configuration=bool
>
> What would adding this device do?

Parameters, capabilities, options for migration.

This was what we discussed on irc.  We want to have a way to control
migration features that depend on versions.

So we disable new features for old machine types (normal thing that we
do).  But right now, creating such a new feature requires creating a
couple of functions to set/clear the feature, adding includes on the
destination side, etc.

This was supposed to be a global property (or a qemu_opt, or whatever).
Just something that could be enabled/disabled easily on machine types,
and if possible independently of machine types.  This (for instance)
would allow that store-global-state is disabled by defaulte for
machine-2.9 (I forgot the exact name for the machine type), but I can
enable it by hand.  That is very handy for testing.

So, I think that the question is, how/where can we set that kind of
properties?

At least for me, being able to *also* set migration
capabilities/parameters with this mechanism on the command line would be
very nice, for instance

   -global migration.xbzrle on

or

   -global migration.max-speed 2G

I don't care about what is the exact syntax, or where we hang them,
i.e. a new device, a new list, somewhere that already exist.  That is
what we ask for advice.

Thanks for the review and the suggestions.

Later, Juan.

  reply	other threads:[~2017-06-09 17:30 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-09  3:48 [Qemu-devel] [PATCH v2 0/6] migration: objectify MigrationState Peter Xu
2017-06-09  3:48 ` [Qemu-devel] [PATCH v2 1/6] machine: export register_compat_prop() Peter Xu
2017-06-09  7:41   ` Juan Quintela
2017-06-09  3:48 ` [Qemu-devel] [PATCH v2 2/6] migration: let MigrationState be a qdev Peter Xu
2017-06-09  7:42   ` Juan Quintela
2017-06-09 13:39   ` Markus Armbruster
2017-06-12  4:46     ` Peter Xu
2017-06-12 16:13       ` Eduardo Habkost
2017-06-13  3:52         ` Peter Xu
2017-06-13 11:27           ` Eduardo Habkost
2017-06-19  9:09         ` Markus Armbruster
2017-06-21  9:28           ` Peter Xu
2017-06-09  3:48 ` [Qemu-devel] [PATCH v2 3/6] migration: move global_state.optional out Peter Xu
2017-06-09  7:43   ` Juan Quintela
2017-06-09 13:40   ` Eduardo Habkost
2017-06-09 17:33     ` Juan Quintela
2017-06-12  8:18     ` Peter Xu
2017-06-13  3:41       ` Peter Xu
2017-06-13 11:16         ` Eduardo Habkost
2017-06-14  2:52           ` Peter Xu
2017-06-16  7:58           ` Peter Xu
2017-06-16 14:34             ` Eduardo Habkost
2017-06-19  6:31               ` Peter Xu
2017-06-09  3:49 ` [Qemu-devel] [PATCH v2 4/6] migration: move only_migratable to MigrationState Peter Xu
2017-06-09  7:43   ` Juan Quintela
2017-06-09  3:49 ` [Qemu-devel] [PATCH v2 5/6] migration: move skip_configuration out Peter Xu
2017-06-09  7:45   ` Juan Quintela
2017-06-09  3:49 ` [Qemu-devel] [PATCH v2 6/6] migration: move skip_section_footers Peter Xu
2017-06-09  7:47   ` Juan Quintela
2017-06-09  8:39     ` Peter Xu
2017-06-09 10:47   ` Eric Blake
2017-06-12  4:37     ` Peter Xu
2017-06-09  7:48 ` [Qemu-devel] [PATCH v2 0/6] migration: objectify MigrationState Juan Quintela
2017-06-09  8:40   ` Peter Xu
2017-06-09 14:02 ` Markus Armbruster
2017-06-09 17:30   ` Juan Quintela [this message]
2017-06-12  7:24   ` Peter Xu
2017-06-19  8:58     ` Markus Armbruster

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=87lgp183wn.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).