Re: [Qemu-devel] [PATCH] SH4: Privilege check for instructions

[Shin-ichiro KAWASAKI]

Blue Swirl wrote:
> On 9/16/08, Shin-ichiro KAWASAKI <address@hidden> 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?

Oh, I reviewed the manual again, and found it.

The manual is 'SH7751 Series SH7751, SH7751R Hardware Manual'.
(It could be found with searching 'e602201_sh7751.pdf'). In section
7.1, there's a description on the status of 'rte' delay slot. 
It says,
- instruction access is done with status before modification (supervisor mode, 
I guess)
- data acess is done with status after modification (user mode)

> >  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.

Those instructions can change any bits in SR or FPSCR.
SR includes supervisor/user mode bits SR_MD, which influences ctx->memidx.
FPSCR includes the bits which decides,
- the size of fp calculation, 32bit or 64 bit  (SZ bit and PR bit)
- bank of register used for fp calculation (FR bit)
Current implementation in "target-sh4/translate.c" refer those
conditions at translation time, and generates the code correspond
to them.


I hope my explanation is clear enough.
Thanks for your response!

Regards,
Shin-ichiro KAWASAKI