New configure option RTEMS_VIRTUAL

[Joel Sherrill]

On 9/17/2013 9:51 AM, Rempel, Cynthia wrote:
>> ________________________________________
>> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Philipp Eppelt [philipp.eppelt at mailbox.tu-dresden.de]
>> Sent: Tuesday, September 17, 2013 5:49 AM
>> To: rtems-devel at rtems.org
>> Subject: New configure option RTEMS_VIRTUAL
>>
> <snip>
>> The only satisfying way to compile the interrupt code dependent on
>> native or virtual environment is to introduce a configuration option
>> similar to RTEMS_SMP and RTEMS_MULTIPROCESSING:
>>
>> RTEMS_HYPERVISOR or RTEMS_VIRTUAL
>>
>> Other options:
>> :Introduce a new CPU target:
>> Besides i386 a new CPU i386-virtual could be introduced. This adds a lot
>> of duplicated code. The only difference would be 160 lines of code.
>>
>>
>> In the future this option can be used for other projects virtualizing
>> RTEMS on top of some hypervisor with any target CPU.
>>
>>
>> Do you have other ideas?
> Yes, option 3 could be to give the user the option of i386-virtual which would set the ax_rtems_virtual macro in configure.ac, so it would look like option 2 to the user and look like option 1 to the build-system... but if we're planning to have a virtual bsp for different architectures, we'd want to decide if option 3 is more desirable than option 1 or 2...
I expect we will end up with hypervisor support for multiple hypervisors
and on the x86, sparc, arm and powerpc architectures.

I know there are unmerged hypervisor ports for the sparc and and pretty
sure for the arm on L4.

If you change the target name, you need to ensure that the target name
change doesn't negatively impact tool name, target dependent configure
logic, etc.

Part of this project was to lay the general groundwork as a pattern
for supporting other hypervisors on x86 and other architectures.
As is typically the case with RTEMS, the solution must be general.
>> What do you think about this?
> Could you provide links in your projects rtems wiki page to the 160 lines of code so a student making a virtual target for a different architecture would know where to start?
> Could you also document why inline functions were unsatisfactory?
One of the cases was interrupt disable/enable. They need to be inlined 
for speed
and have to be virtualized with the hypervisor because (1) you don't 
have permission
to do it in a virtual environment and (2) it may require special 
handling by the
hypervisor.

Some of the other cases I have seen are during context switches where
certain bits or registers are off limits when virtualized.

Also the interrupt dispatching can be impacted. This is often on the BSP
side of the code tree so not as much of a problem but still not the same
virtual or real hardware.

It's not the quantity of code in this case, it is the precision of what
differs and how it impacts performance and behavior.

But I would like a full list. This is just from memory.
> Thanks!
> Cindy
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
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