On Wed, 23 Jul 2014 18:37:44 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote:
> Changing the ACPI table size causes migration to break, and the memory > hotplug work opened our eyes on how horribly we were breaking things in > 2.0 already. > > Unfortunately when reviewing the design I assumed incorrectly that all > tables would be placed in separate fw_cfg files. This would have been > better, because you can always move stuff to a new SSDT (and thus a new > file), keeping the sizes under control. > > Hard-code 64k as the maximum ACPI table size; for -M pc-i440fx-2.0 > and -M pc-i440fx-1.7 compute the payload size of QEMU 2.0 and always > use that one. This works always for QEMU 2.0, and also for 1.7 > except for a few values of "-smp maxcpus". > > The first patch is needed to shrink the ACPI tables and make them > smaller than they used to be in 2.0. > > Please test and ack. I'll do more testing tomorrow. > > Paolo > > > Paolo Bonzini (2): > acpi-dsdt: procedurally generate _PRT > pc: hack for migration compatibility from QEMU 2.0 > > hw/i386/acpi-build.c | 61 +++++++++++++++++++++++++++++++--- > hw/i386/acpi-dsdt.dsl | 90 > ++++++++++++++++++++++----------------------------- > hw/i386/pc_piix.c | 20 ++++++++++++ > hw/i386/pc_q35.c | 5 +++ > include/hw/i386/pc.h | 1 + > 5 files changed, 122 insertions(+), 55 deletions(-) > Aside of my cosmetic comments per-patch, I've tested series with booting guest in QEMU 1.7, migrating to QEMU 2.1 and rebooting guest there with WS2003Ex64, WS2008DCx32, WS2012DCx64, WS2012RC2x64 guest OSes, so on respin you can use my: Tested-by: Igor Mammedov <imamm...@redhat.com>