Commit Graph

15 Commits

Author SHA1 Message Date
Alexander Boettcher
95329c82e2 sel4: update to 5.2.0
Issue #2451
2017-08-17 11:04:19 +02:00
Norman Feske
0167d5af50 Integrate core's RAM service into the PD service
Fixes #2407
2017-05-31 13:16:14 +02:00
Norman Feske
bc82cce72b core: add Platform::max_caps()
This method returns the kernel-specific system-global limit of the total
number of capabilities.

Issue #2398
2017-05-31 13:16:03 +02:00
Norman Feske
29b8d609c9 Adjust file headers to refer to the AGPLv3 2017-02-28 12:59:29 +01:00
Stefan Kalkowski
2a2e5c2df4 base-*: remove usage of printf
base generic code:
  * Remove unused verbosity code from mmio framework
  * Remove escape sequence end heuristic from LOG
  * replace Core_console with Core_log (no format specifiers)
  * move test/printf to test/log
  * remove `printf()` tests from the log test
  * check for exact match of the log test output
base-fiasco:
  * remove unused Fiasco::print_l4_threadid function
base-nova:
  * remove unused hexdump utility from core
base-hw:
  * remove unused Kernel::Thread::_print_* debug utilities
  * always print resource summary of core during startup
  * remove Kernel::Ipc_node::pd_label (not used anymore)
base*:
  * Turn `printf`,`PWRN`, etc. calls into their log equivalents

Ref #1987
Fix #2119
2016-10-21 12:39:36 +02:00
Alexander Boettcher
3a9c6eab17 sel4: use first free cap index reported by kernel
required to bootstrap scenarios with more rom binaries, e.g. noux

Issue #2044
2016-08-10 11:07:53 +02:00
Alexander Boettcher
5b9a61fcb9 sel4: properly detach core local regions
Issue #2044
2016-08-10 11:07:52 +02:00
Norman Feske
9e6f3be806 sel4: update to version 2.1
This patch updates seL4 from the experimental branch of one year ago to
the master branch of version 2.1. The transition has the following
implications.

In contrast to the experimental branch, the master branch has no way to
manually define the allocation of kernel objects within untyped memory
ranges. Instead, the kernel maintains a built-in allocation policy. This
policy rules out the deallocation of once-used parts of untyped memory.
The only way to reuse memory is to revoke the entire untyped memory
range. Consequently, we cannot share a large untyped memory range for
kernel objects of different protection domains. In order to reuse memory
at a reasonably fine granularity, we need to split the initial untyped
memory ranges into small chunks that can be individually revoked. Those
chunks are called "untyped pages". An untyped page is a 4 KiB untyped
memory region.

The bootstrapping of core has to employ a two-stage allocation approach
now. For creating the initial kernel objects for core, which remain
static during the entire lifetime of the system, kernel objects are
created directly out of the initial untyped memory regions as reported
by the kernel. The so-called "initial untyped pool" keeps track of the
consumption of those untyped memory ranges by mimicking the kernel's
internal allocation policy. Kernel objects created this way can be of
any size. For example the phys CNode, which is used to store page-frame
capabilities is 16 MiB in size. Also, core's CSpace uses a relatively
large CNode.

After the initial setup phase, all remaining untyped memory is turned
into untyped pages. From this point on, new created kernel objects
cannot exceed 4 KiB in size because one kernel object cannot span
multiple untyped memory regions. The capability selectors for untyped
pages are organized similarly to those of page-frame capabilities. There
is a new 2nd-level CNode (UNTYPED_CORE_CNODE) that is dimensioned
according to the maximum amount of physical memory (1M entries, each
entry representing 4 KiB). The CNode is organized such that an index
into the CNode directly corresponds to the physical frame number of the
underlying memory. This way, we can easily determine a untyped page
selector for any physical addresses, i.e., for revoking the kernel
objects allocated at a specific physical page. The downside is the need
for another 16 MiB chunk of meta data. Also, we need to keep in mind
that this approach won't scale to 64-bit systems. We will eventually
need to replace the PHYS_CORE_CNODE and UNTYPED_CORE_CNODE by CNode
hierarchies to model a sparsely populated CNode.

The size constrain of kernel objects has the immediate implication that
the VM CSpaces of protection domains must be organized via several
levels of CNodes. I.e., as the top-level CNode of core has a size of
2^12, the remaining 20 PD-specific CSpace address bits are organized as
a 2nd-level 2^4 padding CNode, a 3rd-level 2^8 CNode, and several
4th-level 2^8 leaf CNodes. The latter contain the actual selectors for
the page tables and page-table entries of the respective PD.

As another slight difference from the experimental branch, the master
branch requires the explicit assignment of page directories to an ASID
pool.

Besides the adjustment to the new seL4 version, the patch introduces a
dedicated type for capability selectors. Previously, we just used to
represent them as unsigned integer values, which became increasingly
confusing. The new type 'Cap_sel' is a PD-local capability selector. The
type 'Cnode_index' is an index into a CNode (which is not generally not
the entire CSpace of the PD).

Fixes #1887
2016-02-26 11:36:55 +01:00
Stefan Kalkowski
ccb968ff7d safeguard the synchronized allocator template
* Move the Synced_interface from os -> base
* Align the naming of "synchronized" helpers to "Synced_*"
* Move Synced_range_allocator to core's private headers
* Remove the raw() and lock() members from Synced_allocator and
  Synced_range_allocator, and re-use the Synced_interface for them
* Make core's Mapped_mem_allocator a friend class of Synced_range_allocator
  to enable the needed "unsafe" access of its physical and virtual allocators

Fix #1697
2015-09-30 12:20:39 +02:00
Norman Feske
f19f454ae5 sel4: move core to a libaray, add boot_modules.s 2015-05-26 09:39:59 +02:00
Norman Feske
6ffba0e473 sel4: IPC implementation 2015-05-26 09:39:59 +02:00
Norman Feske
ff46d02c48 sel4: capability lifetime management 2015-05-26 09:39:59 +02:00
Norman Feske
f24b212e47 sel4: core-local thread creation 2015-05-26 09:39:58 +02:00
Norman Feske
e6ad346e24 sel4: management of core's virtual memory 2015-05-26 09:39:57 +02:00
Norman Feske
633f335171 sel4: core skeleton 2015-05-26 09:39:57 +02:00