This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sat Jan 28 01:07:41 2023 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8HJgoi12728 for ; Tue, 17 Sep 2002 21:42:50 +0200 Received: (qmail 1031 invoked from network); 17 Sep 2002 19:39:16 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 17 Sep 2002 19:39:16 -0000 Received: (qmail 2338 invoked by uid 1000); 17 Sep 2002 19:39:16 -0000 MBOX-Line: From linux-kernel-owner@vger.kernel.org Mon Aug 28 12:43:47 2000 Received: (maildatabase); juh Received: (qmail 10490 invoked by alias); 28 Aug 2000 12:43:47 -0000 Received: (qmail 10487 invoked from network); 28 Aug 2000 12:43:46 -0000 Received: from vger.kernel.org (199.183.24.194) by spaans.ds9a.nl with SMTP; 28 Aug 2000 12:43:46 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 28 Aug 2000 08:56:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 28 Aug 2000 08:56:12 -0400 Received: from soong.cistron.net ([195.64.68.35]:39944 "EHLO smtp.cistron.nl") by vger.kernel.org with ESMTP id ; Mon, 28 Aug 2000 08:56:01 -0400 Received: from cs1p37.dial.cistron.nl ([62.216.3.38] helo=test.augan) by smtp.cistron.nl with esmtp (Exim 3.13 #1 (Debian)) id 13TOF7-0006P5-00; Mon, 28 Aug 2000 14:42:25 +0200 Received: from augan.com (IDENT:roman@serv2.augan [130.1.1.31]) by test.augan (8.9.3/8.8.7) with ESMTP id OAA25366; Mon, 28 Aug 2000 14:41:51 +0200 Message-Id: <39AA5E0F.FB164766@augan.com> Date: Mon, 28 Aug 2000 14:41:51 +0200 From: Roman Zippel Organization: Augan Instruments BV X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.15 i686) X-Accept-Language: en Mime-Version: 1.0 To: Timur Tabi Cc: Linux MM mailing list , Linux Kernel Mailing list Subject: Re: How does the kernel map physical to virtual addresses? References: <20000825233718Z131190-247+15@kanga.kvack.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Hi, > When my driver wants to map virtual to physical (and vice versa) addresses, it > calls virt_to_phys and phys_to_virt. All these macros do is add or subtract a > constant (PAGE_OFFSET) to one address to get the other address. > > How does the kernel configure the CPU (x86) to use this mapping? I was under > the impression that the kernel creates a series of 4MB pages, using the x86's > 4MB page feature. For example, in a 64MB machine, there would be 16 PTEs (PGDs? > PMDs?), each one mapping a consecutive 4MB block of physical memory. Is this > correct? Somehow I believe that this is overly simplistic. Do you want it overly complex? :-) As long as you don't have high memory (usally more than 1GB) all available memory is mapped in one virtual mapping, so virt_to_phys/phys_to_virt can simply use an offset. > The reason I ask is that I'm confused as to what happens when a user process or > tries to allocate memory. I assume that the VM uses 4KB pages for this > allocatation. So do we end up with two virtual addresses pointing the same > physical memory? You shouldn't mix kernel virtual mapping and user virtual mapping and yes, a page can be in both mappings, but the kernel can't access the user mapping directly, it has to use copy_(to|from)_user for this. > What happens if I use ioremap_nocache() on normal memory? Is that memory > cached or uncached? If I use the pointer obtained via phys_to_virt(), the > memory is cached. But if I use the pointer returned from ioremap_nocache(), the > memory is uncached. My understanding of x86 is that caching is based on > physical, not virtual addresses. If so, it's not possible for a physical > address to be both cached and uncached at the same. The cache is accessed with physical address, that's correct (at least on most architectures). But before the cache is accessed a virtual to physical translation is done and cached seperatly. During this translation you don't get only the physical address but also some properties on how it should be accessed, like read/write attributes, but also cachable/noncachable information. Only after the cpu got this information, it knows where _and_ how to access the memory and that might happen through the cache or not. BTW you might also want to look at __vmalloc() (in 2.4), it has a protection argument so you can easily create a vmalloc_nocache(). Afterwards you only have to look up the pages that were mapped. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/