From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KAsGK-0007Ts-4o for qemu-devel@nongnu.org; Mon, 23 Jun 2008 16:03:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KAsGJ-0007Tg-8w for qemu-devel@nongnu.org; Mon, 23 Jun 2008 16:03:39 -0400 Received: from [199.232.76.173] (port=43387 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAsGJ-0007Td-37 for qemu-devel@nongnu.org; Mon, 23 Jun 2008 16:03:39 -0400 Received: from 149.red-80-37-155.staticip.rima-tde.net ([80.37.155.149]:54086 helo=claunia.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KAsGH-0005Nx-Vx for qemu-devel@nongnu.org; Mon, 23 Jun 2008 16:03:38 -0400 Received: from [172.26.3.113] (unknown [172.26.3.113]) by claunia.com (Postfix) with ESMTP id B019B32D7420 for ; Mon, 23 Jun 2008 20:53:23 +0100 (BST) Message-ID: <48600130.9060309@claunia.com> Date: Mon, 23 Jun 2008 21:01:52 +0100 From: Natalia Portillo MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RESENT][PATCH 2/2] x86: Issue reset on triple faults References: <485FBE18.4090603@siemens.com> <20080623152348.GA16375@shareable.org> <485FC2BC.3040503@siemens.com> <20080623160047.GB16803@shareable.org> In-Reply-To: <20080623160047.GB16803@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org A CMOS byte? Is there really a way to distinguish between wanted=20 reset-by-triple-fault or a non-wanted-triple-fault? As far as I know the first guest that used this for context switching=20 (OS/2 1.x) used it as an undocumented but convenient bug/feature of 286 c= pu. Jamie Lokier escribi=F3: > Jan Kiszka wrote: > =20 >>> It might be worth distinguishing between >>> triple-fault-used-by-guest-for-context-switch and triple faults which >>> trigger a normal reset, and log only the latter. There's a >>> standardish way of distinguishing them, which the BIOS should check. >>> =20 >> You refer to setting some return address at some magic BIOS location? >> =20 > > Probably; I forget the details. There might be a CMOS byte, too. > > =20 >> Isn't this something the BIOS should handle, not QEMU? >> =20 > > The BIOS should handle it, yes. But since it is standard behaviour, > it might be useful for QEMU to decide whether to _log_ the event as a > system reset based on that state. > > Same for keyboard controller induced reset - that's also used for > context switching, in the same way. (Triple fault is only used > because it's faster.) > > Same also for deciding whether -no-reboot should close down the QEMU > process. Now I think about it, that is the best reason to distinguish > them! > > =20 >>> When helper(SVM_EXIT_SHUTDOWN, 0) is called, should it still also cal= l >>> qemu_system_reset_request()? >>> =20 >> helper_vmexit() is not expected to return (cpu_loop_exit). >> =20 > > Ok. It's not clear unless you know the code, which I don't. Just > wanted to check :-) > > -- Jamie > > > > =20