From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFCzu-0003v2-Cz for qemu-devel@nongnu.org; Mon, 30 Nov 2009 15:37:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFCzp-0003uE-J8 for qemu-devel@nongnu.org; Mon, 30 Nov 2009 15:37:26 -0500 Received: from [199.232.76.173] (port=42915 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFCzp-0003uB-C7 for qemu-devel@nongnu.org; Mon, 30 Nov 2009 15:37:21 -0500 Received: from mail.gmx.net ([213.165.64.20]:35456) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NFCzo-00016y-5D for qemu-devel@nongnu.org; Mon, 30 Nov 2009 15:37:21 -0500 Message-ID: From: "Sebastian Herbszt" References: <20091124062810.GZ2999@redhat.com> <20091124143812.GA27783@shareable.org> <20091124144044.GJ2999@redhat.com> <20091125060951.GA17203@shareable.org> <20091125122039.GM2999@redhat.com> <20091126064533.GR2999@redhat.com> <3A1982E342544524818CFCCFDED95D95@FSCPC> <20091127074420.GA6251@redhat.com> <2EAF309192074B629F26764ACD87ADFE@FSCPC> <20091129082024.GA30150@redhat.com> In-Reply-To: <20091129082024.GA30150@redhat.com> Subject: Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios Date: Mon, 30 Nov 2009 21:34:58 +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 Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote: >> Gleb Natapov wrote: >> >On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote: >> >>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. >> >> >> >If triple fault is used just for a reset we can do hard reset like we do >> >now. It may violate HW spec but it works. >> >> Bad things might happen tho, because some of the hardware state is reset even if it should >> not be. If some OS does program the PIIX3 PIRQx route control registers and then uses >> triple fault to return from protected mode and qemu does reset those registers back to >> default values, the OS might not like it when the BIOS resumes it. >> > We already concluded that "return to PM by triple fault" is not something > we want to support. It was needed only on 286 and QEMU doesn't even > support 286 cpu emulation. I don't think you can conclude this because it's not an optional feature. Whether qemu emulates a 286 cpu is irrelevant in this case because the hardware qemu emulates has to be backward compatible. >> >>>>>> >> >>>>>>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? >> >> >> >Of course. The ability to upgrade cluster transparently is a major >> >feature. So migration from older version to newer one is must to have. >> >> I am wondering how this works on VMware. A VM has a virtualHW.version assigned, so the >> hardware doesn't automagically change on software upgrades. You have to power off the VM >> and request an upgrade for it to change. They also likely have a fairly stable BIOS version. >> If a VM is created on ESX 3.5 with virtualHW.version 4 and live migrated to ESX 4.0, which also >> supports virtualHW.version 7, i would assume it still has the same hardware on a hard reset and even >> if you shutdown and restart it, since no hardware upgrade was requested by the user. If the hardware >> has been upgraded it can't be migrated back to the ESX 3.5 host. The BIOS might be special tho. It does >> likely support both hardware versions. If the VM got migrated, the old BIOS should be run and reloaded >> as long as the VM has not been destroyed / stopped. This should happen even if the VM has been hard reset. >> Now if the VM is shutdown and recreated on the new host it might be ok to load the new BIOS even if the >> hardware version was not upgraded. But it is more (?) reasonable to keep loading the old BIOS until the >> hardware is upgraded and leave the choice to the user. >> > You are talking about major HW upgrades and I am not talking about that > at all. You can't migrate from i440FX to ich9 obviously. I am talking > about bug fixes in existing HW. For instance currently LINT0 is > configured to virtual wire mode by KVM itself, but it should be done by > a BIOS. Suppose new version of KVM fixes this bug, code that did this is > removed from KVM module and LINT0 configuration is added to a BIOS. Now > you migrate old guest to the new QEMU/KVM and do reboot. If old BIOS > will be executed it will not put LINT0 to virtual wire mode and new KVM > will not do that too. OS boot will fail as a result. That is only one > example from real life and I have more. This is unfortunate. Updating the BIOS of a running VM might not be the best idea; tho i don't have a better one. An unfriendly solution would be to disallow live migration between broken and fixed versions. - Sebastian