Paravirtualization project - GSOC 2013

[Philipp Eppelt]

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.


Regards,
Philipp