Hi,
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.
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.
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!
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.
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.
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
This is a massive top-post... my apologies for that... I'll blame it on
being down with the flu... :)
On 05/12/14 10:49, Stefan Kristiansson wrote:
> On Mon, May 12, 2014 at 10:52 AM, Stefan Wallentowitz
> <[email protected]> wrote:
>> On 05/11/2014 07:02 PM, Stefan Kristianss
>> I am sorry, I missed almost all of the TLS discussion. I am somewhat
>> sceptic about this r10 reservation. Isn't that somewhat a security
>> issue, when the kernel depends on that the user doesn't corrupt the
>> register? Can the kernel crash if the user does so?
>> What is the reason that is not a kernel variable. If it urgently needs
>> to be a register, its another candidate for a shadow register. Again
>> sorry, if you need to repeat on this one.
The kernel's use of r10 doesn't overlap with the userspace usage of
r10. As far as the kernel is concerned, r10 is just another
"call-saved" register that it _always_ has to restore when returning to
userspace.
The usage of r10 in the kernel for thread_info is an optimization... I'm
not totally convinced that it's even a good optimization; but much of
the OpenRISC code is "borrowed" from the mips/powerpc architectures and
they use r10 in a similar manner.
> Sorry that I slightly glossed over this explanation, I didn't want it
> to get to lengthy since it's not a viable option anyway.
> But, the idea I had was to exchange the thread_info reg (and you're
> probably right, this might not need to be a register)
> from r10 to r21.
> The point with doing that, was that r21 can be reserved within the
> kernel with the -ffixed-r21 option,
> and that would have left the (globally) reserved r10 free to be used
> as a scratch reg.
> This is how the discarded kernel patch for this looked like:
> http://pastie.org/9167841
As I mentioned above, this just shifts the problem from r10 to r21... I
wanted to use r0 as a scratch reg since it has a known value, but you
wouldn't agree to make r0 _always writable_ so it was a no-go as far as
portability was concerned.
/Jonas
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
