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

["Sebastian Herbszt" <herbszt@gmx.de>]

Anthony Liguori wrote:
> On 12/21/2009 12:24 PM, Sebastian Herbszt wrote:
>> As stated before i don't like the idea of automagically upgrading the 
>> firmware
>> on reset, e.g. after a live migration to a newer qemu version. You 
>> have explained
>> that qemu-kvm needs this in order to work with live migration and 
>> changed hw
>> support because of bug fixes. Is this only needed in the kvm case?
> 
> It's not "needed", it's desired.  The same case can be made for real 
> hardware (automated firmware updates).

Tho on real hardware those updates are initiated by someone and not
automagic.

>> Does any OS (Windows?) depend on the tables the bios creates (e.g. 
>> smbios)
>> for licensing? It would be ugly if Windows wants you to re-activate 
>> after a reboot
>> following a migration to newer qemu version and therefore possibly 
>> changed tables
>> due to newer bios.
> 
> Yes, and this is a good point.  ACPI table changes can absolutely cause 
> re-activation.  If we migrate from 0.12 -> 0.13 and make major changes 
> to the ACPI tables in 0.13, then it's very likely that will result in 
> problems for Windows guests.

Another problem could be on guest resume from S3 after migration if the
bios or acpi tables change.

> I really think that we need to snapshot the FW and store it with the 
> guest state.  If we switch all FW to be allocated with qemu_ram_alloc() 
> and we use an id mechanism, then this will Just Work for savevm based 
> snapshots and live migration.  However, for it to work with -M pc-0.11 
> started from a cold boot, we need an nvram file.  We probably want to 
> make available versioned nvram files from each release too.

So the idea is to store the bios/option roms in the guest state and read them
from there on reset or power cycle?

- Sebastian