From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMlYb-0001Ac-As for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:56:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMlYY-00017f-Fo for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:56:28 -0500 Received: from [199.232.76.173] (port=47649 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMlYY-00017Q-BU for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:56:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7842) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMlMY-0001le-CC for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:44:03 -0500 Date: Mon, 21 Dec 2009 18:43:51 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. Message-ID: <20091221164351.GW4490@redhat.com> References: <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> <4B2FA518.7000905@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2FA518.7000905@codemonkey.ws> 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 , qemu-devel@nongnu.org On Mon, Dec 21, 2009 at 10:40:56AM -0600, Anthony Liguori wrote: > 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. > My package manager warns me that certain application need to be restarted to work correctly after upgrade. This is hardly qemu specific problem. > And more importantly, what is the end-user benefit of doing this? > Working migration? -- Gleb.