From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMoKA-0003R6-PS for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:53:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMoK6-0003Py-4h for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:53:46 -0500 Received: from [199.232.76.173] (port=49571 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMoK5-0003Pv-Vx for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:53:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3480) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMoK5-0005jp-IA for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:53:41 -0500 Date: Mon, 21 Dec 2009 21:53:31 +0200 From: Gleb Natapov Message-ID: <20091221195331.GH21163@redhat.com> References: <4B2E6364.9060903@codemonkey.ws> <20091221015948.GA23556@morn.localdomain> <20091221073204.GS4490@redhat.com> <4B2FA518.7000905@codemonkey.ws> <20091221164351.GW4490@redhat.com> <4B2FAFB4.8050102@codemonkey.ws> <20091221174312.GD21163@redhat.com> <1DB151B654AF44C981FA3327A3A514E6@FSCPC> <4B2FC9C3.7040503@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Herbszt Cc: Kevin O'Connor , Gerd Hoffmann , qemu-devel@nongnu.org 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.