From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMlJp-0006lF-3z for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:41:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMlJk-0006kQ-5T for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:41:12 -0500 Received: from [199.232.76.173] (port=52579 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMlJj-0006kD-Uq for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:41:07 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:42958) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMlJi-0000vs-I7 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:41:07 -0500 Received: by yxe26 with SMTP id 26so5102168yxe.4 for ; Mon, 21 Dec 2009 08:41:05 -0800 (PST) Message-ID: <4B2FA518.7000905@codemonkey.ws> Date: Mon, 21 Dec 2009 10:40:56 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. References: <4B2E3BA0.7080004@codemonkey.ws> <20091220150751.GL4490@redhat.com> <4B2E3E96.7090708@codemonkey.ws> <20091220152346.GM4490@redhat.com> <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> In-Reply-To: <20091221073204.GS4490@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 On 12/21/2009 01:32 AM, Gleb Natapov wrote: > On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote: > >> On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote: >> >>> I think we have two ways to view firmware. The first would be to treat >>> guest firmware as part of the guest. What that means it that we should >>> store all firmware in an nvram file, migrate the nvram file during >>> migration >>> >> [...] >> >>> The other option would be to treat guest firmware as part of the machine >>> state. >>> >> How about mixing the two? Store the firmware in an nvram file and >> migrate it during migration, but clear the nvram and reload the >> firmware on each start-up and qemu reset. >> >> > That's precisely what I propose. > There are some really ugly corner cases here. For instance, guest is running and the user does a yum update which upgrades the qemu package. This includes laying down a new bios. User eventually restarts guest, now we re-read BIOS and we're on a newer BIOS than the device model. Badness ensues. And more importantly, what is the end-user benefit of doing this? Regards, Anthony Liguori