From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grzegorz Milos Subject: Re: mini-guest io emulation Date: Mon, 13 Mar 2006 12:41:11 +0000 Message-ID: <44156867.6010704@cam.ac.uk> 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: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jacob Gorm Hansen Cc: Ian Pratt , xen-devel , "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org As Ian mentioned some work needs to be done to make mini-os work on 64 bit platform but the current 32 bit version of mini-os already has: - simple scheduler (RR like) - memory allocator (buddy allocator, and ported xmalloc build on top of buddy) - xenbus implementation I've implemented all of it last year. Obviously if we start using it for I/O emulation it will have to be tested more extensively, but it seemed to work just when I used it for my trusted domain builder. As Aravindh mentioned it his email, we've recently added 64-bit page table builder, which means that the memory allocator should now work on 64bit platform as well. There are still a few things on TODO list we've created with Aravindh but I think it should be much easier to resolve those then strip Linux down. And I do agree with Jacob, mini-os could be useful for many other things then just I/O emulation. Cheers Gregor >> 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). > > It seems to me the main reason we needs threads and scheduling is to > interact with Xenstore. A page allocator can't be that hard to > implement. I wonder if the Xenstore API could be simplified in a way > that does not require threading, thus making the job of implementing > drivers in a min-os a bit simpler? > > My feeling is that even a stripped down Linux would take some work to > maintain, at least if we wish to remove the need for hotplug scripts > for driver backends and the like from the miniLinux. > > I have little interest in hvm guests, but having a functional mini-os > with an extensible, perhaps oskit- or TinyOS-like, structure would be > a huge win in a number of other situations as well. If I can I would > like to help. If the mini-os ever gets functional, I suppose it would > help to include it in the regression tests, to prevent the bit-rot it > is currently suffering from. > > Jacob > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel