[Xen-ia64-devel] RE: Code merge between VTI code and non VTI code - Magenheimer, Dan (HP Labs Fort Collins) - com.xensource.lists.xen-ia64-devel

6 messages in com.xensource.lists.xen-ia64-devel[Xen-ia64-devel] RE: Code merge betwe...

From	Sent On	Attachments
Magenheimer, Dan (HP Labs Fort Collins)	11 May 2005 13:01
Dong, Eddie	18 May 2005 00:29
Magenheimer, Dan (HP Labs Fort Collins)	18 May 2005 09:38
Yang, Fred	18 May 2005 11:01
Magenheimer, Dan (HP Labs Fort Collins)	18 May 2005 13:32
Dong, Eddie	18 May 2005 18:58

Subject:	[Xen-ia64-devel] RE: Code merge between VTI code and non VTI code
From:	Magenheimer, Dan (HP Labs Fort Collins) (dan....@hp.com)
Date:	05/18/2005 09:38:00 AM
List:	com.xensource.lists.xen-ia64-devel

(Apologies to the list if this content is a repeat. I think the original was off-list but I can't find it to confirm.)

I am very much in favor of Xen/ia64 fully supporting VTI. I am also very much in favor of Xen/ia64 supporting both non-VTI (paravirtualized) domains and VTI domains simultaneously on a VTI system.

However, I am concerned that we have some different objectives and don't fully understand each others' objectives, so merging too much code too quickly may require us to separate code later. In particular, I see paravirtualization disadvantages from merging the vcpu data structure, and differences in the need for large per-domain persistent memory allocations.

I'm also concerned that it is difficult to continue forward progress on areas of common functionality once a merge happens, as VTI is not publicly/widely available yet (even I don't have one) and you don't have an rx26X0 box which is what most of the other Xen/ia64 developer's are using.

Given that VTI systems are still "in the future" (even if I knew exactly when, I'm sure I couldn't say), I am hesitant to slow progress on the paravirtualized front.

Comments?

-----Original Message----- From: Dong, Eddie [mailto:eddi...@intel.com] Sent: Wednesday, May 18, 2005 1:30 AM To: Magenheimer, Dan (HP Labs Fort Collins) Cc: xen-...@lists.xensource.com Subject: RE: Code merge between VTI code and non VTI code

Dan: Base on previous discussion, we got some agreement. Let us have well discssion on the left issues. Adding per domain flag indicating for VTI domain has no problem, it is actually already there now. (exec_domain.arch.arch_vmx.flags). For the compile option, yes we will eliminate it eventually, but we are looking for whole solutions to reduce the rebase effort for all of us. What in my mind for next steps to merge code together before domain N comes out is: step1: Merge vcpu context definition. (I.e exec_domain->arch_exec_domain->arch_vmx_struct vs. domain->shared_info_t->vcpu_info_t->arch_vcpu_info_t). Within this merge, some bug fix for current code we found (like Tiger MCA issue) and some common feature enhancement (like lsapic delivery mechanism enhancement) can be done. Defintely vcpu.c will be merged into one.

step2: Merge pt_regs. After this merge, ivt.S and some VTI specified intialization code will be merged.

step3: Domain N support merge. We are near end of domain N support coding and defintely we want to share them to public so that others can do more. This patch will include the hypercall shared page support, FM support, Control Panel and Device Model. Without step1, this one will get more difference and the rebase effort in future may increase exponentially . step4: VTLB/VHPT merge. Base on the discussion, we can merge vTLB together or keep 2 solutions dynamically. Same for VHPT. -- TBD

Any suggestions? For the details of merging vcpu context, please refer to another thread. thanks,eddie