Re: [Qemu-devel] Deprecating old machine-types (was Re: [PATCH v4 7/8] intel_iommu: keep buggy EIM enabled in 2.7 machine type)

[Eduardo Habkost <ehabkost@redhat.com>]

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   commit    commit 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.0    19857e62  Nov 7 2011   v1.0     Dec 1 2011
> >>> pc-1.1    382b3a68  Feb 21 2012  v1.1.0   Jun 1 2012
> >>> pc-1.2    f1dacf1c  Jun 11 2012  v1.2.0   Sep 5 2012
> >>> pc-1.3    f4306941  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, 0xf0000-0xfffff 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