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