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

[Markus Armbruster]

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