From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3MJP-0002OG-Fh for qemu-devel@nongnu.org; Tue, 03 Apr 2018 09:49:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3MJL-0003o6-Ec for qemu-devel@nongnu.org; Tue, 03 Apr 2018 09:49:23 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39840 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f3MJL-0003nf-9I for qemu-devel@nongnu.org; Tue, 03 Apr 2018 09:49:19 -0400 Date: Tue, 3 Apr 2018 15:49:07 +0200 From: Igor Mammedov Message-ID: <20180403154907.2231a5d7@redhat.com> In-Reply-To: <20180329165754.GZ5046@localhost.localdomain> References: <1520860275-101576-1-git-send-email-imammedo@redhat.com> <1520860275-101576-4-git-send-email-imammedo@redhat.com> <20180323212508.GF28161@localhost.localdomain> <20180327170541.295fc29a@redhat.com> <20180328191732.GQ5046@localhost.localdomain> <20180329150112.2e1d3030@redhat.com> <20180329165754.GZ5046@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: 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 On Thu, 29 Mar 2018 13:57:54 -0300 Eduardo Habkost 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. [...]