From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMogN-0001jZ-0a for qemu-devel@nongnu.org; Mon, 21 Dec 2009 15:16:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMogI-0001ht-L3 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 15:16:42 -0500 Received: from [199.232.76.173] (port=43006 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMogI-0001hq-EO for qemu-devel@nongnu.org; Mon, 21 Dec 2009 15:16:38 -0500 Received: from mail.gmx.net ([213.165.64.20]:40022) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NMogH-0001iW-F2 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 15:16:38 -0500 Message-ID: From: "Sebastian Herbszt" 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> <20091221195331.GH21163@redhat.com> In-Reply-To: <20091221195331.GH21163@redhat.com> Date: Mon, 21 Dec 2009 21:16:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: Gleb Natapov Cc: Kevin O'Connor , Gerd Hoffmann , qemu-devel@nongnu.org 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