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

[Paolo Bonzini]

Il 02/10/2014 14:11, Michael S. Tsirkin ha scritto:
> 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?

Because the current one applies to all ACPI tables.  After this patch,
the padding only applies to the "fixed" tables (FACS, FADT, DSDT).

With the old algorithm, a small change in the DSDT, combined with the
"right" size of the MADT/SSDT, could cause a change in the rounded size.

With the new algorithm, any change in the DSDT will either break
migration or will not, independent of the content of the SSDT.

Example with the old algorithm (up to 2.0):

                         old version of QEMU       new version of QEMU
    fixed table size       4000                      4100
    variable table size    4100                      4100
    total size             8100                      8100
    4k-rounded size        8192                     12288

In 2.1 we changed the rounding to 128k, but the fundamental problem
remains and that is why we warn for ACPI tables whose size is above 64k.

The same example with new algorithm:

                         old version of QEMU       new version of QEMU
    fixed table size       4000                      4100
      padded to           16384                     16384
    variable table size    4100                      4100
    total size            17484                     17484
    4k-rounded size       20480                     20480

Paolo

>> 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(-)
> 
>