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 <pet...@redhat.com>
> > > ---
> > > hw/i386/pc_piix.c | 1 -
> > > hw/ppc/spapr.c | 1 -
> > > hw/xen/xen-common.c | 8 +++++++-
> > > include/hw/compat.h | 4 ++++
> > > include/migration/migration.h | 7 ++++++-
> > > migration/migration.c | 24 ++++++++++++++++--------
> > > 6 files changed, 33 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > > index 2234bd0..c83cec5 100644
> > > --- a/hw/i386/pc_piix.c
> > > +++ b/hw/i386/pc_piix.c
> > > @@ -317,7 +317,6 @@ static void pc_compat_2_3(MachineState *machine)
> > > if (kvm_enabled()) {
> > > pcms->smm = ON_OFF_AUTO_OFF;
> > > }
> > > - global_state_set_optional();
> > > savevm_skip_configuration();
> > > }
> > >
> > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > index ab3aab1..3e78bb9 100644
> > > --- a/hw/ppc/spapr.c
> > > +++ b/hw/ppc/spapr.c
> > > @@ -3593,7 +3593,6 @@ static void
> > > spapr_machine_2_3_instance_options(MachineState *machine)
> > > {
> > > spapr_machine_2_4_instance_options(machine);
> > > savevm_skip_section_footers();
> > > - global_state_set_optional();
> > > savevm_skip_configuration();
> > > }
> >
> > This is a good thing: makes the migration behavior of the
> > machine-types introspectable in compat_props.
> >
> > I suggest moving this part (and all the rest except the new
> > register_compat_prop() call below) to a separate patch, because
> > it is an improvement on its own.
>
> Sure.
>
> >
> > >
> > > 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. :(
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
