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.
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.
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().
Thanks.
Jiageng Yu.
Screenshot-QEMU (fedora14-dm)-1.png
Description: PNG image
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home
