From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 13:20:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 513B263B; Fri, 1 Mar 2013 13:20:18 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id CA9CAD1F; Fri, 1 Mar 2013 13:20:17 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id v28so317670qcm.25 for ; Fri, 01 Mar 2013 05:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MtlF7AyjrtSFAqN0QgKNr3mJV9yAbLMsp9xWXVE9lDQ=; b=0iAwiQOA/bFGZAnKHUrk/NlIAoi1Gs8DqvpljMCUZYcHc1XOyM5Nf30uNhMkxt/rHv Q1n01deQlP7MD4DppPLijAWmYG5KumBXyYde1DOwtQIJYjrb9XRXI62yQDC5bSZt0R+1 8Dq+5GtQkICtGtrb2zfgxijFIXBLFtmxWjB8RAm0vZtQUlNZw665veQRqOmWdnd2RxBC VNlaJJxTgtJIE78r84OmJ0q+xd3EidR0nkt9HBAZNT3+cxD7qs+/8xMBMUWpj0K9uVIO 1Xpjz7yaCOotguMFlTFD1me0vxUIzdhMSKw2hwdsEpi781psDexZpWalcN5TkmYsD/Dn ixEg== MIME-Version: 1.0 X-Received: by 10.224.33.14 with SMTP id f14mr19597959qad.69.1362144016379; Fri, 01 Mar 2013 05:20:16 -0800 (PST) Received: by 10.49.121.198 with HTTP; Fri, 1 Mar 2013 05:20:16 -0800 (PST) In-Reply-To: <20130226123904.GO2454@kib.kiev.ua> 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> Date: Fri, 1 Mar 2013 14:20:16 +0100 Message-ID: Subject: Re: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: 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 13:20:18 -0000 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. Svata