L4 Nucleus Version X Reference Manual x86

L4 Nucleus Version X Reference Manual x86
L4 Nucleus Version X
Reference Manual
x86
Version X.0
Jochen Liedtke
Universität Karlsruhe
[email protected]
September 3, 1999
Under Construction
How To Read This Manual
This reference manual consists of two parts, (1) a processor-independent description of the principles and
mechanisms of L4 and (2) a more detailed processor-specific description. Part 2 refers to the Intel processors,
Pentium R 1 and Pentium R Pro.
Credits
Helpful contributions for improving this reference manual and the L4 interface came from many persons, in
particular from Bryan Ford, Hermann Härtig, Michael Hohmuth, Sebastian Schönberg, Jean Wolter, Kevin
Elphinstone, Trent Jaeger, Yoonho Park, Volkmar Uhlig, and Gernot Heiser.
1 Pentium R
is a registered trademark of Intel Corp.
Contents
1
L4 in General
2
L4-X/x86
2.1 Notational conventions . . . . .
2.2 Data Types . . . . . . . . . . .
2.2.1 Unique Ids . . . . . . .
2.2.2 Fpages . . . . . . . . .
2.2.3 Messages . . . . . . . .
2.2.4 Timeouts . . . . . . . .
2.3 L4 Calls . . . . . . . . . . . . .
ipc . . . . . . . . . . . . . . . .
id nearest . . . . . . . . . . . .
fpage unmap . . . . . . . . . .
thread switch . . . . . . . . . .
thread schedule . . . . . . . . .
lthread ex regs . . . . . . . . .
task new . . . . . . . . . . . . .
2.4 Processor Mirroring . . . . . . .
2.4.1 Segments . . . . . . . .
2.4.2 Exception Handling . .
2.4.3 Debug Registers . . . .
2.5 The Kernel-Info Page . . . . . .
2.6 Page-Fault and Preemption RPC
2.7 RPC protocol . . . . . . . .
2.8 Starting L4 . . . . . . . . . . .
A Booting
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
10
10
11
13
15
16
23
24
25
26
28
30
32
32
32
32
33
34
35
37
39
Chapter 1
L4 in General
Chapter ommitted in this release.
7
Chapter 2
L4-X/x86
The L4/x86 Nucleus runs on x86-type processor’s that offer at least the functionality of an Intel 486 processor,
e.g. 486, Pentium, PentiumPro, Pentium II, and Pentium III.
2.1
Notational conventions
EAX,ECX. . .
SP If this refers to an input parameter, its value is
meaningless. If it refers to an output parameter,
its value is undefined.
denote the processor’s general registers.
denotes the word on the user stack addressed by
SP , where SP represents the user-level stack
pointer.
9
2.2
Data Types
2.2.1
Unique Ids
Unique ids identify tasks, threads and hardware interrupts. Each unique id is a 32-bit value which is unique
in time. An unique id in x86 format consists of one 32-bit word:
thread id
chief
task
lthread
task id
chief
task
0
interrupt id
0
ver
FFFFFFFF
255
64
1024
ver
intr + 1
0
invalid id
2.2.2
nil id
available tasks:
available threads per task:
usable version numbers:
1–255
0–63
0–1023
task 0 does not exist
Fpages
Fpages (Flexpages) are regions of the virtual address space. An fpage consists of all pages actually mapped
in this region. The minimal fpage size is 4 K, the minimal hardware-page size.
An fpage of size has a -aligned base address , i.e. !#"%$&('
) . On the x86 processors, the smallest
possible value for * is 12, since hardware pages are at least 4K. The complete user address space (base address
0, size ,+.-0/21 , where 1 is the size of the kernel area) is denoted by #34)5(*6387 . An fpage with base
address and size is denoted by a 32-bit word:
fpage 9:;5.=<
fpage 9H)5.+I-J/K1L<
>[email protected]=C=DE
0
0
0
F
G G
M
G G
32
IO-Ports
x86 IO-ports form a separate address space besides the conventional memory address space. Its size is 64 K
and its granularity is 16 bytes. However, IO-ports can only be mapped idempotently, i.e. physical port N is
either mapped at the address N in the task’s IO address space or it is not mapped.
L4 handles IO-ports like memory, i.e. as fpages. IO-fpages can be mapped, granted and unmapped like
memory fpages. However, since IO-ports can only mapped idempotent, always the complete IO space (64 K)
should be specified as receive fpage.
An IO-fpage of size (OQP*RPTSVU ) has a -aligned base address W , i.e. W#6"%$X('
) . An fpage with base
port address W and size is denoted by a 32-bit word:
IO-fpage 9W
5( <
F0
M
YQH
0
IO-fpage 9H)5([]\V<
F0
M
0
H
0
2.2.3
FZ
G G
G G
16
Messages
Register Messages/Buffers
Register messages consist of up to 3 words of 32 bits. Upon sending, the message is located in the registers
EDX, EBX, and EDI. Upon receiving, the same registers serve as a buffer, i.e. the registers EDX, EBX, and
EDI contain the received message (where send EDX is received EDX, etc.).
dword 2
EDI
dword 1
EBX
dword 0
EDX
Simple Memory Messages/Buffers
If messages are longer than 3 dwords, memory messages have to be used. Such messages consist of a message
descriptor (dope) that, e.g., specifies the current message length in dwords (msg snd dope) for messages to
be sent.
A message receive buffer is structured similarly but the size of the receive buffer, i.e. the maximum
message length than can be received in this buffer, is specified by the msg size dope, also in dwords. After a
message was received, the msg snd dope contains the current length of the received message. msg size dope
is unchanged.
..
.
dword 3
msg dwords:
+32
(dword 2 — not transferred)
M
+24
(dword 1 — not transferred)
M
+16
(dword 0 — not transferred)
M
+12
msg snd dope:
dwords
^
0
_
G`
+8
msg size dope:
dwords
^
0
_
G`
+4
msg rcv fpage option:
fpage
0
Using different send and size dopes permits to specify not only pure send messages and pure receive message
buffers. It is as well possibe to send a message and receive the reply using the same data structure. And, you
can also receive a message in a message buffer and then forrward this buffer as a message without changing
the data structure.
A further simplification for user-level programming is that the first three dwords of a message are always
transferred via register. This permits to handle long (memory) and short (register) messages basically in the
same way (the first three dwords are always in registers). Note that loading/storing those registers from/to the
message/buffer data structure is not handled by the Nucleus. It can be done at user level.
Memory Messages/Buffers With Indirect Parts
Complex messages or buffers can contain up to 31 indirect parts. The number of those parts is specified in
the parts fields. For buffers, the msg size dope defines the maximum number of accepted indirect parts for
receiving. For messages, msg snd dope defines the current indirect parts for sending, and the dwords field of
msg size dope defines the position a where the first indirect part is located. Therefore, the dwords field of the
msg size dope must be set correctly, even if it is a pure send message.
part0 dope:
..
.
+a +16
Bb
+a +0
X = (msg size dope.parts+3) [email protected]
..
.
..
.
msg dwords:
(dword 1)
+16
(dword 0)
+12
msg snd dope:
dwords
^
parts
_
G +8
msg size dope:
dwords
^
parts
_
G`
+4
msg rcv fpage option:
fpage
0
Every indirect part dope can specify an indirect send part and an indirect receive buffer. For a send message,
the receive buffer part is ignored. For a receive buffer, the receive buffer specifies the buffer address and
maximum length; after a message was received, the send part address is set to the beginning of the receive
buffer and the send part length specifies the current length. Thus, received parts can be forwarded by a
successive send operation without any change.
*rcv part
c
c
+12
.H
rcv part size
*snd part
part dope:
+8
M
snd part size
+4
.H
0
The e bits enable scatter/gather functionality. ef34) specifies the begin of a logical string; ef3gS specifies
that this is a continuation of the last logical string. On the sender side, logical string means a sequence of one
or more parts that are transferred as if they were one contiguous string (gather). On the receiver side, logical
string means a sequence of one or more buffers that are treated as one logical buffer; the corresponding
received string is scattered among them. Continuations can be arbitrarily combined on sender and receiver
side. Note that length and size fields are always per part.
Map Messages/Buffers
Map messages are differentiated from copy messages in the ipc system call. The format of a map message
is like a register message or memory message where the direct message part (not the optional indirect parts)
consists of snd fpages:
snd fpage
snd fpage:
snd base
h i
+4
0
' )
j ' S
k ' )
k ' S
2.2.4
The fpage will be mapped/granted read only.
The fpage will be mapped/granted with the full access right the mapper
possesses.
The fpage will be mapped.
The fpage will be granted.
Timeouts
Timeouts are used to control ipc operations. The send timeout determines how long ipc should try to send a
message. If the specified period is exhausted without that message transfer could start, ipc fails. The receive
timeout specifies how long ipc should wait for an incoming message. Both timouts specify the maximum
period of time before message transfer starts. Once started, message transfer is no longer influenced by send
or receive timeout.
Pagefaults occuring during ipc are controlled by send and receive pagefault timeout. A pagefault is
translated to an RPC by the kernel. In the case of a pagefault in the receiver’s address space, the corresponding
RPC to the pager uses send pagefault timeout (specified by the sender) for both send and receive timeout. In
the case of a pagefault in the sender’s address space, receive pagefault timeout specified by the receiver is
taken.
Besides the special timeouts 0 (do not wait at all) and l (wait forever), periods from 1 m s up to approximately 19 hours can be specified. The complete quadruple is packed into one 32-bit word:
npo Y q nq Y o M
r q must be 1, except for s ' ) .
Note that for efficiency reasons the highest bit of any mantissa s
w
t
snd timeout
w
t
rcv timeout
uvv y
if
vvx @ H_I{}|~ n q€ F
if
r (q z A
r q‚ A
A
if
npq z A„ƒ:r „q z … A
uvv y
if
vvx @ H_I{}|† no  F
if
r (o z A
r o‚ A
if
n Bo z „A ƒ:r o z … A
A
w
t
snd pagefault timeout
rcv pagefault timeout
t
w
r o M
uvv y
if
vvx @ H_I{‡B~  F
if
Y (q z A
A
if
A„ˆ,Y q Š
ˆ ‰]‹
Y q z ‰]‹
uvv y
if
Y o=z A
vvx @ .{‡ †  F
if
A
if
A ˆ Y o ˆ ‰]‹
Y o=z ‰]‹
approximate timeout ranges
r q ƒHr o ƒŒY q ƒŒY o
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
nz A„ƒr  A
snd/rcv timeout
y
pf timeout
y
256 s . . . 19 h
64 s . . . 55 h
16 s . . . 71 m
4 s . . . 17 m
1 s ... 4 m
262 ms . . . 67 s
65 ms . . . 17 s
16 ms . . . 4 s
4 ms . . . 1 s
1 ms . . . 261 ms
256  s . . . 65 ms
64  s . . . 16 ms
16  s . . . 4 ms
4  s . . . 1 ms
1  s . . . 255  s
0
256 s
64 s
16 s
4s
1s
256 ms
64 ms
16 ms
4 ms
1 ms
256  s
64  s
16  s
4 s
0
—
2.3
L4 Calls
This section describes the 7 system calls of L4:
Ž ipc
int 30
Ž id nearest
int 31
Ž fpage unmap
int 32
Ž thread switch
int 33
Ž thread schedule
int 34
Ž lthread ex regs
int 35
Ž task new
int 36
ipc
snd descriptor
timeouts
msg.w0
msg.w1
rcv descriptor
dest
msg.w2
propagatee
/
EAX
EAX
ECX
EDX
ECX
EDX
EBX
EBP

INT 0x30 
EBX
EBP
ESI
ESI
EDI
EDI
‘ SP ’
msg.dope + eBe
/
msg.w0
msg.w1
/
/
source
msg.w2
/
/
/
/
eBe
This is the basic system call for inter-process communication and synchronization. It may be used for intraas inter-address-space communication. All communication is synchronous and unbuffered: a message is
transferred from the sender to the recipient if and only if the recipient has invoked a corresponding ipc
operation. The sender blocks until this happens or a period specified by the sender elapsed whithout that the
destination became ready to receive.
Ipc can be used to copy data as well as to map or grant fpages from the sender to the recipient. For the
description of messages see section 2.2.3.
12-byte messages (plus 32-bit sender id) can be transferred solely via the registers and are thus specially
optimized. If possible, short messages should therefore be reduced to 12-byte messages.
A single ipc call combines an optional send operation with an optional receive operation. Whether it includes
a send respectively a receive is determined by the actual parameters. If the send or receive address is specified
as ”“• (0xFFFFFFFF), the corresponding operation is skipped.
No time is required for the transition between send and receive phase of one ipc operation.
Parameters
snd descriptor
“nil”
0xFFFFFFFF
M
Ipc does not include a send operation.
“mem”
*snd msg/4
M
n Y
Ipc includes sending a message to the destination specified by dest id. *snd
msg must point to a valid message. The first two 32-bit words of the message
(msg.w0 and msg.w1) are not taken from the message data structure but must
be contained in registers EDX and EBX.
“reg”
0
0
Y
Ipc includes sending a message to the destination specified by dest id. The
message consists solely of the two 32-bit words msg.w0 and msg.w1 in registers
EDX and EBX.
s`'
)
Value-copying send operation; the dwords or the message are simply copied to
the recipient.
snd descriptor
rcv descriptor
s ' S
Fpage-mapping send operation. The dwords of the message to be sent are
treated as ’send fpages’. The described fpages are mapped (respectively
granted) into the recipient’s address space. Mapping/granting stops when either the end of the dwords is reached or when an invalid fpage denoter is found,
in particular 0. The send fpage descriptors and all potentially following words
are also transferred by simple copy to the recipient. Thus a message may contain some fpages and additional value parameters. The recipient can use the
received fpage descriptors to determine what has been mapped or granted into
its address space, including location and access rights.
Wd'
)
Normal (unpropagated) send operation. The recipient gets the original sender’s
id.
W ' S
Propagating send operation. The additional propagatee parameter on the stack
specifies the id of the propagatee thread.
If propagatee and current sender or propagatee and receiver belong to the same
task, propagation is always permitted. Otherwise, the current sender is supposed to be a chief that uses deceiting and it is checked whether it is direction
preserving. If not, W and the propagatee parameter are ignored.
If propagation (or deceiving) is permitted, the receiver receives the propagatee’s id instead of the current sender’s id. If the propagatee is waiting (closed)
for a reply from the current sender, the propagatee’s status is additionally modified such that the propagatee now waits for a the new receiver instead of the
current sender.
The propagatee parameter on the user stack is only required if W ' S .
“nil”
0xFFFFFFFF
M
Ipc does not include a receive operation.
“mem”
*snd msg/4
M
–
0
Ipc includes receiving a message respectively waiting to receive a message.
*rcv msg must point to a valid message. The first two 32-bit words of the received message (msg.w0 and msg.w1) are not stored in the message data structure but are returned in registers EDX and EBX.
“reg”
0
–
0
Ipc includes receiving a message respectively waiting to receive a message.
However, only messages up to two 32-bit words msg.w0 and msg.w1 are accepted. The received message is returned in registers EDX and EBX.
“rmap”
rcv fpage
1
–
Ipc includes receiving a message respectively waiting to receive a message.
However, only send-fpage messages or up to two 32-bit words msg.w0 and
msg.w1 are accepted. The received message is returned in registers EDX and
EBX. If a map message is received, “rcv fpage” describes the receive fpage
(instead of “rcv fpage option” in a memory message buffer). Thus fpages can
also be received without a message buffer in memory.
— ' )
Only messages from the thread specified as dest id are accepted (“closed wait”).
Any send operation from a different thread (or hardware interrupt) will be handled exactly as if the actual thread would be busy.
— ' S
Messages from any thread will be accepted (“open wait”). If the actual thread
is associated with a hardware interrupt, also messages from this hardware interrupt can arrive.
'”˜ ”“•
Sending is directed to the specified thread, if it resides in the sender’s clan. If
the destination is outside the sender’s clan, the message is sent to the sender’s
chief. If the destination is in an inner clan (a clan whose chief resides in the
sender’s clan), it is redirected to that chief. (See also ‘nchief’ operation.) If no
send part was specified (snd descriptor ' ”“• ), dest id specifies the source from
which messages can be received. (However recall that the receive restriction is
only effective if — ' ) .)
9™”“• ' )š< Although specifying ”“• as the destination for a send operation is illegal (error: ‘destination not existent’), it can be legally specified for a receiveonly operation. In this case, ipc will not receive any message but will wait
the specified rcv timeout and then terminate with error code ‘receive timeout’.
(However recall that the receive restriction is only effective if — '›) .)
rcv descriptor
dest id
' ”“•
If a message was received this is the id of its sender. (If a hardware interrupt
was received this is the interrupt id.) The parameter is undefined if no message
was received.
source id
msg.w0, w1, w2
“snd”
First three 32-bit words of message to be sent. These message words are taken
directly from registers EDX, EBX, and EDI. They are not read from the message data structure.
“rcv”
First three 32-bit words of received message, undefined if no message was
received. These message words are available only in registers EDX, EBX, and
EDI. The Nucleus does not store it in the receive message buffer. The user
program may store it or use it directly in the registers.
msg.dope + cc
mwords
^
parts
_
œ]œ”
Message dope describing received message. If no message was received, only
eBe is delivered. The dope word of the received message is available only in register EAX. The Nucleus does not store it in the receive message buffer. The user
program may store it or use it directly in the register. (Note that the lowermost
8 bits of msg dope and size dope in the message data structure are undefined.
So it is legal to store EAX in the msg-dope field, even if eBe 'Z
˜ ) .)
r œ cc
'
)
'RS
s ' )
s ' S
¡ ' )
¡ ' S
“'Z)
“'¢S
 ž n Ÿ
The received message is transferred directly (“undeceited”) from source id.
The received message is “deceited” by a chief. source id is the virtual source
id which was specified by the sending chief.
The received message did not contain fpages.
The sender mapped or granted fpages. The sender’s fpage descriptors were also
(besides mapping/granting) transferred as mwords.
The received message was directed to the actual recipient, not redirected to a
chief. I.e. sender and receiver a part of the same clan. The “ -bit has no meaning
in this case and is zero.
The received message was redirected to the chief which was next on the path to
the true destination. Sender and addressed recipient belong to different clans.
If ¡ 'RS : the received message comes from outside the own clan.
If ¡ 'RS : the received message comes from an inner clan.
ec
'›)
ok: the optional send operation was successful, and if a receive operation was
also specified (rcv descriptor ' ˜ ”“• ) a message was also received correctly.
'›
˜ )
If ipc fails the completion code is in the range 0x10. . . 0xF0. If the send operation already failed, ipc is terminated without the potentially specified receive
operation. * specifies whether the error occurred during the receive 9H*£'¤)<
operation or during the send 9:* ' S;< operation:
1
¥¦*
Timeout.
O¦*
Cancelled by another thread (system call lthread ex regs).
U0¦*
Map failed due to a shortage of page tables.
§
¨
©
ª
Non-existing destination or source.
¦*
Send pagefault timeout.
¦*
Receive pagefault timeout.
¦*
Aborted by another thread (system call lthread ex regs).
¦*
Cut message. Potential reasons are (a) the recipient’s mword buffer is too small;
(b) the recipient does not accept enough parts; (c) at least one of the recipient’s
part buffers is too small.
1. . . 5
The according operation was terminated before a real message transfer started.
No partner was directly involved.
6. . . F
The according operation was terminated while a message transfer was running.
The message transfer was aborted. The current partner (sender or receiver) was
involved and got the corresponding error code. It is not defined which parts of
the message are already transferred and which parts are not yet transferred.
This 32-bit word specifies all 4 timouts, the quadruple (snd, rcv, snd pf, rcv pf).
For A detailed description see section 2.2.4. Frequently used values are
timeouts
snd
0x00000000
0x00000001
0x00000011
“snd”
“rcv”
“spf”
“rpf”
y
A
A
rcv
y
y
A
snd pf
y
y
y
rcv pf
y
y
y
If the required send operation cannot start transfer data within the specified
time, ipc is terminated and fails with completion code ‘send timeout’ (0x18).
If ipc does not include a send operation, this parameter is meaningless.
If ipc includes a receive operation and no message transfer starts within the
specified time, ipc is terminated and fails with completion code ‘receive timeout’ (0xA0). If ipc does not include a receive operation, this parameter is meaningless.
If during sending data a pagefault in the receiver’s address space occurs, snd
pf specified by the sender is used as send and receive timeout for the pagefault
RPC.
If during receiving data a pagefault in the sender’s address space occurs, rcv pf
specified by the receiver is used as send and receive timeout for the pagefault
RPC.
Basic Ipc Types
CALL
*snd msg / 0
timeouts
msg.w0
msg.w1
*rcv msg / 0
dest id
msg.w2
EAX
ECX
EDX
EAX
ECX
«
INT 0x30 
EBX
EBP
ESI
EDI
EDX
EBX
EBP
ESI
EDI
msg.dope + e‚e
msg.w0
msg.w1
unchanged
msg.w2
This is the usual blocking RPC. snd msg is sent to dest id and the invoker waits for a reply from dest id.
Messages from other sources are not accepted. Note that since the send/receive transition needs no time, the
destination can reply with snd timeout ' 0.
This operation can also be used for a server with one dedicated client. It sends the reply to the client and
waits for the client’s next order.
SEND / RECEIVE
*snd msg / 0
timeouts
msg.w0
msg.w1
*rcv msg+1 / 0+1
dest id
msg.w2
msg.dope + e‚e
EAX
EAX
ECX
ECX
EDX
EBX
msg.w0
msg.w1
EDX
EBX
«
INT 0x30 
EBP
ESI
EBP
ESI
EDI
EDI
source id
msg.w2
snd msg is sent to dest id and the invoker waits for a reply from any source. This is the standard server
operation: it sends a reply to the actual client and waits for the next order which may come from a different
client.
SEND
*snd msg / 0
timeouts
msg.w0
msg.w1
0xFFFFFFFF
dest id
msg.w2
EAX
EAX
ECX
ECX
EDX
EBX
«
INT 0x30 
EDX
EBX
EBP
ESI
EBP
ESI
EDI
EDI
eBe
snd msg is sent to dest id. There is no receive phase included. The invoker continues working after sending
the message.
RECEIVE FROM
0xFFFFFFFF
timeouts
EAX
ECX
EDX
*rcv msg / 0
dest id
EBX
EBP
ESI
EDI
«
EAX
ECX
INT 0x30 
EDX
EBX
EBP
ESI
EDI
msg.dope + e‚e
msg.w0
msg.w1
unchanged
msg.w2
This operation includes no send phase. The invoker waits for a message from source id. Messages from other
sources are not accepted. Note that also a hardware interrupt might be specified as source.
RECEIVE
0xFFFFFFFF
timeouts
*rcv msg+1 / 0+1
EAX
ECX
EAX
ECX
EDX
EDX
«
INT 0x30 
EBX
EBP
EBX
EBP
ESI
ESI
EDI
EDI
msg.dope + eBe
msg.w0
msg.w1
source id
msg.w2
This operation includes no send phase. The invoker waits for a message from any source (including a hardware interrupt).
RECEIVE INTR
0xFFFFFFFF
timeouts
EAX
ECX
EDX
EAX
ECX
*rcv msg / 0
intr + 1
«
INT 0x30 
EBX
EBP
ESI
EDI
msg.dope + eBe
EDX
EBX
EBP
ESI
EDI
unchanged
This operation includes no send phase. The invoker waits for an interrupt message coming from interrupt
source intr. Note that interrupt messages come only from the interrupt which is currently associated with this
thread.
The intr parameter is only evaluated if rcv timeout ' 0 is specified, see ‘associate intr’.
ASSOCIATE INTR
0xFFFFFFFF
rcv timeout = 0
EAX
EAX
msg.dope + eBe
ECX
EDX
ECX
EDX
EBX
EBP
ESI
EBP
ESI
unchanged
EDI
EDI
«
INT 0x30 
EBX
*rcv msg / 0
intr + 1
The intr parameter is evaluated if rcv timeout ' 0 is specified. If no (currently associated) interrupt is pending,
the current thread is (1) detached from its currently associated interrupt (if any) and (2) associated with the
specified interrupt provided that this one is free, i.e. not associated with another thread. If the association
succeeds, the completion code is receive timeout (0x20) and no interrupt is received.
If an interrupt from the currently associated interrupt was pending, this one is delivered together with
completion code ok (0x00); the interrupt association is not modified. If the requested new interrupt is already
associated to another thread or is not existing, completion code non existing (0x10) is delivered and the
interrupt association is not modified.
Getting rid of an associated interrupt without associating a new one is done by issuing a receive from
nilthread (0) with rcv timeout ' 0.
SLEEP
0xFFFFFFFF
timeouts
EAX
EAX
ECX
EDX
ECX
EDX
EBX
0
0
«
INT 0x30 
EBX
EBP
ESI
EBP
ESI
EDI
EDI
eBe ' ),N
¨
)
This operation includes no send phase. Since ”“• (0) is specified as source, no message can arrive and the ipc
will be terminated with ‘receive timeout’ after the time specified by the rcv-timeout parameter is elapsed.
id nearest
dest id
EAX
EAX
type
ECX
ECX
EDX
EBX
EDX
EBX

INT 0x31 
EBP
EBP
ESI
EDI
ESI
EDI
nearest id
If nil is specified as destination, the system call delivers the uid of the current thread. Otherwise, it deliveres
the nearest partner which would be engaged when sending a message to the specified destination. If the
destination does not belong to the invoker’s clan, this call delivers the chief that is nearest to the invoker on
the path from the invoker to the destination.
Ž If the destination resides outside the invoker’s clan, it delivers the invoker’s own chief.
Ž If the destination is inside a clan or a clan nesting whose chief © is direct member of the invoker’s clan,
©
the call delivers
.
Ž If the destination is a direct member of the invoker’s clan, the call delivers the destination itself.
Ž If the destination is nil, the call delivers the current thread’s id.
Concluding: nchief (dest id ' ˜ nil) delivers exactly that partner to which the kernel would physically send a
message which is targeted to dest id. On the other hand, a message from dest id would physically come from
exactly this partner.
Parameters
Id of the destination.
dest id
type
'Z)©
'
'”O
nearest id
Note that the type values correspond exactly to the completion codes of ipc.
Destination resides in the same clan. dest id is delivered as nearest id.
Destination is in an inner clan. The chief of this clan or clan nesting is delivered
as nearest id.
Destination is outside the invoker’s clan. The invoker’s chief is delivered as
nearest id.
Either the current thread’s id or the id of the nearest partner towards dest id.
fpage unmap
fpage
map mask
EAX
ECX
EDX
EBX
EBP
ESI
EDI
EAX
ECX

INT 0x32 
EDX
EBX
EBP
ESI
EDI
The specified fpage is unmapped in all address spaces into which the invoker mapped it directly or indirectly.
Parameters
fpage
Fpage to be unmapped.
map mask
¬
j '
)
j R
' S
­
'Z)
­
' S
0
^
h
0
Fpage will partially unmapped. Already read/write mapped parts will be set to
read only. Read only mapped parts are not affected.
Fpage will be completely unmapped.
Unmapping happens in all address spaces into which pages of the specified
fpage have been mapped directly or indirectly. The original pages in the own
task remain mapped.
Additionally, also the original pages in the own task are unmapped (flushing).
thread switch
EAX
EAX
ECX
ECX
EDX
EBX
EDX
EBX
dest id

INT 0x33 
EBP
EBP
ESI
EDI
ESI
EDI
The invoking thread releases the processor (non-preemtively) so that another ready thread can be processed.
Parameters
dest id
'””“•
'”˜ ”“•
( '”) ) Processing switches to an undefined ready thread which is selected by the
scheduler. (It might be the invoking thread.) Since this is “ordinary” scheduling, the thread gets a new timeslice.
If dest id is ready, processing switches to this thread. In this “extraordinary”
scheduling, the invoking thread donates its remaining timeslice to the destination thread. (This one gets the donation additionally to its ordinary scheduled
timeslices.)
If the destination thread is not ready, the system call operates as described for
dest id ' ”“• .
thread schedule
param word
ext preempter
EBX
EBX
old param word
time.low
time.high
old preempter
dest id
EBP
ESI
EBP
ESI
partner
EDI
EDI
EAX
EAX
ECX
EDX
ECX
EDX

INT 0x34 
The system call can be used by schedulers to define the priority, timeslice length and external preempter of
other threads. Furthermore, it delivers thread states. Note that due to security reasons thread state information
must be retrieved through the appropriate scheduler.
The system call is only effective, if the current priority of the specified destination is less or equal than
the current task’s maximum controlled priority (mcp).
Parameters
Destination thread id. The destination thread must currently exist and run on
a priority level less than or equal to the current thread’s mcp. Otherwise, the
destination thread is not affected by this system call and all result parameters
except old param word are undefined.
dest id
param word
ext preempter
valid
n® r ® 0
small
prio
M
prio
New priority for destination thread. Must be less than or equal to current
thread’s mcp.
small
(Only effective for Pentium.) Sets the small address space number for the
addressed task. On Pentium, small address spaces from 1 to 127 currently
available. A value of 0 or 255 in this field does not change the current setting
for the task. This field is currently ignored for 486 and PPro.
s°¯(5.±V¯
New timeslice length for the destination thread. The timeslice quantum is encoded like a timeout: O%[²‚³€´µ]s°¯”m
* .
The kernel rounds this value up towards the nearest possible value. Thus the
timeslice granularity can be determined by trying to set the timeslice to 1 m s.
However note that the timeslice granularity may depend on the priority.
Timeslice length 0 (s`¯ ' )5.±„¯ ' ˜ ) ) is always a possible value. It means that the
thread will get no ordinary timeslice, i.e. is blocked. However, even a blocked
thread may execute in a timeslice donated to it by ipc.
“inv”
(0xFFFFFFFF) The current priority and timeslice length of the thread is not
modified.
valid
Defines the external preempter for the destination thread. (Nilthread is a valid
id.)
“inv”
(0xFFFFFFFF, ) The current external preempter of the thread is not changed.
old param word
n ® valid
r ® ¶F£
G·
prio
prio
Old priority of destination thread.
s`¯.5.±„¯
Old timeslice length of the destination thread: O [²‚³€´ µ s`¯Šm
* .
¸
*J'
)0º¹
Oº¹
§
Thread state:
Running. The thread is ready to execute at user-level.
Sending. A user-invoked ipc send operation currently transfers an outgoing
message.
Receiving. A user-invoked ipc receive operation currently receives an imcoming message.
Waiting for receive. A user-invoked ipc receive operation currently waits for an
incoming message.
Pending send. A user-invoked ipc send operation currently waits for the destination (recipient) to become ready to receive.
Reserved.
Dead. The thread is unable to execute.
º¹
C
D
E
F
¹ ' 0
1
2
3
“inv”
Kernel inactive. The kernel does not execute an automatic RPC for the thread.
Pager. The kernel executes a pagefault RPC to the thread’s pager.
Internal preempter. The kernel executes a preemption RPC to the thread’s internal preempter.
External preempter. The kernel executes a preemption RPC to the thread’s
external preempter.
(0xFFFFFFFF) The addressed thread does either not exist or has a priority
which exceeds the current thread’s mcp. All other return parameters are undefined ( ).
old ext preempter
Old external preempter of the destination thread.
partner
Partner of an active user-invoked ipc operation. This parameter is only valid,
if the thread’s user state is sending, receiving, pending or waiting (4. . . D). An
invalid thread id (0xFFFFFFFF, ) is delivered if there is no specific partner,
i.e. if the thread is in an open receive state.
np» time
r » M
r ‡ ¼À Á » Â
¼š½=¾¿.½J
EDX
ECX
Cpu time (48-bit value) in microseconds which has been consumed by the destination thread.
s·Ã!5.±;Ã
Current user-level wakeup of the destination thread, encoded like a timeout.
The value denotes the still remaining timeout interval. Valid only if the user
state is waiting (C) or pending (D).
±‚Ä
Effective pagefault wakeup of the destination thread, encoded like a 4-bit pagefault timeout. The value denotes the still remaining timeout interval. Valid only
if the kernel state is pager ( ¹ ' S ).
lthread ex regs
lthread no
ESP
EIP
int preempter
EAX
ECX
EDX
EBX
pager

EAX
ECX
INT 0x35 
EDX
EBX
EBP
EBP
ESI
EDI
ESI
EDI
old EFLAGS
old ESP
old EIP
old preempter
old pager
This function reads and writes some register values of a thread in the current task.
It also creates threads. Conceptually, creating a task includes creating all of its threads. Except lthread 0,
all these threads run an idle loop. Of course, the kernel does neither allocate control blocks nor time slices
etc. to them. Setting stack and instruction pointer of such a thread to valid values then really generates the
thread.
Note that this operation reads and writes the user-level registers (ESP, EIP and EFLAGS). Ongoing kernel
activities are not affected. However an ipc operation is cancelled or aborted. If the ipc is either waiting to
send a message or waiting to receive a message, i.e. a message transfer is not yet running, ipc is cancelled
(completion code 0x40 or 0x50). If a message transfer is currently running, ipc is aborted (completion code
0xC0 or 0xD0).
Parameters
Å
lthread no
0
lthread
Æ
Number of addressed lthread (0. . . 127) inside the current task.
Ç ' )
Ç ' S
È ' )
È '#S
É!'¤)
ESP
EIP
int preempter
pager
If ESP and EIP are valid, they specify 32-bit protected-mode values. The addressed thread will execute in 32-bit protected mode afterwards.
If ESP and EIP are valid, they specify 16-bit V86-mode values. The addressed
thread will execute in V86 mode afterwards.
The thread’s auto-propagating status is not updated.
The thread’s auto-propagating status is updated by É .
If È '#S , the thread is set to non auto-propagating.
É ' S
If È ' S , the thread is set to auto-propagating.
valid
New stack pointer (ESP) for the thread. It must point into the user-accessible
part of the address space.
“inv”
(0xFFFFFFFF) The existing stack pointer is not modified.
valid
New instruction pointer (EIP) for the thread. It must point into the useraccessible part of the address space.
“inv”
(0xFFFFFFFF) The existing instruction pointer is not modified.
valid
Defines the internal preempter used by the thread. (Nil is a valid id.)
“inv”
(0xFFFFFFFF, ) The existing internal preempter id is not modified.
valid
Defines the pager used by the thread.
“inv”
(0xFFFFFFFF, ) The existing pager id is not modified.
old EFLAGS
Flags of the thread. The VM flag specifies whether the thread currently runs in
32-bit protected mode (VM ') ) or in V86 mode (VM '6S ). Note that this flag
determines the format of the delivered old ESP and EIP.
old ESP
Old stack pointer (ESP) of the thread.
old ESP
Old instruction pointer (EIP) of the thread.
old int preempter
Id of the thread’s old internal preempter (may be nilthread).
old pager
Id of the thread’s old pager.
V86-mode Pointers
ESP, old ESP
SS
SP
EIP, old EIP
CS
Ê
IP
Example
Signalling can be implemented as follows:
signal (lthread) :
esp := receive signal stack ;
eip := receive signal ;
mem [esp – –] := 0 ;
lthread ex regs (lthread, esp, eip, eflags, –, –) ;
mem [esp – –] := eflags ;
mem [esp – –] := eip ;
mem [idle stack – wordlength] := esp .
receive signal :
push all regs ;
while mem [esp + 8 Ë wordlength] = 0 do
thread switch (nilthread)
od ;
pop all regs ;
pop (esp) ;
jmp (signal eip) .
task new
mcp / new chief
initial ESP
initial EIP
pager
dest task
EAX
ECX
EDX
EBX
EBP
ESI
EDI

EAX
ECX
INT 0x36 
EDX
EBX
EBP
ESI
EDI
new task
This function deletes and/or creates a task. Deletion of a task means that the address space of the task and
all threads of the task disappear. The cputime of all deleted threads is added to the cputime of the deleting
thread. If the deleted task was chief of a clan, all tasks of the clan are deleted as well.
Tasks may be created as active or inactive. For an active task, a new address space is created together
with 128 threads. Lthread 0 is started, the other ones wait for a “real” creation by lthread ex regs. An inactive
task is empty. It occupies no resources, has no address space and no threads. Communication with inactive
tasks is not possible. Loosely speaking, inactive tasks are not really existing but represent only the right to
create an active task.
A newly created task gets the creator as its chief, i.e. it is created inside the creator’s clan. Symmetrically,
a task can only be deleted either directly by its chief (its creator) or indirectly by a higher-level chief.
Parameters
Task id of an existing task (active or inactive) whose chief is the current task. If
one of these preconditions is not fulfilled, the system call has no effect. Simultaneously, a new task with the same task number is created. It may be active or
inactive (see next parameter).
dest task
pager
' ˜ nil
' nil
The new task is created as active. The specified pager is associated with lthread
0.
(0) The new task is created as inactive. No lthread is created.
ESP
Initial stack pointer for lthread 0 if the new task is created as an active one.
Ignored otherwise.
EIP
Initial instruction pointer for lthread 0 if the new task is created as an active
one. Ignored otherwise.
mcp
Maximum controlled priority (mcp) defines the highest priority which can be
ruled by the new task acting as a scheduler. The new task’s effective mcp is the
minimum of the creator’s mcp and the specified mcp.
EAX contains this parameter, if the newly generated task is an active task, i.e.
has a pager and at least lthread 0.
new chief
Specifies the chief of the new inactive task. This mechanism permits to transfer
inactive (“empty”) tasks to other tasks. Transferring an inactive task to the
specified chief means to transfer the related right to create a task. Note that the
task number remains unchanged.
EAX contains this parameter, if the newly generated task is an inactive task,
i.e. has no pager and no threads. EAX contains only the lower 32 bits of the
new chief’s task id. (The chief must reside in the same site.)
new task id
'”˜ ”“•
Task creation succeeded. If the new task is active, the new task id will have
a new version number so that it differs from all task ids used earlier. Chief
and task number are the same as in dest task. If the new task is created inactive, the chief is taken from the chief parameter; the task number remains
unchanged. The version is undefined so that the new task id might be identical
with a formerly (but not currently and not in future) valid task id. This is safe
since communication with inactive tasks is impossible.
'””“•
(0) The task creation failed.
2.4
2.4.1
Processor Mirroring
Segments
L4 uses a flat (unsegmented) memory model. There are only two segments available: user space, a read/write
segment, and user space exec, an executable segment. Both cover (at least) the complete user-level address
space.
The values of both segment selectors are undefined. When a thread is created, its segment registers SS,
DS, ES, FS and GS are initialized with user space, CS with user space exec. Whenever the kernel detects a
general protection exception and the segment registers are not loaded properly, it reloads them with the above
mentioned selectors. From the user’s point of view, the segment registers cannot be modified.
However, the binary representation of user space and user space exec may change at any point during
program execution. Never rely on this value.
Furthermore, the LSL (load segment limit) machine instruction may deliver wrong segment limits, even
floating ones. The result of this instruction is always undefined.
2.4.2
Exception Handling
#PF (page fault), #MC (machine check exception) and some #GP (general protection) exceptions are handled
by the kernel. The other exceptions are mirrored to the virtual processor of the thread which raised the
exception.
The mirrored exception handling works as described in the processor manuals.
This machine instruction is emulated by the kernel and operates per thread.
LIDT [EAX]
Any thread should install an IDT by this instruction. The length field of the
IDT vector is not interpreted. The IDT has always a length of 256 bytes, i.e.
covers the Intel-reserved exceptions 0 to 31.
The IDT must have the format described in the processor manuals. However,
only trap gates can be used in a user-level IDT. The segment selectors in the
IDT are ignored, since all segments describe the flat address space.
Invalid IDT addresses or invalid exception-handler addresses do not raise a
double fault; instead, the current thread is shut down.
Note that this mechanism deals only with exceptions, not INT instructions. Executing an INT in 32-bit
mode will always raise a #GP (general protection). The general-protection handler may interpret the error
§
code ( 6¦ , see processor manual) and emulate the INT accordingly.
2.4.3
Debug Registers
User-level debug registers exist per thread. DR0. . . 3, DR6 and DR7 can be accessed by the machine insructions MOV DRx,n and MOV r,DRx. However, only task-local breakpoints can be activated, i.e. bits L0. . . 3
in DR7 cannot be set. Breakpoints operate per thread. Breakpoints are signalled as #DB exception (INT 1).
Note that user-level breakpoints are suspended when kernel breakpoints are set by the kernel debugger.
2.5
The Kernel-Info Page
The kernel-info page contains kernel-version data, memory descriptors and the clock. The remainder of
the page is undefined. (In fact, it contains kernel code.) The kernel-info page is mapped read-only in the
-address space. can use the memory descriptors for its memory management. can map the page
read-only to other address spaces.
ÌÍËÎSVU
L4 version parts
G
bus frequency
G
0xB0
processor frequency
0xA0
clock
dedicated mem4.high
dedicated mem4.low
dedicated mem3.high
dedicated mem3.low
0x90
dedicated mem2.high
dedicated mem2.low
dedicated mem1.high
dedicated mem1.low
0x80
dedicated mem0.high
dedicated mem0.low
reserved mem1.high
reserved mem1.low
0x70
reserved mem0.high
reserved mem0.low
main mem.high
main mem.low
0x60
G
2
+0xC
G
0x50
G
0x40
G
0x30
G
0x20
G
0x10
Ï
“L4 K”
version word
+8
+4
0x00
+0
mem.low
Physical address of first byte of region. Must be page aligned.
mem.high
Physical address of first byte beyond the region. Must be page aligned. If
mem.high ' 0, the region is empty.
main mem
Main memory region.
reserved mem
This region must not be used. It contains kernel code (reserved mem0) or data
(reserved mem1) grabbed by the kernel before was initialized.
dedicated mem
This region contains dedicated memory which cannot be used as standard memory. For example, [640K, 1M] is a popular dedicated memory region.
clock
System clock in m s.
processor frequency
Processor’s external clock rate in MHz.
bus frequency
Processor’s external clock rate in MHz.
2.6
Page-Fault and Preemption RPC
Page Fault RPC
kernel sends:
w0 (EDX)
fault address / 4
w1 (EBX)
j ' )
j '#S
h G
faulting user-level EIP
Read page fault.
Write page fault.
The receive fpage covers the complete user address space. The kernel accepts
mappings or grants into this region as well as a simple 2-word copy message.
The received message is ignored!
kernel receives:
timeouts
used for
pagefault RPC
snd
rcv
snd pf
rcv pf
PF at
user
level
l
l
l
l
PF at ipc in
receiver’s
space
sender’s snd pf
sender’s snd pf
sender’s snd pf
sender’s snd pf
PF at ipc in
sender’s
space
receiver’s rcv pf
receiver’s rcv pf
receiver’s rcv pf
receiver’s rcv pf
Preemption RPC
kernel sends:
kernel receives:
w0 (EDX)
user-level ESP
w1 (EBX)
user-level EIP
M
The kernel accepts only a simple 2-word reply. Its content is ignored!
timeouts
used for
preemption RPC
snd
rcv
snd pf
rcv pf
l
l
l
l
2.7
Ð )
RPC protocol
Ñ is the initial address space. Although it is not part of the kernel, its basic protocol is defined with the
Nucleus. Special Ñ implementations may extend this protocol.
The address space Ñ is idempotent, i.e. all virtual addresses in this address space are identical to the
corresponding physical address. Note that pages requested from *V“ k s`ɚ continue to be mapped idempotent
if the receiver specifies its complete address space as receive fpage.
gives pages to the kernel and to arbitrary tasks, but only once. The idea is that all pagers request the
memory they need in the startup phase of the system so that afterwards has spent all its memory. Further
requests will then automatically denied.
Kernel Communication
Ñ receives from a kernel thread:
w0 (EDX)
FFFFFFFF/4
0 0
G·
w1 (EBX)
For reply, should grant a page (4K) to the kernel thread. The page might be
located at an arbitrary position but must contain ordinary memory. If no more
memory is available, should reply a 0-word instead of a page.
Intended Action:
receives from a kernel thread:
w0 (EDX)
0
1
G`
w1 (EBX)
Intended reply:
.H
0
w0 (EDX)
ÒJ
w1 (EBX)
G ¹ is the number of pages recommended by for kernel use (pagetables and
other kernel-internal data).
General Memory Mapping
receives from a non-kernel thread:
w0 (EDX)
w1 (EBX)
Intended Action:
FFFFFFFF/4
0 0
G·
For reply, should map a page (4K) writable to the requester. The page might
be located at an arbitrary position but must contain ordinary memory. If no
more free page is available, should reply a 0-word instead of a page.
The mapped page must be marked and must not further be mapped or granted
by to another task. However, multiple mapping to the same requester should
be supported.
receives from any thread:
w0 (EDX)
address
Ó
40000000/4
0 0
GÔ
w1 (EBX)
For reply, should map the specified physical page frame (4K) writable to the
requester. If the page is already mapped or is not available, Ñ should reply a
0-word instead of a page.
The mapped page must be marked and must not further be mapped or granted
by to another task. However, multiple mapping to the same requester should
be supported.
Intended Action:
receives from any thread:
w0 (EDX)
40000000/4
ˆ0Õ Ó
C0000000/4
M
0 0
GÔ
w1 (EBX)
For reply, Ñ should map the physical 4M superpage with address É
/Oš)))))))
writable to the requester. If the page is already mapped or is not available, Ñ
should reply a 0-word instead of a page.
The mapped superpage must be marked and must not further be mapped or
granted by to another task. However, multiple mapping to the same requester should be supported.
Intended Action:
receives from any thread:
w0 (EDX)
w1 (EBX)
Intended Action:
0
G·
.H
1
1
For reply, should map read only the kernel info page to the requester.
This page can be mapped multiply.
2.8
Starting L4
For booting L4, see appendix A.
After booting, L4 enters protected mode if started in real mode, enables paging and initializes itself. It
generates the basic address space-servers and a task root server which is intended to boot the higher-level
system.
and the root server are user-level tasks and not part of the pure Nucleus. The predefined ones can be
replaced by modifying the following table in the L4 image before starting L4. The kernel debugger kdebug
is also not part of the Nucleus and can accordingly be replaced by modifying the table.
dedicated mem4.high
dedicated mem4.low
dedicated mem3.high
dedicated mem3.low
0x1090
dedicated mem2.high
dedicated mem2.low
dedicated mem1.high
dedicated mem1.low
0x1080
kdebug permissions
kdebug configuration
root server end+1
root server begin
G
0x1070
G
0x1060
G
root server start EIP
L4 configuration
0x1050
root server start ESP
0x1040
Ö end+1
Ö begin
Ö start EIP
Ö start ESP
0x1030
Ö end+1
Ö begin
Ö start EIP
Ö start ESP
0x1020
kdebug end+1
kdebug begin
+0xC
kdebug exception
+8
0x1010
kdebug init
+4
+0
0x1010 . . . are offsets relative to the load address. The EIP and ESP values however, are absolute 32-bit addresses. The appropriate code must be loaded at these addresses before L4 is started. Note that the predefined
root server currently executes only a brief kernel test.
mem.low
Physical address of first byte of region. Must be page aligned.
mem.high
Physical address of first byte beyond the region. Must be page aligned. If
mem.high ' 0, the region is empty.
dedicated mem
This region contains dedicated memory which cannot be used as standard memory. For example, [640K, 1M] is a popular dedicated memory region.
begin
Physical address of the first byte of a server’s code+data area.
end
Physical address of the last byte of a server’s code+data area.
start EIP
Physical address of a server’s initial instruction pointer (start).
start ESP
Physical address of a server’s initial stack pointer (stack bottom).
kdebug init
Physical address of kdebug’s initialization routine.
kdebug exception
Physical address of kdebug’s debug-exception handler.
L4 configuration
G·Ê
ptabs
pnodes
kdebug configuration
* ' S
port
rate
'6S
'×
'¤7
' U
' S„
kdebug permissions
¹J'¤)
¹Ù0)
s ' S
¡ ' S
' S
j ' S
“ ' S
W ' S
ptabs
number of ptabs (4K each) per 4M of physical memory which the Nucleus
should allocate for page tables. 0 indicates to use the default value. A value
of 128, for example, specifies that 1/8 of memory should be reserved for page
tables.
number of pnode entries (16 bytes each) the Nucleus should allocate per physical frame. A value of 0 indicates to use the default value.
port
pages
pnodes
H
rate
G`Æ
F
pages
The number of 4K pages that kdebug should allocate for its trace buffer. A
value of 0 indicates no trace buffer.
The Nucleus enters kdebug before starting the root server.
Initially, kdebug should use the serial line base IO address port for output and
input. A port address of 0 indicates to use the integrated console (keyboard and
display) instead of a serial line.
determines the default baud rate for kdebug when using a serial line. If
¸
W — ¡ '¤
˜ ) , this is also the initial baud rate. Possible values:
115.2 Kbd
57.6 Kbd
38.4 Kbd
19.2 Kbd
9.6 Kbd
G·
Y  h Ÿ ž n
ÒØ
Any task can use kdebug from user-level.
Only tasks 1 to ¹ can use kdebug from user-level. Threads of other tasks will
be shut down when invoking kdebug.
Kdebug may display mapping.
Kdebug may display user registers.
Kdebug may display user memory.
Kdebug may modify memory, register, mappings and tcbs.
Kdebug may read from and write to IO ports.
Kdebug may protocol page faults and IPC.
Appendix A
Booting
PC-compatible Machines
L4 can be loaded at any 16-byte-aligned location beyond 0x1000 in physical memory. It can be started in real
mode or in 32-bit protected mode at address 0x100 or 0x1000 relative to its load address. The protected-mode
conditions are compliant to the Multiboot Standard Version 0.6.
load base ( Ï )
load offset (Û )
Interrupts
Gate A20
EFLAGS
CR0
(E)IP
CS
SS,DS,ES
EAX
EBX
‘ ÞXÜ&AB’
‘ ÞXÜ[email protected]‚’
‘ ÞXÜ&ßB’
all remaining registers & flags
(general, floating point,
ESP, xDT, TR, CRx, DRx)
ÏpÚ
Û
Start Preconditions
Real Mode
0x1000, 16-byte aligned
z 0x100 or Û z 0x1000
disabled
G
Iz 0
PE z 0
Û
π?V‰]D
G
G
G
n/a
G
Û
32-bit Protected Mode
ÏpÚ 0x1000
z 0x100 or Û z 0x1000
disabled
open
I z 0, VM z 0
PE z 1, PG z 0
ύÜ&Û
0, 4GB, 32-bit exec
0, 4GB, read/write
0x2BADB002
G
Ý=Þ
OR 1
below 640 K mem in K
beyond 1M mem in K
G
L4 relocates itself to 0x1000, enters protected mode if started in real mode, enables paging and initializes
itself.
39
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement