Re: using segmentation in the kernel

[linux-os (Dick Johnson)]

On Tue, 11 Oct 2005, Jonathan M. McCune wrote:

> Hello,
>
> We're starting work on a project for the 32-bit x86 Linux kernel that
> involves using segmentation in the kernel. As a first effort, we'd
> like to adjust the kernel code and data segment descriptors so that
> the kernel code, and data segment, bss, heap and stack exist in linear
> address range between 3GB and 4 GB. How could we implment this so that
> it breaks the memory management subsystem the least (or not at all if
> we are lucky ;-))?
>
> Our current thinking is to modify only the base address and the limit
> of the the kernel code and data segment descriptors (_KERNEL_CS and
> _KERNEL_DS). We set the base address to 3GB and the limit to 1GB. We
> would also change the kernel linker script (vmlinux.lds.S) by removing
> the relocation caused by PAGE_OFFSET. This would mean that the kernel
> would be linked to start at address 0 + 1MB in logical address
> space. Since we would set the base address of the kernel code and data
> segment descriptors to 3GB, the processor would translate all
> addresses emitted by the kernel so that the kernel would use addresses
> of 3GB + 1MB and above in the linear address space. Hopefully, this
> would mean that the all the paging code in the kernel would continue
> to work correctly.
>
> We do not understand the mm subsystem well enough to figure out if our
> method would work at all or if it works what things in the mm
> subsystem would be likely to break. Can someone who understands the mm
> subsystem please help us here?
>
>
> Thanks!
> -Jon
>

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.

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
by making a module that attempts to turn off paging and
then turn it back on. The kernel will crash instantly.
However, if you write some code somewhere in low address-
space where the startup code already exists, that turns
off paging, then turns it back on; and your module code
calls this other code, the machine will work fine. You
need the interrupts off when you play.

So, basically you can't do what you want with any OS that
uses ix86 type CPUs. The question is; "What was it that
you really wanted to do?". What you gave us was the
"implementation details". What I want to know is what
you intend to accomplish. The ix86 architecture lends itself
to a lot of interesting things so if I knew your intentions
I might be able to help.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.48 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@xxxxxxxxxxxx - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/