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

[Aron Griffis <aron@xxxxxx>]

Hello Yamahata-san,

Isaku Yamahata wrote:  [Mon Dec 03 2007, 08:58:40PM EST]
> Hi Xen/IA64 developers.
> Recently Red hat publicly announced that they decided to work
> on the dom0 upstream merge for the long term xen support on Fedora.
>   https://www.redhat.com/archives/fedora-xen/2007-November/msg00106.html
>   http://fedoraproject.org/wiki/Features/XenPvops
> And actually they seem to begin their activity on the mailing lists.
> So we want to push our Linux modification to the upstream too.
> Otherwise xenLinux/IA64 will become rotten rapidly after their merge.

I'm glad you're looking into this.  I am interested in helping, but
I don't have your level of technical expertise.  I would be willing to
test, help with commit messages and posting to linux-ia64, and help
coding wherever possible.

> 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 question is probably best answered by Stephen.  I think what we
want is an x86 forward-ported tree so we can see how the generic bits
change.  Then it's just a matter of making arch/ia64 changes to
accomodate, right?

As an experiment, I started a merge of arch/ia64 to v2.6.23.  The
conflicts are not extensive and are not hard to untangle.  The full
list of conflicting files is:

arch/ia64/Kconfig
arch/ia64/kernel/asm-offsets.c
arch/ia64/kernel/crash.c
arch/ia64/kernel/crash_dump.c
arch/ia64/kernel/efi.c
arch/ia64/kernel/iosapic.c
arch/ia64/kernel/irq_ia64.c
arch/ia64/kernel/machine_kexec.c
arch/ia64/kernel/mca.c
arch/ia64/kernel/pal.S
arch/ia64/kernel/relocate_kernel.S
arch/ia64/kernel/setup.c
arch/ia64/kernel/smp.c
arch/ia64/kernel/time.c
arch/ia64/kernel/topology.c
arch/ia64/mm/contig.c
arch/ia64/mm/ioremap.c
arch/ia64/pci/pci.c

In particular the kexec patches cause conflicts because the
implementation in linux-2.6.18-xen.hg is backported.  But it isn't
hard to sort it out.

I haven't attempted to build the port, though, because of the non-ia64
conflicts.

> Some thoughts.
> - domU first and then dom0.
>   the domu/IA64 part would be easy because MMU is fully virtualized
>   on IA64.
> - Coding Style
>   The current code's style should be clean up.
> - Although xenLinux/x86 uses pv_ops, probably the machine vector
>   should be considered at first. Then consider on the ia64 pv_ops.

I agree about this, although if we can use the generic pv_ops with the
same optimizations, it might reduce duplicated code.

> - The kernel initialization might need to be revised.
>   Especially the hypervisor detection and the initialization order.
> - 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.

Xiantao: Is kvm/ia64 using any form of pv_ops?

So if xenlinux/ia64 is merged into kernel.org, would we then
concentrate all our kernel efforts on that tree and eventually abandon
linux-2.6.18-xen.hg?  I know this is a rhetorical question, but
it seems like it would be better to concentrate on the current tree in
the future, rather than needing to forward port changes continuously.

Thanks,
Aron

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