From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMmHy-0004uF-46 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 12:43:22 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMmHt-0004r2-FY for qemu-devel@nongnu.org; Mon, 21 Dec 2009 12:43:21 -0500 Received: from [199.232.76.173] (port=59468 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMmHt-0004qr-9c for qemu-devel@nongnu.org; Mon, 21 Dec 2009 12:43:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32048) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMmHt-0000oS-3x for qemu-devel@nongnu.org; Mon, 21 Dec 2009 12:43:17 -0500 Date: Mon, 21 Dec 2009 19:43:12 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. Message-ID: <20091221174312.GD21163@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2FAFB4.8050102@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 11:26:12AM -0600, Anthony Liguori wrote: > On 12/21/2009 10:43 AM, Gleb Natapov wrote: > >>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. > > But again, I don't see when this is ever a feature that a user > actually wants. Unless you change restart to fork/exec+exit, you'll > never have reset equivalent to power off + startup. Can you > advocate rereading roms and not advocate re-execing qemu? Why I will never have reset equivalent to power off + startup? Are you saying we are not capable of implementing spec correctly? > >>And more importantly, what is the end-user benefit of doing this? > >> > >Working migration? > > How does it fix migration? Migration needs to transfer the current > roms in order to work. A new version of qemu must support > interacting with the old version of the firmware for migration to > work. What happens after reset has nothing to do with migration but > because of the last requirement, the guest will obviously continue > to work after reboot too. I don't agree with your last requirement. Firmware goes hand in hand with HW. Change that is only FW visible should not be backwards compatible. -- Gleb.