On Fri, Jun 22, 2007 at 08:41:27PM +1200, Matthew Luckie wrote:

> On the 15th of May 2007 we exchanged emails.
> 
> >I'd never have thought to allow CP0 access to user programs.  Certainly
> >from a general standpoint you couldn't do this, since then any user
> >process can completely corrupt the machine state and security would be
> >pretty much non-existant.  That said, it seems like what you suggest
> >might work.  Just be _really_ careful which registers you touch :-)
> 
> For the list archives, it turned out that the magic place to do the 
> modification to the status register is
> 
> sys/arch/mips/mips/mips_machdep.c:setregs()
> 
>  f->f_regs[_R_SR] = PSL_USERSET | MIPS_SR_COP_0_BIT;
> 
> the changes i tried in
> 
> sys/arch/mips/mips/vm_machdep.c:cpu_lwp_fork(), cpu_setfunc()
> 
>  pcb->pcb_context[11] |= (PSL_LOWIPL|MIPS_SR_COP_0_BIT); /* SR */
> 
> had no effect.

I'm both happy and sorta scared that that works for you :-)

> >I'm guessing the overhead of a gettimeofday(2) system call is either
> >too high, or not granular enough?  The way I'd probably go about this
> >if I really needed access to CP0 Count would be to add some sort of
> >fast path handling.  Perhaps add a new system call number and check for
> >it explicitly in MIPSX(SystemCall) before you set up the kernel stack
> >frame.  You could do that in a handful of instructions, and the impact
> >on normal system calls should be quite minimal.
> 
> I wasn't sure what you meant by this when you wrote it, but now it is 
> fairly clear.  I would be happy to put some effort into modifying that 
> routine and submitting code back to NetBSD if someone else thought this 
> might be a useful thing, though I guess modifying such a critical 
> function (speed-wise) is not likely to be feasible.

I think in general we don't want to slow down the syscall patch for such
a special case.  Now that I'm thinking about it again, a perhaps better
option would be do a fast path in the illegal instruction handler to
emulate a "mfc0 <reg>, MIPS_COP_0_COUNT" instruction.  But I'm still not
sure that it'd be worth the effort, and it'd still be slower than your
current (albeit I still think dangerous!) solution.

> But, at this time I've got what I've wanted and I'm happy :)

Cool!

Cheers,
Simon.