RE: [Xen-devel] mini-guest io emulation

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

Anthony Liguori wrote:
> 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 think it depends on how much code we borrow from Linux to get the
netfront/blkfront working. We don't need the plumbing code for
user-level apps, but we need to identify which networking/block layer
code we need for hardware emulation (and virutal device drivers, such as
VBD/VIF for HVM guests). The dependencies in the code often cause the
domino effect, ending up with a lot of codes.

> 
> 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 agree that in the long run Linux-based mini-OS will be harder, and it
depends on how soon we need it. If it's a couple of months of timeframe
(which was in my mind), I would choose xenlinux to start with -- cut the
code as much as possible so that we only use the kernel threads and
drivers. You can easily tell if you broke it because you start from
something working fine. 

The reason we need threads and scheduling is to handle simultaneous I/O
requests from SMP HVM guests. Getting reliable SMP environment is not a
trivial thing.

Jun
---
Intel Open Source Technology Center

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