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

[Gleb Natapov <gleb@redhat.com>]

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.