Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Michael S. Tsirkin]

On Thu, Nov 20, 2014 at 07:05:05AM +0100, Paolo Bonzini wrote:
> 
> 
> On 11/11/2014 18:13, Paolo Bonzini wrote:
> > 
> > 
> > On 06/10/2014 16:56, Paolo Bonzini wrote:
> >> In the emergency last-minute patches of QEMU 2.1 we did two things:
> >>
> >> - fixed migration problems from 1.7 or 2.0 to 2.1 due to changes in
> >>   ACPI table sizes
> >>
> >> - ensured that future versions will not break migration compatibility
> >>   with 2.2 for reasonable configurations (with ACPI tables smaller
> >>   than a hundred kilobytes, roughly)
> >>
> >> However, this came at the cost of wasting 128 KB unconditionally on
> >> even the smaller configuration, and we didn't provide a mechanism to
> >> ensure compatibility with larger configurations.
> >>
> >> This series provides this mechanism.  As mentioned early, the design
> >> is to consider the SSDT immutable and versioned (together with other
> >> non-AML tables such as HPET, TPMA and MADT, SRAT, MCFG, DMAR).
> >> The DSDT instead can change more or less arbitrarily.  To do this,
> >> we add padding after the DSDT to allow for future growth (patch 1).
> >>
> >> Once we do this, the size of the ACPI table fw_cfg "file" is constant
> >> given a machine type and a command-line, so we do not need anymore the
> >> larger 128KB padding (patch 2).
> >>
> >> Patch 3 is just cleanups.
> >>
> >> Paolo
> >>
> >> v1->v2: drop linuxboot changes, instead modify the option ROM
> >>         in a separate patch
> >>
> >> Paolo Bonzini (3):
> >>   pc: introduce new ACPI table sizing algorithm
> >>   pc: go back to smaller ACPI tables
> >>   pc: clean up pre-2.1 compatibility code
> >>
> >>  hw/i386/acpi-build.c | 20 +++++++++++---------
> >>  hw/i386/pc_piix.c    | 20 +++++++++++++++++++-
> >>  hw/i386/pc_q35.c     |  6 ++++--
> >>  include/hw/i386/pc.h |  2 ++
> >>  4 files changed, 36 insertions(+), 12 deletions(-)
> >>
> > 
> > Ping?
> 
> Ping??
> 
> Paolo

I thought we agreed we'll consider alternate approaches after 2.2?
I would prefer not to have yet another mode to support
if we can help it.

-- 
MST