The design of vCPU.

[Philipp Eppelt]

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 <shenyouren at gmail.com
>> <mailto:shenyouren at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>