On Fri, 2008-02-15 at 00:43 +0800, Dong, Eddie wrote:
> I agree with your catagory, but I think #C is the 1st challenge we
> need to address for now. #A could be a future task for performance
> later after pv_ops functionality is completed. I don't worry about
> those several cycles difference in the primitive ops right now,
> since we already spend 500-1000 cycles to enter the C code.
IMHO, #A and #C are both blockers for getting into upstream
Linux/ia64. Upstream isn't going to accept a performance hit for a
paravirt enabled kernel on bare metal, so I'm not sure we should
prioritize one over the other, especially since Isaku has already made
such good progress on #A.
> The major challenge to #C is listed in my previous thread, it is not
> an easy thing to address for now, especially if we need to change
> original IVT code a lot.
The question of how to handle the IVT needs to be decided on
Linux-ia64. There are a couple approaches we could take, but it really
comes down to what Tony and the other developers feel is cleanest and
I think we actually have similar issues with the C code in sba_iommu
and swiotlb. We have paravirtualized versions of these, but they're
very Xen specific. I think we'll need to abstract the interfaces more
to make the inline paravirtualiztion acceptable.
> Another big challenge is machine vector. I would like to create a
> thread to discuss it some time later. Basically it has something overlap
> with pv_ops.
We might extend the machine vector to include some PV features, but
at the moment, they seem somewhat orthogonal to me. The current xen
machine vector helps to simplify things for a unprivileged guest, but
dom0 will need to use the appropriate bare metal machine vector while
still making use of pv_ops. So we somehow need to incorporate pv_ops
into all the machine vectors. Thanks,
Alex Williamson HP Open Source & Linux Org.
Xen-ia64-devel mailing list