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

[Sebastian Herbszt]

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