linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roman Zippel <roman@augan.com>
To: Timur Tabi <ttabi@interactivesi.com>
Cc: Linux MM mailing list <linux-mm@kvack.org>,
	Linux Kernel Mailing list <linux-kernel@vger.kernel.org>
Subject: Re: How does the kernel map physical to virtual addresses?
Date: Mon, 28 Aug 2000 14:41:51 +0200	[thread overview]
Message-ID: <39AA5E0F.FB164766@augan.com> (raw)
In-Reply-To: <20000825233718Z131190-247+15@kanga.kvack.org>

Hi,

> When my driver wants to map virtual to physical (and vice versa) addresses, it
> calls virt_to_phys and phys_to_virt.\x1a 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2000-08-28 12:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-25 23:26 Timur Tabi
2000-08-28 12:41 ` Roman Zippel [this message]
     [not found] <20000825233748Z130198-15329+2857@vger.kernel.org>
2000-08-28 12:56 ` Tigran Aivazian
2000-08-28 15:12   ` Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39AA5E0F.FB164766@augan.com \
    --to=roman@augan.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ttabi@interactivesi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox