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 <aligu...@us.ibm.com>
> >>>>
> >>>> 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.
