Paravirtualization project - GSOC 2013

[Philipp Eppelt]

On 04/16/2013 03:54 PM, Gedare Bloom wrote:
> It seems to me that there would only need to be one para-virtualized
> CPU model and BSP for each architecture? I think it would be better to
> add a single paravirt CPU and one BSP for that CPU to each
> architecture. We can make the name unique by doing something like...
> ${arch}virt.
Yes, one model per architecture.

>
> You can split the score layer between score and libcpu for each
> architecture that has a paravirt target, for example see the sh and
> sparc64 which split some of the score functionality. Then you would
> provide the existing score implementation of privileged/sensitive
> operations as a libcpu/${arch}/shared/score directory, and
> libcpu/${arch}/${arch}virt/score to contain the para-virtualized ISR
> handling and context switch code that needs to access
> privileged/sensitive resources. Probably many para-virtualized targets
> could even be shared in libcpu/shared/virt/. This approach at least
> has some precedence, although I'm not sure what the rest of the
> community thinks about splitting existing score/cpu code between score
> and libcpu.
>
> Then to enable virtualization you would just --enable-bsp=${arch}virt.
> This BSP would set the CPU model to also be ${arch}virt.
>

I think I see where this is going. So I only get the ${arch}virt model 
in libcpu? And I don't need to touch cpukit/score/cpu/${arch}?
What happens if I get conflicting implementations in 
libcpu/${arch}/${arch}virt/ and cpukit/score/cpu/${arch}?


Regards,
Philipp