[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 14 Mar 2006 12:53:04 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 14 Mar 2006 04:53:56 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcZHIS1IdV5NEjlMRTeI9QS4PicrHgAAJ2aQ
  • Thread-topic: [Xen-ia64-devel] [PATCH] [RFC] [TAKE2] P2M/VP (incomplete) patches

>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年3月14日 12:37
>> [SUBARCH]
>[...]
>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?

Yes, option 1 is preferable or else it will be the headache for you to 
maintain the big patch. :-) The subarch of XEN/IA64 is mainly for 
shooting p2m feature, since we have no writable page table. Your 
patch set already gives a clear split about major files we need to 
pull from linux side. Somebody can simply take those files as a base 
and then major challenge is just to ensure compilation.

>
>
>> [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.

No problem. It's the natural way.

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

OK and up to you to decide.

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

OK and let's do it step by step. :-)

Thanks,
Kevin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.