RE: [Xen-ia64-devel] the xenLinux/IA64 upstream merge and Fedora.

["Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>]

Alex Williamson wrote:
> On Tue, 2007-12-04 at 10:58 +0900, Isaku Yamahata wrote:
>> I'd like to share informations and opinions to avoid duplicate
>> works. Please comments. 
>> 
>> Some questions.
>> - Is anyone already working on it?
>> - What code base is best to begin with?
>>   Although the official xenLinux/IA64 tree is
>>   http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
>>   Does Fedora have any forward ported tree?
> 
>    This is definitely one of the tricky parts.  Obviously we'll need
> to submit patches against upstream Linux, but we'll likely need to
> leverage the work of others for forward porting the core of the xen
> enabled components.  The Fedora Xen kernel module may be a reasonable
> target, but there are probably lots of small architecture specific
> parts we can isolate into functional chunks and clean-up for upstream
> in the meantime.
> 
>> Some thoughts.
>> - domU first and then dom0.
>>   the domu/IA64 part would be easy because MMU is fully virtualized
>>   on IA64.
> 
>    Yes, this would also allow us to start out focused on architecture
> specific parts while others solidify what the basis for dom0 looks
> like on upstream.
> 
>> - Coding Style
>>   The current code's style should be clean up.
> 
>    Definitely, although I think we've done a reasonable job matching
> Linux coding style for XenLinux files, I'm sure we'll find examples to
> the contrary.
> 
>> - Although xenLinux/x86 uses pv_ops, probably the machine vector
>>   should be considered at first. Then consider on the ia64 pv_ops.
> 
>    Yes, it's been unclear to me the extent to which ia64 needs pv_ops.
> We already have the xen machine vector and we may be able to expand
> the machine vector to incorporate a few more things where it makes
> sense. Then we need to see what pieces are left and whether it makes
> sense to create an ia64 pv_ops or implement more of the binary
> replacement type things we've discussed previously.
> 
>> - The kernel initialization might need to be revised.
>>   Especially the hypervisor detection and the initialization order.
> 
>    I think all of the xenlinux code should be carefully reviewed and
> re-evaluated as we try to get it upstream.  This is also an
> opportunity to improve the code.
> 
>> - other VMM.
>>   Possibly kvm/ia64 or lguest/ia64 may have their opinion
>>   on paravirtualization. But their code aren't opened yet.
>>   This might make our merge easier or more difficult.
>>   Anyway we'll see.
> 
>    Yes, ia64 is at a bit of a disadvantage here since x86 has several
> implementations of paravirtualization to help tune their pv_ops.  We
> should probably expect some of the interfaces to change over time as
> new PV guests are added, but we should try to solicit feedback from
> Jes and Xiantao as much as we can.

Worked with kvm community guys in last two months, we almost completed
kvm re-frame work. Currently, I  have almost compelted kvm/ia64 rebase
per the new framwork of kvm, although it is still need to refine by
commnunity.  So, after performing internal process, we will send out
our kvm/ia64 patches to community soon. :)
Thanks for your attention!
Xiantao 

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel