Sharing executable modules between user and kernel threads

Details Sharing executable modules between user and kernel threads Sharing executable modules between user and kernel threads

1997-02-06

2002-02-19

Maung, Zarni (Department: 2154)

Electrical computers and digital processing systems: memory

Addressing combined with specific memory configuration or...

Virtual machine memory addressing

C711S203000

Reexamination Certificate

active

06349355

ABSTRACT:

TECHNICAL FIELD
This invention relates to virtual memory systems and techniques in computer systems.
BACKGROUND OF THE INVENTION
It is common for a computer processor and associated operating system to have two different levels of resources and protection. One level, referred to as a non-privileged mode or user mode, is used by various operating system components, application programs, and other so-called “user” processes or programs. At this level, an execution thread is prevented by the operating system and by the computer processor from performing certain security-critical operations. The thread is also prevented from directly accessing many system resources. The purpose of the non-privileged execution mode is to isolate a user process as much as possible so that it cannot interfere with other user processes or with operating system functions. While a user process may itself crash, it should not be able to crash other programs or the operating system.
The other level of execution is referred to as privileged mode, system mode, or kernel mode. Critical operating system components are implemented in kernel mode—kernel-mode components are responsible for things like virtual memory management, responding to interrupts and exceptions, scheduling execution threads, synchronizing the activities of multiple processors, and other critical or sensitive functions. Such components, which execute from system mode, are generally referred to collectively as “the kernel.”
The kernel is responsible for supervising the virtual memory system in most computer systems. The virtual memory system is largely responsible for isolating processes from each other. With virtual memory, a process is assigned its own virtual address space, which is not available to other processes. Through its virtual memory, a process has a logical view of memory that does not correspond to the actual layout of physical memory. Each time a process uses a virtual memory address, the virtual memory system translates it into a physical address using a virtual-to-physical address mapping contained in some type of look-up structure and address mapping database.
Rather than attempting to maintain a translation or mapping for each possible virtual address, virtual memory systems divide virtual and physical memory into blocks. In many systems, these blocks are fixed in size and referred to as sections or pages. Data structures are typically maintained in physical memory to translate from virtual page addresses to physical page addresses. These data structures often take the form of conversion tables, normally referred to as page tables. A page table is indexed by virtual page address or number, and generally has a number of entries corresponding to pages in the virtual address space. Each entry is a mapping of a specific page number or virtual page address to a physical page address.
FIG. 1
shows a prior art example of a virtual memory system using a page table. A process generates a virtual address
12
. The page number portion of the virtual address (usually the uppermost bits) is used to index a page table
13
. The page table, in turn, contains a physical address of a location or page in physical memory
14
. In practice, a two-level page table scheme is often implemented, using multiple page tables in at least one of the levels.
FIG. 2
shows an additional level of address conversion available in processors such as the Intel 486 and Pentium Pro® microprocessors. These processors add a segment offset
15
to virtual memory address
12
before indexing the page table. The segment offset can be changed during program execution. In some cases, the segment offset changes automatically during program execution—such as when switching between privileged and non-privileged execution modes. To implement this feature, the microprocessor has sets of offset registers. A designated set is active at each different privilege level of the microprocessor. The different offset registers in each set are used for different types of memory accesses, such as for data memory access and code memory access.
A typical approach to managing computer system memory is to allocate some portion of the memory to the operating system or kernel and another portion for application or user processes. The kernel typically runs in a dedicated or private virtual address space. The kernel or system virtual address space is protected, by processor hardware, from being accessed by any execution thread that is not in the privileged execution mode. Therefore, in practice, the kernel address space consists of a range of virtual addresses that cannot be directly accessed by user processes.
Current micro processors have a 4 gigabyte virtual address space, which is typically divided for use by the kernel and by a user process, respectively. For example, the upper 2 gigabytes of these addresses might be reserved for the kernel, while the lower 2 gigabytes would be available for a user process. Each user process thus has its own 2 gigabyte virtual address space. A user process may conventionally access only the system memory allocated to the user process. The kernel may access both the kernel system memory and the user process system memory.
FIG. 3
shows virtual memory from the view of a user process and from the view of the system or kernel. The user process can use only a range of addresses from 0-2 gigabytes, typically referred to as a user address space. The kernel can access both its private, protected address space at a range of addresses from 2-4 gigabytes (addresses 80000000h to FFFFFFFFh), and the user address space at 0-2 gigabytes (addresses 00000000h to 80000000h).
Note that the kernel effectively has a single address space extending from 0 gigabytes to 4 gigabytes. The user address space appears in or is mapped into the lower 2 gigabytes of this address space, while the kernel executes from the upper 2 gigabytes of this space. The dashed arrow indicates that the kernel address space is mapped to physical memory in such a way that the user address space appears at addresses 00000000h to 80000000h of the kernel address space.
The actual mapping of virtual memory to physical memory is shown in
FIG. 4. A
user address space
16
(extending from address 00000000h to address 80000000h) is associated with a set of virtual-to-physical mappings
17
(implemented by processor-dependent structures such as page tables and offset registers). These mappings define a region
18
of physical memory for use by a user process.
Similarly, the kernel is located in an address space
19
(extending from address 80000000h to address FFFFFFFFh) that is associated with another set of virtual-to-physical mappings
20
. These mappings define a region
21
of physical memory for use by the kernel. Note that the physical address regions are not necessarily contiguous, although they are shown that way in
FIG. 4
for purposes of this discussion.
The kernel also has access to an address space
22
. This address space is associated with the same virtual-to-physical mappings
17
that are associated with user address space
16
, thereby associating physical memory region
18
with address space
22
. The result is that user address space
16
(corresponding to physical memory region
18
) appears in and can be accessed through address space
22
of the kernel as illustrated in FIG.
3
. Thus, the user address space can be described as being mapped into the kernel address space.
When there are a plurality of user processes, each with its own address space, only one of the address spaces is mapped into the kernel address space at any given time. The particular user address space that is mapped into the kernel's address space depends on the current execution context: if the processor is in the context of a user process
1
, the corresponding address space of user process
1
is mapped into the kernel's address space; if the processor is in the context of a user process
2
, the address space of user process
2
is mapped into the kernel's address space. At each context change,

Affiliated with

Also associated with

Rating

Sharing executable modules between user and kernel threads does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Sharing executable modules between user and kernel threads, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Sharing executable modules between user and kernel threads will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2936349