Including paravirtualization headers in RTEMS

[Cláudio Silva]

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.
>
> Chris
>
>
>>
>> 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.
>> [1] shows the macro for the function stubs, [2] 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.
>>
>> Cheers,
>> Philipp
>>
>>
>> [1]
>>
>> https://github.com/phipse/L4RTEMS/blob/master/c/src/lib/libbsp/l4vcpu/pc386/startup/l4lib.h
>> [2]
>>
>> https://github.com/phipse/L4RTEMS/blob/f5a32ed0121b3e5f0ac8ae4c53e636eab2257fb1/l4/pkg/RTEMS_wrapper/server/src/res.c
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel