From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
peter.maydell@linaro.org, pkrempa@redhat.com, cohuck@redhat.com,
qemu-devel@nongnu.org, armbru@redhat.com, pbonzini@redhat.com,
david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option
Date: Mon, 30 Apr 2018 20:12:09 +0100 [thread overview]
Message-ID: <20180430191208.GA2511@work-vm> (raw)
In-Reply-To: <20180403135210.GT5046@localhost.localdomain>
* Eduardo Habkost (ehabkost@redhat.com) wrote:
> On Tue, Apr 03, 2018 at 03:49:07PM +0200, Igor Mammedov wrote:
> > On Thu, 29 Mar 2018 13:57:54 -0300
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > [...]
> > > > As for the future, I agree it would be much more flexible
> > > > to allow both -preconfig and -incoming at the same time,
> > > > so we could start target with empty CLI, and then feed it
> > > > options from source. It would require audit/refactoring of
> > > > INMIGRATE state and making 'all' current CLI options
> > > > available via QMP interface.
> > > >
> > > > But for now I'd prefer to keep using old way to start target.
> > >
> > > Well, if management software developers tell us that -preconfig
> > > will be already useful without -incoming support, I won't object.
> > As Peter said, mgmt can/will use -preconfig even without -incoming,
> > since it lets deal with initial (source) start-up problem (i.e.
> > avoid restarting QEMU) and lets us make numa configuration work
> > in qemu/libvirt stack without guess work. (that's the end goal of
> > the series)
> >
> > > But it would be very nice for management software if they can
> > > simply assume that -preconfig and -incoming will work together
> > > since the first version. Can we have this as a goal for 2.13?
> > I can't promise to refactor -incoming in near future, as I'm working
> > on ARM cpu-hotplug currently and next in queue is ARM memory hotplug.
> >
> > Peter suggested an alternative idea, to abandon -incoming and
> > enable incoming migration from QMP after all configuration is done.
> > Amount of refactoring need probably would be the same but at least
> > interface and runstate transitions wise it looks cleaner.
>
> Also, support for the "start incoming migration" QMP command
> would be very easy to probe using existing mechanisms. Sounds
> good to me.
You could stick to -incoming defer, that already says that you want
to do an inward migration but doesn't say where from until later.
Note there are some other bits of code scattered around for
checking whether we're in -incoming mode, for example to stop you
do an outwards migration while waiting for an incoming one, or
to stop you doing a migrate-incoming while you're already waiting
for one.
Dave
> --
> Eduardo
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-04-30 19:12 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 13:11 [Qemu-devel] [PATCH v4 0/9] enable numa configuration before machine_init() from QMP Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 1/9] numa: postpone options post-processing till machine_run_board_init() Igor Mammedov
2018-03-23 20:34 ` Eduardo Habkost
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 2/9] numa: split out NumaOptions parsing into parse_NumaOptions() Igor Mammedov
2018-03-23 20:42 ` Eduardo Habkost
2018-03-23 20:49 ` Eric Blake
2018-03-23 21:09 ` Eduardo Habkost
2018-03-26 8:38 ` Laurent Vivier
2018-03-26 14:33 ` Eric Blake
2018-03-27 13:08 ` Igor Mammedov
2018-03-28 18:54 ` Eduardo Habkost
2018-03-29 13:05 ` Igor Mammedov
2018-03-29 16:31 ` Eduardo Habkost
2018-04-03 13:55 ` Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option Igor Mammedov
2018-03-23 21:02 ` Eric Blake
2018-03-23 21:05 ` Eduardo Habkost
2018-03-23 21:25 ` Eduardo Habkost
2018-03-27 15:05 ` Igor Mammedov
2018-03-28 11:48 ` Igor Mammedov
2018-03-28 19:21 ` Eduardo Habkost
2018-03-29 11:43 ` Igor Mammedov
2018-03-29 16:24 ` Eduardo Habkost
2018-04-03 14:32 ` Igor Mammedov
2018-04-03 15:31 ` Eduardo Habkost
2018-04-04 8:51 ` Igor Mammedov
2018-03-28 19:17 ` Eduardo Habkost
2018-03-29 13:01 ` Igor Mammedov
2018-03-29 16:57 ` Eduardo Habkost
2018-04-03 10:41 ` Peter Krempa
2018-04-03 13:49 ` Igor Mammedov
2018-04-03 13:52 ` Eduardo Habkost
2018-04-30 19:12 ` Dr. David Alan Gilbert [this message]
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 4/9] hmp: disable monitor in preconfig state Igor Mammedov
2018-03-23 21:27 ` Eduardo Habkost
2018-03-28 11:16 ` Igor Mammedov
2018-03-28 18:55 ` Eduardo Habkost
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 5/9] qapi: introduce new cmd option "allowed-in-preconfig" Igor Mammedov
2018-03-23 21:11 ` Eric Blake
2018-03-28 15:23 ` Igor Mammedov
2018-03-23 21:28 ` Eduardo Habkost
2018-03-28 12:29 ` Igor Mammedov
2018-03-28 19:30 ` Eduardo Habkost
2018-03-29 9:53 ` Igor Mammedov
2018-03-29 12:21 ` Eduardo Habkost
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 6/9] tests: extend qmp test with preconfig checks Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 7/9] qmp: permit query-hotpluggable-cpus in preconfig state Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 8/9] qmp: add set-numa-node command Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 9/9] tests: functional tests for QMP command set-numa-node Igor Mammedov
2018-04-17 14:13 ` [Qemu-devel] [PATCH v4 0/9] enable numa configuration before machine_init() from QMP Markus Armbruster
2018-04-17 14:27 ` Eduardo Habkost
2018-04-17 15:41 ` Igor Mammedov
2018-04-17 20:41 ` Eduardo Habkost
2018-04-18 7:08 ` Markus Armbruster
2018-04-19 8:00 ` Igor Mammedov
2018-04-19 19:42 ` Eduardo Habkost
2018-04-20 6:31 ` Markus Armbruster
2018-04-23 9:50 ` Igor Mammedov
2018-04-23 13:05 ` Eduardo Habkost
2018-04-23 16:55 ` Igor Mammedov
2018-04-23 20:45 ` Eduardo Habkost
2018-04-26 14:39 ` Igor Mammedov
2018-04-26 14:55 ` Eric Blake
2018-04-27 12:19 ` Igor Mammedov
2018-04-20 5:23 ` David Gibson
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=20180430191208.GA2511@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pkrempa@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 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.