Date: Fri, 1 Mar 2013 14:20:16 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-current@freebsd.org, Olivier Houchard <cognet@ci0.org>, Andrew Turner <andrew@fubar.geek.nz> Subject: Re: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <CAFHCsPWWLkGwNJLcC2iibF0if1rEA%2BC=aeM%2B226X3jjt4xE-uw@mail.gmail.com> In-Reply-To: <20130226123904.GO2454@kib.kiev.ua> References: <CAFHCsPUVTM9jfrnzY72YsPszLWkg-UaJcycTR4xXcS%2BfPzS1Vg@mail.gmail.com> <201302201022.29294.jhb@freebsd.org> <CAFHCsPXEDiaKSkHNbycs%2B1DKkL7BcYJBk5eN%2BKpsLY8B%2B-u5gQ@mail.gmail.com> <201302211043.49906.jhb@freebsd.org> <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> <20130226210651.580c46a7@bender> <20130226123904.GO2454@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 26, 2013 at 1:39 PM, Konstantin Belousov <kostikbel@gmail.com> wrote: > On Tue, Feb 26, 2013 at 09:06:51PM +1300, Andrew Turner wrote: >> Does anyone know if it is only curthread that needs to be atomic? If so >> this should work. Reading the cpuid from the system currently is a >> single instruction, however it appears the code will need to be reworked >> for use with multiple levels of affinity, for example when there >> are clusters of cores the current code will number two cores on >> different clusters with the same id. >> >> I don't think we need to use ldrex/strex to read/write the values, my >> understanding is the rest should be safe to access without atomic >> functions. > > I read about ARM architecture some time ago. What I am saying below is not > a proposal, but rather a way for me to learn more about the architecture. > > From my reading of the docs, ARM has the shadow registers, in particular, > the r13 (stack pointer) is shadowed for all privileged modes. Is the shadow > used by our kernel, is it correctly restored on the context switch ? > > If yes, you can easily recover the pcb address from the current sp, > without accessing any coprocessor registers, and even without any > assignment of the global register for curthread (which needs to be > done at the kernel entry). Just align the stack > start on the 2*PAGE_SIZE boundary (like it is already done for MIPS), > and do the mask operation on the sp value to get the end of pcb. > This is atomic and context-switch safe. > > pcb us already per-thread, and can store the thread pointer. > More, you can store the curcpu or cpuid pointer into pcb too, > and update it on the context switch. > > amd64 has an architecturally-defined special register (k)gsbase, which > effectively must be correctly initialized at each kernel entry, and > restored on the return to usermode. Since the initialization on entry > and restoration on exit is not atomic wrt the entry/exit itself, amd64 > periodically gets a bugs which cause kernel running with user gsbase. > This is the fatal bug, destroying the kernel structures and allowing the > CPU privilege mode switch for normal user. > > Using the shadow registers for this purpose eliminate the whole source > of the bugs. Well, IMHO, the both kernel and user thread stacks must correctly be set for current threads, otherwise it doesn't work. So, the idea to save things on a thread stack and update them on a context switch will work in general. However, the stack must be aligned to its size. And this is the price. I have no idea how this kernel stack alignment can impact kernel virtual space fragmentation. OTOH, as you say, this kernel stack storage can be used for many things. Svata
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPWWLkGwNJLcC2iibF0if1rEA%2BC=aeM%2B226X3jjt4xE-uw>