On Wed, Nov 19, 2014 at 09:16:09AM +0100, Markus Armbruster wrote: > "Michael S. Tsirkin" <m...@redhat.com> writes: > > > On Tue, Nov 18, 2014 at 03:47:16PM +0100, Markus Armbruster wrote: > >> "Michael S. Tsirkin" <m...@redhat.com> 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
