From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4A3FA070.1020200@domain.hid> Date: Mon, 22 Jun 2009 17:17:04 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <634c78ce0906120240t694ded8cpfa7fcd9dfb2c3b8@domain.hid> <200906121148.37732.smolorz@domain.hid> <4A3235BF.5090201@domain.hid> <4A324D3D.9060505@domain.hid> <4A325189.5060905@domain.hid> <4A3253DB.5040109@domain.hid> <4A32674C.7060007@domain.hid> <4A3F8D37.2040908@domain.hid> <4A3F9496.7050209@domain.hid> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ROSSIER Daniel Cc: Jan Kiszka , "embeddedxen-devel@domain.hid" , GERBER Patrick , "xenomai@xenomai.org" ROSSIER Daniel wrote: >> -----Original Message----- >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >> Sent: lundi, 22. juin 2009 16:27 >> To: ROSSIER Daniel >> Cc: Jan Kiszka; xenomai@xenomai.org; GERBER Patrick; embeddedxen- >> devel@domain.hid >> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine >> >> ROSSIER Daniel wrote: >>>> -----Original Message----- >>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid] >>>> Sent: lundi, 22. juin 2009 15:55 >>>> To: ROSSIER Daniel >>>> Cc: Johan Visser; xenomai@xenomai.org >>>> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine >>>> >>>> ROSSIER Daniel wrote: >>>>> Just going through this interesting thread, I though it might be of >>>> interest - probably not fully related to the topic, but... - to know >>>>> that we are currently working on some integration efforts of >> Xenomai >>>> on top of the XEN hypervisor in the context of the >>>>> embeddedXEN project. For the time being, it is purely devoted to >> ARM- >>>> based processors. >>>>> In case of interest, please visit: >>>> https://sourceforge.net/projects/embeddedxen. Xenomai will appear as >> a >>>> natural subtree of embeddedXEN, like xen or minios, >>>>> but currently it is not present yet. The hypervisor and miniOS >> boots >>>> up in Mainstone/QEMU and soon on a Colibri/PXA270 board. EmbeddedXEN >> is >>>> mainly devoted to integrate multiple kernels into a single binary >> image >>>> for embedded systems with the support of hard realtime (domainU-RT, >> a >>>> new kind of Xen domain). >>>> >>>> Interesting, will have a look (again). Last time I checked was two >>>> years >>>> ago when MontaVista (IIRC) announced it. Does/will this version Xen >> not >>>> suffer from the RT problems Xen upstream has, e.g. lacking >>>> preemptibility? >>> Indeed, it is a major point we want to investigate; we will assess >> the overhead bound >>> to the upcall model of XEN. It is too early to make some predictions >>> >>>> And what will be the impact on Xenomai? A new sub-arch per real >> arch? >>>> Will Xenomai run stand-alone or together with a Linux kernel as on >> real >>>> silicon? In the former case, what will be the programming model, >>>> specifically regarding RT<->non-RT communication? >>> We are actually working out a standalone version of Xenomai (removing >> i-pipe) keeping >>> the strict minimum of Linux functionalities in order to bootstrap a >> simple Xenomai domain (memory manager, . >>> I do not have yet a clear vision of how the RT/non-RT communication >> will look like, but probably >>> it will rely on the event channel mechanisms of XEN. Maybe Patrick >> can tell us more about that... >> >> Maybe a stupid question: but does the Xen domain/context switch routine >> flush the cache? > > Not really a stupid question: every time a MMU-context switch occurs, the flash is > invalidated, therefore mostly each time there is a domain context switch. > The way how it is invalidated will depend on the processor; it is badly implemented > with PXA270/Xscale where the entire cash is flushed, requiring quite a lot of latency... > We can improve it using the Fast Context Switching Extension, but never made some tests with that. The problem I see with FCSE is that you will need a way to allocate the PIDs globally, i.e. at Xen level. -- Gilles