move sensitive instructions from score to libcpu

[Joel Sherrill]

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


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985