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
