Re: [Qemu-devel] [PATCH 3/5] pc: future-proof migration-compatibility of ACPI tables
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? -- MST
Re: [Qemu-devel] [PATCH 3/5] pc: future-proof migration-compatibility of ACPI tables
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
Re: [Qemu-devel] [PATCH 3/5] pc: future-proof migration-compatibility of ACPI tables
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_SIZE97
> #define ACPI_BUILD_ALIGN_SIZE 0x1000
>
> +#define ACPI_BUILD_TABLE_SIZE 0x1
> +
> 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
>
[Qemu-devel] [PATCH 3/5] pc: future-proof migration-compatibility of ACPI tables
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.
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_SIZE97
#define ACPI_BUILD_ALIGN_SIZE 0x1000
+#define ACPI_BUILD_TABLE_SIZE 0x1
+
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
[Qemu-devel] [PATCH 3/5] pc: future-proof migration-compatibility of ACPI tables
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.
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 7d2251f..8d42eaf 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -63,6 +63,8 @@
#define ACPI_BUILD_LEGACY_BRIDGE_AML_SIZE 1875
#define ACPI_BUILD_ALIGN_SIZE 0x1000
+#define ACPI_BUILD_TABLE_SIZE 0x1
+
typedef struct AcpiCpuInfo {
DECLARE_BITMAP(found_cpus, ACPI_CPU_HOTPLUG_ID_LIMIT);
} AcpiCpuInfo;
@@ -1593,7 +1595,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
