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

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

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