| Message ID | 1406561658-6761-4-git-send-email-pbonzini@redhat.com |
|---|---|
| State | New |
| Headers | show |
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 <lersek@redhat.com> > Tested-by: Igor Mammedov <imammedo@redhat.com> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > 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 >
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
On Mon, Jul 28, 2014 at 06:08:53PM +0200, Paolo Bonzini wrote: > 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 True ... OK I applied this, and made minor tweaks on top. Any reviewers?
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);