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

RE: [Xen-ia64-devel] paravirt_ops and its alternatives


  • To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Sat, 2 Feb 2008 09:11:50 +0800
  • Delivery-date: Fri, 01 Feb 2008 17:40:27 -0800
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: Achjn0ZufOhY5Z8sQpe80SLaWI0ZQABl5Lag
  • Thread-topic: [Xen-ia64-devel] paravirt_ops and its alternatives

Re-post it to warmup discussion in case people can't read PPT format, 
I didn't see comments from some of active members.
thx, eddie
 


Dong, Eddie wrote:
> Alex & All:
>       Here is a gap analysis for paravirt_ops, can you all comment?
>       In summary we have 4 catagory of jobs:
>       1: CPU paravirt_ops including MMU & timer & interrupt
>       2: Xen hooks
>       3: irq chip paravirt_ops, xen irq chip or vSAPIC?
>       4: dma for driver domain
> 
>       My understanding is that the effort is almost similar for each
part,
>       while all various alternatives such as pre-virtualization,
binary
>       patching (privify) or even unmodified Linux as dom0 only save
part
> of #1 effort, which means less than 25% effort saving. Do we really
> want a temporary solution for 25%- effort saving? So I would suggest
> we go with paravirt_ops which is the Linux community direction to
> avoid resource fragmentation. The writeup is very draft and I am
> planning to spend more time in investigation, comments are welcome.  
> thx, eddie

Attachment: paravirt_ops.pdf
Description: paravirt_ops.pdf

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

 


Rackspace

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