From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9rXr-0004nl-D8 for qemu-devel@nongnu.org; Fri, 18 Dec 2015 04:41:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9rXo-0001Oi-N6 for qemu-devel@nongnu.org; Fri, 18 Dec 2015 04:41:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9rXo-0001OZ-Hi for qemu-devel@nongnu.org; Fri, 18 Dec 2015 04:41:48 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 933D091C15 for ; Fri, 18 Dec 2015 09:41:47 +0000 (UTC) Message-ID: <1450431705.15674.26.camel@redhat.com> From: Gerd Hoffmann Date: Fri, 18 Dec 2015 10:41:45 +0100 In-Reply-To: <1450373244-27585-1-git-send-email-ehabkost@redhat.com> References: <1450373244-27585-1-git-send-email-ehabkost@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] [RESEND PATCH] q35: Remove old machine versions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Victor Kaplansky , Marcel Apfelbaum , John Snow , "Michael S. Tsirkin" , Markus Armbruster , qemu-devel@nongnu.org, Paolo Bonzini , Laszlo Ersek , "Dr. David Alan Gilbert" On Do, 2015-12-17 at 15:27 -0200, Eduardo Habkost 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 > machine classes before pc-q35-2.4 were not migratable, so there's no > point in keeping compatibility code for them. >=20 > Remove all old pc-q35 machine classes and keep only pc-q35-2.4. > -static void pc_compat_1_6(MachineState *machine) > -{ > - pc_compat_1_7(machine); > - rom_file_has_mr =3D false; > - has_acpi_build =3D false; After applying this patch has_acpi_build is always true and can be dropped, together with some other code elsewhere which depends on has_acpi_build. The same is probably true for other variables as well (gigabyte_align?). Guess it's best to do this as one-per-variable incremental patches. Reviewed-by: Gerd Hoffmann