| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] mini-guest io emulation
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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
--
thanks,
edwin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home