RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

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