Aron Griffis
2006-Jun-27 20:40 UTC
[Fedora-xen] [RFC] enable xen-ia64 in fedora kernel cvs
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
2006-Jun-27 20:49 UTC
[Fedora-xen] Re: [RFC] enable xen-ia64 in fedora kernel cvs
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
Chris Wright
2006-Jun-27 21:34 UTC
[Fedora-xen] Re: [RFC] enable xen-ia64 in fedora kernel cvs
* Aron Griffis (aron@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,r12This 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
2006-Jun-27 22:47 UTC
Re: [Fedora-xen] Re: [RFC] enable xen-ia64 in fedora kernel cvs
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
Chris Wright
2006-Jun-27 23:12 UTC
Re: [Fedora-xen] Re: [RFC] enable xen-ia64 in fedora kernel cvs
* Aron Griffis (aron@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