WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] mini-guest io emulation
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Sun, 12 Mar 2006 21:04:51 -0800
Delivery-date: Mon, 13 Mar 2006 05:05:55 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZGDAxq9Jt2k5rVSlWxxMIWrrSajAAOiAAw
Thread-topic: [Xen-devel] mini-guest io emulation
Ian Pratt wrote:
> Folks,
> 
> At the last summit I presented a proposal for rearchitecting the way
> we do io emulation for fully-virtualized (hvm) guests. I'd really
> like to try and get the work to implement this underway, as it cleans
> up a bunch of mess, is a prerequisite for save/restore/relocation of
> hvm guests, and is a precursor to some significant performance
> improvements. It involves a fair chunk of work, so we really want to
> try and get multiple folk working on it.
> 
> The plan is to move the io emulation code (qemu-dm) from running as a
> user-space app in domain 0 into a 'mini guest' that is effectively a
> small paravirtualized guest in the root hardware context associated
> with each hvm domain.
> 
> I guess a very high-level work plan would look something like this:
> 
> * get minios running well on x86_64; add a few simple infrastructure
> functions e.g. simple memory allocator. No need for any 'user space'
> mmu support
> * port (simplified)xenbus/netfront/blkfront to minios; test simple
> net/disk IO
> * implement enough infrastructure to allow qemu-dm to be compiled into
> minios, calling into net/blkfront for IO.
> * plumb the vmexit entry points from MMIO and in/out into minios and
> hence qemu-dm

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 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel