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, Oct 02, 2014 at 03:30:57PM +0200, Paolo Bonzini wrote:
> Il 02/10/2014 14:11, Michael S. Tsirkin ha scritto:
> > 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.
> 
> We can fix linuxboot, it is easy.
> 
> These patches do fix John's scenario, but that is not the main issue.
> They are not an _attempt_ to fix it, they just do so more or less by
> chance.  Their real purpose is fixing the second issue:
> 
> > - 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.
> 
> Allowing fw_cfg size to change during migration (does not matter if it
> is stored in RAM or otherwise) is a huge can of worms because the host
> might have loaded the size and stored it somewhere, way before migration.

Right. I'm not suggesting it. I suggest migrating fw cfg size instead.

> Extreme example: the guest could expect the size to remain the same at
> boot time and S3 resume time.

AFAIK ACPI tables aren't re-read from QEMU at S3 resume.
So guest will always see the same tables that are currently
in RAM.

> So I think the fw_cfg size is guest ABI and cannot change across
> migration anyway.

But this is already the case, this is not the issue.

The issue is that incoming migration might have a different
fw_cfg size from what we have.

I think migrating this value will solve the issue in a cleaner way.


> 
> > 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 :)
> 
> Yeah, I understand that.  But I think the scary part of this series is
> actually the first two patches, rather than the ACPI sizing algorithm.
> 
> Paolo
> 
> > 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(-)