From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JmTeV-0002hM-Kp for qemu-devel@nongnu.org; Thu, 17 Apr 2008 08:55:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JmTeT-0002gI-DS for qemu-devel@nongnu.org; Thu, 17 Apr 2008 08:55:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JmTeS-0002ff-JQ for qemu-devel@nongnu.org; Thu, 17 Apr 2008 08:55:44 -0400 Received: from yw-out-1718.google.com ([74.125.46.156]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JmTeS-0004Eo-33 for qemu-devel@nongnu.org; Thu, 17 Apr 2008 08:55:44 -0400 Received: by yw-out-1718.google.com with SMTP id 4so34252ywq.82 for ; Thu, 17 Apr 2008 05:55:36 -0700 (PDT) Message-ID: <48074740.4000202@codemonkey.ws> Date: Thu, 17 Apr 2008 07:49:04 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] x86: Reboot CPU on triple fault - Version 4 References: <47EE86E0.4070703@reactos.org> <9C7667CB-2CF0-4AC0-843B-6EF442196CAC@csgraf.de> <47F0B445.4030806@suse.de> <4804D254.5040301@siemens.com> <4805F4B0.5020802@siemens.com> <4806009E.8060407@suse.de> <48060F42.3080709@codemonkey.ws> <48070533.5060405@siemens.com> In-Reply-To: <48070533.5060405@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: > Anthony Liguori wrote: > >> Why is it so important to log triple faults? Printing something to >> stderr instead of logfile is just wrong. >> >> What is your use-case? I think you've got the wrong solution to the >> problem and I can't find an adequate description of the problem your >> trying to solve in this thread. >> > > You may not always sit next to your VM when it decides to reboot due to > a _real_ problem that caused a triple fault. > You can always check within the guest to see if it's rebooted (via uptime for instance). It's extremely unlikely you'll ever see an OS triple fault in the wild unless you're doing kernel development. Triple faulting requires a bad IDT or a really bad page table both of which are not something an OS is likely to do by accident. If your OS is triple faulting, I highly doubt it's just going to reboot and everything's going to be okay. Besides, the -no-reboot flag should already satisfy your needs if you're really concerned about it. Regards, Anthony Liguori > Jan > >