Paravirtualization project - GSOC 2013

[Chris Johns]

Philipp Eppelt wrote:
>
> if I add a new virtual BSP to an existing architecture, I use the
> corresponding cpu code in cpukit/score/cpu. So I would have to add code
> in every architecture, for example by adding '#ifdef VIRT'.

What sort of code would you be adding ?
How is this code architecture independent ?

Are you going to create a new --target=virt-rtems4.11 target for gcc and 
RTEMS ?

The score/cpu is tied to the gcc target being used. This is why I am 
confused about this proposed layout. There are rules and we need to 
respect them even when looking to bend them.

> But I also could create a new directory for all the ported virtual
> BSPs/CPUs. It wouldn't mix virtual and non-virtual BSPs, I don't clutter
> up existing ones and it would be easy to see, which BSPs already are
> virtualization capable.

Is virtualization layered onto existing BSPs ?

> Additionally, I could introduce a shared directory in
> cpukit/score/cpu/virt for include files, e.g. containing cli/sti
> replacement functions.

Are these 'replacement functions' architecture specific ?

> With the --enable-virt flag the autoconf files can be notifed about the
> different directory structure.
> I spotted a mistake in my proposed structure. It should be:
>
> c/src/lib/libbsp/virt/<arch>/<bsp_name>
>

What goes in here ?

> So the same structure, only with /virt/ added after /libbsp.
>
> However, I don't know the autoconf process in detail. That's why I'm
> asking if this is a feasible approach.

And I am not familiar with the virtualization specifics to understand 
the purpose. :)

I apologize if I am digging back over something that has already been 
covered.

Chris