version: 20.02

Fixes #3668

VERSION

@@ -1 +1 @@
-19.08
+20.02

depot/cnuke/pubkey

@@ -12,19 +12,19 @@ sCaRvwPZdRCDDdhObkgkMlYROVNdC7ju8jZmB4n5O/5N7Ll7/RVhUWD7KeJu1UTM
 oNEmhxEMrEcYcHFt8N8YVtJleRMVnsrZBNxOkFnpsPZr02XIQKfYi5tqSaBQZ47h
 TTtXP3+FEaU+EoJprWqH55Sh97Fg6vuBJEmcGJeMGudFrypTzwqnM22DHwARAQAB
 tCdKb3NlZiBTw7ZudGdlbiA8Y251a2VAZGVwb3QuZ2Vub2RlLm9yZz6JAlQEEwEI
-AD4WIQSFq6G0496kOfRE2qnpSz5BlOa1+AUCWpAOsgIbAwUJA8JnAAULCQgHAgYV
-CAkKCwIEFgIDAQIeAQIXgAAKCRDpSz5BlOa1+NGTEACg69FezAbc9Rzeb7j66NwW
-3x/Zpi/jbmezMEtCZqAOcR8HJ7C0DN8gmCWPPB6oxAEeyL/i2cUb+9F0fTD6N7OL
-TSOH75mNlyB9b8D2HdDILnLy4ClEitEOHFLMnlP58PGVtUNgbmsiM6cLLQtlJKvg
-1xHlBTG9Ic8qgBcd808lLSC1XWN+nufVYBTE2RHNZqGeIWqPG5z1eW/JJO4M3V3j
-MAw1p5Rpf9G6iWNxURutQOl/ii+97IKmHXX7N6ZRzawMGkOCAGNk1xeI71wCrALv
-i3m7NmXb6XIJjD88hO5xfjjRO/0Gcw3vdmTXcVNzM1TvWj8ZsU6XjnMvNxa4LHqh
-MxWuHlX0cAeCOzo1LJZ54f13hJ3YlTCrv68UIoNGRVi1LEbpE0sU0Ycdbw7ur2Gt
-8Brx5WXv3hXTL8s3fmJzYU3/cFDfXjnaRiMWcNYdvckdHy6R7zPTk1NOvmfkolnO
-W73ivdbonXpn0YqRGo2L76GdahLaVYn2gEeisqHnyeBCvI2snI+dMlEK0YNFrEkP
-wgtWnF131Oorn0HMS6mpjcq4su4s5d84KCMGevFnW69oBRG27Bk/fJQiv2dSqkZg
-+3TnyNApg1G7Bp5uD83mOvJWKdTWAntCJSQGbg1dmEsOBG+Bu7EE5LVBoMH3h/LQ
-GB7c5NpgNIFQ2DZy2vkOI7kCDQRakA6yARAAws48PKN3BQPEM0M4kTO57/OqwGrA
+AD4CGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AWIQSFq6G0496kOfRE2qnpSz5B
+lOa1+AUCXk6dFAUJB4D1YgAKCRDpSz5BlOa1+JHXEACyB6vfzfuyo8fu1IaGrloC
+qUUuSfhdleF1tPhZQn9W92bEEoXPfqFUuiNaxeFIXonyiD7wJYdcowdIb6CiNWrx
+B8yjDQ7yb08sDLlL821I93kByy24Er5hY3QEMuEL3qv8YD/6Bh36Q0aoTXqQXMuQ
+3AcHp0JI932Oez3q+gEdW7CUe40N9LaTx0A7ZTHe0i8IELkUPFtDg8xibOjZhBMR
+vlxNUtzQVvC5kT5Wt0w6ZFKPGJguFylaE+TcsTNtiLNS4Z8PmRPgygrWotmprELo
+2/py/VMxgQb7p4LFj+sNmU9x3ulFO3Efb9cVZVjBMYx5xh83ZiLZ3PvK43Eo+7nm
+kYQhPinAjNmqng4/ZdQFrayFMkZc4oKCqV6BaYnybbsSn2ZEwVQqpDMeswWXTf9k
+qC6DONz3ETtyzBEF8cHDpy+BwHRXx+pysGLhIvHS9C3M91j8oXvogZRbw/dEKGX2
+eWes7nsdHeTbyRJunCCnsXDm0Js8cZcqj3Eu3Kpeu2CbgJGD+ajOel2RSMo2mFtg
+OoRWjCibWHDSeUS+LGtspDpry+4VYwm4KBdcyEgiXnE8WDb/xk/hZgJCr2814AJC
+RPpXoIZdFiwSP46vgoAnHynPbGTmE/Wt+F9Y2cn/dz6rmg5ynS8AKuTOUSoAKEUV
+J20mBJpkSx7Cc95AGE8K/LkCDQRakA6yARAAws48PKN3BQPEM0M4kTO57/OqwGrA
 AMlxnB3n+AP7rtZEC2L548+3pfg7Ub45Oq1X0ySxgPhV15CDUEK69pgs0JhphMbM
 DyaUp04DyQWFhdueAqQVFnKvg6nZm/WIJF1VYEc0/q6Ramsdv2cWdxFBkFHYsH3P
 G2bXCZZAEO6eJI8cdmBH6+bVptky/AybzBLztp1ruWlj+rm79qULmW7zJfxYwL1U
@@ -35,18 +35,18 @@ kAVN0Y0H9EGSEoVyKwS1DErzcBgajPKWedKlmjU1uIzupRWn5oqetVbNfZ3Z/EJ/
 HdMCX0PN1kxg4WoI9mkP/moly1yopVOTTLJwvC2C85NQUmxyZeb4h9O7toFczBxn
 7pV9Eprm/xRcO3ZEEpmdM7gR3+R3PpxkjgPIZAn9il32VYzdT3eQmDZ8sKC0qASG
 ik2if34YnAggGmsrVB0nzT9fZR7CQq2IR7eohczLJRl+n7USQMgRweF+sl9PcbDT
-aC0b0i+VveSEBOEAEQEAAYkCPAQYAQgAJhYhBIWrobTj3qQ59ETaqelLPkGU5rX4
-BQJakA6yAhsMBQkDwmcAAAoJEOlLPkGU5rX4QjEQAIJF78XjvGomhafMsWlcd7fP
-/j45B+KIpyruc7wHtLqWibi+YoDuvtG4m1/4Ckcz5qNrV0f5nQojEAeCSCh7Sl+s
-yAJ9tmP1XET29DJq1t0iMsu+RDCLhdOfL/Wi/YJARtDloYbDlD8Rc/JnL2aOx2W/
-Ybajj2lloxSDxKCnzCh1aZixie1YaQSm8ErshT2k4qTx48D3mRoBLAYyzdEbLkl3
-ZBGDQy3Xk/miJ/hsj6L3w3G2YjMywZZZEjgDSUgSJ6MazBTgMmbCy1/0YGh7rNF7
-iUoWyDZq4qiDGNAI695I6tas7s4X2dhZn10xgbJoa5Dq2rqQLek+ErEsr3DFYN53
-7e9H0vJ9ydXB7piRJ9bxVFBng5CX9677IN5k9T/0lvcZWAFnDcHiMkIjIrTQ1Y04
-WkG6DMVvzLD+PKA07cZLf692rsrbfpP4sGj8X6baWh58mGAMMwZ2Dy07grsi73qI
-p/H4r4c/xRsH6nTbvb40zLfqcCz1xOTEcDtflYGMoeshu/H2EoruNMFi3c/9WO2G
-3zrSOUenWFSiacbsh8HVE9HUFGddBTB3SrLddO5vvvi15OvGI4aWpnkW+9s4107h
-jE0d0+c/Xm4AS0T59OGj/cd45k/vRe5vaPhQobZ6hXBzkKWPVt5uH8xbROiGiqdR
-jMuaeWIldeJ60aeu39Dh
-=JE0L
+aC0b0i+VveSEBOEAEQEAAYkCPAQYAQgAJgIbDBYhBIWrobTj3qQ59ETaqelLPkGU
+5rX4BQJeTp05BQkHgPWHAAoJEOlLPkGU5rX4RRAQAKSsr//mEXy6iQyoqaxJ796s
+ljaoqsmT4ly/+0k9diX1+/wkulSkj4/fL2fDvRQK2cU1i6mYJVugN5swqXvp8WF8
+scnDS/H75v/3Z+clTlsMjZ4qI0PmXYDpcvp5+zU85USEjOxpHmIKvQGflZ0NMvkI
+uo2ZC6F4xnB5iizx9Ebm0gGAiKKEJ8ID/LLhJmOtidnGc3322SUVXIl4+ue9KgpO
+hTBjx5UdIQ+21uSRf+zv3ZQH/KA/08iNyD20fIiUZKfEoeovlW8SipoO/pf/+1DE
+WSiJqL3K7T3ixkC4oWSp7tbo2MWU247PItxTnnGF+KjwbkzpPwyPYPHT5Ed3XEZV
+e39r9xUzdvYKKDCNDToDFsh4bm4hq7xXgnTwAbF6hw0iyBK02ZB6FKJsF/ZJi8gC
+Ni4d3Lb54CV/Z7nAqMFbTa6KT8o9fc0Bw6tgX2ch7SRWU70yVGYmQzrdRsOtDkIV
+iYA05JozwwsIcJQS7hBVnsqgD/huYLd+y7iCUgw35NdQ5764jzVlUpYtFO0NFrM6
+QSKnnFFRiwr3+ZqIja2SGW455uP1hsl2ccA4Rdp/JRuEI6ojIo0R+JBpcMeqdv9d
+HcNsAoZkrm/cQfIwlyKsU4/dEFL09kEtv7x/aO2ImqjAZ5xT3ml+4kFGEn7M7rsc
+M6R6fgkYrVo1GhjXTlCL
+=4bj4
 -----END PGP PUBLIC KEY BLOCK-----

depot/skalk/pubkey

@@ -6,26 +6,26 @@ spm0DdNCEVfUbIQUstbSNt1kDGIlqPvZmoRj5YwDECW6ULG8jTWhaAz9SybJCE86
 jLPzZHjKtVhCVO1X0ogSxvvYGemUpqVCLfKcIb1TucieKKCrnjiHwp0XZ41DWqSb
 kBwWW2YQMEsw8JNGNTfCCUFf6+1l4mMixtv2sEqFiH1wQJ0c4gSa4iSYZ+eNmzJ0
 B13K8kONOctSg3NYZz/dC1aUzLOTkgJHqEPHABEBAAG0KVN0ZWZhbiBLYWxrb3dz
-a2kgPHNrYWxrQGRlcG90Lmdlbm9kZS5vcmc+iQFUBBMBCAA+FiEEI2X1/oP+p+Ls
-2L28qrC4CLnp/P8FAlrQZGACGwMFCQPCZwAFCwkIBwIGFQgJCgsCBBYCAwECHgEC
-F4AACgkQqrC4CLnp/P9kKQgAxc11eDhYkMVg9cuipFoqtV5lY9aT2qkocZ28IhbF
-LXhy9lcn5FlxZSVdkzJQ5tUf4nSuhhMb6z3r8edaOebcYAyFk0DTymNpcEyT2XHd
-lsOcInhfU423m1tCNHdmxtv9HERtj2zS1KNkjWxY6xsqfEw1eDfUvdS3K9KpUqc6
-vWZwsPd9EHxW3mzWJS3lrSAnNsCwtdmiqB9045Yss4KednMcN6qxE+uHppQ+25Ib
-5ZICpiVqOJ+eQXeY3kRx84lfZJr3uFdn00RSU5fn0uol8ZZYX9tQd9SC1GIlkyYj
-HxNLKNVaYzF1nnmR1s7cpY6PUAYbt0im6kd4VJ1wQcWTnrkBDQRaU+QuAQgAuame
+a2kgPHNrYWxrQGRlcG90Lmdlbm9kZS5vcmc+iQFUBBMBCAA+AhsDBQsJCAcCBhUI
+CQoLAgQWAgMBAh4BAheAFiEEI2X1/oP+p+Ls2L28qrC4CLnp/P8FAl4XHPUFCQ0p
+OkcACgkQqrC4CLnp/P8bAgf/ToUKzXMGdRXpB+xIBbOxuu8xVdLRj+5cm7cjZRiy
+N0ulrzAlaZqrfqb5rTujPDjakmVSBVRIi8zWlzU7y67fevTFdi/Q9xeLgbqP3cWU
+UgUJs03cdacFIamSIO//I9gaImZ2kpUcA6Nj+N+jPepRgUBzljsJG8678ndicA0e
+Yio4uAvZY9JmsWGn48rmkqshPf9lag4GUnXn+R/AFKCts55kOiPekux3pJBhmrLJ
+TdLgdAzlzGQfHxQbz3oVK4yE19ReAd6rnpW06oK4KfiWrgCmaEk1quirDNfIMDfr
+nwe6571TY5is0f9zJjJgP8ogLUMI3n54OvwMezUMz+bLbbkBDQRaU+QuAQgAuame
 2VDCgNmiwu+QmWyNN4jzbE7+VNmDr37HO9lZRIROC4eACPOGfUL03jLGvUn7rrxQ
 JK+Pit6gXXCoIWDhCMNRSZKho416KJZWxF2jxKBKGQ7DtWaTR3YOzSf0ka9DZSrp
 wG22xS0Uf1U/0ZBIf24LbyUDFLc8zt4eey2D9AHm+9vCf7wnf8TV6SNIXRz3wj7d
 VqoZLXRTT7twBSaNahLhNtg7fhS8Nu6/THuwXpNKPAvAsgJRTGk7kmrKj5P7rOZA
 rNHC1pvK1EWJJi2onHOmCzBccKRp9SeQlj+ddqG6seZhEnRYG6l7uhkyNZoyvKxO
-Fguc5g8Xf37VyuRMfwARAQABiQE8BBgBCAAmFiEEI2X1/oP+p+Ls2L28qrC4CLnp
-/P8FAlpT5C4CGwwFCQPCZwAACgkQqrC4CLnp/P/IOAf+LnQVtU7aHh4AZDsi1wXq
-KBo5l6r3G8tC/S0HEf8nnWMUio2/mwVrkbuTvBeKrcQ/mXFHHAG8YCAIHPgR7T0y
-2L6l2PL4HoXiLD8EwJ0sWZu2waxuxcTX+bb1i3Xm3squnqDtCX3pyoXWx0GVgrz9
-7I/zitxeER+35ScaZ+JAAcNW59LpiV1SdIXqbtrw5QBJBuZUp0bvnzCNvdZLhnhb
-gWfwPEfcXFt5K87iTmfMFJOJpbUrEz/NWE9gOBCBjqxW0wVb+IWr0oFWvfxjuBq7
-IW9DezwkN1wAavP6g7+B4esCD6SRq+3CCzbT1By3X2h3SevU8tHkCSA3cIKgWdyD
-2A==
-=IsaH
+Fguc5g8Xf37VyuRMfwARAQABiQE8BBgBCAAmAhsMFiEEI2X1/oP+p+Ls2L28qrC4
+CLnp/P8FAl4XHW4FCQ0pOsAACgkQqrC4CLnp/P/xGggAhMz6NH1dYiFtc9+3vkAW
+bZ10MDvxdgyU+G1a0BVYVo2ZXkhJlb2yg5MEeL1MZ6cUtM7MR1OL0U1jayfdcTfr
+kkUi2a35BdvKRpxc3hcc4i2CdDxdx+IGrBa75P+vIKFj8WIvwABgRJNVzY1Oq6Lq
+zKPUpVPug80Hch++Kv6l1DEpcoXlGaI8Z1dWfAjYQ7HJF/YJNHloKwxa1mXo/l/S
+qQSFHB23IN682ANm8iEUphuvJVbOw4mubpCEpmJvIhEBeesgXfB503nniOsshq+9
+1bNZ3CFv/ylnj5sy5VzU0lfW/TrHiW4OOOSbX8mCSvcqN2mhjcu6r4olV0fWPrrV
+Lg==
+=H+8g
 -----END PGP PUBLIC KEY BLOCK-----

doc/challenges.txt

@@ -16,17 +16,6 @@ research projects on Genode.
 Applications and library infrastructure
 #######################################
 
-:GNU Privacy Guard:
-
-  The [https://gnupg.org/ - GNU Privacy Guard] (GNUPG) is the most widely
-  used Free-Software implementation of the OpenGPG standard. It comprises a
-  rich set of tools for encryption and key management. For many forthcoming
-  application scenarios of Genode such as package management and email
-  communication, GNUPG is crucial. Hence, it should be ported to Genode. Such
-  a port may leverage Genode's fine-grained component architecture to strongly
-  separate network-exposed functionality, the storage of key material, and the
-  cryptographic functions.
-
 :VNC server implementing Genode's framebuffer session interface:
 
   With 'Input' and 'Framebuffer', Genode provides two low-level interfaces
@@ -50,24 +39,6 @@ Applications and library infrastructure
   integrated in the operating system, i.e., in the form of Genode components
   or a set of Genode VFS plugins.
 
-:Tiled window manager:
-
-  At Genode Labs, we pursue the goal to shape Genode into an general-purpose
-  operating system suitable for productive work. The feature set needed to
-  achieve this goal largely depends on the tools and applications daily used by
-  the Genode engineers. As one particularly important tool for being highly
-  productive, we identified a tiled user interface. Currently, all developers
-  at Genode Labs embrace either the Ion3 window manager or the tiled Terminator
-  terminal emulator. Hence, we desire to have a similar mode of user
-  interaction on Genode as well. The goal of this challenge is to identify the
-  most important usage patters and the implementation of a tiled GUI that
-  multiplexes the framebuffer into a set of tiled and tabbed virtual
-  framebuffers.
-
-  Related to this work, the low-level 'Framebuffer' and 'Input' interfaces
-  should be subject to a revision, for example for enabling the flexible change
-  of framebuffer sizes as needed by a tiled user interface.
-
 :Interactive sound switchbox based on Genode's Audio_out session interface:
 
   Since version 10.05, Genode features a highly flexible configuration concept
@@ -116,6 +87,11 @@ Applications and library infrastructure
   of communicating threads as captured on the running system. The tool should
   work on a selected kernel that provides a facility for tracing IPC messages.
 
+  The underlying light-weight tracing infrastructure is
+  [https://genode.org/documentation/release-notes/19.08#Tracinghttps://genode.org/documentation/release-notes/19.08#Tracing - already in place].
+  The Qt-based tracing tools would complement this infrastructure with
+  an interactive front end.
+
 :Ports of popular software:
 
   Genode features a ports mechanism to cleanly integrate 3rd-party software.
@@ -127,6 +103,18 @@ Applications and library infrastructure
   have available on Genode is available at
   [http://usr.sysret.de/jws/genode/porting_wishlist.html].
 
+:Native Open-Street-Maps (OSM) client:
+
+  When using Sculpt OS, we regularly need to spawn a fully fledged web
+  browser in a virtual machine for using OSM or Google maps. The goal
+  of this project would be a native component that makes maps functionality
+  directly available on Genode, alleviating the urge to reach for a SaaS
+  product. The work would include a review of existing OSM clients regarding
+  their feature sets and the feasibility of porting them to Genode.
+  Depending on the outcome of this review, an existing application could
+  be ported or a new component could be developed, e.g., leveraging Genode's
+  Qt support.
+
 
 Application frameworks and runtime environments
 ###############################################
@@ -135,18 +123,18 @@ Application frameworks and runtime environments
 
   [http://openjdk.java.net/ - OpenJDK] is the reference implementation of the
   Java programming language and hosts an enormous ecosystem of application
-  software. The goal of this line of work is the ability to run this
-  software directly on Genode. The centerpiece of OpenJDK is Hotspot - the
-  Java virtual machine implementation, which must be ported to Genode.
-  The initial port should suffice to execute simple example programs that
-  operate on textual input. Since Genode has the FreeBSD libc readily
-  available, OpenJDK's existing POSIX backends can be reused. The next step
-  is the creation of Genode-specific native classes that bridge the gap
-  between the Java world and Genode, in particular the glue code to
-  run graphical applications as clients of Genode's GUI server. Since
-  OpenJDK has been ported to numerous platforms (such as Haiku), there
-  exists a comforting number of implementations that can be taken as
-  reference.
+  software.
+
+  Since
+  [https://genode.org/documentation/release-notes/19.02#Showcase_of_a_Java-based_network_appliance - version 19.02], 
+  Genode features a port of OpenJDK that allows the use of Java for networking
+  applications.
+
+  The next step would be the creation of Genode-specific native classes that
+  bridge the gap between the Java world and Genode, in particular the glue
+  code to run graphical applications as clients of Genode's GUI server. Since
+  OpenJDK has been ported to numerous platforms (such as Haiku), there exists
+  a comforting number of implementations that can be taken as reference.
 
 :Android's ART VM natively on Genode:
 
@@ -155,22 +143,6 @@ Application frameworks and runtime environments
   removed from the trusted computing base of Android, facilitating the use of
   this mobile OS in high-assurance settings.
 
-:Rust bindings for the Genode API:
-
-  Rust is a low-level systems programming language that ensures memory
-  safety without employing a garbage collector. It thereby challenges C++
-  as the go-to programming language for high-performance and low-level code.
-  Since
-  [http://genode.org/documentation/release-notes/16.05#New_support_for_the_Rust_programming_language - version 16.05],
-  Genode supports the use of the Rust programming language within
-  components. However, to unleash the potential of this combination,
-  Genode's API must become available to native Rust code. The intermediate goal
-  of this project is the implementation of an example server, e.g., a
-  component that provides a terminal-session interface. Thereby, we
-  will encounter the problems of bootstrapping and configuration of the
-  component, the provisioning of signal handlers and session objects, and
-  memory management.
-
 :Go language runtime:
 
   Go is a popular language in particular for web applications. In the past,
@@ -222,6 +194,33 @@ Application frameworks and runtime environments
   development is [http://halvm.org - HalVM] - a light-weight OS runtime for
   Xen that is based on Haskell.
 
+:Xlib compatibility:
+
+  Developments like Wayland notwithstanding, most application software on
+  GNU/Linux systems is built on top of the Xlib programming interface.
+  However, only a few parts of this wide interface are actually used today.
+  I.e., modern applications generally deal with pixel buffers instead of
+  relying on graphical drawing primitives of the X protocol. Hence, it seems
+  feasible to reimplement the most important parts of the Xlib interface to
+  target Genode's native GUI interfaces (nitpicker) directly. This would
+  allow us to port popular application software to Sculpt OS without
+  changing the application code.
+
+:Bump-in-the-wire components for visualizing session interfaces:
+
+  Genode's session interfaces bear the potential for monitoring and
+  visualizing their use by plugging a graphical application
+  in-between any two components. For example, by intercepting block
+  requests issued by a block-session client to a block-device driver,
+  such a bump-in-the-wire component could visualize
+  the access patterns of a block device. Similar ideas could be pursued for
+  other session interfaces, like the audio-out (sound visualization) or NIC
+  session (live visualization of network communication).
+
+  The visualization of system behavior would offer valuable insights,
+  e.g., new opportunities for optimization. But more importantly, they
+  would be extremely fun to play with.
+
 
 Virtualization
 ##############
@@ -237,21 +236,6 @@ Virtualization
   is normally not possible. Also, complex Genode scenarios (like Turmvilla)
   could be prototyped on GNU/Linux.
 
-:VirtualBox on top of seL4:
-
-  The [https://sel4.systems - seL4 microkernel] is a modern microkernel that
-  undergoes formal verification to prove the absence of bugs. Since version
-  4.0, the kernel supports virtualization support on x86-based hardware.
-  Genode has experimental support for seL4 that allows almost all Genode
-  components to be used on top of this kernel. VirtualBox is an exception
-  because it closely interacts with the underlying kernel (like NOVA) to
-  attain good performance. We have shown that VirtualBox can be executed
-  within a protection domain of the NOVA microhypervisor. The goal of this
-  project is the application of this approach to the virtualization
-  interface of seL4. The result will be a VM hosting environment that
-  ensures the separation of virtual machines via the formally verified
-  seL4 kernel.
-
 :Xen as kernel for Genode:
 
   Using Xen as kernel for Genode would clear the way to remove the
@@ -294,22 +278,25 @@ Virtualization
   the project bears the opportunity to explore the provisioning of the
   KVM interface based on Genode's VFS plugin concept.
 
+:Hardware-accelerated graphics for virtual machines:
+
+  In
+  [https://genode.org/documentation/release-notes/17.08#Hardware-accelerated_graphics_for_Intel_Gen-8_GPUs - Genode 17.08],
+  we introduced a GPU multiplexer for Intel Broadwell along with support
+  for Mesa-based 3D-accelerated applications.
+  While designing Genode's GPU-session interface, we also aimed at supporting
+  the hardware-accelerated graphics for Genode's virtual machine monitors like
+  VirtualBox or Seoul, but until now, we did not took the practical steps of
+  implementing a virtual GPU device model.
+
+  The goal of this project is the offering of a virtual GPU to a Linux guest
+  OS running on top of Genode's existing virtualization and driver
+  infrastructure.
+
 
 Device drivers
 ##############
 
-:Isochronous USB devices:
-
-  Genode's USB driver supports bulk and interrupt endpoints. Thereby, most
-  USB devices like USB storage, user input, printers, and networking devices
-  can be used. However, multi-media devices such as cameras or audio
-  equipment use isochronous endpoints, which are not supported. The goal
-  of this line of work is the support of these devices in Genode. The topic
-  touches the USB driver, the USB session interface, an example implementation
-  of a USB client driver (using the session interface) for a device of choice,
-  and - potentially - the enhancement of Genode's USB-pass-through mechanism
-  for VirtualBox.
-
 :Sound on the Raspberry Pi:
 
   The goal of this project is a component that uses the Raspberry Pi's
@@ -318,18 +305,6 @@ Device drivers
   backend, the new driver will make the sound of all SDL-based games
   available on the Raspberry Pi.
 
-:Framebuffer for UEFI and Coreboot:
-
-  By moving away from the legacy BIOS boot mechanism, it is time to
-  reconsider closely related traditional approaches such as the use of
-  the VESA BIOS extensions for accessing the frame buffer. On UEFI or
-  Coreboot systems, there exist alternative ways to initialize and
-  access the framebuffer in a hardware-independent way. On the course of
-  this project, we will explore the available options and create dedicated
-  Genode driver components that use the modern mechanisms.
-  For reference, the current state of Genode's UEFI support is documented
-  in [https://github.com/genodelabs/genode/issues/2242 - Issue 2242].
-
 :Data Plane Development Kit (DPDK):
 
   Genode utilizes the network device drivers of the iPXE project, which
@@ -357,8 +332,22 @@ Platforms
   Genode functionality such as its native GUI, lwIP, and Noux, many protocol
   stacks can effectively be removed from the Linux kernel.
 
-  The goal of this project is to evaluate how small the Linux kernel can get
-  when used as a microkernel.
+  In 2018, Johannes Kliemann pursued this topic to a state where Genode
+  could be used as init process atop a customized Linux kernel.
+  [https://lists.genode.org/pipermail/users/2018-May/006066.html - His work]
+  included the execution of Genode's regular device drivers for VESA and
+  PS/2 as regular Genode components so that Genode's interactive demo
+  scenario ran happily on a laptop. At this time, however, only parts of
+  his results were merged into Genode's mainline.
+
+  The goal of this project is to follow up on Johannes' work, bring the
+  [https://github.com/genodelabs/genode/pull/2829 - remaining parts] into
+  shape for the inclusion into Genode, and address outstanding topics, in
+  particular the handling of DMA by user-level device drivers. Further down
+  the road, it would be tempting to explore the use of
+  [https://en.wikipedia.org/wiki/Seccomp - seccomp] as sandboxing mechanism
+  for Genode on Linux and the improvement of the Linux-specific implementation
+  of Genode's object-capability model.
 
 :Support for the HelenOS/SPARTAN kernel:
 
@@ -381,34 +370,46 @@ Platforms
   kernel is used for Mac OS X, it could represent an industry-strength
   base platform for Genode supporting all CPU features as used by Mac OS X.
 
-:Linux process containers for supporting Genode`s resource trading:
+:Genode on the Librem5 phone hardware:
 
-  Even though the Linux version of Genode is primarily meant as a development
-  platform, there exist interesting opportunities to explore when combining
-  Genode with Linux, in particular Linux' process containers.
-  Linux process containers provide a mechanism to partition physical resources,
-  foremost CPU time, between Linux processes. This raises the interesting
-  question of whether this mechanism could be used for a proper implementation
-  of Genode's resource trading on Linux.
-  [http://lwn.net/Articles/236038/ - Process containers introduction...]
+  Even though there exists a great variety of ARM-based SoCs, Genode
+  primarily focuses on the NXP i.MX family because it is - in contrast
+  to most SoCs in the consumer space - very liberal in terms of
+  good-quality public documentation and reference code, and it scales
+  from industrial to end-user-facing use cases (multi-media).
+
+  The [https://puri.sm/products/librem-5/ - Librem5] project - with its
+  mission to build a trustworthy mobile phone - has chosen the i.MX family as
+  the basis for their product for likely the same reasons that attract us.
+
+  To goal of this work is bringing Genode to the Librem5 hardware.
+  For the Librem5 project, Genode could pave the ground towards new use cases
+  like high-security markets where a regular Linux-based OS would not be
+  accepted. For the Genode community, the Librem5 hardware could become an
+  attractive mobile platform for everyday use, similar to how we developers
+  use our Genode-based [https://genode.org/download/sculpt - Sculpt OS] on our
+  laptops.
+
+
+System management
+#################
+
+:Remote management of Sculpt OS via Puppet:
+
+  [https://en.wikipedia.org/wiki/Puppet_(company)#Puppet - Puppet] is a
+  software-configuration management tool for administering a large amount
+  of machines from one central place. Genode's
+  [https://genode.org/download/sculpt - Sculpt OS] lends itself to such
+  an approach of remote configuration management by the means of the
+  "config" file system (for configuring components and deployments) and
+  the "report" file system (for obtaining the runtime state of components).
+  The project would explore the application of the Puppet approach and tools
+  to Sculpt OS.
 
 
 Optimizations
 #############
 
-:Low-latency audio streaming:
-
-  Genode comes with an audio streaming interface called 'Audio_out' session.
-  It is based on a shared-memory packet stream accompanied with asynchronous
-  data-flow signals. For real-time audio processing involving chains of Genode
-  components, streams of audio data must be carried at low latency, imposing
-  constraints to buffer sizes and the modes of operation of the audio mixer and
-  audio drivers. The goal of this project is to create a holistic design of the
-  whole chain of audio processing, taking thread-scheduling into account. A
-  particular challenge is the mixed output of real-time (small buffer, low
-  latency) and non-real-time (larger buffer to compensate jitter, higher
-  latency) audio sources.
-
 :De-privileging the VESA graphics driver:
 
   The VESA graphics driver executes the graphics initialization code provided

doc/news.txt

@@ -3,6 +3,114 @@
                                Genode News
                                ===========
 
+
+Genode OS Framework release 20.02 | 2020-02-28
+##############################################
+
+| With version 20.02, Genode makes Sculpt OS fit for running on i.MX 64-bit
+| ARM hardware, optimizes the performance throughout the entire software stack,
+| and takes the next evolutionary step of the user-facing side of Sculpt OS.
+
+Without any doubt, Sculpt OS has been the driving motivation behind most
+working topics featured by the new release. One particularly exciting line
+of work is the enabling of Sculpt on i.MX-based 64-bit ARM hardware, which
+touched the framework on all levels, from the boot loader, over the kernel,
+device drivers, libraries, system management, up to the application level.
+The work goes as far as supporting Sculpt OS as a hypervisor platform for
+hosting Linux in a virtual machine.
+
+As a second Sculpt-related development, we strive to make the user-visible
+side of the operating system better approachable and more logical. With this
+background, the current release comes with a profound redesign of the
+administrative user interface of Sculpt OS. An updated downloadable system
+image will follow soon.
+
+Also related to Sculpt are an updated audio driver based on OpenBSD 6.6,
+the support of virtual desktops, and performance optimization of the
+Seoul virtual machine monitor on x86 hardware.
+
+Regarding the framework API, the release introduces a new library for
+building multi-component applications. It aims to bring the benefits of
+Genode's unique security architecture from the operating-system level to the
+application level.
+
+These topics are only the tip of the iceberg. For the complete picture,
+please consult the
+[https:/documentation/release-notes/20.02 - release documentation of version 20.02...]
+
+
+Road Map for 2020 | 2020-01-20
+##############################
+
+| In 2019, we will be concerned about dwarfing the barrier of entry into
+| the Genode world.
+
+Following the last year's leitmotif of "bridging worlds", we turn our
+attention to the removal of the hurdles faced by aspiring developers and
+users. During the annual road-map
+[https://lists.genode.org/pipermail/users/2019-December/006987.html - discussion]
+on our mailing list, we identified four tangible approaches towards that
+goal. First, making Sculpt OS more user friendly. Second, reinforcing trust in
+Genode by fostering the framework's high quality. Third, making the tooling
+around Genode a joy to use. And finally, the illustration of Genode's
+versatility in the form practical use cases.
+
+Besides this overall theme, we plan to continue our commitment to the
+NXP i.MX SoC family, revisit Genode's low-latency audio support, and
+extend the cultivation of Ada/SPARK within (and on top of) Genode.
+
+More background information about the new road map and a rough schedule are
+presented at our official [https:/about/road-map - road-map page].
+
+
+Genode OS Framework release 19.11 | 2019-11-28
+##############################################
+
+| Following this year's theme of "bridging worlds", Genode 19.11 adds the
+| ability to use popular build tools like CMake for application development,
+| introduces a new virtual-machine monitor for 64-bit ARM, and enhances
+| POSIX compatibility. As another highlight, it features the first version
+| of our custom block-device encrypter.
+
+Block-device encryption is a feature often requested by users of our Sculpt OS.
+Until now, we deliberately left this topic unaddressed because we felt that a
+profound answer was beyond our expertise. However, during the past year, we
+dived deep into it. The result is the prototype for a new block encrypter that
+encrypts data but also protects integrity and freshness. For us, the
+implementation of the encrypter is especially intriguing because - with about
+7000 lines of code - it is Genode's first non-trivial component written in the
+[https://en.wikipedia.org/wiki/SPARK_(programming_language) - SPARK]
+programming language.
+
+The second major addition is a new virtual machine monitor (VMM) for 64-bit
+ARM platforms such as the NXP i.MX8. It leverages the
+[https://genode.org/documentation/articles/arm_virtualization - proof of concept]
+we developed in 2015 for ARMv7, which we pursued as a technology exploration.
+In contrast, our aspiration with the new VMM is a product-quality solution.
+
+In our [https://genode.org/about/road-map - road map] for 2019, we stated
+the "bridging of worlds" as our overall theme for this year. On that account,
+the current release moves the project forward on two levels. First, by
+successively increasing the scope of POSIX compatibility, we reduce the
+friction when porting existing application software to Genode. We managed
+to bridge several gaps in our POSIX support that we considered as impossible
+to cover some years ago. In particular, we identified ways to emulate certain
+POSIX signals, ioctl calls, and fork/execve semantics. This way, popular
+software such as bash, coreutils, or Vim can now be executed as regular
+Genode components with no additional runtime environment (like Noux or a VMM)
+required.
+
+At a higher level, the current release introduces new tooling especially
+geared at the development and porting of application software. Compared to
+Genode's regular development tools, which were designed for whole-system
+development, the new tool called Goa relieves the developer from the
+complexity of Genode's custom build system and instead promotes the use of
+popular commodity solutions like CMake.
+
+These and more topics are described in the
+[https:/documentation/release-notes/19.11 - release documentation of version 19.11...]
+
+
 Genode OS Framework release 19.08 | 2019-08-28
 ##############################################
 

doc/release_notes-19-08.txt

@@ -143,8 +143,8 @@ corresponds to Shift, '<mod2>' to Control, '<mod3>' to AltGr, and '<mod4>' to
 Caps Lock.
 
 ! <mod1> <key name="KEY_LEFTSHIFT"/> <key name="KEY_RIGHTSHIFT"/> </mod1>
-! <mod2> <key name="KEY_LEFTCTRL"/>  <key name="KEY_RIGHTCTRL"/> </mod4>
-! <mod3> <key name="KEY_RIGHTALT"/> </mod4> <!-- AltGr -->
+! <mod2> <key name="KEY_LEFTCTRL"/>  <key name="KEY_RIGHTCTRL"/> </mod2>
+! <mod3> <key name="KEY_RIGHTALT"/> </mod3> <!-- AltGr -->
 ! <mod4> <rom name="capslock"/> </mod4>
 
 As outlined above, the '<key>' nodes generated by xkb2ifcfg always use the

doc/release_notes-19-11.txt

@@ -0,0 +1,815 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 19.11
+              ===============================================
+
+                               Genode Labs
+
+
+
+On our [https://genode.org/about/road-map - road map] for this year, we stated
+"bridging worlds" as our guiding theme of 2019. The current release pays
+tribute to this ambition on several accounts.
+
+First, acknowledging the role of POSIX in the real world outside the heavens
+of Genode, the release vastly improves our (optional) C runtime with respect
+to the emulation of POSIX signals, execve, and ioctl calls. With the line of
+work described in Section [C runtime with improved POSIX compatibility], we
+hope to greatly reduce the friction when porting and hosting existing
+application software directly on Genode.
+
+Second, we identified the process of porting or developing application
+software worth improving. Our existing tools were primarily geared to
+operating-system development, not application development. Application
+developers demand different work flows and tools, including the freedom to use
+a build system of their choice.
+Section [New tooling for bridging existing build systems with Genode]
+introduces our new take on this productivity issue.
+
+Third, in cases where the porting of software to Genode is considered
+infeasible, virtualization comes to the rescue. With the current release, a
+new virtual machine monitor for the 64-bit ARM architecture enters the
+framework. It is presented in Section [Virtualization of 64-bit ARM platforms].
+
+As another goal for 2019, we envisioned a solution for block-level device
+encryption, which is a highly anticipated feature among Genode users. We are
+proud to present the preliminary result of our year-long development in
+Section [Preliminary block-device encrypter].
+
+
+Preliminary block-device encrypter
+##################################
+
+Over the past year, we worked on implementing a block-device encryption
+component that makes use of the
+[https://en.wikipedia.org/wiki/SPARK_(programming_language) - SPARK]
+programming language for its core logic. In contrast to common
+block-device encryption techniques where normally is little done besides
+the encryption of the on-disk blocks, the _consistent block encrypter (CBE)_
+aims for more. It combines multiple techniques to ensure integrity -
+the detection of unauthorized modifications of the block-device -
+and robustness against data loss. Robustness is achieved by keeping snapshots
+of old states of the device that remain unaffected by the further operation of
+the device. A copy-on-write mechanism (only the differential changes to the
+last snapshot are stored) is employed to maintain this snapshot history with
+low overhead. To be able to access all states of the device in the same manner,
+some kind of translation from virtual blocks to blocks on the device is needed.
+Hash-trees, where each node contains the hash of its sub-nodes, combine the
+aspect of translating blocks and ensuring their integrity in an elegant way.
+During the tree traversal, the computed hash of each node can be easily checked
+against the hash stored in the parent node.
+
+The CBE does not perform any cryptography by itself but delegates
+cryptographic operations to another entity. It neither knows nor cares about
+the used algorithm. Of all the nodes in the virtual block device (VBD), only
+the leaf nodes, which contain the data, are encrypted. All other nodes, which
+only contain meta-data, are stored unencrypted.
+
+Design
+------
+
+As depicted in Figure [cbe_trees], all information describing the various
+parts of the CBE is stored in the superblock. The referenced VBD is a set of
+several hash trees, each representing a certain device state including the
+current working state. Only the tree of the current working state is used to
+write data to the block device. All other trees represent snapshots of older
+states and are immutable. Each stored device state has a generation number
+that provides the chronological order of the states.
+
+As you can see, in the depicted situation, there exist four device states - the
+snapshot with generation 3 is the oldest, followed by two newer snapshots and
+generation 6 that marks the working state of the virtual device. The tree with
+generation 6 is the current working tree. Each tree contains all changes done
+to the VBD since the previous generation (for generation 6 the red nodes). All
+parts of a tree that didn't change since the previous generation are references
+into older trees (for generation 6 the gray nodes). Note that in the picture,
+nodes that are not relevant for generation 6 are omitted to keep it manageable.
+The actual data blocks of the virtual device are the leaf nodes of the trees,
+shown as squares.
+
+[image cbe_trees]
+
+Whenever a block request from the client would override data blocks in
+generation 6 that are still referenced from an older generation, new blocks for
+storing the changes are needed. Here is where the so-called _Free Tree_ enters
+the picture. This tree contains and manages the spare blocks. Spare blocks are
+a certain amount of blocks that the CBE has in addition to the number of blocks
+needed for initializing the virtual device. So, after having initialized a
+virtual device, they remain unused and are only referenced by the Free Tree.
+Therefore, in case the VBD needs new blocks, it consults the Free Tree (red
+arrow).
+
+In the depicted situation, writing the first data block (red square) would
+require allocating 4 new blocks as all nodes in the branch leading to the
+corresponding leaf node - including the leaf node itself - have to be written.
+In contrast, writing the second data block would require allocating only one
+new block as the inner nodes (red circles) now already exist. Subsequent write
+requests affecting only the new blocks will not trigger further block
+allocations because they still belong to the current generation and will be
+changed in-place. To make them immutable we have to create a new snapshot.
+
+The blocks in generation 5 that were replaced by the change to generation 6
+(blue nodes) are not needed for the working state of the virtual device
+anymore. They are therefore, in exchange for the allocated blocks, added to
+the Free Tree. But don't be fooled by the name, they are not free for
+allocation yet, but marked as "reserved" only. This means, they are
+potentially still part of a snapshot (as is the case in our example) but the
+Free Tree shall keep checking, because once all snapshots that referenced the
+blue blocks have disappeared, they become free blocks and can be allocated
+again.
+
+To create a new snapshot, we first have to make all changes done to the VBDs
+working state as well as the Free Tree persistent by writing all corresponding
+blocks to the block-device. After that, the new superblock state is written to
+the block-device. To safeguard this operation, the CBE always maintains several
+older states of the superblock on the block device. In case writing the new
+state of the superblock fails, the CBE could fall back to the last state that,
+in our example, would contain only generations 3, 4, and 5. Finally, the
+current generation of the superblock in RAM is incremented by one (in the
+example to generation 7). Thereby, generation 6 becomes immutable.
+
+A question that remains is when to create snapshots. Triggering a snapshot
+according to some heuristics inside the CBE might result in unnecessary
+overhead. For instance, the inner nodes of the tree change frequently during a
+sequential operation. We might not want them to be re-allocated all the time.
+Therefore, the creation of a snapshot must be triggered explicitly from the
+outside world. This way, we can accommodate different strategies, for
+instance, client-triggered, time-based, or based on the amount of data
+written.
+
+When creating a snapshot, it can be specified whether it shall be disposable
+or persistent. A disposable snapshot will be removed automatically by the CBE
+in two situations, either
+
+* When there are not enough usable nodes in the Free Tree left to
+  satisfy a write request, or
+* When creating a new snapshot and all slots in the superblock that might
+  reference snapshots are already occupied.
+
+A persistent snapshot, or quarantine snapshot, on the other hand will never be
+removed automatically. Its removal must be requested explicitly.
+
+During initialization, the CBE selects the most recent superblock and reads the
+last generation value from it. The current generation (or working state
+generation) is then set to the value incremented by one. Since all old blocks,
+that are still referenced by a snapshot, are never changed again, overall
+consistency is guaranteed for every generation whose superblock was stored
+safely on disk.
+
+Implementation
+--------------
+
+Although we aimed for a SPARK implementation of the CBE, we saw several
+obstacles with developing it in SPARK right from the beginning. These obstacles
+mainly came from the fact that none of us was experienced in designing
+complex software in SPARK. So we started by conducting a rapid design-space
+exploration using our mother tongue (C++) while using only language features
+that can be mapped 1:1 to SPARK concepts. Additionally, we applied a clear
+design methodology that allowed us to keep implementation-to-test cycles
+small and perform a seamless and gradual translation into SPARK:
+
+* _Control flow_
+
+  The core logic of the CBE is a big state machine that doesn't block. On each
+  external event, the state machine gets poked to update itself accordingly.
+  C++ can call SPARK but SPARK never calls C++. The SPARK code therefore
+  evolves as self-contained library.
+
+* _Modularity_
+
+  The complex state machine of the CBE as a whole is split-up into smaller
+  manageable sub-state-machines, working independently from each other. These
+  modules don't call each other directly. Instead, an additional superior
+  module handles the interplay. This is done by constantly iterating over all
+  modules with the following procedure until no further progress can be made:
+
+  # Try to enter requests of other modules into the current one
+  # Poke the state machine of the current module
+  # The current module may have generated requests - Try to enter them into
+    the targeted modules
+  # The current module may have finished requests - Acknowledge them at the
+    modules they came from
+
+  Each module is represented through a class (C++) respectively a package with
+  a private state record (SPARK).
+
+* _No global state_
+
+  There are no static (C++) or package (SPARK) variables. All state is kept in
+  members of objects (C++) respectively records (SPARK). All packages are pure
+  and sub-programs have no side-effects. Therefore, memory management and
+  communication with other components is left to OS glue-code outside the
+  core logic.
+
+This approach worked out well. Module by module, we were able to translate the
+C++ prototype to SPARK without long untested phases, rendering all regression
+bugs manageable. In Genode, the CBE library is currently integrated through
+the CBE-VFS plugin. Figure [cbe_modules] depicts its current structure and the
+integration via VFS plugin.
+
+[image cbe_modules]
+
+The green and blue boxes each represent an Ada/SPARK package. The translation
+to SPARK started at the bottom of the picture moving up to the more abstract
+levels until it reached the Library module. This is the module that handles
+the interplay of all other modules. Its interface is the front end of the CBE
+library. So, all green packages are now completely written in SPARK and
+together form the CBE library. Positioned above, the CXX library in blue is
+brought in by a separate library and exports the CBE interface to C++. This
+way, the CBE can also be used in other environments including pure SPARK
+programs. The CXX Library package is not written in SPARK but Ada and performs
+all the conversions and checks required to meet the preconditions set by the
+SPARK packages below.
+
+At the C++ side, we have the VFS plugin. Even at this level, the already
+mentioned procedure applies: The plugin continuously tries to enter requests
+coming from the VFS client (above) into the CBE (below), pokes the CBE state
+machine, and puts thereby generated block/crypto requests of the CBE into the
+corresponding back-ends (left). This process is repeated until there is no
+further progress without waiting for an external event.
+
+Current state
+-------------
+
+In its current state, the CBE library is still pretty much in flux and is not
+meant for productive use.
+
+As the Free Tree does not employ copy-on-write semantics for its meta-data, a
+crash, software- or hardware-wise, will corrupt the tree structure and renders
+the CBE unusable on the next start.
+
+This issue is subject to ongoing work. That being said, there are
+components that, besides being used for testing, show how the interface of the
+CBE library lends itself to be integrated in components in different ways. At
+the moment, there are two components making use of the CBE library as
+block-device provider.
+
+The first one is the aforementioned CBE-VFS plugin. Besides r/w access to the
+working tree and r/o access to all persistent snapshots, it also provides a
+management interface where persistent snapshots can be created or discarded.
+Its current layout is illustrated by Figure [cbe_vfs]. The VFS plugin
+generates three top directories in its root directory. The first one is the
+_control_ directory. It contains several pseudo files for managing the CBE:
+
+[image cbe_vfs]
+
+:'key': set a key by writing a string into the file.
+:'create_snapshot': writing 'true' to this file will attempt to create
+  a new snapshot. (Eventually the snapshot will
+  appear in the 'snapshots' directory if it could be
+  created successfully.)
+:'discard_snapshot': writing a snapshot ID into this file will discard
+  the snapshot
+
+The second is the 'current' directory. It gives access to the current
+working tree of the CBE and contains the following file:
+
+:'data': this file represents the virtual block device and gives
+  read and write access to the data stored by the CBE.
+
+The third and last is the 'snapshots' directory. For each persistent snapshot,
+there is a sub-directory named after the ID of the snapshot. This directory,
+like the 'current' directory, contains a 'data' file. This file, however,
+gives only read access to the data belonging to the snapshot.
+
+The CBE-VFS plugin itself uses the VFS to access the underlying block device.
+It utilizes the file specified in its configuration. Here is a '<vfs>'
+snippet that shows a configured CBE-VFS plugin where the block device is
+provided by the block VFS plugin.
+
+! <vfs>
+!  <dir name="dev">
+!   <block name="block"/>
+!   <cbe name="cbe" block="/dev/block"/>
+!  </dir>
+! </vfs>
+
+An exemplary ready-to-use run script can be found in the CBE repository
+at _run/cbe_vfs_snaps.run_. This run script uses a bash script to
+automatically perform a few operations on the CBE using the VFS plugin.
+Afterwards it will drop the user into a shell where further operations
+can be performed manually, e.g.:
+
+! dd if=/dev/zero of=/dev/cbe/current/data bs=4K
+
+The second component is the CBE server. In contrast to the CBE-VFS plugin,
+it is just a simple block-session proxy component that uses a block connection
+as back end to access a block-device. It provides a front-end block session to
+its client, creates disposable snapshots every few seconds, and uses the
+'External_Crypto' library to encrypt the data blocks using AES-CBC-ESSIV. The
+used key is a plain passphrase. The following snippet illustrates its
+configuration:
+
+! <start name="cbe">
+!  <resource name="RAM" quantum="4M"/>
+!  <provides><service name="Block"/></provides>
+!  <config sync_interval="5" passphrase="All your base are belong to us"/>
+! </start>
+
+The _run/cbe.run_ run script in the CBE repository showcases the use of the
+CBE server.
+
+Both run scripts will create the initial CBE state in a RAM-backed
+block device that is then accessed by the CBE server or the CBE-VFS
+plugin.
+
+The run-script and the code itself can be found on the
+[https://github.com/cnuke/cbe/tree/cbe_19.11 - cbe/cbe_19.11] branch on
+GitHub. If you intend to try it out, you have to checkout
+the corresponding
+[https://github.com/cnuke/genode/tree/cbe_19.11 - genode/cbe_19.11]
+branch in the Genode repository as well.
+
+Future plans
+------------
+
+Besides addressing the current shortcomings and getting the CBE library
+production-ready so that it can be used in Sculpt, there are still
+a few features that are currently unimplemented. For one we would like
+to add support for making it possible to resize the VBD as well as the
+Free Tree. For now the geometry is fixed at initialization time and cannot
+be changed afterwards. Furthermore, we would like to enable re-keying,
+i.e., changing the used cryptographic key and re-encrypting the tree
+set of the VBD afterwards. In addition to implementing those features, the
+overall tooling for the CBE needs to be improved. E.g., there is currently
+no proper initialization component. For now, we rely on a component
+that was built merely as a test vehicle to generate the initial trees.
+
+
+Virtualization of 64-bit ARM platforms
+######################################
+
+Genode has a long history regarding support of all kinds of
+virtualization-related techniques including
+[https://genode.org/documentation/release-notes/9.11#Paravirtualized_Linux_on_Genode_OKL4 - para-virtualization],
+[https://genode.org/documentation/articles/trustzone - TrustZone],
+hardware-assisted virtualization on
+[https://genode.org/documentation/articles/arm_virtualization - ARM],
+[https://genode.org/documentation/release-notes/13.02#Full_virtualization_on_NOVA_x86 - x86],
+up to the full virtualization stack of
+[https://genode.org/documentation/release-notes/14.02#VirtualBox_on_top_of_the_NOVA_microhypervisor - VirtualBox].
+
+We regard those techniques as welcome stop-gap solutions for using non-trivial
+existing software stacks on top of Genode's clean-slate OS architecture. The
+[https://genode.org/documentation/release-notes/19.05#Kernel-agnostic_virtual-machine_monitors - recent]
+introduction of a kernel-agnostic interface to control virtual machines (VM)
+ushered a new level for the construction respectively porting of
+virtual-machine monitors (VMM). By introducing a new ARMv8-compliant VMM
+developed from scratch, we continue this line of work.
+
+The new VMM builds upon our existing proof-of-concept (PoC) implementation for
+ARMv7 as introduced in release
+[https://genode.org/documentation/release-notes/15.02#Virtualization_on_ARM - 15.02].
+In contrast to the former PoC implementation, however, it aims to be complete
+to a greater extent. Currently, it comprises device models for the following
+virtual hardware:
+
+* RAM
+* System Bus
+* CPU
+* Generic Interrupt Controller v2 and v3
+* Generic Timer
+* PL011 UART (limited)
+* Pass-through devices
+
+The VMM is able to load diverse 64-bit Linux kernels including
+Device-Tree-Binary (DTB) and Initramfs. Currently, the implementation uses a
+fixed memory layout for the guest-physical memory view, which needs to be
+reflected by the DTB used by the guest OS. An example device-tree source file
+can be found at _repos/os/src/server/vmm/spec/arm_v8/virt.dts_. The actual VMM
+is located in the same directory.
+
+Although support for multi-core VMs is already considered internally, it is
+not yet finished. Further outstanding features that are already in development
+are Virtio device model support for networking and console. As the first - and
+by now only - back end, we tied the VMM to the ARMv8 broadened Kernel-agnostic
+VM-session interface as implemented by Genode's custom base-hw kernel. As a
+side effect of this work, we consolidated the generic VM session interface
+slightly. The RPC call to create a new virtual-CPU now returns an identifier
+for identification.
+
+The VMM has a strict dependency on ARM's hardware virtualization support
+(EL2), which comprises extensions for the ARMv8-A CPU, ARM's generic timer,
+and ARM's GIC. This rules out the Raspberry Pi 3 board as a base platform
+because it does not include a GIC but a custom interrupt-controller without
+hardware-assisted virtualization of interrupts. To give the new VMM a try, we
+recommend using the run script _repos/os/run/vmm_arm.run_ as a starting point
+for executing the VMM on top of the i.MX8 Evaluation Kit board.
+
+
+New tooling for bridging existing build systems with Genode
+###########################################################
+
+Genode's development tools are powerful and intimidating at the same time.
+Being designed from the perspective of a whole-systems developer, they put
+emphasis on the modularity of the code base (separating concerns like
+different kernels or system abstraction levels), transitive dependency
+tracking between libraries, scripting of a wide variety of system-integration
+tasks, and the continuous integration of complete Genode-based
+operating-system scenarios. Those tools are a two-edged sword though.
+
+On the one hand, the tools are key for the productivity of seasoned Genode
+developers once the potential of the tools is fully understood and leveraged.
+For example, during the development of Sculpt OS, we are able to
+change an arbitrary line of code in any system component and can test-drive
+the resulting Sculpt system on real hardware within a couple of seconds.
+As another example, the almost seamless switching from one OS kernel to
+another has become a daily routine that we just take for granted without
+even thinking about it.
+
+On the other hand, the sophistication of the tools stands in the way of
+application developers who are focused on a particular component instead
+of the holistic Genode system. In this case, the powerful system-integration
+features remain unused but the complexity of the tools and the build system
+prevails. Speaking of build systems, this topic is ripe of emotions
+anyway. _Developers use to hate build systems._ Forcing Genode's build
+system down the throats of application developers is probably not the best
+idea to make Genode popular.
+
+This line of thoughts prompted us to re-approach the tooling for Genode from
+the perspective of an application developer. The intermediate result is a new
+tool called Goa:
+
+:Goa project at GitHub:
+
+  [https://github.com/nfeske/goa]
+
+Unlike Genode's regular tools, Goa's work flow is project-centered. A project
+is a directory that may contain source code, data, instructions how to
+download source codes from a 3rd party, descriptions of system scenarios, or
+combinations thereof. Goa is independent from Genode's regular build system.
+It combines Genode's package management (depot) with commodity build systems
+such a CMake. In addition to building and test-driving application software
+directly on a Linux-based development system, Goa is able to aid the process
+of exporting and packaging the software in the format expected by Genode
+systems like Sculpt OS.
+
+At the current stage, Goa should be considered as work in progress. It's a new
+approach and its success is anything but proven. That said, if you are
+interested in developing or porting application software for Genode, your
+feedback would be especially valuable. As a starting point, you may find the
+following introductory article helpful:
+
+:Goa - streamlining the development of Genode applications:
+
+  [https://genodians.org/nfeske/2019-11-25-goa]
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+File-system session
+===================
+
+The file-system session interface received a much anticipated update.
+
+Writing modification times
+--------------------------
+
+The new operation WRITE_TIMESTAMP allows a client to update the modification
+time of a file-system node. The time is defined by the client to keep
+file-system servers free from time-related concerns. The VFS server implements
+the operation by forwarding it to the VFS plugin interface. At present, this
+new interface is implemented by the rump VFS plugin to store modification
+times on EXT2 file systems.
+
+
+Enhanced file-status info
+-------------------------
+
+The status of a file-system node as returned by the 'File_system::Status'
+operation has been revisited. First, we replaced the fairly opaque "mode" bits -
+which were an ad-hoc attempt to stay compatible with Unix - with the explicit
+notion of 'readable', 'writeable', and 'executable' attributes. We completely
+dropped the notion of users and groups. Second, we added the distinction
+between *continuous* and *transactional* files to allow for the robust
+implementation of continuous write operations across component boundaries. A
+continuous file can be written-to via a sequence of arbitrarily sized chunks
+of data. For such files, a client can split a large write operation into any
+number of smaller operations in accordance to the size of the used I/O
+buffers. In contrast, a write to a transactional file is regarded as a
+distinct operation. The canonical example of a transactional file is a
+socket-control pseudo file.
+
+
+Virtual file-system infrastructure
+==================================
+
+First fragments of a front-end API
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The VFS is mostly used indirectly via the C runtime. However, it is also
+useful for a few components that use the Genode API directly without any
+libc. To accommodate such users of the VFS, we introduced the front-end
+API at _os/vfs.h_ that covers a variety of current use cases. Currently, those
+use cases revolve around the watching, reading, and parsing of files and
+file-system structures - as performed by Sculpt's deployment mechanism.
+Writing to files is not covered.
+
+
+Improved file-watching support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All pseudo files that use the VFS-internal 'Readonly_value_file_system'
+utility have become able to deliver watch notifications. This change enables
+VFS clients to respond to VFS-plugin events (think of terminal resize)
+dynamically.
+
+Speaking of the *terminal VFS plugin*, the current release enhances the plugin
+in several respects. First, it now delivers status information such as the
+terminal size via pseudo files. Second, we equipped the VFS terminal file
+system with the ability to detect user interrupts in the incoming data stream,
+and propagate this information via the new pseudo file '.terminal/interrupts'.
+Each time, the user presses control-c in the terminal, the value stored in
+this pseudo file is increased. Thereby, a VFS client can watch this file to
+get notified about the occurrences of user interrupts.
+
+
+VFS plugin for emulating POSIX pipes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We added a new VFS plugin for emulating POSIX pipes. The new plugin creates
+pipes between pairs of VFS handles. It replaces the deprecated libc_pipe
+plugin. In contrast to the libc_pipe plugin, which was limited to pipes within
+one component, the new VFS plugin can also be used to establish pipes between
+different components by mounting the plugin at a shared VFS server.
+
+
+C runtime with improved POSIX compatibility
+===========================================
+
+Within Genode, we used to think of POSIX as a legacy that is best avoided.
+In fact, the foundational components of the framework do not depend on a
+C runtime at all. However, higher up the software stack - at the latest when
+3rd-party libraries enter the picture - a working C runtime is unavoidable. In
+this statement, the term "working" is rather muddy though. Since we have never
+fully embraced POSIX, we were content with cutting corners here and there. For
+example, given Genode's architecture, supporting 'fork' and 'execve' seemed
+totally out of question because those mechanisms would go against the grain of
+Genode.
+
+However, our growing aspiration to bridge the gap between existing popular
+applications and Genode made us re-evaluate our stance towards POSIX.
+All technical criticism aside, POSIX is immensely useful because it is
+a universally accepted stable interface. To dissolve friction between
+Genode and popular application software, we have to satisfy the application's
+expectations. This ignited a series of developments, in particular
+the added support for 'fork' and 'execve' - of all things - in
+[https://genode.org/documentation/release-notes/19.08#Consolidation_of_the_C_runtime_and_Noux - Genode 19.08],
+which was nothing short of surprising, even to us.
+The current release continues this line of development and brings the
+following improvements.
+
+
+Execve
+------
+
+The libc's 'execve' implementation got enhanced to evaluate the path of the
+executable binary according to the information found on the VFS, in particular
+by traversing directories and following symbolic links. This enables the libc
+to execute files stored at sub directories of the file system.
+
+Furthermore, 'execve' received handling for *executing shell scripts* by
+parsing the shebang marker at the beginning of the executable file. This way,
+the 'execve' mechanism of the libc reaches parity with the feature set of the
+Noux runtime that we traditionally used to host Unix software on top of
+Genode.
+
+
+Modification-time handling
+--------------------------
+
+By default, the libc uses the just added facility for updating the timestamp
+of file-system nodes when closing a written-to file, which clears the path
+towards using tools like 'make' that rely on file-modifications times.
+
+The libc's mechanism can be explicitly disabled by specifying
+! <libc update_mtime="no"...>
+This is useful for applications that have no legitimate access to a time
+source.
+
+
+Emulation of 'ioctl' operations via pseudo files
+------------------------------------------------
+
+With the current release, we introduce a new scheme of handling ioctl
+operations, which maps 'ioctl' calls to pseudo-file accesses, similar to how
+the libc already maps socket calls to socket-fs operations.
+
+A device file can be accompanied with a (hidden) directory that is named after
+the device file and hosts pseudo files for triggering the various device
+operations. For example, for accessing a terminal, the directory structure
+looks like this:
+
+! /dev/terminal
+! /dev/.terminal/info
+! /dev/.terminal/rows
+! /dev/.terminal/columns
+! /dev/.terminal/interrupts
+
+The 'info' file contains device information in XML format. The type of the XML
+node corresponds to the device type. Whenever the libc receives a TIOCGWINSZ
+ioctl for _/dev/terminal_, it reads the content of _/dev/.terminal/info_ to
+obtain the terminal-size information. In this case, the _info_ file looks as
+follows:
+
+! <terminal rows="25" columns="80/>
+
+Following this scheme, VFS plugins can support ioctl operations by providing
+an ioctl directory in addition to the actual device file.
+
+
+Emulation of POSIX signals
+--------------------------
+
+Even though there is no notion of POSIX signals at the Genode level, we
+can reasonably emulate certain POSIX signals at the libc level. The current
+release introduces the first bunch of such emulated signals:
+
+:SIGWINCH: If 'stdout' is connected to a terminal, the libc watches the
+  terminal's ioctl pseudo file _.terminal/info_. Whenever the terminal
+  size changes, the POSIX signal SIGWINCH is delivered to the application.
+  With this improvement, Vim becomes able to dynamically adjust itself
+  to changed window dimensions when started as a native Genode component
+  (w/o the Noux runtime environment).
+
+:SIGINT: If 'stdin' is connected to a terminal, the libc watches the
+  terminal's pseudo file _.terminal/interrupts_. Since, the terminal VFS
+  plugin modifies the file for each occurred user interrupt (control-c),
+  the libc is able to reflect such an event as SIGINT signal to the
+  application.
+
+:Process-local signal delivery: The libc's implementation of 'kill' got
+  enhanced with the ability to submit signals to the local process.
+
+
+Support for arbitrarily large write operations
+----------------------------------------------
+
+The number of bytes written by a single 'write' call used to be constrained by
+the file's underlying I/O buffer size. Even though our libc correctly returned
+this information to the application, we found that real-world applications
+rarely check the return value of 'write' because partial writes do usually not
+occur on popular POSIX systems. Thanks to the added distinction between
+continuous and transactional files as described in Section
+[File-system session], we became able to improve the libc's write operation to
+iterate on partial writes to continuous files until the original write count
+is reached. The split of large write operations into small partial writes as
+dictated by the VFS infrastructure becomes invisible to the libc-using
+application.
+
+
+Input-event handling
+====================
+
+In Genode 19.08, we undertook a comprehensive rework of our keyboard-event
+handling in the light of localization and also promised to tie up remaining
+loose ends soon.
+
+First, we again dived into our character generators for a thorough check of
+our stack of keyboards and fixed remaining inconsistencies in French and
+German layouts. En passant, we also increased the default RAM quotas for
+the input filter to 1280K in our recipes to cope with the increased
+layout-configuration sizes in corner cases.
+
+Next - and more importantly - we subdued the monsters lurking in our Qt5
+keyboard back end and enabled transparent support for system-wide keyboard
+layout configuration for Qt5 components. One important change during this work
+was to move the handling of control key sequences into the clients. For
+example, the graphical terminal and Qt5 interpret key events in combination
+with the CTRL modifier based on characters and, thus, support CTRL-A with
+AZERTY and QWERTY layouts correctly. As a result we removed all CTRL modifier
+(mod2) configurations from our character-generator configurations.
+
+Finally we'd like to point out one important change of our rework that
+repeatedly led to surprises: For keys without character mappings the reworked
+character-generator mechanism emits invalid codepoints in contrast to
+codepoints with value 0. For that reason, components interpreting character
+events should check 'Codepoint::valid()' to prevent the processing of invalid
+characters (and not the frequent pattern of 'codepoint.value != 0').
+
+
+NIC router
+==========
+
+The NIC router has received the ability to report the link state of its NIC
+interfaces (downlinks and uplinks). To control this mechanism, there are two
+new boolean attributes 'link_state' and 'link_state_triggers' in the <report>
+tag of the NIC router configuration. If the former is set to "true", the report
+will contain the current link state for each interface:
+
+! <domain name="domain1">
+!    <interface label="uplink1" link_state="false"/>
+!    <interface label="downlink1" link_state="true"/>
+! </domain>
+! <domain name="domain2">
+!    <interface label="downlink2" link_state="true"/>
+! </domain>
+
+The second attribute decides whether to trigger a report update each time the
+link state of an interface changes. By default, both attributes are set to
+"false".
+
+
+Device drivers
+==============
+
+Platform driver on x86
+~~~~~~~~~~~~~~~~~~~~~~
+
+During our enablement of Genode on a
+[https://genodians.org/chelmuth/2019-10-21-sculpt-elitebook - recent notebook],
+we spotted some PC platform shortcomings, we address with this release. Most
+prominently we added support for
+[https://en.wikipedia.org/wiki/PCI_configuration_space#Bus_enumeration - 64-bit PCI base address registers]
+to the x86 platform driver. This allows the use of PCI devices that are
+assigned to physical I/O-memory regions beyond 4 GiB by the boot firmware.
+
+
+Wireless driver
+~~~~~~~~~~~~~~~
+
+We added the firmware images for the 5000 and 9000 series of Intel wireless
+devices to the firmware white-list in the _wifi_drv_ component. Such devices
+as 5100AGN, 5300AGN and 5350AGN as well as 9461, 9462 and 9560 should now be
+usable on Genode.
+
+
+Libraries and applications
+##########################
+
+VirtualBox improvements
+=======================
+
+The GUI handling of our VirtualBox port got improved to react on window-size
+changes more instantly. The effect is that an interactive adjustment of the
+window size, e.g., on Sculpt, becomes quickly visible to the user. Still, the
+VM may take some time to adjust to the resolution change, which ultimately
+depends on the behavior of the driver of the VirtualBox guest additions.
+
+
+Updated 3rd-party software
+==========================
+
+With the addition of the 64-bit ARM architecture (AARCH64) with the
+[https://genode.org/documentation/release-notes/19.05#Broadened_CPU_architecture_support_and_updated_tool_chain - 19.05]
+release, it became necessary to update the libraries the Genode tool chain
+(gcc) depends on in order to support AARCH64 properly. This concerns the GNU
+multi precision arithmetic library (gmp), which has been updated from version
+4.3.2 to 6.1.2, as well as the libraries that depend on it: Multi precision
+floating point (mpfr) and multi precision complex arithmetic (mpc). All those
+old versions did not offer support for the AARCH64 architecture, which is a
+requirement to make Genode self hosting. Targets for building binutils and GCC
+within Genode for AARCH64 are in place, GNU make is in place, and even code
+coverage (gcov) has been added. This work puts AARCH64 in line with other
+supported CPU architectures and emphasizes our interest in the ARM 64-bit
+architecture.
+
+
+Platforms
+#########
+
+Execution on bare hardware (base-hw)
+====================================
+
+With the previous release, Genode's base-hw kernel got extended to support the
+ARMv8-A architecture in principle. The first hardware supported was the
+Raspberry Pi 3 as well as the i.MX8 evaluation kit (EVK). But only a single
+CPU-core was usable at that time. Now, we lifted this limitation. On both
+boards, all four CPU-cores are available henceforth.
+
+
+Removed components
+##################
+
+The current release removes the following components:
+
+:gems/src/app/launcher:
+
+  The graphical launcher remained unused for a few years now. It is not
+  suitable for systems as flexible as Sculpt OS.
+
+:os/src/app/cli_monitor:
+
+  CLI monitor was a runtime environment with a custom command-line interface
+  to start and stop subsystems. It was part of the user interface of our
+  first take on a Genode-based desktop OS called
+  [https://genode.org/documentation/release-notes/15.11#Genode_as_desktop_OS - Turmvilla].
+
+  Nowadays, we use standard command-line tools like Vim to edit init
+  configurations dynamically, which is more flexible and - at the same time -
+  alleviates the need for a custom CLI. The CLI-monitor component was too
+  limited for use cases like Sculpt anyway.
+
+  Along with the CLI monitor, we removed the ancient (and untested for long
+  time) _terminal_mux.run_ script, which was the only remaining user of the CLI
+  monitor.
+
+:fatfs_fs, rump_fs, and libc_fatfs plugin:
+
+  The stand-alone file-system servers fatfs_fs and rump_fs as well as the
+  fatfs libc plugin have been superseded by the fatfs and rump VFS plugins.
+  The stand-alone servers can be replaced by using the VFS server plus the
+  corresponding VFS plugin as a drop-in replacement.
+

doc/release_notes-20-02.txt

@@ -0,0 +1,814 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 20.02
+              ===============================================
+
+                               Genode Labs
+
+
+
+This year's [https://genode.org/about/road-map - road map] is all about making
+Genode and Sculpt OS more approachable. It turns out that the first release of
+the year already pays tribute to that goal. First, it equips Sculpt OS with a
+much more logical and welcoming graphical user interface
+(Section [Redesign of the administrative user interface of Sculpt OS]).
+Second, it greatly reduces the friction when hosting existing applications on
+Genode by smoothening several rough edges with respect to POSIX compatibility,
+and by generally improving performance.
+
+Most topics of the release are closely related to Sculpt. The biggest
+break-though is certainly the ability of running Sculpt OS on 64-bit ARM
+hardware (Section [Sculpt OS on 64-bit ARM i.MX8 hardware]) along with our
+custom virtual machine monitor (VMM). On PC hardware, Sculpt users can enjoy
+an updated audio driver and optimizations of the Seoul VMM. Furthermore,
+Sculpt's window manager received the much anticipated ability to use virtual
+desktops.
+
+At the framework-API level, the most significant changes are the introduction
+of dedicated types for inter-thread synchronization patterns
+(Section [Base-framework refinements]) and a new library for
+bringing the benefits of the Genode architecture to the application level
+(Section [New sandbox library based on the init component]).
+
+
+Redesign of the administrative user interface of Sculpt OS
+##########################################################
+
+On our [https://genode.org/about/road-map - road map] for 2020, we stated
+the dwarfing of the barrier of entry as our main concern of the year.
+We highlighted the ease of use of Sculpt OS as one particular work area.
+
+
+Removing Unix from the picture
+------------------------------
+
+Until now, Sculpt's administrative user interface - lyrically called
+Leitzentrale - employed a small Unix runtime and the Vim editor as utility for
+basic file operations and for the tweaking of configurations. Even though this
+was a practical intermediate solution, we have to face the fact that not
+everyone loves the Unix command-line interface as much as we do. Quite the
+opposite, actually. When presenting Sculpt, we can clearly sense that people
+with a non-Unix background are put off by it. The audience generally loves the
+runtime graph, visual cues, and discoverability. Furthermore, command-line
+interfaces are (albeit wrongly) perceived as archaic and impenetrable relics
+by many computer users who are otherwise perfectly happy with the notion of
+files and directories. We identified that file-manipulation tasks performed in
+the Leitzentrale are rare and simple. Relying on Unix for those basic tasks is
+like taking a sledgehammer to crack a nut. On average, the Leitzentrale is
+used in just a few moments a day for basic things like browsing a file-system
+hierarchy, glimpsing at the reports stored on the report file system, deleting
+or copying a file or two, or tweaking a configuration file. With a Unix shell
+presenting one barrier, Vim is certainly an even higher one. Familiarity with
+Vim should definitely not be a prerequisite for using an operating system.
+Following this reasoning, we decided to swap out the command-line interface
+and Vim by a simple GUI-based file browser and a notepad-like editor, which do
+not require any learning curve.
+
+Note that even once the Unix command-line interface is removed from Sculpt's
+Leitzentrale, advanced users will still be able to manipulate Sculpt's config
+file system via a Unix runtime deployed as a regular component, similar to the
+use of the noux-system package we have today.
+
+
+New user-interface layout
+-------------------------
+
+The move away from the command-line interface goes hand in hand with the
+redesign of the overall user-interface layout. A new panel at the top of the
+screen contains two centered tabs for switching between the runtime graph and
+the file-system browser.
+
+[image sculpt_20.02_panel]
+
+The storage-management functionality has been moved from the former storage
+dialog into the respective nodes of the runtime graph. E.g., to format a block
+device, the user can now select a USB or storage node of the graph to get a
+menu of block-device-level operations.
+
+[image sculpt_20.02_storage]
+
+The network-management is now located at a drop-down menu that can be toggled
+via a button at the right side of the panel.
+
+[image sculpt_20.02_network]
+
+A new button on the left side of the panel allows the user to toggle a
+drop-down menu for GUI settings. At the current time, there is only the option
+to adjust the font size. In the future, the dialog will give easy access to
+the screen-resolution options and the keyboard layout.
+
+The log-message view is now hidden in another drop-down menu that can be
+toggled via a panel button. So when starting the system, the user is greeted
+with only the runtime graph, which is a much nicer and cleaner looking
+experience.
+
+Informative or diagnostic messages are displayed in the left-bottom corner of
+the screen.
+
+[image sculpt_20.02_message]
+
+The "Files" tab of the panel switches the main screen area to a simple file
+browser that lists all file systems available. By toggling one of the
+file-system buttons, the directory hierarchy can be browsed. When hovering
+a file, an "Edit" or "View" button appears, which can be used to open
+the file in a text area that appears on the right side of the file browser.
+The editor supports the usual notepad-like motions, operations, and
+shortcuts (control-c for copy, control-v for paste, control-s for save).
+
+[image sculpt_20.02_editor]
+
+
+Half-way there
+--------------
+
+With the current release, one can already accomplish a lot without having to
+resort to a command-line interface: connecting to the network, managing
+storage devices, installing and deploying software, inspecting the system
+state, and tweaking configurations.
+
+There are still a few gaps though. In particular the file browser does
+not yet support file operations like the copying, renaming, or removal of
+files. For these tasks, the current version of Sculpt still features the
+Unix-based inspect window, which can be accessed by toggling the "Inspect"
+button inside the USB or storage dialog. Once selected, the panel presents an
+"Inspect" tab that features the familiar Unix shell and Vim. Note, however,
+that we keep the inspect window only as an interim solution. It will
+eventually be removed. As with every new feature, there are still rough edges
+to be expected in the editor and file browser, e.g., the editing of files with
+long lines or the browsing of directories with many entries is not
+appropriately covered yet.
+
+To see the current new version of Sculpt OS in action, you may find the
+following presentation entertaining.
+
+:Live demonstration of Sculpt OS at FOSDEM 2020:
+
+  [https://fosdem.org/2020/schedule/event/uk_sculpt/]
+
+The new version 20.02 of Sculpt OS is part of this release and can be built
+from source and used right now. Several Genode developers already provide
+ready-to-use packages for the new version. The software depots by alex-ab,
+cnuke, skalk are worth exploring. A downloadable system image along with an
+updated manual will be released shortly.
+
+
+Sculpt OS on 64-bit ARM i.MX8 hardware
+######################################
+
+Within the past two releases, big steps were taken to support ARMv8 hardware in
+the Genode OS framework. After implementing basic support for Raspberry Pi 3,
+and the i.MX 8M Evaluation Kit, the network card was enabled for the latter.
+Moreover, we updated the Linux TCP/IP, and C library ports, as well as
+the Noux environment to support the architecture. Finally, with the latest
+releases, a new ARMv8-compliant virtual-machine monitor for the base-hw kernel
+entered the framework.
+
+The rapid achievements motivated us to strive for a more ambitious scenario to
+run on top of the currently focused ARMv8 hardware platform. So why not using
+Sculpt OS on the i.MX 8M System-on-Chip?
+
+
+Persistent storage
+==================
+
+There were several challenges to cope with initially. First, persistent
+storage was needed. Luckily, the Genode OS framework contained already an
+SD-card driver implementation for the i.MX series. The driver was written for
+Genode from scratch and initially supported the i.MX53 SoC only. From then, it
+got extended repeatedly to drive the SD-card controller of several i.MX6 and
+i.MX7 platforms. Therefore, it was not a big issue to support the new hardware
+too. However, when we later used it in Sculpt, it turned out that the driver
+has some low-latency requirements. If those were not met, it got stuck. This
+was the time where the CPU-quota mechanism came in handy in a real-world
+scenario. It helped to let the interrupt handler of the driver be scheduled in
+time, and thereby let the driver run stable.
+
+Having a working block device is one part, but it is of little use without a
+file system. In Sculpt OS, the NetBSD rump kernel's ext2 file-system is
+typically used to host the depot package system and for keeping configuration
+files persistent. Unfortunately, the version of NetBSD as used in Genode's
+rump kernel port does not contain the ARMv8 architecture. Of course, we could
+have upgraded the rump kernel as a whole. But this software stack is quite
+complex with a lot of threads reproducing a sophisticated state machine. It
+took some time in the past to meet its required semantics. Therefore,
+backporting some header definitions and a few architecture-dependent functions
+seemed more attractive. Luckily, it turned out to be the right decision, and
+after a day of backporting work, the file system could run on ARMv8.
+
+Display engine
+==============
+
+One of the more challenging tasks was certainly the enabling of the Display
+Controller Subsystem (DCSS) of the i.MX 8M SoC. Originally, we hoped to profit
+from our experiences with the Image Processing Unit (IPU), the display engine
+of former i.MX SoCs. But as it turned out, the DCSS is a completely new
+design, and has not much in common with the IPU. When first writing a driver
+for the IPU of the i.MX53, we were surprised by the complexity and flexibility
+of this piece of hardware. Back then, it took months to get something
+meaningful working. To not lose too much time by re-implementing a driver from
+scratch, we decided to take the DDE Linux approach, which worked out pretty
+fast. The resulting driver should provide the same flexibility like the Linux
+original one. However, as the i.MX 8M EVK board provides a HDMI connector
+only, we did not test more than that. The configuration of the driver is
+analogous to the Intel framebuffer driver, and looks like the following:
+
+! <config>
+!   <connector name="HDMI-A-1" width="1920" height="1080" hz="60" enabled="true"/>
+! </config>
+
+Later, when using the driver in practice within the Sculpt OS, we could
+experience a slightly sluggish behaviour, which was due to a missing
+architectural back end of the blitting library of Genode. After tweaking this
+too, the graphical user interface experience was good.
+
+
+USB and Input
+=============
+
+The last missing I/O device to run Sculpt OS on the ARMv8 was something for
+user generated input. Therefore, the existent USB host controller driver for
+the i.MX series got updated. The only roadblock here was the powering of the
+device. As there is no platform driver for the target hardware yet, which
+would manage power and clocks, the hardware either has to be pre-configured
+correctly, or the driver has to enable it on its own. Ethernet card, SD-card,
+and the display engine were all already powered by the bootloader, but not
+USB. In contrast to the first devices, the u-boot bootloader turns off USB
+explicitly as soon as it starts the OS. As an interim solution, we patched
+u-boot to not turn off the USB host controller, and enforced u-boot to
+initialize the powering in our boot scripts. Therefore, if one wants to use
+USB on the i.MX 8M EVK, make sure to take our modified version. As a
+convenient solution, you can use the 'uboot' port within the base repository.
+Just issue the following command in the Genode directory:
+
+! tool/ports/prepare_port uboot
+
+Finally, you have to copy u-boot to the SD-card as root user:
+
+! dd if=`tool/ports/current uboot`/imx8q_evk/imx-mkimage/iMX8M/flash.bin \
+!    of=/dev/sd<?> bs=1k seek=33 conv=fsync
+
+Of course, you have replace 'sd<?>' with the correct device node of your
+attached SD-card.
+
+After enabling the USB host controller driver, we could successfully re-use the
+USB HID client driver to drive keyboard and mouse connected to the board. As a
+nice side-effect, the list of possible storage devices got extended with USB
+mass storage too by adding the USB block client driver.
+
+
+Missing libraries
+=================
+
+Finally, when building the necessary and optional packages for Sculpt OS, we
+stumbled across several libraries that needed to be adapted to compile and
+link for ARMv8 too. Mostly, the inclusion of some other compilation units and
+headers was sufficient. The related libraries are: libssl, libcrypto, libpng,
+and Mesa. With the latter two, it is now even possible to execute Qt5
+components on the target hardware.
+
+Apart from all the new driver components and extended libraries, the Sculpt
+manager had to be slightly modified to execute on the i.MX 8M hardware. In its
+original form it is inherently dependent on x86 drivers, as it for example
+generates configurations for some of those drivers. For the time being, the
+changes to the Sculpt manager are not yet part of the official release.
+Nevertheless, you can produce a Sculpt OS image to be run on an i.MX 8M EVK
+board by using the following
+[https://github.com/skalk/sculpt_20.02_imx8q_evk/ - topic branch].
+
+Alternatively, you can also have a look at Sculpt OS on ARMv8 hardware by
+following the video recordings of the following talk at FOSDEM 2020.
+
+:Live demonstration of Sculpt OS on i.MX 8M EVK at FOSDEM 2020:
+
+  [https://fosdem.org/2020/schedule/event/uk_genode_armv8/]
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+New sandbox library based on the init component
+===============================================
+
+The init component is Genode's canonical mechanism for the composition of
+components. This role was further amplified when init became
+[https://genode.org/documentation/release-notes/17.02#Dynamically_reconfigurable_init_component - dynamically reconfigurable].
+The latter change cleared the ground for system scenarios like Sculpt OS, the
+on-target deployment of packages, and dynamic device discovery. One typical
+pattern found in such scenarios is one dynamically configured instance of init
+accompanied by a controlling component that is usually called "manager". The
+manager would consume reports of the subsystem hosted within the dynamic init,
+and adjust the init configuration according to a domain-specific policy. Such
+a configuration change, in turn, may trigger new reports, which effectively
+turns this setting into a feedback control loop.
+
+Whereas this established pattern is suitable for many scenarios, it is not
+always natural. In particular if the manager does not only need to
+manage a subsystem but also wants to intercept a service used by the
+subsystem, the roles are no longer clear-cut. A practical example is a
+GUI application that employs the menu-view component for the GUI rendering
+while processing keyboard events locally. This application would need to
+intercept the menu-view's GUI session to obtain the stream of user input
+events. For such an application, the most natural approach would be the
+co-location of the init functionality with the application logic into a
+single all-encompassing component.
+
+To accommodate such scenarios where a domain-specific management component is
+tightly coupled with a dynamic subsystem, we extracted the child-management
+functionality from the init component into a new library called "sandbox". The
+library API is located at
+[https://github.com/genodelabs/genode/blob/master/repos/os/include/os/sandbox.h - os/include/os/sandbox.h].
+
+In addition to the hosting of components, the sandbox API also allows for the
+interaction with the sandboxed children by providing locally implemented
+services. The latter mechanism is illustrated by a new test available at
+_os/src/test/sandbox_.
+
+
+POSIX compatibility improvements
+================================
+
+During the release cycle of Genode 20.02, we continued our mission to host
+POSIX software effortlessly as Genode components. In particular, we followed
+up the line of work pursued with the two previous releases
+[https://genode.org/documentation/release-notes/19.08#Consolidation_of_the_C_runtime_and_Noux - 19.08] and
+[https://genode.org/documentation/release-notes/19.11#C_runtime_with_improved_POSIX_compatibility - 19.11]
+with respect to the traditional Unix mechanisms fork, execve, and pipes.
+After covering several edge cases - cloexec, file-descriptor lifetimes,
+line-buffer handling, vfork, just to name a few - as needed by programs like
+make, bash, and tclsh, we eventually reached a state where the website
+generator of [https://genodians.org] works without the need for the now
+deprecated Noux runtime.
+
+For years we have been running complex software stacks like the Qt-based web
+browser on top of our C runtime but not without carefully placed tweaks and
+occasional patches. With the current release, we address the area of
+concurrency and introduce a thorough reimplementation of the synchronization
+primitives namely POSIX mutexes and condition variables as well as semaphores.
+We also reaped the fruit of our labor by replacing our custom Qt thread back
+end by the standard POSIX-thread based implementation. Further, we reduced the
+number of threads in Qt applications by moving the QPA event handling to the
+component entrypoint and removing the timed-semaphore utility from LibC.
+
+Beyond Qt, we also address synchronization issues revealed by running a
+third-party port of [https://grpc.io/ - gRPC] in our network back ends and
+amended thread-local errno in the C runtime. Finally, our POSIX thread
+implementation supports cleanup handlers now.
+
+
+Base-framework refinements
+==========================
+
+Replacing the 'Lock' type by new 'Mutex' and 'Blockade' types
+-------------------------------------------------------------
+
+Up to now, Genode's lock implementation supports mainly two flavour of usage.
+On the one hand, it is used to protect critical sections where the lock is
+initialized as unlocked. In the contention case, the lock holder is supposed
+to release the critical section. On the other hand, the lock is used as
+blockade to synchronize startup between various executions of threads. Here
+the lock is initialized as locked during instantiation whereby the thread that
+releases the lock is not necessarily the same thread as the creator of the
+lock.
+
+We decided to make the two usage pattern more obvious by introducing two
+separate classes, called 'Mutex' and 'Blockade'. The reasons are two fold.
+First, during code review, the usage pattern at hand becomes more obvious.
+Second, by codifying the programmer's intent behind the use of a
+synchronization primitive, Genode becomes able to perform additional checks,
+and diagnose certain dead-lock situations and other usage errors on the spot.
+
+The separation got introduced shortly before this release. Up to now, it is
+only used in 'Genode::Thread', 'Genode::Heap', and 'Genode::Registry'. The
+plan is to cultivate the usage across all Genode sources over the next
+releases and to ultimately remove the 'Genode::Lock' from the public API.
+
+The 'Mutex' class is more restrictive compared to the 'Lock' class.
+
+* At initialisation time, it is always unlocked.
+* To enter and leave a critical section the methods 'acquire()' and
+  'release()' are used.
+* A 'Mutex::Guard' is provided, which will 'acquire()' a mutex at
+  construction time and release it automatically at destruction time of
+  the guard.
+* No thread is permitted to lock twice. The code will generate a warning if
+  a dead-lock is detected.
+* Only the lock holder is permitted to release the mutex. The code will
+  generate a warning and will not release the mutex if this rule is violated.
+
+! Genode::Mutex mutex;
+! mutex.acquire();
+! mutex.release();
+!
+! {
+!   Genode::Mutex::Guard guard(mutex) /* acquire() during construction */
+! }                                   /* release() on guard object destruction */
+!
+! Genode::Mutex::Guard guard(mutex);
+! mutex.acquire();                    /* <-- Will cause a warning about the dead-lock */
+
+The 'Blockade' class is always initialized as locked and provides the methods
+'block()' and 'wakeup()'. Beside the initialization aspect, the 'Blockade'
+behaves up to now like the 'Genode::Lock' implementation.
+
+! Genode::Blockade blockade;
+!
+! /* step */    /* thread A */        /* thread B */
+! 0:            -start thread B-
+! 1:            ...                     -startup-
+! 2:            blockade.block();       ...
+! 3:            -sleep-                 ...
+! 4:            -sleep-                 blockade.wakeup();
+! 5:            ...                     ...
+
+
+Performance optimization of the XML parser
+------------------------------------------
+
+Genode's XML parser used to rely on C++ exceptions while parsing, which is an
+almost historic artifact inherited from the initial implementation. The
+performance penalties of exceptions in the rare use of XML was acceptable
+back when we started. But modern Genode systems like Sculpt OS rely on the
+dynamic processing of XML like a back bone. The overhead became particularly
+apparent when executing [Sculpt OS on 64-bit ARM i.MX8 hardware]. Prompted by
+this observation, we reworked the code such that exceptions are no longer
+thrown in any hot code path. The public interface of 'Xml_node' remains
+unchanged.
+
+
+New polling variant for register framework
+------------------------------------------
+
+Genode's register framework has offered a 'wait_for' method for a long time.
+This function sleeps for a certain amount of microseconds and checks if one or
+more given conditions become true. The number of attempts to sleep and check
+the conditions must also be specified. In case the conditions are not met
+after these attempts, a polling timeout exception is thrown. The function
+simply returns in case of success. With the current Genode release, we have
+added a 'wait_for_any' method with almost the same semantics but instead of
+waiting for all conditions to become true, it returns if any condition is
+meet, and thus, implements a logical OR.
+
+
+Migration to modern block-device API
+====================================
+
+With release 19.02, Genode introduced two new APIs for block-session handling.
+The client side of a block session now uses the job API in order to send block
+requests to the server, which in turn receives those jobs as requests through
+the Request API. These two APIs replace Genode's 'Block::Driver' and
+'Block::Session_component' implementations that used the packet stream API
+directly, which turned out to be error prone for block session implementations.
+Instead, these new APIs wrap the packet stream handling in a controlled
+manner while handling all corner cases and even the overcommit of packets.
+With the current release, we have adapted Genode's AHCI driver and partition
+manager to these new interfaces, with the plan to adjust all block session
+clients/servers to the new APIs with Genode release 20.05.
+
+During this line of work, the AHCI driver received a major cleanup. For
+example, dynamic memory allocations were removed, the whole initialization
+state machine has been removed, ATAPI support for Qemu has been re-enabled,
+and Exynos5 AHCI support is gone - since the platform is outdated and not
+supported by Genode any more.
+
+
+Updated audio driver based on OpenBSD 6.6
+=========================================
+
+In this release, we updated the 3rd-party sources of the audio driver component
+to OpenBSD 6.6 and adapted the emulation glue code. While doing so, we fixed
+a bug regarding the 'delay()' implementation where the function expects
+microseconds but was given milliseconds. This led to a increased start-up
+time of the component. We also fixed the logging back end that accidentally
+was rendered silent and brought in the 'printf' back end from DDE Linux to
+be able to produce better formatted LOG messages in the future.
+
+Until now the component only supported HDA and EAP (ES1370 PCI) devices. The
+first is primarily intended to be used with real hardware wheres the latter
+was used during the initial porting effort in Qemu. That being said, the EAP
+driver apparently also works on hardware according to community feedback.
+
+Since the HDA driver does not work when used in VirtualBox and users expressed
+the desire to also use audio when running in a VM, we enabled another driver,
+for which a device-model in VirtualBox exists: the AC97 ICH. As it turned out,
+using this driver, we can produce audio, albeit the quality is far from
+usable. Nevertheless, with the driver enabled, interested parties are free to
+investigate the cause for the current issues.
+
+All in all, this update is solely a catch up effort to stay more
+update-to-date with the upstream changes and to pull in HDA quirks for more
+recent systems. More interesting changes to the driver component, like
+reworking the OpenBSD kernel emulation layer and bringing support for USB
+audio devices, are scheduled for future releases.
+
+
+Support for unlabeled LOG output
+================================
+
+In situations where a Genode system is remotely controlled and monitored,
+it is useful to allow a special component to produce log output with no
+Genode label applied. This way, such a component can produce log data in
+a format that is immediately suitable for a controller. This feature can be
+enabled for a component by rewriting the label of the component's LOG session
+to "unlabeled".
+
+! <route>
+!   <service name="LOG"> <parent label="unlabeled"/> </service>
+!   ...
+! </route>
+
+
+Libraries and applications
+##########################
+
+Custom virtual machine monitor on ARM
+=====================================
+
+The ARMv8-compliant virtual-machine monitor introduced in the previous release
+19.11 now contains new device models to enable the interaction with a
+virtual-machine via network and terminal services. The new virtual ethernet
+card and console implementations are compliant to the virtualization standard
+VIRTIO 1.1.
+
+Currently, the VMM cannot be configured to contain specific devices. It is
+hard-wired to provide exactly:
+
+* One virtual ethernet card that connects to Genode's "Nic" service,
+* A VIRTIO console that opens up a session to the "Terminal" service using the
+  label "console", and
+* The traditional PL011 serial device model, which connects to a
+  "Terminal" service too but uses the label "earlycon"
+
+
+Seoul VMM
+=========
+
+During the usage of Seoul on Sculpt, it became apparent that the Seoul VMM
+caused a constant CPU load even when the guest VM was idling. After some
+investigation it became clear that having a fixed rate to synchronize the
+guest graphic memory with the Genode GUI service was the main reason for the
+constant load. With this release, we added the feature to dynamically adjust
+the GUI refresh rate depending on the rate of user interactivity.
+Additionally, if all virtual CPUs go to idle state, the GUI refresh is stopped
+completely. With these measures, the overall CPU load could be reduced
+noticeable.
+
+
+TCP terminal
+============
+
+The TCP terminal is a long-living component in the Genode OS framework since
+release 11.11. It can be used, e.g., to connect to a headless Genode system
+via telnet. Until now, it always listened to incoming network connections at
+configured ports. The port had to be configured for each terminal session
+client.
+
+The TCP terminal got extended to either listen to incoming network
+connections, or to directly connect to another network server, dependent on
+the policy defined for the corresponding terminal client. The following
+example configuration illustrates the differences:
+
+! <config>
+!   <policy label="client" ip="10.0.0.5" port="1234"/>
+!   <policy label="another_client"       port="4567"/>
+! </config>
+
+If only a port is described in the policy, the TCP terminal will listen on
+that port for incoming connections. If an IP address is provided additionally,
+it connects to the IP address using the given port.
+
+
+Virtual desktops
+================
+
+Genode's GUI stack enables a high degree of flexibility. Beside the fundamental
+nitpicker component, responsible for basically multiplexing input events and
+framebuffer content, there is the window-manager component, and example
+implementations of a window-layouter, and decorator. The interplay of the
+latter three allows a window management that scales from simple to rich and
+sophisticated without lowering its security properties. For a brief description
+of its architecture, please refer to the release notes of
+[http://genode.org/documentation/release-notes/14.08 - 14.08].
+
+In this architecture, the window layouter is responsible for the arrangement
+of the different windows. It exports a data model of the window layout.
+Although, the example implementation of the window layouter introduced in
+14.08 was simple, it already contained a notion of having different virtual
+screens and screen sections, beside the actual window placements. However,
+until now there was no use-case of switching dynamically in between different
+virtual screens respectively window sets related to them.
+
+While using more and more different graphical components within Sculpt, the
+window layouter in its initial form hit a limit. Although it already allowed to
+switch in-between different windows via configured key-combinations, it became
+inconvenient when having more than a handful windows hiding each other.
+
+Therefore, the window layouter now got extended to allow switching dynamically
+in between several pre-defined virtual screens. For the time being, one has to
+assign a new window to a screen in the rule-set of the window layouter
+initially by hand. Defining the currently visible screen can either be done by
+editing the rule-set, or by using pre-configured key-combinations.
+
+The new default configuration of the window layouter as exported by its
+corresponding depot package looks like the following:
+
+! <config rules="rom">
+!   <rules>
+!     <screen name="screen_1"/>
+!     <screen name="screen_2"/>
+!     <screen name="screen_3"/>
+!     <screen name="screen_4"/>
+!     <screen name="screen_5"/>
+!     <screen name="screen_6"/>
+!     <screen name="screen_7"/>
+!     <screen name="screen_8"/>
+!     <screen name="screen_9"/>
+!     <screen name="screen_0"/>
+!     <assign label_prefix="" target="screen_1" xpos="any" ypos="any"/>
+!   </rules>
+!
+!   <press key="KEY_SCREEN">
+!     <press key="KEY_ENTER" action="toggle_fullscreen"/>
+!     <press key="KEY_1"     action="screen" target="screen_1"/>
+!     <press key="KEY_2"     action="screen" target="screen_2"/>
+!     <press key="KEY_3"     action="screen" target="screen_3"/>
+!     <press key="KEY_4"     action="screen" target="screen_4"/>
+!     <press key="KEY_5"     action="screen" target="screen_5"/>
+!     <press key="KEY_6"     action="screen" target="screen_6"/>
+!     <press key="KEY_7"     action="screen" target="screen_7"/>
+!     <press key="KEY_8"     action="screen" target="screen_8"/>
+!     <press key="KEY_9"     action="screen" target="screen_9"/>
+!     <press key="KEY_0"     action="screen" target="screen_0"/>
+! ...
+
+As can be seen, individual keys are assigned to switch to a specific virtual
+screen. By default ten screens are defined that are accessible via the number
+keys. The first screen definition in the rules configuration marks the
+currently visible screen.
+
+
+Menu-view widget renderer
+=========================
+
+The line of work described in Section
+[Redesign of the administrative user interface of Sculpt OS] called for
+the enhancement of Genode's GUI-rendering component. This component - named
+menu view - was
+[https://genode.org/documentation/release-notes/14.11#New_menu_view_application - originally introduced in Genode 14.11]
+for the rendering of the relatively simple menus of an application launcher.
+Its software design largely deviates from the beaten track of established
+widget toolkits, which come in the form of client-side libraries. The
+menu view is not a complete toolkit but solely a dialog renderer sandboxed
+in a dedicated component. This design reinforces the strict separation of the
+view from the application logic, fosters screen-resolution independence, and -
+most importantly - keeps the complexity of pixel processing out of the
+application program. Because of the latter, it lends itself to the
+implementation of security-sensitive interactive applications.
+
+It would certainly be misguiding to tout our menu-view as feature competitive
+with existing toolkits. We certainly won't recommend using it over Qt in
+general. But Sculpt's custom administrative user interface "Leitzentrale"
+presented us with the perfect playground to explore and grow the potential of
+our novel approach.
+
+In contrast to the previous iteration of the Leitzentrale GUI, which relied on
+a small Unix runtime and Vim for editing text files, the new version ought to
+feature a simple text editor integrated in the GUI. A text editor requires
+a much tighter interplay between the view and the actual program logic
+compared to an application with just a bunch of buttons. Think about cursor
+handling, scrolling text, displaying textual selections, or placing a text
+cursor with the mouse. On the course of the work towards the text-area
+component featured in the new Leitzentrale, the menu view received the
+following improvements:
+
+:Text-cursor support:
+
+  The label widget gained the ability to display one or multiple text cursors,
+  as illustrated by the following example:
+
+  ! <label text="...">
+  !   <cursor at="10"/>
+  ! </label>
+
+  For the display of multiple cursors, each cursor must feature a distinctive
+  'name' attribute.
+
+:Character position featured in the hover report:
+
+  The hovering information provided by the menu view used to be at the
+  granularity of widgets, which is insufficient for placing a text cursor with
+  the mouse. Hence, the information of a hovered label additionally provides
+  the character position within the label now.
+
+:Unquoting label text attribute values:
+
+  The text displayed in label widgets is provided by a 'text' attribute value,
+  which raises the question of how to present '"' characters on the GUI. With
+  the new version, the attribute value can contain XML-quoted characters,
+  specifically "&quot;".
+
+:Support for displaying text selections:
+
+  Similarly to the way of how a <cursor> can be defined for a <label>
+  widget, a selection can now be expressed as follows:
+
+  ! <label ...>
+  !   <selection at="2" length="12"/>
+  ! </label>
+
+:Support of multiple '<float>' widgets within a '<frame>':
+
+  We refined the hover reporting of <float> widgets such that a float widget
+  never responds to hovering unless a child is hovered. This way, it becomes
+  possible to stack multiple float widgets within one frame and still reach
+  all child widgets. This is useful for aligning multiple widgets within one
+  screen area independently from each other. For example, for left-aligning,
+  centering, and right-aligning the elements of a panel.
+
+:Enforcing the minimum size of a label:
+
+  The new '<label min_ex="..">' attribute can be used to enforce a minimum
+  width in the unit of the size of the character 'x'. In the absence of a
+  'text' attribute, the minimum height of a label is implicitly set to 0. The
+  combination of both changes makes the label usable as a horizontal spacer.
+
+:Basic support for styling labels:
+
+  The new version allows for the customization of the text color and alpha
+  value of the label widget by the means of a style-definition file. The
+  mechanism is exemplified with the new "invisible" label style that sets the
+  alpha value to zero.
+
+With these few incremental changes in place, the menu-view widget renderer
+becomes usable as the basis of the simple text editor used in Sculpt's new user
+interface.
+
+
+Self-hosting the tool chain on 64-bit ARM
+=========================================
+
+With our ongoing ARM 64-bit effort, we have successfully updated Genode's tool
+chain with release
+[https://genode.org/documentation/release-notes/19.05#Broadened_CPU_architecture_support_and_updated_tool_chain - 19.05].
+With the current release, we have additionally managed to make Genode's tool
+chain self hosting on ARM 64-bit, which means the tool chain can compile
+source code on ARM 64-bit directly.
+
+
+Platforms
+#########
+
+Execution on bare hardware (base-hw)
+====================================
+
+The generic code base of the base-hw kernel underwent several cosmetic changes
+to reduce or eliminate the application of certain problematic constructs like
+too much inheritance, pointers, and dynamic casts. Those changes were
+motivated to ease the translation of several kernel parts to the Ada/SPARK
+language in the context of the Spunky project. For more information regarding
+this experiment to write a Genode kernel in Ada/SPARK, please have a look at
+the recent [https://genodians.org/m-stein/index - genodians.org article series]
+of Martin Stein or listen to his recent
+[https://video.fosdem.org/2020/AW1.125/ada_spunky.mp4 - FOSDEM talk].
+
+Moreover, the IPC path implementation got simplified to lower the overhead
+costs introduced by the transfer of capabilities. Together with the mentioned
+Spunky cleanup efforts, this change measurably improved IPC performance.
+
+The base-hw kernel now exports time consumption of individual threads via
+the trace service analogously to the implementation for NOVA. Thereby, it
+becomes possible to use for instance the top component within the Sculpt OS
+also on this kernel.
+
+Until now, support for the Raspberry Pi 3 was limited to Qemu emulation only.
+Thanks to a contribution of Tomasz Gajewski, it is now possible to execute
+Genode on all four CPUs of the actual hardware concurrently.
+
+
+Execution on Linux
+==================
+
+Traditionally, the Linux version of Genode serves us as very handy development
+vehicle but it was never intended as an actual target platform. On Linux,
+Genode is usually executed as a multi-process application on top of a regular
+GNU/Linux desktop distribution by specifying 'KERNEL=linux' and 'BOARD=linux'
+to the run tool.
+
+However, thanks to the work of Johannes Kliemann, Genode has become able to
+run on a bare-bone Linux kernel without any other user land.
+We blatantly used to refer to this idea as the
+[https://genode.org/about/challenges#Platforms - microkernelization of Linux].
+Johannes picked up the idea, supplemented Genode's core with the services
+needed for user-level device drivers (IRQ, IOMEM, IOPORT) and supplemented
+the tooling for the integration of Genode scenarios into a bootable initrd
+image. This target of execution can be addressed by specifying 'KERNEL=linux'
+and 'BOARD=pc' to the run tool now. If specified, the run tool will produce a
+bootable Linux system image for the given run script and run it in Qemu.
+
+That said, as this line of work is still considered as an experimental
+playground - not for productive use - the work flow is not entirely automated.
+In particular, one needs to prepare a suitable
+[https://github.com/jklmnn/linux/commits/genode - Linux kernel] manually.
+If you are interested in the topic, please refer to the background information
+given in the [https://github.com/genodelabs/genode/pull/2829 - issue tracker].
+

doc/road_map.txt

@@ -14,122 +14,121 @@ The road map is not fixed. If there is commercial interest of pushing the
 Genode technology to a certain direction, we are willing to revisit our plans.
 
 
-Review of 2018
+Review of 2019
 ##############
 
-Sculpt is our take on creating a Genode-based general-purpose operating
-system. When we declared 2018 as Genode's Year of Sculpt one year ago, our
-vision of how Sculpt OS would shape up was still vague. We were convinced that
-we had - functionality-wise - all building blocks of a general-purpose OS in
-place. But it was rather unclear how to best put them together to attain a
-practical system. The unconquered design space seemed vast, which was both
-exciting but also - at times - a bit paralyzing.
+For the road map 2019, we picked "bridging worlds" as our guiding theme:
+(1) Lowering the friction when combining existing software with Genode,
+(2) Fostering interoperability with widely used protocols and APIs, and
+(3) Making Genode easier to approach and generally more practical.
 
-The Year of Sculpt was more than anything a design-space exploration, not
-an up-front planned activity. The process was driven by intensive
-brainstorming, experimentation, and the continuous practical evaluation
-through the day-to-day use of the system by its developers. For us, this ride
-was certainly the most rewarding period in Genode's history so far. Now, when
-looking at the result, we are proud about what we have achieved together.
-Whenever having the chance to showing off Sculpt running on our laptops,
-the system doesn't fail to impress.
+With respect to (1), we identified Genode's custom tooling (build
+system, run scripts, ports mechanism, depot tools) as a point of
+friction. They are arguably powerful and flexible but require a lot of
+up-front learning. This is certainly a burden unacceptable for a casual
+developer without a black belt in Make and Expect/Tcl. The new
+[https://genode.org/documentation/release-notes/19.11#New_tooling_for_bridging_existing_build_systems_with_Genode - Goa]
+tool rearranges the existing tools in a way that puts the concerns of casual
+developers into focus, allowing for the use of commodity build systems,
+eliminating Tcl syntax from the equation, running sub-second test cycles, and
+streamlining the packaging of software.
 
-Unsurprisingly, many topics of the past year had a direct connection to
-Sculpt, e.g., the NIC router, the huge device-driver efforts, the GUI-stack
-improvements, our custom microcode update mechanism, the software packaging
-and deployment, and the work on the file-system and networking stacks.
+On account of (2), we
+[https://genode.org/documentation/release-notes/19.05#Broadened_CPU_architecture_support_and_updated_tool_chain - switched to C++17]
+by default, fostered the use of
+[https://genodians.org/ssumpf/2019-02-27-java-19-02 - Java],
+updated Qt5, and put
+[https://genode.org/documentation/release-notes/19.11#C_runtime_with_improved_POSIX_compatibility - POSIX]
+compatibility into the spotlight. We were eventually able to dissolve the need
+for our custom Unix runtime (Noux) because all features of Noux are covered by
+our regular libc now.
 
-The bottom line of the Year of Sculpt is that Sculpt OS has become a
-surprisingly versatile and robust system. It can be deployed in a few seconds
-by booting from USB, runs as day-to-day OS on almost all of our laptops, its
-mechanisms for installing and updating software from packages have become a
-second nature, and it continues to inspire us to explore new application
-areas. Even outside of Genode Labs, there is a small and enthusiastic user
-base.
+Our biggest step towards (3) is the [https://genodians.org] website we
+started in winter 2019, which gives individual members of our community
+an easy way to present thoughts, projects, and experiences.
+Complementing Genode's formal documentation, it also conserves practical
+tips and tricks that were previously not covered in written form.
 
-Besides Sculpt, we set forth a number of other goals one year ago.
+When speaking of "bridging worlds", we should not forget to mention the
+tremendous effort to bring Sculpt-OS-like workloads to the 64-bit ARM world.
+Thanks to the added support for
+[https://genode.org/documentation/release-notes/19.08#64-bit_ARM_and_NXP_i.MX8 - multi-core AARCH64],
+hardware-based
+[https://genode.org/documentation/release-notes/19.11#Virtualization_of_64-bit_ARM_platforms - virtualization],
+and network/USB/graphics drivers for the i.MX8 SoC, the flexibility of Sculpt
+OS will eventually become available on PC hardware and ARM-based devices
+alike.
 
-:The transition from NOVA to our custom kernel and seL4: is ongoing but
-  the topic received less attention than originally planned. This has
-  two reasons. First, Alexander Boettcher's excellent maintenance and gradual
-  improvement of NOVA keeps us hooked. Over the past year, there has been not
-  much incentive of actual Sculpt users to move away from NOVA. Second, there
-  is renewed interest in NOVA beyond our use of the kernel. Most specifically,
-  we started joining forces with
-  [https://cyberus-technology.de - Cyberus Technology] to improve NOVA
-  together. That's fantastic!
-
-  This development notwithstanding, we still follow our ambition to bring the
-  support for the other kernels like seL4 on par with NOVA to give Genode
-  users the ultimate choice.
-  Speaking of seL4, throughout the year, we have continuously adapted Genode
-  to the kernel's upstream development and enjoy the informal collaboration
-  with seL4 developer community. That said, the seL4 version of Genode still
-  remains a side activity with no commercial backing.
-
-:NXP i.MX: support has become much better, particularly with respect to
-  network support and performance. Our ongoing commitment to the i.MX
-  platform is also fueled by privacy-advocating projects like the Librem
-  phone that are based on the same SoC.
-
-:Software quality and resilience: ultimately became the title story of the
-  [https://genode.org/documentation/release-notes/18.11#Raising_the_bar_of_quality_assurance - release 18.11].
-  We greatly intensified the amount and quality of testing, explored static
-  code analysis, and vastly scaled up the complexity of workloads carried
-  by Genode.
-
-:System monitoring, tracing, profiling: remains a somewhat underdeveloped area
-  of Genode. As a step in the right direction, we introduced a simple
-  trace-logging tool. Also, Sculpt's introspection features like the ability
-  to inspect the runtime's state live on the machine make Genode's behavior
-  easier to capture and to understand. But that said, the use of these
-  features remains a black art mastered only by a few.
-
-:Java: has found its way into Genode via our port of OpenJDK. Details such as
-  the enabling of the JIT engine on ARM took much more effort than anticipated.
-  We are happy to report that Tomcat works fine. But at the current state, it
-  is still too early to advertise Java as a stable feature.
+Over the course of 2019, we admittedly skipped a few topics originally
+mentioned on our road map. In particular, the user-visible side of
+Sculpt OS received less attention than originally envisioned. We also
+deferred several ideas we had in mind about reworking our GUI stack.
+Instead, we expanded our work in the areas of storage (block-level APIs,
+test infrastructure,
+[https://genode.org/documentation/release-notes/19.11#Preliminary_block-device_encrypter - block encryption])
+and
+[https://genode.org/documentation/release-notes/19.08#Flexible_keyboard_layouts - input processing].
+This shift of focus is mostly attributed to the priorities of Genode Labs'
+customers who fund our work.
 
 
-2019 - Bridging Worlds
-######################
+2020 - Dwarfing the barrier of entry
+####################################
 
-We dedicated the year 2018 to prove that Genode scales to general-purpose
-computing. [https://genode.org/download/sculpt - Sculpt OS] leaves no doubt
-about that. The logical next step is to make Sculpt OS relevant and appealing
-for a broader community.
-During our public road-map
-[https://lists.genode.org/pipermail/users/2018-December/006517.html - discussion]
-on our mailing list, we identified three ways towards that goal:
+Genode as a technology is there. For more than one decade, we walked unfathomed
+territory, fought with countless deep rabbit holes, took risky decisions,
+tracked back, explored design spaces, developed taste and distaste, pruned
+technical debt, and eventually found formulas of success. Today, there are no
+(fundamental) unsolved questions. All the puzzle pieces are in place. There
+could be no better proof than our daily use of Sculpt OS. The time is right
+to make Genode palatable for a wider circle. We identified four actionable
+topics to achieve that.
 
-# In order to capture the interest of new Genode users, we have to
-  put *emphasis on the practical use* of Genode, not on its technical prowess.
-  With practical use, we refer to both desktop computing and headless
-  scenarios like network appliances and servers. Over the course of 2019,
-  we plan to establish (variations of) Sculpt as an attractive foundation for
-  those application areas, and advance Genode's protocol stacks (storage and
-  encryption come in mind) and hardware support (e.g., ARM 64-bit) accordingly.
+:User friendliness of Sculpt OS:
 
-  This will go hand in hand with making Genode easier to discover and to use,
-  describing use cases at a digestible level of detail, and fostering the
-  sense of one community that includes both users and developers.
+  Until now, Sculpt OS is not exactly friendly towards users who are
+  unfamiliar with the Unix command-line tools. Since Sculpt is not Unix
+  based, this is a bit paradoxical. 2020 will give Sculpt OS a friendlier
+  and discoverable user experience. In this context, we will inevitably
+  put our attention to Genode's GUI stack.
 
-# Since an operating system is only valuable with applications, we have
-  to make the *porting of existing software* and the use of popular
-  *programming languages* a frictionless experience. Besides supporting the
-  reuse of existing software, we should also cultivate the "Genode way" as
-  an option for designing native applications. Such applications can
-  leverage the unique capabilities of the framework, in particular the
-  sandboxing of code at a very fine granularity and the low footprint of raw
-  Genode components.
+:Perception of high quality:
 
-# Because an operating system does not exist in isolation, we must foster
-  Genode's *interoperability* with other systems and applications by speaking
-  widely used protocols and supporting universally expected
-  software-integration features.
+  Compared to commodity operating systems who stood the test of time,
+  Genode is a young and largely unproven technology. It understandably calls
+  for skepticism. All the more we must leave no doubts about our high
+  quality standards. There must be no room for uncertainty. Hence, during
+  2020, we will intensify the consolidation and optimization of the framework
+  and its API, and talk about it.
+
+:Enjoyable tooling:
+
+  Genode's success at large will depend on developers. As of today, software
+  development for Genode requires a huge up-front learning curve. This is
+  fine for people who are already convinced of Genode. But it unacceptable
+  for casual developers who want to get their toes wet. We should aim for
+  tooling that allows new developers to keep up their flow and beloved
+  tools. The recently introduced [https://genodians.org/nfeske/2019-11-25-goa - Goa]
+  tooling is our first take in this respect. It is certainly too early to call
+  Goa a success. In order to find out if we are on the right track, we want to
+  expose Goa to as many problems as possible, primarily by the means of
+  porting software. Also, things like IDE usage or adapters for a variety of
+  build systems will certainly move into focus in 2020.
+
+:Convincing use cases:
+
+  Use cases can give exemplary proof of the fitness of Genode. We already
+  took a few baby steps to extend the range of documented use cases beyond
+  Sculpt OS last year. The boot2java scenenario comes in mind. 2020 will
+  hopefully see several more illustrations of Genode's versatility.
 
 
-Milestones for 2019
+Apart from this overall theme, we plan to continue our commitment to the
+NXP i.MX SoC family, revisit Genode's low-latency audio support, and
+extend the cultivation of Ada/SPARK within (and on top of) Genode.
+
+
+Milestones for 2020
 ###################
 
 In the following, we present a rough schedule of the planned work. As usual,
@@ -137,57 +136,64 @@ it is not set in stone. If you are interested in a particular line of work,
 please get in touch.
 
 
-February - Release 19.02
+February - Release 20.02
 ========================
 
-* OpenJDK with JIT on ARM and x86
-* Sculpt with support for online package discovery
-* Showcase of a Genode-based web appliance
-* Showcase of a multi-port network appliance
+* Consolidation: removal of the Noux runtime
+* Library version of the init component
+* Updated audio drivers
+* Sculpt
+  * 64-bit ARM (i.MX8)
+  * Revised administrative user interface
+  * System image without Unix tools
 
 
-May - Release 19.05
+May - Release 20.05
 ===================
 
 * Updated "Genode Foundations" book
-* Tool-chain update and SDK (C++-17, enabling O3 by default, considering GDC)
-* Headless Sculpt
-  * Pluggable network drivers
-  * Native support for Let's Encrypt certificates
-* Revisited GUI-related framework interfaces
+* Consolidation
+  * Block-level components (update to Genode's modern block APIs)
+  * ARM device drivers (introducing the notion of a platform driver)
+  * Improved STL support (e.g., threading and mutexes)
+  * Continuous POSIX-compliance testing
+  * Systematic network-stack stress and performance tests
+* Desktop: panel and virtual desktops
+* Use case: Genode-based network router
+* Goa: broadened support for 3rd-party build systems
+* Native tool chain, including Git
 * Sculpt
-  * Improved interactive system composition
-  * Passphrase handling
-  * Clipboard support
-* Kernel-agnostic virtual-machine monitors
-* ARM 64-bit
+  * Interactive device management
+  * Keyboard-controlled administration
+* Support for BSPs maintained outside of Genode's mainline repository
 
 
-August - Release 19.08
+August - Release 20.08
 ======================
 
-* Interactive tracing tool
-* Virtualization support for the base-hw kernel on x86
-* Library version of the init component
+* Revisited GUI-related framework interfaces
+* Extended tooling for performance monitoring
+* Goa: Qt development workflow
+* Desktop
+  * Native mail client
+  * Native web browser
 * Sculpt
-  * Fine-grained USB-device policies
-  * Interactive depot manager (ability to add/remove software providers)
-  * Configuration of CPU affinities and scheduling priorities
-  * Audio
-* Showcase of a Sculpt-based network router
-* VM-based desktop applications (enhanced VM integration features)
-* Updated Qt5
-* Consolidation of the Noux runtime (performance)
+  * Configurable CPU resources
+  * On-screen documentation
+  * Block encryption via our
+    [https://genode.org/documentation/release-notes/19.11#Preliminary_block-device_encrypter - consistent block encrypter]
+    implemented in Ada/SPARK
+* USB audio
+* Initial version of a kernel implemented in Ada/SPARK
 
 
-November - Release 19.11
+November - Release 20.11
 ========================
 
-* Building Genode packages directly on Sculpt
-* VNC server support
-* Sculpt
-  * On-target debugging of components
-  * Shutdown protocol
-* Block-level encrypted storage
-* Drag-and-drop protocol
+* Consolidation of capability-space management across kernels
+* CPU-load balancing
+* Hardware-accelerated graphics on i.MX8 (experimental)
+* Reworked audio stack (interfaces, mixing)
+* Sculpt: component lifetime management, shutdown protocol
+* VFS plugins for lwext4 and FUSE-based file systems
 

repos/base-fiasco/lib/mk/base-fiasco-common.mk

@@ -10,5 +10,7 @@ LIBS += startup-fiasco syscall-fiasco
 
 SRC_CC += capability.cc capability_raw.cc
 SRC_CC += rpc_dispatch_loop.cc
+SRC_CC += rpc_entrypoint_manage.cc
 SRC_CC += thread.cc thread_bootstrap.cc thread_myself.cc
 SRC_CC += stack_area_addr.cc
+SRC_CC += rpc_entry.cc

repos/base-fiasco/lib/mk/base-fiasco.mk

@@ -6,3 +6,4 @@ SRC_CC += thread_start.cc
 SRC_CC += cache.cc
 SRC_CC += capability_space.cc
 SRC_CC += signal_transmitter.cc signal.cc
+SRC_CC += platform.cc

repos/base-fiasco/recipes/src/base-fiasco/hash

@@ -1 +1 @@
-2019-08-27 87228cf07e72e871410818fa83bdeef44c9f5ef8
+2020-02-27 6311f83c887384fa01828af695bae799b148e0ad

repos/base-fiasco/src/core/thread_start.cc

@@ -29,7 +29,7 @@ void Thread::_thread_start()
 {
 	Thread::myself()->_thread_bootstrap();
 	Thread::myself()->entry();
-	Thread::myself()->_join_lock.unlock();
+	Thread::myself()->_join.wakeup();
 	sleep_forever();
 }
 

repos/base-fiasco/src/lib/base/ipc.cc

@@ -201,16 +201,14 @@ void Genode::ipc_reply(Native_capability caller, Rpc_exception_code exc,
 	            snd_header.protocol_word,
 	            snd_header.num_caps,
 	            L4_IPC_SEND_TIMEOUT_0, &result);
-
-	if (L4_IPC_IS_ERROR(result))
-		error("ipc_send error ", Hex(L4_IPC_ERROR(result)), ", ignored");
 }
 
 
-Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &last_caller,
-                                           Rpc_exception_code      exc,
-                                           Msgbuf_base            &reply_msg,
-                                           Msgbuf_base            &request_msg)
+Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const         &last_caller,
+                                           Rpc_exception_code              exc,
+                                           Msgbuf_base                    &reply_msg,
+                                           Msgbuf_base                    &request_msg,
+                                           Rpc_entrypoint::Native_context &)
 {
 	using namespace Fiasco;
 
@@ -277,9 +275,10 @@ Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &last_caller,
 }
 
 
-Ipc_server::Ipc_server()
+Ipc_server::Ipc_server(Rpc_entrypoint::Native_context& native_context)
 :
-	Native_capability(Capability_space::import(Fiasco::l4_myself(), Rpc_obj_key()))
+	Native_capability(Capability_space::import(Fiasco::l4_myself(), Rpc_obj_key())),
+	_native_context(native_context)
 { }
 
 

repos/base-fiasco/src/lib/base/lock.cc

@@ -13,6 +13,7 @@
 
 /* Genode includes */
 #include <base/cancelable_lock.h>
+#include <base/thread.h>
 #include <cpu/atomic.h>
 #include <cpu/memory_barrier.h>
 
@@ -33,6 +34,13 @@ Cancelable_lock::Cancelable_lock(Cancelable_lock::State initial)
 
 
 void Cancelable_lock::lock()
+{
+	Applicant myself(Thread::myself());
+	lock(myself);
+}
+
+
+void Cancelable_lock::lock(Applicant &myself)
 {
 	/*
 	 * XXX: How to notice cancel-blocking signals issued when  being outside the
@@ -41,11 +49,14 @@ void Cancelable_lock::lock()
 	while (!Genode::cmpxchg(&_state, UNLOCKED, LOCKED))
 		if (Fiasco::l4_ipc_sleep(Fiasco::l4_ipc_timeout(0, 0, 500, 0)) != L4_IPC_RETIMEOUT)
 			throw Genode::Blocking_canceled();
+
+	_owner = myself;
 }
 
 
 void Cancelable_lock::unlock()
 {
+	_owner = Applicant(nullptr);
 	Genode::memory_barrier();
 	_state = UNLOCKED;
 }

repos/base-foc/lib/mk/base-foc-common.inc

@@ -10,6 +10,9 @@ LIBS += syscall-foc startup-foc
 
 SRC_CC += spin_lock.cc cap_map.cc
 SRC_CC += rpc_dispatch_loop.cc
+SRC_CC += rpc_entrypoint_manage.cc
 SRC_CC += thread.cc thread_bootstrap.cc thread_myself.cc utcb.cc
 SRC_CC += capability.cc
 SRC_CC += signal_source_client.cc
+SRC_CC += platform.cc
+SRC_CC += rpc_entry.cc

repos/base-foc/recipes/src/base-foc-arndale/hash

@@ -1 +1 @@
-2019-08-27 5b6cf80fc675be3f7432434e48f4f1548f55ef41
+2020-02-27 82bbd7275951340ff82061af8bc2cce41f1519e3

repos/base-foc/recipes/src/base-foc-imx6q_sabrelite/hash

@@ -1 +1 @@
-2019-08-27 a867f84460323da4f69d8159ff21200e50a9a2fd
+2020-02-27 c5602daf28cdc5d005a26f408527e64ab905197e

repos/base-foc/recipes/src/base-foc-imx7d_sabre/hash

@@ -1 +1 @@
-2019-08-27 e8b6d91bf19df090192d689a46f34570b43bc1bc
+2020-02-27 a3912478467dcf01ab6379502bb15719b748c388

repos/base-foc/recipes/src/base-foc-pbxa9/hash

@@ -1 +1 @@
-2019-08-27 07b6913f38716e380057df3212da94054a359bc8
+2020-02-27 e7f8bca57dbed6597e46aafd0256dfd5a6ac42c3

repos/base-foc/recipes/src/base-foc-pc/hash

@@ -1 +1 @@
-2019-08-27 2f2313ed4479d13b9f3964db6f7ceaaf2c12320a
+2020-02-27 b03dfe2bde7fe637c0a7eff9e709845e64b4d09c

repos/base-foc/recipes/src/base-foc-rpi3/hash

@@ -1 +1 @@
-2019-08-27 b248520f85bcf3d1dbe68e23ca949f447cd78dbb
+2020-02-27 a1eb6dfc01d82b598f0778c0b74f2a49387cc42d

repos/base-foc/src/core/include/vm_session_component.h

@@ -108,7 +108,7 @@ class Genode::Vm_session_component
 		void attach(Dataspace_capability, addr_t, Attach_attr) override;
 		void attach_pic(addr_t) override { }
 		void detach(addr_t, size_t) override;
-		void _create_vcpu(Thread_capability);
+		Vcpu_id _create_vcpu(Thread_capability);
 };
 
 #endif /* _CORE__VM_SESSION_COMPONENT_H_ */

repos/base-foc/src/core/ipc_pager.cc

@@ -36,7 +36,7 @@ void Ipc_pager::_parse(unsigned long label) {
 	if (_type == PAGEFAULT || _type == EXCEPTION)
 		_parse_pagefault();
 	if (_type == PAUSE || _type == EXCEPTION)
-		memcpy(&_regs, l4_utcb_exc(), sizeof(l4_exc_regs_t));
+		_regs = *l4_utcb_exc();
 }
 
 
@@ -134,7 +134,7 @@ void Ipc_pager::acknowledge_wakeup()
 
 void Ipc_pager::acknowledge_exception()
 {
-	memcpy(l4_utcb_exc(), &_regs, sizeof(l4_exc_regs_t));
+	_regs = *l4_utcb_exc();
 	l4_cap_idx_t dst = Fiasco::Capability::valid(_last.kcap)
 	                 ? _last.kcap : (l4_cap_idx_t)L4_SYSF_REPLY;
 	Fiasco::l4_msgtag_t const msg_tag =

repos/base-foc/src/core/platform.cc

@@ -495,6 +495,10 @@ Platform::Platform() :
 			xml.node("hardware", [&] () {
 				_setup_platform_info(xml, sigma0_map_kip());
 			});
+			xml.node("affinity-space", [&] () {
+				xml.attribute("width", affinity_space().width());
+				xml.attribute("height", affinity_space().height());
+			});
 		});
 
 		_rom_fs.insert(new (core_mem_alloc()) Rom_module(phys_addr, size,

repos/base-foc/src/core/vm_session_component.cc

@@ -107,10 +107,12 @@ Vcpu::~Vcpu()
 		_ram_alloc.free(_ds_cap);
 }
 
-void Vm_session_component::_create_vcpu(Thread_capability cap)
+Vm_session::Vcpu_id Vm_session_component::_create_vcpu(Thread_capability cap)
 {
+	Vcpu_id ret;
+
 	if (!cap.valid())
-		return;
+		return ret;
 
 	auto lambda = [&] (Cpu_thread_component *thread) {
 		if (!thread)
@@ -146,10 +148,11 @@ void Vm_session_component::_create_vcpu(Thread_capability cap)
 		}
 
 		_vcpus.insert(vcpu);
-		_id_alloc++;
+		ret.id = _id_alloc++;
 	};
 
 	_ep.apply(cap, lambda);
+	return ret;
 }
 
 Dataspace_capability Vm_session_component::_cpu_state(Vcpu_id const vcpu_id)

repos/base-foc/src/include/base/internal/lock_helper.h

@@ -78,7 +78,7 @@ static inline void thread_switch_to(Genode::Thread *thread_base)
 __attribute__((optimize("-fno-omit-frame-pointer")))
 __attribute__((noinline))
 __attribute__((used))
-static void thread_stop_myself()
+static void thread_stop_myself(Genode::Thread *)
 {
 	using namespace Fiasco;
 

repos/base-foc/src/lib/base/ipc.cc

@@ -238,6 +238,11 @@ static l4_msgtag_t copy_msgbuf_to_utcb(Msgbuf_base &snd_msg,
 		/* setup flexpage for valid capability to delegate */
 		if (caps[i].valid) {
 			unsigned const idx = num_msg_words + 2*num_cap_sel;
+
+			/* check bounds of 'l4_msg_regs_t::mr' */
+			if (idx + 1 >= L4_UTCB_GENERIC_DATA_SIZE)
+				break;
+
 			l4_utcb_mr()->mr[idx]     = L4_ITEM_MAP/* | L4_ITEM_CONT*/;
 			l4_utcb_mr()->mr[idx + 1] = l4_obj_fpage(caps[i].sel,
 			                                         0, L4_FPAGE_RWX).raw;
@@ -311,10 +316,11 @@ void Genode::ipc_reply(Native_capability, Rpc_exception_code exc,
 }
 
 
-Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &,
-                                           Rpc_exception_code      exc,
-                                           Msgbuf_base            &reply_msg,
-                                           Msgbuf_base            &request_msg)
+Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const         &,
+                                           Rpc_exception_code              exc,
+                                           Msgbuf_base                    &reply_msg,
+                                           Msgbuf_base                    &request_msg,
+                                           Rpc_entrypoint::Native_context &)
 {
 	Receive_window &rcv_window = Thread::myself()->native_thread().rcv_window;
 
@@ -365,9 +371,10 @@ Genode::Rpc_request Genode::ipc_reply_wait(Reply_capability const &,
 }
 
 
-Ipc_server::Ipc_server()
+Ipc_server::Ipc_server(Rpc_entrypoint::Native_context& native_context)
 :
-	Native_capability((Cap_index*)Fiasco::l4_utcb_tcr()->user[Fiasco::UTCB_TCR_BADGE])
+	Native_capability((Cap_index*)Fiasco::l4_utcb_tcr()->user[Fiasco::UTCB_TCR_BADGE]),
+	_native_context(native_context)
 {
 	Thread::myself()->native_thread().rcv_window.init();
 }

repos/base-foc/src/lib/base/thread_bootstrap.cc

@@ -59,6 +59,6 @@ void Genode::Thread::_thread_start()
 
 	Thread::myself()->_thread_bootstrap();
 	Thread::myself()->entry();
-	Thread::myself()->_join_lock.unlock();
+	Thread::myself()->_join.wakeup();
 	sleep_forever();
 }

repos/base-foc/src/lib/base/x86/vm_session.cc

@@ -50,7 +50,6 @@ static bool svm_np() { return svm_features() & (1U << 0); }
 struct Vcpu;
 
 static Genode::Registry<Genode::Registered<Vcpu> > vcpus;
-static unsigned vcpu_id = 0;
 
 struct Vcpu : Genode::Thread
 {
@@ -202,7 +201,7 @@ struct Vcpu : Genode::Thread
 		Semaphore                   _wake_up { 0 };
 		Semaphore                  &_handler_ready;
 		Allocator                  &_alloc;
-		Vm_session_client::Vcpu_id  _id;
+		Vm_session_client::Vcpu_id  _id { Vm_session_client::Vcpu_id::INVALID };
 		addr_t                      _state { 0 };
 		addr_t                      _task { 0 };
 		enum Virt const             _vm_type;
@@ -1184,20 +1183,20 @@ struct Vcpu : Genode::Thread
 	public:
 
 		Vcpu(Env &env, Signal_context_capability &cap,
-		     Semaphore &handler_ready,
-		     Vm_session_client::Vcpu_id &id, enum Virt type,
+		     Semaphore &handler_ready, enum Virt type,
 		     Allocator &alloc, Affinity::Location location)
 		:
 			Thread(env, "vcpu_thread", STACK_SIZE, location, Weight(), env.cpu()),
 			_signal(cap), _handler_ready(handler_ready), _alloc(alloc),
-			_id(id), _vm_type(type)
+			_vm_type(type)
 		{ }
 
 		Allocator &allocator() const { return _alloc; }
 
 		bool match(Vm_session_client::Vcpu_id id) { return id.id == _id.id; }
 
-		Genode::Vm_session_client::Vcpu_id id() const { return _id; }
+		Genode::Vm_session_client::Vcpu_id id() const  { return _id; }
+		void id(Genode::Vm_session_client::Vcpu_id id) { _id = id;   }
 
 		void assign_ds_state(Region_map &rm, Dataspace_capability cap)
 		{
@@ -1266,12 +1265,10 @@ Vm_session_client::Vcpu_id
 Vm_session_client::create_vcpu(Allocator &alloc, Env &env,
                                Vm_handler_base &handler)
 {
-	Vm_session_client::Vcpu_id id = { vcpu_id };
-
 	enum Virt vm_type = virt_type(env);
 	if (vm_type == Virt::UNKNOWN) {
 		Genode::error("unsupported hardware virtualisation");
-		return id;
+		return Vm_session::Vcpu_id();
 	}
 
 	Thread * ep = reinterpret_cast<Thread *>(&handler._rpc_ep);
@@ -1279,17 +1276,17 @@ Vm_session_client::create_vcpu(Allocator &alloc, Env &env,
 
 	/* create thread that switches modes between thread/cpu */
 	Vcpu * vcpu = new (alloc) Registered<Vcpu>(vcpus, env, handler._cap,
-	                                           handler._done, id, vm_type,
+	                                           handler._done, vm_type,
 	                                           alloc, location);
 
 	try {
 		/* now it gets actually valid - vcpu->cap() becomes valid */
 		vcpu->start();
 
-		call<Rpc_exception_handler>(handler._cap, vcpu->id());
-
 		/* instruct core to let it become a vCPU */
-		call<Rpc_create_vcpu>(vcpu->cap());
+		vcpu->id(call<Rpc_create_vcpu>(vcpu->cap()));
+
+		call<Rpc_exception_handler>(handler._cap, vcpu->id());
 
 		vcpu->assign_ds_state(env.rm(), call<Rpc_cpu_state>(vcpu->id()));
 	} catch (...) {
@@ -1299,9 +1296,7 @@ Vm_session_client::create_vcpu(Allocator &alloc, Env &env,
 		destroy(alloc, vcpu);
 		throw;
 	}
-
-	vcpu_id ++;
-	return id;
+	return vcpu->id();
 }
 
 void Vm_session_client::run(Vcpu_id vcpu_id)

repos/base-hw/include/spec/arm_64/cpu/vm_state_virtualization.h

@@ -0,0 +1,109 @@
+/*
+ * \brief   CPU, PIC, and timer context of a virtual machine
+ * \author  Stefan Kalkowski
+ * \date    2015-02-10
+ */
+
+/*
+ * Copyright (C) 2015-2017 Genode Labs GmbH
+ *
+ * This file is part of the Genode OS framework, which is distributed
+ * under the terms of the GNU Affero General Public License version 3.
+ */
+
+#ifndef _INCLUDE__SPEC__ARM_64__CPU__VM_STATE_VIRTUALIZATION_H_
+#define _INCLUDE__SPEC__ARM_64__CPU__VM_STATE_VIRTUALIZATION_H_
+
+/* Genode includes */
+#include <cpu/cpu_state.h>
+
+namespace Genode
+{
+	/**
+	 * CPU context of a virtual machine
+	 */
+	struct Vm_state;
+
+	using uint128_t = __uint128_t;
+}
+
+struct Genode::Vm_state : Genode::Cpu_state
+{
+	Genode::uint64_t pstate         { 0 };
+	Genode::uint64_t exception_type { 0 };
+	Genode::uint64_t esr_el2        { 0 };
+
+	/** Fpu registers **/
+	Genode::uint128_t q[32]         { 0 };
+	Genode::uint32_t fpcr           { 0 };
+	Genode::uint32_t fpsr           { 0 };
+
+	Genode::uint64_t elr_el1        { 0 };
+	Genode::uint64_t sp_el1         { 0 };
+	Genode::uint32_t spsr_el1       { 0 };
+	Genode::uint32_t esr_el1        { 0 };
+
+	Genode::uint64_t sctlr_el1      { 0 };
+	Genode::uint64_t actlr_el1      { 0 };
+	Genode::uint64_t vbar_el1       { 0 };
+	Genode::uint32_t cpacr_el1      { 0 };
+	Genode::uint32_t afsr0_el1      { 0 };
+	Genode::uint32_t afsr1_el1      { 0 };
+	Genode::uint32_t contextidr_el1 { 0 };
+
+	Genode::uint64_t ttbr0_el1      { 0 };
+	Genode::uint64_t ttbr1_el1      { 0 };
+	Genode::uint64_t tcr_el1        { 0 };
+	Genode::uint64_t mair_el1       { 0 };
+	Genode::uint64_t amair_el1      { 0 };
+	Genode::uint64_t far_el1        { 0 };
+	Genode::uint64_t par_el1        { 0 };
+
+	Genode::uint64_t tpidrro_el0    { 0 };
+	Genode::uint64_t tpidr_el0      { 0 };
+	Genode::uint64_t tpidr_el1      { 0 };
+
+	Genode::uint64_t vmpidr_el2     { 0 };
+
+	Genode::uint64_t far_el2        { 0 };
+	Genode::uint64_t hpfar_el2      { 0 };
+
+	/**
+	 * Timer related registers
+	 */
+	struct Timer {
+		Genode::uint64_t offset   { 0 };
+		Genode::uint64_t compare  { 0 };
+		Genode::uint32_t control  { 0 };
+		Genode::uint32_t kcontrol { 0 };
+		bool             irq      { false };
+	} timer {};
+
+	/**
+	 * Interrupt related values
+	 */
+	struct Pic
+	{
+		unsigned last_irq    { 1023 };
+		unsigned virtual_irq { 1023 };
+	} irqs {};
+
+	/**************************
+	 ** Platform information **
+	 **************************/
+
+	Genode::uint64_t id_aa64isar0_el1 { 0 };
+	Genode::uint64_t id_aa64isar1_el1 { 0 };
+	Genode::uint64_t id_aa64mmfr0_el1 { 0 };
+	Genode::uint64_t id_aa64mmfr1_el1 { 0 };
+	Genode::uint64_t id_aa64mmfr2_el1 { 0 };
+	Genode::uint64_t id_aa64pfr0_el1  { 0 };
+	Genode::uint64_t id_aa64pfr1_el1  { 0 };
+	Genode::uint64_t id_aa64zfr0_el1  { 0 };
+
+	Genode::uint32_t ccsidr_inst_el1[7] { 0 };
+	Genode::uint32_t ccsidr_data_el1[7] { 0 };
+	Genode::uint64_t clidr_el1          { 0 };
+};
+
+#endif /* _INCLUDE__SPEC__ARM_64__CPU__VM_STATE_VIRTUALIZATION_H_ */

repos/base-hw/lib/mk/base-hw-common.mk

@@ -10,5 +10,7 @@ include $(BASE_DIR)/lib/mk/base-common.inc
 LIBS += syscall-hw
 
 SRC_CC += rpc_dispatch_loop.cc
+SRC_CC += rpc_entrypoint_manage.cc
 SRC_CC += thread.cc thread_myself.cc thread_bootstrap.cc
 SRC_CC += signal_transmitter.cc
+SRC_CC += rpc_entry.cc

repos/base-hw/lib/mk/base-hw.mk

@@ -7,5 +7,6 @@ SRC_CC += raw_write_string.cc
 SRC_CC += signal_receiver.cc
 SRC_CC += stack_area_addr.cc
 SRC_CC += native_utcb.cc
+SRC_CC += platform.cc
 
 LIBS += startup-hw base-hw-common cxx timeout-hw

repos/base-hw/lib/mk/bootstrap-hw.inc

@@ -17,6 +17,7 @@ SRC_CC  += lib/base/heap.cc
 SRC_CC  += lib/base/registry.cc
 SRC_CC  += lib/base/log.cc
 SRC_CC  += lib/base/output.cc
+SRC_CC  += lib/base/raw_output.cc
 SRC_CC  += lib/base/slab.cc
 SRC_CC  += lib/base/sleep.cc
 SRC_CC  += lib/base/sliced_heap.cc

repos/base-hw/lib/mk/core-hw.inc

@@ -52,7 +52,6 @@ SRC_CC += pager.cc
 SRC_CC += _main.cc
 SRC_CC += kernel/cpu.cc
 SRC_CC += kernel/cpu_scheduler.cc
-SRC_CC += kernel/double_list.cc
 SRC_CC += kernel/init.cc
 SRC_CC += kernel/ipc_node.cc
 SRC_CC += kernel/irq.cc

repos/base-hw/lib/mk/spec/arm/core-hw.inc

@@ -17,7 +17,7 @@ SRC_CC += spec/arm/platform_support.cc
 
 # add assembly sources
 SRC_S += spec/arm/crt0.s
-SRC_S += spec/arm/exception_vector.s
+SRC_S += spec/arm/exception_vector.S
 
 vpath spec/32bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
 

repos/base-hw/lib/mk/spec/arm_v7/core-hw-arndale.mk

@@ -6,16 +6,16 @@
 
 # add include paths
 INC_DIR += $(REP_DIR)/src/core/spec/arndale
-INC_DIR += $(REP_DIR)/src/core/spec/arm_v7/virtualization
+INC_DIR += $(REP_DIR)/src/core/spec/arm/virtualization
 
 # add C++ sources
 SRC_CC += kernel/vm_thread_on.cc
 SRC_CC += spec/arm/gicv2.cc
 SRC_CC += spec/arm_v7/virtualization/kernel/vm.cc
-SRC_CC += spec/arm_v7/virtualization/platform_services.cc
-SRC_CC += spec/arm_v7/virtualization/vm_session_component.cc
-SRC_CC += spec/arm_v7/vm_session_component.cc
+SRC_CC += spec/arm/virtualization/platform_services.cc
+SRC_CC += spec/arm/virtualization/vm_session_component.cc
 SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 # add assembly sources
 SRC_S += spec/arm_v7/virtualization/exception_vector.s

repos/base-hw/lib/mk/spec/arm_v7/core-hw-imx53_qsb_tz.mk

@@ -5,7 +5,8 @@ SRC_CC += kernel/vm_thread_on.cc
 SRC_CC += spec/arm_v7/trustzone/kernel/vm.cc
 SRC_CC += spec/arm_v7/trustzone/platform_services.cc
 SRC_CC += spec/arm_v7/trustzone/vm_session_component.cc
-SRC_CC += spec/arm_v7/vm_session_component.cc
+SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 SRC_S += spec/arm_v7/trustzone/exception_vector.s
 

repos/base-hw/lib/mk/spec/arm_v7/core-hw-imx7d_sabre.mk

@@ -6,17 +6,18 @@
 
 # add include paths
 INC_DIR += $(REP_DIR)/src/core/spec/imx7d_sabre
-INC_DIR += $(REP_DIR)/src/core/spec/arm_v7/virtualization
+INC_DIR += $(REP_DIR)/src/core/spec/arm/virtualization
 
 # add C++ sources
 SRC_CC += kernel/vm_thread_on.cc
 SRC_CC += spec/arm/generic_timer.cc
 SRC_CC += spec/arm/gicv2.cc
 SRC_CC += spec/arm_v7/virtualization/kernel/vm.cc
-SRC_CC += spec/arm_v7/virtualization/platform_services.cc
-SRC_CC += spec/arm_v7/virtualization/vm_session_component.cc
-SRC_CC += spec/arm_v7/vm_session_component.cc
+SRC_CC += spec/arm/virtualization/gicv2.cc
+SRC_CC += spec/arm/virtualization/platform_services.cc
+SRC_CC += spec/arm/virtualization/vm_session_component.cc
 SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 # add assembly sources
 SRC_S += spec/arm_v7/virtualization/exception_vector.s

repos/base-hw/lib/mk/spec/arm_v7/core-hw-usb_armory.mk

@@ -17,7 +17,8 @@ SRC_CC += spec/arm/imx_tzic.cc
 SRC_CC += spec/arm_v7/trustzone/kernel/vm.cc
 SRC_CC += spec/arm_v7/trustzone/platform_services.cc
 SRC_CC += spec/arm_v7/trustzone/vm_session_component.cc
-SRC_CC += spec/arm_v7/vm_session_component.cc
+SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 # add assembly sources
 SRC_S += spec/arm_v7/trustzone/exception_vector.s

repos/base-hw/lib/mk/spec/arm_v8/bootstrap-hw-imx8q_evk.mk

@@ -7,6 +7,8 @@ SRC_CC  += lib/base/arm_64/kernel/interface.cc
 SRC_CC  += spec/64bit/memory_map.cc
 SRC_S   += bootstrap/spec/arm_64/crt0.s
 
+NR_OF_CPUS = 4
+
 vpath spec/64bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
 
 include $(BASE_DIR)/../base-hw/lib/mk/bootstrap-hw.inc

repos/base-hw/lib/mk/spec/arm_v8/bootstrap-hw-rpi3.mk

@@ -8,4 +8,6 @@ SRC_S   += bootstrap/spec/arm_64/crt0.s
 
 vpath spec/64bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
 
+NR_OF_CPUS = 4
+
 include $(BASE_DIR)/../base-hw/lib/mk/bootstrap-hw.inc

repos/base-hw/lib/mk/spec/arm_v8/core-hw-imx8q_evk.mk

@@ -1,24 +1,32 @@
 INC_DIR += $(REP_DIR)/src/core/spec/imx8q_evk
 INC_DIR += $(REP_DIR)/src/core/spec/arm_v8
+INC_DIR += $(REP_DIR)/src/core/spec/arm/virtualization
 
 # add C++ sources
-SRC_CC += kernel/cpu_up.cc
-SRC_CC += kernel/lock.cc
-SRC_CC += kernel/vm_thread_off.cc
-SRC_CC += platform_services.cc
+SRC_CC += kernel/cpu_mp.cc
+SRC_CC += kernel/vm_thread_on.cc
 SRC_CC += spec/64bit/memory_map.cc
 SRC_CC += spec/arm/generic_timer.cc
 SRC_CC += spec/arm/gicv3.cc
+SRC_CC += spec/arm/kernel/lock.cc
 SRC_CC += spec/arm/platform_support.cc
 SRC_CC += spec/arm_v8/cpu.cc
 SRC_CC += spec/arm_v8/kernel/cpu.cc
 SRC_CC += spec/arm_v8/kernel/thread.cc
+SRC_CC += spec/arm_v8/virtualization/kernel/vm.cc
+SRC_CC += spec/arm/virtualization/platform_services.cc
+SRC_CC += spec/arm/virtualization/vm_session_component.cc
+SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 #add assembly sources
 SRC_S += spec/arm_v8/exception_vector.s
 SRC_S += spec/arm_v8/crt0.s
+SRC_S += spec/arm_v8/virtualization/exception_vector.s
 
 vpath spec/64bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
 
+NR_OF_CPUS = 4
+
 # include less specific configuration
 include $(REP_DIR)/lib/mk/core-hw.inc

repos/base-hw/lib/mk/spec/arm_v8/core-hw-rpi3.mk

@@ -2,17 +2,17 @@ INC_DIR += $(REP_DIR)/src/core/spec/rpi3
 INC_DIR += $(REP_DIR)/src/core/spec/arm_v8
 
 # add C++ sources
-SRC_CC += platform_services.cc
+SRC_CC += kernel/cpu_mp.cc
 SRC_CC += kernel/vm_thread_off.cc
-SRC_CC += kernel/cpu_up.cc
-SRC_CC += kernel/lock.cc
-SRC_CC += spec/arm_v8/cpu.cc
-SRC_CC += spec/arm_v8/kernel/thread.cc
-SRC_CC += spec/arm_v8/kernel/cpu.cc
-SRC_CC += spec/arm/platform_support.cc
+SRC_CC += platform_services.cc
+SRC_CC += spec/64bit/memory_map.cc
 SRC_CC += spec/arm/bcm2837_pic.cc
 SRC_CC += spec/arm/generic_timer.cc
-SRC_CC += spec/64bit/memory_map.cc
+SRC_CC += spec/arm/kernel/lock.cc
+SRC_CC += spec/arm/platform_support.cc
+SRC_CC += spec/arm_v8/cpu.cc
+SRC_CC += spec/arm_v8/kernel/cpu.cc
+SRC_CC += spec/arm_v8/kernel/thread.cc
 
 #add assembly sources
 SRC_S += spec/arm_v8/exception_vector.s
@@ -20,5 +20,7 @@ SRC_S += spec/arm_v8/crt0.s
 
 vpath spec/64bit/memory_map.cc $(BASE_DIR)/../base-hw/src/lib/hw
 
+NR_OF_CPUS = 4
+
 # include less specific configuration
 include $(REP_DIR)/lib/mk/core-hw.inc

repos/base-hw/lib/mk/spec/x86_64/core-hw-muen.mk

@@ -35,7 +35,10 @@ SRC_CC += spec/x86_64/muen/platform_services.cc
 SRC_CC += spec/x86_64/muen/platform_support.cc
 SRC_CC += spec/x86_64/muen/sinfo_instance.cc
 SRC_CC += spec/x86_64/muen/timer.cc
+SRC_CC += spec/x86_64/muen/vm_session_component.cc
 SRC_CC += spec/x86_64/platform_support_common.cc
+SRC_CC += vm_session_common.cc
+SRC_CC += vm_session_component.cc
 
 SRC_CC += spec/64bit/memory_map.cc
 

repos/base-hw/recipes/api/base-hw/hash

@@ -1 +1 @@
-2019-07-08 abc6d82ca4a240319850c788f29cde2655eab1d1
+2019-11-25 6593319a4dec74af9dc15554139e4343ef4312a9

repos/base-hw/recipes/src/base-hw-arndale/hash

@@ -1 +1 @@
-2019-08-27 d4178964debbd47e4c0d37a127f51662054cd237
+2020-02-27 e1a80cef41a848e8f63df9a249a4e57148e66331

repos/base-hw/recipes/src/base-hw-imx53_qsb/hash

@@ -1 +1 @@
-2019-08-27 5b6d3f57e76de132294eca0418ae63ff18a4d921
+2020-02-27 bd79fb9d11cef09e99ba545408128a605b47814a

repos/base-hw/recipes/src/base-hw-imx53_qsb_tz/hash

@@ -1 +1 @@
-2019-08-27 51d44f6fef88b6cdeba9cfdbab1b170250ed28ad
+2020-02-27 879f89b08454a6aab78bab0c018d1902af792a47

repos/base-hw/recipes/src/base-hw-imx6q_sabrelite/hash

@@ -1 +1 @@
-2019-08-27 559fcb46116ad7f3234892968271b268295b9296
+2020-02-27 447889337c681d7b9f68c637f9a3eac3abfd2f30

repos/base-hw/recipes/src/base-hw-imx7d_sabre/hash

@@ -1 +1 @@
-2019-08-27 f2b8b089ac104f6ac25cbdf7a522f83e761bca86
+2020-02-27 42c284564d38f3bdbd6b30e58280a2f699b657f9

repos/base-hw/recipes/src/base-hw-imx8q_evk/hash

@@ -1 +1 @@
-2019-08-27 c4b95a617529b279fb7a681b55cf6861a1cbb8ba
+2020-02-27 9d9e438a93c416499bb7b414bbcf2de7f2d3650f

repos/base-hw/recipes/src/base-hw-muen/hash

@@ -1 +1 @@
-2019-08-27 e70d7f749ced55e96ce5486859123db5e9ee596d
+2020-02-27 ff3428ffdd5d60514fa5028b003b54327da895ad

repos/base-hw/recipes/src/base-hw-nit6_solox/hash

@@ -1 +1 @@
-2019-08-27 c39e790ba567b102afabd0ae34d2fb4bffebb531
+2020-02-27 84aec73deeae79a6b34374fe859ea5333d05da69

repos/base-hw/recipes/src/base-hw-odroid_xu/hash

@@ -1 +1 @@
-2019-08-27 16dc7287252a28981c894d15465c3ab34a88b91e
+2020-02-27 e87fc4e86962227db5c41bf048eeacf1c27d04c1

repos/base-hw/recipes/src/base-hw-panda/hash

@@ -1 +1 @@
-2019-08-27 7bf52d5fec332b0d453e2193c32c6c912467f9fa
+2020-02-27 ebd97e5400e2b99fd810cd233c0f881ede48f376

repos/base-hw/recipes/src/base-hw-pbxa9/hash

@@ -1 +1 @@
-2019-08-27 a9ed26560e2da949fd5e54bcba12eee6fdef15e5
+2020-02-27 5d0722736647b538eb52b35286b7734581402426

repos/base-hw/recipes/src/base-hw-pc/hash

@@ -1 +1 @@
-2019-08-27 40de2c240789026faa255646fb1063042cb96b0d
+2020-02-27 1caed3e6b2d8bc98948b9fd43f3bb26abd52f780

repos/base-hw/recipes/src/base-hw-rpi/hash

@@ -1 +1 @@
-2019-08-27 d7ae8cddd46c47b43f7f162c07d19e3a6879d0e0
+2020-02-27 6d72eb037774a58fc079c5df7bd5b7348c8799b4

repos/base-hw/recipes/src/base-hw-rpi3/hash

@@ -1 +1 @@
-2019-08-27 9eda2e18c925c75f60be5267e02c65a96d9d4583
+2020-02-27 41e345219f64781ef6cb472d4f9d374b0295328b

repos/base-hw/recipes/src/base-hw-zynq_qemu/hash

@@ -1 +1 @@
-2019-08-27 1f55a4206dfd96f36c2bb68598a77b2b1b69d663
+2020-02-27 c2481cbfd690b653b38c6bfe09c296094240e90d

repos/base-hw/run/cpu_scheduler.run

@@ -23,7 +23,7 @@ install_config {
 		<default-route>
 			<any-service> <parent/> </any-service>
 		</default-route>
-		<start name="test-cpu_scheduler">
+		<start name="test-cpu_scheduler" caps="100">
 			<resource name="RAM" quantum="10M"/>
 		</start>
 	</config>}

repos/base-hw/run/double_list.run

@@ -16,11 +16,14 @@ install_config {
 		<parent-provides>
 			<service name="LOG"/>
 			<service name="RM"/>
+			<service name="PD"/>
+			<service name="CPU"/>
+			<service name="ROM"/>
 		</parent-provides>
 		<default-route>
 			<any-service> <parent/> </any-service>
 		</default-route>
-		<start name="test-double_list">
+		<start name="test-double_list" caps="100">
 			<resource name="RAM" quantum="10M"/>
 		</start>
 	</config>

repos/base-hw/src/bootstrap/lock.cc

@@ -12,6 +12,7 @@
  */
 
 #include <base/lock.h>
+#include <base/mutex.h>
 #include <hw/assert.h>
 
 Genode::Cancelable_lock::Cancelable_lock(Genode::Cancelable_lock::State state)
@@ -30,3 +31,13 @@ void Genode::Cancelable_lock::lock()
 	assert(_state == UNLOCKED);
 	_state = LOCKED;
 }
+
+void Genode::Mutex::acquire()
+{
+	_lock.lock();
+}
+
+void Genode::Mutex::release()
+{
+	_lock.unlock();
+}

repos/base-hw/src/bootstrap/log.cc

@@ -19,6 +19,7 @@
 /* base-internal includes */
 #include <base/internal/globals.h>
 #include <base/internal/output.h>
+#include <base/internal/raw_write_string.h>
 #include <base/internal/unmanaged_singleton.h>
 
 #include <board.h>
@@ -57,3 +58,5 @@ struct Buffer
 Genode::Log &Genode::Log::log() {
 	return unmanaged_singleton<Buffer>()->log; }
 
+
+void Genode::raw_write_string(char const *str) { log(str); }

repos/base-hw/src/bootstrap/platform.cc

@@ -19,6 +19,7 @@
 
 using namespace Bootstrap;
 
+extern unsigned _bss_end;
 
 /*****************************
  ** Platform::Ram_allocator **
@@ -179,7 +180,7 @@ Platform::Platform()
 	/* temporarily map all bootstrap memory 1:1 for transition to core */
 	// FIXME do not insert as mapping for core
 	core_pd->map_insert(Mapping(bootstrap_region.base, bootstrap_region.base,
-	                            bootstrap_region.size, Hw::PAGE_FLAGS_KERN_TEXT));
+	                            (addr_t)&_bss_end - (addr_t)&_prog_img_beg, Hw::PAGE_FLAGS_KERN_TEXT));
 
 	/* map memory-mapped I/O for core */
 	board.core_mmio.for_each_mapping([&] (Mapping const & m) {

repos/base-hw/src/bootstrap/platform.h

@@ -47,7 +47,6 @@ class Bootstrap::Platform
 			Mmio_space const    core_mmio;
 			unsigned            cpus              { NR_OF_CPUS };
 			::Board::Boot_info  info              { };
-			::Board::Pic        pic               { };
 
 			Board();
 		};

repos/base-hw/src/bootstrap/spec/arm/cortex_a8_mmu.cc

@@ -15,6 +15,7 @@
 
 unsigned Bootstrap::Platform::enable_mmu()
 {
+	::Board::Pic pic { };
 	::Board::Cpu::Sctlr::init();
 	::Board::Cpu::enable_mmu_and_caches((addr_t)core_pd->table_base);
 

repos/base-hw/src/bootstrap/spec/arm/cortex_a9_mmu.cc

@@ -109,16 +109,21 @@ unsigned Bootstrap::Platform::enable_mmu()
 	static Cpu_counter   data_cache_invalidated;
 	static Cpu_counter   data_cache_enabled;
 	static Cpu_counter   smp_coherency_enabled;
+	static unsigned long diag_reg = 0;
 
 	bool primary = primary_cpu;
-	if (primary) primary_cpu = false;
+	if (primary) {
+		primary_cpu = false;
+		diag_reg = Cpu::Diag::read();
+	}
 
 	Cpu::Sctlr::init();
 	Cpu::Cpsr::init();
 	Actlr::disable_smp();
+	Cpu::Diag::write(diag_reg);
 
 	/* locally initialize interrupt controller */
-	board.pic.init_cpu_local();
+	::Board::Pic pic { };
 
 	Cpu::invalidate_data_cache();
 	data_cache_invalidated.inc();
@@ -170,6 +175,7 @@ unsigned Bootstrap::Platform::enable_mmu()
 	/* wait for other cores' coherency activation */
 	smp_coherency_enabled.wait_for(NR_OF_CPUS);
 
-	Cpu::synchronization_barrier();
+	asm volatile("dsb sy\n"
+	             "isb sy\n" ::: "memory");
 	return Cpu::Mpidr::Aff_0::get(Cpu::Mpidr::read());
 }

repos/base-hw/src/bootstrap/spec/arm/gicv2.cc

@@ -13,8 +13,41 @@
 
 #include <board.h>
 
-void Board::Pic::init_cpu_local()
+Hw::Gicv2::Gicv2()
+: _distr(Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_BASE),
+  _cpui (Board::Cpu_mmio::IRQ_CONTROLLER_CPU_BASE),
+  _last_iar(Cpu_interface::Iar::Irq_id::bits(spurious_id)),
+  _max_irq(_distr.max_irq())
 {
+	static bool distributor_initialized = false;
+
+	if (!distributor_initialized) {
+		distributor_initialized = true;
+
+		/* disable device */
+		_distr.write<Distributor::Ctlr>(0);
+
+		/* configure every shared peripheral interrupt */
+		for (unsigned i = min_spi; i <= _max_irq; i++) {
+			if (Board::NON_SECURE) {
+				_distr.write<Distributor::Igroupr::Group_status>(1, i);
+			}
+			_distr.write<Distributor::Icfgr::Edge_triggered>(0, i);
+			_distr.write<Distributor::Ipriorityr::Priority>(0, i);
+			_distr.write<Distributor::Icenabler::Clear_enable>(1, i);
+		}
+
+		/* enable device */
+		Distributor::Ctlr::access_t v = 0;
+		if (Board::NON_SECURE) {
+			Distributor::Ctlr::Enable_grp0::set(v, 1);
+			Distributor::Ctlr::Enable_grp1::set(v, 1);
+		} else {
+			Distributor::Ctlr::Enable::set(v, 1);
+		}
+		_distr.write<Distributor::Ctlr>(v);
+	}
+
 	if (Board::NON_SECURE) {
 		_cpui.write<Cpu_interface::Ctlr>(0);
 
@@ -40,34 +73,3 @@ void Board::Pic::init_cpu_local()
 	}
 	_cpui.write<Cpu_interface::Ctlr>(v);
 }
-
-
-Hw::Gicv2::Gicv2()
-: _distr(Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_BASE),
-  _cpui (Board::Cpu_mmio::IRQ_CONTROLLER_CPU_BASE),
-  _last_iar(Cpu_interface::Iar::Irq_id::bits(spurious_id)),
-  _max_irq(_distr.max_irq())
-{
-	/* disable device */
-	_distr.write<Distributor::Ctlr>(0);
-
-	/* configure every shared peripheral interrupt */
-	for (unsigned i = min_spi; i <= _max_irq; i++) {
-		if (Board::NON_SECURE) {
-			_distr.write<Distributor::Igroupr::Group_status>(1, i);
-		}
-		_distr.write<Distributor::Icfgr::Edge_triggered>(0, i);
-		_distr.write<Distributor::Ipriorityr::Priority>(0, i);
-		_distr.write<Distributor::Icenabler::Clear_enable>(1, i);
-	}
-
-	/* enable device */
-	Distributor::Ctlr::access_t v = 0;
-	if (Board::NON_SECURE) {
-		Distributor::Ctlr::Enable_grp0::set(v, 1);
-		Distributor::Ctlr::Enable_grp1::set(v, 1);
-	} else {
-		Distributor::Ctlr::Enable::set(v, 1);
-	}
-	_distr.write<Distributor::Ctlr>(v);
-}

repos/base-hw/src/bootstrap/spec/arm/gicv2.h

@@ -1,26 +0,0 @@
-/*
- * \brief  Interrupt controller definitions for ARM
- * \author Stefan Kalkowski
- * \date   2017-02-22
- */
-
-/*
- * Copyright (C) 2017 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU Affero General Public License version 3.
- */
-
-#ifndef _SRC__BOOTSTRAP__SPEC__ARM__GICV2_H_
-#define _SRC__BOOTSTRAP__SPEC__ARM__GICV2_H_
-
-#include <hw/spec/arm/gicv2.h>
-
-namespace Board { struct Pic; }
-
-struct Board::Pic : Hw::Gicv2
-{
-	void init_cpu_local();
-};
-
-#endif /* _SRC__BOOTSTRAP__SPEC__ARM__GICV2_H_ */

repos/base-hw/src/bootstrap/spec/arm_64/cortex_a53_mmu.cc

@@ -11,10 +11,12 @@
  * under the terms of the GNU Affero General Public License version 3.
  */
 
+#include <hw/spec/arm_64/memory_map.h>
 #include <platform.h>
 
 using Board::Cpu;
 
+extern "C" void * _crt0_start_secondary;
 
 static inline void prepare_non_secure_world()
 {
@@ -56,11 +58,54 @@ static inline void prepare_non_secure_world()
 }
 
 
-static inline void prepare_hypervisor()
+static inline void prepare_hypervisor(Cpu::Ttbr::access_t const ttbr)
 {
-	Cpu::Hcr::access_t scr = Cpu::Hcr::read();
-	Cpu::Hcr::Rw::set(scr,  1); /* exec in aarch64 */
-	Cpu::Hcr::write(scr);
+	using namespace Hw::Mm;
+
+	/* forbid trace access */
+	Cpu::Cptr_el2::access_t cptr = Cpu::Cptr_el2::read();
+	Cpu::Cptr_el2::Tta::set(cptr, 1);
+	Cpu::Cptr_el2::write(cptr);
+
+	/* allow physical counter/timer access without trapping */
+	Cpu::Cnthctl_el2::write(0b111);
+
+	/* forbid any 32bit access to coprocessor/sysregs */
+	Cpu::Hstr_el2::write(0xffff);
+
+	Cpu::Hcr_el2::access_t hcr = Cpu::Hcr_el2::read();
+	Cpu::Hcr_el2::Rw::set(hcr, 1); /* exec in aarch64 */
+	Cpu::Hcr_el2::write(hcr);
+
+	/* set hypervisor exception vector */
+	Cpu::Vbar_el2::write(el2_addr(hypervisor_exception_vector().base));
+	Genode::addr_t const stack_el2 = el2_addr(hypervisor_stack().base +
+	                                          hypervisor_stack().size);
+
+	/* set hypervisor's translation table */
+	Cpu::Ttbr0_el2::write(ttbr);
+
+	Cpu::Tcr_el2::access_t tcr_el2 = 0;
+	Cpu::Tcr_el2::T0sz::set(tcr_el2, 25);
+	Cpu::Tcr_el2::Irgn0::set(tcr_el2, 1);
+	Cpu::Tcr_el2::Orgn0::set(tcr_el2, 1);
+	Cpu::Tcr_el2::Sh0::set(tcr_el2, 0b10);
+
+	/* prepare MMU usage by hypervisor code */
+	Cpu::Tcr_el2::write(tcr_el2);
+
+	/* set memory attributes in indirection register */
+	Cpu::Mair::access_t mair = 0;
+	Cpu::Mair::Attr0::set(mair, Cpu::Mair::NORMAL_MEMORY_UNCACHED);
+	Cpu::Mair::Attr1::set(mair, Cpu::Mair::DEVICE_MEMORY);
+	Cpu::Mair::Attr2::set(mair, Cpu::Mair::NORMAL_MEMORY_CACHED);
+	Cpu::Mair::Attr3::set(mair, Cpu::Mair::DEVICE_MEMORY);
+	Cpu::Mair_el2::write(mair);
+
+	Cpu::Vtcr_el2::access_t vtcr = 0;
+	Cpu::Vtcr_el2::T0sz::set(vtcr, 25);
+	Cpu::Vtcr_el2::Sl0::set(vtcr, 1); /* set to starting level 1 */
+	Cpu::Vtcr_el2::write(vtcr);
 
 	Cpu::Spsr::access_t pstate = 0;
 	Cpu::Spsr::Sp::set(pstate, 1); /* select non-el0 stack pointer */
@@ -71,26 +116,54 @@ static inline void prepare_hypervisor()
 	Cpu::Spsr::D::set(pstate, 1);
 	Cpu::Spsr_el2::write(pstate);
 
+	Cpu::Sctlr::access_t sctlr = Cpu::Sctlr_el2::read();
+	Cpu::Sctlr::M::set(sctlr, 1);
+	Cpu::Sctlr::A::set(sctlr, 0);
+	Cpu::Sctlr::C::set(sctlr, 1);
+	Cpu::Sctlr::Sa::set(sctlr, 0);
+	Cpu::Sctlr::I::set(sctlr, 1);
+	Cpu::Sctlr::Wxn::set(sctlr, 0);
+	Cpu::Sctlr_el2::write(sctlr);
+
 	asm volatile("mov x0, sp      \n"
 	             "msr sp_el1, x0  \n"
 	             "adr x0, 1f      \n"
 	             "msr elr_el2, x0 \n"
+	             "mov sp, %0      \n"
 	             "eret            \n"
-	             "1:");
+	             "1:": : "r"(stack_el2): "x0");
 }
 
 
 unsigned Bootstrap::Platform::enable_mmu()
 {
+	static volatile bool primary_cpu = true;
+	bool primary = primary_cpu;
+	if (primary) primary_cpu = false;
+
+	Cpu::Ttbr::access_t ttbr =
+		Cpu::Ttbr::Baddr::masked((Genode::addr_t)core_pd->table_base);
+
+	/* primary cpu wakes up all others */
+	if (primary && NR_OF_CPUS > 1) Cpu::wake_up_all_cpus(&_crt0_start_secondary);
+
 	while (Cpu::current_privilege_level() > Cpu::Current_el::EL1) {
-		if (Cpu::current_privilege_level() == Cpu::Current_el::EL3)
+		if (Cpu::current_privilege_level() == Cpu::Current_el::EL3) {
 			prepare_non_secure_world();
-		else
-			prepare_hypervisor();
+		} else {
+			::Board::Pic pic __attribute__((unused)) {};
+			prepare_hypervisor(ttbr);
+		}
 	}
 
 	/* enable performance counter for user-land */
 	Cpu::Pmuserenr_el0::write(0b1111);
+	Cpu::Pmcr_el0::access_t pmcr = Cpu::Pmcr_el0::read();
+	Cpu::Pmcr_el0::write(pmcr | 1);
+	Cpu::Pmcntenset_el0::write(1 << 31);
+
+	/* enable user-level access of physical/virtual counter */
+	Cpu::Cntkctl_el1::write(0b11);
 
 	Cpu::Vbar_el1::write(Hw::Mm::supervisor_exception_vector().base);
 
@@ -100,9 +173,8 @@ unsigned Bootstrap::Platform::enable_mmu()
 	Cpu::Mair::Attr1::set(mair, Cpu::Mair::DEVICE_MEMORY);
 	Cpu::Mair::Attr2::set(mair, Cpu::Mair::NORMAL_MEMORY_CACHED);
 	Cpu::Mair::Attr3::set(mair, Cpu::Mair::DEVICE_MEMORY);
-	Cpu::Mair::write(mair);
+	Cpu::Mair_el1::write(mair);
 
-	Cpu::Ttbr::access_t ttbr = Cpu::Ttbr::Baddr::masked((Genode::addr_t)core_pd->table_base);
 	Cpu::Ttbr0_el1::write(ttbr);
 	Cpu::Ttbr1_el1::write(ttbr);
 
@@ -119,14 +191,15 @@ unsigned Bootstrap::Platform::enable_mmu()
 	Cpu::Tcr_el1::As::set(tcr, 1);
 	Cpu::Tcr_el1::write(tcr);
 
-	Cpu::Sctlr_el1::access_t sctlr = Cpu::Sctlr_el1::read();
-	Cpu::Sctlr_el1::C::set(sctlr, 1);
-	Cpu::Sctlr_el1::I::set(sctlr, 1);
-	Cpu::Sctlr_el1::A::set(sctlr, 0);
-	Cpu::Sctlr_el1::M::set(sctlr, 1);
-	Cpu::Sctlr_el1::Sa0::set(sctlr, 1);
-	Cpu::Sctlr_el1::Sa::set(sctlr, 0);
+	Cpu::Sctlr::access_t sctlr = Cpu::Sctlr_el1::read();
+	Cpu::Sctlr::C::set(sctlr, 1);
+	Cpu::Sctlr::I::set(sctlr, 1);
+	Cpu::Sctlr::A::set(sctlr, 0);
+	Cpu::Sctlr::M::set(sctlr, 1);
+	Cpu::Sctlr::Sa0::set(sctlr, 1);
+	Cpu::Sctlr::Sa::set(sctlr, 0);
+	Cpu::Sctlr::Uct::set(sctlr, 1);
 	Cpu::Sctlr_el1::write(sctlr);
 
-	return 0;
+	return (Cpu::Mpidr::read() & 0xff);
 }

repos/base-hw/src/bootstrap/spec/arm_64/crt0.s

@@ -11,20 +11,34 @@
  * under the terms of the GNU Affero General Public License version 3.
  */
 
+/**
+ * Store CPU number in register x0
+ */
+.macro _cpu_number
+	mrs x0, mpidr_el1
+	and x0, x0, #0b11111111
+.endm
+
 .section ".text.crt0"
 
 	.global _start
 	_start:
 
-	/***********************
-	 ** Detect CPU number **
-	 ***********************/
-
-	mrs x0, mpidr_el1
-	and x0, x0, #0b11111111
+	/**
+	 * Hack for Qemu, which starts all cpus at once
+	 * only first CPU runs through, all others wait for wakeup
+	 */
+	_cpu_number
 	cbz x0, _crt0_fill_bss_zero
+	1:
+	ldr  x1, =_crt0_qemu_start_secondary_cpus
+	ldr  w1, [x1]
+	cbnz w1, _crt0_enable_fpu
 	wfe
-	b _start
+	b 1b
+	.global _crt0_qemu_start_secondary_cpus
+	_crt0_qemu_start_secondary_cpus:
+	.long 0
 
 
 	/***************************
@@ -32,33 +46,50 @@
 	 ***************************/
 
 	_crt0_fill_bss_zero:
-	ldr x0, =_bss_start
-	ldr x1, =_bss_end
+	ldr x1, =_bss_start
+	ldr x2, =_bss_end
 	1:
-	cmp x1, x0
+	cmp x2, x1
 	b.eq _crt0_enable_fpu
-	str xzr, [x0], #8
+	str xzr, [x1], #8
 	b 1b
 
 
+	/************************************
+	 ** Common Entrypoint for all CPUs **
+	 ************************************/
+
+	.global _crt0_start_secondary
+	_crt0_start_secondary:
+
+
 	/****************
 	 ** Enable FPU **
 	 ****************/
 
 	_crt0_enable_fpu:
-	mov x0, #0b11
-	lsl x0, x0, #20
-	msr cpacr_el1, x0
+	mov x1, #0b11
+	lsl x1, x1, #20
+	msr cpacr_el1, x1
 
 
 	/**********************
 	 ** Initialize stack **
 	 **********************/
 
-	ldr x0, =_crt0_start_stack
-	mov sp, x0
+	.set STACK_SIZE, 0x2000
+
+	_cpu_number
+	ldr x1, =_crt0_start_stack
+	ldr x2, [x1]
+	mul x0, x0, x2
+	add x1, x1, x0
+	mov sp, x1
 	bl init
 
 	.p2align 4
-	.space 0x4000
+	.rept NR_OF_CPUS
+		.space STACK_SIZE
+	.endr
 	_crt0_start_stack:
+	.long STACK_SIZE

repos/base-hw/src/bootstrap/spec/arndale/board.h

@@ -17,11 +17,11 @@
 #include <hw/spec/arm/arndale_board.h>
 #include <hw/spec/arm/lpae.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Arndale_board;
-
+	using Pic = Hw::Gicv2;
 	static constexpr bool NON_SECURE = true;
 }
 

repos/base-hw/src/bootstrap/spec/arndale/platform.cc

@@ -155,7 +155,9 @@ unsigned Bootstrap::Platform::enable_mmu()
 	using namespace ::Board;
 
 	static volatile bool primary_cpu = true;
-	board.pic.init_cpu_local();
+
+	/* locally initialize interrupt controller */
+	::Board::Pic pic { };
 
 	prepare_nonsecure_world();
 	prepare_hypervisor((addr_t)core_pd->table_base);

repos/base-hw/src/bootstrap/spec/imx6q_sabrelite/board.h

@@ -18,11 +18,11 @@
 #include <spec/arm/cortex_a9_actlr.h>
 #include <spec/arm/cortex_a9_page_table.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Imx6q_sabrelite_board;
-
+	using Pic = Hw::Gicv2;
 	struct L2_cache;
 
 	static constexpr bool NON_SECURE = false;

repos/base-hw/src/bootstrap/spec/imx7d_sabre/board.h

@@ -17,11 +17,11 @@
 #include <hw/spec/arm/imx7d_sabre_board.h>
 #include <hw/spec/arm/lpae.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Imx7d_sabre_board;
-
+	using Pic = Hw::Gicv2;
 	static constexpr bool NON_SECURE = true;
 }
 

repos/base-hw/src/bootstrap/spec/imx7d_sabre/platform.cc

@@ -287,7 +287,9 @@ unsigned Bootstrap::Platform::enable_mmu()
 {
 	static volatile bool primary_cpu = true;
 	static unsigned long timer_freq  = Cpu::Cntfrq::read();
-	board.pic.init_cpu_local();
+
+	/* locally initialize interrupt controller */
+	::Board::Pic pic { };
 
 	prepare_nonsecure_world(timer_freq);
 	prepare_hypervisor((addr_t)core_pd->table_base);

repos/base-hw/src/bootstrap/spec/imx8q_evk/board.h

@@ -21,7 +21,12 @@
 
 namespace Board {
 	using namespace Hw::Imx8q_evk_board;
-	using Cpu = Hw::Arm_64_cpu;
+
+	struct Cpu : Hw::Arm_64_cpu
+	{
+		static void wake_up_all_cpus(void*);
+	};
+
 	using Hw::Pic;
 };
 

repos/base-hw/src/bootstrap/spec/imx8q_evk/platform.cc

@@ -24,4 +24,269 @@ Bootstrap::Platform::Board::Board()
             Memory_region { ::Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_BASE,
                             ::Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_SIZE },
             Memory_region { ::Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_BASE,
-                            ::Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_SIZE }) {}
+                            ::Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_SIZE })
+{
+	::Board::Pic pic {};
+
+	static volatile unsigned long initial_values[][2] {
+		// GPC values
+		{ 0x303A0004, 0x5050424  },
+		{ 0x303A0030, 0xEB22DE22 },
+		{ 0x303A0034, 0xFFFFF1C7 },
+		{ 0x303A0038, 0x7BFFBC00 },
+		{ 0x303A003C, 0xFA3BF12A },
+		{ 0x303A004C, 0xFFFFDFFF },
+		{ 0x303A01B4, 0x3980     },
+		{ 0x303A01CC, 0xFFFFBFFF },
+		{ 0x303A01D4, 0xFFFF7FFF },
+		{ 0x303A01DC, 0xFFFF7FFF },
+		{ 0x303A01FC, 0x107FF9F  },
+		{ 0x303A080C, 0x1        },
+		{ 0x303A0840, 0x1        },
+		{ 0x303A084C, 0x1        },
+		{ 0x303A0880, 0x1        },
+		{ 0x303A088C, 0x1        },
+		{ 0x303A08C0, 0x1        },
+		{ 0x303A08CC, 0x1        },
+		{ 0x303A0C8C, 0x1        },
+		{ 0x303A0DCC, 0x1        },
+		{ 0x303A0E0C, 0x1        },
+		{ 0x303A0ECC, 0x1        },
+		{ 0x303A0F00, 0x1        },
+		{ 0x303A0F0C, 0x1        },
+
+		// CCM values
+		{ 0x303840B0, 0x2        },
+		{ 0x303840B4, 0x2        },
+		{ 0x303840B8, 0x2        },
+		{ 0x303840BC, 0x2        },
+		{ 0x303840C0, 0x2        },
+		{ 0x303840C4, 0x2        },
+		{ 0x303840C8, 0x2        },
+		{ 0x303840CC, 0x2        },
+		{ 0x303840D0, 0x2        },
+		{ 0x303840D4, 0x2        },
+		{ 0x303840D8, 0x2        },
+		{ 0x303840DC, 0x2        },
+		{ 0x303840E0, 0x2        },
+		{ 0x303840E4, 0x2        },
+		{ 0x303840E8, 0x2        },
+		{ 0x303840EC, 0x2        },
+		{ 0x303840F0, 0x2        },
+		{ 0x303840F4, 0x2        },
+		{ 0x303840F8, 0x2        },
+		{ 0x303840FC, 0x2        },
+		{ 0x30384250, 0x3        },
+		{ 0x30384254, 0x3        },
+		{ 0x30384258, 0x3        },
+		{ 0x3038425C, 0x3        },
+		{ 0x303843A0, 0x3        },
+		{ 0x303843A4, 0x3        },
+		{ 0x303843A8, 0x3        },
+		{ 0x303843AC, 0x3        },
+		{ 0x303844D0, 0x3        },
+		{ 0x303844D4, 0x3        },
+		{ 0x303844D8, 0x3        },
+		{ 0x303844DC, 0x3        },
+		{ 0x303844F0, 0x3        },
+		{ 0x303844F4, 0x3        },
+		{ 0x303844F8, 0x3        },
+		{ 0x303844FC, 0x3        },
+		{ 0x30384560, 0x0        },
+		{ 0x30384564, 0x0        },
+		{ 0x30384568, 0x0        },
+		{ 0x3038456C, 0x0        },
+		{ 0x303845D0, 0x3        },
+		{ 0x303845D4, 0x3        },
+		{ 0x303845D8, 0x3        },
+		{ 0x303845DC, 0x3        },
+		{ 0x30388010, 0x0        },
+		{ 0x30388014, 0x0        },
+		{ 0x30388018, 0x0        },
+		{ 0x3038801C, 0x0        },
+		{ 0x30388020, 0x0        },
+		{ 0x30388024, 0x0        },
+		{ 0x30388028, 0x0        },
+		{ 0x3038802C, 0x0        },
+		{ 0x30388030, 0x11000400 },
+		{ 0x30388034, 0x11000400 },
+		{ 0x30388038, 0x11000400 },
+		{ 0x3038803C, 0x11000400 },
+		{ 0x30388080, 0x11000000 },
+		{ 0x30388084, 0x11000000 },
+		{ 0x30388088, 0x11000000 },
+		{ 0x3038808C, 0x11000000 },
+		{ 0x30388090, 0x0        },
+		{ 0x30388094, 0x0        },
+		{ 0x30388098, 0x0        },
+		{ 0x3038809C, 0x0        },
+		{ 0x303880B0, 0x1100     },
+		{ 0x303880B4, 0x1100     },
+		{ 0x303880B8, 0x1100     },
+		{ 0x303880BC, 0x1100     },
+		{ 0x30388110, 0x0        },
+		{ 0x30388114, 0x0        },
+		{ 0x30388118, 0x0        },
+		{ 0x3038811C, 0x0        },
+		{ 0x30388180, 0x1000000  },
+		{ 0x30388184, 0x1000000  },
+		{ 0x30388188, 0x1000000  },
+		{ 0x3038818C, 0x1000000  },
+		{ 0x303881A0, 0x10000000 },
+		{ 0x303881A4, 0x10000000 },
+		{ 0x303881A8, 0x10000000 },
+		{ 0x303881AC, 0x10000000 },
+		{ 0x303881B0, 0x1000100  },
+		{ 0x303881B4, 0x1000100  },
+		{ 0x303881B8, 0x1000100  },
+		{ 0x303881BC, 0x1000100  },
+		{ 0x30388200, 0x1000000  },
+		{ 0x30388204, 0x1000000  },
+		{ 0x30388208, 0x1000000  },
+		{ 0x3038820C, 0x1000000  },
+		{ 0x30388220, 0x10000000 },
+		{ 0x30388224, 0x10000000 },
+		{ 0x30388228, 0x10000000 },
+		{ 0x3038822C, 0x10000000 },
+		{ 0x30388230, 0x1000100  },
+		{ 0x30388234, 0x1000100  },
+		{ 0x30388238, 0x1000100  },
+		{ 0x3038823C, 0x1000100  },
+
+		// CCMA values
+		{ 0x30360000, 0x88080    },
+		{ 0x30360004, 0x292A2FA6 },
+		{ 0x30360004, 0x292A2FA6 },
+		{ 0x30360008, 0x88080    },
+		{ 0x30360008, 0x88080    },
+		{ 0x3036000C, 0x10385BA3 },
+		{ 0x3036000C, 0x10385BA3 },
+		{ 0x30360010, 0x98080    },
+		{ 0x30360010, 0x98080    },
+		{ 0x30360014, 0x3FFFFF1A },
+		{ 0x30360014, 0x3FFFFF1A },
+		{ 0x30360018, 0x88081    },
+		{ 0x30360054, 0x2B9      },
+
+		// IOMUXC
+		{ 0x30330064, 0x6        },
+		{ 0x30330140, 0x0        },
+		{ 0x30330144, 0x0        },
+		{ 0x30330148, 0x0        },
+		{ 0x3033014C, 0x0        },
+		{ 0x30330150, 0x0        },
+		{ 0x30330154, 0x0        },
+		{ 0x30330158, 0x0        },
+		{ 0x30330180, 0x2        },
+		{ 0x30330184, 0x0        },
+		{ 0x30330188, 0x0        },
+		{ 0x3033018C, 0x0        },
+		{ 0x30330190, 0x0        },
+		{ 0x30330194, 0x0        },
+		{ 0x30330198, 0x0        },
+		{ 0x3033019C, 0x0        },
+		{ 0x303301A0, 0x0        },
+		{ 0x303301A4, 0x0        },
+		{ 0x303301A8, 0x0        },
+		{ 0x303301AC, 0x0        },
+		{ 0x303301BC, 0x0        },
+		{ 0x303301C0, 0x0        },
+		{ 0x303301C4, 0x0        },
+		{ 0x303301C8, 0x0        },
+		{ 0x303301E8, 0x0        },
+		{ 0x303301EC, 0x0        },
+		{ 0x303301FC, 0x1        },
+		{ 0x30330200, 0x1        },
+		{ 0x3033021C, 0x10       },
+		{ 0x30330220, 0x10       },
+		{ 0x30330224, 0x10       },
+		{ 0x30330228, 0x10       },
+		{ 0x3033022C, 0x12       },
+		{ 0x30330230, 0x12       },
+		{ 0x30330244, 0x0        },
+		{ 0x30330248, 0x0        },
+		{ 0x3033029C, 0x19       },
+		{ 0x303302A4, 0x19       },
+		{ 0x303302A8, 0x19       },
+		{ 0x303302B0, 0xD6       },
+		{ 0x303302C0, 0x4F       },
+		{ 0x303302C4, 0x16       },
+		{ 0x303302CC, 0x59       },
+		{ 0x3033033C, 0x9F       },
+		{ 0x30330340, 0xDF       },
+		{ 0x30330344, 0xDF       },
+		{ 0x30330348, 0xDF       },
+		{ 0x3033034C, 0xDF       },
+		{ 0x30330350, 0xDF       },
+		{ 0x30330368, 0x59       },
+		{ 0x30330370, 0x19       },
+		{ 0x3033039C, 0x19       },
+		{ 0x303303A0, 0x19       },
+		{ 0x303303A4, 0x19       },
+		{ 0x303303A8, 0xD6       },
+		{ 0x303303AC, 0xD6       },
+		{ 0x303303B0, 0xD6       },
+		{ 0x303303B4, 0xD6       },
+		{ 0x303303B8, 0xD6       },
+		{ 0x303303BC, 0xD6       },
+		{ 0x303303C0, 0xD6       },
+		{ 0x303303E8, 0xD6       },
+		{ 0x303303EC, 0xD6       },
+		{ 0x303303F0, 0xD6       },
+		{ 0x303303F4, 0xD6       },
+		{ 0x303303F8, 0xD6       },
+		{ 0x303303FC, 0xD6       },
+		{ 0x30330400, 0xD6       },
+		{ 0x30330404, 0xD6       },
+		{ 0x30330408, 0xD6       },
+		{ 0x3033040C, 0xD6       },
+		{ 0x30330410, 0xD6       },
+		{ 0x30330414, 0xD6       },
+		{ 0x30330424, 0xD6       },
+		{ 0x30330428, 0xD6       },
+		{ 0x3033042C, 0xD6       },
+		{ 0x30330430, 0xD6       },
+		{ 0x30330450, 0xD6       },
+		{ 0x30330454, 0xD6       },
+		{ 0x30330464, 0x49       },
+		{ 0x30330468, 0x49       },
+		{ 0x3033046C, 0x16       },
+		{ 0x30330484, 0x67       },
+		{ 0x30330488, 0x67       },
+		{ 0x3033048C, 0x67       },
+		{ 0x30330490, 0x67       },
+		{ 0x30330494, 0x76       },
+		{ 0x30330498, 0x76       },
+		{ 0x303304AC, 0x49       },
+		{ 0x303304B0, 0x49       },
+		{ 0x303304C8, 0x1        },
+		{ 0x303304CC, 0x4        },
+		{ 0x30330500, 0x1        },
+		{ 0x30330504, 0x2        },
+		{ 0x30340038, 0x49409600 },
+		{ 0x30340040, 0x49409200 }
+	};
+
+	unsigned num_values = sizeof(initial_values) / (2*sizeof(unsigned long));
+	for (unsigned i = 0; i < num_values; i++)
+		*((volatile Genode::uint32_t*)initial_values[i][0]) = (Genode::uint32_t)initial_values[i][1];
+}
+
+
+void Board::Cpu::wake_up_all_cpus(void * ip)
+{
+	enum Function_id { CPU_ON = 0xC4000003 };
+
+	unsigned long result = 0;
+	for (unsigned i = 1; i < NR_OF_CPUS; i++) {
+		asm volatile("mov x0, %1  \n"
+		             "mov x1, %2  \n"
+		             "mov x2, %3  \n"
+		             "mov x3, %2  \n"
+		             "smc #0      \n"
+		             "mov %0, x0  \n"
+		             : "=r" (result) : "r" (CPU_ON), "r" (i), "r" (ip)
+		                      : "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
+		                        "x8", "x9", "x10", "x11", "x12", "x13", "x14");
+	}
+}

repos/base-hw/src/bootstrap/spec/nit6_solox/board.h

@@ -18,11 +18,11 @@
 #include <spec/arm/cortex_a9_actlr.h>
 #include <spec/arm/cortex_a9_page_table.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Nit6_solox_board;
-
+	using Pic = Hw::Gicv2;
 	struct L2_cache;
 
 	static constexpr bool NON_SECURE = false;

repos/base-hw/src/bootstrap/spec/odroid_xu/board.h

@@ -17,10 +17,11 @@
 #include <hw/spec/arm/odroid_xu_board.h>
 #include <hw/spec/arm/lpae.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Odroid_xu_board;
+	using Pic = Hw::Gicv2;
 	static constexpr bool NON_SECURE = false;
 }
 

repos/base-hw/src/bootstrap/spec/odroid_xu/platform.cc

@@ -25,7 +25,9 @@ Bootstrap::Platform::Board::Board()
 
 unsigned Bootstrap::Platform::enable_mmu()
 {
-	board.pic.init_cpu_local();
+	/* locally initialize interrupt controller */
+	::Board::Pic pic { };
+
 	Cpu::Sctlr::init();
 	Cpu::Cpsr::init();
 	Cpu::invalidate_data_cache();

repos/base-hw/src/bootstrap/spec/panda/board.h

@@ -17,11 +17,11 @@
 #include <hw/spec/arm/panda_board.h>
 #include <spec/arm/cortex_a9_page_table.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Panda_board;
-
+	using Pic = Hw::Gicv2;
 	static constexpr bool NON_SECURE = false;
 
 	class L2_cache;

repos/base-hw/src/bootstrap/spec/pbxa9/board.h

@@ -19,11 +19,13 @@
 #include <spec/arm/cortex_a9_actlr.h>
 #include <spec/arm/cortex_a9_page_table.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Pbxa9_board;
 
+	using Pic = Hw::Gicv2;
+
 	static constexpr bool NON_SECURE = false;
 }
 

repos/base-hw/src/bootstrap/spec/riscv/board.h

@@ -16,10 +16,7 @@
 
 #include <hw/spec/riscv/board.h>
 
-namespace Board {
-	using namespace Hw::Riscv_board;
-	struct Pic {};
-}
+namespace Board { using namespace Hw::Riscv_board; }
 
 template <typename E, unsigned B, unsigned S>
 void Sv39::Level_x_translation_table<E, B, S>::_translation_added(addr_t, size_t)

repos/base-hw/src/bootstrap/spec/rpi/board.h

@@ -18,11 +18,7 @@
 #include <hw/spec/arm/page_table.h>
 #include <spec/arm/cpu.h>
 
-namespace Board {
-	using namespace Hw::Rpi_board;
-
-	struct Pic {};
-}
+namespace Board { using namespace Hw::Rpi_board; }
 
 
 constexpr unsigned Hw::Page_table::Descriptor_base::_device_tex() {

repos/base-hw/src/bootstrap/spec/rpi3/board.h

@@ -20,8 +20,13 @@
 
 namespace Board {
 	using namespace Hw::Rpi3_board;
-	using Cpu = Hw::Arm_64_cpu;
-	struct Pic {};
+
+	struct Cpu : Hw::Arm_64_cpu
+	{
+		static void wake_up_all_cpus(void*);
+	};
+
+	struct Pic { }; /* dummy object */
 };
 
 #endif /* _BOOTSTRAP__SPEC__RPI3__BOARD_H_ */

repos/base-hw/src/bootstrap/spec/rpi3/platform.cc

@@ -26,3 +26,20 @@ Bootstrap::Platform::Board::Board()
                             ::Board::LOCAL_IRQ_CONTROLLER_SIZE },
             Memory_region { ::Board::IRQ_CONTROLLER_BASE,
                             ::Board::IRQ_CONTROLLER_SIZE }) {}
+
+
+extern unsigned int _crt0_qemu_start_secondary_cpus;
+
+void Board::Cpu::wake_up_all_cpus(void * ip)
+{
+	/* start when in qemu */
+	_crt0_qemu_start_secondary_cpus = 1;
+
+	/* start on real hardware */
+	*((void * volatile *) 0xe0) = ip;   /* cpu 1 */
+	*((void * volatile *) 0xe8) = ip;   /* cpu 2 */
+	*((void * volatile *) 0xf0) = ip;   /* cpu 3 */
+
+	/* send event for both variants */
+	asm volatile("dsb #15; sev");
+}

repos/base-hw/src/bootstrap/spec/usb_armory/platform.cc

@@ -38,6 +38,8 @@ Bootstrap::Platform::Board::Board()
 	Aipstz aipstz_1(AIPS_1_MMIO_BASE);
 	Aipstz aipstz_2(AIPS_2_MMIO_BASE);
 
+	Pic pic {};
+
 	/* set monitor mode exception vector entry */
 	Cpu::Mvbar::write(Hw::Mm::system_exception_vector().base);
 

repos/base-hw/src/bootstrap/spec/wand_quad/board.h

@@ -18,11 +18,13 @@
 #include <spec/arm/cortex_a9_actlr.h>
 #include <spec/arm/cortex_a9_page_table.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Wand_quad_board;
 
+	using Pic = Hw::Gicv2;
+
 	struct L2_cache;
 
 	static constexpr bool NON_SECURE = false;

repos/base-hw/src/bootstrap/spec/x86_64/board.h

@@ -22,7 +22,6 @@
 namespace Board {
 	using namespace Hw::Pc_board;
 	using Cpu = Hw::X86_64_cpu;
-	struct Pic {};
 }
 
 #endif /* _SRC__BOOTSTRAP__SPEC__X86_64__BOARD_H_ */

repos/base-hw/src/bootstrap/spec/zynq_qemu/board.h

@@ -18,10 +18,11 @@
 #include <spec/arm/cortex_a9_actlr.h>
 #include <spec/arm/cortex_a9_page_table.h>
 #include <spec/arm/cpu.h>
-#include <spec/arm/gicv2.h>
+#include <hw/spec/arm/gicv2.h>
 
 namespace Board {
 	using namespace Hw::Zynq_qemu_board;
+	using Pic = Hw::Gicv2;
 	static constexpr bool NON_SECURE = false;
 }
 

repos/base-hw/src/core/cpu_session_support.cc

@@ -18,6 +18,9 @@
 #include <cpu_session_component.h>
 #include <kernel/configuration.h>
 
+/* base-internal includes */
+#include <base/internal/native_utcb.h>
+
 using namespace Genode;
 
 
@@ -33,3 +36,7 @@ Cpu_session::Quota Cpu_session_component::quota()
 	size_t const u = quota_lim_downscale<sizet_arithm_t>(_quota, spu);
 	return { spu, u };
 }
+
+
+size_t Cpu_session_component::_utcb_quota_size() {
+	return sizeof(Native_utcb); }

repos/base-hw/src/core/irq_session_component.cc

@@ -18,7 +18,6 @@
 /* core includes */
 #include <kernel/irq.h>
 #include <irq_root.h>
-#include <irq_args.h>
 #include <core_env.h>
 
 /* base-internal includes */
@@ -35,10 +34,7 @@ unsigned Irq_session_component::_find_irq_number(const char * const args)
 
 void Irq_session_component::ack_irq()
 {
-	using Kernel::User_irq;
-	if (!_sig_cap.valid()) { return; }
-	User_irq * const kirq = reinterpret_cast<User_irq*>(&_kernel_object);
-	Kernel::ack_irq(kirq);
+	if (_kobj.constructed()) Kernel::ack_irq(*_kobj);
 }
 
 
@@ -51,8 +47,8 @@ void Irq_session_component::sigh(Signal_context_capability cap)
 
 	_sig_cap = cap;
 
-	if (Kernel::new_irq((addr_t)&_kernel_object, _irq_number,
-	                    Capability_space::capid(_sig_cap)))
+	if (!_kobj.create(_irq_number, _irq_args.trigger(), _irq_args.polarity(),
+	                  Capability_space::capid(_sig_cap)))
 		warning("invalid signal handler for IRQ ", _irq_number);
 }
 
@@ -61,18 +57,16 @@ Irq_session_component::~Irq_session_component()
 {
 	using namespace Kernel;
 
-	User_irq * kirq = reinterpret_cast<User_irq*>(&_kernel_object);
 	_irq_alloc.free((void *)(addr_t)_irq_number);
-	if (_sig_cap.valid())
-		Kernel::delete_irq(kirq);
 }
 
 
 Irq_session_component::Irq_session_component(Range_allocator &irq_alloc,
                                              const char * const args)
-:
-	_irq_number(Platform::irq(_find_irq_number(args))), _irq_alloc(irq_alloc),
-	_is_msi(false), _address(0), _value(0)
+: _irq_args(args),
+  _irq_number(Platform::irq(_irq_args.irq_number())),
+  _irq_alloc(irq_alloc),
+  _kobj(), _is_msi(false), _address(0), _value(0)
 {
 	const long mmconf =
 		Arg_string::find_arg(args, "device_config_phys").long_value(0);
@@ -89,8 +83,4 @@ Irq_session_component::Irq_session_component(Range_allocator &irq_alloc,
 		error("unavailable interrupt ", _irq_number, " requested");
 		throw Service_denied();
 	}
-
-	Irq_args const irq_args(args);
-
-	Kernel::irq_mode(_irq_number, irq_args.trigger(), irq_args.polarity());
 }

repos/base-hw/src/core/irq_session_component.h

@@ -19,6 +19,8 @@
 #include <util/list.h>
 #include <irq_session/capability.h>
 
+#include <irq_args.h>
+#include <object.h>
 #include <kernel/irq.h>
 
 namespace Genode { class Irq_session_component; }
@@ -31,13 +33,13 @@ class Genode::Irq_session_component : public  Rpc_object<Irq_session>,
 
 		friend class List<Irq_session_component>;
 
-		unsigned         _irq_number;
-		Range_allocator &_irq_alloc;
-		Genode::uint8_t  _kernel_object[sizeof(Kernel::User_irq)];
-		bool             _is_msi;
-		addr_t           _address, _value;
-
-		Signal_context_capability _sig_cap { };
+		Irq_args const                  _irq_args;
+		unsigned                        _irq_number;
+		Range_allocator               & _irq_alloc;
+		Kernel_object<Kernel::User_irq> _kobj;
+		bool                            _is_msi;
+		addr_t                          _address, _value;
+		Signal_context_capability       _sig_cap { };
 
 		unsigned _find_irq_number(const char * const args);
 

repos/base-hw/src/core/kernel/core_interface.h

@@ -31,6 +31,7 @@ namespace Kernel
 	class Vm;
 	class User_irq;
 	using Native_utcb = Genode::Native_utcb;
+	template <typename T> class Core_object_identity;
 
 	/**
 	 * Kernel names of the kernel calls
@@ -60,15 +61,14 @@ namespace Kernel
 	constexpr Call_arg call_id_delete_obj()             { return 122; }
 	constexpr Call_arg call_id_cancel_thread_blocking() { return 123; }
 	constexpr Call_arg call_id_new_core_thread()        { return 124; }
-	constexpr Call_arg call_id_irq_mode()               { return 125; }
 
 	/**
 	 * Invalidate TLB entries for the `pd` in region `addr`, `sz`
 	 */
-	inline void invalidate_tlb(Pd * const pd, addr_t const addr,
+	inline void invalidate_tlb(Pd & pd, addr_t const addr,
 	                           size_t const sz)
 	{
-		call(call_id_invalidate_tlb(), (Call_arg)pd, (Call_arg)addr,
+		call(call_id_invalidate_tlb(), (Call_arg)&pd, (Call_arg)addr,
 		     (Call_arg)sz);
 	}
 
@@ -79,9 +79,9 @@ namespace Kernel
 	 * \param thread  kernel object of the targeted thread
 	 * \param quota   new CPU quota value
 	 */
-	inline void thread_quota(Kernel::Thread * const thread, size_t const quota)
+	inline void thread_quota(Kernel::Thread & thread, size_t const quota)
 	{
-		call(call_id_thread_quota(), (Call_arg)thread, (Call_arg)quota);
+		call(call_id_thread_quota(), (Call_arg)&thread, (Call_arg)quota);
 	}
 
 
@@ -104,9 +104,9 @@ namespace Kernel
 	 * continue the execution of a thread no matter what state the thread is
 	 * in.
 	 */
-	inline void pause_thread(Thread * const thread)
+	inline void pause_thread(Thread & thread)
 	{
-		call(call_id_pause_thread(), (Call_arg)thread);
+		call(call_id_pause_thread(), (Call_arg)&thread);
 	}
 
 
@@ -115,9 +115,9 @@ namespace Kernel
 	 *
 	 * \param thread  pointer to thread kernel object
 	 */
-	inline void resume_thread(Thread * const thread)
+	inline void resume_thread(Thread & thread)
 	{
-		call(call_id_resume_thread(), (Call_arg)thread);
+		call(call_id_resume_thread(), (Call_arg)&thread);
 	}
 
 
@@ -132,11 +132,11 @@ namespace Kernel
 	 * \retval   0  suceeded
 	 * \retval !=0  failed
 	 */
-	inline int start_thread(Thread * const thread, unsigned const cpu_id,
-	                        Pd * const pd, Native_utcb * const utcb)
+	inline int start_thread(Thread & thread, unsigned const cpu_id,
+	                        Pd & pd, Native_utcb & utcb)
 	{
-		return call(call_id_start_thread(), (Call_arg)thread, cpu_id,
-		            (Call_arg)pd, (Call_arg)utcb);
+		return call(call_id_start_thread(), (Call_arg)&thread, cpu_id,
+		            (Call_arg)&pd, (Call_arg)&utcb);
 	}
 
 
@@ -155,9 +155,9 @@ namespace Kernel
 	 * limit the time a parent waits for a server when closing a session
 	 * of one of its children.
 	 */
-	inline void cancel_thread_blocking(Thread * const thread)
+	inline void cancel_thread_blocking(Thread & thread)
 	{
-		call(call_id_cancel_thread_blocking(), (Call_arg)thread);
+		call(call_id_cancel_thread_blocking(), (Call_arg)&thread);
 	}
 
 
@@ -167,10 +167,10 @@ namespace Kernel
 	 * \param thread             pointer to thread kernel object
 	 * \param signal_context_id  capability id of the page-fault handler
 	 */
-	inline void thread_pager(Thread * const thread,
-	                         capid_t  const signal_context_id)
+	inline void thread_pager(Thread & thread,
+	                         capid_t const signal_context_id)
 	{
-		call(call_id_thread_pager(), (Call_arg)thread, signal_context_id);
+		call(call_id_thread_pager(), (Call_arg)&thread, signal_context_id);
 	}
 
 
@@ -179,9 +179,9 @@ namespace Kernel
 	 *
 	 * \param vm  pointer to vm kernel object
 	 */
-	inline void run_vm(Vm * const vm)
+	inline void run_vm(Vm & vm)
 	{
-		call(call_id_run_vm(), (Call_arg) vm);
+		call(call_id_run_vm(), (Call_arg) &vm);
 	}
 
 
@@ -190,33 +190,9 @@ namespace Kernel
 	 *
 	 * \param vm  pointer to vm kernel object
 	 */
-	inline void pause_vm(Vm * const vm)
+	inline void pause_vm(Vm & vm)
 	{
-		call(call_id_pause_vm(), (Call_arg) vm);
-	}
-
-	/**
-	 * Create an interrupt object
-	 *
-	 * \param p                 memory donation for the irq object
-	 * \param irq_nr            interrupt number
-	 * \param signal_context_id capability id of the signal context
-	 */
-	inline int new_irq(addr_t const p, unsigned irq_nr,
-	                   capid_t signal_context_id)
-	{
-		return call(call_id_new_irq(), (Call_arg) p, irq_nr, signal_context_id);
-	}
-
-	/**
-	 * Set trigger/polaruty of IRQ
-	 * \param  irq_nr   interrupt number
-	 * \param  trigger  low or edge
-	 * \param  polarity low or high
-	 */
-	inline void irq_mode(unsigned irq_nr, unsigned trigger, unsigned polarity)
-	{
-		call(call_id_irq_mode(), irq_nr, trigger, polarity);
+		call(call_id_pause_vm(), (Call_arg) &vm);
 	}
 
 	/**
@@ -224,40 +200,9 @@ namespace Kernel
 	 *
 	 * \param irq  pointer to interrupt kernel object
 	 */
-	inline void ack_irq(User_irq * const irq)
+	inline void ack_irq(User_irq & irq)
 	{
-		call(call_id_ack_irq(), (Call_arg) irq);
-	}
-
-	/**
-	 * Destruct an interrupt object
-	 *
-	 * \param irq  pointer to interrupt kernel object
-	 */
-	inline void delete_irq(User_irq * const irq)
-	{
-		call(call_id_delete_irq(), (Call_arg) irq);
-	}
-
-	/**
-	 * Create a new object identity for a thread
-	 *
-	 * \param dst  memory donation for the new object
-	 * \param cap  capability id of the targeted thread
-	 */
-	inline capid_t new_obj(void * const dst, capid_t const cap)
-	{
-		return call(call_id_new_obj(), (Call_arg)dst, (Call_arg)cap);
-	}
-
-	/**
-	 * Destroy an object identity
-	 *
-	 * \param dst pointer to the object identity object
-	 */
-	inline void delete_obj(void * const dst)
-	{
-		call(call_id_delete_obj(), (Call_arg)dst);
+		call(call_id_ack_irq(), (Call_arg) &irq);
 	}
 }
 

repos/base-hw/src/core/kernel/cpu.cc

@@ -40,7 +40,7 @@ void Cpu_job::_activate_own_share() { _cpu->schedule(this); }
 void Cpu_job::_deactivate_own_share()
 {
 	assert(_cpu->id() == Cpu::executing_id());
-	_cpu->scheduler().unready(this);
+	_cpu->scheduler().unready(*this);
 }
 
 
@@ -74,13 +74,13 @@ void Cpu_job::_interrupt(unsigned const /* cpu_id */)
 void Cpu_job::affinity(Cpu &cpu)
 {
 	_cpu = &cpu;
-	_cpu->scheduler().insert(this);
+	_cpu->scheduler().insert(*this);
 }
 
 
 void Cpu_job::quota(unsigned const q)
 {
-	if (_cpu) { _cpu->scheduler().quota(this, q); }
+	if (_cpu) { _cpu->scheduler().quota(*this, q); }
 	else { Cpu_share::quota(q); }
 }
 
@@ -93,7 +93,7 @@ Cpu_job::Cpu_job(Cpu_priority const p, unsigned const q)
 Cpu_job::~Cpu_job()
 {
 	if (!_cpu) { return; }
-	_cpu->scheduler().remove(this);
+	_cpu->scheduler().remove(*this);
 }
 
 
@@ -115,8 +115,13 @@ Cpu::Idle_thread::Idle_thread(Cpu &cpu)
 
 void Cpu::schedule(Job * const job)
 {
-	if (_id == executing_id()) { _scheduler.ready(&job->share()); }
-	else if (_scheduler.ready_check(&job->share())) { trigger_ip_interrupt(); }
+	if (_id == executing_id()) { _scheduler.ready(job->share()); }
+	else {
+		_scheduler.ready_check(job->share());
+		if (_scheduler.need_to_schedule()) {
+			trigger_ip_interrupt();
+		}
+	}
 }
 
 
@@ -140,7 +145,8 @@ Cpu_job & Cpu::schedule()
 		_scheduler.update(_timer.time());
 		time_t t = _scheduler.head_quota();
 		_timer.set_timeout(this, t);
-		_timer.schedule_timeout();
+		time_t duration = _timer.schedule_timeout();
+		old_job.update_execution_time(duration);
 	}
 
 	/* return new job */
@@ -157,11 +163,11 @@ addr_t Cpu::stack_start() {
 	return (addr_t)&kernel_stack + KERNEL_STACK_SIZE * (_id+1); }
 
 
-Cpu::Cpu(unsigned const id, Board::Pic & pic,
+Cpu::Cpu(unsigned const id,
          Inter_processor_work_list & global_work_list)
 :
-	_id(id), _pic(pic), _timer(*this),
-	_scheduler(&_idle, _quota(), _fill()), _idle(*this),
+	_id(id), _timer(*this),
+	_scheduler(_idle, _quota(), _fill()), _idle(*this),
 	_ipi_irq(*this),
 	_global_work_list(global_work_list)
 { _arch_init(); }
@@ -174,7 +180,7 @@ Cpu::Cpu(unsigned const id, Board::Pic & pic,
 bool Cpu_pool::initialize()
 {
 	unsigned id = Cpu::executing_id();
-	_cpus[id].construct(id, _pic, _global_work_list);
+	_cpus[id].construct(id, _global_work_list);
 	return --_initialized == 0;
 }
 

repos/base-hw/src/core/kernel/cpu.h

@@ -112,7 +112,7 @@ class Kernel::Cpu : public Genode::Cpu, private Irq::Pool, private Timeout
 
 
 		unsigned const _id;
-		Board::Pic    &_pic;
+		Board::Pic     _pic {};
 		Timer          _timer;
 		Cpu_scheduler  _scheduler;
 		Idle_thread    _idle;
@@ -132,7 +132,7 @@ class Kernel::Cpu : public Genode::Cpu, private Irq::Pool, private Timeout
 		/**
 		 * Construct object for CPU 'id'
 		 */
-		Cpu(unsigned const id, Board::Pic & pic,
+		Cpu(unsigned const id,
 		    Inter_processor_work_list & global_work_list);
 
 		static inline unsigned primary_id() { return 0; }
@@ -169,7 +169,7 @@ class Kernel::Cpu : public Genode::Cpu, private Irq::Pool, private Timeout
 		 * Returns the currently active job
 		 */
 		Job & scheduled_job() const {
-			return *static_cast<Job *>(_scheduler.head())->helping_sink(); }
+			return *static_cast<Job *>(&_scheduler.head())->helping_sink(); }
 
 		unsigned id() const { return _id; }
 		Cpu_scheduler &scheduler() { return _scheduler; }
@@ -178,6 +178,11 @@ class Kernel::Cpu : public Genode::Cpu, private Irq::Pool, private Timeout
 
 		Inter_processor_work_list & work_list() {
 			return _local_work_list; }
+
+		/**
+		 * Return CPU's idle thread object
+		 */
+		Kernel::Thread &idle_thread() { return _idle; }
 };
 
 
@@ -191,7 +196,6 @@ class Kernel::Cpu_pool
 {
 	private:
 
-		Board::Pic                 _pic {};
 		Inter_processor_work_list  _global_work_list {};
 		unsigned                   _count;
 		unsigned                   _initialized { _count };

repos/base-hw/src/core/kernel/cpu_context.h

@@ -35,6 +35,8 @@ class Kernel::Cpu_job : private Cpu_share
 
 		friend class Cpu; /* static_cast from 'Cpu_share' to 'Cpu_job' */
 
+		time_t _execution_time { 0 };
+
 		/*
 		 * Noncopyable
 		 */
@@ -112,6 +114,16 @@ class Kernel::Cpu_job : private Cpu_share
 		 */
 		bool own_share_active() { return Cpu_share::ready(); }
 
+		/**
+		 * Update total execution time
+		 */
+		void update_execution_time(time_t duration) { _execution_time += duration; }
+
+		/**
+		 * Return total execution time
+		 */
+		time_t execution_time() const { return _execution_time; }
+
 
 		/***************
 		 ** Accessors **