Paravirtualization project - GSOC 2013
Cláudio Silva
claudiodcsilva at gmail.com
Mon Apr 8 20:22:13 UTC 2013
That was the first experience. Write your proposal and keep discussing your
ideas about the project with the community :)
Ok! I have to explore that architecture better.
On Mon, Apr 8, 2013 at 3:04 PM, Philipp Eppelt <
philipp.eppelt at mailbox.tu-dresden.de> wrote:
> Hi Cláudio,
>
> okay. So do you have experiences, which I need to consider up front, when
> writing my proposal? Otherwise I just write one and await your comments :)
>
>
> Can you further explain your L4 based approach? Does it seem like a
>> modified jump table?
>>
>
> Yes, indeed. The L4_EXTERNAL_FUNC macro defines three sections:
> .data.l4external.str, *.symtab and *.jmptbl and in the .text section an
> resolver part, that jumps to __l4_external_resolver. This pointer needs to
> be passed at system startup to the guest system.
>
> When compiling the L4 wrapper code, the .data.l4external.str is scanned
> and every functionname gets copied in a new header file (func_list.h).
> These function have the form EF(func) and EF() gets defined in the
> resolver file. First to produce the function definitions, second after a
> redefine of EF to produce a 'else-if' list, which generates a kind of
> lookup table.
> So when the function is called the first time, the programm jumps to the
> resolver function, which looks for the function name in the lookup table,
> replaces itself with the correct address for future references and returns
> with a call to the searched function.
>
> Regards,
> Philipp
>
>
>
> On 04/07/2013 03:07 PM, Cláudio Silva wrote:
>
>> 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<philipp.eppelt at mailbox.tu-dresden.de>
>> <mailto:philipp.eppelt@**mailbox.tu-dresden.de<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>
>>
>> <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>
>>
>> <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>
>>
>> <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>
>>
>> <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>
>>
>> <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>
>>
>> <mailto:philipp.eppelt@**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>
>> <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 <mailto:rtems-users at rtems.org>
>> http://www.rtems.org/mailman/_**_listinfo/rtems-users<http://www.rtems.org/mailman/__listinfo/rtems-users>
>> <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/20130408/70af9c84/attachment-0001.html>
More information about the users
mailing list