Paravirtualization project - GSOC 2013

[Gedare Bloom]

On Tue, Apr 16, 2013 at 9:20 AM, Philipp Eppelt
<philipp.eppelt at mailbox.tu-dresden.de> wrote:
> Hi,
>
>
> On 04/16/2013 10:54 AM, Chris Johns wrote:
>>
>> 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 ?
>
> _CPU_Thread_Idle_body() is executing the privileged instruction "hlt" on
> i386. This is not allowed in a virtual environment, as it would impact other
> VMs using this CPU.
> In L4RTEMS, using L4Re (L4 Runtime environment), I replaced "hlt"with a call
> to l4vcpu_wait_for_event() which stops the VM until the next interrupt.
> I guess other CPUs have similar instructions, so the _CPU_Thread_Idle_body()
> could be implemented in a architecture independent fashion.
>
>
>>
>> Are you going to create a new --target=virt-rtems4.11 target for gcc and
>> RTEMS ?
>
> I did this in L4RTEMS, it's called l4vcpu-rtems4.11, but it's unlikely you
> want to add a new target for _every_ virtual CPU RTEMS should run. So the
> idea is, to stick to the target, but add an additional flag (--enable-virt),
> and do all the virtualization stuff inside the /virt/ directories.
>
>
>>
>> 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.
>
> That's why I am asking ;)
>
>>
>>> 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 ?
>
> Partially, you have to port every BSP by hand to the virtual environment. As
> hardware access is different from normal execution. You have to share the
> hardware, so the hypervisor has to assign resources to the VMs. So you need
> functions for signing a request. These should be(goal) architecture
> independent. If the hypervisor supports device-pass-through, you don't have
> to change much, but you can't pass through a clock or timer.
>
>
>>
>>> 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 ?
>
>
> The goal is to provide a clear interface, which is implemented by the
> hypervisor. Once it's up and running, RTEMS should be fine and the
> hypervisor side has to implement the interface.
>
>>
>>> 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 ?
>
> All virtualization capable architectures and BSPs. To draw a clear line
> between real hardware and virtual hardware BSPs.
>
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.

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.

-Gedare

>
> Regards,
> Philipp
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users