Paravirtualization project - GSOC 2013

[Gedare Bloom]

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

>
> Regards,
> Philipp