From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAjRM-0001q9-Cx for qemu-devel@nongnu.org; Fri, 25 Jul 2014 13:38:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XAjRD-0004jM-7k for qemu-devel@nongnu.org; Fri, 25 Jul 2014 13:37:56 -0400 Sender: Paolo Bonzini Message-ID: <53D295E5.20900@redhat.com> Date: Fri, 25 Jul 2014 19:37:41 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1406303338-13212-1-git-send-email-imammedo@redhat.com> <1406303338-13212-3-git-send-email-imammedo@redhat.com> In-Reply-To: <1406303338-13212-3-git-send-email-imammedo@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.1 2/2] acpi: mark ACPI tables ROM blob as extend-able on migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, lersek@redhat.com, qemu-stable@nongnu.org, dgilbert@redhat.com, mst@redhat.com Il 25/07/2014 17:48, Igor Mammedov ha scritto: > It fixes migration failure for machine type pc-i440fx-1.7 from > QEMU 1.7/2.0 to QEMU 2.1 > > Migration fails due to ACPI tables size grows across 1.7-2.1 > versions. That causes ACPI tables ROM blob to change its size > differently for the same configurations on different QEMU versions. > As result migration code bails out when attempting to load > smaller ROM blob into a bigger one on a newer QEMU. > To trigger failure it's enough to add pci-bridge device to QEMU CLI > > Marking ACPI tables ROM blob as extend-able on migration allows > QEMU to load smaller ACPI tables from QEMU 1.7/2.0, fixing > forward migration failure introduced since 2.0 which affects > only configurations that cause ACPI ROM blob size change. This works in this case, and it is more friendly to downstreams indeed. It also is simpler, at least on the surface. I think the ramifications could be a bit larger than with my own patches, but still I guess it's more appropriate at this point of the release cycle. It doesn't handle the case of ACPI tables that shrink, which can happen as well. I guess if this ever happens we can just hard-code the table size of the "old" versions to something big enough (64K?) and keep using fine-grained sizing. I'd like a day or two to mull about it, but I have it even if the patches are applied. Peter, feel free to go ahead with Igor's patches. Paolo