From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZghT-0001W0-QH for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:45:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZghN-0001aS-Gn for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:45:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZghN-0001aL-7X for qemu-devel@nongnu.org; Thu, 02 Oct 2014 09:45:37 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s92DjaXu027881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 2 Oct 2014 09:45:36 -0400 Date: Thu, 2 Oct 2014 16:49:05 +0300 From: "Michael S. Tsirkin" Message-ID: <20141002134905.GC26273@redhat.com> References: <1411057074-11157-1-git-send-email-pbonzini@redhat.com> <20141002121140.GA25373@redhat.com> <542D5391.8080007@redhat.com> <20141002134137.GA26273@redhat.com> <542D5687.3050604@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542D5687.3050604@redhat.com> 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: Paolo Bonzini Cc: jsnow@redhat.com, qemu-devel@nongnu.org On Thu, Oct 02, 2014 at 03:43:35PM +0200, Paolo Bonzini wrote: > 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 Migrating RAM size is actually useful too, I think someone asked for it. -- MST