[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Introduction to Linux based stubdom (GSoC 2011)


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: 于佳耕 <yujiageng734@xxxxxxxxx>
  • Date: Thu, 5 May 2011 23:45:29 +0800
  • Delivery-date: Thu, 05 May 2011 08:46:40 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=d+XgkBo/RH1PUsxqOqOi08qOKi+DzvpzzLi1X5llvIoxwiJVZk9fHOFhBp7zqryDMQ A9XDzdyCdxn2OQ3gW9v/K6gMn+xJkhXBShNud8saJTAsiiUxFVJZGu8OhyksTk8v/T29 1PZBAZeb9KdNSQ/apvVXG97p6m6SJd6wT6shY=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi all,

    I am Jiageng Yu. I come from Institute of Software, Chinese
Academy of Sciences, Beijing, China. I have been accepted to GSoC 2011
and will work on the project of Linux based stubdom in next three
monthes. I am greatly honored and excited to join the Xen community.

    Stubdoms are very small Xen PV guests used to run some software
components that otherwise live in dom0. We plan to implement a linux
based stubdom, which provides devices emulation to a particular HVM
guest. The major tasks of this project are described below.

     1. We have to establish the environment of linux based stubdom
with minimal linux kernel and shared libraries, which could contain
the upstream qemu exactly. We also maintain a minimal upstream qemu by
cutting unnecessary objs in its configuration phase. The minimal linux
kernel, shared libraries and the upstream qemu are packed into the
ramdisk, which is the real body of stubdom we need.

     2. We could adapt simulation devices of upstream qemu to the
relevant frontend devices of stubdom in optimal ways. In this
scenario, we will consider the devices including network, disk and
graphics.

     3. We could also implement the proper save/restore mechanism of
simulation devices. As we all know, qemu running in the stubdom writes
a statefile that has to be returned to the toolstack in dom0.
Currently minios based stubdoms use two PV consoles to do that, which
have not been supported in Linux. Therefore, instead of additional
consoles, we create a dynamic virtual disk to transfer save/restore
data between Dom0 and stubdom.

     4. We plan to make stubdom to support pci pass-through devices.
Our goal is to map the memories (including ioport, iomem and irq) of
pass-through devices into memories of frontend devices in stubdom.
That could be a few differences to the implementation of MiniOS based
stubdom.

     5. At last, we produce benchmarks to measure the resource usage
and the level of performances of linux stubdom in comparison with
MiniOS stubdom. We will measure the throughputs such as CPU, disk and
network, etc.

    This is a brief introduction to the project. Any suggestion or
question will be Thankful!

    Best Regards!


Jiageng Yu

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.