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. > 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. Bye, Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
