Paravirtualization project - GSOC 2013

Mon Apr 8 14:04:25 UTC 2013

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
> <mailto: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
>         <mailto: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 <mailto:rtems-users at rtems.org>
>             http://www.rtems.org/mailman/__listinfo/rtems-users
>             <http://www.rtems.org/mailman/listinfo/rtems-users>
>
>