From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 15:32:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2EBBDC88; Fri, 1 Mar 2013 15:32:42 +0000 (UTC) (envelope-from cognet@ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id BCE5E36D; Fri, 1 Mar 2013 15:32:41 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r21FWAYU024819; Fri, 1 Mar 2013 16:32:10 +0100 (CET) (envelope-from cognet@ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r21FWA6I024818; Fri, 1 Mar 2013 16:32:10 +0100 (CET) (envelope-from cognet@ci0.org) X-Authentication-Warning: kanar.ci0.org: doginou set sender to cognet@ci0.org using -f Date: Fri, 1 Mar 2013 16:32:10 +0100 From: Olivier Houchard To: Svatopluk Kraus Subject: Re: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130301153210.GA24802@ci0.org> References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> <20130226210651.580c46a7@bender> <20130226123904.GO2454@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 01 Mar 2013 16:21:49 +0000 Cc: Konstantin Belousov , freebsd-current@freebsd.org, Olivier Houchard , Andrew Turner X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:32:42 -0000 On Fri, Mar 01, 2013 at 02:20:16PM +0100, Svatopluk Kraus wrote: > On Tue, Feb 26, 2013 at 1:39 PM, Konstantin Belousov > 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. > Hi, FWIW, I have a proof-of-ooncept patch that does just that, and it seems to work well. Regards, Olivier