fedora-xen-ia64 integration, step 1

[Aron Griffis]

Hi Dave and Juan,

I'd like to get started on the path to integrating the fedora-xen-ia64
work into fedora.  There are a number of pieces that I'll be trying to
pull together over the next few days.  The biggest/hardest piece is
the kernel rpm.

I've split the changes into two parts:
    1. generic fixes and enablement
    2. ia64 xen integration

This mail contains the first part.  For the second part, I'd like to
request that Juan updates his patch to the most recent xen-unstable
first.  Then I'll work on making it build on ia64 and send back
whatever changes are necessary, including the ia64-xen[0U] configs.

Once the kernel rpm is working, it should be a relatively simple
matter to make the remainder of modifications to "turn on" xen-ia64.
Sound reasonable?

Regards,
Aron

--
This patch makes the following changes to the kernel specfile:

    - abstract xenlinux build using xen_flags, xen_target and
      xen_image instead of assuming x86 behavior

    - add xen_* overrides to %ifarch ia64, won't be used until
      buildxen is flipped on for ia64

    - run the xen-mkbuildtree-pre hook following applying the xen
      patch.  This touches a couple files on ia64 but doesn't
      interfere with any patching down the line.  (I and others have
      been submitting patches to xen-ia64-devel and xen-devel to
      further reduce its function, but it should be harmless as-is.)

    - update numerous hardcoded references to /boot to use
      %{image_install_path} instead.  But make an exception for the
      xenU kernels which never need to be available for system
      boot.

    - build the hypervisor with %{?_smp_mflags} (it works fine)

Signed-off-by: Aron Griffis <aron(a)hp.com&gt;

--- kernel-2.6.spec.orig	2006-06-01 19:12:59.000000000 -0400
+++ kernel-2.6.spec	2006-06-02 11:18:33.000000000 -0400
@@ -32,6 +32,9 @@
 %define xen_version 20060524
 %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}
 
@@ -127,11 +130,15 @@
 %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
 
 #
@@ -834,6 +841,15 @@
 # Delete the rest of the backup files, they just confuse the build later
 find -name "*.p.xen" | xargs rm -f
 
+# Run the xen-mkbuildtree-pre hook, if it exists for this architecture.
+# Hopefully this is kept clean (or non-existent) so that patches aren't confused
+# further down the line.  Presently it's used only for ia64, and only for files
+# that we aren't interested in patching.
+if [[ -f "arch/%{_arch}/xen-mkbuildtree-pre" ]]; then
+    chmod +x arch/%{_arch}/xen-mkbuildtree-pre
+    arch/%{_arch}/xen-mkbuildtree-pre
+fi
+
 #
 # 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
@@ -1157,7 +1173,13 @@
     mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
     install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
     install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
-    cp $KernelImage $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer
+    if [[ "$Flavour" == *xenU* ]]; then
+      # xenU kernels should always install to /boot
+      # because they're never needed for system boot
+      cp $KernelImage $RPM_BUILD_ROOT/boot/vmlinuz-$KernelVer
+    else
+      cp $KernelImage $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer
+    fi
     if [ -f arch/$Arch/boot/zImage.stub ]; then
       cp arch/$Arch/boot/zImage.stub
$RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
     fi
@@ -1293,15 +1315,15 @@
 %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 %{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
@@ -1310,31 +1332,31 @@
 cd linux-%{kversion}.%{_target_cpu}
 
 %if %{buildup}
-BuildKernel %make_target %kernel_image
+BuildKernel %{make_target} %{kernel_image}
 %endif
 
 %if %{buildpae}
-BuildKernel %make_target %kernel_image PAE
+BuildKernel %{make_target} %{kernel_image} PAE
 %endif
 
 %if %{buildsmp}
-BuildKernel %make_target %kernel_image smp
+BuildKernel %{make_target} %{kernel_image} smp
 %endif
 
 %if %{includexen}
 %if %{buildxenPAE}
-BuildKernel vmlinuz vmlinuz xen0-PAE
-BuildKernel vmlinuz vmlinuz xenU-PAE
+BuildKernel %{xen_target} %{xen_image} xen0-PAE
+BuildKernel %{xen_target} %{xen_image} xenU-PAE
 %endif
 
 %if %{buildxen}
-BuildKernel vmlinuz vmlinuz xen0
-BuildKernel vmlinuz vmlinuz xenU
+BuildKernel %{xen_target} %{xen_image} xen0
+BuildKernel %{xen_target} %{xen_image} xenU
 %endif
 %endif
 
 %if %{buildkdump}
-BuildKernel %make_target %kernel_image kdump
+BuildKernel %{make_target} %{kernel_image} kdump
 %endif
 
 ###
@@ -1443,7 +1465,7 @@
 
 %post xen0
 [ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen0
-/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL} %{KVERREL}xen0
+/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL} %{KVERREL}xen0
 [ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
 
 %post xen0-devel
@@ -1469,7 +1491,7 @@
 
 %post xen0-PAE
 [ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen0-PAE
-/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
+/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
 [ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
 
 %post xen0-PAE-devel
@@ -1611,7 +1633,7 @@
 /%{image_install_path}/vmlinuz-%{KVERREL}xen0
 /boot/System.map-%{KVERREL}xen0
 /boot/config-%{KVERREL}xen0
-/boot/xen.gz-%{KVERREL}
+/%{image_install_path}/xen.gz-%{KVERREL}
 /boot/xen-syms-%{KVERREL}
 %dir /lib/modules/%{KVERREL}xen0
 /lib/modules/%{KVERREL}xen0/kernel
@@ -1628,7 +1650,7 @@
 
 %files xenU
 %defattr(-,root,root)
-/%{image_install_path}/vmlinuz-%{KVERREL}xenU
+/boot/vmlinuz-%{KVERREL}xenU
 /boot/System.map-%{KVERREL}xenU
 /boot/config-%{KVERREL}xenU
 %dir /lib/modules/%{KVERREL}xenU
@@ -1651,7 +1673,7 @@
 /%{image_install_path}/vmlinuz-%{KVERREL}xen0-PAE
 /boot/System.map-%{KVERREL}xen0-PAE
 /boot/config-%{KVERREL}xen0-PAE
-/boot/xen.gz-%{KVERREL}-PAE
+/%{image_install_path}/xen.gz-%{KVERREL}-PAE
 /boot/xen-syms-%{KVERREL}-PAE
 %dir /lib/modules/%{KVERREL}xen0-PAE
 /lib/modules/%{KVERREL}xen0-PAE/kernel
@@ -1668,7 +1690,7 @@
 
 %files xenU-PAE
 %defattr(-,root,root)
-/%{image_install_path}/vmlinuz-%{KVERREL}xenU-PAE
+/boot/vmlinuz-%{KVERREL}xenU-PAE
 /boot/System.map-%{KVERREL}xenU-PAE
 /boot/config-%{KVERREL}xenU-PAE
 %dir /lib/modules/%{KVERREL}xenU-PAE

[Jeremy Katz]

On Fri, 2006-06-02 at 11:32 -0400, Aron Griffis wrote:
>      - update numerous hardcoded references to /boot to use
>        %{image_install_path} instead.  But make an exception for the
>        xenU kernels which never need to be available for system
>        boot. 
For consistency with native, I'd prefer the kernels for xenU to also end
up in %{image_install_path}.

Jeremy

[Aron Griffis]

Jeremy Katz wrote:  [Fri Jun 02 2006, 11:48:39AM EDT]
>  On Fri, 2006-06-02 at 11:32 -0400, Aron Griffis wrote:
>  >     - update numerous hardcoded references to /boot to use
>  >       %{image_install_path} instead.  But make an exception for the
>  >       xenU kernels which never need to be available for system
>  >       boot.
>  
>  For consistency with native, I'd prefer the kernels for xenU to also end
>  up in %{image_install_path}. 
Ok, it doesn't make a huge difference to me.  I was just trying to
spare the efi partition, but it's not a big deal.

Aron

[Juan Quintela]

On Fri, 2006-06-02 at 11:32 -0400, Aron Griffis wrote:
>  Hi Dave and Juan, 
Hi Aron



>  --
>  This patch makes the following changes to the kernel specfile:
>  
>      - abstract xenlinux build using xen_flags, xen_target and
>        xen_image instead of assuming x86 behavior
>  
>      - add xen_* overrides to %ifarch ia64, won't be used until
>        buildxen is flipped on for ia64
>  
>      - run the xen-mkbuildtree-pre hook following applying the xen
>        patch.  This touches a couple files on ia64 but doesn't
>        interfere with any patching down the line.  (I and others have
>        been submitting patches to xen-ia64-devel and xen-devel to
>        further reduce its function, but it should be harmless as-is.) 
I think that this one is not acceptable :(
We compile from the same source on _all_ architectures.  If the source
changes  from architecture to architecture, we are broken :(

Notice also that I do my compile testing as something like:i 

cd tree
for arch in $CONFIGS; do
	make O=../$ARCH all
done

Or somesuch. What is on that patch, anyways.

>      - update numerous hardcoded references to /boot to usetu
>        %{image_install_path} instead.  But make an exception for the
>        xenU kernels which never need to be available for system
>        boot. 
Uh, oh.  If everything happens as I hope, after this weekend, xenU
kernel is history.  xen0 & xenU kernels are going to be the same
kernel :p  You need another solution here.  I haven't studied the ia64
efi thing to be able to suggest anything, sorry.

>      - build the hypervisor with %{?_smp_mflags} (it works fine)
 
>   %if %{buildup}
>  -BuildKernel %make_target %kernel_image
>  +BuildKernel %{make_target} %{kernel_image}
>   %endif 
Any reason why you do this changes?  in space separated cases, it
shouldn't be needed the use of {}

Hope that this helps.

Later, Juan.

[Aron Griffis]

Juan Quintela wrote:  [Fri Jun 02 2006, 12:14:25PM EDT]
>  >     - run the xen-mkbuildtree-pre hook following applying the
> xen
>  >       patch.  This touches a couple files on ia64 but doesn't
>  >       interfere with any patching down the line.  (I and others have
>  >       been submitting patches to xen-ia64-devel and xen-devel to
>  >       further reduce its function, but it should be harmless as-is.)
>  
>  I think that this one is not acceptable :(
>  We compile from the same source on _all_ architectures.  If the source
>  changes  from architecture to architecture, we are broken :(
>  
>  Notice also that I do my compile testing as something like:i 
>  
>  cd tree
>  for arch in $CONFIGS; do
>  	make O=../$ARCH all
>  done 
Ok, we can make this work, no problem :-)

Here is the current xen-mkbuildtree-pre in xen-unstable: 
http://xenbits.xensource.com/xen-unstable.hg?f=a2d784a51f25;file=linux-2....

Instead of running it only on ia64, we can run it on all
architectures.  Since the recent patches, the last remaining files
created by that script are:

    include/asm-ia64/xen/asm-xsi-offsets.h
    drivers/xen/core/xenia64_init.c

Neither of those affect any architecture other than ia64.  I'm hoping
to move the second one to a better home next week.  The first one is
less trivial since it's auto-generated in the hypervisor build.

>  >     - update numerous hardcoded references to /boot to usetu
>  >       %{image_install_path} instead.  But make an exception for the
>  >       xenU kernels which never need to be available for system
>  >       boot.
>  
>  Uh, oh.  If everything happens as I hope, after this weekend, xenU
>  kernel is history.  xen0 & xenU kernels are going to be the same
>  kernel :p  You need another solution here.  I haven't studied the ia64
>  efi thing to be able to suggest anything, sorry. 
No problem.  I'm very happy to switch to a unified xen kernel.

>  >     - build the hypervisor with %{?_smp_mflags} (it works fine)
>  
>   
>  >  %if %{buildup}
>  > -BuildKernel %make_target %kernel_image
>  > +BuildKernel %{make_target} %{kernel_image}
>  >  %endif
>  
>  Any reason why you do this changes?  in space separated cases, it
>  shouldn't be needed the use of {} 
Nope, it just seemed more consistent with, for example, the %if
conditional preceding it :-)

Aron

[Juan Quintela]

On Fri, 2006-06-02 at 12:37 -0400, Aron Griffis wrote:

Hi
	I am going to integrate the _non_ problematic changes right now :)

>  Ok, we can make this work, no problem :-)
>  
>  Here is the current xen-mkbuildtree-pre in xen-unstable: 
>
> http://xenbits.xensource.com/xen-unstable.hg?f=a2d784a51f25;file=linux-2....
>  
>  Instead of running it only on ia64, we can run it on all
>  architectures.  Since the recent patches, the last remaining files
>  created by that script are:
>  
>      include/asm-ia64/xen/asm-xsi-offsets.h
>      drivers/xen/core/xenia64_init.c 
Noooooooooooo, the sparse tree braindamage again :(

xen-sparse tree is already brain-damaged enough for now, I think that
addind this kind of "improvements" will make it completelly
uncromprensible.

If you already have a different repository, why don't you _just_ put
that files into the right place in the 1st place?

I will very much preffer to add another patch that this copy of files :p

/me is just confused

>  Nope, it just seemed more consistent with, for example, the %if
>  conditional preceding it :-) 
Taking a look at integrating your changes.

Thanks, Juan.

[Aron Griffis]

Juan Quintela wrote:  [Fri Jun 02 2006, 12:53:02PM EDT]
>  > Here is the current xen-mkbuildtree-pre in xen-unstable: 
>  >
> http://xenbits.xensource.com/xen-unstable.hg?f=a2d784a51f25;file=linux-2....
>  > 
>  > Instead of running it only on ia64, we can run it on all
>  > architectures.  Since the recent patches, the last remaining files
>  > created by that script are:
>  > 
>  >     include/asm-ia64/xen/asm-xsi-offsets.h
>  >     drivers/xen/core/xenia64_init.c
>  
>  Noooooooooooo, the sparse tree braindamage again :(
>  
>  xen-sparse tree is already brain-damaged enough for now, I think
>  that addind this kind of "improvements" will make it completelly
>  uncromprensible. 
I agree that it's an ugly hack.  But please consider two things:

1. If you look at the revision history for xen-mkbuildtree-pre (at the
   link I posted above) you'll see that it's down from 12 files to
   2 in the past month.  We're working hard on getting rid of it
   completely.

2. The two files that are left have zero chance of confusing your
   patching process.  One is regenerated on every build
   (asm-xsi-offsets.h).  The other is planning to be moved soon.

>  If you already have a different repository, why don't you _just_
> put
>  that files into the right place in the 1st place? 
Now I'm the one that's confused!  :-(

I don't have a different repository.  I have a temporary
xen-ia64-unstable tree ported to 2.6.17-rc5-git6 (at the moment) so
I could generate linux-2.6-xen.patch.  The repository I have
personally is only for the purpose of prototyping this effort.

At this point I'm working on going from prototyping to integration,
which means that instead of using my temporary tree, we'll use the
xen-unstable tree that you have already ported.  xen-unstable and
xen-ia64-unstable were synced just a couple days ago so it should work
well on ia64.

Thanks for looking at the changes.  I'll work on eradicating
xen-mkbuildtree-pre, but it will probably take a few days at least.

Aron

[Juan Quintela]

On Fri, 2006-06-02 at 16:54 -0400, Aron Griffis wrote:

Hi

>  I agree that it's an ugly hack.  But please consider two things:
>  
>  1. If you look at the revision history for xen-mkbuildtree-pre (at the
>     link I posted above) you'll see that it's down from 12 files to
>     2 in the past month.  We're working hard on getting rid of it
>     completely. 
That is one steep in the right direction :)

>  2. The two files that are left have zero chance of confusing your
>     patching process.  One is regenerated on every build
>     (asm-xsi-offsets.h).  The other is planning to be moved soon. 
It is my understanding that you generate this file during the hypervisor
building, right.  Just now, we are not generating file from the
hypervisor, but we could generate it.


>  > If you already have a different repository, why don't you
> _just_ put
>  > that files into the right place in the 1st place?
>   
>  Now I'm the one that's confused!  :-( 
Sorry, to confuse you.

>  I don't have a different repository.  I have a temporary
>  xen-ia64-unstable tree ported to 2.6.17-rc5-git6 (at the moment) so
>  I could generate linux-2.6-xen.patch.  The repository I have
>  personally is only for the purpose of prototyping this effort. 
ok, s/repository/tree/, or s/repository/local repository/.  You are
already patching the xen-unstable tree.  Your patch contains several
changes.  Why don't you add just two files instead of a script that
generates two links to two files that you also included in your patch?

I am losing anything?  Or could you, instead of generate the script that
links the files, just include the files in the right place?

>  At this point I'm working on going from prototyping to
> integration,
>  which means that instead of using my temporary tree, we'll use the
>  xen-unstable tree that you have already ported.  xen-unstable and
>  xen-ia64-unstable were synced just a couple days ago so it should work
>  well on ia64. 
Actually we use linux-2.6-xen instead of xen-unstable because it is a
_real_ tree, and make everything _so_ much nicer :)

What I don't understand is:

a- all your changes are on xen-unstable, then they should also be on
linux-2.6-xen, and you should do nothing, everything should be fine.

b- some of your patches are not on xen-unstable, and you need to send me
a patch.  If you have to send me a patch to put on top of my linux-xen
patch, then you can also include that two missing files instead of one
sript that generates a link to them?

I am missing anything?


_
>  Thanks for looking at the changes.  I'll work on eradicating
>  xen-mkbuildtree-pre, but it will probably take a few days at least. 
A few days is not a problem at all :)

Later, Juan.

Kernel DomU ??????

[Eric Marty]

Hello All,

The stupid question ...

When i boot in DOMU i have :


Fedora Core release 3
kernel xen.2.6.16-xen on an i686

same with other version Fedora

if i verify mu kernel with uname -a , i have Xen.

If anybody can tell me Why ?

Thanks

Eric

[Aron Griffis]

Here is an updated patch based on Juan's and Jeremy's comments.

--
This patch makes the following changes to the kernel specfile:

    - abstract xenlinux build using xen_flags, xen_target and
      xen_image instead of assuming x86 behavior

    - add xen_* overrides to %ifarch ia64, won't be used until
      buildxen is flipped on for ia64

    - run the ia64 xen-mkbuildtree-pre hook following applying the xen
      patch, on all architectures for consistency.

    - update numerous hardcoded references to /boot to use
      %{image_install_path} instead.  No exception for xenU kernels.

    - build the hypervisor with %{?_smp_mflags} (it works fine)

Signed-off-by: Aron Griffis <aron(a)hp.com&gt;

--- kernel-2.6.spec.orig	2006-06-01 19:12:59.000000000 -0400
+++ kernel-2.6.spec	2006-06-02 13:05:34.000000000 -0400
@@ -32,6 +32,9 @@
 %define xen_version 20060524
 %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}
 
@@ -127,11 +130,15 @@
 %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
 
 #
@@ -834,6 +841,11 @@
 # Delete the rest of the backup files, they just confuse the build later
 find -name "*.p.xen" | xargs rm -f
 
+# Run the ia64 xen-mkbuildtree-pre hook, which creates these symlinks:
+#       include/asm-ia64/xen/asm-xsi-offsets.h
+#       drivers/xen/core/xenia64_init.c
+arch/ia64/xen-mkbuildtree-pre
+
 #
 # 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
@@ -1293,15 +1305,15 @@
 %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 %{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
@@ -1323,13 +1335,13 @@
 
 %if %{includexen}
 %if %{buildxenPAE}
-BuildKernel vmlinuz vmlinuz xen0-PAE
-BuildKernel vmlinuz vmlinuz xenU-PAE
+BuildKernel %xen_target %xen_image xen0-PAE
+BuildKernel %xen_target %xen_image xenU-PAE
 %endif
 
 %if %{buildxen}
-BuildKernel vmlinuz vmlinuz xen0
-BuildKernel vmlinuz vmlinuz xenU
+BuildKernel %xen_target %xen_image xen0
+BuildKernel %xen_target %xen_image xenU
 %endif
 %endif
 
@@ -1443,7 +1455,7 @@
 
 %post xen0
 [ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen0
-/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL} %{KVERREL}xen0
+/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL} %{KVERREL}xen0
 [ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
 
 %post xen0-devel
@@ -1469,7 +1481,7 @@
 
 %post xen0-PAE
 [ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen0-PAE
-/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
+/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
 [ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
 
 %post xen0-PAE-devel
@@ -1611,7 +1623,7 @@
 /%{image_install_path}/vmlinuz-%{KVERREL}xen0
 /boot/System.map-%{KVERREL}xen0
 /boot/config-%{KVERREL}xen0
-/boot/xen.gz-%{KVERREL}
+/%{image_install_path}/xen.gz-%{KVERREL}
 /boot/xen-syms-%{KVERREL}
 %dir /lib/modules/%{KVERREL}xen0
 /lib/modules/%{KVERREL}xen0/kernel
@@ -1651,7 +1663,7 @@
 /%{image_install_path}/vmlinuz-%{KVERREL}xen0-PAE
 /boot/System.map-%{KVERREL}xen0-PAE
 /boot/config-%{KVERREL}xen0-PAE
-/boot/xen.gz-%{KVERREL}-PAE
+/%{image_install_path}/xen.gz-%{KVERREL}-PAE
 /boot/xen-syms-%{KVERREL}-PAE
 %dir /lib/modules/%{KVERREL}xen0-PAE
 /lib/modules/%{KVERREL}xen0-PAE/kernel