On 9/17/2013 9:51 AM, Rempel, Cynthia wrote:
________________________________________
From: [email protected] [[email protected]] on behalf
of Philipp Eppelt [[email protected]]
Sent: Tuesday, September 17, 2013 5:49 AM
To: [email protected]
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
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
--
Joel Sherrill, Ph.D. Director of Research & Development
[email protected] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
