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

[Anthony Liguori <anthony@codemonkey.ws>]

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 <aliguori@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.

>  Second what if ROM size have changed (on destination it is
> smaller)?

Then we're in trouble :-)

>  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.

But the fw_cfg rom loading doesn't seem handle migration :-/

Regards,

Anthony Liguori