From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xb8fM-0008Iq-69 for qemu-devel@nongnu.org; Mon, 06 Oct 2014 09:49:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xb8fG-0000VR-1U for qemu-devel@nongnu.org; Mon, 06 Oct 2014 09:49:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xb8fF-0000Tm-Pz for qemu-devel@nongnu.org; Mon, 06 Oct 2014 09:49:25 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s96DnORR011925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 6 Oct 2014 09:49:24 -0400 Date: Mon, 6 Oct 2014 16:52:53 +0300 From: "Michael S. Tsirkin" Message-ID: <20141006135253.GA29563@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> <20141002134905.GC26273@redhat.com> <54329C29.9070508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54329C29.9070508@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 Mon, Oct 06, 2014 at 03:42:01PM +0200, Paolo Bonzini wrote: > Il 02/10/2014 15:49, Michael S. Tsirkin ha scritto: > >>> 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. > > > > Migrating RAM size is actually useful too, I think someone asked for it. > > Migrating RAM size was discussed for BIOS and option ROMs, in order to > support migration from old versions of QEMU. It was floated around for > some time, but ultimately we ended up shipping two copies of affected > firmware (128k/256k BIOS, and non-EFI/EFI option ROMs). > > For BIOS it wouldn't be enough, because the BIOS size affects the memory > map. Of course ACPI tables aren't mapped anywhere, but I'd be wary of > adding code to migration that is half-broken and almost never used. > > Also, RAM blocks that have different size would be yet another thing > that makes machine types "almost compatible" with the QEMU version > they're supposed to represent. In a scenario similar to John's, with > mutable RAM sizes, would have likely broken all machine types, because > we would not have bothered doing full backwards-compatibility. > > I'm not an advocate of backwards bug-compatibility, but I think RAM > block sizes are way beyond the line of what we should be allowed to > modify between machine types. > > Paolo Maybe we should just modify ACPI and rom files in general to use something else, not RAM? It looked like a good fit initially so we went ahead with it, but these things are fairly small, so it's not a problem to migrate them as part of the device state. -- MST