Paravirtualization project - GSOC 2013

Philipp Eppelt philipp.eppelt at
Wed Apr 17 13:41:00 UTC 2013

On 04/17/2013 02:41 PM, Gedare Bloom wrote:
> On Wed, Apr 17, 2013 at 5:16 AM, Philipp Eppelt
> <philipp.eppelt at> wrote:
>> 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}?
> You need to split the existing code in score/cpu/${arch} so that none
> of it touches privileged/sensitive resources. Then you will move the
> privileged/sensitive accesses to libcpu/${arch}/shared and point to it
> for the non-virt targets, and write the hypercalls for the
> libcpu/${arch}/$[arch}virt. This will avoid the potential conflicts,
> but leaves the score/cpu "incomplete" in the sense that some
> functionality like context switch and ISR handling is no longer
> located there for that target. This needs to be considered by the
> other developers too, as I do not know all the ramifications for
> splitting the score/cpu code out. You might like to start a new ml
> thread to solicit feedback on the idea if it seems the likely
> direction.
> -Gedare

Thanks for the explanation. I think this approach is very promising and 
would like to explore it.
I started a discussion on rtems-devel.


More information about the users mailing list