From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMOZl-0001oW-85 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 11:24:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMOZg-0001kc-Ai for qemu-devel@nongnu.org; Sun, 20 Dec 2009 11:24:08 -0500 Received: from [199.232.76.173] (port=42411 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMOZg-0001kK-2f for qemu-devel@nongnu.org; Sun, 20 Dec 2009 11:24:04 -0500 Received: from mail-gx0-f223.google.com ([209.85.217.223]:34166) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMOZf-0001a0-SF for qemu-devel@nongnu.org; Sun, 20 Dec 2009 11:24:04 -0500 Received: by gxk23 with SMTP id 23so4767942gxk.2 for ; Sun, 20 Dec 2009 08:24:03 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20091220161531.GQ4490@redhat.com> References: <20091220145200.GA6706@redhat.com> <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> <20091220161531.GQ4490@redhat.com> From: Blue Swirl Date: Sun, 20 Dec 2009 16:23:43 +0000 Message-ID: Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 2009/12/20 Gleb Natapov : > On Sun, Dec 20, 2009 at 04:08:32PM +0000, Blue Swirl wrote: >> On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov wrote: >> > On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote: >> >> 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. =C2=A0The fact that firmw= are >> >> 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. =C2=A0The 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. >> >> >> > Ah now I see what you mean. New FW has to be used after reboot because= old >> > one may not be able to init HW any longer. Suppose some bug in cirrus >> > emulation has being fixed and old vga bios should be accommodated to >> > those changes, if old vga bios will run after reset video output may n= ot >> > work. Thinking about it we'll have the same problem if migration happe= ns >> > during vga bios loading, but this is MUCH less likely to happen. >> > >> >> 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. =C2=A0I'm not sure that's les= s >> >> predictable then hard shutdown/start-up and I'm not sure I can >> >> really make an argument for one way vs. the other. >> >> >> > system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we >> > just arguing if the same applies for the case that migration was done >> > between boot and reset. >> >> Some devices are careful enough to implement warm reset using a flag, >> see for example hw/sun4u.c. If you want more precision, you could >> introduce for example system_off_on with the memory clearing behavior >> you want. > I am not familiar with other architectures. All I am saying applies to > IBM PC only. Of course it is possible to design a system that impossible > to reset completely from software or by pushing reset button. (To design > general purpose computer like that one should be braindead though). On > IBM PC there are ways to reset different parts of the system and there > are ways to completely reset the system. We support only the later and > ACPI spec mandates this kind of reset if reset is done via ACPI. Then hw/pc.c could install a reset handler that clears all memory etc.