From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jm6SM-00060C-2I for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:09:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jm6SJ-000600-HV for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:09:40 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jm6SJ-0005zx-Bz for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:09:39 -0400 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194] helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jm6SI-00031d-QH for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:09:39 -0400 Message-ID: <4805EC5D.20603@qumranet.com> Date: Wed, 16 Apr 2008 15:09:01 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Reboot CPU on triple fault References: <47EE86E0.4070703@reactos.org> <9C7667CB-2CF0-4AC0-843B-6EF442196CAC@csgraf.de> <47F0B445.4030806@suse.de> <4804D254.5040301@siemens.com> <4805B673.3010200@suse.de> <4805EAE6.1070601@siemens.com> In-Reply-To: <4805EAE6.1070601@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Jan Kiszka wrote: > Kevin Wolf wrote: > >> Jan Kiszka schrieb: >> >>> As the same requirement came up here, I worked out the following patch. >>> I feel a bit uneasy about it because >>> >>> o I'm unsure if breaking out of the exception loop is OK this way. >>> >>> o including necessary headers fails, mostly due to stdio redefinitions >>> in dyngen-exec.h. >>> >>> This patch behaves as it should, but only in one specific test case. >>> Feedback is welcome. >>> >> This is exactly the behaviour I'd like to have. I still needed a small >> change to your patch, though: You shouldn't return 0 from >> check_exception, after all it's not a divide error. I'm not sure if >> EXCP_HLT is the right thing to return here, but the attached patch works >> for me. Without this change it kept hanging in a loop forever writing >> more dumps than I ever wanted. ;-) >> > > Your version still works for me (and makes more sense than return 0, > indeed). So we just need someone to confirm that this is actually a > clean way to leave the fault handling. > > And we need a consensus regarding fault reporting... What about > confining the dump to the logfile, leaving the console alone? > If logging is really necessary, have it disabled by default and add a switch to enable it. This way ordinary (non-developers) don't need to worry about it, and developers can conveniently see it on stdout. -- error compiling committee.c: too many arguments to function