Hi Kevin, thanks for your comments.
On Tue, Mar 14, 2006 at 12:02:04AM +0800, Tian, Kevin wrote:
> [SUBARCH]
> Since you start to import more linux files with modifications, maybe
> it's time now to consider make xenlinux/ia64 as a REAL subarch like
> x86/x86-64. (agp.h, dma-mapping.h, io.h, machvec.h, page.h, etc.) Or we can
> call it a new machvec on ia64, like a "xen" in same dir as "dig", "hp", etc.
> See what you've done for CONFIG_XEN_IA64_DOM0_VP, which finally presents a
> new/virtual type of IA64 box. By doing that, we back to same highway as x86,
> since subarch is current way that xen community is supposing to linux
> community. Also you see how it makes your later work cleaner, though a bit
> extra effort may be required to setup the initial hierarchy.
I agree with you that SUBARCH is preferable.
However there is a choice here.
1. change xen-ia64-unstable.hg to use subarch and
then the P2M/VP patch catches it up.
or
2. The P2M/VP patch includes the subarch patch. Single huge jump.
1. is desirable for the P2M/VP maintenance costs, but the xen/ia64
community consensus and volunteers are required to do so. volunteers?
> [HYPERCALL for new do_dom0vp_op]
> I noted that you added a bunch of new interfaces to do some specific
> dom0 operations for phys2mach relationship. (Not looked into yet) But seems
> some ops are conflicting to common code, like IA64_DOM0VP_populate_physmap
> when there is XENMEM_populate_physmap. Any reason there?
Just for easy implementations to get P2M/VP model to work.
I agree that common codes should used. However it requires
common code clean up defining arch dependent/independent interface.
I'd like to get P2M/VP model to work early than arch dependent/independent
code clean up. It will be addressed at code clean up/merge step.
I have the following priority in my mind.
High
1. get vnif to work
2. get balloon to work
3. grant table interface clean up
4.(?) consider/decide on dommem allocation
5. code clean up, arch depedent/independent code clean up, merge effort
Low
> Another example like XENMEM_translate_gpfn_list. Is it possible to be
> used in your patch?
Yes, I think it's possible.
> Do you have idea how much effort would be added if direct map p2m table
> into dom0? More or less, compared to hypercall approach?
A mechanism similar to grant table can be used.
I guess one month or so at most.
But this change can be done independently with other effort
like vIOSAPIC.
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|