Re: [Xen-devel] Re: Linux Stubdom Problem

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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