From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDYAZ-0003Cq-Oi for qemu-devel@nongnu.org; Thu, 26 Nov 2009 01:49:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDYAU-0003AS-Ly for qemu-devel@nongnu.org; Thu, 26 Nov 2009 01:49:34 -0500 Received: from [199.232.76.173] (port=56305 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDYAU-0003AD-CR for qemu-devel@nongnu.org; Thu, 26 Nov 2009 01:49:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20329) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDYAT-0006Ui-VV for qemu-devel@nongnu.org; Thu, 26 Nov 2009 01:49:30 -0500 Date: Thu, 26 Nov 2009 08:49:25 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios Message-ID: <20091126064925.GS2999@redhat.com> References: <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> <20091125225349.GA18812@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091125225349.GA18812@morn.localdomain> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: qemu-devel@nongnu.org, Sebastian Herbszt On Wed, Nov 25, 2009 at 05:53:49PM -0500, Kevin O'Connor wrote: > On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote: > >> 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. > > I see a "BIOS reload" as equivalent to directing access to rom. > > > How is shadowing currently implemented in qemu? Is the only BIOS > > copy overwritten or is the rom copy separate from the ram copy? > > My understanding is that both the ram and rom are kept. (Though, on a > "BIOS reload" I don't know if the ram is preserved.) > > > To summarize the discussion so far, there seems to be a potential > issue with reset: > > * If qemu doesn't reload the bios (a soft-reset) then there is a > potential issue with the bios and option roms not running properly > after a system reset invoked by Linux or other modern OSs. > > * If qemu does reload the bios (a hard-reset) then there is a good > chance that old DOS programs will break when they invoke a reset in > an attempt to switch from protected mode to real mode. > > Is that correct? > Reloading of a BIOS will not prevent old DOS program from working. It will slow switch to real mode, but otherwise I see no harm. What may prevent them from working is the fact that too much devices are reset on triple fault, but this has nothing to do with reloading of a BIOS. -- Gleb.