public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Denis Vlasenko <vda@ilport.com.ua>
To: "linux-os \(Dick Johnson\)" <linux-os@analogic.com>
Cc: "Jonathan M. McCune" <jonmccune@cmu.edu>,
	linux-kernel@vger.kernel.org,
	"Arvind Seshadri" <arvinds@cs.cmu.edu>,
	"Bryan Parno" <parno@cmu.edu>
Subject: Re: using segmentation in the kernel
Date: Thu, 13 Oct 2005 11:51:16 +0300	[thread overview]
Message-ID: <200510131151.16675.vda@ilport.com.ua> (raw)
In-Reply-To: <Pine.LNX.4.61.0510120837370.8832@chaos.analogic.com>

On Wednesday 12 October 2005 16:03, linux-os (Dick Johnson) wrote:
> On the ix86 you have a problem. Let's say that you write some
> code from scratch, that runs the CPU in 32-bit linear address-mode
> without paging. Then you want to activate paging. To activate
> paging, you MUST have provided some code and some data-space for
> your descriptors, where there is a 1:1 mapping between virtual
> and bus addresses. If you don't do this, at the instant you
> change to paging mode, you crash. The CPU fetches garbage.
> 
> This is why the first few megabytes of Linux are unity-mapped.
> You will always need to run the kernel out of an area where
> a portion of that "segment" is unity-mapped. That segment
> is where the descriptors for addressing, paging, and interrupts
> must reside.
>
> If you truly wanted to run the kernel from 3-4 GB as you state,
> you must have RAM there, i.e., some physical stuff so that
> a 1:1 mapping could be implemented. The 3-4 GB region is
> where a lot of PCI addressing occurs on 32-bit machines and,
> in fact, there are some "do-not-touch" addresses in that
> region as well.

This is untrue. After paging is enabled, you can jump
to non-unity mapped location and remove small unity-mapped region.

> Remember that the kernel runs in virtual address mode, but
> the descriptors that specify that mode need to be in physical
> memory, addressed at the same offset. You can experiment

Some of us are smart enough to add an offset when doing virt<->phys
conversion, if needed.
--
vda

      reply	other threads:[~2005-10-13  8:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-11 20:15 using segmentation in the kernel Jonathan M. McCune
2005-10-11 20:36 ` Brian Gerst
2005-10-11 20:24   ` Alon Bar-Lev
2005-10-11 21:12     ` Al Viro
2005-10-11 21:14     ` Brian Gerst
2005-10-12  9:05     ` Arjan van de Ven
2005-10-12 16:07       ` Alan Cox
2005-10-12 15:44         ` Arjan van de Ven
2005-10-12 23:55         ` Jonathan M. McCune
2005-10-12 13:03 ` linux-os (Dick Johnson)
2005-10-13  8:51   ` Denis Vlasenko [this message]

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=200510131151.16675.vda@ilport.com.ua \
    --to=vda@ilport.com.ua \
    --cc=arvinds@cs.cmu.edu \
    --cc=jonmccune@cmu.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=parno@cmu.edu \
    /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