|
|
|
|
|
|
|
|
|
|
xen-ia64-devel
[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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-ia64-devel] RE: Code merge between VTI code and non VTI code,
Dong, Eddie <=
|
|
|
|
|