Paravirtualization project - GSOC 2013

[Cláudio Silva]

Hello Philipp,

RTEMS on POK was meant as a first virtualization experience for  RTEMS on
top of an open source ARINC 653 compliant hypervisor. A future generic
paravirtualization interface would be build based on this first experience.
System calls are there to maintain the independence between RTEMS and the
partitioning kernel. Of course the system calls (or hypercalls) can
(should) be hidden by a small library that is linked against the
virtualized operating system. Originally, POK uses system calls to
interface between the ARINC 653 executive in each partition and the
partitioning kernel.

Can you further explain your L4 based approach? Does it seem like a
modified jump table?


Regards,
Cláudio Silva


On Sat, Apr 6, 2013 at 11:23 PM, Philipp Eppelt <
philipp.eppelt at mailbox.tu-dresden.de> wrote:

> Hi,
>
> thanks for the source, Gedare. I built the tool chain and the example code
> and  thanks to the great Manual(!), it's working.
>
>
> Now, I have a question regarding the design.
>
> You have chosen to use syscalls to provides functionality to the partition
> application (e.g. console writes). From my understanding, one aspect of the
> project is to provide a defined interface to run RTEMS on various other
> hypervisors. Why did you choose syscalls to provide this interface?
>
> From my experience there are two other ways to achieve this functionality.
>
> The first is pretty close, but with a different compile process.
> There is one header file with function definitions. These functions have
> to be implemented in the host and made available in form of a library,
> which is used while linking RTEMS.
>
> The second way is used in L4Linux and I did it the same way in L4RTEMS.
> Inside the guest system, host functionality is wrapped with a
> L4_EXTERNAL_FUNC(..) macro. This macro adds the function to special
> sections in the binary, which are defined in the linkcmds file. Therefore
> no undefined references occur.
> While compiling the wrapper code in L4 the mentioned sections in the RTEMS
> binary are scanned and the function addresses get fixed.
> This is a very abbreviated explanation. So for further reading I recommend
> these files on github [0].
>
> Both ways look like a better portable approach to me, but I assume they
> are not as efficient as yours. Mainly, because there will be at least on
> more function call to get into the kernel.
>
> I am sure, there is a lot I missed. So what other reasons led you to your
> decision?
>
>
> Regards,
> Philipp
>
>
>
> [0]
> * L4_EXTERNAL_FUNC'tions. https://github.com/phipse/**
> L4RTEMS/blob/master/c/src/lib/**libbsp/l4vcpu/pc386/startup/**handler.c<https://github.com/phipse/L4RTEMS/blob/master/c/src/lib/libbsp/l4vcpu/pc386/startup/handler.c>
> * Section magic: https://github.com/phipse/**
> L4RTEMS/blob/master/c/src/lib/**libbsp/l4vcpu/pc386/startup/**l4lib.h<https://github.com/phipse/L4RTEMS/blob/master/c/src/lib/libbsp/l4vcpu/pc386/startup/l4lib.h>
> * Resolver the sections: https://github.com/phipse/**
> L4RTEMS/blob/master/l4/pkg/**RTEMS_wrapper/server/src/res.c<https://github.com/phipse/L4RTEMS/blob/master/l4/pkg/RTEMS_wrapper/server/src/res.c>
> * Grab function names; Line 20: https://github.com/phipse/**
> L4RTEMS/blob/master/l4/pkg/**RTEMS_wrapper/server/src/**Makefile<https://github.com/phipse/L4RTEMS/blob/master/l4/pkg/RTEMS_wrapper/server/src/Makefile>
>
>
>
> On 04/03/2013 10:32 PM, Gedare Bloom wrote:
>
>> The code is here: https://github.com/jolkaczad/**rtems<https://github.com/jolkaczad/rtems>
>>
>> There is a lot to do, although I don't know how what is reasonable in
>> the scope of a GSOC project. I think somehow last year's project was
>> too ambitious and did not meet all its goals.
>>
>> On Wed, Apr 3, 2013 at 4:20 PM, Philipp Eppelt
>> <philipp.eppelt at mailbox.tu-**dresden.de<philipp.eppelt at mailbox.tu-dresden.de>>
>> wrote:
>>
>>> Hi,
>>>
>>> I am interested in the paravirtualization project[0] for this years
>>> round of
>>> the Google Summer of Code. Unfortunately, I am unable to find results of
>>> the
>>> mentioned gsoc2011 project. I guess it's the hypervisor project, but I am
>>> not allowed to view the proposal, neither have I found any related source
>>> code.
>>>
>>> So is there anything left from the project to build upon?
>>>
>>> Regards,
>>> Philipp
>>>
>>>
>>> [0] http://www.rtems.org/wiki/**index.php/RTEMS_**Paravirtualization<http://www.rtems.org/wiki/index.php/RTEMS_Paravirtualization>
>>> ______________________________**_________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/**listinfo/rtems-users<http://www.rtems.org/mailman/listinfo/rtems-users>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130407/3693305d/attachment-0001.html>