From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBnKF-0000bs-2Z for qemu-devel@nongnu.org; Mon, 28 Jul 2014 11:59:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBnK7-0000Ag-6z for qemu-devel@nongnu.org; Mon, 28 Jul 2014 11:58:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBnK6-0000Aa-Uu for qemu-devel@nongnu.org; Mon, 28 Jul 2014 11:58:51 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6SFwomN005085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 28 Jul 2014 11:58:50 -0400 Date: Mon, 28 Jul 2014 17:59:07 +0200 From: "Michael S. Tsirkin" Message-ID: <20140728155907.GA30104@redhat.com> References: <1406561658-6761-1-git-send-email-pbonzini@redhat.com> <1406561658-6761-4-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1406561658-6761-4-git-send-email-pbonzini@redhat.com> 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: Paolo Bonzini Cc: imammedo@redhat.com, lersek@redhat.com, qemu-devel@nongnu.org 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. This localizes the pain to cross-version migration. > > Reviewed-by: Laszlo Ersek > Tested-by: Igor Mammedov > Signed-off-by: Paolo Bonzini > --- > hw/i386/acpi-build.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > index a3d5822..25cf297 100644 > --- a/hw/i386/acpi-build.c > +++ b/hw/i386/acpi-build.c > @@ -62,6 +62,8 @@ > #define ACPI_BUILD_LEGACY_CPU_AML_SIZE 97 > #define ACPI_BUILD_ALIGN_SIZE 0x1000 > > +#define ACPI_BUILD_TABLE_SIZE 0x10000 > + > typedef struct AcpiCpuInfo { > DECLARE_BITMAP(found_cpus, ACPI_CPU_HOTPLUG_ID_LIMIT); > } AcpiCpuInfo; > @@ -1569,7 +1571,13 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables *tables) > } > g_array_set_size(tables->table_data, legacy_table_size); > } else { > - acpi_align_size(tables->table_data, ACPI_BUILD_ALIGN_SIZE); > + if (tables->table_data->len > ACPI_BUILD_TABLE_SIZE) { > + /* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots. */ > + error_report("ACPI tables are larger than 64k. Please remove"); > + error_report("CPUs, NUMA nodes, memory slots or PCI bridges."); > + exit(1); > + } > + g_array_set_size(tables->table_data, ACPI_BUILD_TABLE_SIZE); > } > > acpi_align_size(tables->linker, ACPI_BUILD_ALIGN_SIZE); > -- > 1.8.3.1 >