Re: mini-guest io emulation

[Edwin Zhai <edwin.zhai@intel.com>]

Ian,
have some questions for mini-os io emulation
1. seems dom0 still need do the user interaction( screen painting, kbd/mouse
detection), so how much performance gain with extra dom switch(dom0<->mini
os<->VMX guest) ?

2. even with mini-os io emulation, pit/pic/iopaic/lapic still sit in Hypervisior,
right?

3. we are currently doing the save/restore for VMX guest with the expection that
mini-os emulation only affect device model save/resotore. we can continue
current work (just save the qemu-dm state) and sync with mini os in future.


On Sun, Mar 12, 2006 at 09:26:26PM -0000, 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
> 
> 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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
thanks,
edwin