From owner-freebsd-arm@FreeBSD.ORG Wed Mar 25 00:40:24 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70921106566B for ; Wed, 25 Mar 2009 00:40:24 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 102808FC12 for ; Wed, 25 Mar 2009 00:40:23 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n2P0eK5E085340; Tue, 24 Mar 2009 19:40:20 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1237941620; bh=jyMo+mCucmNNuCFImp3waGDHOwDtezawj79yv6DMosg=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=AIXZ0Arx85vEMR1JQkofxB6d/TQ//69d2FH3VrNsB6p9s6D31TivMk1whLzf226iJ BEpkDQXMXkZbGXBU/LgTldLguHIfueOaqLSW/j0kb6BnBqs9sWG37h2DhPg8FO2CWz n2PQn1cwbxUO3AfJ4M+eDPUql43/TpuXxdQwzV2c= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n2P0eKHG085339; Tue, 24 Mar 2009 19:40:20 -0500 (CDT) (envelope-from tinguely) Date: Tue, 24 Mar 2009 19:40:20 -0500 (CDT) From: Mark Tinguely Message-Id: <200903250040.n2P0eKHG085339@casselton.net> To: mlfbsd@ci0.org, tinguely@casselton.net In-Reply-To: <20090325001649.GA84198@ci0.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.1.10 (casselton.net [127.0.0.1]); Tue, 24 Mar 2009 19:40:20 -0500 (CDT) Cc: freebsd-arm@freebsd.org Subject: Re: ARM atomic question X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:40:24 -0000 > > 1) how does this make it atomic? no one reads ras_start or ras_end > > to verify that it has not changed since I set it. This applies > > to all non-kernel atomic commands. Oliver says: > It is done by the kernel, when a trap occurs. They are issues with that > code, though, which should be worked on. Warner says: > The kernel looks at these addresses when it does a context switch. > Since there are no atomic ops, and you can't disable interrupts in > userland, we settle for the next worse thing: set critical sections > that are restarted if the kernel interrupts them. The page is installed in the KVA writable with user permission, in machdep: #ifdef ARM_CACHE_LOCK_ENABLE pmap_kenter_user(ARM_TP_ADDRESS, ARM_TP_ADDRESS); arm_lock_cache_line(ARM_TP_ADDRESS); #else m = vm_page_alloc(NULL, 0, VM_ALLOC_NOOBJ | VM_ALLOC_ZERO); pmap_kenter_user(ARM_TP_ADDRESS, VM_PAGE_TO_PHYS(m)); #endif Shouldn't a user be able to read/write to this address without a trap? I rewrote the cpu_throw() and cpu_switch(). Because: - combine the back end of cpu_throw() and cpu_switch. - implemented pmap active bit for a CPU for future SMP. - use the registers for per-cpu and TLS. - ARMv6 does not need to flush tlb/cache on context switch: - new ASID to identify 256 address spaces. - the VIPT caches need some changes to pmap_fix_cache(): - I don't want to make changes to pmap caching until we resolve the pre-ARMv6 multiple KVA map caching issue. I am running the pre-ARMv6 cache patch that I proposed (and the new swtch.S)that I proposed with QEMU. The patch finds remapping situations, but not those that caused cache problem. - the PIPT cache does not need to do pmap_fix_cache() at all. In rewiting the context change, I noticed that ARM_TP_ADDRESS/ARM_RAS_START/ ARM_RAS_END addresses are saved and restored on context switches. Atomic commands don't look to see if the ARM_RAS_START is 0 and ARM_RAS_END is 0xffffffff before they put their addresses and do their change. Thanks, --Mark.