This patch introduces the functions 'affinity' and 'num_cpus' to the CPU
session interface. The interface extension will allow the assignment of
individual threads to CPUs. At this point, it is just a stub with no
actual platform support.
The Cap_mapping abstraction in core shouldn't use a Cap_index directly, but
use Native_capability instead, as it can break reference-counting, as long as
the same Cap_index gets used in a Cap_mapping and a Native_capability. This
commit finally fixes#208.
This commit fixes several issues that were triggered e.g. by the
'noux_tool_chain' run-script (fix#208 in part). The following problems
are tackled:
* Don't reference count capability selectors within a task that are actually
controlled by core (all beneath 0x200000), because it's undecideable which
"version" of a capability selector we currently use, e.g. a thread gets
destroyed and a new one gets created immediately some other thread might
have a Native_capability pointing to the already destroyed thread's gate
capability-slot, that is now a new valid one (the one of the new thread)
* In core we cannot invalidate and remove a capability from the so called
Cap_map before each reference to it is destroyed, so don't do this in
Cap_session_component::free, but only reference-decrement within there,
the actual removal can only be done in Cap_map::remove. Because core also
has to invalidate a capability to be removed in all protection-domains
we have to implement a core specific Cap_map::remove method
* When a capability gets inserted into the Cap_map, and we detect an old
invalid entry with the dame id in the tree, don't just overmap that
invalid entry (as there exist remaining references to it), but just remove
it from the tree and allocate an new entry.
* Use the Cap_session_component interface to free a Pager_object when it
gets dissolved, as its also used for allocation
Let the Fiasco.OC base platform succeed the cap_integrity run-script meaning
that it is not feasible anymore to fake a capability by using a valid one
together with a guessed local_name.
Eliminate prints to stderr for normal messages, because it leads to exceptional
returns in TCL-scripts e.g. when run-script is triggered by the autopilot even
if the script's return code itself will be zero.
This patch extends the RAM session interface with the ability to
allocate DMA buffers. The client specifies the type of RAM dataspace to
allocate via the new 'cached' argument of the 'Ram_session::alloc()'
function. By default, 'cached' is true, which correponds to the common
case and the original behavior. When setting 'cached' to 'false', core
takes the precautions needed to register the memory as uncached in the
page table of each process that has the dataspace attached.
Currently, the support for allocating DMA buffers is implemented for
Fiasco.OC only. On x86 platforms, it is generally not needed. But on
platforms with more relaxed cache coherence (such as ARM), user-level
device drivers should always use uncacheable memory for DMA transactions.
When sigma0 runs on a lower priority than the rest of the threads in the
system it might come to the point that while answering a page fault or
I/O memory area request the timeslice of the caller (core-pager) gets
fully consumed. As long as other threads are still executable and don't block
sigma0 won't do progress anymore, because it runs at the lowest priority.
This commit simply sets sigma0's priority to the highest in the system.
When invoking the bootstrap build in the L4RE build-system to create
a single elf-image containing all needed files to boot a scenario, don't
use the 'ENTRY' variable, but 'E' variable instead. Otherwise 'ENTRY'
might get overridden (dependent on the make-version). Moreover, using
'E' seems to be the way L4Re is expecting it has to be invoked.
Fixes#226
When core requests all RAM from sigma0 it normally unmaps page 0 so that
null-pointer dereferences are detected by a pagefault. The unmap syscall
in the Fiasco.OC base platform was used insufficiently in this particular
case.
Introduce process global spin-lock for Cap_index's reference-counter
to avoid non-atomic increment/decrement of the counter. Here, we don't
use a static Spinlock object, because it's constructor wouldn't be
initialized before used for the first time.
The following fixes partly solve the problems triggered by the noux stress
test introduced by nfeske in issue #208.
* The check whether a capability exists in the Cap_map, and its insertion,
has to be done atomically
* While removing a capability it is looked up in the Cap_map via its id,
check whether the found capability pointer is the same like the looked up,
otherwise the wrong capability gets freed
* When a local capability is un- resp. marshalled, only the local pointer
gets transfered, not the redundant capability id
* Introduce several assertions and warnings to facilitate debugging
This patch increases the size of the JDB kernel object names buffer. The
original size was too small for some Genode scenarios and caused missing
thread names in the kernel debugger thread list.
Fixes#191.
When unmarshalling capabilities it is checked, whether a capability with the
id was leaking, but this isn't done when creating a thread. Here the capability
is transfered indirectly via the thread state object. This patch checks for
old leakage capabilities while thread creation.
Due to recently introduces smart-pointers to Cap_index objects it's
necessary to always keep at least one reference as long as a corresponding
slot in the capability-space of a process is in use. This is especially
important for L4Linux that uses cap-slots directly without the given
abstractions of Genode.
The syscall l4_task_cap_equal almost returns false although the referenced
kernel-objects are equal. This patch changes the semantic of the syscall so
that whenever two capabilities refering the same kernel-object are compared
it will return true. Please refer to the discussion of the following mail
thread:
http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg05162.html
Implements Native_capability as smart-pointer type referencing Cap_index
objects. Whenever capabilities are copied, assigned, constructed, or destructed
the reference-counter of the Cap_index is incremented/decremented. When it
reaches zero the Cap_index is removed from the process-global cap_map and
gets freed. Fix for issue #32.
When the pager gets a pagefault, exception, pause, or wakeup request it's
always possible, that the corresponding thread gets destroyed between
receiving the message and looking up the thread's pager_object. This commit
unifies the check for a valid pager_object for each kind of requests to the
pager, thereby adds currently missing checks.
The 'copy_to' function turned out to be not flexible enough to
accommodate the Noux fork mechanism. This patch removes the function,
adds an accessor for the capability destination and a compound type
'Native_capability::Raw' to be used wherever plain capability
information must be communicated.
In applications that use ldso the main_thread_bootstrap() function is called
twice which results in the main thread's gate-capability to be inserted twice
in the Capability_map which results in an exception. Unfortunately at least
on ARM this exception cannot be handled that early, so this commit prevents
the exception by checking, whether the capability is inserted already or not.
Fixes#164.
When constructing a thread object its capability is inserted into the
capability map. Normally this is done by the ipc-unmarshalling code, but
in this case the thread-capability isn't transfered via normal IPC, but in
a special form via the thread_state object. In contrast to the unmarshalling
code, the thread-startup code doesn't check, whether the capability-map
already contains a deprecated entry with the same capability id before
inserting the thread's capability. This commit add the necessary check.
Moreover, a check is added to the insertion methods of the capability-map
to verify that capability-allocation didn't failed.
Removing a Cap_index from Capability_map in core can happen twice, via
Cap_session_component or destructor of a Cap_mapping. That it's checked
whether the index is part of the map before removing it. This patch puts
the check into the remove method, so both operations are within the same
lock context, to remove a race condition.
This is a follow up fix for commit d287b9d893
This commit introduces a Cap_index class for Fiasco.OC's capabilities.
A Cap_index is a combination of the global capability id, that is used by Genode
to correctly identify a kernel-object, and a corresponding entry in a
protection-domain's (kernel-)capability-space. The cap-indices are non-copyable,
unique objects, that are held in a Cap_map. The Cap_map is used to re-find
capabilities already present in the protection-domain, when a capability is
received via IPC. The retrieval of capabilities effectively fixes issue #112,
meaning the waste of capability-space entries.
Because Cap_index objects are non-copyable (their address indicates the position
in the capability-space of the pd), they are inappropriate to use as
Native_capability. Therefore, Native_capability is implemented as a reference
to Cap_index objects. This design seems to be a good pre-condition to implement
smart-pointers for entries in the capability-space, and thereby closing existing
leaks (please refer to issue #32).
Cap_index, Cap_map, and the allocator for Cap_index objects are designed in a way,
that it should be relatively easy to apply the same concept to NOVA also. By now,
these classes are located in the `base-foc` repository, but they intentionally
contain no Fiasco.OC specific elements.
The previously explained changes had extensive impact on the whole Fiasco.OC
platform implementation, due to various dependencies. The following things had to
be changed:
* The Thread object's startup and destruction routine is re-arranged, to
enable another thread (that calls the Thread destructor) gaining the
capability id of the thread's gate to remove it from the Cap_map, the
thread's UTCB had to be made available to the caller, because there
is the current location of that id. After having the UTCB available
in the Thread object for that reason, the whole thread bootstrapping
could be simplified.
* In the course of changing the Native_capability's semantic, a new Cap_mapping
class was introduced in core, that facilitates the establishment and
destruction of capability mappings between core and it's client's, especially
mappings related to Platform_thread and Platform_task, that are relevant to
task and thread creation and destruction. Thereby, the destruction of
threads had to be reworked, which effectively removed a bug (issue #149)
where some threads weren't destroyed properly.
* In the quick fix for issue #112, something similar to the Cap_map was
introduced available in all processes. Moreover, some kind of a capability
map already existed in core, to handle cap-session request properly. The
introduction of the Cap_map unified both structures, so that the
cap-session component code in core had to be reworked too.
* The platform initialization code had to be changed sligthly due to the
changes in Native_capability
* The vcpu initialization in the L4Linux support library had to be adapted
according to the already mentioned changes in the Thread object's bootstrap
code.
There seems to be a bug in Fiasco.OC, that is hard to reproduce. The scenario
discussed in issue #157 triggers it relatively often. When sigma0 handles
pagefaults of core on demand at runtime, at some point its reply ipc-message
gets stucked in the kernel. This commit touches all ROM-modules when the
platform is initialized in advance (like it was done for RAM etc. already
before).
This commit unifies the policy name for the template argument for
Native_capability_tpl to Cap_dst_policy, like suggested by Norman in the
discussion resulting from issue #145. Moreover, it takes the memcpy
operation for copying a Native_capability out of the template, which is
included by a significant bunch of files, and separates it in a library,
analog to the suggestion in issue #145.
Because we use to pass a policy class to 'Native_capability_tpl'
we can pass the dst type as part of the policy instead of as
a separate template argument. This patch also adds documentation
of the POLICY interface as expected by 'Native_capability_tpl'.
This patch unifies the Native_capability classes for the different kernel
platforms by introducing an appropriate template, and eliminating naming
differences. Please refer issue #145.
To give the platform developer more freedom in how the Native_capability
class is internally implemented (e.g. turning it into a smart-pointer),
this patch removes the memcpy operation, when transfering the parent-capability
to a new process from the generic code, and let the implementation of the
platform-specific Native_capability decide how the transfer has to be done.
Please refer to issue #144.
Introduce a factory-, and dereference method for local capabilities. These are
capabilities that reference objects of services, which are known to be used
protection-domain internally only. To support the new Capability class methods
a protected constructor and accessor to the local object's pointer is needed
in the platform's capability base-classes. For further discussion details please
refer issue #139.
Separate spin-lock implementation from lock-implementation and put it into a
non-public header, so it can be re-used by the DDE kit's and Fiasco.OC's
capability-allocator spin lock. Fixes issue #123.
The old variant provided 8K capability slots to all processes on core,
which increased binaries by 180 KB for the static allocator. I reduced it
to 4K capabilities stay under 100 KB overhead for the allocator.
Anyway, pci_drv and pl11x_drv need more RAM quota now: 2M for pl11x_drv
and 1M for pci_drv.
In the cap-session component in core when freeing a capability, the
corresponding kernel object should be unmapped from all processes and core.
Until now, the unmap operation for removing the kernel object didn't worked
because of using the wrong rights-map. This patch fixes it.
The re-use of capabilities introduced by the last patch triggered this
problem because its essential for the capability-registry to detect
invalidated capabilities.
This is an interim fix for issue #112. This patch extends the
'Capability_allocator' class with the ability to register the global
ID of a Genode capability so that the ID gets associated with a
process-local kernel capability. Whenever a Genode capability gets
unmarshalled from an IPC message, the capability-allocator is asked,
with the global ID as key, whether the kernel-cap already exists.
This significantly reduces the waste of kernel-capability slots.
To circumvent problems of having one and the same ID for different kernel
objects, the following problems had to be solved:
* Replace pseudo IDs with unique ones from core's badge allocator
* When freeing a session object, free the global ID _after_ unmapping
the kernel object, otherwise the global ID might get re-used in some
process and the registry will find a valid but wrong capability
for the ID
Because core aggregates all capabilities of all different processes, its
capability registry needs much more memory compared to a regular process.
By parametrizing capability allocators differently for core and non-core
processes, the global memory overhead for capability registries is kept
at a reasonable level.
The new function 'Platform_env::reload_parent_cap' triggers a reload
of the parent capability and its respective resources. It is needed
during the bootstrap of a new process forked from an existing Noux
process.
It turns out that recent subversion clients are more nitpicking with respect to
the usage of 'svn update'. Formerly it was ok to just checkout a toplevel
directory of some repository, and then update that parts in the repo that are
needed. This is used in the preparation makefile in 'base-foc' to just checkout
a small part of the L4Re software stack. Recent clients complain about using
update with some remote target, so we've to use 'checkout' here too.
This commit fixes#84.
