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: Gleb Natapov
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Date: Mon, 21 Dec 2009 21:53:31 +0200

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.




reply via email to

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