From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDlOw-0007dp-Dg for qemu-devel@nongnu.org; Thu, 26 Nov 2009 15:57:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDlOs-0007d1-QF for qemu-devel@nongnu.org; Thu, 26 Nov 2009 15:57:18 -0500 Received: from [199.232.76.173] (port=43588 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDlOs-0007cq-Lg for qemu-devel@nongnu.org; Thu, 26 Nov 2009 15:57:14 -0500 Received: from mail.gmx.net ([213.165.64.20]:34150) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NDlOs-0003dB-8E for qemu-devel@nongnu.org; Thu, 26 Nov 2009 15:57:14 -0500 Message-ID: <3A1982E342544524818CFCCFDED95D95@FSCPC> From: "Sebastian Herbszt" References: <20091123111137.GF2999@redhat.com> <11090DAABE9449F7B5D1415C45F8F411@FSCPC> <20091123194307.GC13854@redhat.com> <2D659FA33BF64C419243FD76049AFD33@FSCPC> <20091124062810.GZ2999@redhat.com> <20091124143812.GA27783@shareable.org> <20091124144044.GJ2999@redhat.com> <20091125060951.GA17203@shareable.org> <20091125122039.GM2999@redhat.com> <20091126064533.GR2999@redhat.com> In-Reply-To: <20091126064533.GR2999@redhat.com> Subject: Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios Date: Thu, 26 Nov 2009 21:55:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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 , qemu-devel@nongnu.org Gleb Natapov wrote: > On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote: >> Gleb Natapov wrote: >> >On Wed, Nov 25, 2009 at 06:09:51AM +0000, Jamie Lokier wrote: >> >>Gleb Natapov wrote: >> >>> > But QEMU is used to run old OSes too. >> >>> > > That's OK. I don't expect BIOS to be reloaded if OS >> >>restart by jumping >> >>> to BIOS reset code. >> >> >> >>That's good then. >> >> >> >>What about DOS and DOS-extender programs which do a soft reset by >> >>triple-faulting the CPU (see Sebastian's notes on i440FX behaviour), >> >>and asking the keyboard controller? >> >> >> >>Both of those methods are used by DOS and DOS-extender programs to >> >>switch from protected mode to real mode. Keyboard controller was used >> >>originally, but then someone figured out that triple fault can be used >> >>(on most PCs) and is faster. >> >> >> >>The switch to real mode is done by writing somewhere the BIOS checks, >> >>so the BIOS just branches back to the application. >> >> >> >If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored >> >in memory address 0x467. >> > >> >>I think that may imply it has to be a "soft reset" as described by >> >>Sebastian in the i440FX description, and I would think the BIOS must >> >>not be reloaded. >> >Reading ich9 spec I see that on this chipset it is possible to configure >> >what kind of reset triple fault generates. Make it not very reliable. Was >> >this triple fault trick only needed on 286 anyway? >> >> It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices >> are reset. Table 5-40 is pretty descriptive and there seem to be way too many >> ways to trigger a reset. I think PLTRST# is used when a reset is triggered by >> the ACPI method. Fortunatelly we don't have to implement this (yet) since >> it's not available on the 440fx. >> >> Using triple fault to reset is used on 286+. >> > Triple fault use as a reset is widely used today. Use of triple fault to > switch from protected mode to real mode was specific for 286. Whether triple fault is used just for a reset or to switch from protected mode to real mode is irrelevant, because from the hardware point of view this is exactly the same reset. And old applications can still use this method on new CPUs. >> >> >> >>But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard >> >>controller method is used and the word asking for a branch back to the >> >>application has not been set. Because that's how a modern OS (if not >> >>using ACPI) asks for a system reset. >> >> >> >>Do you think the above is (a) correct, and (b) what's implemented? >> >> >> >Do different things during reset depending on CMOS values doesn't sound >> >right to me. I don't know what is implemented right now. I thought that >> >we reload BIOS on reset. >> >> Currently the BIOS seems to be only loaded once and not reloaded during the life >> time of a VM. >> I don't think there is a notion of BIOS reload on real hardware. CPU access to it is >> either directed to the rom (power-up configuration, all those fancy reset conditions) >> or to ram. > Reloading BIOS in QEMU is needed for a reason not present on real HW. Think > about migration from old QEMU to new QEMU. Suppose old BIOS can't > properly initialize new QEMU. Then next reboot after migration will fail > since old BIOS will be used. Do you mean live migration between different QEMU versions? That doesn't sound safe, especially if the hardware changes on reboot. Does the competition support this? - Sebastian