[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-ia64-devel] 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 _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |