qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sebastian Herbszt
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Date: Mon, 21 Dec 2009 21:16:17 +0100

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.

>>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? Anyway, will the guest even resume from S3 if the hw 
changed
on migration and the bios doesn't know how to init it?

- Sebastian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]