[RFC] enable xen-ia64 in fedora kernel cvs

[Aron Griffis]

This patch enables xen-ia64 support in the fedora kernel.  It applies
to the cvs tree checked out according to the instructions at
http://people.redhat.com/davej/

This is *nearly* ready to be applied.  AFAIK, the only nagging issue
is that it doesn't boot because of the hypervisor/kernel mismatch.
(Full description of the problem at 
https://www.redhat.com/archives/fedora-ia64-list/2006-June/msg00026.html)

To fix this for the moment, I think all that needs to happen is for
Juan to generate a new linux-2.6-xen.patch from the linux-2.6.tip-xen
repository, and then take a new snapshot of the hypervisor from
xen-unstable.  That should bring the two into near enough proximity
for ia64 to boot again.

Juan, could you do this ASAP?  It would be a great help since I could
follow up with a version of this patch suitable for integration.

Regarding long-term solution, I think it would be best for Juan to
take maintainership of the linux-2.6.tip-xen repository.  That would
allow him to sync it to xen-unstable at the same time that he takes
the hypervisor snapshot.  The result should always be a matched pair.

I'd be interested to hear comments regarding this suggestion and this
patch.

 b/devel/configs/config-xen-ia64        |   19 +++++++++
 b/devel/linux-2.6-xen-ia64-fixes.patch |   63 +++++++++++++++++++++++++++++++++
 b/devel/xen-ia64-fixes.patch           |   13 ++++++
 devel/Makefile.config                  |   18 +++++++--
 devel/kernel-2.6.spec                  |   57 ++++++++++++++++++++---------
 5 files changed, 149 insertions(+), 21 deletions(-)

diff -r 73280cc9332c -r ab31e6d960bb devel/Makefile.config
--- a/devel/Makefile.config	Tue Jun 27 15:01:33 2006 -0400
+++ b/devel/Makefile.config	Tue Jun 27 15:50:47 2006 -0400
@@ -13,7 +13,8 @@ CONFIGFILES	= \
 	$(CFG)-ppc.config $(CFG)-ppc-smp.config \
 	$(CFG)-ppc64.config $(CFG)-ppc64-kdump.config $(CFG)-ia64.config \
 	$(CFG)-i686-xen-PAE.config \
-	$(CFG)-i686-xen.config $(CFG)-x86_64-xen.config
+	$(CFG)-i686-xen.config $(CFG)-x86_64-xen.config \
+	$(CFG)-ia64-xen.config
 
 PLATFORMS	= x86 x86_64 powerpc powerpc32 powerpc64 s390 ia64 # sparc sparc64
 TEMPFILES	= $(addprefix temp-, $(addsuffix -generic, $(PLATFORMS)))
@@ -21,8 +22,10 @@ configs: $(CONFIGFILES)
 configs: $(CONFIGFILES)
 	@rm -f kernel-*-config
 	@rm -f $(TEMPFILES)
-	@rm -f temp-xen-generic temp-x86-xen-generic temp-x86_64-xen-generic \
-		temp-generic temp-x86_64-xen-generic-tmp
+	@rm -f temp-generic temp-xen-generic \
+		temp-x86-xen-generic \
+		temp-x86_64-xen-generic temp-x86_64-xen-generic-tmp \
+		temp-ia64-xen-generic temp-ia64-xen-generic-tmp
 
 # Augment the clean target to clean up our own cruft
 clean ::
@@ -69,6 +72,12 @@ temp-x86_64-xen-generic-tmp: configs/con
 	perl scripts/merge.pl $^ > $@
 
 temp-x86_64-xen-generic: configs/config-xen-x86_64 temp-x86_64-xen-generic-tmp
+	perl scripts/merge.pl $^ > $@
+
+temp-ia64-xen-generic-tmp: configs/config-xen-generic temp-ia64-generic
+	perl scripts/merge.pl $^ > $@
+
+temp-ia64-xen-generic: configs/config-xen-ia64 temp-ia64-xen-generic-tmp
 	perl scripts/merge.pl $^ > $@
 
 kernel-$(VERSION)-i686.config: configs/config-i686 temp-x86-generic
@@ -134,3 +143,6 @@ kernel-$(VERSION)-x86_64-xen.config: con
 kernel-$(VERSION)-x86_64-xen.config: configs/config-xen-xen temp-x86_64-xen-generic
 	perl scripts/merge.pl $^ x86_64 > $@
 
+kernel-$(VERSION)-ia64-xen.config: configs/config-xen-xen temp-ia64-xen-generic
+	perl scripts/merge.pl $^ ia64 > $@
+
diff -r 73280cc9332c -r ab31e6d960bb devel/kernel-2.6.spec
--- a/devel/kernel-2.6.spec	Tue Jun 27 15:01:33 2006 -0400
+++ b/devel/kernel-2.6.spec	Tue Jun 27 15:50:47 2006 -0400
@@ -37,6 +37,9 @@ Summary: The Linux kernel (the core of t
 %define xen_version 20060610
 %define make_target bzImage
 %define kernel_image x86
+%define xen_flags verbose=y debug=y crash_debug=y
+%define xen_target vmlinuz
+%define xen_image vmlinuz
 
 %define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
 
@@ -55,10 +58,14 @@ Summary: The Linux kernel (the core of t
 %define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-*.config
 %endif
 
-# Xen and kdump only build on i686 and x86_64 ...
+# kdump only builds on i686 and x86_64
 %ifnarch i686 x86_64
+%define buildkdump 0
+%endif
+
+# Xen only builds on i686, x86_64 and ia64 ...
+%ifnarch i686 x86_64 ia64
 %define buildxen 0
-%define buildkdump 0
 %endif
 
 %ifarch ppc64
@@ -140,11 +147,15 @@ Summary: The Linux kernel (the core of t
 %endif
 
 %ifarch ia64
-%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-ia64.config
+%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-ia64*.config
 %define image_install_path boot/efi/EFI/redhat
 %define signmodules 1
 %define make_target compressed
 %define kernel_image vmlinux.gz
+# ia64 doesn't building with debug=y at the moment
+%define xen_flags verbose=y crash_debug=y
+%define xen_target compressed
+%define xen_image vmlinux.gz
 %endif
 
 #
@@ -246,6 +257,8 @@ Source36: kernel-%{kversion}-i686-xen-PA
 #Source67: kernel-%{kversion}-sparc64.config
 #Source68: kernel-%{kversion}-sparc64-smp.config
 
+Source133: kernel-%{kversion}-ia64-xen.config
+
 #
 # Patches 0 through 100 are meant for core subsystem upgrades
 #
@@ -288,6 +301,7 @@ Patch703: linux-2.6-xen-move-vdso-fixmap
 Patch703: linux-2.6-xen-move-vdso-fixmap.patch
 Patch704: linux-2.6-xen-vsyscall_base.patch
 Patch706: linux-2.6-xen_remap_vma_flags.patch
+Patch707: linux-2.6-xen-ia64-fixes.patch
 
 #
 # Patches 800 through 899 are reserved for bugfixes to the core system
@@ -439,6 +453,7 @@ Patch10001: linux-2.6-random-patches.pat
 
 # Xen hypervisor patches
 Patch20000: xen-sched-sedf.patch
+Patch20001: xen-ia64-fixes.patch
 
 
 # END OF PATCH DEFINITIONS
@@ -717,6 +732,7 @@ cp -rl xen-%{xen_version} xen
 
 # Any necessary hypervisor patches go here
 %patch20000 -p0
+%patch20001 -p0
 %endif
 
 cd linux-%{kversion}.%{_target_cpu}
@@ -784,11 +800,10 @@ cd linux-%{kversion}.%{_target_cpu}
 #
 %patch700 -p1 -b .p.xen
 #
-# ... and back out all the ia64-specific sections, as they currently prevent
+# ... and back out all the tpm-specific sections, as they currently prevent
 # non-xen builds from working.
-# Now also with tpm
-#
-for f in `find drivers/char/tpm arch/ia64/ include/asm-ia64/
include/xen/interface/arch-ia64.h* -type f -name "*.p.xen"` ; do \
+#
+for f in `find drivers/char/tpm -type f -name "*.p.xen"` ; do \
     g=`dirname $f`/`basename $f .p.xen`; \
     mv "$f" "$g"; \
     if [ ! -s "$g" ] ; then rm -f "$g" ; fi; \
@@ -796,6 +811,11 @@ done
 # Delete the rest of the backup files, they just confuse the build later
 find -name "*.p.xen" | xargs rm -f
 
+# These are fixed in xen-ia64-unstable, can go away when that
+# propagates to Juan's patch
+ln -sf ../../../../xen/include/asm-ia64/asm-xsi-offsets.h include/asm-ia64/xen/
+ln -sf ../../../arch/ia64/xen/drivers/xenia64_init.c drivers/xen/core/
+
 #
 # Xen includes a patch which moves the vsyscall fixmap into a user-space VA,
 # freeing user-space from reliance on an absolute fixmap area and so allowing
@@ -811,6 +831,7 @@ find -name "*.p.xen" | xargs rm -f
 %patch702 -p1
 %patch704 -p1
 %patch706 -p1
+%patch707 -p1
 
 %endif
 
@@ -1266,15 +1287,15 @@ mkdir -p $RPM_BUILD_ROOT/boot
 %if %{includexen}
 %if %{buildxen}
   cd xen
-  mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
+  mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot
 %if %{buildxenPAE}
-  make debug=y verbose=y crash_debug=y pae=y
-  install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}-PAE
+  make %{?_smp_mflags} %{xen_flags} pae=y
+  install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}-PAE
   install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}-PAE
   make clean
 %endif
-  make debug=y verbose=y crash_debug=y
-  install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}
+  make %{?_smp_mflags} %{xen_flags}
+  install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}
   install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}
   cd ..
 %endif
@@ -1296,11 +1317,11 @@ BuildKernel %make_target %kernel_image s
 
 %if %{includexen}
 %if %{buildxenPAE}
-BuildKernel vmlinuz vmlinuz xen-PAE
+BuildKernel %xen_target %xen_image xen-PAE
 %endif
 
 %if %{buildxen}
-BuildKernel vmlinuz vmlinuz xen
+BuildKernel %xen_target %xen_image xen
 %endif
 %endif
 
@@ -1405,7 +1426,7 @@ fi
 %post xen
 [ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen
 if [ -e /proc/xen/xsd_kva -o ! -d /proc/xen ]; then 
-	/sbin/new-kernel-pkg --package kernel-xen --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL} %{KVERREL}xen
+	/sbin/new-kernel-pkg --package kernel-xen --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL} %{KVERREL}xen
 else 
 	/sbin/new-kernel-pkg --package kernel-xen --mkinitrd --depmod --install %{KVERREL}xen
 fi
@@ -1422,7 +1443,7 @@ fi
 %post xen-PAE
 [ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen-PAE
 if [ -e /proc/xen/xsd_kva ]; then 
-	/sbin/new-kernel-pkg --package kernel-xen-PAE --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL}-PAE %{KVERREL}xen-PAE
+	/sbin/new-kernel-pkg --package kernel-xen-PAE --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}-PAE %{KVERREL}xen-PAE
 else 
 	/sbin/new-kernel-pkg --package kernel-xen-PAE --mkinitrd --depmod --install
%{KVERREL}xen-PAE
 fi
@@ -1551,7 +1572,7 @@ fi
 /boot/symvers-%{KVERREL}xen.gz
 /boot/symsets-%{KVERREL}xen.tar.gz
 /boot/config-%{KVERREL}xen
-/boot/xen.gz-%{KVERREL}
+/%{image_install_path}/xen.gz-%{KVERREL}
 /boot/xen-syms-%{KVERREL}
 %dir /lib/modules/%{KVERREL}xen
 /lib/modules/%{KVERREL}xen/kernel
@@ -1576,7 +1597,7 @@ fi
 /boot/symvers-%{KVERREL}xen-PAE.gz
 /boot/symsets-%{KVERREL}xen-PAE.tar.gz
 /boot/config-%{KVERREL}xen-PAE
-/boot/xen.gz-%{KVERREL}-PAE
+/%{image_install_path}/xen.gz-%{KVERREL}-PAE
 /boot/xen-syms-%{KVERREL}-PAE
 %dir /lib/modules/%{KVERREL}xen-PAE
 /lib/modules/%{KVERREL}xen-PAE/kernel
diff -r 73280cc9332c -r ab31e6d960bb devel/configs/config-xen-ia64
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/devel/configs/config-xen-ia64	Tue Jun 27 15:50:47 2006 -0400
@@ -0,0 +1,19 @@
+# override i686 xen
+
+# CONFIG_X86 is not set
+# CONFIG_X86_XEN is not set
+CONFIG_IA64=y
+CONFIG_XEN=y
+CONFIG_XEN_IA64_DOM0_VP=y
+CONFIG_XEN_DISABLE_SERIAL=y
+
+# override ia64 generic
+
+# CONFIG_IA64_GENERIC is not set
+CONFIG_IA64_DIG=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+CONFIG_FLATMEM_MANUAL=y
+CONFIG_FORCE_MAX_ZONEORDER=11
+
+# internal #defines conflict with xen-ia64
+# CONFIG_FB_NEOMAGIC is not set
diff -r 73280cc9332c -r ab31e6d960bb devel/linux-2.6-xen-ia64-fixes.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/devel/linux-2.6-xen-ia64-fixes.patch	Tue Jun 27 15:50:47 2006 -0400
@@ -0,0 +1,63 @@
+--- linux-2.6.17.ia64.orig/arch/ia64/xen/xenentry.S	2006-06-21 16:56:36.000000000 -0400
++++ linux-2.6.17.ia64/arch/ia64/xen/xenentry.S	2006-06-21 20:59:47.000000000 -0400
+@@ -819,9 +819,6 @@ skip_rbs_switch:
+ 	st8 [r2]=r8
+ 	st8 [r3]=r10
+ .work_pending:
+-	tbit.nz p6,p0=r31,TIF_SIGDELAYED		// signal delayed from  MCA/INIT/NMI/PMI context?
+-(p6)	br.cond.sptk.few .sigdelayed
+-	;;
+ 	tbit.z p6,p0=r31,TIF_NEED_RESCHED		// current_thread_info()->need_resched==0?
+ (p6)	br.cond.sptk.few .notify
+ #ifdef CONFIG_PREEMPT
+@@ -857,17 +854,6 @@ skip_rbs_switch:
+ (pLvSys)br.cond.sptk.few  .work_pending_syscall_end
+ 	br.cond.sptk.many .work_processed_kernel	// don't re-check
+ 
+-// There is a delayed signal that was detected in MCA/INIT/NMI/PMI context where
+-// it could not be delivered.  Deliver it now.  The signal might be for us and
+-// may set TIF_SIGPENDING, so redrive ia64_leave_* after processing the delayed
+-// signal.
+-
+-.sigdelayed:
+-	br.call.sptk.many rp=do_sigdelayed
+-	cmp.eq p6,p0=r0,r0				// p6 <- 1, always re-check
+-(pLvSys)br.cond.sptk.few  .work_pending_syscall_end
+-	br.cond.sptk.many .work_processed_kernel	// re-check
+-
+ .work_pending_syscall_end:
+ 	adds r2=PT(R8)+16,r12
+ 	adds r3=PT(R10)+16,r12
+--- linux-2.6.17.ia64.orig/include/asm-ia64/io.h	2006-06-21 16:56:36.000000000 -0400
++++ linux-2.6.17.ia64/include/asm-ia64/io.h	2006-06-21 18:11:00.000000000 -0400
+@@ -450,28 +450,14 @@ __writeq (unsigned long val, volatile vo
+ # define outl_p		outl
+ #endif
+ 
+-/*
+- * An "address" in IO memory space is not clearly either an integer or a
pointer. We will
+- * accept both, thus the casts.
+- *
+- * On ia-64, we access the physical I/O memory space through the uncached kernel
region.
+- */
+-static inline void __iomem *
+-ioremap (unsigned long offset, unsigned long size)
+-{
+-#ifdef CONFIG_XEN
+-	offset = HYPERVISOR_ioremap(offset, size);
+-#endif
+-	return (void __iomem *) (__IA64_UNCACHED_OFFSET | (offset));
+-}
++extern void __iomem * ioremap(unsigned long offset, unsigned long size);
++extern void __iomem * ioremap_nocache (unsigned long offset, unsigned long size);
+ 
+ static inline void
+ iounmap (volatile void __iomem *addr)
+ {
+ }
+ 
+-#define ioremap_nocache(o,s)	ioremap(o,s)
+-
+ /* Use normal IO mappings for DMI */
+ #define dmi_ioremap ioremap
+ #define dmi_iounmap(x,l) iounmap(x)
diff -r 73280cc9332c -r ab31e6d960bb devel/xen-ia64-fixes.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/devel/xen-ia64-fixes.patch	Tue Jun 27 15:50:47 2006 -0400
@@ -0,0 +1,13 @@
+--- xen.orig/include/asm-ia64/xenpage.h	2006-05-03 15:05:40.000000000 -0400
++++ xen/include/asm-ia64/xenpage.h	2006-06-22 12:15:40.000000000 -0400
+@@ -28,6 +28,10 @@
+ #define page_to_virt(_page)	maddr_to_virt(page_to_maddr(_page))
+ #define maddr_to_page(kaddr)	mfn_to_page(((kaddr) >> PAGE_SHIFT))
+ 
++/* Convert between Xen-heap virtual addresses and machine frame numbers. */
++#define virt_to_mfn(va)		(virt_to_maddr(va) >> PAGE_SHIFT)
++#define mfn_to_virt(mfn)	maddr_to_virt(mfn << PAGE_SHIFT)
++
+ #ifndef __ASSEMBLY__
+ typedef union xen_va {
+ 	struct {

[Dave Jones]

On Tue, Jun 27, 2006 at 04:40:03PM -0400, Aron Griffis wrote:
>  This patch enables xen-ia64 support in the fedora kernel.  It
> applies
>  to the cvs tree checked out according to the instructions at
>  http://people.redhat.com/davej/
>  
>  This is *nearly* ready to be applied.  AFAIK, the only nagging issue
>  is that it doesn't boot because of the hypervisor/kernel mismatch.
>  (Full description of the problem at 
>  https://www.redhat.com/archives/fedora-ia64-list/2006-June/msg00026.html)
>  
>  To fix this for the moment, I think all that needs to happen is for
>  Juan to generate a new linux-2.6-xen.patch from the linux-2.6.tip-xen
>  repository, and then take a new snapshot of the hypervisor from
>  xen-unstable.  That should bring the two into near enough proximity
>  for ia64 to boot again. 
Yeah, the daily -git rejects got the better of me yesterday, so I disabled
xen builds whilst that gets worked out.

There's another larger problem right now - the signed modules code is broken
for some reason, resulting in kernels that don't boot.  Fixing that is
my priority right now.

		Dave

-- 
http://www.codemonkey.org.uk

* Aron Griffis (aron(a)hp.com) wrote:
>  --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>  +++ b/devel/linux-2.6-xen-ia64-fixes.patch	Tue Jun 27 15:50:47 2006 -0400
>  @@ -0,0 +1,63 @@
>  +--- linux-2.6.17.ia64.orig/arch/ia64/xen/xenentry.S	2006-06-21 16:56:36.000000000 -0400
>  ++++ linux-2.6.17.ia64/arch/ia64/xen/xenentry.S	2006-06-21 20:59:47.000000000 -0400
>  +@@ -819,9 +819,6 @@ skip_rbs_switch:
>  + 	st8 [r2]=r8
>  + 	st8 [r3]=r10
>  + .work_pending:
>  +-	tbit.nz p6,p0=r31,TIF_SIGDELAYED		// signal delayed from  MCA/INIT/NMI/PMI context?
>  +-(p6)	br.cond.sptk.few .sigdelayed
>  +-	;;
>  + 	tbit.z p6,p0=r31,TIF_NEED_RESCHED		// current_thread_info()->need_resched==0?
>  + (p6)	br.cond.sptk.few .notify
>  + #ifdef CONFIG_PREEMPT
>  +@@ -857,17 +854,6 @@ skip_rbs_switch:
>  + (pLvSys)br.cond.sptk.few  .work_pending_syscall_end
>  + 	br.cond.sptk.many .work_processed_kernel	// don't re-check
>  + 
>  +-// There is a delayed signal that was detected in MCA/INIT/NMI/PMI context where
>  +-// it could not be delivered.  Deliver it now.  The signal might be for us and
>  +-// may set TIF_SIGPENDING, so redrive ia64_leave_* after processing the delayed
>  +-// signal.
>  +-
>  +-.sigdelayed:
>  +-	br.call.sptk.many rp=do_sigdelayed
>  +-	cmp.eq p6,p0=r0,r0				// p6 <- 1, always re-check
>  +-(pLvSys)br.cond.sptk.few  .work_pending_syscall_end
>  +-	br.cond.sptk.many .work_processed_kernel	// re-check
>  +-
>  + .work_pending_syscall_end:
>  + 	adds r2=PT(R8)+16,r12
>  + 	adds r3=PT(R10)+16,r12 
This should already be in tip-xen on xenbits (thanks to your patch).

>  +--- linux-2.6.17.ia64.orig/include/asm-ia64/io.h	2006-06-21
> 16:56:36.000000000 -0400
>  ++++ linux-2.6.17.ia64/include/asm-ia64/io.h	2006-06-21 18:11:00.000000000 -0400
>  +@@ -450,28 +450,14 @@ __writeq (unsigned long val, volatile vo
>  + # define outl_p		outl
>  + #endif
>  + 
>  +-/*
>  +- * An "address" in IO memory space is not clearly either an integer or a
> pointer. We will
>  +- * accept both, thus the casts.
>  +- *
>  +- * On ia-64, we access the physical I/O memory space through the uncached kernel
> region.
>  +- */
>  +-static inline void __iomem *
>  +-ioremap (unsigned long offset, unsigned long size)
>  +-{
>  +-#ifdef CONFIG_XEN
>  +-	offset = HYPERVISOR_ioremap(offset, size);
>  +-#endif
>  +-	return (void __iomem *) (__IA64_UNCACHED_OFFSET | (offset));
>  +-}
>  ++extern void __iomem * ioremap(unsigned long offset, unsigned long size);
>  ++extern void __iomem * ioremap_nocache (unsigned long offset, unsigned long size);
>  + 
>  + static inline void
>  + iounmap (volatile void __iomem *addr)
>  + {
>  + }
>  + 
>  +-#define ioremap_nocache(o,s)	ioremap(o,s)
>  +-
>  + /* Use normal IO mappings for DMI */
>  + #define dmi_ioremap ioremap
>  + #define dmi_iounmap(x,l) iounmap(x) 
This should already be this way in tip-xen on xenbits, that's how I
did the merge.

>  diff -r 73280cc9332c -r ab31e6d960bb devel/xen-ia64-fixes.patch
>  --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>  +++ b/devel/xen-ia64-fixes.patch	Tue Jun 27 15:50:47 2006 -0400
>  @@ -0,0 +1,13 @@
>  +--- xen.orig/include/asm-ia64/xenpage.h	2006-05-03 15:05:40.000000000 -0400
>  ++++ xen/include/asm-ia64/xenpage.h	2006-06-22 12:15:40.000000000 -0400
>  +@@ -28,6 +28,10 @@
>  + #define page_to_virt(_page)	maddr_to_virt(page_to_maddr(_page))
>  + #define maddr_to_page(kaddr)	mfn_to_page(((kaddr) >> PAGE_SHIFT))
>  + 
>  ++/* Convert between Xen-heap virtual addresses and machine frame numbers. */
>  ++#define virt_to_mfn(va)		(virt_to_maddr(va) >> PAGE_SHIFT)
>  ++#define mfn_to_virt(mfn)	maddr_to_virt(mfn << PAGE_SHIFT)
>  ++
>  + #ifndef __ASSEMBLY__
>  + typedef union xen_va {
>  + 	struct { 
Hmm, this one is missing, and it's not in xen-unstable sparse tree
either, so I can see why it's not picked up.

thanks,
-chris

[Aron Griffis]

Chris Wright wrote:  [Tue Jun 27 2006, 05:34:10PM EDT]
>  This should already be in tip-xen on xenbits (thanks to your patch).
>  
>  This should already be this way in tip-xen on xenbits, that's how I
>  did the merge. 
Right, these patches are not the issue.  The issue is that Juan's
patch is derived from one tree while the hypervisor snapshot is taken
from another.  The result is a hypervisor/kernel pair that have
a proximity window of 2 weeks or so, but should be matched if possible
to guarantee compatibility.

Generally it shouldn't be an issue, but there was a compatibility
break in ia64 recently, and the current fedora hypervisor snapshot is
on one side of the line, while the xenlinux patch is on the other.

IMHO the easiest way to avoid potential incompatibility on any
architecture is to make sure they both source from the same
xen-unstable changeset.  That calls for either 
    - Juan to handle the linux-2.6.tip-xen tree, or
    - closer synchronization between you and Juan, or
    - Juan to be able to snapshot the hypervisor using the same
      xen-unstable changeset used in linux-2.6.tip-xen at any time.

Maybe the last one would be easiest?  Is it possible to
programmatically determine from the perspective of linux-2.6.tip-xen
the related xen-unstable changeset?

>  Hmm, this one is missing, and it's not in xen-unstable sparse
> tree
>  either, so I can see why it's not picked up. 
I think it's in xen-ia64-unstable.  

This is a different issue, and not one for which I have any
suggestions.  The latency between xen-ia64-unstable and fedora is
unavoidably long, due to the chain: xen-ia64-unstable -> xen-unstable
-> linux-2.6.tip-xen -> Juan -> kernel.rpm.  It's easy for upstream
patches to be held up on that route.  For that reason, I think it's
likely an ia64 fixup patch will often be needed in kernel.rpm,
especially while xen-ia64 is seeing so much work.

Thakns,
Aron

* Aron Griffis (aron(a)hp.com) wrote:
>  Chris Wright wrote:  [Tue Jun 27 2006, 05:34:10PM EDT]
>  > This should already be in tip-xen on xenbits (thanks to your patch).
>  > 
>  > This should already be this way in tip-xen on xenbits, that's how I
>  > did the merge.
>  
>  Right, these patches are not the issue.  The issue is that Juan's
>  patch is derived from one tree while the hypervisor snapshot is taken
>  from another.  The result is a hypervisor/kernel pair that have
>  a proximity window of 2 weeks or so, but should be matched if possible
>  to guarantee compatibility.
>  
>  Generally it shouldn't be an issue, but there was a compatibility
>  break in ia64 recently, and the current fedora hypervisor snapshot is
>  on one side of the line, while the xenlinux patch is on the other. 
This is difficult to track unless we get some actual heads up for
interface breakage.  For x86 32/86, these things get caught since it's
where the bulk of the testing is done.

>  IMHO the easiest way to avoid potential incompatibility on any
>  architecture is to make sure they both source from the same
>  xen-unstable changeset.  That calls for either 
>      - Juan to handle the linux-2.6.tip-xen tree, or
>      - closer synchronization between you and Juan, or
>      - Juan to be able to snapshot the hypervisor using the same
>        xen-unstable changeset used in linux-2.6.tip-xen at any time.
>  
>  Maybe the last one would be easiest?  Is it possible to
>  programmatically determine from the perspective of linux-2.6.tip-xen
>  the related xen-unstable changeset? 
The flow looks like this:

xen-unstable (sparse tree cherry picks) -> linux-2.6-xen -> linux-2.6.tip-xen

That first step records the xen-unstable cset number as part of the commit
message.  So when it hits linux-2.6.tip-xen that info is preserved, and
can be culled programtically.  Syncing the hv to that cset is not enough
to guarantee compatibility, but should be pretty darn likely to work ;)

The fedora side has additional changes which shouldn't be mixed with a
pristine linux-2.6.tip-xen.

thanks,
-chris