From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LMPHv-0001De-HD for qemu-devel@nongnu.org; Mon, 12 Jan 2009 11:05:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LMPHu-0001Ch-Lj for qemu-devel@nongnu.org; Mon, 12 Jan 2009 11:05:15 -0500 Received: from [199.232.76.173] (port=36873 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LMPHu-0001CU-H4 for qemu-devel@nongnu.org; Mon, 12 Jan 2009 11:05:14 -0500 Received: from lizzard.sbs.de ([194.138.37.39]:21483) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LMPHt-0003Js-Ro for qemu-devel@nongnu.org; Mon, 12 Jan 2009 11:05:14 -0500 Message-ID: <496B6A35.2090708@siemens.com> Date: Mon, 12 Jan 2009 17:05:09 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <34308.89.102.207.186.1231083937.squirrel@mail.netbsd.sk> <496B342B.7050409@siemens.com> <3CE5FCB0-8B5B-4EBE-863C-6355B749C414@suse.de> In-Reply-To: <3CE5FCB0-8B5B-4EBE-863C-6355B749C414@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] Resend: x86: Reboot CPU on triple fault Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "lkundrak@v3.sk" , "qemu-devel@nongnu.org" Alexander Graf wrote: > > > > > On 12.01.2009, at 13:14, Jan Kiszka wrote: > >> lkundrak@v3.sk wrote: >>> This is a (slightly adjusted for 2009-01-04 SVN) resend of Jan Kiszka's >>> Reboot CPU on triple fault patch (see patch file for the exact >>> reference) >>> >>> It seems like a consensus was reached on how to deal with tripple >>> faults, >>> but noone commited the last version (8) of the patch anyways. >>> >>> Just for the record -- 386BSD relies on this behavior to reset the >>> CPU -- >>> it unmaps the whole address space in order to trigger a tripple fault. >>> >> >> Good that you picked this up! It is still on my to-do list to get this >> in, but with medium prio. However, let's try to push it a bit. >> >>> This is a slightly adjusted (for 2009-01-04 SVN) "reset on tripple >>> fault patch" >>> >>> Originally from: >>> >>> Subject: [Qemu-devel] Re: [PATCH] x86: Reboot CPU on triple fault - >>> Version 8 >>> Message-ID: <483C340E.1030207@siemens.com> >>> Date: Tue, 27 May 2008 18:17:18 +0200 >>> From: Jan Kiszka >> >> Note that I posted an enhanced version on 2008-09-02, also covering >> reset logging for non-x86 archs. Please use that one. >> >> ... >>> Index: target-i386/op_helper.c >>> =================================================================== >>> --- target-i386/op_helper.c (revision 6159) >>> +++ target-i386/op_helper.c (working copy) >>> @@ -1244,6 +1244,9 @@ >>> } >>> } >>> >>> +/* This should come from sysemu.h - if we could include it here... */ >>> +void qemu_system_reset_request(void); >>> + >>> /* >>> * Check nested exceptions and change to double or triple fault if >>> * needed. It should only be called, if this is not an interrupt. >>> @@ -1261,9 +1264,19 @@ >>> fprintf(logfile, "check_exception old: 0x%x new 0x%x\n", >>> env->old_exception, intno); >>> >>> - if (env->old_exception == EXCP08_DBLE) >>> - cpu_abort(env, "triple fault"); >>> +#if !defined(CONFIG_USER_ONLY) >>> + if (env->old_exception == EXCP08_DBLE) { >>> + if (env->intercept) >>> + helper_vmexit(SVM_EXIT_SHUTDOWN, 0); >>> >>> + if (loglevel & CPU_LOG_RESET) >>> + fprintf(logfile, "Triple fault\n"); >>> + >>> + qemu_system_reset_request(); >>> + return EXCP_HLT; >>> + } >>> +#endif >>> + >>> if ((first_contributory && second_contributory) >>> || (env->old_exception == EXCP0E_PAGE && >>> (second_contributory || (intno == EXCP0E_PAGE)))) { >> >> I meanwhile think that SVM hook should rather look like this >> >> helper_svm_check_intercept_param(SVM_EXIT_SHUTDOWN, 0); >> >> >> in order to properly check if shutdown events are actually intercepted. >> Alexander, am I right? > > Yes, sounds right. Any reason not to put the intercept in reset_request? > (asking blindly, I don't have access to the qemu source right now) You mean qemu_system_reset_request? That's generic code while the hook is x86-specific. Jan -- Siemens AG, Corporate Technology, CT SE 26 Corporate Competence Center Embedded Linux