[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.

[Gleb Natapov]

On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
> >>Gleb Natapov wrote:
> >>>On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
> >>>>From: Anthony Liguori <address@hidden>
> >>>>
> >>>> Hi,
> >>>>
> >>>>Option rom saga continued.  This is the first series I consider ready
> >>>>for merging.  Changes:
> >>>>
> >>>> * pci roms: will be loaded via option pci rom bar.
> >>>> * non-pci roms: will be loaded via fw_cfg.
> >>>>
> >>>>Note that using the old bochs-bios based pc-bios will stop working
> >>>>with this patch series applied.
> >>>>
> >>>>The last two patches of this series are *not* intended to be merged,
> >>>>they are just for testing convinience.  They carry a new seabios
> >>>>binary and the changes needed and turn on bios debug messages in qemu.
> >>>>
> >>>>Seabios patches will be posted shortly as separate patch series.
> >>>>
> >>>I see that this is merged already, but I have a question. How migration
> >>>during ROM loading suppose to work?
> >>Magically :-)
> >>
> >>Really, we have a fundamentally problem with live migration (that's
> >>orthogonal to this series).  We allocate memory via qemu_ram_alloc()
> >>but we don't have any context to that allocation.  When we migrate
> >>memory, we do so by transferring ram basically in allocation order.
> >>
> >>If for some reason allocation order changes, badness ensues.  The
> >>problem is, a lot of devices use qemu_ram_alloc() now and they do so
> >>when they are initialized so the stability of the allocation depends
> >>on the initialization order.  It's exacerbated by things like PCI
> >>hotplug.
> >>
> >>We need to make a change in the live migration protocol that
> >>transfers memory identified with tuples (id, chunk offset).  We'll
> >>need to change every qemu_ram_alloc() to take an id argument too.
> >>
> >>>What will happed if we migrate to newer
> >>>qemu with updated vgabios ROM while BIOS is in the middle of loading it on 
> >>>the
> >>>source? It seems that destination will have garbled ROM loaded.
> >>During device init, pci device allocates memory, loads rom into
> >>allocated memory.  Upon live migration, allocated memory gets over
> >>written by rom contents from source.  So in this case, it will
> >>actually work today (assuming you get stable ram allocation
> >>offsets).
> >>
> >That much I noticed :), but first after reboot new ROMs should take effect.
> >Does this happed?
> 
> No.  You have to physically shut down and start up again.  That's
> the right semantics IMHO.
> 
Reset is equivalent (or should be) to shut down and start up again.

> > Second what if ROM size have changed (on destination it is
> >smaller)?
> 
> Then we're in trouble :-)
> 
Yeah, we are. May be relaying on file size is not good enough heuristic
to determine ROM BAR size.

> > And third what about roms that are loaded with fw_cfg interface (me
> >mentioning vgabios was not accident :))
> 
> vgabios will be loaded as a PCI rom.  -std vga still uses fw_cfg but
> that's a really easy fix.
I mean -std vga and other "genroms" (multiboot, linuxboot, vapic). 

> 
> But the fw_cfg rom loading doesn't seem handle migration :-/
> 
Looks like it. We should send them over during migration too.

--
                        Gleb.