qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 3/6] migration: move global_state.optional ou


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v2 3/6] migration: move global_state.optional out
Date: Tue, 13 Jun 2017 08:16:35 -0300
User-agent: Mutt/1.8.0 (2017-02-23)

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 <address@hidden>
[...]
> > > > 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.

> 
> If finally we can have a new way (e.g., as you suggested in the other
> thread, using a new INTERFACE to show that one QObject supports global
> qdev properties) to allow TYPE_CPU to use global properties, then
> these two requirements can merge. Otherwise IMHO we may still need to
> keep the *_default_props in CPU codes.
> 
> Thanks,
> 
> -- 
> Peter Xu

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]