On Mon, May 12, 2014 at 2:25 PM, Jonas Bonn <[email protected]> wrote:
> Sorry for the long silence on the list... not much time for OpenRISC of
> late. Thought I'd chime in with a couple of comments, mostly off the
> top of my head.
>
Nice to hear from you again!
> i) the _only_ reason we need scratch regs is because we need to switch
> from the user-stack to the process' kernel stack.
> ii) for syscalls, we have scratch regs (the call-clobbered regs) so
> there's no issue here... I don't think I pushed my patch for this
> upstream, but it should be in my repo somewhere... check for branches
> with syscall in the name
> iii) for exceptions, there's nothing you can do that will suddenly get
> you a scratch reg... _all_ the regs are precious and need to be restored
> exactly as they were when returning to userspace. Switching from r10 to
> r21 gets you nothing here as you still need to save r21.
You miss the point of what I tried to achieve, I was hoping to make
use of r10 as a "kernel reserved register" (since that's what the
'bug' basically could be interpreted as).
So, with an ABI like that, yes, you'd need to save r21, but not r10.
But, this discussion is moot anyway now ;)
> iv) r10 was chosen as the TLS reg (GOT? not quite sure...) exactly
> because it was globally reserved, but it was just a happy coincidence
> that it was reserved because it really didn't need to be (from the
> kernel's point of view) and the spec definitely doesn't (didn't)
> document it as so. It was, really, a bug in the compiler... now that
> "bug" has been put to good use!
It's TLS, for GOT we've got another reg pinned down - r16.
> v) I never liked the way Linux uses some hard-coded low memory address
> for scratch space... there's almost always a cache-miss there to begin
> with that slows down exception handling a fair bit.
Yeah, and the problem we are trying to solve now is that it doesn't
work in the multi-core case.
So it's a multi-issue that would be nice to get around. ;)
> vi) We can't use the userspace stack for scratch space because we can't
> afford to take a page fault when accessing the scratch regs.
>
> So what's the way forward here...?
>
> i) fast context switching is a no go because this assumes that the
> exception context doesn't need to know anything about the interrupted
> context... this is not true on LInux where the kernel definitely needs
> to access the userspace registers.
>
Yeah, I agree, it's also way to "heavy" to implement everything the
arch spec demands for 'fast context switching' anyway I think.
> ii) r1 is the "stack" register and this is documented in the spec. What
> if there was an SPR that contained the "supervisor stack" address, and
> on an exception the processor automatically writes that value into r1
> and saves the value of r1 (the userspace stack pointer) into another SPR
> ("process stack" SPR, like it saves the PC to an SPR...? This would
> amount to a "fast" context switch that's relevant for Linux, at least...
> a fast swap of the process stack. And it really only requires a single
> SPR as you could presumably just swap the value of r1 with this SPR when
> going to/from an exception.
>
> SPR_EXCEPTION_STACK: contains the address of an exception stack to
> switch to on exception entry; upon exception entry, the values of this
> SPR and r1 will be swapped so that r1 points to the exception stack and
> the SPR contains the value of the r1 from the interrupted context
>
Hmm, interesting thought, that will need some more consideration.
Otoh, you could quite easily manually implement this kind of behaviour
with the more "generic" kind of SPR scratch regs we have been
discussing below.
Stefan
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
