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
