From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZgfZ-0008Of-75 for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:43:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZgfT-0000oz-3Y for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:43:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZgfS-0000op-Si for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:43:39 -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 s92Dhclu013151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 2 Oct 2014 09:43:38 -0400 Message-ID: <542D5687.3050604@redhat.com> Date: Thu, 02 Oct 2014 15:43:35 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1411057074-11157-1-git-send-email-pbonzini@redhat.com> <20141002121140.GA25373@redhat.com> <542D5391.8080007@redhat.com> <20141002134137.GA26273@redhat.com> In-Reply-To: <20141002134137.GA26273@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 15:41, Michael S. Tsirkin ha scritto: > On Thu, Oct 02, 2014 at 03:30:57PM +0200, Paolo Bonzini wrote: >> 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. > > The issue is that incoming migration might have a different > fw_cfg size from what we have. Understood now. > I think migrating this value will solve the issue in a cleaner way. Perhaps. The question is whether it would complicate the forwards-migration code beyond what is sane. I think we are practically speaking stuck with RAM. Paolo