New configure option RTEMS_VIRTUAL

Joel Sherrill joel.sherrill at
Tue Sep 17 15:08:38 UTC 2013

On 9/17/2013 9:51 AM, Rempel, Cynthia wrote:
>> ________________________________________
>> From: rtems-devel-bounces at [rtems-devel-bounces at] on behalf of Philipp Eppelt [philipp.eppelt at]
>> Sent: Tuesday, September 17, 2013 5:49 AM
>> To: rtems-devel at
>> 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
>> 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, 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

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

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

More information about the devel mailing list