From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NMnl9-0006da-07
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:17:35 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NMnl4-0006ba-L1
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:17:34 -0500
Received: from [199.232.76.173] (port=50267 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NMnl3-0006bK-Po
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:17:29 -0500
Received: from mail-gx0-f223.google.com ([209.85.217.223]:61327)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NMnl3-0006IF-LX
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:17:29 -0500
Received: by gxk23 with SMTP id 23so5702309gxk.2
	for <qemu-devel@nongnu.org>; Mon, 21 Dec 2009 11:17:28 -0800 (PST)
Message-ID: <4B2FC9C3.7040503@codemonkey.ws>
Date: Mon, 21 Dec 2009 13:17:23 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
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>
In-Reply-To: <1DB151B654AF44C981FA3327A3A514E6@FSCPC>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Sebastian Herbszt <herbszt@gmx.de>
Cc: Kevin O'Connor <kevin@koconnor.net>, Gerd Hoffmann <kraxel@redhat.com>, Gleb Natapov <gleb@redhat.com>, qemu-devel@nongnu.org

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).

> 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.

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.

Regards,

Anthony Liguori

>
> - Sebastian
>