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: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps

To: "Alex Williamson" <alex.williamson@xxxxxx>, "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Mon, 10 Mar 2008 13:56:55 +0800
Delivery-date: Mon, 10 Mar 2008 05:31:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1201740507.6508.55.camel@lappy>
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: <1201740507.6508.55.camel@lappy>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchjoxTyKut3PcL9STeNode/NSijyge0BFaA
Thread-topic: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
Alex & all:
        I exchanged some ideas with Isaku to discuss the gap and status
of pv_ops support in IA64, Isaku did a lot of work toward pv_ops since
his previous forward backport patch. Great thanks to Isaku.
        The attached doc is a draft for some of the key gaps and current
status. I think it is time for another cross major company meeting to
discuss how we cooperate and how effectively go with pv_ops. Mostly
Isaku and I are in same page for what IA64 pv_ops should look like now,
though some details may have different understanding. 

Any ideas?
Thx, Eddie


Alex Williamson wrote:
> Hi all,
> 
>    A few of us from the various companies working on Xen/ia64 and Red
> Hat had a phone conference to discuss requirements and directions for
> getting the XenLinux parts of Xen/ia64 into upstream and future Red
> Hat releases.  This was partially spurred by my questions on the
> mailing list about whether it's time for hybrid virtualization.  We
> decided not to pursue this option for a couple reasons.  Hybrid
> virtualization would make VT capable hardware a requirement.  This is
> unacceptable to at least Bull, and probably others.  We could work
> around this using pre-virtualization/afterburning, but that would
> introduce some potentially non-trivial post-processing and build
> changes that aren't particularly appealing.  Hybrid virtualization
> also has an unknown performance risk.  Therefore, we decided the best
> approach would be to pursue a paravirt_ops technique similar to x86.
> 
>    As with x86, there are potentially a few levels at which we'll need
> some type of paravirt ops, ex. cpu, interrupt, dma, etc...  I was
> reminded the other day that Yamahata-san already proposed a cpu level
> paravirt ops last summer:
> 
>
http://lists.xensource.com/archives/html/xen-ia64-devel/2007-07/msg00119
.html
> 
> I know he has a more recent version of this that he can send out after
> LCA, but I think this is probably a good starting point.  The cpu
> level paravirt ops are probably the most performance sensitive, so
> require some careful coding and binary patching.  As we move up the
> stack, we can probably lean more towards indirect function calls,
> much like is done with the ia64 machine vectors.
> 
>    We also discussed the need to have somewhere to collaborate on
> these activities.  I know Yamahata-san is already working on a
> forward port of domU XenLinux to a more recent tree.  We need
> somewhere to host this where we can work out the issues outside of
> the stable Xen trees.  We probably need to switch to git for this
> development so that we can more easily interact with upstream Linux
> and Stephen's tree for doing x86 dom0 work.  SourceForge might be a
> good place to host this, but I'll investigate.  Other suggestions?  I
> expect we'll want multiple admins with commit access to this tree. 
> We'll need to investigate the best way to manage this so that we can
> easily rebase, perhaps patch queues as Stephen is doing with his work.
> 
>    It was also mentioned that this will be a good time to clean up the
> code base and remove anything that's no longer needed.  Forward
> porting domU is a good first step, but we'll need to do lots of
> re-architecting to both match the new interfaces in upstream kernels
> and come up with something that we think will be acceptable to
> upstream.  I believe that's all, someone please chime in if I missed
> something.  Comments and suggestions also welcome.  Thanks,
> 
>       Alex

Attachment: paravirt_ops-discussion2.pdf
Description: paravirt_ops-discussion2.pdf

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