No subject

[Youren Shen]

Hi, Gedare, Philipp and Cláudio Silva:

I'm very glad to be accepted by GSoC, and that's not only an honor but also
an opportunity to change our idea and design to become code.

Hi, Cláudio , I'm a junior student from china, and my major in college is
embedded system. Nice to meet you.

OK, Cliché should not be long, Let's focus on the project.

I have discussed with the Philipp about the jobs should be done in this
summer. Thanks to Phillpp's strict adherence, we have already get a clear
design. I have put a brief outline on my blog[1]. But if you don't mind,
please let me introduced it now:

Thanks to Phillpp's contributions last year about the paravirtualization
layer, we could run RTEMS application successfully on POK already, which
means we can focus on CPU virtualization this year. And I'd like continue
the work based on the Paravirtualization Layer implement by Phillpp last
year. By the way, the job last year was really creative and great. Because
of lacking time and complicated task, The job was not get the purpose
eventually, I hope this year, I can make it with the guide of Philpp and
other mentors.

This year, the jobs includeing two aspect, one is implement a Hypercall
system, the other is develop a interrupt handling system in POK with the
function we design in Hypercall system.

The implementation of Hypercall system will not be difficult, but we should
take heed about the reusability and flexibility of the code, since we
certainly will reuse the job and extend the functionality of Hypercall
system.

In the other hand, we need to design a interrupt dandling system to
delivery the interrupt. As we discussed, the following should be the
workflow of interruption:
1. When the RTEMS startup, It should register the interrupt by hypercall,
then we will bond the corresponding interruption to this partition that the
RTEMS locals in.
2. When an interrupt(or events including traps like a floating point
error), the POK will intercept the interrupt, do some common handler and
decide to whether delivery it or not by the type of this interrupt.For
example, if the time interrupt occurs, the POK will deal it in kernel, but
then send a dummy clock interrupt to every RTEMS.
3. If a interrupt should be delivery to Partitions(RTEMS), then the POK
kernel compact the context of the interruption, and send the package of
interrupt to corresponding Partitions, then mask a bit in some mechanism,
to notify the Partitions that there happens a interrupt when you are
suspended.
4. When the Partitions being evoked, it should check the mask bit, if the
mask bit is settled, then using the native interrupt handler in RTEMS(but
should change some sensitive function by Hypercall in VIrtualization Layer).

So, as we can see, in this section, we need to design a system to save and
delivery the interruptions.This system is called event channel in XEN, and
Phillpp named it notify, which is more accurate(because there are no
necessary to implement a complicated system like event channel). About this
part, I have upload a blog to describe, and I have conclude the to-dos as
following:
1. Build a structure to store the context of interrupt.
2. Build a structure  to mark that there is an event pending.
3. When the partition(RTEMS) resume, check the value of the bit.
4. Design a callback function mechanism. Including the operation of
register an event and callback function. The register of events should bind
the corresponding partitions.
5. In the callback function, we should invoke the normal interrupt handler
in RTEMS, let the RTEMS deal with this interrupt.
6. Adapt the interrupt structure in POK, make it  able to bond a Partitions.

The POK, which is obey to ARINC-653, already supplied series mechanism to
communicate between partitions or threads in a single process. I want to
find some mechanism could use to communicate between POK kernel and
Partitions, so we can adapt it directly. I have read the examples in POK
and DO NOT find any example about it. If the POK did not support such
mechanism, the mostly worse, we have to write a notify system from
nothing.

Thank you very much for your patience to read this e-mail, I'm not
a connoisseur in virtualization, so I have to design it as earlier as I can
to prevent potential mistakes, So I really appreciate to Philipp that he
insist on the outline. The purpose of this email is make a summary of the
design, and hope to propaganda it to my mentors to review it and find any
mistake or negligence that not be considered yet.

There are something for my private reason, I have register a GRE in 18 May,
and before the date, I can devote myself in this project, both of GRE and
the project for RTEMS is really important for me.

Thank you very much. It will be a exciting summer.

[1].
http://huaiyusched.github.io/rtems/2014/04/07/the-brief-design-and-outline/

-- 
Best Regards.
Youren Shen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140427/a5096cef/attachment.html>