Contents of CR3 register when a kernel thread is executed

[dhylands@gmail.com (Dave Hylands)]

Hi John,

2011/4/20 limp <johnkyr83@hotmail.com>:
> Thank you all for your replies,
>
>> yes, "borrow" in the sense that: ? kernel thread DOES NOT have any process
>> context, and so it can be executed in any process context, and which ever
>> process context it is executing, when u print the CR3 value, it will
> belong
>> to that process which the kernel thread is currently executing under.
>
> I've read on LKD by Robert Love book the following:
> "Because kernel threads do not have any pages in user-space, they do not
> really
> deserve their own memory descriptor and page tables. Despite this, kernel
> threads
> need some of the data, such as the page tables, even to access kernel
> memory.
> To provide kernel threads the needed data, kernel threads use the memory
> descriptor
> of whatever task ran previously"
>
> I can't really tell which are the data which are needed by kernel threads
> that the
> book is talking about..By combining the above with the following (from the
> same book):

The data being referred to is the memory which contains the page
tables which provide the mapping from virtual to physical addresses.

The page tables are actually allocated out of system memory. The MMU
only uses them, it doesn't have any memory of its own (except for
things like TLB caches).

> "The kernel thread can then use the previous process's page tables as
> needed. Because
> kernel threads do not access user-space memory, they make use of only the
> information
> in the address space pertaining to kernel memory, which is the same for all
> processes."
>
> I conclude the following:
> A kernel thread uses only the address space of the previously scheduled user
> process
> pertaining to kernel memory for accessing kernel memory. Also, a kernel
> thread is using
> the virtual memory mechanism of user process to access kernel memory. That
> is, it runs
> on user-space but accesses *only* kernel memory, right? - i.e. it is
> basically a user
> process that access only Kernel memory - Why kernel threads cannot directly
> access
> kernel memory and use a mechanism used in user-space for accessing it?

Well - yeah that's sort of right. Except that kernel threads aren't
really in any "process", unless perhaps you consider the entire kernel
to be one big process.

Every user process has the kernel space mapped into it, but it's not
accessible unless you're in "supervisor" mode. When you transition
from user space to kernel space, you switch to supervisor mode and you
can now access kernel memory.

For example, 0xc0000000 - 0xffffffff is typically your kernel space,
and 0x00000000 - 0xbfffffff is user space (there are lots of
variations, this is just an example).

Since the kernel threads don't access the memory below 0xc0000000,
every kernel thread sees the same mapping.

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com