From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NMoFR-0001cX-Pd
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:48:53 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NMoFM-0001aZ-Ie
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:48:53 -0500
Received: from [199.232.76.173] (port=53658 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NMoFM-0001aU-Eg
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:48:48 -0500
Received: from mx1.redhat.com ([209.132.183.28]:19017)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <gleb@redhat.com>) id 1NMoFM-0004eg-2m
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 14:48:48 -0500
Date: Mon, 21 Dec 2009 21:48:41 +0200
From: Gleb Natapov <gleb@redhat.com>
Message-ID: <20091221194841.GG21163@redhat.com>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B2FC9C3.7040503@codemonkey.ws>
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Kevin O'Connor <kevin@koconnor.net>, Gerd Hoffmann <kraxel@redhat.com>, Sebastian Herbszt <herbszt@gmx.de>

On Mon, Dec 21, 2009 at 01:17:23PM -0600, Anthony Liguori wrote:
> >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.
> 
On the contrary. This is very unlikely. Otherwise BIOS upgrade would
cause Windows reactivation.

> 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.
> 
Yes, firmware should be part of machine description.

--
			Gleb.