From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBnU1-0007wM-BX for qemu-devel@nongnu.org; Mon, 28 Jul 2014 12:09:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBnTt-0003Rn-SZ for qemu-devel@nongnu.org; Mon, 28 Jul 2014 12:09:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25658) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBnTt-0003Rh-L4 for qemu-devel@nongnu.org; Mon, 28 Jul 2014 12:08:57 -0400 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 (8.14.4/8.14.4) with ESMTP id s6SG8ugQ028022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 28 Jul 2014 12:08:57 -0400 Message-ID: <53D67595.2000702@redhat.com> Date: Mon, 28 Jul 2014 18:08:53 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1406561658-6761-1-git-send-email-pbonzini@redhat.com> <1406561658-6761-4-git-send-email-pbonzini@redhat.com> <20140728155907.GA30104@redhat.com> In-Reply-To: <20140728155907.GA30104@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/5] pc: future-proof migration-compatibility of ACPI tables List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: imammedo@redhat.com, lersek@redhat.com, qemu-devel@nongnu.org Il 28/07/2014 17:59, Michael S. Tsirkin ha scritto: > On Mon, Jul 28, 2014 at 05:34:16PM +0200, Paolo Bonzini wrote: >> This patch avoids that similar changes break QEMU again in the future. >> QEMU will now hard-code 64k as the maximum ACPI table size, which >> (despite being an order of magnitude smaller than 640k) should be enough >> for everyone. > > Famous last words :) So what worries me here, is that we > are potentially breaking legal configurations for the > benefit of the minority that cares about cross-version > migration. > > So I'm inclined to apply everything except this patch, and > instead, use the patches that I sent to make the > ram block very large, something like 1 Megabyte. Even just 128k are enough for 160 VCPUs, 255 memory slots and 35-40 PCI bridges. And for 2.2 I'd rather move to the other model where all user-defined elements (MADT, SSDT) are in a separate file and we guarantee that *all* changes are versioned by machine type. What do you think about just changing 64k->128k? Your patch is a huge amount of code for -rc4. Paolo