WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: Transparent paravirtualization vs. xen paravirtualization(was:RE: [X

To: "Yang, Fred" <fred.yang@xxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: Transparent paravirtualization vs. xen paravirtualization(was:RE: [Xen-ia64-devel] IRQ management)
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 25 Oct 2005 19:45:52 -0700
Delivery-date: Wed, 26 Oct 2005 02:43:25 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXYoH5VC58JP0jcTAKD11ElTp2+BAADaykAABRR42AAGmYeQAAVNmjAAAVaOgA=
Thread-topic: Transparent paravirtualization vs. xen paravirtualization(was:RE: [Xen-ia64-devel] IRQ management)
> The community should try to reduce recurrent effort.

I agree entirely but I think the correct way to do this is
to determine and implement a proper interface between
arch-dep and arch-neutral functionality for Xen, as was done on
Linux.  We were successful at doing this for the core hypervisor.
We need to do this for drivers too.

> Key issue on
> gnttab is Domain0 should also have PMT table support, which shouldn't
> access machine physical with gpn=mpn directly.  This issue is also the
> key reason causing major effort in porting VBD/DomainU for 
> each upstream
> merge.  This also blocks the forward VNIF effort due to page flipping
> issue.
> PMT is a must for gnttab to support VBD, VNIF and forward 
> development of
> Xen/ia64.   PMT would need to be shared between Domain and Xen for
> performance

I guess I disagree.  I've seen all the patches for each upstream
merge and it doesn't look to me as if a major design change
is required, just a clarification of the arch-specific boundaries.

Could you explain what you mean by "blocks the forward VNIF effort
due to page flipping issue"?  Page flipping should work just fine
in the current design; Matt had it almost working (out of tree)
before he went back to school.

> > By fixing irq handling and clearly understanding and properly
> > implementing architectural neutrality in event channels and
> > grant tables, I think we will eliminate most of the rebasing
> > difficulties.
> Key issue is Xen/ia64 shouldn't derail from basic grant table design

I don't see that it is significantly different.  We moved to
a separate file only as a temporary measure because there were
a handful of x86-specific lines of code in the core gnttab.c.
Unfortunately, we have not yet merged back, and that is the
source of some of the upstream merge issues.

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

<Prev in Thread] Current Thread [Next in Thread>