From owner-freebsd-arm@FreeBSD.ORG Thu Jan 17 01:35:13 2008 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 E6AED16A418 for ; Thu, 17 Jan 2008 01:35:13 +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 8714713C45A for ; Thu, 17 Jan 2008 01:35:13 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.13.8/8.13.8) with ESMTP id m0H1ZAJE059477; Wed, 16 Jan 2008 19:35:10 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1200533710; bh=BHXjL4Jb9sgd+aH50P2HIHODSNP0s4gUSOGAYvU gKH4=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=i9VqNUzX lN0K7hDWRGJjA5xKx1KO7cjAt6TYo+B+yIZz+/BMD4ooVT6Z8vGf+kB9FVRcguFIGPX rf21f5DujoaVEnOVJm6hKJPljsU7UGFQX66ObnxXKi545oXMXZR9xE3/CPtzUDWYOFZ tmiXSIrn/oOXkJ5ocXVGp37pkZCtE= Received: (from tinguely@localhost) by casselton.net (8.13.8/8.13.8/Submit) id m0H1Z8Dc059476; Wed, 16 Jan 2008 19:35:08 -0600 (CST) (envelope-from tinguely) Date: Wed, 16 Jan 2008 19:35:08 -0600 (CST) From: Mark Tinguely Message-Id: <200801170135.m0H1Z8Dc059476@casselton.net> To: mlfbsd@ci0.org, tinguely@casselton.net In-Reply-To: <20080117001757.GA63358@ci0.org> Cc: freebsd-arm@freebsd.org Subject: Re: ARM pmap cache flushed after PT modification. 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: Thu, 17 Jan 2008 01:35:14 -0000 > > On Wed, Jan 09, 2008 at 06:31:21PM -0600, Mark Tinguely wrote: > > > > Using the same logic that the ARM ARM for pre-ARMv6 MMUs says the > > cache has to be written back and/or invalidated before making > > changes to page table entries; pmap_remove_all() also forces the > > page table entry to NULL and I believe needs to be invalidated. > > > > Hi Mark, > > I'm not sure this is needed, because we mark the page tables as write-through. > Also, I must miss something, because I understand why we should wb after doing > the changes, but why before ? > > (And no, I didn't forget you, and I'll have a look at your work soon, honest). I think we are talking about 2 different issues: 1 You are talking about the Memory that holds pagetable enties. The pagetable entry gets changed and the memory that holds the the pagetable is write through so that pagetable value is reflected back to memory. 2 The Instructions/Data that is in a cache Let me attempt to describe the other issue. pagetable maps virtual address to a physical address. The data/instruction can be cached in a virtul indexed, virtual tagged cache in ARM MMUs before ARMv6 (starting at ARMv6, they used either virtual indexed, virtual tagged or physical indexed, physically tagged caches). The virtual indexed/virtual tagged cache needs the virtual to physical mapping (TLB or pagetable walk) to write the dirty values to the correct physical memory location. Therefore it is important to write back the cache before clearing the pagetable entry - before the virtual to physical mapping is gone. In the two routines that I mentioned, this is simple to do: in pmap_remove_pages(), the cpu_idcache_wdinv_all() can be done before the loop; in pmap_remove_all(), a pmap_remove_write() before the loop will give 2 benefits, it will flush/invalidate and prevent the exceesive vac_me_harder() calls. --- ARMv6 will be much better when it comes caching. Besides the physical tagging on the cache - so addresses can more easily share a physical page, there is a ID that can be assigned to 256 virtual address spaces and not have to flush the virtual address spaces so often. --Mark.