From owner-freebsd-arm@FreeBSD.ORG Wed Mar 25 01:10:42 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 DBD63106564A for ; Wed, 25 Mar 2009 01:10:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF6A8FC23 for ; Wed, 25 Mar 2009 01:10:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n2P18P5b002269; Tue, 24 Mar 2009 19:08:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 24 Mar 2009 19:09:00 -0600 (MDT) Message-Id: <20090324.190900.1598390393.imp@bsdimp.com> To: tinguely@casselton.net From: "M. Warner Losh" In-Reply-To: <200903250040.n2P0eKHG085339@casselton.net> References: <20090325001649.GA84198@ci0.org> <200903250040.n2P0eKHG085339@casselton.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 01:10:43 -0000 In message: <200903250040.n2P0eKHG085339@casselton.net> Mark Tinguely writes: : > > 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? Yes. In fact, that's the idea... : 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. Right. The kernel checks to see if a RAS is in flight. If so, it restores the pc to the start of the RAS. Warner