From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMo6n-0005wy-Oq for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:39:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMo6j-0005wU-E1 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:39:57 -0500 Received: from [199.232.76.173] (port=54787 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMo6j-0005wR-Ap for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:39:53 -0500 Received: from mail.gmx.net ([213.165.64.20]:56004) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NMo6i-0002r6-8f for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:39:53 -0500 Message-ID: From: "Sebastian Herbszt" References: <4B2E42A2.6030600@codemonkey.ws> <20091220153347.GN4490@redhat.com><4B2E453A.3060004@codemonkey.ws> <20091220155201.GP4490@redhat.com><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> In-Reply-To: <4B2FC9C3.7040503@codemonkey.ws> Date: Mon, 21 Dec 2009 20:39:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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: Anthony Liguori Cc: Kevin O'Connor , Gerd Hoffmann , Gleb Natapov , qemu-devel@nongnu.org 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. >> 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. > 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