Re: [Xen-ia64-devel] [PATCH] [RFC] [TAKE2] P2M/VP (incomplete) patches

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

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