From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JmYsE-0008EC-2o for qemu-devel@nongnu.org; Thu, 17 Apr 2008 14:30:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JmYsB-0008D7-Aw for qemu-devel@nongnu.org; Thu, 17 Apr 2008 14:30:17 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JmYsA-0008D2-T7 for qemu-devel@nongnu.org; Thu, 17 Apr 2008 14:30:15 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JmYsA-0007U0-KB for qemu-devel@nongnu.org; Thu, 17 Apr 2008 14:30:14 -0400 Received: by py-out-1112.google.com with SMTP id u52so269221pyb.10 for ; Thu, 17 Apr 2008 11:30:09 -0700 (PDT) Message-ID: <4807972C.8030807@codemonkey.ws> Date: Thu, 17 Apr 2008 13:30: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> <48074740.4000202@codemonkey.ws> <48075A4C.5050205@siemens.com> In-Reply-To: <48075A4C.5050205@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: > >> Jan Kiszka wrote: >> >> 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. > Nor will you with your patch. >> 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. > It's not a question of whether it's logged, it's a question of whether it gets logged *specially*. That's the crux of the discussion here. My argument is that triple faults are not sufficiently special that they warrant *special* logging. Regards, Anthony Liguori