On Thu, 2013-03-14 at 23:17 +0100, Norman Feske wrote:
Hello Fiasco.OC developers,
I skip the whole first part of the mail, may be we can discuss this later...
Current state and open questions
With the current state of the implementation, the complete software stack of Genode runs without sigma0. This includes L4Linux. So I am pretty confident that the removal of sigma0 from the system does not imply functional disadvantages.
That said, there are a few remaining questions that I'd like to discuss.
First, the sole use of 'l4_task_unmap' to remotely flush memory mappings in other processes means that we must no longer provide the option of granting memory mappings. Otherwise, a process that received a mapping from roottask could "steal" the physical memory by granting it to someone else. Roottask would not know about that, and an attempt to flush the mappings in the original receiver of the mapping would just target a hole in the address space. My question is:
"Can we live without granting memory?"
or the other way: "What is a known use case for granting memory?"
Yes, it is possible to live without grant for memory, however this would make it impossible to implement a pass-through pager that does not keep mappings on its own. And second, grant does not allow steeling something, if Task A wants to revoke memory it mapped to Task B it can always use its local address to do that regardless of what Task B did by granting or mapping memory somewhere else. So in other words the 'l4_task_unmap' call is useful for tasks that are fully controlled by some other task (tasks that cannot map/grant by themselves) As for example L4Linux user-level tasks or virtual machines.
So there is no functional benefit from removing 'grant', but there are legitimate use-cases that are impossible without grant.
Second, the new situation triggers some code paths in the kernel that were not used before. Apparently, the unmapping of memory from sigma0 was not considered. This is where I hit a few assertions in the kernel. Right now, I have just worked around these assertions by uncommenting the offending code in 'kernel/fiasco/src/kern/map_util.cpp'. I understand that this is just a stop-gap solution. Would you like to lend a helping hand to find out...
"How to support unmap from sigma0 in a clean way?"
So we currently do not consider removing sigma0 as a user-level process. Nor do we consider changing the semantics that sigma0 has access to all physical memory resources. Hence there is currently no good reason to support unmapping memory from sigma0 because it could regain access to that memory by accessing it.
Modifying the Fiasco interface in the proposed way would make the semantics for the sigma0 task very special and to all other tasks on Fiasco, which is currently not the case.
I would like to avoid Genode from diverging too much from the semantics of the official Fiasco.OC kernel. Hence, I would appreciate your consideration:
"Would you like to follow a similar path with L4Re?"
That would be very nice. But even if this should not be the case, I would find your rationale behind sticking with sigma0 very valuable to know, e.g., for reconsidering my plan.
Currently not, we consider sigma0 being part of our architecture and will probably stay with it. However, there could be possible enhancements to the sigma0 interface that support your use-cases. And there could also be some kernel-interface enhancements that allow more effective and robust user-level memory management.
regards