'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.
Some guests don't handle remote wake up correctly causing devices to
stop functioning. Therefore, we disable the remote wake up bit (5) in
`bmAttributes` of the device configuration descriptor.
Thanks to Peter for the initial fix.
Fixes#4278
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.
* Wait for for completion before return from 'execbuffer2'. This makes
buffer execution synchronous.
* Because the Iris driver manages the virtual address space of the GPU
and creates one GEM context for each batch buffer we have to map/unmap
all buffer objects before and after batch buffer execution.
issue #4260
This patch adds a switch to internal poll function in libssh that
allows to force this function to immediately return without actually
polling for data and in consequence processing this data. This switch
is used to avoid calling callback functions when flushing output
streams which caused locks due to recursive access to internal
ssh_terminal sessions registry.
Issue #4258
This patch allows to replace sftp packet read and write with
completely asynchronous versions needed to properly hook in existing
ssh_terminal implementation.
Issue #4258
* Switch mesa support from DRI to gallium
Supported drivers are
- softpipe (Sebstian Sumpf)
- iris for Intel GPUs (Alexander Boetcher)
- etnaviv for Vivante GPUs (Josef Söntgen)
* Mesa's generated files are placed into 'contrib/mesa-<hash>/generated'
and are cloned per default from a separate Git repo in order to avoid
hash updates upon package build. In case you need to generate files
yourself use
! prepare_port mesa GENERATE_FILES=1
issue #4254
Support for iris and etnvaviv
* entaviv:
- libdrm on FreeBSD is not prepared for !PCI (and libc our is missing
<sys/pciio.h>
- missing <sys/types.h> include in xf86drmMode.c
- etnaviv relies on linux header files - dummy in $(INC_DIR)
- IOCTL FreeBSD ↔ Linux have swapped IO/OUT bit
- O_CLOEXEC differs between FreeBSD ↔ Linux
issue #4254
- remove redundant file system factory
- remove dead code block
The code was guarded by preprocessor directives checking whether the
contrib code define "_USE_MKFS" is 1. As "_USE_MKFS" is not set one
for our port of FAT, the code was never executed and can be removed.
- remove uneffective config attributes
Apparently, the former XML attributes to the plugin 'drive' and
'codepage' had no effect. I tested them in a scenario with the VFS
block server on a disk-image boot-module as back end. Regardless of
the 'drive' value, the block session label was always "0". Regardless
of the 'codepage' value, the FAT on the disk image succeeded to mount
when not using '--codepage' for 'mkfs.fat' and failed to mount when
using '--codepage' to specify a supported but foreign codepage for
'mkfs.fat' (e.g. "720").
Ref #4220
There was one global static constructor:
! namespace Fatfs { static Constructible<Platform> _platform; }
This caused applications that used the lib or the <fatfs> VFS plugin to end up
in an uncaught exception due to Genode::Component complaining that method
'construct' returned without executing pending static constructors if they
didn't call Genode::Env::exec_static_constructors().
As the use of Genode::Env::exec_static_constructors() is discouraged in Genode,
this commit rather moves the '_platform' object to the scope of the
initializing function and introduces a global static pointer to the object that
gets set by the initializing function. Although this prevents the exception, it
is, technically speaking even worse than the former solution as the new pointer
isn't checked for validity in contrast to the 'Constructible' object.
However, so far, I don't see a clean solution to this problem without the need
for Genode::Env::exec_static_constructors().
Fixes#4220
For mesa-21 the client takes care and manages
the virtual address space of the vGPU by itself and the intel/gpu driver
can't add silently a guard page anymore. Move the patch to the drm/ioctl
of the former mesa version.
Issue #4148#4233
The symlink implementation wrongly constructed a 'Sync' object within
the context of a monitor call. The 'Sync' constructor indirectly
depended on libc I/O for obtaining the current time, ultimately
resulting in a nested attempt of a monitor call. This could be
reproduced via the base.run script:
$ cd /home
$ ln -s a b
The 'ln' command resulted in the following log message:
[init -> /bin/bash -> 7] Error: deadlock ahead, mutex=0x10ff8c70, return ip=0x500583a7
The patch fixes the problem by splitting the single monitor call into
two monitor calls and moving the construction of the 'Sync' object
in-between both monitor calls, thereby executing the constructor at the
libc application level.
Fixes#4219
- Patch the XHCI model in order to handle frame wrapping correctly. For
this adjust 'mfindex_kick' to the correct period (same, before, or after
'mfindex').
- Flush EP when it is stopped, this causes all pending packets for the EP
to be acked. Correct counting of packets in flight.
- Add BEI patch by Josef.
issue #4196
Because qemu-usb allocated host devices after 'USB_HOST_DEVICE' in the
object array and 'USB_WEBCAM' is loacated after 'USB_HOST_DEVICE' the
webcam model can overwrite an already allocated pass-through device. As
a solution add the 'USB_FIRST_FREE' to make it clear from where host
devices can be allocated. Also increase the number of supported host
devices to eight.
fixes#4182
