From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KfFrT-0003c2-9w for qemu-devel@nongnu.org; Mon, 15 Sep 2008 11:19:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KfFrS-0003bE-Hl for qemu-devel@nongnu.org; Mon, 15 Sep 2008 11:19:34 -0400 Received: from [199.232.76.173] (port=35230 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KfFrS-0003b2-2G for qemu-devel@nongnu.org; Mon, 15 Sep 2008 11:19:34 -0400 Received: from yw-out-1718.google.com ([74.125.46.158]:53476) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KfFrS-00076a-6l for qemu-devel@nongnu.org; Mon, 15 Sep 2008 11:19:34 -0400 Received: by yw-out-1718.google.com with SMTP id 6so627161ywa.82 for ; Mon, 15 Sep 2008 08:19:32 -0700 (PDT) Message-ID: Date: Mon, 15 Sep 2008 18:19:31 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] SH4: Privilege check for instructions In-Reply-To: <48CDBC9A.2070504@juno.dti.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CC8D3E.1040401@juno.dti.ne.jp> <48CCE727.7000203@juno.dti.ne.jp> <48CDBC9A.2070504@juno.dti.ne.jp> 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/15/08, Shin-ichiro KAWASAKI wrote: > Blue Swirl wrote: > > > On 9/14/08, Shin-ichiro KAWASAKI wrote: > > > > > Thank you for the comment! > > > > > > Blue Swirl wrote: > > > > > > > > > > On 9/14/08, Shin-ichiro KAWASAKI wrote: > > > > > > > > > > > > > This patch adds check for all SH4 instructions which are > > > > > executed only in privileged mode. > > > > > > > > > > > > > > The checks get the privileged mode status from translation context. In > > > > theory, the same TB code block could be used in unprivileged and > > > > privileged mode, so the status that was true at translation time may > > > > no longer be correct at execution time. Of course normally kernel code > > > > is not visible or executable to user processes. > > > > > > > > > > > As you say, this patch has the restriction that you pointed out : the > > > generated TB cannot used for both unprivileged and privileged. > > > > > > > Qemu will happily use the same TB for both modes, if the TB flags > > match (cpu-exec.c): > > > > if (unlikely(!tb || tb->pc != pc || tb->cs_base != cs_base || > > tb->flags != flags)) { > > tb = tb_find_slow(pc, cs_base, flags); > > } > > > > Thanks! I have not understood this point. You mean, > the main problem is that the one TB can be reused for both modes, and to > check if new translation for the TB is necessary or not, > flags should contain enough information taken from CPU status. Right. > > > 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'?