mirror of
https://github.com/genodelabs/genode.git
synced 2025-01-19 03:06:39 +00:00
Genode OS Framework
armcpluspluscppframeworkgenodegoahypervisorlinuxmicrokernelnovaobject-capabilitiesoperating-systemosdevriscvsculpt-ossel4virtualizationx86
880cd3a490
The problem can be seen when running nic_router_flood scenarion on arm qemu_virt boards. With the amount of data this scenario tries to send the driver quickly complains it has failed to push data into TX VirtIO queue. After this warning message is printed nothing really happens and after a while the test scenario fails. The fact that we can't write all available data to the device is not unexpected. VirtIO queue size is slected at initialization time and we don't change it during driver lifetime. It can be tweaked via driver config, but this does not change the fact that we'll always be able to produce more data packets than we have free space in the VirtIO queue. IMO the expected behavior of the driver in such case should be to: 1. Notify the device there is data to process. 2. Wait for the device to process at least part of it. 3. Retry sending queued packets. One could expect returning Transmit_result::RETRY from _drv_transmit_pkt would produce such result. Unfortunately it seems that Uplink_client_base treats RETRY return value as indication of link being down. It'll retry sending the packet only after the device notifies it the link is once again up. This is the reason why nothing happens when running nic_router_flood on top of virtio_nic driver. The link never goes down in this case so once we fill the TX VirtIO queue and tell the base class to retry the send, we'll be stuck waiting for link up change event which will never arrive. To fix this problem, when sending a packet to the device fails, do a synchrnonus TX VirtIO queue flush (tell device there is data to process and wait until its done with it). With this fix in place nic_router_flood test scenario passes on both arm qemu_virt boards. Issue #4264 |
||
|---|---|---|
| depot | ||
| doc | ||
| repos | ||
| tool | ||
| .gitignore | ||
| LICENSE | ||
| README | ||
| VERSION | ||
=================================
Genode Operating System Framework
=================================
This is the source tree of the reference implementation of the Genode OS
architecture. For a general overview about the architecture, please refer to
the project's official website:
:Official project website for the Genode OS Framework:
[https://genode.org/documentation/general-overview]
The current implementation can be compiled for 8 different kernels: Linux,
L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom
kernel for running Genode directly on ARM-based hardware. Whereas the Linux
version serves us as development vehicle and enables us to rapidly develop the
generic parts of the system, the actual target platforms of the framework are
microkernels. There is no "perfect" microkernel - and neither should there be
one. If a microkernel pretended to be fit for all use cases, it wouldn't be
"micro". Hence, all microkernels differ in terms of their respective features,
complexity, and supported hardware architectures.
Genode allows the use of each of the kernels listed above with a rich set of
device drivers, protocol stacks, libraries, and applications in a uniform way.
For developers, the framework provides an easy way to target multiple different
kernels instead of tying the development to a particular kernel technology. For
kernel developers, Genode contributes advanced workloads, stress-testing their
kernel, and enabling a variety of application use cases that would not be
possible otherwise. For users and system integrators, it enables the choice of
the kernel that fits best with the requirements at hand for the particular
usage scenario.
Documentation
#############
The primary documentation is the book "Genode Foundations", which is available
on the front page of Genode website:
:Download the book "Genode Foundations":
[https://genode.org]
The book describes Genode in a holistic and comprehensive way. It equips you
with a thorough understanding of the architecture, assists developers with the
explanation of the development environment and system configuration, and
provides a look under the hood of the framework. Furthermore, it contains the
specification of the framework's programming interface.
The project has a quarterly release cycle. Each version is accompanied with
detailed release documentation, which is available at the documentation
section of the project website:
:Release documentation:
[https://genode.org/documentation/release-notes/]
Directory overview
##################
The source tree is composed of the following subdirectories:
:'doc':
This directory contains general documentation along with a comprehensive
collection of release notes.
:'repos':
This directory contains the source code, organized in so-called source-code
repositories. Please refer to the README file in the 'repos' directory to
learn more about the roles of the individual repositories.
:'tool':
Source-code management tools and scripts. Please refer to the README file
contained in the directory.
:'depot':
Directory used by Genode's package-management tools. It contains the public
keys and download locations of software providers.
Additional community-maintained components
##########################################
The components found within the main source tree are complemented by a growing
library of additional software, which can be seamlessly integrated into Genode
system scenarios.
:Genode-world repository:
[https://github.com/genodelabs/genode-world]
Contact
#######
The best way to get in touch with Genode developers and users is the project's
mailing list. Please feel welcome to join in!
:Genode Mailing Lists:
[https://genode.org/community/mailing-lists]
Commercial support
##################
The driving force behind the Genode OS Framework is the German company Genode
Labs. The company offers commercial licensing, trainings, support, and
contracted development work:
:Genode Labs website:
[https://www.genode-labs.com]