Eduardo Habkost <ehabk...@redhat.com> wrote:
D> 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.
>
>>
>> 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.
That is the kind of discussion that I wanted to start. Thanks.
For the migration point of view, we don't care *how* or *where* it is
implemented, just that it is easy to add new properties (call it
whatever name that you want).
And yes, making xen/kvm/tcg use QOM like everything else looks like a
good idea to me.
Later, Juan.
