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
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
|
Home