Including paravirtualization headers in RTEMS
claudiodcsilva at gmail.com
Sun May 25 18:39:50 UTC 2014
Sorry all, miss send. Returning to where I was:
Yes, Partitions are fully linked executables created "off-line". No
linking occurs in run-time. The partition elf is simply loaded in to
memory by a partition loader or by the bootloader.
Typically, you have a thin abstraction layer defining simple functions
that will trap into the partitioning kernel. Something like:
In POK + RTEMS case, this library is being compiled by POK's compiler
and then linked to each partitions' executable. When this partition is
an RTEMS one, the remaining binaries (RTEMS+Application) were compiled
with the RTEMS' compiler. Therefore you are linking two sets of
binaries produced by different compilers.
I guess this is also true for the recently submitted Xtratum BSP.
We have several options available:
- Let the two binaries (RTEMS + abstraction lib), compiled with
different compilers, to be linked together (how it is currently
- Compile the partitioning kernel abstraction layer with the RTEMS
compiler - this will result in a complex configuration and build
- Implement the functionality of the abstraction layer completely
inside RTEMS as part of the libbsp/libcpu - This can be a good
solution for the CPU/TImer/Interrupt part of the abstraction layer.
However, for other elements like the queueing and sampling port APIs
that have no match inside RTEMS...
On Sun, May 25, 2014 at 7:22 PM, Cláudio Silva <claudiodcsilva at gmail.com> wrote:
> Hello Chris,
> Yes, Partitions are fully linked executables created "off-line". No
> linking occurs in run-time. The partition elf is simply loaded in to
> memory by a partition loader or the bootloader.
> Typically, you have a thin abstraction layer defining simple functions
> that will trap into the partitioning kernel. Something like:
> On Sat, May 24, 2014 at 12:27 AM, Chris Johns <chrisj at rtems.org> wrote:
>> On 23/05/2014 6:46 pm, Philipp Eppelt wrote:
>>>> On 05/21/2014 03:54 PM, Gedare Bloom wrote:> On Wed, May 21, 2014 at 4:04
>>>> AM, Christian Mauderer
>>>>> <Christian.Mauderer at embedded-brains.de> wrote:
>>>>>> First of all: Thanks for your comments. You will find answers below.
>>>>>> Am 20.05.2014 16:58, schrieb Gedare Bloom:
>>>>>> That is correct. It's part of XtratuM. Is there some preferred way of
>>>>>> marking such headers?
>>>>> Not that I know of. We have discussed a similar issue with the POK
>>>>> paravirtualization project. The problem is to allow external code
>>>>> linking to RTEMS. The design should be considered carefully and
>>>>> probably discussed in a separate thread.
>>> To pick up this discussion, I like first to picture the problem, second
>>> to collect possible solutions and third name some known problems with
>>> the solutions.
>> Thank you for posting this email. I followed the links and looked at the
>> code and realised I need to ask more questions.
>>> In a paravirtualized environment we need to make function calls from our
>>> guest system to the host system. The implementation of these functions
>>> rely sole on the host system.
>> Are they function calls ? To me a function call assumes some sort of linking
>> process between the guest and the host system either static or via some form
>> of runtime binding, ie a link editor. I also assume a guest is an RTEMS
>> partition executable and the host is the POK microkernel providing the
>> partitioned environment in some sort of protective environment.
>>> Hence, at compile time the guest system is missing the implementation of
>>> this host specific functions.
>> My understanding is partitions are loaded into an ELF image that POK loads
>> and executes. Is there some sort of linking happening when the partition is
>> written into the ELF image or when it is being loaded ?
>> For me this is the really important because I am wanting to first understand
>> the which pieces of code are compiled into object files and by which
>> compilers and then archived into static libraries and then linked to any
>> RTEMS code compiled with an RTEMS compiler. I do not understand if there are
>> function calls into the POK kernel or syscall type calls which I consider an
>> ABI, ie a trap or VM exception.
>> If I can understand these needs I will be in a better position to help with
>> the remaining topics in this email.
>>> To provide the guest system with the function implementation there are a
>>> couple of possible solutions.
>>> (A) Provide a host library
>>> The host compiles a library containing the function implementations
>>> including all dependencies. This host library is passed to the guest
>>> system, to resolve the `undefined reference` errors during link time.
>>> In the case of POK+RTEMS the resulting RTEMS binary is a valid POK
>>> partition and can run without further modifications.
>>> The recently propose XantruM BSP seems to follow a similar approach.
>>> (B) Use function stubs and build a jump table in the host
>>> The guest system makes use of function stubs, written into a special
>>> section in the binary to build. This section is analysed by the host
>>> system to intercept function calls and replace them with the host
>>> implementation of the calls.
>>> This approach is used in L4Linux and I gave it a shot in L4RTEMS.
>>>  shows the macro for the function stubs,  the hosts resolver part.
>>> (C) add your solution
>>> Problems with the solutions
>>> P(A) Dependencies and foreign code
>>> The library is host code, which has to be maintained, which can get out
>>> of sync between BSP and host. Licensing is another question.
>>> To my knowledge this approach won't get merged upstream.
>>> P(B) Support by the host system
>>> The host system needs a piece of code, loading the guest binary and
>>> providing it with knowledge about the environment (external_resolver).
>>> We haven't discussed this approach in detail.
>>> I hope, this gives a good overview and we can have a fruitful discussion.
>>> rtems-devel mailing list
>>> rtems-devel at rtems.org
>> rtems-devel mailing list
>> rtems-devel at rtems.org
More information about the devel