From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UX6Xp-0000Am-3e for qemu-devel@nongnu.org; Tue, 30 Apr 2013 05:08:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UX6Xm-0001og-GD for qemu-devel@nongnu.org; Tue, 30 Apr 2013 05:08:17 -0400 Date: Tue, 30 Apr 2013 12:08:01 +0300 From: "Michael S. Tsirkin" Message-ID: <20130430090800.GA28318@redhat.com> References: <1360111706-13138-1-git-send-email-mdroth@linux.vnet.ibm.com> <87lib2cf6j.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lib2cf6j.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] [PATCH for-1.4 0/2] fix migration failure from 1.3 due to SeaBIOS size change List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: quintela@redhat.com, qemu-devel@nongnu.org, qemu-stable@nongnu.org, Michael Roth , owasserm@redhat.com, kraxel@redhat.com On Tue, Feb 05, 2013 at 09:08:20PM -0600, Anthony Liguori wrote: > Michael Roth writes: > > > Migration from 1.3 currently fails due to a mismatch between the expected size > > of 256KB and the received size of 128KB for seabios. This series attempts to > > fix the issue by allowing a resize function to be registered to handle resizing > > memory blocks to accomodate the source's, and using that to re-initialize > > "pc.bios" and "isa-bios" MemoryRegions based on the size of the incoming block. > > > > There are also 2 potential alternatives to this patch set: > > > > 1) When I compile seabios 1.7.2 locally I end up with a 128KB binary. > > So do I on Fedora 18. Unless someone has a reason why this is a bad > thing, I'll commit a 128kb binary and we can avoid this problem for 1.4. > > Obviously, we need to figure it out but that at least buys us some time... > > Regards, > > Anthony Liguori So we never bothered with this patch, and so it's still out. How about we apply this for 1.5? This way we, at least, won't have the problem with -M1.5 in the future. Barring that - early in 1.6 cycle? -- MST