This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] paravirt_ops and its alternatives
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <10EA09EFD8728347A513008B6B0DA77A02B655F0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <10EA09EFD8728347A513008B6B0DA77A02B655F0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
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
>       while all various alternatives such as pre-virtualization,
>       patching (privify) or even unmodified Linux as dom0 only save
> 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