Hi Lionel,On Thu, May 20, 2010 at 7:36 PM, SAMBUC Lionel <email@example.com> wrote:
First, let me apologize for my last mail, whose formatting was a
disaster. I am glad it still was helpful.
It seems this is not yet clear, so I will try to explicit this by using an
> -----Original Message-----
> From: Pushparajan V [mailto:firstname.lastname@example.org]
> Sent: Tuesday, May 18, 2010 8:25 PM
> To: SAMBUC Lionel
> Cc: email@example.com
> 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.. :) )
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
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 outFor the rights, a line like the following should be alright:
> 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
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.
This error is still to be explained, we also have it, usually one time
> Finally able to see the DOM0 shell. But sometimes getting nfs: RPC call
> returned error 101, which is anyway some configuration issue.
every two starts, or something approaching. I have no solution or idea
concerning this minor issue.
The current EmbeddedXen is based on the official 3.1.3 version of Xen.
> Attached screenshot of it.
> I have one query, From which version of Xen (svn label) embeddedxen is
> cloned from ?
The project is still in alpha stage, so there is no plan to upstream it
> 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?
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).
> Really gr8 work done here. I would love to contribute on the front ofWe are welcoming any help, but to answer that last point, it may help
> documentation (as much a begineer can do here).
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.