On Mon, May 12, 2014 at 10:52 AM, Stefan Wallentowitz <[email protected]> wrote: > On 05/11/2014 07:02 PM, Stefan Kristiansson wrote: >> As I mentioned in another thread, I've grown less hostile than I first >> was towards this. >> And now I've came into the position where I believe we really need it ;) > good :) >> Long story short, I've been looking into what would be needed to make >> the reg stashing in the Linux >> kernel per-cpu, and I had an idea that I would be able to use the >> globally reserved register r10. >> The reason I believed this was that the only usage within the kernel >> was for the thread_info >> pointer, and that only needs to be reserved *within* the kernel. >> All was going well until Christian pointed out that r10 is now used by >> the TLS code. > 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.
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 The prerequisite for this to work, is of course that user space doesn't use r10 for anything. The problem now, is that user space *do* use r10 for TLS related things. (https://github.com/openrisc/or1k-glibc/blob/master/ports/sysdeps/or1k/nptl/tls.h#L47) So, to make things clear, the kernel doesn't rely on r10 to stay intact "over userspace", it'll reload it on userspace->kernelspace transitions. The only thing that the kernel relies on, is that r10 stay intact *within* the kernel. The fact that r10 now was taken in to use for the TLS stuff is just an unrelated (slightly unfortunate) coincidence and I don't blame Christian for picking that, I probably would have considered the already reserved r10 a convenient choice as well. =) >> So, the end result is that in Linux, we now have 0 scratch regs to use. >> >> I've been giving this some *further* more thought, and I believe what >> might be the best solution, >> both from a "keep the arch spec changes down" and an implementation >> point of view, is to >> allow implementations to use the GPR SPR address space to add another >> set of GPRs, but >> without being forced to implement all of the "heavy" context-switch stuff. > That sounds reasonable. > > I have another option that is only senseful when this is a > multicore-only problem (which I think is not the case with r10 in Linux): > Use a "Multicore Support Unit" (TODO: find better name), that has > scratch SPRs to temporarily store data. But beside this it may be good > to have something like mailboxes or inter-processor interrupts (maybe a > new exception for this also). Although not necessary, it may be worth > considering. Yes, I agree that there might be other multicore specific things that'll be needed/desired. It probably makes sense to group them together as you suggest. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
