Re: [Qemu-devel] Deprecating old machine-types (was Re: [PATCH v4 7/8] intel_iommu: keep buggy EIM enabled in 2.7 machine type)
On Tue, Oct 11, 2016 at 10:47:43AM +0200, Paolo Bonzini wrote: > > > On 11/10/2016 10:23, Daniel P. Berrange wrote: > > On Tue, Oct 11, 2016 at 09:36:29AM +0200, Paolo Bonzini wrote: > >> > >> > >> On 10/10/2016 19:46, Eduardo Habkost wrote: > >>> I don't think we have a plan, but I would support deprecating and > >>> removing very old machine-types. The question is: how old is too > >>> old? > >>> > >>> For reference, the commits and dates when each machine-type was > >>> added are below: > >>> > >>> machine commitcommit date release release date > >>> pc-0.10 e8b2a1c6 Jul 8 2009 v0.11.0 Sep 22 2009 > >>> pc-0.13 95747581 Jul 22 2009 v0.12.0 Dec 19 2009 > >>> pc-0.12 2cae6f5e Jan 8 2010 v0.13.0 Oct 14 2010 > >>> pc-0.13 d76fa62d Feb 15 2010 v0.13.0 Oct 14 2010 > >>> pc-0.14 b903a0f7 Nov 11 2010 v0.14.0 Feb 16 2011 > >>> pc-0.15 ce01a508 Dec 18 2011 v1.1.0 Jun 1 2012 > >>> pc-1.019857e62 Nov 7 2011 v1.0 Dec 1 2011 > >>> pc-1.1382b3a68 Feb 21 2012 v1.1.0 Jun 1 2012 > >>> pc-1.2f1dacf1c Jun 11 2012 v1.2.0 Sep 5 2012 > >>> pc-1.3f4306941 Sep 13 2012 v1.3.0 Dec 3 2012 > >> > >> Anything before pc-1.3 has issues with migration due to the introduction > >> of the memory API. Basically, 0xf-0xf is not migrated > >> correctly, and the result is that rebooting after migration causes the > >> guest to crash. So that could be a reasonable place to draw the line at. > > > > That is a one-off special case - I think it would be desirable to come up > > with a general rule we can follow indefinitely, which we can apply at the > > start of each release cycle to purge old stuff. > > > > If we wanted to pick pc-1.3 as the starting point and generalize it, we > > choose declare we'll support machine types for 4 years. Or we could do > > it in terms of number of releases - eg we'll support the last N releases > > (for 3/releases per year cadence, that'd be N == 12) > > I don't know, it's already boring to create a new machine every time... > I would hate to have to remove one or more machine types every three > months. Consider that adding new machine types will hardly introduce > bugs; what causes bugs is removing them. I wouldn't like to _have_ to remove them, but I would love to have a clear policy that would set user expectations and allow us to remove some of them once in a while. -- Eduardo
Re: [Qemu-devel] Deprecating old machine-types (was Re: [PATCH v4 7/8] intel_iommu: keep buggy EIM enabled in 2.7 machine type)
On 11/10/2016 10:23, Daniel P. Berrange wrote: > On Tue, Oct 11, 2016 at 09:36:29AM +0200, Paolo Bonzini wrote: >> >> >> On 10/10/2016 19:46, Eduardo Habkost wrote: >>> I don't think we have a plan, but I would support deprecating and >>> removing very old machine-types. The question is: how old is too >>> old? >>> >>> For reference, the commits and dates when each machine-type was >>> added are below: >>> >>> machine commitcommit date release release date >>> pc-0.10 e8b2a1c6 Jul 8 2009 v0.11.0 Sep 22 2009 >>> pc-0.13 95747581 Jul 22 2009 v0.12.0 Dec 19 2009 >>> pc-0.12 2cae6f5e Jan 8 2010 v0.13.0 Oct 14 2010 >>> pc-0.13 d76fa62d Feb 15 2010 v0.13.0 Oct 14 2010 >>> pc-0.14 b903a0f7 Nov 11 2010 v0.14.0 Feb 16 2011 >>> pc-0.15 ce01a508 Dec 18 2011 v1.1.0 Jun 1 2012 >>> pc-1.019857e62 Nov 7 2011 v1.0 Dec 1 2011 >>> pc-1.1382b3a68 Feb 21 2012 v1.1.0 Jun 1 2012 >>> pc-1.2f1dacf1c Jun 11 2012 v1.2.0 Sep 5 2012 >>> pc-1.3f4306941 Sep 13 2012 v1.3.0 Dec 3 2012 >> >> Anything before pc-1.3 has issues with migration due to the introduction >> of the memory API. Basically, 0xf-0xf is not migrated >> correctly, and the result is that rebooting after migration causes the >> guest to crash. So that could be a reasonable place to draw the line at. > > That is a one-off special case - I think it would be desirable to come up > with a general rule we can follow indefinitely, which we can apply at the > start of each release cycle to purge old stuff. > > If we wanted to pick pc-1.3 as the starting point and generalize it, we > choose declare we'll support machine types for 4 years. Or we could do > it in terms of number of releases - eg we'll support the last N releases > (for 3/releases per year cadence, that'd be N == 12) I don't know, it's already boring to create a new machine every time... I would hate to have to remove one or more machine types every three months. Consider that adding new machine types will hardly introduce bugs; what causes bugs is removing them. Paolo
Re: [Qemu-devel] Deprecating old machine-types (was Re: [PATCH v4 7/8] intel_iommu: keep buggy EIM enabled in 2.7 machine type)
On Tue, Oct 11, 2016 at 09:36:29AM +0200, Paolo Bonzini wrote: > > > On 10/10/2016 19:46, Eduardo Habkost wrote: > > I don't think we have a plan, but I would support deprecating and > > removing very old machine-types. The question is: how old is too > > old? > > > > For reference, the commits and dates when each machine-type was > > added are below: > > > > machine commitcommit date release release date > > pc-0.10 e8b2a1c6 Jul 8 2009 v0.11.0 Sep 22 2009 > > pc-0.13 95747581 Jul 22 2009 v0.12.0 Dec 19 2009 > > pc-0.12 2cae6f5e Jan 8 2010 v0.13.0 Oct 14 2010 > > pc-0.13 d76fa62d Feb 15 2010 v0.13.0 Oct 14 2010 > > pc-0.14 b903a0f7 Nov 11 2010 v0.14.0 Feb 16 2011 > > pc-0.15 ce01a508 Dec 18 2011 v1.1.0 Jun 1 2012 > > pc-1.019857e62 Nov 7 2011 v1.0 Dec 1 2011 > > pc-1.1382b3a68 Feb 21 2012 v1.1.0 Jun 1 2012 > > pc-1.2f1dacf1c Jun 11 2012 v1.2.0 Sep 5 2012 > > pc-1.3f4306941 Sep 13 2012 v1.3.0 Dec 3 2012 > > Anything before pc-1.3 has issues with migration due to the introduction > of the memory API. Basically, 0xf-0xf is not migrated > correctly, and the result is that rebooting after migration causes the > guest to crash. So that could be a reasonable place to draw the line at. That is a one-off special case - I think it would be desirable to come up with a general rule we can follow indefinitely, which we can apply at the start of each release cycle to purge old stuff. If we wanted to pick pc-1.3 as the starting point and generalize it, we choose declare we'll support machine types for 4 years. Or we could do it in terms of number of releases - eg we'll support the last N releases (for 3/releases per year cadence, that'd be N == 12) Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
Re: [Qemu-devel] Deprecating old machine-types (was Re: [PATCH v4 7/8] intel_iommu: keep buggy EIM enabled in 2.7 machine type)
On 10/10/2016 19:46, Eduardo Habkost wrote: > I don't think we have a plan, but I would support deprecating and > removing very old machine-types. The question is: how old is too > old? > > For reference, the commits and dates when each machine-type was > added are below: > > machine commitcommit date release release date > pc-0.10 e8b2a1c6 Jul 8 2009 v0.11.0 Sep 22 2009 > pc-0.13 95747581 Jul 22 2009 v0.12.0 Dec 19 2009 > pc-0.12 2cae6f5e Jan 8 2010 v0.13.0 Oct 14 2010 > pc-0.13 d76fa62d Feb 15 2010 v0.13.0 Oct 14 2010 > pc-0.14 b903a0f7 Nov 11 2010 v0.14.0 Feb 16 2011 > pc-0.15 ce01a508 Dec 18 2011 v1.1.0 Jun 1 2012 > pc-1.019857e62 Nov 7 2011 v1.0 Dec 1 2011 > pc-1.1382b3a68 Feb 21 2012 v1.1.0 Jun 1 2012 > pc-1.2f1dacf1c Jun 11 2012 v1.2.0 Sep 5 2012 > pc-1.3f4306941 Sep 13 2012 v1.3.0 Dec 3 2012 Anything before pc-1.3 has issues with migration due to the introduction of the memory API. Basically, 0xf-0xf is not migrated correctly, and the result is that rebooting after migration causes the guest to crash. So that could be a reasonable place to draw the line at. Paolo
