(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:eddie.dong@xxxxxxxxx]
> Sent: Wednesday, May 18, 2005 1:30 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> 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
>
>
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home