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

[Gedare Bloom]

On Wed, May 15, 2013 at 1:29 PM, Philipp Eppelt
<philipp.eppelt at mailbox.tu-dresden.de> wrote:
>
>
> On 05/15/2013 03:55 PM, Gedare Bloom wrote:
>>
>> 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".
>>
>
> I would refrain from calling it shared/, as it would imply shared
> functionality with virtual/. At least that my understanding of the usage in
> all other parts of the system.
> Maybe native is the best description as it opposes virtual.
>
> *libcpu/i386/virtual
> *libcpu/i386/native
>
OK this might be good enough. The "shared/" subdirectory is used as an
optional shared in libbsp, but since shared/ exists in some of the
libcpu/ARCH directories, it will be better to provide a new name like
"native" or whatever we finally set on.

>
>
>>> 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.
>
>
> The mentioned functions contain privileged instructions: hlt, cli, sti
> These functions cannot be executed in a virtual environment and must be
> replaced with environment specific function calls.
>
Yes I know, we just need to document the set of instructions (per
architecture) somewhere sensible.

>
> Regards,
> Philipp