From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMNsq-0008MX-41 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:39:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMNsl-0008IP-Ci for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:39:47 -0500 Received: from [199.232.76.173] (port=41854 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMNsl-0008IJ-0G for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:39:43 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:57002) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMNsk-0000Iw-KT for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:39:42 -0500 Received: by yxe26 with SMTP id 26so4342808yxe.4 for ; Sun, 20 Dec 2009 07:39:42 -0800 (PST) Message-ID: <4B2E453A.3060004@codemonkey.ws> Date: Sun, 20 Dec 2009 09:39:38 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1261134074-11795-1-git-send-email-kraxel@redhat.com> <20091220083857.GE4490@redhat.com> <4B2E381A.4080804@codemonkey.ws> <20091220145200.GA6706@redhat.com> <4B2E3BA0.7080004@codemonkey.ws> <20091220150751.GL4490@redhat.com> <4B2E3E96.7090708@codemonkey.ws> <20091220152346.GM4490@redhat.com> <4B2E42A2.6030600@codemonkey.ws> <20091220153347.GN4490@redhat.com> In-Reply-To: <20091220153347.GN4490@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Gerd Hoffmann , qemu-devel@nongnu.org Gleb Natapov wrote: >> More importantly though, what's the use-case here? >> >> > Use-case for what? This just what need to be done for correct HW > emulation. > Live migration is transparent to the guest. The fact that firmware can upgrade itself without the guest doing anything is not something that really has a real world equivalent. Even if it did, whether that automatic upgrade happens after a reboot vs. a hard power cycle is irrelevant. The guest has no knowledge of the fact that the automatic firmware upgrade happened so if it gets delayed indefinitely, it doesn't matter. It's not a matter of correctness IMHO. I can understand an argument for predictability wrt wanted to be able to guarantee that after the first reboot during a live migration, you'll get the new firmware. I'm not sure that's less predictable then hard shutdown/start-up and I'm not sure I can really make an argument for one way vs. the other. If anything, I can better understand the argument for not ever upgrading the firmware transparently. Something like having a nvram file that we load all of the ROMs into, then do live migration and migrate the nvram file. That would mean that we would have to be very careful in the future about supporting fw_cfg as a versioned interface. We would also want to provide a mechanism for a user to manually upgrade the firmware from within a guest if we went this route. Regards, Anthony Liguori