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

[Shin-ichiro KAWASAKI]

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