From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqkGq-0007GR-I0 for qemu-devel@nongnu.org; Tue, 18 Nov 2014 10:00:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqkGj-0003a9-TH for qemu-devel@nongnu.org; Tue, 18 Nov 2014 10:00:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqkGj-0003Zz-Jx for qemu-devel@nongnu.org; Tue, 18 Nov 2014 10:00:37 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAIF0aML024148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 18 Nov 2014 10:00:36 -0500 Date: Tue, 18 Nov 2014 17:00:33 +0200 From: "Michael S. Tsirkin" Message-ID: <20141118150033.GA23256@redhat.com> References: <1416254843-16859-1-git-send-email-mst@redhat.com> <87sihgmuq3.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sihgmuq3.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH 0/5] pc: make ROMs resizeable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: pbonzini@redhat.com, Juan Quintela , qemu-devel@nongnu.org, dgilbert@redhat.com On Tue, Nov 18, 2014 at 03:47:16PM +0100, Markus Armbruster wrote: > "Michael S. Tsirkin" writes: > > > At the moment we migrate ROMs which reside in fw cfg, which allows > > changing ROM code at will, and supports migrating largish blocks early, > > with good performance. > > However, we are running into a problem: changing size breaks > > migration every time. > > Pardon my ignorance... changing ROM in migration? I would expect > migration to be as transparent for ROM as it is for RAM. What am I > missing? > > [...] Nothing really. We migrate RAM size too - but if there's a mismatch, migration fails. RAM size is user configurable. ROM is used internally so we have to figure out the size, and it turned out to be a hard problem, so we end up maintaining logic for ROM size "like we did in 1.7" "like we did in 2.0" etc. I don't want to add any more: let's just accept whatever is migrated, and stick to it. -- MST