From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFDFh-0005q5-6S for qemu-devel@nongnu.org; Mon, 30 Nov 2009 15:53:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFDFc-0005l5-AT for qemu-devel@nongnu.org; Mon, 30 Nov 2009 15:53:44 -0500 Received: from [199.232.76.173] (port=59342 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFDFc-0005l2-5a for qemu-devel@nongnu.org; Mon, 30 Nov 2009 15:53:40 -0500 Received: from mail2.shareable.org ([80.68.89.115]:52386) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NFDFb-0002Uw-OS for qemu-devel@nongnu.org; Mon, 30 Nov 2009 15:53:39 -0500 Date: Mon, 30 Nov 2009 20:53:35 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios Message-ID: <20091130205335.GD5560@shareable.org> References: <20091125060951.GA17203@shareable.org> <20091125122039.GM2999@redhat.com> <20091126064533.GR2999@redhat.com> <3A1982E342544524818CFCCFDED95D95@FSCPC> <20091127074420.GA6251@redhat.com> <2EAF309192074B629F26764ACD87ADFE@FSCPC> <20091129082024.GA30150@redhat.com> <14822EE0-7526-4E6E-99BD-28B9D61C66AA@claunia.com> <20091130071257.GC30150@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091130071257.GC30150@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org Gleb Natapov wrote: > On Sun, Nov 29, 2009 at 10:53:40PM +0000, Natalia Portillo wrote: > > >> > > >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. > > > > It is used by a whole kind of operating systems (all the 16-bit OS/2 > > tree) and who knows by how many DOS extenders. > I suppose none. But if you know any please mansion it by name here. Note > that is should support i386 CPU since QMEU does not emulate i286. > > I386 has native way to switch to PM, no need triple fault trick and it > was introduced by Intel in 1985. For those who wanted to be compatible > with 286 there was a trick invented back then to switch to PM in a > portable way between i386 and i286: > http://www.rcollins.org/ftp/source/3fault/reset.asm > > I doubt that OS/2 was not updated to use something like this. I can't test 16-bit OS/2, so if someone would like to give it a try that'd be great. It'd be interesting to see what method it uses. I will try 16-bit Windows 3, and MS-DOS with HIMEM.SYS and Turbo C++ to see if (a) they still work and (b) what method they use. > > It is supported by Pentium processors, so it should be by QEMU, no > > matter it does not emulate the 286 but a later CPU. > Most chipsets can be configured to do full reset on CPU shutdown cycle. > You simple can't rely on certain behaviour of triple fault. I wouldn't be surprised if, for ancient 286 app compatibility, real BIOSes always set the chipset to do a soft reset, but I've no idea really what they do. 286 era PCs didn't do much on soft reset :-) The triple fault and keyboard reset methods, when BIOS is told it's for PM->RM switch, don't disturb the video output, lose keyboard input or have to do a slow reinitialisation of hard disk or memory, because those things all carry on working. The PM->RM switch is used as a slow context switch or method for calling the BIOS in multitasking environments. Even though it's slow (especially when done through a keyboard controller request), it's fast enough to use for context switching. > BTW QEMU today does full reset on triple fault and I haven't noticed any > complains. Those OSes we've just talked about don't care about the ACPI (etc) tables getting wiped in the BIOS, do they? :-) I'm getting the impression all the BIOS self-modification is in areas which aren't used by ancient OSes using the triple fault or keyboard methods for PM->RM switch. Is that right? It would still be unfortunate if you could boot DOS, run a few things that use the old PM->RM methods, then run LOADLIN to boot a modern Linux (from DOS) and find Linux needs something that's messed up in the BIOS. -- Jamie