On Thu, 17 Nov 2011, Jiageng Yu wrote:
> 2011/11/10 Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> >
> > On Wed, 9 Nov 2011, Jiageng Yu wrote:
> > > The keyboard driver is OK now. I am working on network device. In
> > > linux stubdom, I have udev, ifconfig and brctl tools. After udevd
> > > started, stubdom executes "ifconfig eth0 IPadderss netmask netgate up"
> > > to setup the network. When qemu in stubdom creates a tapxx interface
> > > for hvm guest, �?� the script should be executed to build a net bridge.
> > >
> > > �?� �?� �?� /sbin/brctl addbr eth0
> > > �?� �?� �?� /sbin/brctl addif eth0 tapXX
> > >
> > > Therefore, the hvm guest has the network device. Is this plan
> > > reasonable? Or have better one?
> >
> > The bridge should be called xenbr0, the stubdom's network interface
> > (that should probably called eth0) should be added to the bridge at boot
> > time.
> >
> > Like you said, when qemu starts is going to create a tap interface, on
> > Linux usually we rely on a udev script to add the tap interface to the
> > bridge. The script is tools/hotplug/Linux/vif-setup, that calls
> > tools/hotplug/Linux/vif-bridge.
> >
> > So at the end you have:
> >
> > xenbr0 (bridge)
> > ||
> > |+-------------------------------+
> > | Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã?Â
> > �?� �?� �?� �?� �?� �?� �?� |
> > eth0 Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã?Â
> > �?� �?� �?� �?� �?� �?� |
> > (stubdom network interface) �?� �?� �?� tapXX
> > Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã? Ã??Ã?Â
> > �?� �?� �?� �?� �?� �?� �?� (qemu's tap
> > interface)
>
>
> Hi Stefano,
>
> �?� �?� �?� I have a prototype of network of linux based stubdom,
> as shown in
> attached figure. I list my design�?� points, please comment on them.
>
> 1. Qemu-ifup script in Linux stubdom.
>
> Qemu in stubdom invokes qemu-ifup script to setup the
> bridge(net/tap.c). Because the linux stubdom only has nash and can not
> execute the qemu-ifup script, I implement a c version of qemu-ifup
> script. Using the following way, the qemu will invoke qemu-ifup
> program in stubdom.
>
> diff -r 0f36c2eec2e1 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c Thu Jul 28 15:40:54 2011 +0100
> +++ b/tools/libxl/libxl_dm.c Thu Nov 17 22:41:29 2011 +0000
> @@ -29,9 +29,12 @@
> #include "libxl.h"
> #include "flexarray.h"
>
> -static const char *libxl_tapif_script(libxl__gc *gc)
> +static const char *libxl_tapif_script(libxl__gc *gc,
> + libxl_device_model_info *info)
> {
> #ifdef __linux__
> + if(info->device_model_linux_stubdomain)
> + return libxl__sprintf(gc, "/bin/qemu-ifup");
> return libxl__strdup(gc, "no");
> #else
> return libxl__sprintf(gc, "%s/qemu-ifup", libxl_xen_script_dir_path());
>
> I do not use libxl_xen_script_dir_path() to determine the path of
> qemu-ifup, because we don't want include xen-unstable.hg/Config.mk in
> linux stubdom. Therefore, I hardcoded this path.
That is OK.
> 2. Network tools.
>
> Our linux based stubdom do not have the real shell and IP stack,
> so we must custom the network tools. I notice the bridge-utils-1.5
> version creates AF_LOCAL socket, so brctl can be used without
> modification. But ifconfig would not be so luck. I need to rewrite
> ifconfig and make it only support bring up the interfaces.
I think you need to call a couple of ioctl in order to enable a
network interface.
> 3. The mac address.
>
> If we declare the mac address in stubdom-cfg file, the eth0 in
> stubdom and eth0 in hvm guest will be set to the same mac address.
>
> do_domain_create (or libxl__create_stubdom)
> -->libxl_device_nic_add
>
> As a temporary solution, I hardcoded a static mac address for linux
> stdubom in libxl__create_stubdom().
The mac address of eth0 (and xenbr0) in the stubdom is not
important considering that is never going to be used: all the traffic
should go through the tap interface anyway.
It could even be fe:ff:ff:ff:ff:ff._______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home