[Qemu-devel] [PATCH] q35: Remove old machine versions

[Qemu-devel] [PATCH] q35: Remove old machine versions

[Eduardo Habkost]

Migration with q35 was not possible before commit
04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
an ich9-ahci device, that was marked as unmigratable. So all q35 machines
before pc-q35-2.4 were unmigratable, and there's no point in keeping
compatibility code for them.

Remove all old pc-q35 machine classes and keep only pc-q35-2.4.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 hw/i386/pc_q35.c | 153 -------------------------------------------------------
 1 file changed, 153 deletions(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 4ee653e..e482f2f 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -272,60 +272,6 @@ static void pc_q35_init(MachineState *machine)
     }
 }
 
-static void pc_compat_2_3(MachineState *machine)
-{
-    PCMachineState *pcms = PC_MACHINE(machine);
-    savevm_skip_section_footers();
-    if (kvm_enabled()) {
-        pcms->smm = ON_OFF_AUTO_OFF;
-    }
-    global_state_set_optional();
-    savevm_skip_configuration();
-}
-
-static void pc_compat_2_2(MachineState *machine)
-{
-    pc_compat_2_3(machine);
-    machine->suppress_vmdesc = true;
-}
-
-static void pc_compat_2_1(MachineState *machine)
-{
-    PCMachineState *pcms = PC_MACHINE(machine);
-
-    pc_compat_2_2(machine);
-    pcms->enforce_aligned_dimm = false;
-    x86_cpu_compat_kvm_no_autodisable(FEAT_8000_0001_ECX, CPUID_EXT3_SVM);
-}
-
-static void pc_compat_2_0(MachineState *machine)
-{
-    pc_compat_2_1(machine);
-}
-
-static void pc_compat_1_7(MachineState *machine)
-{
-    pc_compat_2_0(machine);
-    option_rom_has_mr = true;
-    x86_cpu_compat_kvm_no_autoenable(FEAT_1_ECX, CPUID_EXT_X2APIC);
-}
-
-static void pc_compat_1_6(MachineState *machine)
-{
-    pc_compat_1_7(machine);
-    rom_file_has_mr = false;
-}
-
-static void pc_compat_1_5(MachineState *machine)
-{
-    pc_compat_1_6(machine);
-}
-
-static void pc_compat_1_4(MachineState *machine)
-{
-    pc_compat_1_5(machine);
-}
-
 #define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
     static void pc_init_##suffix(MachineState *machine) \
     { \
@@ -358,102 +304,3 @@ static void pc_q35_2_4_machine_options(MachineClass *m)
 
 DEFINE_Q35_MACHINE(v2_4, "pc-q35-2.4", NULL,
                    pc_q35_2_4_machine_options);
-
-
-static void pc_q35_2_3_machine_options(MachineClass *m)
-{
-    pc_q35_2_4_machine_options(m);
-    m->no_floppy = 0;
-    m->no_tco = 1;
-    m->alias = NULL;
-    SET_MACHINE_COMPAT(m, PC_COMPAT_2_3);
-}
-
-DEFINE_Q35_MACHINE(v2_3, "pc-q35-2.3", pc_compat_2_3,
-                   pc_q35_2_3_machine_options);
-
-
-static void pc_q35_2_2_machine_options(MachineClass *m)
-{
-    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-    pc_q35_2_3_machine_options(m);
-    SET_MACHINE_COMPAT(m, PC_COMPAT_2_2);
-    pcmc->rsdp_in_ram = false;
-}
-
-DEFINE_Q35_MACHINE(v2_2, "pc-q35-2.2", pc_compat_2_2,
-                   pc_q35_2_2_machine_options);
-
-
-static void pc_q35_2_1_machine_options(MachineClass *m)
-{
-    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-    pc_q35_2_2_machine_options(m);
-    m->default_display = NULL;
-    SET_MACHINE_COMPAT(m, PC_COMPAT_2_1);
-    pcmc->smbios_uuid_encoded = false;
-}
-
-DEFINE_Q35_MACHINE(v2_1, "pc-q35-2.1", pc_compat_2_1,
-                   pc_q35_2_1_machine_options);
-
-
-static void pc_q35_2_0_machine_options(MachineClass *m)
-{
-    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-    pc_q35_2_1_machine_options(m);
-    SET_MACHINE_COMPAT(m, PC_COMPAT_2_0);
-    pcmc->has_reserved_memory = false;
-    pcmc->smbios_legacy_mode = true;
-    pcmc->acpi_data_size = 0x10000;
-}
-
-DEFINE_Q35_MACHINE(v2_0, "pc-q35-2.0", pc_compat_2_0,
-                   pc_q35_2_0_machine_options);
-
-
-static void pc_q35_1_7_machine_options(MachineClass *m)
-{
-    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-    pc_q35_2_0_machine_options(m);
-    m->default_machine_opts = NULL;
-    SET_MACHINE_COMPAT(m, PC_COMPAT_1_7);
-    pcmc->smbios_defaults = false;
-    pcmc->gigabyte_align = false;
-}
-
-DEFINE_Q35_MACHINE(v1_7, "pc-q35-1.7", pc_compat_1_7,
-                   pc_q35_1_7_machine_options);
-
-
-static void pc_q35_1_6_machine_options(MachineClass *m)
-{
-    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-    pc_q35_machine_options(m);
-    SET_MACHINE_COMPAT(m, PC_COMPAT_1_6);
-    pcmc->has_acpi_build = false;
-}
-
-DEFINE_Q35_MACHINE(v1_6, "pc-q35-1.6", pc_compat_1_6,
-                   pc_q35_1_6_machine_options);
-
-
-static void pc_q35_1_5_machine_options(MachineClass *m)
-{
-    pc_q35_1_6_machine_options(m);
-    SET_MACHINE_COMPAT(m, PC_COMPAT_1_5);
-}
-
-DEFINE_Q35_MACHINE(v1_5, "pc-q35-1.5", pc_compat_1_5,
-                   pc_q35_1_5_machine_options);
-
-
-static void pc_q35_1_4_machine_options(MachineClass *m)
-{
-    pc_q35_1_5_machine_options(m);
-    m->hot_add_cpu = NULL;
-    SET_MACHINE_COMPAT(m, PC_COMPAT_1_4);
-}
-
-DEFINE_Q35_MACHINE(v1_4, "pc-q35-1.4", pc_compat_1_4,
-                   pc_q35_1_4_machine_options);
-- 
2.1.0

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Dr. David Alan Gilbert]

* Eduardo Habkost (ehabkost@redhat.com) wrote:
> Migration with q35 was not possible before commit
> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> compatibility code for them.
> 
> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.

But doesn't that mean that anyone who has a machine configured with one
of those machine types will suddenly find it wont start?

Dave

> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  hw/i386/pc_q35.c | 153 -------------------------------------------------------
>  1 file changed, 153 deletions(-)
> 
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 4ee653e..e482f2f 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -272,60 +272,6 @@ static void pc_q35_init(MachineState *machine)
>      }
>  }
>  
> -static void pc_compat_2_3(MachineState *machine)
> -{
> -    PCMachineState *pcms = PC_MACHINE(machine);
> -    savevm_skip_section_footers();
> -    if (kvm_enabled()) {
> -        pcms->smm = ON_OFF_AUTO_OFF;
> -    }
> -    global_state_set_optional();
> -    savevm_skip_configuration();
> -}
> -
> -static void pc_compat_2_2(MachineState *machine)
> -{
> -    pc_compat_2_3(machine);
> -    machine->suppress_vmdesc = true;
> -}
> -
> -static void pc_compat_2_1(MachineState *machine)
> -{
> -    PCMachineState *pcms = PC_MACHINE(machine);
> -
> -    pc_compat_2_2(machine);
> -    pcms->enforce_aligned_dimm = false;
> -    x86_cpu_compat_kvm_no_autodisable(FEAT_8000_0001_ECX, CPUID_EXT3_SVM);
> -}
> -
> -static void pc_compat_2_0(MachineState *machine)
> -{
> -    pc_compat_2_1(machine);
> -}
> -
> -static void pc_compat_1_7(MachineState *machine)
> -{
> -    pc_compat_2_0(machine);
> -    option_rom_has_mr = true;
> -    x86_cpu_compat_kvm_no_autoenable(FEAT_1_ECX, CPUID_EXT_X2APIC);
> -}
> -
> -static void pc_compat_1_6(MachineState *machine)
> -{
> -    pc_compat_1_7(machine);
> -    rom_file_has_mr = false;
> -}
> -
> -static void pc_compat_1_5(MachineState *machine)
> -{
> -    pc_compat_1_6(machine);
> -}
> -
> -static void pc_compat_1_4(MachineState *machine)
> -{
> -    pc_compat_1_5(machine);
> -}
> -
>  #define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
>      static void pc_init_##suffix(MachineState *machine) \
>      { \
> @@ -358,102 +304,3 @@ static void pc_q35_2_4_machine_options(MachineClass *m)
>  
>  DEFINE_Q35_MACHINE(v2_4, "pc-q35-2.4", NULL,
>                     pc_q35_2_4_machine_options);
> -
> -
> -static void pc_q35_2_3_machine_options(MachineClass *m)
> -{
> -    pc_q35_2_4_machine_options(m);
> -    m->no_floppy = 0;
> -    m->no_tco = 1;
> -    m->alias = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_3);
> -}
> -
> -DEFINE_Q35_MACHINE(v2_3, "pc-q35-2.3", pc_compat_2_3,
> -                   pc_q35_2_3_machine_options);
> -
> -
> -static void pc_q35_2_2_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_3_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_2);
> -    pcmc->rsdp_in_ram = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_2, "pc-q35-2.2", pc_compat_2_2,
> -                   pc_q35_2_2_machine_options);
> -
> -
> -static void pc_q35_2_1_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_2_machine_options(m);
> -    m->default_display = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_1);
> -    pcmc->smbios_uuid_encoded = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_1, "pc-q35-2.1", pc_compat_2_1,
> -                   pc_q35_2_1_machine_options);
> -
> -
> -static void pc_q35_2_0_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_1_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_0);
> -    pcmc->has_reserved_memory = false;
> -    pcmc->smbios_legacy_mode = true;
> -    pcmc->acpi_data_size = 0x10000;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_0, "pc-q35-2.0", pc_compat_2_0,
> -                   pc_q35_2_0_machine_options);
> -
> -
> -static void pc_q35_1_7_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_0_machine_options(m);
> -    m->default_machine_opts = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_7);
> -    pcmc->smbios_defaults = false;
> -    pcmc->gigabyte_align = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v1_7, "pc-q35-1.7", pc_compat_1_7,
> -                   pc_q35_1_7_machine_options);
> -
> -
> -static void pc_q35_1_6_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_6);
> -    pcmc->has_acpi_build = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v1_6, "pc-q35-1.6", pc_compat_1_6,
> -                   pc_q35_1_6_machine_options);
> -
> -
> -static void pc_q35_1_5_machine_options(MachineClass *m)
> -{
> -    pc_q35_1_6_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_5);
> -}
> -
> -DEFINE_Q35_MACHINE(v1_5, "pc-q35-1.5", pc_compat_1_5,
> -                   pc_q35_1_5_machine_options);
> -
> -
> -static void pc_q35_1_4_machine_options(MachineClass *m)
> -{
> -    pc_q35_1_5_machine_options(m);
> -    m->hot_add_cpu = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_4);
> -}
> -
> -DEFINE_Q35_MACHINE(v1_4, "pc-q35-1.4", pc_compat_1_4,
> -                   pc_q35_1_4_machine_options);
> -- 
> 2.1.0
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Eduardo Habkost]

On Wed, Aug 19, 2015 at 10:55:26AM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> > Migration with q35 was not possible before commit
> > 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> > an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > compatibility code for them.
> > 
> > Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> 
> But doesn't that mean that anyone who has a machine configured with one
> of those machine types will suddenly find it wont start?

Yes, and they will have to update their configuration to use pc-q35-2.4
or newer.

-- 
Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Michael S. Tsirkin]

On Wed, Aug 19, 2015 at 09:30:20AM -0700, Eduardo Habkost wrote:
> On Wed, Aug 19, 2015 at 10:55:26AM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Habkost (ehabkost@redhat.com) wrote:
> > > Migration with q35 was not possible before commit
> > > 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> > > an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > > before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > > compatibility code for them.
> > > 
> > > Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > 
> > But doesn't that mean that anyone who has a machine configured with one
> > of those machine types will suddenly find it wont start?
> 
> Yes, and they will have to update their configuration to use pc-q35-2.4
> or newer.

That seems easily avoidable: just make pc-q35-X alias pc-q35-2.4 for X < 2.4.

> -- 
> Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[John Snow]

On 08/25/2015 05:42 AM, Michael S. Tsirkin wrote:
> On Wed, Aug 19, 2015 at 09:30:20AM -0700, Eduardo Habkost wrote:
>> On Wed, Aug 19, 2015 at 10:55:26AM +0100, Dr. David Alan Gilbert wrote:
>>> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>>>> Migration with q35 was not possible before commit
>>>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
>>>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
>>>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
>>>> compatibility code for them.
>>>>
>>>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
>>>
>>> But doesn't that mean that anyone who has a machine configured with one
>>> of those machine types will suddenly find it wont start?
>>
>> Yes, and they will have to update their configuration to use pc-q35-2.4
>> or newer.
> 
> That seems easily avoidable: just make pc-q35-X alias pc-q35-2.4 for X < 2.4.
> 

Both Marcel and Markus would prefer it to fail outright instead of
silently perform magic, in response to my suggesting the same thing.

>> -- 
>> Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Michael S. Tsirkin]

On Tue, Aug 25, 2015 at 12:16:04PM -0400, John Snow wrote:
> 
> 
> On 08/25/2015 05:42 AM, Michael S. Tsirkin wrote:
> > On Wed, Aug 19, 2015 at 09:30:20AM -0700, Eduardo Habkost wrote:
> >> On Wed, Aug 19, 2015 at 10:55:26AM +0100, Dr. David Alan Gilbert wrote:
> >>> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> >>>> Migration with q35 was not possible before commit
> >>>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> >>>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> >>>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> >>>> compatibility code for them.
> >>>>
> >>>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> >>>
> >>> But doesn't that mean that anyone who has a machine configured with one
> >>> of those machine types will suddenly find it wont start?
> >>
> >> Yes, and they will have to update their configuration to use pc-q35-2.4
> >> or newer.
> > 
> > That seems easily avoidable: just make pc-q35-X alias pc-q35-2.4 for X < 2.4.
> > 
> 
> Both Marcel and Markus would prefer it to fail outright instead of
> silently perform magic, in response to my suggesting the same thing.

I think it's result of a misunderstanding - let's discuss some more.

> >> -- 
> >> Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[John Snow]

On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>> Migration with q35 was not possible before commit
>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
>> compatibility code for them.
>>
>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> 
> But doesn't that mean that anyone who has a machine configured with one
> of those machine types will suddenly find it wont start?
> 
> Dave
> 

To some extent, all versions of this board prior to 2.4 should be
considered unsupported and we should discourage their use anyway.

If you really want, I suppose we could just alias them to 2.4 ...

>>
>> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
>> ---
>>  hw/i386/pc_q35.c | 153 -------------------------------------------------------
>>  1 file changed, 153 deletions(-)
>>
>> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>> index 4ee653e..e482f2f 100644
>> --- a/hw/i386/pc_q35.c
>> +++ b/hw/i386/pc_q35.c
>> @@ -272,60 +272,6 @@ static void pc_q35_init(MachineState *machine)
>>      }
>>  }
>>  
>> -static void pc_compat_2_3(MachineState *machine)
>> -{
>> -    PCMachineState *pcms = PC_MACHINE(machine);
>> -    savevm_skip_section_footers();
>> -    if (kvm_enabled()) {
>> -        pcms->smm = ON_OFF_AUTO_OFF;
>> -    }
>> -    global_state_set_optional();
>> -    savevm_skip_configuration();
>> -}
>> -
>> -static void pc_compat_2_2(MachineState *machine)
>> -{
>> -    pc_compat_2_3(machine);
>> -    machine->suppress_vmdesc = true;
>> -}
>> -
>> -static void pc_compat_2_1(MachineState *machine)
>> -{
>> -    PCMachineState *pcms = PC_MACHINE(machine);
>> -
>> -    pc_compat_2_2(machine);
>> -    pcms->enforce_aligned_dimm = false;
>> -    x86_cpu_compat_kvm_no_autodisable(FEAT_8000_0001_ECX, CPUID_EXT3_SVM);
>> -}
>> -
>> -static void pc_compat_2_0(MachineState *machine)
>> -{
>> -    pc_compat_2_1(machine);
>> -}
>> -
>> -static void pc_compat_1_7(MachineState *machine)
>> -{
>> -    pc_compat_2_0(machine);
>> -    option_rom_has_mr = true;
>> -    x86_cpu_compat_kvm_no_autoenable(FEAT_1_ECX, CPUID_EXT_X2APIC);
>> -}
>> -
>> -static void pc_compat_1_6(MachineState *machine)
>> -{
>> -    pc_compat_1_7(machine);
>> -    rom_file_has_mr = false;
>> -}
>> -
>> -static void pc_compat_1_5(MachineState *machine)
>> -{
>> -    pc_compat_1_6(machine);
>> -}
>> -
>> -static void pc_compat_1_4(MachineState *machine)
>> -{
>> -    pc_compat_1_5(machine);
>> -}
>> -
>>  #define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
>>      static void pc_init_##suffix(MachineState *machine) \
>>      { \
>> @@ -358,102 +304,3 @@ static void pc_q35_2_4_machine_options(MachineClass *m)
>>  
>>  DEFINE_Q35_MACHINE(v2_4, "pc-q35-2.4", NULL,
>>                     pc_q35_2_4_machine_options);
>> -
>> -
>> -static void pc_q35_2_3_machine_options(MachineClass *m)
>> -{
>> -    pc_q35_2_4_machine_options(m);
>> -    m->no_floppy = 0;
>> -    m->no_tco = 1;
>> -    m->alias = NULL;
>> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_3);
>> -}
>> -
>> -DEFINE_Q35_MACHINE(v2_3, "pc-q35-2.3", pc_compat_2_3,
>> -                   pc_q35_2_3_machine_options);
>> -
>> -
>> -static void pc_q35_2_2_machine_options(MachineClass *m)
>> -{
>> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>> -    pc_q35_2_3_machine_options(m);
>> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_2);
>> -    pcmc->rsdp_in_ram = false;
>> -}
>> -
>> -DEFINE_Q35_MACHINE(v2_2, "pc-q35-2.2", pc_compat_2_2,
>> -                   pc_q35_2_2_machine_options);
>> -
>> -
>> -static void pc_q35_2_1_machine_options(MachineClass *m)
>> -{
>> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>> -    pc_q35_2_2_machine_options(m);
>> -    m->default_display = NULL;
>> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_1);
>> -    pcmc->smbios_uuid_encoded = false;
>> -}
>> -
>> -DEFINE_Q35_MACHINE(v2_1, "pc-q35-2.1", pc_compat_2_1,
>> -                   pc_q35_2_1_machine_options);
>> -
>> -
>> -static void pc_q35_2_0_machine_options(MachineClass *m)
>> -{
>> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>> -    pc_q35_2_1_machine_options(m);
>> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_0);
>> -    pcmc->has_reserved_memory = false;
>> -    pcmc->smbios_legacy_mode = true;
>> -    pcmc->acpi_data_size = 0x10000;
>> -}
>> -
>> -DEFINE_Q35_MACHINE(v2_0, "pc-q35-2.0", pc_compat_2_0,
>> -                   pc_q35_2_0_machine_options);
>> -
>> -
>> -static void pc_q35_1_7_machine_options(MachineClass *m)
>> -{
>> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>> -    pc_q35_2_0_machine_options(m);
>> -    m->default_machine_opts = NULL;
>> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_7);
>> -    pcmc->smbios_defaults = false;
>> -    pcmc->gigabyte_align = false;
>> -}
>> -
>> -DEFINE_Q35_MACHINE(v1_7, "pc-q35-1.7", pc_compat_1_7,
>> -                   pc_q35_1_7_machine_options);
>> -
>> -
>> -static void pc_q35_1_6_machine_options(MachineClass *m)
>> -{
>> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>> -    pc_q35_machine_options(m);
>> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_6);
>> -    pcmc->has_acpi_build = false;
>> -}
>> -
>> -DEFINE_Q35_MACHINE(v1_6, "pc-q35-1.6", pc_compat_1_6,
>> -                   pc_q35_1_6_machine_options);
>> -
>> -
>> -static void pc_q35_1_5_machine_options(MachineClass *m)
>> -{
>> -    pc_q35_1_6_machine_options(m);
>> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_5);
>> -}
>> -
>> -DEFINE_Q35_MACHINE(v1_5, "pc-q35-1.5", pc_compat_1_5,
>> -                   pc_q35_1_5_machine_options);
>> -
>> -
>> -static void pc_q35_1_4_machine_options(MachineClass *m)
>> -{
>> -    pc_q35_1_5_machine_options(m);
>> -    m->hot_add_cpu = NULL;
>> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_4);
>> -}
>> -
>> -DEFINE_Q35_MACHINE(v1_4, "pc-q35-1.4", pc_compat_1_4,
>> -                   pc_q35_1_4_machine_options);
>> -- 
>> 2.1.0
>>
>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Markus Armbruster]

John Snow <jsnow@redhat.com> writes:

> On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
>> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>>> Migration with q35 was not possible before commit
>>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
>>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
>>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
>>> compatibility code for them.
>>>
>>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
>> 
>> But doesn't that mean that anyone who has a machine configured with one
>> of those machine types will suddenly find it wont start?
>> 
>> Dave
>> 
>
> To some extent, all versions of this board prior to 2.4 should be
> considered unsupported and we should discourage their use anyway.
>
> If you really want, I suppose we could just alias them to 2.4 ...

I'd very much prefer an honest "won't start" over a silent change of the
machine type.

If we really want to bend over backwards for existing uses of these
machine types, we could make them error out with "use pc-q35-2.5
instead".  Since I don't think they exist outside testing, I wouldn't
bother.

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[John Snow]

On 08/24/2015 02:54 AM, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
> 
>> On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
>>> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>>>> Migration with q35 was not possible before commit
>>>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
>>>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
>>>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
>>>> compatibility code for them.
>>>>
>>>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
>>>
>>> But doesn't that mean that anyone who has a machine configured with one
>>> of those machine types will suddenly find it wont start?
>>>
>>> Dave
>>>
>>
>> To some extent, all versions of this board prior to 2.4 should be
>> considered unsupported and we should discourage their use anyway.
>>
>> If you really want, I suppose we could just alias them to 2.4 ...
> 
> I'd very much prefer an honest "won't start" over a silent change of the
> machine type.
> 
> If we really want to bend over backwards for existing uses of these
> machine types, we could make them error out with "use pc-q35-2.5
> instead".  Since I don't think they exist outside testing, I wouldn't
> bother.
> 

I like the discrete error idea, but I'm not sure how much clutter it'd
require to code in. If it's not a lot, it would be nice.

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Marcel Apfelbaum]

On 08/24/2015 12:54 PM, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
>
>> On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
>>> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>>>> Migration with q35 was not possible before commit
>>>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
>>>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
>>>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
>>>> compatibility code for them.
>>>>
>>>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
>>>
>>> But doesn't that mean that anyone who has a machine configured with one
>>> of those machine types will suddenly find it wont start?
>>>
>>> Dave
>>>
>>
>> To some extent, all versions of this board prior to 2.4 should be
>> considered unsupported and we should discourage their use anyway.
>>
>> If you really want, I suppose we could just alias them to 2.4 ...
>
> I'd very much prefer an honest "won't start" over a silent change of the
> machine type.
+1

Thanks,
Marcel

>
> If we really want to bend over backwards for existing uses of these
> machine types, we could make them error out with "use pc-q35-2.5
> instead".  Since I don't think they exist outside testing, I wouldn't
> bother.
>

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Daniel P. Berrange]

On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
> 
> > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> >> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> >>> Migration with q35 was not possible before commit
> >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> >>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> >>> compatibility code for them.
> >>>
> >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> >> 
> >> But doesn't that mean that anyone who has a machine configured with one
> >> of those machine types will suddenly find it wont start?
> >> 
> >> Dave
> >> 
> >
> > To some extent, all versions of this board prior to 2.4 should be
> > considered unsupported and we should discourage their use anyway.
> >
> > If you really want, I suppose we could just alias them to 2.4 ...
> 
> I'd very much prefer an honest "won't start" over a silent change of the
> machine type.
> 
> If we really want to bend over backwards for existing uses of these
> machine types, we could make them error out with "use pc-q35-2.5
> instead".  Since I don't think they exist outside testing, I wouldn't
> bother.

Agreed, we should be reporting a hard error for any machine types we
have deleted. Or if we care about smooth upgrade path then we shouldn't
be deleting them in the first place. Silently changing the user's
requested machine type into a different machine type is violating
the semantics of stable machine types.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Michael S. Tsirkin]

On Tue, Aug 25, 2015 at 05:21:16PM +0100, Daniel P. Berrange wrote:
> On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
> > John Snow <jsnow@redhat.com> writes:
> > 
> > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> > >> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> > >>> Migration with q35 was not possible before commit
> > >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> > >>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > >>> compatibility code for them.
> > >>>
> > >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > >> 
> > >> But doesn't that mean that anyone who has a machine configured with one
> > >> of those machine types will suddenly find it wont start?
> > >> 
> > >> Dave
> > >> 
> > >
> > > To some extent, all versions of this board prior to 2.4 should be
> > > considered unsupported and we should discourage their use anyway.
> > >
> > > If you really want, I suppose we could just alias them to 2.4 ...
> > 
> > I'd very much prefer an honest "won't start" over a silent change of the
> > machine type.
> > 
> > If we really want to bend over backwards for existing uses of these
> > machine types, we could make them error out with "use pc-q35-2.5
> > instead".  Since I don't think they exist outside testing, I wouldn't
> > bother.
> 
> Agreed, we should be reporting a hard error for any machine types we
> have deleted. Or if we care about smooth upgrade path then we shouldn't
> be deleting them in the first place. Silently changing the user's
> requested machine type into a different machine type is violating
> the semantics of stable machine types.
> 
> Regards,
> Daniel

The reason we are deleting them is because changes in behaviour are not
user visible implementation details, and live migration is unsupported.

In other words 2.4 is identical to <2.3 in all respect except live
migration, which didn't work in <2.3 and works in 2.4, that's why
aliasing them is fine.

But if people really want "2.3 = 2.4 that does not migrate" we could
do that with very little code, too.



> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Daniel P. Berrange]

On Thu, Aug 27, 2015 at 01:50:10PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 25, 2015 at 05:21:16PM +0100, Daniel P. Berrange wrote:
> > On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
> > > John Snow <jsnow@redhat.com> writes:
> > > 
> > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> > > >> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> > > >>> Migration with q35 was not possible before commit
> > > >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> > > >>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > > >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > > >>> compatibility code for them.
> > > >>>
> > > >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > > >> 
> > > >> But doesn't that mean that anyone who has a machine configured with one
> > > >> of those machine types will suddenly find it wont start?
> > > >> 
> > > >> Dave
> > > >> 
> > > >
> > > > To some extent, all versions of this board prior to 2.4 should be
> > > > considered unsupported and we should discourage their use anyway.
> > > >
> > > > If you really want, I suppose we could just alias them to 2.4 ...
> > > 
> > > I'd very much prefer an honest "won't start" over a silent change of the
> > > machine type.
> > > 
> > > If we really want to bend over backwards for existing uses of these
> > > machine types, we could make them error out with "use pc-q35-2.5
> > > instead".  Since I don't think they exist outside testing, I wouldn't
> > > bother.
> > 
> > Agreed, we should be reporting a hard error for any machine types we
> > have deleted. Or if we care about smooth upgrade path then we shouldn't
> > be deleting them in the first place. Silently changing the user's
> > requested machine type into a different machine type is violating
> > the semantics of stable machine types.
> 
> The reason we are deleting them is because changes in behaviour are not
> user visible implementation details, and live migration is unsupported.
> 
> In other words 2.4 is identical to <2.3 in all respect except live
> migration, which didn't work in <2.3 and works in 2.4, that's why
> aliasing them is fine.

If you run a guest with machine type 2.3 on new QEMU, it will
in fact be running machine type 2.4.  Libvirt will still believe
it is using machine type 2.3, so will happily allow you to start
a migrate to a host with old QEMU with the original 2.3 machine
type. This is bad because the machine types are not compatible
for migration and we should report this up front, not let the
migration start and that fail with some problem loading the
migration data stream.

We know 2.3 machine type is broken, so should just be upfront
about this and drop support for it and have users update their
guests to a non-broken machine type.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Michael S. Tsirkin]

On Thu, Aug 27, 2015 at 12:01:17PM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 27, 2015 at 01:50:10PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 25, 2015 at 05:21:16PM +0100, Daniel P. Berrange wrote:
> > > On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
> > > > John Snow <jsnow@redhat.com> writes:
> > > > 
> > > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> > > > >> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> > > > >>> Migration with q35 was not possible before commit
> > > > >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> > > > >>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > > > >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > > > >>> compatibility code for them.
> > > > >>>
> > > > >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > > > >> 
> > > > >> But doesn't that mean that anyone who has a machine configured with one
> > > > >> of those machine types will suddenly find it wont start?
> > > > >> 
> > > > >> Dave
> > > > >> 
> > > > >
> > > > > To some extent, all versions of this board prior to 2.4 should be
> > > > > considered unsupported and we should discourage their use anyway.
> > > > >
> > > > > If you really want, I suppose we could just alias them to 2.4 ...
> > > > 
> > > > I'd very much prefer an honest "won't start" over a silent change of the
> > > > machine type.
> > > > 
> > > > If we really want to bend over backwards for existing uses of these
> > > > machine types, we could make them error out with "use pc-q35-2.5
> > > > instead".  Since I don't think they exist outside testing, I wouldn't
> > > > bother.
> > > 
> > > Agreed, we should be reporting a hard error for any machine types we
> > > have deleted. Or if we care about smooth upgrade path then we shouldn't
> > > be deleting them in the first place. Silently changing the user's
> > > requested machine type into a different machine type is violating
> > > the semantics of stable machine types.
> > 
> > The reason we are deleting them is because changes in behaviour are not
> > user visible implementation details, and live migration is unsupported.
> > 
> > In other words 2.4 is identical to <2.3 in all respect except live
> > migration, which didn't work in <2.3 and works in 2.4, that's why
> > aliasing them is fine.
> 
> If you run a guest with machine type 2.3 on new QEMU, it will
> in fact be running machine type 2.4.  Libvirt will still believe
> it is using machine type 2.3, so will happily allow you to start
> a migrate to a host with old QEMU with the original 2.3 machine
> type. This is bad because the machine types are not compatible
> for migration and we should report this up front, not let the
> migration start and that fail with some problem loading the
> migration data stream.

2.3 simply didn't allow migration.
We can have 2.3 and old be same as 2.4 + disable migration.

> 
> We know 2.3 machine type is broken, so should just be upfront
> about this and drop support for it and have users update their
> guests to a non-broken machine type.
> 
> Regards,
> Daniel

They aren't broken any more than any other old machine type.
The reason we can drop most of compatibility code is
because it's only important for live migration, and
that was blocked anyway.


> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Daniel P. Berrange]

On Thu, Aug 27, 2015 at 02:05:49PM +0300, Michael S. Tsirkin wrote:
> On Thu, Aug 27, 2015 at 12:01:17PM +0100, Daniel P. Berrange wrote:
> > On Thu, Aug 27, 2015 at 01:50:10PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 25, 2015 at 05:21:16PM +0100, Daniel P. Berrange wrote:
> > > > On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
> > > > > John Snow <jsnow@redhat.com> writes:
> > > > > 
> > > > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> > > > > >> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> > > > > >>> Migration with q35 was not possible before commit
> > > > > >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> > > > > >>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > > > > >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > > > > >>> compatibility code for them.
> > > > > >>>
> > > > > >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > > > > >> 
> > > > > >> But doesn't that mean that anyone who has a machine configured with one
> > > > > >> of those machine types will suddenly find it wont start?
> > > > > >> 
> > > > > >> Dave
> > > > > >> 
> > > > > >
> > > > > > To some extent, all versions of this board prior to 2.4 should be
> > > > > > considered unsupported and we should discourage their use anyway.
> > > > > >
> > > > > > If you really want, I suppose we could just alias them to 2.4 ...
> > > > > 
> > > > > I'd very much prefer an honest "won't start" over a silent change of the
> > > > > machine type.
> > > > > 
> > > > > If we really want to bend over backwards for existing uses of these
> > > > > machine types, we could make them error out with "use pc-q35-2.5
> > > > > instead".  Since I don't think they exist outside testing, I wouldn't
> > > > > bother.
> > > > 
> > > > Agreed, we should be reporting a hard error for any machine types we
> > > > have deleted. Or if we care about smooth upgrade path then we shouldn't
> > > > be deleting them in the first place. Silently changing the user's
> > > > requested machine type into a different machine type is violating
> > > > the semantics of stable machine types.
> > > 
> > > The reason we are deleting them is because changes in behaviour are not
> > > user visible implementation details, and live migration is unsupported.
> > > 
> > > In other words 2.4 is identical to <2.3 in all respect except live
> > > migration, which didn't work in <2.3 and works in 2.4, that's why
> > > aliasing them is fine.
> > 
> > If you run a guest with machine type 2.3 on new QEMU, it will
> > in fact be running machine type 2.4.  Libvirt will still believe
> > it is using machine type 2.3, so will happily allow you to start
> > a migrate to a host with old QEMU with the original 2.3 machine
> > type. This is bad because the machine types are not compatible
> > for migration and we should report this up front, not let the
> > migration start and that fail with some problem loading the
> > migration data stream.
> 
> 2.3 simply didn't allow migration.
> We can have 2.3 and old be same as 2.4 + disable migration.

Ok that would be reasonable as it ensures query-machines still lists
all types that QEMU is capable of actually running.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Eduardo Habkost]

On Thu, Aug 27, 2015 at 01:50:10PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 25, 2015 at 05:21:16PM +0100, Daniel P. Berrange wrote:
> > On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
> > > John Snow <jsnow@redhat.com> writes:
> > > 
> > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> > > >> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> > > >>> Migration with q35 was not possible before commit
> > > >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> > > >>> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > > >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > > >>> compatibility code for them.
> > > >>>
> > > >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > > >> 
> > > >> But doesn't that mean that anyone who has a machine configured with one
> > > >> of those machine types will suddenly find it wont start?
> > > >> 
> > > >> Dave
> > > >> 
> > > >
> > > > To some extent, all versions of this board prior to 2.4 should be
> > > > considered unsupported and we should discourage their use anyway.
> > > >
> > > > If you really want, I suppose we could just alias them to 2.4 ...
> > > 
> > > I'd very much prefer an honest "won't start" over a silent change of the
> > > machine type.
> > > 
> > > If we really want to bend over backwards for existing uses of these
> > > machine types, we could make them error out with "use pc-q35-2.5
> > > instead".  Since I don't think they exist outside testing, I wouldn't
> > > bother.
> > 
> > Agreed, we should be reporting a hard error for any machine types we
> > have deleted. Or if we care about smooth upgrade path then we shouldn't
> > be deleting them in the first place. Silently changing the user's
> > requested machine type into a different machine type is violating
> > the semantics of stable machine types.
> > 
> > Regards,
> > Daniel
> 
> The reason we are deleting them is because changes in behaviour are not
> user visible implementation details, and live migration is unsupported.
> 
> In other words 2.4 is identical to <2.3 in all respect except live
> migration, which didn't work in <2.3 and works in 2.4, that's why
> aliasing them is fine.

I don't know what you mean by "not user visible implementation details"
and "identical in all respect", because I see lots of compat code that
implement user-visible differences inside pc_compat_*(), PC_COMPAT_*,
pc_q35_*_machine_options() for 2.3 and older.

-- 
Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Markus Armbruster]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Thu, Aug 27, 2015 at 01:50:10PM +0300, Michael S. Tsirkin wrote:
>> On Tue, Aug 25, 2015 at 05:21:16PM +0100, Daniel P. Berrange wrote:
>> > On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
>> > > John Snow <jsnow@redhat.com> writes:
>> > > 
>> > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
>> > > >> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>> > > >>> Migration with q35 was not possible before commit
>> > > >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35
>> > > >>> unconditionally creates
>> > > >>> an ich9-ahci device, that was marked as unmigratable. So all
>> > > >>> q35 machines
>> > > >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
>> > > >>> compatibility code for them.
>> > > >>>
>> > > >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
>> > > >> 
>> > > >> But doesn't that mean that anyone who has a machine configured with one
>> > > >> of those machine types will suddenly find it wont start?
>> > > >> 
>> > > >> Dave
>> > > >> 
>> > > >
>> > > > To some extent, all versions of this board prior to 2.4 should be
>> > > > considered unsupported and we should discourage their use anyway.
>> > > >
>> > > > If you really want, I suppose we could just alias them to 2.4 ...
>> > > 
>> > > I'd very much prefer an honest "won't start" over a silent change of the
>> > > machine type.
>> > > 
>> > > If we really want to bend over backwards for existing uses of these
>> > > machine types, we could make them error out with "use pc-q35-2.5
>> > > instead".  Since I don't think they exist outside testing, I wouldn't
>> > > bother.
>> > 
>> > Agreed, we should be reporting a hard error for any machine types we
>> > have deleted. Or if we care about smooth upgrade path then we shouldn't
>> > be deleting them in the first place. Silently changing the user's
>> > requested machine type into a different machine type is violating
>> > the semantics of stable machine types.
>> > 
>> > Regards,
>> > Daniel
>> 
>> The reason we are deleting them is because changes in behaviour are not
>> user visible implementation details, and live migration is unsupported.
>> 
>> In other words 2.4 is identical to <2.3 in all respect except live
>> migration, which didn't work in <2.3 and works in 2.4, that's why
>> aliasing them is fine.

While I don't think maintaining the old, not-really-functional q35 types
is worth the bother, I wouldn't mind these aliases...

> I don't know what you mean by "not user visible implementation details"
> and "identical in all respect", because I see lots of compat code that
> implement user-visible differences inside pc_compat_*(), PC_COMPAT_*,
> pc_q35_*_machine_options() for 2.3 and older.

... *if* the compat code *demonstrably* has no guest-visible effects.

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Eduardo Habkost]

On Fri, Aug 28, 2015 at 12:00:58PM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
> 
> > On Thu, Aug 27, 2015 at 01:50:10PM +0300, Michael S. Tsirkin wrote:
> >> On Tue, Aug 25, 2015 at 05:21:16PM +0100, Daniel P. Berrange wrote:
> >> > On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
> >> > > John Snow <jsnow@redhat.com> writes:
> >> > > 
> >> > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
> >> > > >> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> >> > > >>> Migration with q35 was not possible before commit
> >> > > >>> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35
> >> > > >>> unconditionally creates
> >> > > >>> an ich9-ahci device, that was marked as unmigratable. So all
> >> > > >>> q35 machines
> >> > > >>> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> >> > > >>> compatibility code for them.
> >> > > >>>
> >> > > >>> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> >> > > >> 
> >> > > >> But doesn't that mean that anyone who has a machine configured with one
> >> > > >> of those machine types will suddenly find it wont start?
> >> > > >> 
> >> > > >> Dave
> >> > > >> 
> >> > > >
> >> > > > To some extent, all versions of this board prior to 2.4 should be
> >> > > > considered unsupported and we should discourage their use anyway.
> >> > > >
> >> > > > If you really want, I suppose we could just alias them to 2.4 ...
> >> > > 
> >> > > I'd very much prefer an honest "won't start" over a silent change of the
> >> > > machine type.
> >> > > 
> >> > > If we really want to bend over backwards for existing uses of these
> >> > > machine types, we could make them error out with "use pc-q35-2.5
> >> > > instead".  Since I don't think they exist outside testing, I wouldn't
> >> > > bother.
> >> > 
> >> > Agreed, we should be reporting a hard error for any machine types we
> >> > have deleted. Or if we care about smooth upgrade path then we shouldn't
> >> > be deleting them in the first place. Silently changing the user's
> >> > requested machine type into a different machine type is violating
> >> > the semantics of stable machine types.
> >> > 
> >> > Regards,
> >> > Daniel
> >> 
> >> The reason we are deleting them is because changes in behaviour are not
> >> user visible implementation details, and live migration is unsupported.
> >> 
> >> In other words 2.4 is identical to <2.3 in all respect except live
> >> migration, which didn't work in <2.3 and works in 2.4, that's why
> >> aliasing them is fine.
> 
> While I don't think maintaining the old, not-really-functional q35 types
> is worth the bother, I wouldn't mind these aliases...
> 
> > I don't know what you mean by "not user visible implementation details"
> > and "identical in all respect", because I see lots of compat code that
> > implement user-visible differences inside pc_compat_*(), PC_COMPAT_*,
> > pc_q35_*_machine_options() for 2.3 and older.
> 
> ... *if* the compat code *demonstrably* has no guest-visible effects.

Most of the compat code has guest-visible effects, it seems. Enumerating
some of them:

* Lots of CPUID compat code
* virtio and PCI compat properties at PC_COMPAT_2_0: I assume
  at least some of them have guest-visible effects
* USB msos-desc property on PC_COMPAT_1_7
* no_floppy on pc_q35_2_3_machine_options()

-- 
Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Laszlo Ersek]

On 08/19/15 01:11, Eduardo Habkost wrote:
> Migration with q35 was not possible before commit
> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> compatibility code for them.
> 
> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  hw/i386/pc_q35.c | 153 -------------------------------------------------------
>  1 file changed, 153 deletions(-)

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 4ee653e..e482f2f 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -272,60 +272,6 @@ static void pc_q35_init(MachineState *machine)
>      }
>  }
>  
> -static void pc_compat_2_3(MachineState *machine)
> -{
> -    PCMachineState *pcms = PC_MACHINE(machine);
> -    savevm_skip_section_footers();
> -    if (kvm_enabled()) {
> -        pcms->smm = ON_OFF_AUTO_OFF;
> -    }
> -    global_state_set_optional();
> -    savevm_skip_configuration();
> -}
> -
> -static void pc_compat_2_2(MachineState *machine)
> -{
> -    pc_compat_2_3(machine);
> -    machine->suppress_vmdesc = true;
> -}
> -
> -static void pc_compat_2_1(MachineState *machine)
> -{
> -    PCMachineState *pcms = PC_MACHINE(machine);
> -
> -    pc_compat_2_2(machine);
> -    pcms->enforce_aligned_dimm = false;
> -    x86_cpu_compat_kvm_no_autodisable(FEAT_8000_0001_ECX, CPUID_EXT3_SVM);
> -}
> -
> -static void pc_compat_2_0(MachineState *machine)
> -{
> -    pc_compat_2_1(machine);
> -}
> -
> -static void pc_compat_1_7(MachineState *machine)
> -{
> -    pc_compat_2_0(machine);
> -    option_rom_has_mr = true;
> -    x86_cpu_compat_kvm_no_autoenable(FEAT_1_ECX, CPUID_EXT_X2APIC);
> -}
> -
> -static void pc_compat_1_6(MachineState *machine)
> -{
> -    pc_compat_1_7(machine);
> -    rom_file_has_mr = false;
> -}
> -
> -static void pc_compat_1_5(MachineState *machine)
> -{
> -    pc_compat_1_6(machine);
> -}
> -
> -static void pc_compat_1_4(MachineState *machine)
> -{
> -    pc_compat_1_5(machine);
> -}
> -
>  #define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
>      static void pc_init_##suffix(MachineState *machine) \
>      { \
> @@ -358,102 +304,3 @@ static void pc_q35_2_4_machine_options(MachineClass *m)
>  
>  DEFINE_Q35_MACHINE(v2_4, "pc-q35-2.4", NULL,
>                     pc_q35_2_4_machine_options);
> -
> -
> -static void pc_q35_2_3_machine_options(MachineClass *m)
> -{
> -    pc_q35_2_4_machine_options(m);
> -    m->no_floppy = 0;
> -    m->no_tco = 1;
> -    m->alias = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_3);
> -}
> -
> -DEFINE_Q35_MACHINE(v2_3, "pc-q35-2.3", pc_compat_2_3,
> -                   pc_q35_2_3_machine_options);
> -
> -
> -static void pc_q35_2_2_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_3_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_2);
> -    pcmc->rsdp_in_ram = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_2, "pc-q35-2.2", pc_compat_2_2,
> -                   pc_q35_2_2_machine_options);
> -
> -
> -static void pc_q35_2_1_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_2_machine_options(m);
> -    m->default_display = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_1);
> -    pcmc->smbios_uuid_encoded = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_1, "pc-q35-2.1", pc_compat_2_1,
> -                   pc_q35_2_1_machine_options);
> -
> -
> -static void pc_q35_2_0_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_1_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_0);
> -    pcmc->has_reserved_memory = false;
> -    pcmc->smbios_legacy_mode = true;
> -    pcmc->acpi_data_size = 0x10000;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_0, "pc-q35-2.0", pc_compat_2_0,
> -                   pc_q35_2_0_machine_options);
> -
> -
> -static void pc_q35_1_7_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_0_machine_options(m);
> -    m->default_machine_opts = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_7);
> -    pcmc->smbios_defaults = false;
> -    pcmc->gigabyte_align = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v1_7, "pc-q35-1.7", pc_compat_1_7,
> -                   pc_q35_1_7_machine_options);
> -
> -
> -static void pc_q35_1_6_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_6);
> -    pcmc->has_acpi_build = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v1_6, "pc-q35-1.6", pc_compat_1_6,
> -                   pc_q35_1_6_machine_options);
> -
> -
> -static void pc_q35_1_5_machine_options(MachineClass *m)
> -{
> -    pc_q35_1_6_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_5);
> -}
> -
> -DEFINE_Q35_MACHINE(v1_5, "pc-q35-1.5", pc_compat_1_5,
> -                   pc_q35_1_5_machine_options);
> -
> -
> -static void pc_q35_1_4_machine_options(MachineClass *m)
> -{
> -    pc_q35_1_5_machine_options(m);
> -    m->hot_add_cpu = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_4);
> -}
> -
> -DEFINE_Q35_MACHINE(v1_4, "pc-q35-1.4", pc_compat_1_4,
> -                   pc_q35_1_4_machine_options);
> 

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Eduardo Habkost]

Ping?

So, what's the reason we are still keeping those old machines in the
code?


On Tue, Aug 18, 2015 at 04:11:42PM -0700, Eduardo Habkost wrote:
> Migration with q35 was not possible before commit
> 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> before pc-q35-2.4 were unmigratable, and there's no point in keeping
> compatibility code for them.
> 
> Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  hw/i386/pc_q35.c | 153 -------------------------------------------------------
>  1 file changed, 153 deletions(-)
> 
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 4ee653e..e482f2f 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -272,60 +272,6 @@ static void pc_q35_init(MachineState *machine)
>      }
>  }
>  
> -static void pc_compat_2_3(MachineState *machine)
> -{
> -    PCMachineState *pcms = PC_MACHINE(machine);
> -    savevm_skip_section_footers();
> -    if (kvm_enabled()) {
> -        pcms->smm = ON_OFF_AUTO_OFF;
> -    }
> -    global_state_set_optional();
> -    savevm_skip_configuration();
> -}
> -
> -static void pc_compat_2_2(MachineState *machine)
> -{
> -    pc_compat_2_3(machine);
> -    machine->suppress_vmdesc = true;
> -}
> -
> -static void pc_compat_2_1(MachineState *machine)
> -{
> -    PCMachineState *pcms = PC_MACHINE(machine);
> -
> -    pc_compat_2_2(machine);
> -    pcms->enforce_aligned_dimm = false;
> -    x86_cpu_compat_kvm_no_autodisable(FEAT_8000_0001_ECX, CPUID_EXT3_SVM);
> -}
> -
> -static void pc_compat_2_0(MachineState *machine)
> -{
> -    pc_compat_2_1(machine);
> -}
> -
> -static void pc_compat_1_7(MachineState *machine)
> -{
> -    pc_compat_2_0(machine);
> -    option_rom_has_mr = true;
> -    x86_cpu_compat_kvm_no_autoenable(FEAT_1_ECX, CPUID_EXT_X2APIC);
> -}
> -
> -static void pc_compat_1_6(MachineState *machine)
> -{
> -    pc_compat_1_7(machine);
> -    rom_file_has_mr = false;
> -}
> -
> -static void pc_compat_1_5(MachineState *machine)
> -{
> -    pc_compat_1_6(machine);
> -}
> -
> -static void pc_compat_1_4(MachineState *machine)
> -{
> -    pc_compat_1_5(machine);
> -}
> -
>  #define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
>      static void pc_init_##suffix(MachineState *machine) \
>      { \
> @@ -358,102 +304,3 @@ static void pc_q35_2_4_machine_options(MachineClass *m)
>  
>  DEFINE_Q35_MACHINE(v2_4, "pc-q35-2.4", NULL,
>                     pc_q35_2_4_machine_options);
> -
> -
> -static void pc_q35_2_3_machine_options(MachineClass *m)
> -{
> -    pc_q35_2_4_machine_options(m);
> -    m->no_floppy = 0;
> -    m->no_tco = 1;
> -    m->alias = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_3);
> -}
> -
> -DEFINE_Q35_MACHINE(v2_3, "pc-q35-2.3", pc_compat_2_3,
> -                   pc_q35_2_3_machine_options);
> -
> -
> -static void pc_q35_2_2_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_3_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_2);
> -    pcmc->rsdp_in_ram = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_2, "pc-q35-2.2", pc_compat_2_2,
> -                   pc_q35_2_2_machine_options);
> -
> -
> -static void pc_q35_2_1_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_2_machine_options(m);
> -    m->default_display = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_1);
> -    pcmc->smbios_uuid_encoded = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_1, "pc-q35-2.1", pc_compat_2_1,
> -                   pc_q35_2_1_machine_options);
> -
> -
> -static void pc_q35_2_0_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_1_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_0);
> -    pcmc->has_reserved_memory = false;
> -    pcmc->smbios_legacy_mode = true;
> -    pcmc->acpi_data_size = 0x10000;
> -}
> -
> -DEFINE_Q35_MACHINE(v2_0, "pc-q35-2.0", pc_compat_2_0,
> -                   pc_q35_2_0_machine_options);
> -
> -
> -static void pc_q35_1_7_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_2_0_machine_options(m);
> -    m->default_machine_opts = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_7);
> -    pcmc->smbios_defaults = false;
> -    pcmc->gigabyte_align = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v1_7, "pc-q35-1.7", pc_compat_1_7,
> -                   pc_q35_1_7_machine_options);
> -
> -
> -static void pc_q35_1_6_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -    pc_q35_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_6);
> -    pcmc->has_acpi_build = false;
> -}
> -
> -DEFINE_Q35_MACHINE(v1_6, "pc-q35-1.6", pc_compat_1_6,
> -                   pc_q35_1_6_machine_options);
> -
> -
> -static void pc_q35_1_5_machine_options(MachineClass *m)
> -{
> -    pc_q35_1_6_machine_options(m);
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_5);
> -}
> -
> -DEFINE_Q35_MACHINE(v1_5, "pc-q35-1.5", pc_compat_1_5,
> -                   pc_q35_1_5_machine_options);
> -
> -
> -static void pc_q35_1_4_machine_options(MachineClass *m)
> -{
> -    pc_q35_1_5_machine_options(m);
> -    m->hot_add_cpu = NULL;
> -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_4);
> -}
> -
> -DEFINE_Q35_MACHINE(v1_4, "pc-q35-1.4", pc_compat_1_4,
> -                   pc_q35_1_4_machine_options);
> -- 
> 2.1.0
> 
> 

-- 
Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Markus Armbruster]

Eduardo Habkost <ehabkost@redhat.com> writes:

> Ping?
>
> So, what's the reason we are still keeping those old machines in the
> code?

Inertia?

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Michael S. Tsirkin]

On Fri, Sep 11, 2015 at 03:44:47PM -0300, Eduardo Habkost wrote:
> Ping?
> 
> So, what's the reason we are still keeping those old machines in the
> code?

Victor also wanted to clean out some very old machine types for
the PIIX, too.

But if someone created a machine with libvirt, these machine types
are now written in the XML. Failing to start guests isn't nice.

Maybe we could drop most of the compat code, but keep the
old machine types around with most visible changes (no_floppy? anything
else?). As we can't live migrate these older machine types,
minor guest visible changes aren't a big deal if they don't
break guest boot.

> 
> On Tue, Aug 18, 2015 at 04:11:42PM -0700, Eduardo Habkost wrote:
> > Migration with q35 was not possible before commit
> > 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally creates
> > an ich9-ahci device, that was marked as unmigratable. So all q35 machines
> > before pc-q35-2.4 were unmigratable, and there's no point in keeping
> > compatibility code for them.
> > 
> > Remove all old pc-q35 machine classes and keep only pc-q35-2.4.
> > 
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> >  hw/i386/pc_q35.c | 153 -------------------------------------------------------
> >  1 file changed, 153 deletions(-)
> > 
> > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> > index 4ee653e..e482f2f 100644
> > --- a/hw/i386/pc_q35.c
> > +++ b/hw/i386/pc_q35.c
> > @@ -272,60 +272,6 @@ static void pc_q35_init(MachineState *machine)
> >      }
> >  }
> >  
> > -static void pc_compat_2_3(MachineState *machine)
> > -{
> > -    PCMachineState *pcms = PC_MACHINE(machine);
> > -    savevm_skip_section_footers();
> > -    if (kvm_enabled()) {
> > -        pcms->smm = ON_OFF_AUTO_OFF;
> > -    }
> > -    global_state_set_optional();
> > -    savevm_skip_configuration();
> > -}
> > -
> > -static void pc_compat_2_2(MachineState *machine)
> > -{
> > -    pc_compat_2_3(machine);
> > -    machine->suppress_vmdesc = true;
> > -}
> > -
> > -static void pc_compat_2_1(MachineState *machine)
> > -{
> > -    PCMachineState *pcms = PC_MACHINE(machine);
> > -
> > -    pc_compat_2_2(machine);
> > -    pcms->enforce_aligned_dimm = false;
> > -    x86_cpu_compat_kvm_no_autodisable(FEAT_8000_0001_ECX, CPUID_EXT3_SVM);
> > -}
> > -
> > -static void pc_compat_2_0(MachineState *machine)
> > -{
> > -    pc_compat_2_1(machine);
> > -}
> > -
> > -static void pc_compat_1_7(MachineState *machine)
> > -{
> > -    pc_compat_2_0(machine);
> > -    option_rom_has_mr = true;
> > -    x86_cpu_compat_kvm_no_autoenable(FEAT_1_ECX, CPUID_EXT_X2APIC);
> > -}
> > -
> > -static void pc_compat_1_6(MachineState *machine)
> > -{
> > -    pc_compat_1_7(machine);
> > -    rom_file_has_mr = false;
> > -}
> > -
> > -static void pc_compat_1_5(MachineState *machine)
> > -{
> > -    pc_compat_1_6(machine);
> > -}
> > -
> > -static void pc_compat_1_4(MachineState *machine)
> > -{
> > -    pc_compat_1_5(machine);
> > -}
> > -
> >  #define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
> >      static void pc_init_##suffix(MachineState *machine) \
> >      { \
> > @@ -358,102 +304,3 @@ static void pc_q35_2_4_machine_options(MachineClass *m)
> >  
> >  DEFINE_Q35_MACHINE(v2_4, "pc-q35-2.4", NULL,
> >                     pc_q35_2_4_machine_options);
> > -
> > -
> > -static void pc_q35_2_3_machine_options(MachineClass *m)
> > -{
> > -    pc_q35_2_4_machine_options(m);
> > -    m->no_floppy = 0;
> > -    m->no_tco = 1;
> > -    m->alias = NULL;
> > -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_3);
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v2_3, "pc-q35-2.3", pc_compat_2_3,
> > -                   pc_q35_2_3_machine_options);
> > -
> > -
> > -static void pc_q35_2_2_machine_options(MachineClass *m)
> > -{
> > -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> > -    pc_q35_2_3_machine_options(m);
> > -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_2);
> > -    pcmc->rsdp_in_ram = false;
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v2_2, "pc-q35-2.2", pc_compat_2_2,
> > -                   pc_q35_2_2_machine_options);
> > -
> > -
> > -static void pc_q35_2_1_machine_options(MachineClass *m)
> > -{
> > -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> > -    pc_q35_2_2_machine_options(m);
> > -    m->default_display = NULL;
> > -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_1);
> > -    pcmc->smbios_uuid_encoded = false;
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v2_1, "pc-q35-2.1", pc_compat_2_1,
> > -                   pc_q35_2_1_machine_options);
> > -
> > -
> > -static void pc_q35_2_0_machine_options(MachineClass *m)
> > -{
> > -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> > -    pc_q35_2_1_machine_options(m);
> > -    SET_MACHINE_COMPAT(m, PC_COMPAT_2_0);
> > -    pcmc->has_reserved_memory = false;
> > -    pcmc->smbios_legacy_mode = true;
> > -    pcmc->acpi_data_size = 0x10000;
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v2_0, "pc-q35-2.0", pc_compat_2_0,
> > -                   pc_q35_2_0_machine_options);
> > -
> > -
> > -static void pc_q35_1_7_machine_options(MachineClass *m)
> > -{
> > -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> > -    pc_q35_2_0_machine_options(m);
> > -    m->default_machine_opts = NULL;
> > -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_7);
> > -    pcmc->smbios_defaults = false;
> > -    pcmc->gigabyte_align = false;
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v1_7, "pc-q35-1.7", pc_compat_1_7,
> > -                   pc_q35_1_7_machine_options);
> > -
> > -
> > -static void pc_q35_1_6_machine_options(MachineClass *m)
> > -{
> > -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> > -    pc_q35_machine_options(m);
> > -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_6);
> > -    pcmc->has_acpi_build = false;
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v1_6, "pc-q35-1.6", pc_compat_1_6,
> > -                   pc_q35_1_6_machine_options);
> > -
> > -
> > -static void pc_q35_1_5_machine_options(MachineClass *m)
> > -{
> > -    pc_q35_1_6_machine_options(m);
> > -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_5);
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v1_5, "pc-q35-1.5", pc_compat_1_5,
> > -                   pc_q35_1_5_machine_options);
> > -
> > -
> > -static void pc_q35_1_4_machine_options(MachineClass *m)
> > -{
> > -    pc_q35_1_5_machine_options(m);
> > -    m->hot_add_cpu = NULL;
> > -    SET_MACHINE_COMPAT(m, PC_COMPAT_1_4);
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v1_4, "pc-q35-1.4", pc_compat_1_4,
> > -                   pc_q35_1_4_machine_options);
> > -- 
> > 2.1.0
> > 
> > 
> 
> -- 
> Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Markus Armbruster]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Fri, Sep 11, 2015 at 03:44:47PM -0300, Eduardo Habkost wrote:
>> Ping?
>> 
>> So, what's the reason we are still keeping those old machines in the
>> code?
>
> Victor also wanted to clean out some very old machine types for
> the PIIX, too.
>
> But if someone created a machine with libvirt, these machine types
> are now written in the XML. Failing to start guests isn't nice.
>
> Maybe we could drop most of the compat code, but keep the
> old machine types around with most visible changes (no_floppy? anything
> else?). As we can't live migrate these older machine types,
> minor guest visible changes aren't a big deal if they don't
> break guest boot.

We've been through this before, but we can go through it once more.
Choices:

A. Remove old machine type

   A guest using it can't be started.  Easy to understand on the host.
   An error message advising to switch to a newer machine type would be
   a nice touch.

   This is a clean break in backward compatibility.  To be mentioned in
   release notes, obviously.

B. Change old machine type in a guest-visible way

   Depending on the nature of the change and the guest, a guest using it
   either doesn't notice, copes with it successfully, or fails in
   guest-specific ways.  If the latter, the failure can be "guest
   hangs", which is much harder to figure out than A.

   Unless we can *demonstrate* that nothing bad happens for all the
   guests people actually use with the old machine types, this is a
   different kind of backward compatibility break.

   Demonstrating this is feels infeasible to me, but you're welcome to
   try.

I could call the difference between the two a tradeoff, but since we've
been through this before, I'll be more blunt: choosing B robs Peter (the
guy with guests where badness happens) to pay Paul (the guy with guests
that cope).  Paul is saved the inconvenience of having to read release
notes or his logs, and change machine types.  Peter pays for that with
figuring out WTF his guests are doing now.

As a user, I'd pick a clean break in backward compatibility over a hack
that preserves effective compatibility when it works, but breaks it
uncleanly when it doesn't.

As a developer, I'm insisting on it.

So, if you want B, the onus is on *you* to show us why nothing bad will
happen.

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

On 09/13/2015 03:28 AM, Michael S. Tsirkin wrote:
> On Fri, Sep 11, 2015 at 03:44:47PM -0300, Eduardo Habkost wrote:
>> Ping?
>>
>> So, what's the reason we are still keeping those old machines in the
>> code?
> 
> Victor also wanted to clean out some very old machine types for
> the PIIX, too.
> 
> But if someone created a machine with libvirt, these machine types
> are now written in the XML. Failing to start guests isn't nice.

New qemu with old libvirt isn't always guaranteed to work. And new
libvirt can be patched to automatically update any old hard-coded
machine name to a newer safe alternative, _when such update is proven
safe_ (we've done it in the past for Fedora: if I recall correctly,
Fedora 13 branched its own machine type, then in Fedora 15 qemu decided
to quit supporting the branch, so libvirt was patched downstream in
Fedora 15-17 to rewrite the old name into its safe upstream counterpart.
 The downstream patch was dropped in Fedora 18 since F15 was EOL by then
so no more new machines would have been created with the old spelling,
and since a year was deemed long enough for people to have either run
their guest to pick up the automatic update, or that their guest was so
infrequently run that they could read the error message and act on it
themselves).

Failing to start guests isn't nice, but it also isn't the end of the
world, when there is no choice but to break ABI.  An explicit ABI break
(by making the user rewrite machine type) is better than silent change
in behavior with a potential for broken guests.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Eduardo Habkost]

On Mon, Sep 14, 2015 at 09:09:12AM -0600, Eric Blake wrote:
> On 09/13/2015 03:28 AM, Michael S. Tsirkin wrote:
> > On Fri, Sep 11, 2015 at 03:44:47PM -0300, Eduardo Habkost wrote:
> >> Ping?
> >>
> >> So, what's the reason we are still keeping those old machines in the
> >> code?
> > 
> > Victor also wanted to clean out some very old machine types for
> > the PIIX, too.
> > 
> > But if someone created a machine with libvirt, these machine types
> > are now written in the XML. Failing to start guests isn't nice.
> 
> New qemu with old libvirt isn't always guaranteed to work. And new
> libvirt can be patched to automatically update any old hard-coded
> machine name to a newer safe alternative, _when such update is proven
> safe_ (we've done it in the past for Fedora: if I recall correctly,
> Fedora 13 branched its own machine type, then in Fedora 15 qemu decided
> to quit supporting the branch, so libvirt was patched downstream in
> Fedora 15-17 to rewrite the old name into its safe upstream counterpart.
>  The downstream patch was dropped in Fedora 18 since F15 was EOL by then
> so no more new machines would have been created with the old spelling,
> and since a year was deemed long enough for people to have either run
> their guest to pick up the automatic update, or that their guest was so
> infrequently run that they could read the error message and act on it
> themselves).
> 
> Failing to start guests isn't nice, but it also isn't the end of the
> world, when there is no choice but to break ABI.  An explicit ABI break
> (by making the user rewrite machine type) is better than silent change
> in behavior with a potential for broken guests.

What I get from this, is that this is an user interface and usability
problem, and it's better to solve it at the appropriate layer (which is
not QEMU).

If QEMU can't emulate those machines anymore, QEMU's job is to just tell
that to libvirt (so libvirt and management layers can decide what's the
best way to help the user cope with it), instead of lying to them and
say that we still emulate the same machine when we actually don't.

-- 
Eduardo

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions

[Markus Armbruster]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Mon, Sep 14, 2015 at 09:09:12AM -0600, Eric Blake wrote:
>> On 09/13/2015 03:28 AM, Michael S. Tsirkin wrote:
>> > On Fri, Sep 11, 2015 at 03:44:47PM -0300, Eduardo Habkost wrote:
>> >> Ping?
>> >>
>> >> So, what's the reason we are still keeping those old machines in the
>> >> code?
>> > 
>> > Victor also wanted to clean out some very old machine types for
>> > the PIIX, too.
>> > 
>> > But if someone created a machine with libvirt, these machine types
>> > are now written in the XML. Failing to start guests isn't nice.
>> 
>> New qemu with old libvirt isn't always guaranteed to work. And new
>> libvirt can be patched to automatically update any old hard-coded
>> machine name to a newer safe alternative, _when such update is proven
>> safe_ (we've done it in the past for Fedora: if I recall correctly,
>> Fedora 13 branched its own machine type, then in Fedora 15 qemu decided
>> to quit supporting the branch, so libvirt was patched downstream in
>> Fedora 15-17 to rewrite the old name into its safe upstream counterpart.
>>  The downstream patch was dropped in Fedora 18 since F15 was EOL by then
>> so no more new machines would have been created with the old spelling,
>> and since a year was deemed long enough for people to have either run
>> their guest to pick up the automatic update, or that their guest was so
>> infrequently run that they could read the error message and act on it
>> themselves).
>> 
>> Failing to start guests isn't nice, but it also isn't the end of the
>> world, when there is no choice but to break ABI.  An explicit ABI break
>> (by making the user rewrite machine type) is better than silent change
>> in behavior with a potential for broken guests.
>
> What I get from this, is that this is an user interface and usability
> problem, and it's better to solve it at the appropriate layer (which is
> not QEMU).
>
> If QEMU can't emulate those machines anymore, QEMU's job is to just tell
> that to libvirt (so libvirt and management layers can decide what's the
> best way to help the user cope with it), instead of lying to them and
> say that we still emulate the same machine when we actually don't.

Seconded.

The story for direct use by humans is at least as convincing.