From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVGT5-0003Ru-EB for qemu-devel@nongnu.org; Fri, 28 Aug 2015 06:01:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVGT0-0004Ub-Du for qemu-devel@nongnu.org; Fri, 28 Aug 2015 06:01:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVGT0-0004T7-6W for qemu-devel@nongnu.org; Fri, 28 Aug 2015 06:01:02 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 1626E8E67B for ; Fri, 28 Aug 2015 10:01:01 +0000 (UTC) From: Markus Armbruster References: <1439939502-4722-1-git-send-email-ehabkost@redhat.com> <20150819095526.GB2332@work-vm> <55D4C813.1070308@redhat.com> <87vbc5qadz.fsf@blackfin.pond.sub.org> <20150825162116.GD25920@redhat.com> <20150827134638-mutt-send-email-mst@redhat.com> <20150827182629.GK4230@thinpad.lan.raisama.net> Date: Fri, 28 Aug 2015 12:00:58 +0200 In-Reply-To: <20150827182629.GK4230@thinpad.lan.raisama.net> (Eduardo Habkost's message of "Thu, 27 Aug 2015 15:26:29 -0300") Message-ID: <874mjjd95x.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] q35: Remove old machine versions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Marcel Apfelbaum , Laszlo Ersek , "Michael S. Tsirkin" , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Paolo Bonzini , John Snow Eduardo Habkost 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 writes: >> > > >> > > > On 08/19/2015 02:55 AM, Dr. David Alan Gilbert wrote: >> > > >> * Eduardo Habkost (ehabkost@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.