I must confess I am not following all the details of this discussion which looks interesting.
However, I have some experience with multiprocessors sharing the same memory which I may outline and appreciate feedback: -- By means of physical address separation by hardware the various processors would have different physical memories, except for one shared portion. This way, no complications with virtual memory would occur. -- References to this shared portion would not be recognized as virtual addresses but would be directly accessed. Mutex and semaphores would be used for reserved access by each processor. Anything makes sense here? Jose On Mon, May 12, 2014 at 9:49 AM, Stefan Kristiansson < [email protected]> wrote: > 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 > -- Jose T. de Sousa, PhD Office: +351 213 100 213 R. Alves Redol 9 1000-029 Lisboa Portugal
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
