This patch takes precautions against the use of blocking packet-stream
operations like 'submit_packet'.
With the change of issue #4388, the ready-to-submit signals are no
longer implicitly handled. Hence, a call of submit_packet to a
saturated submit queue blocks infinitely.
Issue #4390
* use 'Id_space::apply_any' instead of 'for_each' to destroy session local
buffer objects
* save session capability in session because 'cap()' is not valid in
'Session_component' destructor because it was dissolved before calling
'Root::_destruct_session', the cap is necessary to remove owned
buffers from the EP
issue #4380
Add 'export_buffer'/'import_buffer' calls in order to support buffer
sharing between GPU sessions.
Reduce CAP costs for Gpu::Connection from 256 to 32.
issue #4380
Account RAM and CAP resources for GPU sessions and trigger client
upgrades before allocating resources at the multiplexer. This prevents
the multiplexer from running out of resources.
issue #4380
Imagine receiving the signal for an available TX ack or an available RX packet
at the Uplink connection but a later received signal for a link-state change
(to link state "down") at the same connection is handled first and destructs
the Uplink connection before the handling of the former signals. In this case,
the methods 'Uplink_client_base::_conn_tx_handle_ack_avail' and
'Uplink_client_base::_conn_rx_handle_packet_avail' must be guarded against an
unconstructed '_conn' member, but they weren't so far.
Fixes#4384
So far, the generic Uplink connection code considered NIC drivers to transmit
connection RX packets in three different manners. Most of the drivers follow
the "normal" way of transmission with only one driver callback from generic
code. The monolithic USB NIC-driver, however, used to send in a "burst" mode
that required a dedicated path with multiple driver callbacks in the generic
code. And then there were drivers that had a fully custom function for doing
transmissions.
Also for handling connection TX acks, there was a "normal" and a
"custom handler" way.
Today, all NIC drivers in the Genode repos and the Genode-World repo follow the
"normal" way. Therefor, the unused code can be removed.
Ref #4384
This patch equips Sculpt with the ability to customize the system image
in very flexible ways.
All customizable aspects of the image have been relocated from the
former sculpt.run script and the accompanied gems/run/sculpt/ directory
to a new location - the sculpt/ directory - which can exist in any
repository. The directory at repos/gems/sculpt/ serves as reference.
The sculpt directory can host any number of <name>-<board>.sculpt files,
each containing a list of ingredients to be incorporated into the
Sculpt system image. The <name> can be specified to the sculpt.run
script. E.g., the following command refers to the 'default-pc.sculpt'
file:
make run/sculpt KERNEL=nova BOARD=pc SCULPT=default
If no 'SCULPT' argument is supplied, the value 'default' is used.
A .sculpt file refers to a selection of files found at various
subdirectries named after their respective purpose. In particular, There
exists a subdirectory for each file in Sculpt's config fs, like
nitpicker, drivers... The .sculpt file selects the alternative to use
by a simple tag-value notation.
drivers: pc
The supported tags are as follows.
*Optional* selection of /config files. If not specified, those files are
omitted, which prompts Sculpt to manage those configurations
automatically or via the Leitzentrale GUI:
fonts
nic_router
event_filter
wifi
runtime
gpu_drv
Selection of mandatory /config files. If not specified, the respective
'default' alternative will be used.
nitpicker
deploy
fb_drv
clipboard
drivers
numlock_remap
leitzentrale
usb
system
ram_fs
Furthermore, the .sculpt file supports the optional selection of
supplemental content such as a set of launchers.
launches: nano3d system_shell
Another type of content are the set of blessed pubkey/download files
used for installing and verifying software on target.
With the new version, it has become possible to supply a depot with the
the system image. The depot content is assembled according to the 'pkg'
attributes found in launcher files and the selected deploy config.
The resulting depot is incorporated into the system image as 'depot.tar'
archive. It can be supplied to the Sculpt system by mounting it into the
ram fs as done by the 'ram_fs/depot' configuration for the ram fs.
It is possible to add additional boot modules to the system image. There
are two options.
build: <list of targets>
This tag prompts the sculpt.run script to build the specified targets
directly using the Genode build system and add the created artifacts
into the system image as boot modules.
import: <list of depot src or pkg archives>
This tag instructs Sculpt to supply the specifid depot-archive content
as boot modules to the system image. This change eliminates the need for
board-specific pkg/sculpt-<board> archives. The board-specific
specializations can now be placed directly into the respective .sculpt
files by using 'import:'.
To make the use of Sculpt as testbed during development more convenient,
the log output of the drivers, leitzentrale, and runtime subsystems
can be redirected to core using the optional 'LOG=core' argument, e.g.,
make run/sculpt KERNEL=linux BOARD=linux LOG=core
The former pkg/sculpt-installation and pkg/sculpt-installation-pc
archives have been replaced by pkg/sculpt_distribution-pc, which
references the generic pkg/sculpt_distribution archive. Those pkgs are
solely used for publishing / distribution purposes.
Fixes#4369
Fix some trivial cases where the signedness of the constant value does
not match the signedness of type the code expects to see. GCC can be
asked to warn about those by passing Wsign-covnersion flag.
Issue #4354
This comes up when building the code with clang 13. It happens due to
recently enabled Wconversion warning, which in case of clang also
enables implicit-int-conversion warning. The warning reads:
fs_file_system.h:937:44: error: higher order bits are zeroes after
implicit conversion [-Werror,-Wimplicit-int-conversion]
::File_system::Watch_handle fs_handle { -1U };
~~~~~~~~~ ^~~
This can be fixed by properly specifying fs_handle value to be of
unsigned long type.
Issue #4354
Remove '_expected_offset' check on round trip test from RX packet,
because allocators between RX/TX can have different allocation
strategies. Rely on 'pattern' check for RX packets only.
In loopback server alloc size must match actual packet size.
issue #4312
Override 'try_alloc/free' because ethernet frame headers are 14 bytes
(src/dst mac (12) + ethertype (2)) causing the IP header to be 2 byte
aligned, leading to problems on platforms that require load/store
operations to be naturally aligned when reading, for example, 4 byte IP
addresses. Therefore, we align the allocation to 2 bytes, so the IP
header is aligned to 4.
issue #4312
This patch improves the robustness of the CPU-affinity handling.
- The types in base/affinity.h received the accessors
'Location::within(space)' and 'Affinity::valid', which alleviates
the fiddling with coordinates when sanity checking the values,
in init or core.
- The 'Affinity::Location::valid' method got removed because its
meaning was too vague. For sanity checks of affinity configurations,
the new 'within' method is approriate. In cases where only the x,y
values are used for selecting a physical CPU (during thread creation),
the validity check (width*height > 0) was not meaningful anyway.
- The 'Affinity::Location::from_xml' requires a 'Affinity::Space'
as argument because a location always relates to the bounds of
a specific space. This function now implements the selection of
whole rows or columns, which has previously a feature of the
sandbox library only.
- Whenever the sandbox library (init) encounters an invalid affinity
configuration, it prints a warning message as a diagnostic aid.
- A new 'Affinity::unrestricted' function constructs an affinity that
covers the whole affinity space. The named functions clarifies
the meaning over the previous use of the default constructor.
- Core's CPU service denies session requests with an invalid
affinity parameter. Previously, it would fall back to an
unrestricted affinity.
Issue #4300
After VirtIO::Queue refactoring buffers no longer share the same
dataspace as VirtIO rings. This makes optimal buffer calculations a lot
easier. In this case 64 buffers 2kB each will need precisely 128kB of
RAM. Previous value of 2016 will just waste 768b.
Fixed#4347
The key changes in this patch are:
* Buffer allocation is moved into a separate Buffer_pool helper. The
implementation of the buffer allocation strategy does not change.
The helper allocates a single RAM dataspace and splits it in multiple,
equally sized chunks.
* Management of main descriptor ring is enacapsulated in Descriptor_ring
helper class.
* Use separate RAM dataspaces for descriptor rings and buffers.
Previously both of them were packed into a single dataspace. This
might have been more RAM efficient, but IMO it made the code uglier and
harder to understand.
* All of the VirtIO::Queue members are now initialized on the class member
initializer list. This is possible due to previously listed changes.
* Since all VirtIO::Queue members are initalized on member initalizer
list, some additional ones can be marked as const, ex _avail, _used ring
pointers.
* Move descriptor writing code into a common method used by both
write_data and write_data_read_reply members. This avoids some code
duplication between those methods.
* Get rid of request_irq argument that most public VirtIO::Queue methods
accept. None of the existing drivers use it and I doubt this will
change any time soon.
* Use Genode namespace by default in Virtio.
This patch also fixes at least one bug that I discovered while working
on VirtIO block device driver. Namely, when chaining descriptors only the
first descriptor in the chain should be exposed in the available ring.
Issue #4347
The const-variant of the data() method contained an erroneous
calculation of the tail size. This led to the size guard throwing
exceptions when trying to parse TCP packets that only contained the
TCP header.
Fixesgenodelabs/genode#4340
Thanks to Piotr Tworek for the fix and his explanation as follows:
The basic idea is to try to fit payload data into the descriptor used to
send the header. If there is no payload, or the payload fits exactly
into the remaining space in the header decriptor, len should be 0 and
only one descriptor should be used. In such case the "next" and "flags"
members of the descriptor structure should be set to 0.
In case there is some extra payload data to send, but its size is
bigger than the remaining free space in the descriptor used to send the
header, len should contain the remaining size of the payload that
can't be sent via the header descriptor. The code will then chain
additional descriptors to handle this remainder.
With the len variable shadowing, the code will never queue the remaining
data.
Issue #4327
Share datastructures for clock, power and reset related configurations
per device. In the generic platform driver component these structures
are kept empty. Driver derivates can fill the clocks settings, power and
reset switches with life. The former Driver::Env gets removed.
Fix#4338
This change of the inner working of the platform driver for ARM allows
clients to have permanent open sessions, as long as a policy node matches
the client. If devices disappear from the policy resp. from the set of
available devices (hotplug), the devices ROM of the session gets updated,
and a corresponding device session gets closed. If the device remains
untouched in the configuration but other devices appeared/disappeared, the
device session is not affected.
Ref #4330
* Only give managing_system permission when all parent nodes of the
corresponding component agree in doing so.
* Move the physical memory constrains heuristic from sandbox library to core
Fix#4335
* Track all caps and ram quotas of the sub-sessions properly
* Release DMA buffers, it is not done implicitely when destroying
the Constrained_ram_allocator
* Do not replenish quota before really releasing memory from
the allocator
Issue #4330
The Session_component must be destroyed before updating the device
model because the Session_component must also release all previously
acquired devices. If the device model is updated before, the devices
might have been removed.
Issue #4330
Pre-allocate all possible type of policy objects as part of the thread meta
state to avoid increased memory consumption due to different policy object
sizes. The cpu_balancer accounts the memory per client and can't forward
potentially occurring out-of-ram exceptions during config-ROM update phases.
Fixes#4333
The commits avoids reading in and allocating memory for all potentially
threads, which are potentially currently not existent (but configured in the
policy beforehand). Instead the policy is read in and evaluated when a thread
is created and policy changes are solely applied to existing/running threads.
By this the commit avoids the increase of memory consumption during the
evaluation of policies during config ROM updates.
Issue #4333
This implements the necessary bits to provide 2D framebuffer support on
top of VirtIO GPU device as implemented in Qemu. I don't know if any
other implementation of this specific device exists.
Compared to the ramfb driver which already exists in Genode Virtio FB driver
has one major benefit. It allows Qemu window to be dynamically resized at
runtime. The driver will treat this as resolution change and act accordingly.
Ramfb driver can currently only use the hardcoded 1024x768 screen size. Changing
screen resolution might not sound like a big deal, but it is rather useful to
run Genode on Qemu in full screen mode.
Some more advanced devices like VirtIO GPU do expect they can receive
responses to VirtIO commands they issue via VirtIO queue. Such responses
are not sent via a separate device writeable queue. Instead the driver
is expected to queue some additional descriptors and buffers which the
device can then use to provide the reply.
This patch adds support for such write-data-read-response opeartion to
Genode VirtIO::Queue implementation. The implementation is pretty simple
and does not support any fancy features like receiving the response
asynchronously. Instead the operation will use caller provided callback
to wait for the device to process the command. Once this callback
returns the write-data-read-response VirtIO::Queue function will invoke
another callback passing received response as argument.
Mesa queries information about the underlying device and this header
denotes the layout of the information. It is also used by the driver
itself to populate the 'info_dataspace'.
Issue #4329.
This filter bridges the gap between a touchscreen driver, which
generates raw touch events and traditional GUI applications that expect
a pointer (absolute motion, press/release of the left mouse button).
Fixes#4332
This patch changes the 'Allocator' interface to the use of 'Attempt'
return values instead of using exceptions for propagating errors.
To largely uphold compatibility with components using the original
exception-based interface - in particluar use cases where an 'Allocator'
is passed to the 'new' operator - the traditional 'alloc' is still
supported. But it existes merely as a wrapper around the new
'try_alloc'.
Issue #4324
Since the top-level node of the output ROM is always generated by the
rom_filter, there is no way to pass-through the content of an input ROM
without wrapping in an addition XML node.
genodelabs/genode#4326
This patch makes the test less dependent on the rate of state updates by
calculating the upgraded quota from the values found in the state report
instead of simply increasing the '_ram_quota' for each incoming report.
This patch replaces the 'Ram_allocator::alloc' RPC function by a
'try_alloc' function, which reflects errors as 'Attempt' return value
instead of an exception.
Issue #4322
Issue #3612
The new interfaces are meant to gradually replace the existing
Gpio_session interface.
- Each session refers to a single pin.
- The session types distiguish the direction of the signal as input or
output.
- Pin coordinates can be selected via session labels.
- GPIO interrupts are covered by the regular IRQ session interface.
The interfaces are accompanied by framework utilities and interfaces:
- os/pin_driver.h
- pin_control_session/component.h
- pin_state_session/component.h
These headers relieve GPIO drivers from implementing boilerplate code by
providing device-agnostic portions. The A64 pio driver serves as
reference for using those utilities.
https://github.com/nfeske/genode-allwinner/tree/master/src/drivers/pin/a64Fixes#4315
Accidentally, the size of IOMEM dataspace got accounted within the
implementation of the platform driver for ARM. Instead we should
only account a bit for the metadata and paging of the I/O memory.
Fix#4307
The custom ack avail handler is required for zero-copy nic drivers (e.g.
the zynq nic driver), which must release the corresponding DMA buffers.
Fixesgenodelabs/genode#4277
This component can service Qemu VirtIO mouse, keyboard and tablet
devices. The implementation is based on VirtIO 1.1 device spec. Its
described in section 5.8 "Input Device".
Issue #4282
- CPU-architecture annotations
- Change order of top-level menu, moving Mesa driver to the end
- Add black_hole, recall_fs, file_fault
- Add usb_webcam, test-capture
- Add audio driver and mixer
- Add vbox6, keeping vbox5-nova-sculpt as fallback
- Remove recall_fs launcher, which is obsolete with the recall_fs pkg
- Replace system_clock by system_clock-pc pkg
Issue #4281
This patch extends the notion of having only one uniquely hovered client
in the presence of held keys.
If motion occurs once a key is pressed (e.g., while dragging), the
receiver of the key sequence observes the motion events. In this case,
we have to submit an artificial leave event to the originally hovered
client so that no more than one client observes itself as being hovered
at the same time. Once the key sequence is finished, the hovering is
updated again, eventually presenting a motion event to the originally
hovered client and a leave event to the receiver of the key sequence.
Issue #4176
The new 'Env::try_session' method mirrors the existing 'Env::session'
without implicitly handling exceptions of the types 'Out_of_ram',
'Out_of_caps', 'Insufficient_ram_quota', and 'Insufficient_cap_quota'.
It enables runtime environments like init to reflect those exceptions to
their children instead of paying the costs of implicit session-quota
upgrades out of the own pocket.
By changing the 'Parent_service' to use 'try_session', this patch fixes
a resource-exhaustion problem of init in Sculpt OS that occurred when
the GPU multiplexer created a large batch of IO_MEM sessions, with each
session requiring a second attempt with the session quota upgraded by
4 KiB.
Issue #3767
'Out_of_ram' was so far the only exception a client had to deal with
during buffer managment. Allocating memory, however, does not only
consume RAM quota but CAP quota as well.
This commit tries to mitigate that shortcoming by reflecting the
'Out_of_caps' state back to the client. Furthermore it allows for
resource accounting on certain client allocations, e.g. buffers.
Fixes#4284.
Allocating and mapping buffers not only consumes RAM quota, it consumes
CAP quota as well. Extended the Gpu session to allow for dealing with
that on the client side.
On a side note, the amount of initial CAP quota needed to establish
a connection is increased to cover the current costs of the Intel
GPU multiplexer.
Issue #4284.
The platform driver uses a 'Constrained_ram_allocator' to allocate
meta-data on behave of a client. It uses the PD session as
'Ram_allocator' back end that in return is implemented via the
'Expanding_pd_session_client'.
Whenever the PD client itselft comes into resource shortage it will
ask its parent unconditionally. However, depending on the integration,
such a request may be left unanswered.
This commit introduces a check to prevent that situation from
occurring. In case the platform driver notices the resource shortage
it will reflect that back to the client.
Issue #4284.
ROM clients have to request an initial update of dynamic ROMs explicitly
and should not depend on artificial signals from the ROM session on
signal-handler registration.
Issue #4274
The sequence app should immediately stop the child when it called
parent().exit(). Otherwise, the child will continue execution which
causes a race condition: The child's ld.lib.so will eventually destruct
an Attached_rom_dataspace for the config rom. If sequence destructed the
corresponding service first, we will get an Ipc_error.
genodelabs/genode#4267
This patch introduces a C API to be used by input drivers to generate
Genode events. The initial version is limited to multitouch events only.
Fixes#4273
The former implementation did not internally track ROM changes notified
vs. delivered to the client. We adapt the versioning implementation
implemented in dynamic_rom_session.h and enable explicit notification of
the current version.
The feature is used by the clipboard to notify permitted readers of the
clipboard ROM service on focus change via the newly created private
Rom::Module::_notify_permitted_readers() function.
Fixes#4274
The various mapping methods are modelled after the requirements of
the Intel GPUs or rather the Mesa driver back end.
With upcoming support for other driver back ends, we need to
sequeeze their requirements in as well. For now hijack 'map_buffer'
to provide for specifying the kind of attributes the client needs.
For now all buffers mapped in the GGTT for Intel GPUs are treated
as RW.
Issue #4265.
This call allows for checking if the given execution buffer has been
completed and complements the completion signal. Initially the GPU
multiplexer always sent such a signal when the currently scheduled
execution buffer has been completed. During enablement of the 'iris'
driver it became necessary to properly check of sequence number.
In case of the Intel GPU multiplexer the sequence numbers are
continous, which prompted the greater-than-or-equal check in the
DRM back end. By hidding this implementation detail behind the
interface, GPU drivers are free to deal with sequence numbers any
way they like and allows for polling in the client, where the
completion signal is now more of a progress signal.
Issue #4265.
The current info implementation (as RPC) is limited in a few ways:
* The amount of data that may be transferred is constrained by the
underlying base platform
* Most information never changes during run time but is copied
nonetheless
* The information differs depending on the used GPU device and
in its current implementation only contains Intel GPU specific
details
With this commit the 'info' RPC call is replaced with the
'info_dataspace' call that transfers the capability for the dataspace
containing the information only. This is complemented by a client
local 'attached_info' call that allows for getting typed access to
the information. The layout of the information is moved to its own
and GPU-specific header file, e.g., 'gpu/info_intel.h'
Issue #4265.
Rather than using the dataspace capability directly, let the client
choose its own local identifier that is linked to the underlying
capability.
Fixes#4265.
Right now the warning about failure to forward packet from driver to
uplink RX connection reads:
"exception while trying to forward packet from driverto Uplink
connection TX"
Add missing space between "driver" and "to".
Issue #4264
32KB is a rather small value. The driver can cope with it now, but
it does not perform as well as it should. This visible especially
in scenarions like nic_router_flood where we still often hit
synchronous wait path. Bump the size to 256kB.
Issue #4264
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
The contents of those descriptor rings can be modified by the device.
Mark them as volatile so the compiler does not make any assumptions
about them.
Issue #4264
