[GSOC] Paravirtualization Layer in RTEMS.

[Gedare Bloom]

Hi Youren,

On Sun, Apr 27, 2014 at 9:56 AM, Cláudio Silva <claudiodcsilva at gmail.com> wrote:
> Hello Youren,
>
> Welcome to the RTEMS community.
> I hope you have a successful RTEMS summer of code :)
> Virtualization of RTEMS on POK is a complex mid-term project with
> several people involved, therefore, lets make an effort to keep the
> RTEMS wiki updated with new developments and design decisions.
>
> Regarding the interrupt virtualization, lets keep the design simple as
> possible. I think we should mimic the behaviour of the underlying
> hardware interrupt management as it makes the paravirtualization
> easier.
>
> To summarize, the interrupt virtualization layer shall:
>  - forward interrupts to the current executing partition in user mode;
>  - allow a partition to disable/enable virtual interrupts;
>  - allow a partition to mask/unmask virtual interrupts;
>  - track pending interrupts;
>  - forward pending interrupts as soon as the partition enables or
> unmasks interrupts ;
>
> I doubt you will be able to find an POK mechanism that can be adapted
> to achieve this. It needs to be developed departing from Phillip's
> work last year.
>
This development effort should also be cross-posted to pok-devel mailing list.

Welcome aboard and I look forward to your project!

-Gedare

> Could you try to summarize the design you have in mind in a blog post
> or wiki page? Maybe with some simple diagrams explaining the behavior
> (how to register a virtual interrupt, how do you keep interrupts
> pending, where and how to store the interrupt context, etc).
>
> Thanks,
> Best Regards,
> Cláudio
>
>
>
> On Sun, Apr 27, 2014 at 9:44 AM, Youren Shen <shenyouren at gmail.com> wrote:
>> 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.