Including paravirtualization headers in RTEMS

[Sebastian Huber]

On 2014-05-23 10:46, 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.
>
>
> 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.
> Hence, at compile time the guest system is missing the implementation of
> this host specific functions.
>
>
> 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.

Yes, for XtratuM we tried to use (A).  XtratuM is just a normal operating 
system with virtual memory (like Linux).  The guest systems are like processes 
and run in user mode.  They interact with the hypervisor via so called 
hypercalls which are really just system calls, but this sounds hypertimes more 
sophisticated.

For a minimum BSP it is possible to avoid a guest support library entirely and 
simply use a handful of hypercalls.  This probably avoids also the GPLv2 
problem.  A RTEMS application is then a normal ELF executable.

The guest support library provides some higher level services like message 
passing between partitions, etc.  (this is just pack/unpack of data plus a 
hypercall).

XtratuM contains some additional tools to glue partition executables together 
with the hypervisor and a boot loader.  Maybe this is the point in which GPLv2 
creates derivative work.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.