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

[Alex Williamson <alex.williamson@xxxxxx>]

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

-- 
Alex Williamson                             HP Open Source & Linux Org.


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