[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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

Intel Open Source Technology Center

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.