From: "Blue Swirl" <blauwirbel@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] SH4: Privilege check for instructions
Date: Tue, 16 Sep 2008 21:19:26 +0300 [thread overview]
Message-ID: <f43fc5580809161119id344f4el42ec1f77ccf3176f@mail.gmail.com> (raw)
In-Reply-To: <48CFE26E.80302@juno.dti.ne.jp>
On 9/16/08, Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp> wrote:
> 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'?
I guess the TB will end after the delay slot. If that is the case,
only the delay slot instruction after 'rte' will be executed with user
permissions. Is this in line with the manual?
> 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?
That is the safest way, though I don't know what the bits mean. Maybe
some of the instructions can't change the interesting bits.
next prev parent reply other threads:[~2008-09-16 18:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-14 4:04 [Qemu-devel] [PATCH] SH4: Privilege check for instructions Shin-ichiro KAWASAKI
2008-09-14 6:34 ` Blue Swirl
2008-09-14 10:27 ` Shin-ichiro KAWASAKI
2008-09-14 11:26 ` Blue Swirl
2008-09-15 1:38 ` Shin-ichiro KAWASAKI
2008-09-15 8:49 ` Aurelien Jarno
2008-09-15 15:19 ` Blue Swirl
2008-09-16 16:44 ` Shin-ichiro KAWASAKI
2008-09-16 18:19 ` Blue Swirl [this message]
2008-09-17 1:20 ` Shin-ichiro KAWASAKI
2008-09-17 14:42 ` Paul Mundt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f43fc5580809161119id344f4el42ec1f77ccf3176f@mail.gmail.com \
--to=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).