Fedora xen - Jul 2006 - Four ways RH could help with xen-ia64

Hi guys,

There are four ways you could be a big help to the xen-ia64 effort.
I have mentioned these in the past but never pulled them together into
a single request.

1. Publish Juan''s tree which is the result of his merge of
   linux-2.6.tip-xen, linux-2.6 and linux-2.6-xen.  How about
   http://people.redhat.com/quintela/linux-2.6.tip-xen-fedora.hg?
   As things stand right now, it''s very difficult for ia64 devs to
   contribute to Juan''s patch, for 2 reasons: (1) we never see it
   until after a new kernel rpm is published, (2) all we get is the
   final result, lacking the extremely helpful changeset history.

2. Use matched xenlinux/hypervisor pairs.  At the OLS Xen mini-summit
   there was some discussion of compatibility.  The statements were:
	- old domU should run on new hypervisor
	- new domU NOT guaranteed to run on old hypervisor
	- dom0 and hypervisor should be MATCHED

   Presently (kernel-2.6.17-1.2432.fc6.src.rpm) it appears that the
   hypervisor and xen patch are both dated 20060719.  That''s a good
   sign! :-)   It would be great if you could provide some indication
   of your intent to continue using matched pairs.  Are they actually
   based on the same xen-unstable changeset?  We, the users, can''t
   tell because the tarball is dated instead of cset-stamped, and
   Juan''s tree isn''t available.  See #1 ;-)

3. Apply my kernel.spec and config changes at the end of this email.
   This would make it much easier for the ia64 developers to do test
   builds and track down failures.  Presently it''s a pain for me to
   maintain this out of tree.

4. Apply the xen.spec and libvirt.spec changes.
	https://www.redhat.com/archives/fedora-xen/2006-July/msg00022.html
	https://www.redhat.com/archives/fedora-xen/2006-July/msg00021.html

   Regarding libvirt.spec, I''ve talked with Daniel and he''s
just
   waiting for xen.spec to be ia64-enabled...

Objections/comments?  I''ll attempt to update any relevant BZs today.

Thanks,
Aron

 b/devel/configs/config-xen-ia64 |   20 ++++++++++++++++
 devel/Makefile.config           |   18 ++++++++++++--
 devel/kernel-2.6.spec           |   50 +++++++++++++++++++++++++++++-----------
 3 files changed, 72 insertions(+), 16 deletions(-)

diff -r 658c33aa557a -r 250cc32cdde6 devel/Makefile.config
--- a/devel/Makefile.config	Sat Jul 22 09:19:48 2006 -0400
+++ b/devel/Makefile.config	Sat Jul 22 09:25:25 2006 -0400
@@ -12,7 +12,8 @@ CONFIGFILES	= \
 	$(CFG)-s390.config $(CFG)-s390x.config \
 	$(CFG)-ppc.config $(CFG)-ppc-smp.config \
 	$(CFG)-ppc64.config $(CFG)-ppc64-kdump.config $(CFG)-ia64.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)))
@@ -20,8 +21,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 ::
@@ -67,6 +70,12 @@ temp-x86_64-xen-generic-tmp: configs/con
 	perl merge.pl $^ > $@
 
 temp-x86_64-xen-generic: configs/config-xen-x86_64 temp-x86_64-xen-generic-tmp
+	perl merge.pl $^ > $@
+
+temp-ia64-xen-generic-tmp: configs/config-xen-generic temp-ia64-generic
+	perl merge.pl $^ > $@
+
+temp-ia64-xen-generic: configs/config-xen-ia64 temp-ia64-xen-generic-tmp
 	perl merge.pl $^ > $@
 
 kernel-$(VERSION)-i686.config: configs/config-i686 temp-x86-generic
@@ -132,3 +141,6 @@ kernel-$(VERSION)-x86_64-xen.config: con
 kernel-$(VERSION)-x86_64-xen.config: configs/config-x86_64
temp-x86_64-xen-generic
 	perl merge.pl $^ x86_64 > $@
 
+kernel-$(VERSION)-ia64-xen.config: configs/config-xen-xen temp-ia64-xen-generic
+	perl merge.pl $^ ia64 > $@
+
diff -r 658c33aa557a -r 250cc32cdde6 devel/kernel-2.6.spec
--- a/devel/kernel-2.6.spec	Sat Jul 22 09:19:48 2006 -0400
+++ b/devel/kernel-2.6.spec	Sat Jul 22 09:25:25 2006 -0400
@@ -36,6 +36,9 @@ Summary: The Linux kernel (the core of t
 %define xen_version 20060719
 %define make_target bzImage
 %define kernel_image x86
+%define xen_flags verbose=y debug=y crash_debug=y pae=y
+%define xen_target vmlinuz
+%define xen_image vmlinuz
 
 %define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
 
@@ -56,10 +59,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
@@ -134,11 +141,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
 
 #
@@ -237,6 +248,7 @@ Source33: kernel-%{kversion}-i686-xen.co
 Source33: kernel-%{kversion}-i686-xen.config
 Source34: kernel-%{kversion}-x86_64-xen.config
 Source35: kernel-%{kversion}-i686-kdump.config
+Source36: kernel-%{kversion}-ia64-xen.config
 
 #Source66: kernel-%{kversion}-sparc.config
 #Source67: kernel-%{kversion}-sparc64.config
@@ -785,17 +797,29 @@ cd linux-%{kversion}.%{_target_cpu}
 #
 %patch950 -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; \
 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, they will announce their retirement
+# automatically when the changes propogate down the chain to Juan
+if [[ ! -f arch/ia64/kernel/asm-offsets.c ]]; then
+    ln -sf ../../../../xen/include/asm-ia64/asm-xsi-offsets.h
include/asm-ia64/xen/
+else
+    printf "*\n* please retire asm-xsi-offsets.h symlink from
kernel-2.6.spec\n*\n"
+fi
+if grep -q xenia64_init drivers/xen/core/Makefile; then
+    ln -sf ../../../arch/ia64/xen/drivers/xenia64_init.c drivers/xen/core/
+else
+    printf "*\n* please retire xenia64_init.c symlink from
kernel-2.6.spec\n*\n"
+fi
 
 %patch951 -p1
 %patch952 -p1
@@ -1235,9 +1259,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
 %if %{includexen}
 %if %{buildxen}
   cd xen
-  mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
-  make debug=y verbose=y crash_debug=y pae=y
-  install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}
+  mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot
+  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 ..
   mkdir -p $RPM_BUILD_ROOT/usr/src/kernels/%{KVERREL}-xen-%{_target_cpu}
@@ -1261,7 +1285,7 @@ BuildKernel %make_target %kernel_image s
 
 %if %{includexen}
 %if %{buildxen}
-BuildKernel vmlinuz vmlinuz xen
+BuildKernel %xen_target %xen_image xen
 %endif
 %endif
 
@@ -1432,7 +1456,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
@@ -1565,7 +1589,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
diff -r 658c33aa557a -r 250cc32cdde6 devel/configs/config-xen-ia64
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/devel/configs/config-xen-ia64	Sat Jul 22 09:25:25 2006 -0400
@@ -0,0 +1,20 @@
+# 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_SPARSEMEM_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

>
>
> 4. Apply the xen.spec and libvirt.spec changes.
> 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00022.html
> 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00021.html
>
>    Regarding libvirt.spec, I''ve talked with Daniel and
he''s just
>    waiting for xen.spec to be ia64-enabled...
>
> Objections/comments?  I''ll attempt to update any relevant BZs
today.
>
>   
Aron,

Fedora has moved forward to 2.6.18.  We''ll have to port forward the 
2.6.17 ia64 changes and then apply the kernel.rpm patch below.

The BZs I''ve opened are:

   199683 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199683> 
Fedora Core 
<https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora%20Core&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=CLOSED>
NEW normal enable xen-ia64 in fedora kernel cvs
   199684 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199684> 
Fedora Core 
<https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora%20Core&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=CLOSED>
NEW normal Forward port 2.6.17 ia64 xen to 2.6.18
   199685 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199685> 
Fedora Core 
<https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora%20Core&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=CLOSED>
NEW normal enable ia64 builds for libvirt
   199686 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199686> 
Fedora Core 
<https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora%20Core&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=CLOSED>
NEW normal enable ia64 builds for the xen rpm

P.
> Thanks,
> Aron
>
>  b/devel/configs/config-xen-ia64 |   20 ++++++++++++++++
>  devel/Makefile.config           |   18 ++++++++++++--
>  devel/kernel-2.6.spec           |   50
+++++++++++++++++++++++++++++-----------
>  3 files changed, 72 insertions(+), 16 deletions(-)
>
> diff -r 658c33aa557a -r 250cc32cdde6 devel/Makefile.config
> --- a/devel/Makefile.config	Sat Jul 22 09:19:48 2006 -0400
> +++ b/devel/Makefile.config	Sat Jul 22 09:25:25 2006 -0400
> @@ -12,7 +12,8 @@ CONFIGFILES	= \
>  	$(CFG)-s390.config $(CFG)-s390x.config \
>  	$(CFG)-ppc.config $(CFG)-ppc-smp.config \
>  	$(CFG)-ppc64.config $(CFG)-ppc64-kdump.config $(CFG)-ia64.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)))
> @@ -20,8 +21,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 ::
> @@ -67,6 +70,12 @@ temp-x86_64-xen-generic-tmp: configs/con
>  	perl merge.pl $^ > $@
>  
>  temp-x86_64-xen-generic: configs/config-xen-x86_64
temp-x86_64-xen-generic-tmp
> +	perl merge.pl $^ > $@
> +
> +temp-ia64-xen-generic-tmp: configs/config-xen-generic temp-ia64-generic
> +	perl merge.pl $^ > $@
> +
> +temp-ia64-xen-generic: configs/config-xen-ia64 temp-ia64-xen-generic-tmp
>  	perl merge.pl $^ > $@
>  
>  kernel-$(VERSION)-i686.config: configs/config-i686 temp-x86-generic
> @@ -132,3 +141,6 @@ kernel-$(VERSION)-x86_64-xen.config: con
>  kernel-$(VERSION)-x86_64-xen.config: configs/config-x86_64
temp-x86_64-xen-generic
>  	perl merge.pl $^ x86_64 > $@
>  
> +kernel-$(VERSION)-ia64-xen.config: configs/config-xen-xen
temp-ia64-xen-generic
> +	perl merge.pl $^ ia64 > $@
> +
> diff -r 658c33aa557a -r 250cc32cdde6 devel/kernel-2.6.spec
> --- a/devel/kernel-2.6.spec	Sat Jul 22 09:19:48 2006 -0400
> +++ b/devel/kernel-2.6.spec	Sat Jul 22 09:25:25 2006 -0400
> @@ -36,6 +36,9 @@ Summary: The Linux kernel (the core of t
>  %define xen_version 20060719
>  %define make_target bzImage
>  %define kernel_image x86
> +%define xen_flags verbose=y debug=y crash_debug=y pae=y
> +%define xen_target vmlinuz
> +%define xen_image vmlinuz
>  
>  %define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
>  
> @@ -56,10 +59,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
> @@ -134,11 +141,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
>  
>  #
> @@ -237,6 +248,7 @@ Source33: kernel-%{kversion}-i686-xen.co
>  Source33: kernel-%{kversion}-i686-xen.config
>  Source34: kernel-%{kversion}-x86_64-xen.config
>  Source35: kernel-%{kversion}-i686-kdump.config
> +Source36: kernel-%{kversion}-ia64-xen.config
>  
>  #Source66: kernel-%{kversion}-sparc.config
>  #Source67: kernel-%{kversion}-sparc64.config
> @@ -785,17 +797,29 @@ cd linux-%{kversion}.%{_target_cpu}
>  #
>  %patch950 -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; \
>  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, they will announce their
retirement
> +# automatically when the changes propogate down the chain to Juan
> +if [[ ! -f arch/ia64/kernel/asm-offsets.c ]]; then
> +    ln -sf ../../../../xen/include/asm-ia64/asm-xsi-offsets.h
include/asm-ia64/xen/
> +else
> +    printf "*\n* please retire asm-xsi-offsets.h symlink from
kernel-2.6.spec\n*\n"
> +fi
> +if grep -q xenia64_init drivers/xen/core/Makefile; then
> +    ln -sf ../../../arch/ia64/xen/drivers/xenia64_init.c drivers/xen/core/
> +else
> +    printf "*\n* please retire xenia64_init.c symlink from
kernel-2.6.spec\n*\n"
> +fi
>  
>  %patch951 -p1
>  %patch952 -p1
> @@ -1235,9 +1259,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
>  %if %{includexen}
>  %if %{buildxen}
>    cd xen
> -  mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
> -  make debug=y verbose=y crash_debug=y pae=y
> -  install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}
> +  mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot
> +  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 ..
>    mkdir -p $RPM_BUILD_ROOT/usr/src/kernels/%{KVERREL}-xen-%{_target_cpu}
> @@ -1261,7 +1285,7 @@ BuildKernel %make_target %kernel_image s
>  
>  %if %{includexen}
>  %if %{buildxen}
> -BuildKernel vmlinuz vmlinuz xen
> +BuildKernel %xen_target %xen_image xen
>  %endif
>  %endif
>  
> @@ -1432,7 +1456,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
> @@ -1565,7 +1589,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
> diff -r 658c33aa557a -r 250cc32cdde6 devel/configs/config-xen-ia64
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/devel/configs/config-xen-ia64	Sat Jul 22 09:25:25 2006 -0400
> @@ -0,0 +1,20 @@
> +# 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_SPARSEMEM_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
>

On Sat, 2006-07-22 at 09:31 -0400, Aron Griffis wrote:
> Hi guys,
> 
> There are four ways you could be a big help to the xen-ia64 effort.
> I have mentioned these in the past but never pulled them together into
> a single request.
Sorry for getting so long in answering you, but A PAE bug and getting
linux-2.6-xen working on 2.6.18-rc2 have required all my attention :(
> 1. Publish Juan''s tree which is the result of his merge of
>    linux-2.6.tip-xen, linux-2.6 and linux-2.6-xen.  How about
>    http://people.redhat.com/quintela/linux-2.6.tip-xen-fedora.hg?
>    As things stand right now, it''s very difficult for ia64 devs to
>    contribute to Juan''s patch, for 2 reasons: (1) we never see it
>    until after a new kernel rpm is published, (2) all we get is the
>    final result, lacking the extremely helpful changeset history.
It is based on 2.6.18-rc2.  It is on:

http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora

It is public only since Tuesday (I was waiting for a place where to
publish it).  Tree will not work on ia64, I didn''t forward ported the
ia64 changes, noly x86 & x86_64 (and it was painfull enough, time
source, smp-alternatives x86_64, irqtrace, vDSO on x86 & friends meaned
that I had to go back & re-apply series of patches one at a time to find
a coulpe of bugs).
> 2. Use matched xenlinux/hypervisor pairs.  At the OLS Xen mini-summit
>    there was some discussion of compatibility.  The statements were:
Believe me that we _try_, and very hard.
> 	- old domU should run on new hypervisor
Agreed.  I normally test plain fc5 domU on all my new kernels.
> 	- new domU NOT guaranteed to run on old hypervisor
We have found that lately this "normally" works, versus bugs.
> 	- dom0 and hypervisor should be MATCHED
Guess why HV on fedora is on the same package that the kernel, and they
have indeed the same version number?
>    Presently (kernel-2.6.17-1.2432.fc6.src.rpm) it appears that the
>    hypervisor and xen patch are both dated 20060719.  That''s a
good
>    sign! :-)   It would be great if you could provide some indication
>    of your intent to continue using matched pairs.  Are they actually
>    based on the same xen-unstable changeset?  We, the users, can''t
>    tell because the tarball is dated instead of cset-stamped, and
>    Juan''s tree isn''t available.  See #1 ;-)
Normally I add cset numbers in the changelog, but will try to put them
into the HV version number (it maks as much sense as the date,
actually).

About the source tree, it is already public.  It hasn''t been published
sooner due to lack of somobdy setting up a server.  Now it is done.
> 3. Apply my kernel.spec and config changes at the end of this email.
>    This would make it much easier for the ia64 developers to do test
>    builds and track down failures.  Presently it''s a pain for me
to
>    maintain this out of tree.
Will do today.  Will send one email once this is done.
> 4. Apply the xen.spec and libvirt.spec changes.
> 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00022.html
> 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00021.html
> 
>    Regarding libvirt.spec, I''ve talked with Daniel and
he''s just
>    waiting for xen.spec to be ia64-enabled...
Will talk with daniel when he is back from OLS.
> Objections/comments?  I''ll attempt to update any relevant BZs
today.
Will comment on the patches in a follow-up.

Later, Juan.

On Sat, 2006-07-22 at 09:31 -0400, Aron Griffis wrote:
> Hi guys,
Hi Aron
> 3. Apply my kernel.spec and config changes at the end of this email.
>    This would make it much easier for the ia64 developers to do test
>    builds and track down failures.  Presently it''s a pain for me
to
>    maintain this out of tree.
Applied everything except this two bits:

> @@ -56,10 +59,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
Not enable ia64 until I know that it compiles at least :p
>  %ifarch ppc64
> @@ -785,17 +797,29 @@ cd linux-%{kversion}.%{_target_cpu}
>  #
>  %patch950 -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; \
>  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, they will announce their
retirement
> +# automatically when the changes propogate down the chain to Juan
> +if [[ ! -f arch/ia64/kernel/asm-offsets.c ]]; then
> +    ln -sf ../../../../xen/include/asm-ia64/asm-xsi-offsets.h
include/asm-ia64/xen/
> +else
> +    printf "*\n* please retire asm-xsi-offsets.h symlink from
kernel-2.6.spec\n*\n"
> +fi
> +if grep -q xenia64_init drivers/xen/core/Makefile; then
> +    ln -sf ../../../arch/ia64/xen/drivers/xenia64_init.c drivers/xen/core/
> +else
> +    printf "*\n* please retire xenia64_init.c symlink from
kernel-2.6.spec\n*\n"
> +fi
>  
>  %patch951 -p1
>  %patch952 -p1
I need this to get plain ia64 compiling.  I will get an account in an
ia64 machine at some point next week.  Once that I check that plain ia64
compiles out of my tree, I remove this bit.

Fair enough?

Comments?

Later, Juan.

Hi, Juan, Aron and all

I fix Juan''s http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora 
to build on ia64.
But I have not booted linux kernel (not xen), 
and there are many compile warnings.
I''m fixing the tree now.

I used the attach config.
Please check them.

My fix patcheds are the blew. Please comments.
1. build_ia64_add_files.patch
   simple import gate.S, gate.ld.S, patch.c into arch/ia64/kernel
   (these are from linux-2.6.18-rc2)
2. build_ia64.patch
   some fix (resend_irq, ioremap, and so on)

Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>

Best Regards,

Akio Takebe
>On Sat, 2006-07-22 at 09:31 -0400, Aron Griffis wrote:
>> Hi guys,
>> 
>> There are four ways you could be a big help to the xen-ia64 effort.
>> I have mentioned these in the past but never pulled them together into
>> a single request.
>
>Sorry for getting so long in answering you, but A PAE bug and getting
>linux-2.6-xen working on 2.6.18-rc2 have required all my attention :(
>
>> 1. Publish Juan''s tree which is the result of his merge of
>>    linux-2.6.tip-xen, linux-2.6 and linux-2.6-xen.  How about
>>    http://people.redhat.com/quintela/linux-2.6.tip-xen-fedora.hg?
>>    As things stand right now, it''s very difficult for ia64
devs to
>>    contribute to Juan''s patch, for 2 reasons: (1) we never see
it
>>    until after a new kernel rpm is published, (2) all we get is the
>>    final result, lacking the extremely helpful changeset history.
>
>It is based on 2.6.18-rc2.  It is on:
>
>http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora
>
>It is public only since Tuesday (I was waiting for a place where to
>publish it).  Tree will not work on ia64, I didn''t forward ported
the
>ia64 changes, noly x86 & x86_64 (and it was painfull enough, time
>source, smp-alternatives x86_64, irqtrace, vDSO on x86 & friends meaned
>that I had to go back & re-apply series of patches one at a time to find
>a coulpe of bugs).
>
>> 2. Use matched xenlinux/hypervisor pairs.  At the OLS Xen mini-summit
>>    there was some discussion of compatibility.  The statements were:
>
>Believe me that we _try_, and very hard.
>
>> 	- old domU should run on new hypervisor
>
>Agreed.  I normally test plain fc5 domU on all my new kernels.
>
>> 	- new domU NOT guaranteed to run on old hypervisor
>
>We have found that lately this "normally" works, versus bugs.
>
>> 	- dom0 and hypervisor should be MATCHED
>
>Guess why HV on fedora is on the same package that the kernel, and they
>have indeed the same version number?
>
>>    Presently (kernel-2.6.17-1.2432.fc6.src.rpm) it appears that the
>>    hypervisor and xen patch are both dated 20060719.  That''s a
good
>>    sign! :-)   It would be great if you could provide some indication
>>    of your intent to continue using matched pairs.  Are they actually
>>    based on the same xen-unstable changeset?  We, the users,
can''t
>>    tell because the tarball is dated instead of cset-stamped, and
>>    Juan''s tree isn''t available.  See #1 ;-)
>
>Normally I add cset numbers in the changelog, but will try to put them
>into the HV version number (it maks as much sense as the date,
>actually).
>
>About the source tree, it is already public.  It hasn''t been
published
>sooner due to lack of somobdy setting up a server.  Now it is done.
>
>> 3. Apply my kernel.spec and config changes at the end of this email.
>>    This would make it much easier for the ia64 developers to do test
>>    builds and track down failures.  Presently it''s a pain for
me to
>>    maintain this out of tree.
>
>Will do today.  Will send one email once this is done.
>
>> 4. Apply the xen.spec and libvirt.spec changes.
>> 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00022.html
>> 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00021.html
>> 
>>    Regarding libvirt.spec, I''ve talked with Daniel and
he''s just
>>    waiting for xen.spec to be ia64-enabled...
>
>Will talk with daniel when he is back from OLS.
>
>> Objections/comments?  I''ll attempt to update any relevant BZs
today.
>
>Will comment on the patches in a follow-up.
>
>Later, Juan.
>
>--
>Fedora-ia64-list mailing list
>Fedora-ia64-list@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-ia64-list

Hi, Juan, Aron and all

I fix Juan''s http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora 
to build on ia64.
But I have not booted linux kernel (not xen), 
and there are many compile warnings.
I''m fixing the tree now.

I used the attach config.
Please check them.

My fix patcheds are the blew. Please comments.
1. build_ia64_add_files.patch
   simple import gate.S, gate.ld.S, patch.c into arch/ia64/kernel
   (these are from linux-2.6.18-rc2)
2. build_ia64.patch
   some fix (resend_irq, ioremap, and so on)

Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>

Best Regards,

Akio Takebe

Juan Quintela wrote:  [Sat Jul 22 2006, 10:33:50AM EDT]
> > 1. Publish Juan''s tree which is the result of his merge of
> >    linux-2.6.tip-xen, linux-2.6 and linux-2.6-xen.  How about
> >    http://people.redhat.com/quintela/linux-2.6.tip-xen-fedora.hg?
> >    As things stand right now, it''s very difficult for ia64
devs to
> >    contribute to Juan''s patch, for 2 reasons: (1) we never
see it
> >    until after a new kernel rpm is published, (2) all we get is the
> >    final result, lacking the extremely helpful changeset history.
> 
> It is based on 2.6.18-rc2.  It is on:
> 
> http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora
Thanks Juan, this is a huge help.
> > 2. Use matched xenlinux/hypervisor pairs.  At the OLS Xen mini-summit
> >    there was some discussion of compatibility.  The statements were:
> 
> Believe me that we _try_, and very hard.
Thanks, that is good to know.  Until now I hadn''t heard a statement
from RH regarding that.

I posted a message a while back containing a method for absolutely
matching the hypervisor to the kernel patch:

https://www.redhat.com/archives/fedora-xen/2006-July/msg00024.html

Is that approximately what you''re doing now?
> > 	- old domU should run on new hypervisor
> 
> Agreed.  I normally test plain fc5 domU on all my new kernels.
> 
> > 	- new domU NOT guaranteed to run on old hypervisor
> 
> We have found that lately this "normally" works, versus bugs.
I''m sorry, your response confuses me here.  :-( 

Just to be clear: These three bullet points I posted are the stated
goals of Xen upstream.  Fedora should assume that a new domU will NOT
run on an old hypervisor, regardless of empirical evidence...
> > 	- dom0 and hypervisor should be MATCHED
> 
> Guess why HV on fedora is on the same package that the kernel, and they
> have indeed the same version number?
:-)

Thanks,
Aron

Hi Aron
> I posted a message a while back containing a method for absolutely
> matching the hypervisor to the kernel patch:
> 
> https://www.redhat.com/archives/fedora-xen/2006-July/msg00024.html
> 
> Is that approximately what you''re doing now?
No :)

My experience is that HV <-> dom0 is too unstable.  Then basically I
update the hypervisor when I found that i386/x86_64 domU kernel don''t
work.  Or somebody complains that HVM has become too unstable and that
using unstable HV fixes it.

With the state of flush that is xen at this moment, I preffer that
approach.  But feel free to ask me to update the HV each time that gets
broken for you :)
> > > 	- old domU should run on new hypervisor
> > 
> > Agreed.  I normally test plain fc5 domU on all my new kernels.
> > 
> > > 	- new domU NOT guaranteed to run on old hypervisor
> > 
> > We have found that lately this "normally" works, versus
bugs.
> 
> I''m sorry, your response confuses me here.  :-( 
In the past, no guarantees that not matching dom0 <->HV will work.  And
it failed quite a bit.

Lately (for 3.0.2 more or less), HV and dom0 try to agree on a minimum
set of capabilities.  And it has worked "reasonablely well".  I have
seen a couple of bugs in the compatibility, but they were fixed quite
fast.
> Just to be clear: These three bullet points I posted are the stated
> goals of Xen upstream.  Fedora should assume that a new domU will NOT
> run on an old hypervisor, regardless of empirical evidence...
For FC6, this is not a problem.  But for the future, this is a _big_
problem.  When FC7 is about to be out, it is reasonable for fedora users
to expect that installing  a new domU will lets them to test fc7 domU on
its existing fc6 dom0.  My understanding is that XenSource expect that
dom0 <-> domU interface to stay stable.  HV <-> domU interface to be
a
"we will not broke on purpose", but no guarntees.

Later, Juan.

On Sat, 2006-07-22 at 09:31 -0400, Aron Griffis wrote:
> 4. Apply the xen.spec and libvirt.spec changes.
> 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00022.html
> 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00021.html
> 
>    Regarding libvirt.spec, I''ve talked with Daniel and
he''s just
>    waiting for xen.spec to be ia64-enabled...
These should now be built and present in rawhide tomorrow.

Jeremy

On Wed, Aug 02, 2006 at 05:52:59PM -0400, Jeremy Katz
wrote:
> On Sat, 2006-07-22 at 09:31 -0400, Aron Griffis wrote:
> > 4. Apply the xen.spec and libvirt.spec changes.
> > 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00022.html
> > 	https://www.redhat.com/archives/fedora-xen/2006-July/msg00021.html
> > 
> >    Regarding libvirt.spec, I''ve talked with Daniel and
he''s just
> >    waiting for xen.spec to be ia64-enabled...
> 
> These should now be built and present in rawhide tomorrow.
  and the spec file has been updated upstream last week too.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/