Hi, can you please evaluate, which pieces already implemented in pok/kernel/* can be reused to build the vCPU structure? Also, how the vCPU structure can be build on top of / merged into the partition structure.
Cheers, Philipp On 06/12/2014 12:00 PM, Philipp Eppelt wrote: > Hi, > > I think we have to chose the 'host model'. In order to provide > separation POK puts (at least some) device drivers (network card) into > their own partitions and offers a kernel supervised communication > interface. (If this is new, read the POK paper by Julien.) > > This also implies some restrictions on the device driver used. They need > to be implemented in POK and the RTEMS guest needs to communicate with > these drivers. > > It looks unlikely to me, that we are able to assign hardware exclusively > to one partition. Also this needs to be configurable through the AADL > model at some point in time. > > Concerning the vCPU research you did: > > For now, it is sufficient to support just one vCPU on a single core > processor. No SMP, no mixed design with more than one vCPUs or a vCPU > and a native partition. > You should keep this in mind to ease future development, which works on > these issues, but it is not your concern right now. > > This brings me to you scheduling issue. A vCPU is basically a task in > POK. This task is scheduled like any other task from the kernel point of > view. What this task does internally is of no concern to the kernel. > So the vCPU is just a partition to POK. > > How to get a unique ID for the vCPU? Reuse the partition ID, POK already > uses. > > > The interrupt delivery mechanism is still an open question, but I like > to focus on a simple hello world. This doesn't need interrupts outside > the kernel. It is a proof-of-concept for your VMM and vCPU. > It also raises the question of loading a guest binary. > But this also looks like beyond midterm. > > To summarize: > * host model > * small, simple vCPU model, without own scheduling policies and without SMP > * vCPU needs to look like a partition to the kernel > * no interrupts for now! > > Figure out, which parts of the vCPU and VMM need to go where in the POK > system. Meaning, what needs to go to kernel/* and what to libpok/* and > where does it belong in there. > > > Cheers, > Philipp > > > > On 06/10/2014 04:25 PM, Youren Shen wrote: >> Hi, Philipp: >> >> As I said in the last post, there are still several issues remained to >> be discussed. I hope I can have a discussion with you in some >> day.According to the discussion in the meeting, we need to figure out a >> realistic target for midterm. >> >> I have post a blog about the pictures that I want to share and discuss >> with you. >> >> Thank you very much. >> >> [1]. >> http://huaiyusched.github.io/2014/06/10/some-discussion-about-the-paravirtualization-architecture/ >> >> >> On Tue, Jun 10, 2014 at 7:13 PM, Youren Shen <shenyou...@gmail.com >> <mailto:shenyou...@gmail.com>> wrote: >> >> Hi,Philipp: >> >> Sorry for so late to update my blog, I got two examinations last >> Sunday, so I have to prepare it in Saturday. >> >> I have post a blog[1] about my design of vCPU. please have a review. >> I have described several problem and their solutions, if you have >> any suggestion, please tell me. >> I will update another blog later, for the interesting picture I >> mentioned before. >> >> Thank you very much. >> >> [1]. http://huaiyusched.github.io/2014/06/10/the-design-of-vcpu-in-pok/ >> >> -- >> Best Regards. >> Youren Shen. >> >> >> >> >> -- >> Best Regards. >> Youren Shen. > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
