Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Sep 18, 2014 at 06:17:48PM +0200, 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.

I'm not sure I got this one.
Why is this padding more robust than the one we have now?

> 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.
> 
> This is done in patches 4-6.
> 
> However, there is another problem.  As the ACPI tables grow, we need
> to move the address at which linuxboot.bin loads the initrd.  This
> address is placed close to the end of memory, but it is QEMU that
> tells linuxboot.bin where exactly the initrd is to be loaded.  And
> QEMU cannot really know how much high memory SeaBIOS will use, because
> QEMU does not know the final e820 memory map.
> 
> The solution would be to let linuxboot.bin parse the memory map and
> ignore the suggested initrd base address, but that's tedious.  In the
> meanwhile, we can just assume that most of the need comes from the ACPI
> tables (which is in fact true: patch 3 adds a fixed 32k extra just in
> case) and dynamically resize the padding.
> 
> This is what patches 1-3 do.  The nice part is that they also remove
> some differences between Xen and other accelerators.  I would appreciate
> Xen testing from interested people.
> 
> Thanks,
> 
> Paolo


I'm not inclined to apply this for 2.2.

Summarizing what you say, there are two issues around ACPI tables:
- linuxboot uses FW CFG to for memory allocations,
  seabios ignores that, so they might conflict.
  Let's fix either linuxboot or seabios (or both!)
  and forget about it.

- table size changes cause cross version migration issues
  this is really due to the fact we are using RAM
  to migrate ACPI tables.
  IMHO a more robust fix would be to allow RAM size to change
  during migration, or to avoid using RAM, switch to another type of
  object.

So both issues have other solutions, and I think it's a good
idea to focus on them for now.
Also, I really would like to avoid having ACPI sizing-related
issues for this release. The memory of 2.1.X pain is too fresh :)
I'm not NACKing this patchset, but let's
make some progress on the bigger issues listed above, then come
back and address sizing as appropriate.

Thanks!

> 
> Paolo Bonzini (6):
>     pc: initialize fw_cfg earlier
>     pc: load the kernel after ACPI tables are built
>     pc: redo sizing of reserved high memory area for -kernel/-initrd
>     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 |   23 +++++++++-------
>  hw/i386/pc.c         |   72 +++++++++++++++++----------------------------------
>  hw/i386/pc_piix.c    |   32 ++++++++++++++--------
>  hw/i386/pc_q35.c     |    7 ++--
>  include/hw/i386/pc.h |    4 ++
>  5 files changed, 66 insertions(+), 72 deletions(-)