© 2001 Universität Karlsruhe, System Architecture Group L4 Version 4 (X.2) (Jochen Liedtke) Uwe Dannowski Espen Skoglund Volkmar Uhlig

© 2001 Universität Karlsruhe, System Architecture

Group

L4 Version 4 (X.2)

(Jochen Liedtke)Uwe DannowskiEspen SkoglundVolkmar Uhlig

© 2001 Universität Karlsruhe, System Architecture Group

About presentation

Audience should be familiar with L4Version 2 and/or Version X.0

Presentation will focus on: Task/thread creation deletion, and Communication

In depth discussions afterwards


Major changes from Version 2

No Clans and Chiefs Use “redirection”

instead Redesigned IPC API

Two phases(build and send)

Optimized for IDL compilers

Support for absolute timeouts

Architecture independent API 64-bit/32-bit clean Use virtual

registers to expand register set

(E.g., for IPC messages)

Portable(Recompilation

needed)


Thread IDs Word sized

32 or 64 bit depending on architecture

Task number not encapsulated in ID

No restrictions on number of threads in a task (address space)

Threads can be migrated between tasks (address spaces)

Version numbers not assigned by kernel

Handled through privileged ThreadControl() syscall

Each thread has a global and a local ID

Local ID is only valid inside an address space

(Typically location of UTCB)

Global IDs are unique across all spaces


Privileged threads and system calls

Privileged threads are able to perform certain privileged (“unsafe”) syscalls

(e.g., MemoryControl(), ProcessorControl())

Only threads within privileged (tasks) address spaces are themselves privileged

Only tasks started initially by the kernel are privileged

(Sigma0 and Root Task)


Group

Version 4:

Task and Thread Creation/Deletion

Espen Skoglund


Task creation

Two syscalls involved SpaceControl() ThreadControl()

Both syscalls are privileged Only root task can

create/delete tasks

Three steps required Create empty

space Configure newly

created space Start initial thread


The SpaceControl() system call

ThreadId Space SpecifierFpage Kernel Interface Page AreaFpage Utcb AreaThreadId RedirectorWord Control

Word Result

Address spaces have no IDs

A thread ID specifies the space in which the thread resides

The interface page is mapped by the kernel

Argument specifies the virtual memory area of interface page

A nil-page deletes the specified space

(If space only contains one thread)




Word Result

UTCBs are mapped by kernel

Argument specifies virtual memory area of the UTCBs

Specifies the “redirector” who controls IPC operations in the address space

Redirectors currently have undefined semantics




Word Result

Controls address space specific settings

Small spaces ASID allocation

Not in Schedule() to allow for global allocation schemes

Indicates whether operation was successful or not


The ThreadControl() system call

ThreadId DestinationThreadId Space SpecifierThreadId SchedulerThreadId Pager

Word Result

Identifies addressed thread May have different version

number than existing thread(Will change version number)

Non-existent threads will be created

Specfies space in which to create thread

A specifier equal to Destination creates a new empty address space

A nil-thread specifier deletes the addressed thread


The ThreadControl() system call

ThreadId DestinationThreadId Space SpecifierThreadId SchedulerThreadId Pager

Word Result

Species scheduler for addressed thread

Indicates whether operation was successful or not

Species pager for addressed thread

Upon thread creation: Nil ID creates inactive

thread Non-nil ID creates active

thread


Task creation - walkthrough

P AThreadControl (A, A, nil, nil)

A

Thread created inactive

Empty address space created(i.e., without Kernel Interface

Page and UTCB area)

Privileged thread


A


P ASpaceControl (A, ~, ~, ~)

A

Thread is still inactive

Address space now contains

Kernel Interface Pageand UTCB area



P AAThreadControl (A, A, SA, PA)

A

Thread is now active

How does A know whereto start executing?


Thread startup protocol

Actively created threads start receiving a startup message from their pager

Pager sends IP and SPto thread

Kernel sets IP andSP according tostartup message

The initial thread starts executing

SPSP

IPIP

~~ 00 00 22

MR2

MR1

MR0

Startup message receivedfrom pager



P AA

Recv (PA, ~, ~)

PA

Send (A, ip, sp)


Task deletion

Delete all but one thread from address space

ThreadControl (t, nil, ...) Delete address space

using remaining thread SpaceControl (t, nil, ...)

Safe since only privileged threads can create new threads inside address space

Address space need not be completely deleted

Leave remaining thread as inactive

Flush complete address space

Allows for cheap task creation

(only one ThreadControl() call to active initial thread)


The ExchangeRegisters() system call

ThreadId DestinationWord ControlWord SPWord IPWord FLAGSThreadId PagerWord User Defined Handle

Addressed thread Must be located in same

address space May use global or local ID

Specifies what to do Halt/resume thread? Abort send and/or receive IPC

operations? Set any of the SP, IP, FLAGS,

Pager, or User Defined Handle values of addressed thread?

ThreadId ResultWord ControlWord SPWord IPWord FLAGSThreadId PagerWord User Defined Handle




Specifes new SP, IP, FLAGS, and Pager of addressed thread

Ignored if the respective flag in Control is not set

Specifies new User Defined Handle

Value ignored by kernel Can be used by, e.g.,

user- level thread packages





Addressed thread’s global or local ID

Depending on whether Destination was global or local

Old values of SP, IP, etc.


Current state of addressed thread

Halted or not? Within IPC send or receive

phase?


Thread creation - two alternatives

Create new threads using ThreadControl() Alternative A:

Generate a pool of new threads Each thread is halted upon startup

(using ExchangeRegisters())

Threads can be “created” locally from the pool(using ExchangeRegisters() to resume them)

Alternative B: No pool is generated Each thread creation must happen externally


Group

Version 4:

CommunicationEspen Skoglund


Version 4 IPC mechanism

IPC operations happen in two steps:

Message construction Specify message contents (64 words)

Message sending Invoke IPC system call


Message construction

Messages are stored in registers (MR0 MR63)

Message registers are backed by real registers or memory

First register (MR0) acts as message tag

Subsequent registers contain:

Untyped words (u), and Typed words (t)

(e.g., map item, string item)

labellabel flagsflags tt uuMR0

Message Tag

Various IPC flags

Number of typed words

Number of untyped words

Freely available (e.g., request

type)



Messages are stored in registers (MR0 MR63)

Message registers are backed by real registers or memory

First register (MR0) acts as message tag

Subsequent registers contain:

Untyped words (u), and Typed words (t)

(e.g., map item, string item)

labellabel flagsflags tt uuMR0

Message

MR8

MR7

MR6

MR5

MR4

5

MR2

MR3

MR1

3



Typed items occupy one or more words

Three currently defined items:

Map item (2 words) Grant item (2 words) String item (2+ words)

Typed items can have arbitrary order labellabel flagsflags tt uuMR0

Message

MR2

MR3

MR1

3

MR8

MR7

MR6

MR5

MR4

5

Map Item

String Item


Map and Grant items

Two words: Send base

Similar to Version 2 Fpage

Similar to Version 2 Contains more access

bits

Lower bits of send base indicates map or grant item

send basesend base

send fpagesend fpage

00 100C100C

Map Item

send basesend base

send fpagesend fpage

00 101C101C

Grant Item

locationlocation sizesize 0wrx0wrx

Fpage

MRi

MRi+1

MRi

MRi+1


String items

No alignment required

Max size 4MB (per string)

Compound strings supported Allows scatter-gather

Incorporates cacheability hints Reduce cache pollution

for long copy operations

string lengthstring length

string pointerstring pointer

String Item

00 00 0hhC0hhC MRi

MRi+1

“hh” indicates cacheability hints for the

string


String items



String Item

00 00 0hhC0hhC MRi

MRi+1

1



00 00 0hhC0hhC MRi+j+1

MRi+j+2


k - 1

MRi+j+3string pointerstring pointer

MRi+j+k

“hh” indicates cacheability hints for the

string

j - 1


j - 1

MRi+2string pointerstring pointer

MRi+j

k - 1

1All substrings are of

same size

Different size compound strings

require a new string specifier

New string specifiermay of course contain

substrings


Message sending

The Ipc() syscall will transfer message registers from sender to receiver

Strings will be copied to receiver(if receiver has specified sufficiently large receive buffers)

Mappings will be mapped/granted(if receiver has specified an appropriate receive window)

No page-faults will occur if no strings are copied No page-faults on accessing message

registers “Short IPCs” are thus up to 64 words


The Ipc() system call

ThreadId ToThreadId From SpecifierWord Timeouts

ThreadId From

Receiver of message Nil if no send-phase included

Specifies who to receive from:

Nil indicates no receive-phase

Anythread indicates an open receive

Anylocalthread indicates an open receive from a local thread

Any other thread ID

Different To and From specifiers allows for, e.g, a combined send reply

and wait for other thread!


The Ipc() system call

ThreadId ToThreadId From SpecifierWord Timeouts

ThreadId From

Specifies Send and Receive timeouts

Timeout before IPC operation initiates

Transfer timeout specified in a separate virtual register

Combined timeout of all page faults during IPC string copy

Indicates sender of message

(only for IPCs with receive phase)

Result of IPC is stored in MR0

Received untyped words and typed items are stored in remaining MRs


The Lipc() system call (local IPC)

Identical semantics as normal Ipc()

Lipc() has some restrictions

Sender and receiver are in same address space

Sender and receiver runs on same processor

Includes both send and receive phase

Receive timeout is (infinite)

IPC includes no map/grant operation

Lipc() can fallback to normal Ipc()

If restrictions are not met

Enables fast local IPC implementation, useful for, e.g.:

Distributing requests Intra-address-space

synchronization Lipc() not necessarily

needed for all architectures


Receiving messages

Receiver buffers are specified in registers (BR0 … BR33)

Backed by real registers or memory

First BR (BR0) contains “Acceptor”

May specify receive window (if not nil-fpage)

May indicate presence of receive strings/buffers(if s-bit set)

Acceptor

receive windowreceive window 000s000s BR0


Receiving messages

Acceptor

receive windowreceive window 000s000s BR0



00 00 0hhC0hhC BR1

BR2

0001

The s-bit set indicates presence of string items acting as receive buffers



00 00 0hhC0hhC BR3

BR4

0hh1

If C-bit in string item is set, it

indicates presence of morereceive buffers


j - 1

BR5string pointerstring pointer

BR4+j

A receive buffer can of course

be a compound string

If C-bit in string item is cleared,

it indicates that no morereceive buffers are present

0hh0


The Unmap() system call

Word Control Void

Specifies unmap or flush, and How many fpages to unmap

Fpages are listed in MRs Each fpage indicate

permissions to remove

Each fpage (MR) will on return contain page access bits

Written Referenced eXecuted

Page access bits are reset upon unmap

A no revocation unmap will just reset and return previous access bits

Documents

© 2001 Universität Karlsruhe, System Architecture Group L4 Version 4 (X.2) (Jochen Liedtke) Uwe Dannowski Espen Skoglund Volkmar Uhlig