From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5Vc-00044j-B9 for qemu-devel@nongnu.org; Wed, 19 Nov 2014 08:41:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr5VV-0006qB-0B for qemu-devel@nongnu.org; Wed, 19 Nov 2014 08:41:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36371) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5VU-0006py-Nn for qemu-devel@nongnu.org; Wed, 19 Nov 2014 08:41:16 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAJDfFff013434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 19 Nov 2014 08:41:15 -0500 Date: Wed, 19 Nov 2014 15:41:11 +0200 From: "Michael S. Tsirkin" Message-ID: <20141119134111.GB27488@redhat.com> References: <1416254843-16859-1-git-send-email-mst@redhat.com> <87sihgmuq3.fsf@blackfin.pond.sub.org> <20141118150033.GA23256@redhat.com> <87zjbn7ghi.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zjbn7ghi.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, qemu-devel@nongnu.org, dgilbert@redhat.com, Juan Quintela On Wed, Nov 19, 2014 at 09:16:09AM +0100, Markus Armbruster wrote: > "Michael S. Tsirkin" writes: > > > 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. > > Are you proposing to change ROM size on the target from "whatever was > configured during startup" to "whatever is configured on the source"? Exactly. ROMs are running within guest, they should just migrate together with VM. *They already do* except for their size. Which kind of mostly does not create problems anyway because we round size up. -- MST