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

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

2015-09-15 Thread Markus Armbruster

Eduardo Habkost  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.

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

2015-09-14 Thread Eric Blake

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

signature.asc
Description: OpenPGP digital signature

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

2015-09-14 Thread Markus Armbruster

"Michael S. Tsirkin"  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

2015-09-14 Thread 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

2015-09-13 Thread 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 
> > ---
> >  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 = 0x1;
> > -}
> > -
> > -DEFINE_Q35_MACHINE(v2_0, "pc-q35-2.0", pc_compat_2_0,
> > -   pc_q35_2_0_machine_options);
> > -
> > -
> > -static

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

2015-09-11 Thread 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 
> ---
>  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 = 0x1;
> -}
> -
> -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)
>

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

2015-09-11 Thread Markus Armbruster

Eduardo Habkost  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

2015-08-28 Thread Markus Armbruster

Eduardo Habkost ehabk...@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 js...@redhat.com writes:
   
On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
* Eduardo Habkost (ehabk...@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

2015-08-28 Thread Eduardo Habkost

On Fri, Aug 28, 2015 at 12:00:58PM +0200, Markus Armbruster wrote:
 Eduardo Habkost ehabk...@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 js...@redhat.com writes:

 On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
 * Eduardo Habkost (ehabk...@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

2015-08-27 Thread 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 js...@redhat.com writes:
 
  On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
  * Eduardo Habkost (ehabk...@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

2015-08-27 Thread 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 js...@redhat.com writes:
   
On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
* Eduardo Habkost (ehabk...@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

2015-08-27 Thread 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 js...@redhat.com writes:
  
   On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
   * Eduardo Habkost (ehabk...@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

2015-08-27 Thread 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 (ehabk...@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

2015-08-27 Thread 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 js...@redhat.com writes:
   
On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
* Eduardo Habkost (ehabk...@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

2015-08-27 Thread 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 js...@redhat.com writes:

 On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
 * Eduardo Habkost (ehabk...@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

2015-08-25 Thread Daniel P. Berrange

On Mon, Aug 24, 2015 at 11:54:48AM +0200, Markus Armbruster wrote:
 John Snow js...@redhat.com writes:
 
  On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
  * Eduardo Habkost (ehabk...@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

2015-08-25 Thread 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 (ehabk...@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

2015-08-25 Thread Marcel Apfelbaum


On 08/24/2015 12:54 PM, Markus Armbruster wrote:

John Snow js...@redhat.com writes:


On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:

* Eduardo Habkost (ehabk...@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

2015-08-25 Thread 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 (ehabk...@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

2015-08-24 Thread Markus Armbruster

John Snow js...@redhat.com writes:

 On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
 * Eduardo Habkost (ehabk...@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

2015-08-24 Thread John Snow



On 08/24/2015 02:54 AM, Markus Armbruster wrote:
 John Snow js...@redhat.com writes:
 
 On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
 * Eduardo Habkost (ehabk...@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

2015-08-21 Thread 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 ehabk...@redhat.com
 ---
  hw/i386/pc_q35.c | 153 
 ---
  1 file changed, 153 deletions(-)

Reviewed-by: Laszlo Ersek ler...@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 = 0x1;
 -}
 -
 -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)

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

2015-08-20 Thread John Snow



On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote:
 * Eduardo Habkost (ehabk...@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 ehabk...@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 = 0x1;
 -}
 -
 -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,
 -

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

2015-08-19 Thread Eduardo Habkost

On Wed, Aug 19, 2015 at 10:55:26AM +0100, Dr. David Alan Gilbert wrote:
 * Eduardo Habkost (ehabk...@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

2015-08-19 Thread Dr. David Alan Gilbert

* Eduardo Habkost (ehabk...@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 ehabk...@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 = 0x1;
 -}
 -
 -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,
 -

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

2015-08-18 Thread 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 ehabk...@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 = 0x1;
-}
-
-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26 matches

Site Navigation

Mail list logo

Footer information