From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IXfiF-0001wl-Rh for qemu-devel@nongnu.org; Tue, 18 Sep 2007 12:14:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IXfi9-0001pe-Qc for qemu-devel@nongnu.org; Tue, 18 Sep 2007 12:14:10 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IXfi9-0001pH-KJ for qemu-devel@nongnu.org; Tue, 18 Sep 2007 12:14:05 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IXfi9-00021T-8W for qemu-devel@nongnu.org; Tue, 18 Sep 2007 12:14:05 -0400 Received: by nf-out-0910.google.com with SMTP id 30so1568319nfu for ; Tue, 18 Sep 2007 09:14:03 -0700 (PDT) Message-ID: Date: Tue, 18 Sep 2007 19:14:03 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] SVM support In-Reply-To: <1190110170.14938.244.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46D6DA17.7050304@suse.de> <46D6E9BE.4020508@suse.de> <46DACD41.4020606@suse.de> <20070913024948.GC15247@networkno.de> <46E956F8.2050908@suse.de> <1190016494.14938.146.camel@rapid> <46EE50B3.5060502@suse.de> <1190038589.21267.45.camel@jma4.dev.netgem.com> <46EF23BA.10208@suse.de> <1190110170.14938.244.camel@rapid> 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 On 9/18/07, J. Mayer wrote: > Going this way, I see no reason why the interruption code in the cpu_exec loop > could not finally become: > interrupt_request = env->interrupt_request; > if (__builtin_expect(interrupt_request, 0)) { > if (interrupt_request & CPU_INTERRUPT_DEBUG) { > env->interrupt_request &= ~CPU_INTERRUPT_DEBUG; > env->exception_index = EXCP_DEBUG; > cpu_loop_exit(); > } > if (interrupt_request & CPU_INTERRUPT_HALT) { > env->interrupt_request &= ~CPU_INTERRUPT_HALT; > env->halted = 1; > env->exception_index = EXCP_HLT; > cpu_loop_exit(); > } > if (interrupt_request & CPU_INTERRUPT_HARD) { > hw_interrupt(env); > if (env->pending_interrupts == 0) > env->interrupt_request &= ~CPU_INTERRUPT_HARD; > #if defined(__sparc__) && !defined(HOST_SOLARIS) > tmp_T0 = 0; > #else > T0 = 0; > #endif > } > /* Don't use the cached interupt_request value, > do_interrupt may have updated the EXITTB flag. */ > if (interrupt_request & CPU_INTERRUPT_EXITTB) { > env->interrupt_request &= ~CPU_INTERRUPT_EXITTB; > /* ensure that no TB jump will be modified as > the program flow was changed */ > #if defined(__sparc__) && !defined(HOST_SOLARIS) > tmp_T0 = 0; > #else > T0 = 0; > #endif > } > if (interrupt_request & CPU_INTERRUPT_EXIT) { > env->interrupt_request &= ~CPU_INTERRUPT_EXIT; > env->exception_index = EXCP_INTERRUPT; > cpu_loop_exit(); > } > } > All the targets specific tricks could be done in the hw_interrupt routine. And the generic code > would become much more readable. But this needs some works (not so much) and intensive tests... > And I guess nobody feels like taking this risk right now ;-) > But I think this will have to be done someday... I vote for this. There are some other places where we could use the same API: cpu_dump_state() cpu_list() cpu_register()