RFC - Time & space partitioning with RTEMS

Mon Apr 28 17:12:14 UTC 2008

Is this herebelow the RTEMS open project you are currently evoking  ?
If it is the case, I think it is really interesting, if it is possible to implement the hypervisor though a very light {subset+adaptation} of the current RTEMS supercore, in order to maintain acceptable real time performances. 
What is your opinion ?

RTEMS Virtual Machine Monitor

Status: No active volunteers. 
RTEMS based RT-VMM (Real-Time Virtual Machine Monitor). Current RTEMS can not support to run another OS (such as Linux or uClinux). We want to add hypervisor (or Virtual Machine Monitor) function on RTEMS, then RTEMS has the power like XEN that can run Linux or other OS, but RTEMS also maintain original hard Real-Time funtions. First, we will try to make RTEMS run uClinux on ARM simulator SkyEye( http://www.skyeye.org <http://www.skyeye.org/>  ), then we will try to make RTEMS run ARM Linux on XSCALE CPU based board or SkyEye simulator. We consider virtualization techs on Embedded RTOS area has potential value. (from chyyuu at gmail.com)
	-----Message d'origine-----
	De : xu ray [mailto:rayx.cn at gmail.com] 
	Envoyé : lundi 28 avril 2008 18:42
	À : Metge Jean-Jacques
	Cc : rtems-users at rtems.com
	Objet : Re: RFC - Time & space partitioning with RTEMS

	One of the item I put in rtems wishing list has something in common to this is proposal. However, I just want to put MMU and page system to RTEMS memory management. This proposal is more focus on divide user mode and supervisor mode.
	I think this will be a tough job for only one or two people. Also, if we want to implement this mode, lots of driver/BSP might need to change when user what to put data from App to HW. And, how to support both non-MMU and MMU processor is another problem.

	2008/4/28 Metge Jean-Jacques <jean-jacques.metge at cnes.fr>:

		Dear all,

		I would like to re-open a july 2007 discussion about time and space
		partitionnig with RTEMS (see below).
		Based on my past experience of ARINC653 development in aeronautics
		domain, I really think, as Joel wrote in july 2007, that space community
		(at least), which is an important user community of RTEMS products,
		could get a big added-value from splitting RTEMS in 2 separate layers :
		- 1 low level and very light layer (let's call it "RTEMS level 1"),
		usually called "hypervisor", running in supervisor mode, aiming at
		creating robust partitions in the sense of ARINC653 standard (ie
		dedicated memory zones, dedicated I/O zones and appropriate time slices,
		with appropriate protections and monitoring). This supervisor should
		rely on a hardware MMU, meaning that appropriate hardware function
		should be specifically developed for the LEON processor
		- 1 medium level layer (let's call it "RTEMS level 2"), sometimes called
		"partition OS", running in user mode, to be hosted, if requested by one
		or several users, in one or several of the created partitions.(*)

		(*) The upper layer being the software applications themselves.
		Note that a the decision to use or not RTEMS layer 2 as partition OS is
		totally let to any user, which may prefer to develop its own basic
		software or to adapt its own usual  OS on top of RTEMS level 1.

		In order to concretly progress on this ambitious topic (I think), my
		current idea would be to :
		- first, develop a new "2-layers RTEMS" prototype (to be ran on ground,
		on an existing LEON board prototype), to be derived from an existing
		RTEMS version for LEON, in order to validate the concept
		- in a second step, develop, on the basis on this prototype, a new RTEMS
		open source version, compatible with LEON processor, and compatible with
		software development standards applicable to space on board software.

		Does anybody feels some interest with this exercise ?
		Does anybody already works on this idea and could be ready to provide
		some helps and/or to exchange some technical views ?

		Thank you by adavance for your attention.

		Regards

		Jean-Jacques

		========================================================================
		========

		RFC - Memory Partitioning

		*       Date: Tue, 24 Jul 2007 10:19:08 -0500
		*       From: joel.sherrill at oarcorp.com (Joel Sherrill)
		*       Subject: RFC - Memory Partitioning

		Robert S. Grimes wrote:
		> I've been thinking about this for a while too.  I haven't anything too
		> concrete to suggest at this time, but I don't want to see your post
		die
		> on the vine.  I do have some observations about the nature of the
		> proposed beast...
		>
		> One thought is that this move could result in the POSIX API becoming
		> more in line with other implementations, if each "partition" could act
		> as a "process" in the proposed RTEMS.  This would allow developers the
		> usual choices of multi-process, multi-threaded (I like to think of
		RTEMS
		> "tasks", in traditional API-speak, as "threads"), or combinations.
		>
		>
		I think you proposed using a hypervisor to put each
		RTEMS "process" inside its own container.  Then you could
		get ARINC separation.  Without reading the standard, could
		we implement an ARINC 653 manager that each RTEMS
		application runs inside of?
		> Another thought is that truly hard-real-time activities could run in a
		> suitably "high priority" partition, using such things as the rate
		> monotonic scheduler, and softer code then could run in other
		partitions.
		>
		> I certainly would not want to eliminate the current model of RTEMS,
		> especially wrt low overhead, high performance on "smaller" systems,
		> especially those without MMU.  A rather simple-minded idea could be to
		> think of such systems as "single partition" systems, which might lead
		to
		> a useful guiding principle: In the proposed new RTEMS, a single
		> partition looks, acts, feels, sounds, smells, etc. like a traditional
		> RTEMS system.
		>
		I think this is the way to go.  Writing trap interfaces
		for god knows how many services, dealing with the
		known memory issues (e.g. copying buffers, mapping
		memory, etc.), and who knows what else will be a significant
		undertaking.

		Approaching the problem by writing an ARINC 653 hypervisor
		will be more definable and give more value in the end to
		the RTEMS Experience. :)

		I think this approach would have extremely high value for
		the community and I would like to see it as a project.
		If there is interest, users from the space and aviation
		communities should be able to help sponsor this.

		> Just my $0.02, adjusted for inflation...
		>
		My opinion's value is about the same. :)
		> -Bob
		>
		> Charles Steaderman wrote:
		>
		>> RFC
		>>
		>> Memory Partitioning Support in RTEMS
		>>
		>> Goals:
		>> Provide task level code and memory partitioning for RTEMS. The short
		>> term goal would be for a project that contains functionality to be
		FAA
		>> certified at different certification levels (background data
		>> collection and storage certified to FAA Level C, and user interface
		>> non-certified).
		>>
		>> Proposed Strategy:
		>> Based upon some research into commercial partitioned embedded OSes
		>> (Integrity, Nucleus Secure, etc), I would like to suggest the
		>> following strategy for enhancing RTEMS. First, to provide separation
		>> from the kernel, I would propose that all RTEMS kernel calls be
		>> accessed via a TRAP or SWI. In this way, the kernel code can be
		mapped
		>> into a non-accessable memory area in order to provide protection from
		>> userland tasks. Second, I would propose that task creation and
		context
		>> switching become memory region aware. Task creation would need to be
		>> supplied memory regions and access permissions and those permissions
		>> would need to be updated on a context switch (MMU registers). In
		>> addition, each task could have its own private memory heap for
		dynamic
		>> memory allocation. This would mean that memory allocation would need
		>> to be told whether the allocation should come from the local or
		global
		>> heap.
		>>
		>> I am sure that there is a large number of issues that I have
		>> overlooked, but I would like to get people thinking about
		partitioning
		>> in RTEMS. In much the same way that desktop operating systems have
		>> benefitted from process protectsion (Win9x vs. WinNT or OS 9 vs. OS
		>> X), I think that given the present and future state of embedded
		>> hardware, embedded systems could benefit from the same robustness.
		One
		>> advantage that I believe the proposed solution has is that the code
		>> resides in a single address space, rather than virtual memory spaces.
		>> Perhaps this will cause problems with library calls and shared code,
		>> but perhaps there is a novel solution that we could employ.
		>>
		>> Thank you for your time and consideration.
		>>
		>> - Charlie
		>>
		>> _______________________________________________
		>> rtems-users mailing list
		>> rtems-users at rtems.com
		>> http://rtems.rtems.org/mailman/listinfo/rtems-users
		>>
		>>
		> _______________________________________________
		> rtems-users mailing list
		> rtems-users at rtems.com
		> http://rtems.rtems.org/mailman/listinfo/rtems-users
		>

		*       References:
		*       RFC - Memory Partitioning <msg00084.html>
		*       From: charlies at poliac.com (Charles Steaderman)
		*       RFC - Memory Partitioning <msg00086.html>
		*       From: rsg at alum.mit.edu (Robert S. Grimes)
		*       Prev by Date: RFC - Memory Partitioning <msg00086.html>
		*       Next by Date: GameBoy Advance BSP <msg00088.html>
		*       Previous by thread: RFC - Memory Partitioning <msg00086.html>
		*       Next by thread: RTEMS and I2C APIs <msg00111.html>
		*       Index(es):
		*       Date <date1.html>
		Thread

		_______________________________________________
		rtems-users mailing list
		rtems-users at rtems.com
		http://rtems.rtems.org/mailman/listinfo/rtems-users

	-- 
	Thanks & Best Regards!

	Ray, Xu 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080428/06067bf5/attachment-0001.html>