Hi Lionel,

On Sun, May 23, 2010 at 12:21 AM, Pushparajan V <vprajan@gmail.com> wrote:
Hi Lionel,

On Thu, May 20, 2010 at 7:36 PM, SAMBUC Lionel <lionel.sambuc@heig-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@gmail.com]
> Sent: Tuesday, May 18, 2010 8:25 PM
> To: SAMBUC Lionel
> Cc: embeddedxen-devel@lists.sourceforge.net
> 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

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, 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

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 ( [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:

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