Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd

[SAMBUC L. <lio...@he...>]

Hello,

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:vp...@gm...]
> Sent: Tuesday, May 18, 2010 8:25 PM
> To: SAMBUC Lionel
> Cc: emb...@li...
> 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").
 
> 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:
/opt/boards/filesystem/rootfs-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.

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.

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

> 
> --
> Pushparajan V
> http://vprajan.blogspot.com
> 
> 
> 

Regards, 

Lionel Sambuc