| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] the xenLinux/IA64 upstream merge and Fedora.
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
|
|
|
| |
|
Home