[virt-layer] score/libcpu split (i386)

[Gedare Bloom]

On Tue, May 14, 2013 at 11:55 AM, Philipp Eppelt
<philipp.eppelt at mailbox.tu-dresden.de> wrote:
> Hi,
>
> I looked into the libcpu/sh dir to understand how the split of the CPU code
> between score/cpu and libcpu/ works.
>
> My approach for the i386 arch brings some changes to existing files:
>
> * score/i386/rtems/score/cpu.h
> * score/i386/cpu.c
> * score/i386/rtems/score/interrupts.h
>
> The list of functions, sensitive for a virtualization environment is rather
> short (up until now):
>
> * _CPU_ISR_Set_level (cpu.h)
> * _CPU_Fatal_halt (cpu.h)
> * _CPU_Thread_Idle_body (cpu.c)
> * everything in interrupt.h
>
> For a full and up to date list, check [0].
>
> I want to introduce new directories containing the right versions for the
> above mentioned functions:
> * libcpu/i386/virt-pok
> * libcpu/i386/{native|hw|nonvirt|..}
>
Why "virt-pok" and not just "virt" or "virtual"?

Probably the other side (native/hw/nonvirt) can just be called
"shared/score". And you would put the virtualized functionality in the
"virt-pok/score".

>
> To get this into the toolchain:
> * Introduce a conditional called 'virt-pok' in configure.ac
> * Branch on this conditional in Makefile.am
>
Yep.

>
>
> As just a small portion of cpu.h is affected, does it make sense to split
> this file?
I think so. Documentation shall have to be added in a few places.

> Which part do I need to explain in more detail?
Probably the justification for which code is identified as
sensitive/privileged, and what is not.

> Do you know of any traps, that I might run into?
There may be some doubts about performance if some thing that is a
macro or inline routine turns into a function call. Then we will need
to evaluate the performance overhead for the non-virtualized version.

> What do you think of this?
> Is there a chance to get this change upstream? Otherwise I have to find a
> more convenient approach to solve this.
>
I think so, but it depends a little on the performance overhead.
Probably it will be fine...

-Gedare

>
> Regards,
> Philipp
>
>
> [0]
> http://wiki.rtems.org/wiki/index.php/GSOC_2013_-_Paravirtualization_of_RTEMS#libcpu.2Fscore_split
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel