From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: mini-guest io emulation Date: Mon, 13 Mar 2006 10:25:08 -0600 Message-ID: <44159CE4.1020106@us.ibm.com> References: <7F740D512C7C1046AB53446D3720017307306474@scsmsx402.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <7F740D512C7C1046AB53446D3720017307306474@scsmsx402.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Nakajima, Jun" Cc: Ian Pratt , xen-devel List-Id: xen-devel@lists.xenproject.org Nakajima, Jun wrote: > For the "mini guest", I think it could be much easier if we > substantially strip down xenlinux rather than adding (eventually) a lot > of stuff to the current mini-os, mainly because we need probably a > multi-threaded run-time environment, scheduler, memory allocator, event > handling, drivers such as xenbus/netfront/blkfront, etc. At least, I > think we can use xenlinux as the development platform. For example, > implement the qemu-dm as a driver adding the infrastructure required > (e.g. small in-kernel glibc). > Once you get past vl.c, qemu-dm has very little reliance on glibc functions. Since we're only trying to do hardware emulation here, I'd expect that vl.c would not be included. I suspect stripping down Linux is going to prove harder in the long run. As Jacob mentioned, you only really need a simple page allocator. The only reasons I can think of to use threads is XenBus (threads shouldn't be required to implement it) and asynchronous IO. I think an interesting alternative for AIO would actually be to create another VCPU specifically for the mini-os code to run in. The physically analogy is sane and if you truly do need more parallelism you can always just use two VCPUs. Regards, Anthony Liguori >> Once the above is working we'll be in good shape. We can remove all >> the skany qemu-dm support from the tools as from their POV paravirt >> and hvm guests will look identical. It should also be easy to >> implement save/restore of hvm guests -- just save the miniguest as >> part of the hvm guests', memory image. The next stage would then be >> to improve performance by enhancing the device models, e.g. adding a >> network card that suports jumbo frames and csum offload, and requires >> fewer vmexits in operation. >> >> How best to move forward on this? Any volunteers? >> >> Thanks, >> Ian >> >> > > Jun > --- > Intel Open Source Technology Center > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >