From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctV4X-0007zQ-0W for qemu-devel@nongnu.org; Thu, 30 Mar 2017 04:04:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ctV4V-0004jm-SM for qemu-devel@nongnu.org; Thu, 30 Mar 2017 04:04:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43452) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ctV4V-0004j7-Kx for qemu-devel@nongnu.org; Thu, 30 Mar 2017 04:04:43 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AADDE624DF for ; Thu, 30 Mar 2017 08:04:42 +0000 (UTC) Message-ID: <1490861069.11091.55.camel@redhat.com> From: Gerd Hoffmann Date: Thu, 30 Mar 2017 10:04:29 +0200 In-Reply-To: <0eebf55d-aeb9-5426-001d-175b0cbfc60c@redhat.com> References: <3d1c16a1-ec05-0367-e569-64a63b34f2e3@redhat.com> <4a56f716-3528-ddd4-f8c4-f3f6b23c469a@redhat.com> <3044459b-65a3-ca78-c009-15de9823704a@redhat.com> <20170329164646.GD2501@work-vm> <0eebf55d-aeb9-5426-001d-175b0cbfc60c@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] Deprecating old machine types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Dr. David Alan Gilbert" , Thomas Huth , Juan Quintela , John Snow , qemu-devel@nongnu.org, "Michael S. Tsirkin" On Mi, 2017-03-29 at 18:58 +0200, Paolo Bonzini wrote: >=20 > On 29/03/2017 18:46, Dr. David Alan Gilbert wrote: > >> By the way, what about old machine types like "pc-0.10" ? Do we want t= o > >> carry them along forever (e.g. since it is not too complicated to > >> maintain?), or shall we get rid of those one day (e.g. with QEMU 3.0),= too? > > It seems reasonable to slowly deprecate them. > > I'm just not sure how slowly. >=20 > Some data: >=20 > - dropping 0.12, 0.13 _and_ isapc would let us kill the code for > rombar=3D0 (i.e. where QEMU copies ROM BARs directly to low memory). >=20 > - the oldest versions in use are probably 0.12 (CentOS 6) and 1.0 > (Ubuntu 12.04) >=20 > - migration from old versions is broken in various ways from at least > QEMU 1.2 and older. Maybe it is useful to discuss this more in terms of code we want drop instead of version numbers ... So, here is my (x86-centric) wishlist: * Drop support for isapc (already added that to the wiki a few days ago). Also isa-* devices where we have pci variants (isa-vga, isa-cirrus-vga, ne2k_isa). Any old guests without pci support (such as ms-dos) should be happy with "pc" having vga and ide ioports on the standard isa locations for backward compatibility and seabios handing all pci stuff. Plugging isa devices (soundblaster for example) into "pc" works too. So I can't see a compelling use case for isapc. IIRC we even had a release with broken isapc with nobody noticing during the -rc phase ... * Drop support for rombar, and also the code for the linear vbe framebuffer magically showing up at 0xe0000000. * Drop backward-compatibility with pre-memory-api qemu versions. I guess the memory api switch is one of the big reasons why live migration to older versions is broken. The memory api was merged in 1.0, so the above would imply dropping support for all pc-0.x machine types and isapc. The 1.0 release was tagged on Dec 1st 2011, more than five years ago. cheers, Gerd