From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Jm6WU-0007HP-Q9
	for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:13:58 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Jm6WR-0007H9-CY
	for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:13:58 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Jm6WR-0007H6-5W
	for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:13:55 -0400
Received: from mx2.suse.de ([195.135.220.15])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <kwolf@suse.de>) id 1Jm6WR-0004BH-27
	for qemu-devel@nongnu.org; Wed, 16 Apr 2008 08:13:55 -0400
Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id A5EE044AF2
	for <qemu-devel@nongnu.org>; Wed, 16 Apr 2008 14:13:52 +0200 (CEST)
Message-ID: <4805EC42.7060909@suse.de>
Date: Wed, 16 Apr 2008 14:08:34 +0200
From: Kevin Wolf <kwolf@suse.de>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH] Reboot CPU on triple fault
References: <47EE86E0.4070703@reactos.org>	<20080416092340.GA27898@shareable.org>
	<4805CC9B.7050809@suse.de>
	<200804161217.33019.michal.schulz@gmx.de>
In-Reply-To: <200804161217.33019.michal.schulz@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Michal Schulz schrieb:
> A software which tries to go back from protected to 
> real mode sets the warm-reset vector in BIOS memory area, sets the reboot 
> reason variable in CMOS memory and issues a CPU reset.

Oh, I see. The modification of the BIOS memory area is the piece I
missed. Now this makes much more sense.

Still the questions remains what to do with triple faults wrt logging. I
understand that in 286 PM there might be masses of faults which nobody
is interested in. On the other hand, I'd really hate to have no output
when my code crashes with a triple fault and I haven't enabled -d int.

Maybe we can check if this vector has been modified? If not, the triple
fault certainly wouldn't be an intended usage of a "feature".

Kevin