From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JmUoj-0006Dl-7o for qemu-devel@nongnu.org; Thu, 17 Apr 2008 10:10:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JmUoh-0006D0-Qp for qemu-devel@nongnu.org; Thu, 17 Apr 2008 10:10:24 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JmUoh-0006Cm-FT for qemu-devel@nongnu.org; Thu, 17 Apr 2008 10:10:23 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JmUog-0004jy-V9 for qemu-devel@nongnu.org; Thu, 17 Apr 2008 10:10:23 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m3HEAKil016700 for ; Thu, 17 Apr 2008 16:10:20 +0200 Received: from [139.21.95.227] (mchn012c.mchh.siemens.de [139.21.95.227] (may be forged)) by mail2.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m3HEAKWL010930 for ; Thu, 17 Apr 2008 16:10:20 +0200 Message-ID: <48075A4C.5050205@siemens.com> Date: Thu, 17 Apr 2008 16:10:20 +0200 From: Jan Kiszka MIME-Version: 1.0 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> <48074740.4000202@codemonkey.ws> In-Reply-To: <48074740.4000202@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] x86: Reboot CPU on triple fault - Version 4 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 Anthony Liguori wrote: > 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). But you won't find the CPU state on triple fault there. > > 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. There are various OSes out there in the wild. Not all of them conform to common assumptions about how OSes typically look like. And once you start moving things under a different roof (like QEMU), you are better off logging such /potentially/ critical events (specifically if that roof is a bit smaller due to missing segment limit and type checks). That's at least our situation ATM. > > Besides, the -no-reboot flag should already satisfy your needs if you're > really concerned about it. Nope, because we also have the case where a triple fault is intentionally triggered to perform a reboot. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux