From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xb8YK-0006Ax-IZ for qemu-devel@nongnu.org; Mon, 06 Oct 2014 09:42:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xb8YB-0005X1-HB for qemu-devel@nongnu.org; Mon, 06 Oct 2014 09:42:16 -0400 Received: from mail-qa0-x234.google.com ([2607:f8b0:400d:c00::234]:33709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xb8YB-0005Wp-D1 for qemu-devel@nongnu.org; Mon, 06 Oct 2014 09:42:07 -0400 Received: by mail-qa0-f52.google.com with SMTP id dc16so3415205qab.25 for ; Mon, 06 Oct 2014 06:42:06 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <54329C29.9070508@redhat.com> Date: Mon, 06 Oct 2014 15:42:01 +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> <542D5687.3050604@redhat.com> <20141002134905.GC26273@redhat.com> In-Reply-To: <20141002134905.GC26273@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 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