Right, that's with kernel space descriptor is in gdt and not in ldt
>This could be done different
> for system calls (microkernels), but for interrupts flipping MMU state (VM
> map) would lead to delays unacceptable for many sorts of hardware. Kernel
> code needs to access *all* physical memory. Linux simply maps it starting
> from 0xc000000 (on x86). It's not the only way, see 4.4BSD pmap layer for
> example of alternative design. But there is no way in Hell to make all
> address space available for process. At the very least, you should have
> all kernel code mapped into it (and completely closed for usermode).
> Ditto for for large part of kernel data. It's not a Linux-specific
> question, BTW - it's how things work in any UNIX kernel.
Adress space is (on 386) 64TeraBytes pro task. Its enough to have
4Gbytes phys mem mapped into virutal memory, and 4Gbytes for one
process
When a task jumps into kernel code, CS is 0x10
When a task is in user mode, CS is 0x23.
It means that it is already two separate 4Gbytes capable spaces.
I agry kernel has to access all physical mem all the time. Just map
all 4Gbytes phys memory to selector 0x10, and leave 4Gbytes virtual
space for selector 0x23.
>
> > We should be able to map part of 4Go physical memory space to
> > where we want in virtual memory, by pages of 4kb,
> > And each process should be able to have 4Go virtual memory
>
> And where would the kernel live?
User CS=0x23, Kernel CS=0x10
>
> > Up to the kernel to do that.
>
> >From *where*?
>
> > Dont understand why we cut virtual memory in two parts: one usable
> > and one equal to "fixed" 1Go physical memory "pseudo limit"
>
> See above. x86 ain't KL-10. There is only one memory context and switch is
> way too expensive. For 64-bit architectures it's mostly non-issue -
> physical memory is *much* smaller than the address space.
>
In 386 also: 64Tera bytes address space, 4Gbytes phys space
Even if we say that process can only use 32 bits pointers, we still
have a full 4Gbytes space for process, and the rest for kernel
christophe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/