By transforming the Device_pd into an Io_mmu::Domain, we implement an
IOMMU device that uses the kernel API for controlling the IOMMU. This
device gets special treatment and is used by default for every device
that has no <io_mmu/> child.
genodelabs/genode#4761
Every session component manages a registry of Io_mmu::Domain objects
that it creates on demand depending on the acquired devices (i.e. the
IOMMU devices referenced by the acquired devices). Via the domain
objects, a session component adds/removes the address ranges of the
allocated DMA buffers. Additionally, domain objects provide an interface
for enabling/disabling pci devices.
Domain objects get destroyed with the corresponding control device.
Moreover, on devices/policy ROM updates, domain objects of control
devices that are not referenced by any acquired device anymore get destroyed.
genodelabs/genode#4761
This allows referencing an arbitrary number of IOMMU devices within a
<devices> node, e.g.:
<device>
<io_mmu name="foobar"/>
</device>
The specified name is supposed to refer to an existing device in the
devices ROM. The platform driver automatically acquires known IOMMU
devices whenever they become available so that the device object can be
looked up from the platform-driver-owned devices.
genodelabs/genode#4761
With this change, platform-specific code is able to define factories that
acquire IOMMU devices to be used by the platform driver.
genodelabs/genode#4761
The method did not handle device changes properly. When a new policy
does not contain an owned device any more, we must consider this device
as changed and release it. Moreover, the warning messages were interchanged.
genodelabs/genode#4761
"-cpu phenom" does not support all CPU instructions necessary with
gcc 12 toolchain update issuing more SSSE3, e.g. pshufb.
Additionally, remove good/bad Qemu version check of outdated versions.
Issue genodelabs/genode-world#329
In 'SUPR3InitEx' (SUPLib.cpp) a 'SUPQUERYFUNCS' structure is allocated
with
! (PSUPQUERYFUNCS)RTMemAllocZ(SUP_IOCTL_QUERY_FUNCS_SIZE(CookieReq.u.Out.cFunctions));
where 'CookieReq.u.Out.cFunctions' is 0. To determine the size of the
allocation
! #define SUP_IOCTL_QUERY_FUNCS_SIZE(cFuncs) \
! RT_UOFFSETOF_DYN(SUPQUERYFUNCS, u.Out.aFunctions[(cFuncs)])
is used with cFuncs = 0 (SUPDrvIOC.h) leading to an allocation up to the
arrow below
! typedef struct SUPQUERYFUNCS
! {
! /** The header. */
! SUPREQHDR Hdr;
! union
! {
! struct
! {
! /** Number of functions returned. */
! uint32_t cFunctions;
! /** Array of functions. */
==> end of allocation
! SUPFUNC aFunctions[1];
! } Out;
! } u;
==> sizeof(SUPQUERYFUNCS)
! } SUPQUERYFUNCS, *PSUPQUERYFUNCS;
In sup.cc (Genode) 'ioctl(SUPQUERYFUNCS &request)' will lead to
'with_out_ioctl'
! auto &out = request.u.Out;
where auto is 'SUPQUERYFUNCS' and finally
! out = { };
will zero out 'SUPQUERYFUNCS' up to the second arrow above. Because
'RTMemAllocZ' will call 'calloc' to allocate the memory 'out = { };'
will corrupt the slab block after the allocation. Therefore, it is
reasonable to allocate at least 'sizeof(SUPQUERYFUNCS)'.
Note there might be other 'ioctl' cases like this. A better way might be
to use 'SUPQUERYFUNCS.Hdr.cbOut' to determine the 'out' size.
fixes#4675
In case the meta data (or more) got zeroed upon 'free', print error
message. The offset in the meta data can never be zero. This does not
help on other memory corruptions, but at least gives a hint in the too
much zeroed out case.
issue #4675
GPU device access is hard to achieve in run scripts and even harder to
implement generic.
Use the "Modularize Sculpt OS image creation"
(commit b723b11b30)
approach instead.
issue #4900
The XHCI model reserves 0x4000 of IO memory but uses only 0x530.
Implement read (0) and write (nop) for these regions as real hardware
does.
fixes#4902
Triggered by the toolchain update to GCC 12 certain pragmas lead to
a build error as those are now unknown. As quick-fix add '-gnatwG',
which suppresses warnings on unrecognized pragmas.
Issue #4880.
