Hi Youren, On Sun, Apr 27, 2014 at 9:56 AM, Cláudio Silva <claudiodcsi...@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 <shenyou...@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. _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
