On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote: > 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. > Because on real hardware it is impossible to do it differently may be? My cable TV provider upgrades FW on my set-top-box automatically.
> >>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. On resume from S3 BIOS doesn't recreate ACPI tables. ACPI tables are not part of a BIOS image and in fact OS can reuse memory ACPI tables reside in. So such problem definitely does not exist. > > >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 -- Gleb.