18 messages in com.xensource.lists.xen-ia64-devel[Xen-ia64-devel] paravirt_ops and its...
FromSent OnAttachments
Dong, Eddie30 Jan 2008 16:21.ppt
Isaku Yamahata30 Jan 2008 17:44 
Alex Williamson30 Jan 2008 19:23 
Dong, Eddie30 Jan 2008 19:44 
Isaku Yamahata30 Jan 2008 20:45 
Isaku Yamahata30 Jan 2008 20:51 
Dong, Eddie01 Feb 2008 17:11.pdf
Yang, Fred03 Feb 2008 09:23 
Dong, Eddie03 Feb 2008 17:52 
Alex Williamson04 Feb 2008 11:44 
Yang, Fred04 Feb 2008 12:10 
Dong, Eddie04 Feb 2008 15:40 
Isaku Yamahata04 Feb 2008 18:44 
Kouya Shimura05 Feb 2008 02:25 
Dong, Eddie05 Feb 2008 05:46 
Dong, Eddie05 Feb 2008 06:16 
Isaku Yamahata05 Feb 2008 17:59 
Dong, Eddie05 Feb 2008 23:13 
Subject:[Xen-ia64-devel] paravirt_ops and its alternatives
From:Dong, Eddie (eddi@intel.com)
Date:01/30/2008 04:21:28 PM
List:com.xensource.lists.xen-ia64-devel
Attachments:

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