From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KfdfE-0006P1-5r for qemu-devel@nongnu.org; Tue, 16 Sep 2008 12:44:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KfdfD-0006OA-9b for qemu-devel@nongnu.org; Tue, 16 Sep 2008 12:44:31 -0400 Received: from [199.232.76.173] (port=43863 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KfdfD-0006O4-7F for qemu-devel@nongnu.org; Tue, 16 Sep 2008 12:44:31 -0400 Received: from vsmtp02.dti.ne.jp ([202.216.231.137]:34533) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KfdfC-00042b-Fm for qemu-devel@nongnu.org; Tue, 16 Sep 2008 12:44:31 -0400 Received: from [192.168.1.21] (PPPa1372.e11.eacc.dti.ne.jp [124.255.91.108]) by vsmtp02.dti.ne.jp (3.11v) with ESMTP AUTH id m8GGiPru020985 for ; Wed, 17 Sep 2008 01:44:25 +0900 (JST) Message-ID: <48CFE26E.80302@juno.dti.ne.jp> Date: Wed, 17 Sep 2008 01:44:30 +0900 From: Shin-ichiro KAWASAKI MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] SH4: Privilege check for instructions References: <48CC8D3E.1040401@juno.dti.ne.jp> <48CCE727.7000203@juno.dti.ne.jp> <48CDBC9A.2070504@juno.dti.ne.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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 Blue Swirl wrote: >>>> I guess the codes generated by tcg_gen_qemu_st/ld() have the same >>>> restriction, because those tcg_gen functions take the argument QEMU >> memory >>>> index flags, which is decided at translation time. If it is true, the >>>> restriction might be allowed for privilege check. >>>> >>> The loads and stores have the same problem, the generated code assumes >>> that the privilege mode stays the same as what it was during >>> translation. >>> >> And the other problem is that loads/stores instructions (and privilege >> instructions), cannot follow some CPU status changes within one TB. >> This problem will be left considering the trade off with performance. > > The loads/stores will use the ctx->memidx, but that's fine as long as > ctx->memidx is accurate. To ensure this, the supervisor/user bits of > the CPU status may not change during the TB, all instructions that > write to those bits must end the TB. Maybe the other instructions are > fine, but how about 'rte'? 'rte' might cause a problem, but it will be a quite rare case, I guess. Other instructions have problems too. Those problems seems more important. 'rte' is one of the branch instructions, and it is used to return from exception handling. It has a delay slot. So at the end of TB, delay slot instruction is placed, and 'rte' is placed just in front of it. If 'rte' changes supervisor/user bits, it seems that the instruction in the delay slot should follow the change. But, I found that SH4 manual says that 'rte' has a restriction, that no exception allowed to happen in the delay slot. Because memory load/store instructions can cause TLB exception, I guess most OSes does not place memory load/store instructions in delay slot. SH-Linux places 'nop' in the delay slot. I'm not sure about other OSes. How about to check what kind of instruction is in the delay slot of 'rte'? By the way, special load instructions for SR ('ldc Rm,SR' and 'ldc @Rm+,SR'), can change supervisor/user bits. Though I guess SH-Linux does not use it to modify supervisor/user bits, it might be a problem for other OSes. Similar problems happen for status of floating point unit. The instructions 'lds Rm,FPSCR', 'lds @Rm+,FPSCR', 'frchg', and 'fschg', might change the status, and confuse the translated codes. I guess this will happen so often on SH-Linux. Will it be a solution to cut the TB just after these special load instructions? Regards, Shin-ichiro KAWASAKI