On Mon, Dec 21, 2009 at 09:16:17PM +0100, Sebastian Herbszt wrote: > Gleb Natapov wrote: > >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. > > Your cable TV provider does likely also control what beside the FW (if > anything) > runs on your set-top-box. So he can verify the FW upgrade doesn't break > anything > in the field. That pre-deployment verification is not possible in non closed > environments. > Yet it doesn't stop HW manufacturers to require FW update as the first step of their support procedure. They don't do it automatically only because they can't.
> >>>>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. > > If the OS recycles the whole memory which holds the ACPI tables i am not sure > how > the BIOS will find the firmware_waking_vector. Maybe the OS can only use the > memory > which holds the DSDT? OS can reuse memory marked as "ACPI data" in e820 map. BIOS can put firmware_waking_vector pointer into reserved memory or "ACPI NVS" > Anyway, will the guest even resume from S3 if the hw > changed > on migration and the bios doesn't know how to init it? Probably not, so we need to use new BIOS that knows how to init HW. -- Gleb.