Dan,
We are in same page with you in having a single binary to support both
para-virtualization and VTI simultaneously. Xen can runtime back to
pure para-virtualization mode if run on a non-VTI platform; or users can
run both VTI and para-virtualization Domains on a VTI platform.
We strongly believe with good structure support, both models can work
and shine together like ia32/Xen. We shouldn't limit ia64/Xen to only
run on a specific platform, rather, you want ia64/Xen to run on as many
different platforms as possible to extend its capability. This is the
beauty of public community - everyone contributes on what he/she can
contribute.
Without major data structure or interfaces merged ASAP, the detail
implementation will be diverged further away and make it harder & harder
to get to the goal. Are you proposing put 2-headed source into
Xen-ia64-unstable BK? That definitely helps us on rebase effort and
ease the effort in further structural merging.
-Fred
Magenheimer, Dan (HP Labs Fort Collins) wrote:
> (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
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home