From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhpCk-0004xl-OW for qemu-devel@nongnu.org; Thu, 01 Oct 2015 21:32:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhpCg-0003D9-Iy for qemu-devel@nongnu.org; Thu, 01 Oct 2015 21:32:10 -0400 Received: from mail-am1on0077.outbound.protection.outlook.com ([157.56.112.77]:62676 helo=emea01-am1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhpCg-0003Bh-1H for qemu-devel@nongnu.org; Thu, 01 Oct 2015 21:32:06 -0400 References: <1443703035-4433-1-git-send-email-gang.chen.5i5j@gmail.com> <560DD1AB.7080808@twiddle.net> From: Chris Metcalf Message-ID: <560DDE8D.8040202@ezchip.com> Date: Thu, 1 Oct 2015 21:31:57 -0400 MIME-Version: 1.0 In-Reply-To: <560DD1AB.7080808@twiddle.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3] target-tilegx: Support iret instruction and related special registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , gang.chen.5i5j@gmail.com, peter.maydell@linaro.org Cc: qemu-devel@nongnu.org, xili_gchen_5257@hotmail.com On 10/1/2015 8:36 PM, Richard Henderson wrote: > On 10/01/2015 10:37 PM, gang.chen.5i5j@gmail.com wrote: >> { >> mtspr INTERRUPT_CRITICAL_SECTION, r3 >> shli r2, r2, SPR_EX_CONTEXT_0_1__ICS_SHIFT >> } >> >> { >> mtspr EX_CONTEXT_0_0, lr >> ori r2, r2, RETURN_PL >> } >> >> { >> or r0, r1, r0 >> mtspr EX_CONTEXT_0_1, r2 >> } >> >> iret >> >> jrp lr >> >> Until now, EX_CONTEXT_0_0 and EX_CONTEXT_0_1 are only used in mtspr, so >> just skip them, at present. "jrp lr" in __longjmp is for historical >> reasons, and might get removed in the future. > > So, really, iret is supposed to branch to EX_CONTEXT_0_0, and (presumably) validate the privilege level in EX_CONTEXT_0_1 continues to be user-mode. Yes, I gave the same feedback earlier today. EX_CONTEXT_0_1 should be either 0 or 1 to set INTERRUPT_CRITICAL_SECTION appropriately, and raise GPV for any other value. (Obviously it's more complex if you're really emulating system software, but for now that's out of scope, I think.) > >> + case OE_RR_X1(IRET): >> + if (srca) { >> + return TILEGX_EXCP_OPCODE_UNIMPLEMENTED; >> + } >> + srca = TILEGX_R_LR; >> + mnemonic = "iret"; >> + goto do_jr; > > which means this is wrong, but just happens to work for __longjmp. > > It appears that the entire point of this iret path is to atomically branch and set INTERRUPT_CRITICAL_SECTION at the same time. So, this isn't complete. > > What INTERRUPT_CRITICAL_SECTION is supposed to *do* at user mode, I don't know. It disables interrupts from being delivered. This means asynchronous interrupts get deferred until ICS is set back to zero, and synchronous interrupts (page fault, etc) cause a double-fault instead. ICS is automatically set on entry to interrupt handlers, so the handler has time to acquire any information about the interrupt from SPRs, and it is expected that ICS is cleared as soon as possible. ICS can also be used before returning from interrupts if you need to do something like adjust the interrupt mask prior to returning. -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com