All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: cohutta <cohutta@MailAndNews.com>
Cc: linux-mm@kvack.org
Subject: Re: temp. mem mappings
Date: Wed, 6 Jun 2001 09:23:58 +0100	[thread overview]
Message-ID: <20010606092358.R26756@redhat.com> (raw)
In-Reply-To: <3B581215@MailAndNews.com>; from cohutta@MailAndNews.com on Tue, Jun 05, 2001 at 04:42:52PM -0400

Hi,

On Tue, Jun 05, 2001 at 04:42:52PM -0400, cohutta wrote:

>   Normal memory is identity-mapped very early in boot anyway (except for
>   highmem on large Intel boxes, that is, and kmap() works for that.)
> 
> I don't really want to play with the page tables if i can help it.
> I didn't use ioremap() because it's real system memory, not IO bus
> memory.
> 
> How much normal memory is identity-mapped at boot on x86?
> Is it more than 8 MB?

> I'm trying to read some ACPI tables, like the FACP.
> On my system, this is at physical address 0x3fffd7d7 (e.g.).

It depends at what time during boot.  Some ACPI memory is reusable
once the system boots: the kernel parses the table then frees up the
memory which the BIOS initialised.

VERY early in boot, while the VM is still getting itself set up, there
is only a minimal mapping set up by the boot loader code.  However,
once the VM is initialised far enough to let you play with page
tables, all memory will be identity-mapped up to just below the 1GB
watermark.

> kmap() ends up calling set_pte(), which is close to what i am
> already doing.  i'm having a problem on the unmap side when i
> am done with the temporary mapping.

kunmap().  :-)  But kmap only works on CONFIG_HIGHMEM kernel builds.
On kernels built without high memory support, kmap will not allow you
to access memory beyond the normal physical memory boundary.

Cheers,
 Stephen
--
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-mm.org/

  parent reply	other threads:[~2001-06-06  8:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-05 20:42 temp. mem mappings cohutta
2001-06-05 20:59 ` Timur Tabi
2001-06-05 22:27   ` Joseph A. Knapka
2001-06-06  8:23 ` Stephen C. Tweedie [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-06-11 16:32 cohutta
2001-06-25  6:52 ` Eric W. Biederman
2001-06-08  1:38 cohutta
2001-06-08 17:02 ` Joseph A. Knapka
2001-06-08 18:07 ` Stephen C. Tweedie
2001-06-08 21:22   ` Joseph A. Knapka
2001-06-06 21:14 cohutta
2001-06-07 10:00 ` Stephen C. Tweedie
2001-06-05 17:54 cohutta
2001-06-05 18:25 ` Timur Tabi
2001-06-05 18:41   ` Stephen C. Tweedie
2001-06-05 18:51     ` Timur Tabi
2001-06-05 18:59       ` 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=20010606092358.R26756@redhat.com \
    --to=sct@redhat.com \
    --cc=cohutta@MailAndNews.com \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.