From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDFPz-000391-5Q for qemu-devel@nongnu.org; Wed, 25 Nov 2009 05:48:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDFPu-00036H-RS for qemu-devel@nongnu.org; Wed, 25 Nov 2009 05:48:14 -0500 Received: from [199.232.76.173] (port=39485 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDFPu-000367-LH for qemu-devel@nongnu.org; Wed, 25 Nov 2009 05:48:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47217) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDFPu-0004bf-6d for qemu-devel@nongnu.org; Wed, 25 Nov 2009 05:48:10 -0500 Date: Wed, 25 Nov 2009 12:48:01 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios Message-ID: <20091125104801.GL2999@redhat.com> References: <20091122151052.GK3193@redhat.com> <217FD12D88EA4AC2B2A32D77E010B16C@FSCPC> <20091122153809.GL3193@redhat.com> <8A56C1F849F34911ABF51DE049CA3D24@FSCPC> <20091123111137.GF2999@redhat.com> <11090DAABE9449F7B5D1415C45F8F411@FSCPC> <20091123194307.GC13854@redhat.com> <2D659FA33BF64C419243FD76049AFD33@FSCPC> <20091124062810.GZ2999@redhat.com> <5CC421C2B93B4444A14E88071CC2546A@FSCPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CC421C2B93B4444A14E88071CC2546A@FSCPC> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Herbszt Cc: Kevin O'Connor , qemu-devel@nongnu.org On Wed, Nov 25, 2009 at 12:27:06AM +0100, Sebastian Herbszt wrote: > Gleb Natapov wrote: > >On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote: > >>Gleb Natapov wrote: > >>>On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote: > >>>>Gleb Natapov wrote: > >>>>>On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote: > >>>>>>Gleb Natapov wrote: > >>>>>>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote: > >>>>>>>> > >>>>>>>>Bad things could happen if someone modifies the BIOS because it's unprotected > >>>>>>>>(e.g. VM crash). > >>>>>>>> > >>>>>>>BIOS is reloaded during VM reset. > >>>>>> > >>>>>>The BIOS is not reloaded - tested with "reboot" on Linux and system_reset in monitor. > >>>>>> > >>>>>Looks like a bug. Tested with latest QEMU version I assume? > >>>> > >>>>Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour > >>>>on "reboot" or system_reset? I think it depends wheter it's a software or hardware reset. > >>>> > >>>The bug is that BIOS rom is not reloaded on hardware reset (what do you > >>>call software reset?). Can you retest with latest git? > >> > >>Same with v0.11.0-rc0-1699-gb0293e5. > >>Bochs has the notion of BX_RESET_SOFTWARE and BX_RESET_HARDWARE. Those > >>two describe the source of the reset and the hardware, in most cases just the cpu, is reset > >>differently depending on the source (e.g. hardware reset / power on vs. INIT#). I think this > >>behaviour is also described in the 440fx spec (chapter "4.5.3 SYSTEM RESET"). > >> > >>If the monitor command "system_reset" is supposed to be the equivalent of pushing the reset > >>button of the box, then the bios should be reloaded (i think, not entirely sure what the pin is > >>wired to). But the bios should not be reloaded if the OS just jumps to the bios reset code. > >> > >Correct, but modern OSes never jump to the bios reset code. They use > >ACPI reset, kbd reset or triple fault to do reset. All of those generate > >exactly the same kind of reset as "system_reset" monitor command. > > With the 440FX you get two sources of a hard reset - power on and i/o write to reset control register. > Tho the PMC should not be used to generate a hard reset if used with a PIIX3. You get a soft reset on > CPU shutdown bus cycle, i/o write to keyboard controller, i/o write to port 92h and i/o write to reset > control register. The latter can be used for hard and soft resets. During a hard reset the PMC sets its > configuration registers to default values. The PAM registers are set to 0 and the BIOS is accessed thru > rom and not shadow ram. On a triple fault the CPU generates the shutdown bus cycle and since the PMC > responds to it with a soft reset the BIOS is not reloaded (?). I might have missed something in some > specification tho. > Nice sum up. Thanks. When I said "all of those generate exactly the same kind of reset as "system_reset" monitor command" I meant in QEMU, not on actual HW. QEMU has no notion of different type of resets, though it should. -- Gleb.