From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dKyQK-0004NK-T8 for qemu-devel@nongnu.org; Tue, 13 Jun 2017 22:52:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dKyQH-0005w4-Ql for qemu-devel@nongnu.org; Tue, 13 Jun 2017 22:52:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42854) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dKyQH-0005vS-Iw for qemu-devel@nongnu.org; Tue, 13 Jun 2017 22:52:45 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 19F0080483 for ; Wed, 14 Jun 2017 02:52:43 +0000 (UTC) Date: Wed, 14 Jun 2017 10:52:37 +0800 From: Peter Xu Message-ID: <20170614025237.GF11751@pxdev.xzpeter.org> References: <1496980142-8986-1-git-send-email-peterx@redhat.com> <1496980142-8986-4-git-send-email-peterx@redhat.com> <20170609134010.GK22043@thinpad.lan.raisama.net> <20170612081356.GD12928@pxdev.xzpeter.org> <20170613034102.GA11751@pxdev.xzpeter.org> <20170613111635.GU5016@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170613111635.GU5016@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [PATCH v2 3/6] migration: move global_state.optional out List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, Laurent Vivier , Markus Armbruster , "Dr . David Alan Gilbert" , Juan Quintela On Tue, Jun 13, 2017 at 08:16:35AM -0300, Eduardo Habkost wrote: > On Tue, Jun 13, 2017 at 11:41:02AM +0800, Peter Xu wrote: > > On Mon, Jun 12, 2017 at 04:18:06PM +0800, Peter Xu wrote: > > > On Fri, Jun 09, 2017 at 10:40:10AM -0300, Eduardo Habkost wrote: > > > > On Fri, Jun 09, 2017 at 11:48:59AM +0800, Peter Xu wrote: > > > > > Put it into MigrationState then we can use the properties to specify > > > > > whether to enable storing global state. > > > > > > > > > > Removing global_state_set_optional() since now we can use HW_COMPAT_2_3 > > > > > for x86/power in general, and the register_compat_prop() for xen_init(). > > > > > > > > > > Signed-off-by: Peter Xu > [...] > > > > > diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c > > > > > index 0bed577..8240d50 100644 > > > > > --- a/hw/xen/xen-common.c > > > > > +++ b/hw/xen/xen-common.c > > > > > @@ -138,7 +138,13 @@ static int xen_init(MachineState *ms) > > > > > } > > > > > qemu_add_vm_change_state_handler(xen_change_state_handler, NULL); > > > > > > > > > > - global_state_set_optional(); > > > > > + /* > > > > > + * TODO: make sure global MigrationState has not yet been created > > > > > + * (otherwise the compat trick won't work). For now we are in > > > > > + * configure_accelerator() so we are mostly good. Better to > > > > > + * confirm that in the future. > > > > > + */ > > > > > > > > So, this makes accelerator initialization very sensitive to > > > > ordering. > > > > > > > > > + register_compat_prop("migration", "store-global-state", "off"); > > > > > > > > It's already hard to track down machine-type stuff that is > > > > initialized at machine->init() time but it's not introspectable, > > > > let's not do the same mistake with accelerators. > > > > > > > > Can't this be solved by a AcceleratorClass::global_props field, > > > > so we are sure there's a single place in the code where globals > > > > are registered? (Currently, they are all registered by the few > > > > lines around the machine_register_compat_props() call in main()). > > > > > > > > I think I see other use cases for a new > > > > AcceleratorClass::global_props field. e.g.: replacing > > > > kvm_default_props and tcg_default_props in target/i386/cpu.c. > > > > > > Hmm, this sounds nice. Then we can also get rid of the TODO above. > > > > > > Thanks for your suggestion and review! I'll see whether I can writeup > > > something as RFC for this. > > > > After a second thought, I see these requirements are slightly > > different. > > > > For xen_init(), AccelClass::global_props may help since that's mainly > > properties to be setup for TYPE_MIGRATION (let's assume it's okay that > > MigrationState can be a QDev). > > > > For kvm_default_props and tcg_default_props, AccelClass::global_props > > may not help since they are setting up properties for TYPE_CPU, and > > TYPE_CPU cannot really use global property features yet. :( > > TYPE_CPU can use global properties, for sure. TYPE_CPU is a > TYPE_DEVICE subclass, and -cpu is implemented internally using > global properties. Indeed. :) Thanks, -- Peter Xu