From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZgTM-0003zJ-G5 for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:31:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZgTF-0004Gv-F9 for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:31:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZgTF-0004Gk-6c for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:31:01 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s92DV0uQ006700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 2 Oct 2014 09:31:00 -0400 Message-ID: <542D5391.8080007@redhat.com> Date: Thu, 02 Oct 2014 15:30:57 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1411057074-11157-1-git-send-email-pbonzini@redhat.com> <20141002121140.GA25373@redhat.com> In-Reply-To: <20141002121140.GA25373@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 0/6] pc: bring ACPI table size below to 2.0 levels, try fixing -initrd for good List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: jsnow@redhat.com, qemu-devel@nongnu.org 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. Extreme example: the guest could expect the size to remain the same at boot time and S3 resume time. So I think the fw_cfg size is guest ABI and cannot change across migration anyway. > 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(-)