Indeed, XEN as such - from out of the shelf - is not suited to hard realtime applications, mainly due to its inter-domains scheduling strategy
and its IRQ layer model. First, the scheduler needs to deserve a hard realtime domain whenever it is required by task deadlines, and this
is not properly done yet (nor in embeddedxen actually). This is a major point on which we will spend more time on over the next months.
Any help in this area will be welcome besides. On the other hand, the IRQ layer model is based on a event polling mechanism within the
guest domain, which is not adequate to hard realtime; so this part also needs to be reworked out and designed accordingly.
This is why we set up a particular domU-RT domain (for hard realtime applications) in XEN to be able to manage this kind of issues, but
as you can see, a lot of work remains to be done. If you want, we can guide you through theses different adaptations; but one thing sure,
Thanks for your help.
> -----Original Message-----
> From: Pushparajan V [mailto:vprajan@...]
> Sent: mardi 1 juin 2010 20:17
> To: SAMBUC Lionel
> Cc: embeddedxen-devel@...
> Subject: Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd
> Hi Lionel,
> On Sun, May 23, 2010 at 12:21 AM, Pushparajan V <vprajan@...>
> Hi Lionel,
> On Thu, May 20, 2010 at 7:36 PM, SAMBUC Lionel <lionel.sambuc@...
> vd.ch> wrote:
> First, let me apologize for my last mail, whose formatting was a disaster. I am
> glad it still was helpful.
> > -----Original Message-----
> > From: Pushparajan V [mailto:vprajan@...]
> > Sent: Tuesday, May 18, 2010 8:25 PM
> > To: SAMBUC Lionel
> > Cc: embeddedxen-devel@...
> > Subject: Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd
> > Hi Lionel,
> > Thanks for the guidance.
> > Finally I am able to connect to the NFS server from qemu (without
> > breaking my head with making the rootfs in flash).
> > I reiterated the steps and got the correct configuration for this.
> > Since this is first time working with bridge & tap for U-boot, got
> > confused with the steps. :)
> > As 2 ethernet cards are required, I added one more network adapter in
> > the vmware ubuntu (adding new network card costed me just $ 0.. :) )
> It seems this is not yet clear, so I will try to explicit this by using an analogy.
> The bridge is like a hub, which has a number of interfaces (ports), as this is all
> software we can add and remove "ports" (interfaces) on the fly.
> Now in /etc/interfaces we define the bridge br0 and attached to it an ip
> address (in my configuration 192.168.1.1), while each ports (interfaces) as no
> ip identification of it's own.
> A little trick used to ensure that the Ethernet interfaces (our "ports") does
> not filter the traffic as they would usually do and transmit everything up the
> network stack is used. We put them into promiscuous mode.
> This is done in the same file for the second physical card and by qemu
> through the parameters we give it (as we instruct it to use the tap0 interface
> and the qemu-ifup and qemu-ifdown scripts). Those two script simply add to
> / remove from the bridge the interface (the "port") created by qemu when it
> starts and quits.
> This works because as soon as it is part of the bridge, all the traffic sent to /
> received on the bridge is automatically seen by all its "ports".
> On the other end of each "ports" there is a second network interface (be it
> the one emulated by qemu, or a real one) which has its own ip address.
> Then we tell the dhcp server to only listen for request on the bridge (and not
> one of its port) we enables us to add / remove "ports" on the fly without
> having to relaunch the dhcp server, as the bridge (hub) itself stays always on.
> For the tftp server, there is no such facilities, so it will answer anyone who try
> to load a file from it. As there is only our kernel uImage, it is not that much of
> a threat, but it means other computer can connect and load any file visible
> under the tftp root. It may be possible to increase security by adding some
> restriction on the inet super server.
> Now for the NFS server, it will allow the connection to the shares only
> according to the /etc/exports file in which we allow only our private network
> to access to our shares ("exports").
> Thanks for a clear explanation. I will try this out
> > 1. Changed /etc/exports for the local subnet (192.168.198.0) [got -13
> > "access denied errors, so gave full permission with asterix) 2.
> > Changed /etc/dhcp3/dhcpd.conf 3. Changed /etc/network/interfaces to
> > add new bridge interface with new ethernet card eth1 4. Reconfigured
> > embeddedxem/.cmdline.h -> It was pointing to hardcoded IP address
> > settings.. changed and recompiled
> For the rights, a line like the following should be alright:
> oabi 192.168.198.0/24(rw,no_root_squash,async,no_subtree_check)
> As explained before, the bridge do not require to have a real interface
> connected to it, so you may simply delete it and remove the references to
> your eth1 card in /etc/network. QEMU will still work as intended.
> > Finally able to see the DOM0 shell. But sometimes getting nfs: RPC
> > call returned error 101, which is anyway some configuration issue.
> This error is still to be explained, we also have it, usually one time every two
> starts, or something approaching. I have no solution or idea concerning this
> minor issue.
> > Attached screenshot of it.
> > I have one query, From which version of Xen (svn label) embeddedxen is
> > cloned from ?
> The current EmbeddedXen is based on the official 3.1.3 version of Xen.
> > I heard Samsung has done an ARM port of Xen already and didn't
> > upstream it and also it is not in sync with latest Xen. Is embeddedxen
> > also falls into the same state or it goes in sync with Xen community?
> The project is still in alpha stage, so there is no plan to upstream it at the
> moment. Now, the project was done while incorporating some of the
> modifications released by Samsung, but we are not related to them.
> We are planning to update the linux kernel used to version 2.6.34 (I am
> personally starting on this) and we may upgrade our Xen version to the 4.0.0.
> That last point is not yet defined, as we need to evaluate the benefit our
> internal projects may gain from this move.
> Thats a good news!!.. I am just curious about various usage scenarios of
> embeddedxen. If its possible to share, please do so.
> We also continue our work on the realtime side, as we still need to do some
> major modifications to the scheduling policy of the hypervisor (Xen) to be
> able to ensure the realtime constraints for a domain.
> The next item i am planning to explore more about is the performance of
> hypervisor/DOM0 service layer calls under Real time constraints. (need to try
> DOM-rt-xenomai next). I already read some articles about real time usability
> of Xen. But also confused with KVM added up from Linux kernel 2.6.20 with
> paravirtualization + hardware virtualization (support only for x86).
> I tried the xenomai stack as well and found some DOM-RT: xen_tests
> running. The main objective as you mentioned is to get seperate scheduling
> for each domain with hard realtime constraint. I got that I-pipe is responsible
> for this and its ported for some specific board under embeddedxen code
> base. (should be pxa? )
> If you can give more exposure on the flow of code under DOM-RT, it will be
> very helpful. I can collect the profiling data using Oprofile and share it.
> If possible, we can have offline chat on IRC or private chat to get more
> understanding on this.
> I found that OKL4 proves that it satisfy all RT constraints and also many
> papers are constantly proving that xen is not suited for embedded control
> systems. I strongly doubt on this.
> not sure what problem does Xen have that OKL4 solve for the RT?.. Is it only
> the scheduling method at the hypervisor level?
> basically my first objective is to get a proof that xen is also usable for RT
> systems as well.
> > Really gr8 work done here. I would love to contribute on the front of
> > documentation (as much a begineer can do here).
> We are welcoming any help, but to answer that last point, it may help if you
> could mail me what are your goals concerning EmbeddedXen.
> We can then discuss what you can contribute to the project.
> I am just experimenting with xen (for embedded systems) without much
> knowledge about it, So cannot comment more on the goals concerning to it.
> I want to try the following things with embeddedxen,
> 1. VM snapshot for pause/resume (pause at one device and resume at
> another device) 2. Try various types of virtualization possible, application virt
> (RPC), OS virt, hardware virt. software virt (qemu) 3. Try some real world
> scenario (android, meego with beagleboard)
> Not sure about the practical implication of the above experiments and also
> not sure whether any of the above trails will help in contribution.
> Pushparajan V
> Pushparajan V