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