Re: [Qemu-devel] [PULL 0/8] pc: resizeable ROM blocks

[Paolo Bonzini]

On 24/12/2014 13:41, Michael S. Tsirkin wrote:
>> I don't think these are necessary, and I thought these were just RFC
>> when they were posted.  I and mst didn't really understand each other,
>> and I take the fault for not reviewing the submission; however, Peter,
>> please hold these for a little more.
>>
>> Paolo
> 
> Yes, please do, I'd like Paolo to review at least the memory core
> changes.

I don't have any issue with the implementation; I'm just not sure that
this is necessary.

My point is that until ACPI tables are actually trimmed, migration
really won't be broken.  So there is no need to apply these patches
until/unless we are ready to trim the tables.

Worst case, some scenarios can now print the "migration may not work"
warning if ACPI tables go from <64k to >64k.  But migration actually
will work until the tables shoot beyond >128k.

The warning sucks, and the workaround we have (round to twice the
"expected" maximum size for "reasonable" VMs) is limited and hence also
sucks.  But it _does_ work as a stopgap until we figure out what
migration of ACPI tables really entails.

The question then is: when should we trim the tables?  Because answering
that question also answers whether we should apply your patches.  My
answer to that question is "not anytime soon", perhaps 2.4 but more
likely 2.5.

For 2.3, the target should be the two other pending ACPI series that
reorganize the tables.  In different and complementary ways, both
attempt at making the tables more predictable and thus mitigate or
resolve the migration problems.  My patches add some separation between
"mutable" and "constant" tables.  Igor's patches make "constant" tables
really constant by taking IASL out of the equation.  (Note that if
useful, the C generation can also be applied to the mutable tables; it's
also possible to have a mutable SSDT and a constant one, the only
requirement for mutable tables is that their size be bounded).

I cannot of course be sure of how the ACPI tables will evolve in the
future.  But we can give a try to the improvements that I and Igor
introduced for a release cycle or two.  For those releases we can still
keep the 128k ACPI tables, and detect breakage using bios-tables-test.
We can improve the test to check table sizes (not contents) for a bunch
of configurations.  We only need to cover edges, not paths, so it's not
hard to do.

Paolo