move sensitive instructions from score to libcpu

[Philipp Eppelt]

So far I didn't come across others, while developing L4RTEMS. But there 
are include files from L4Re that I added to score. So depending on the 
hypervisor, there might be shared code that should go - in this case - 
to libcpu, too.

But I haven't checked for instructions that are sensitive, but don't 
cause a GPF. I think PUSHF/POPF are example for this. Clearly, I need to 
do more research on this.


On 04/17/2013 04:38 PM, Joel Sherrill wrote:
> Answering quickly as I am overwhelmed today.
>
> If you don't inline disable/enable interrupts, then that has
> a performance impact on the system as well as an increase
> in the maximum length of time interrupts are disabled.
>
> The SPARC already has to trap to supervisor mode to do
> this so it would not have any impact to replace the trap
> code with safe code.
>
> The x86 likely won't matter is you do this because they
> are generally very fast anyway.
>
> The ARM would have to be thought about.
>
> I doubt anyone would paravirtualize any other architectures
> anyway.
>
> What other instructions are you worried about?
>
> On 4/17/2013 8:38 AM, Philipp Eppelt wrote:
>> Hi,
>>
>> while discussing the paravirtualization project for this years GSoC, the
>> problem with the special CPU models arose.
>> If you are running in a virtual environment you can't execute privileged
>> instruction like cli/sti or hlt (x86). They need to be exchanged with a
>> call to the hypervisor (hypercall).
>>
>> To solve this we see several options:
>> 1) a new CPU model is introduced for every virtual BSP/CPU.
>> 2) loads of #ifdef guards
>> 3) split CPU model between score and libcpu. sensitive/privileged
>> instructions go to libcpu.
>> 4) new config option, which introduces a new directory packaging all
>> virtual CPU models
>>
>> 1)
>> * a lot duplicated code and a cluttered cpukit/score/cpu/ directory
>>
>> 2)
>> * mixing virtual and non-virtual code
>>
>> 3)
>> explanation by Gedare:
>>
>>> 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
>> 4)
>> * cpukit/score/cpu/virt/${arch} and libbsp/virt/${arch} introduced
>> * add --enable-virtual flag  to configure scripts
>> * modify configure scripts to adapt to the added virt/ in the source tree
>> * all virtual execution capable CPUs and BSPs bundled in the
>> corresponding directory
>>
>> The discussion leading here is on rtems-user called "Paravirtualization
>> project - GSOC 2013".
>>
>>
>> So much for the overview. The solution in question is the one by Gedare.
>> Is it feasible to split the code between score and libcpu?
>>
>> If you like it, I would explore this approach in my GSoC project on the
>> x86 architecture.
>>
>>
>> Regards,
>> Philipp
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>
>