Paravirtualization project - GSOC 2013

[Philipp Eppelt]

On 04/17/2013 02:41 PM, Gedare Bloom wrote:
> On Wed, Apr 17, 2013 at 5:16 AM, Philipp Eppelt
> <philipp.eppelt at mailbox.tu-dresden.de> 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
>
Hi,

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

Regards,
Philipp