Mainline Linux Kernel Configs: Difference between revisions

From Xen
Jump to navigationJump to search
m (remove two duplicates dom0 option)
No edit summary
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Getting the current stable version ==
== Getting the Current Stable Version ==
<span id="stable_version"></span>
<span id="stable_version"></span>
With [http://blog.xen.org/index.php/2011/06/14/linux-3-0-how-did-we-get-initial-domain-dom0-support-there/ v3.0 - how did dom0 support get there] has technical details, but the summary is that the 3.0 is "With Linux 3.0 we now have the major components to be classified as a working initial domain – aka – dom0.". There are bugs, which are documented in [http://wiki.xensource.com/xenwiki/Linux_30_bugs Linux 3.0 and further bugs]


The current kernel tarballs are linked from the front page of [http://kernel.org kernel.org]. For stable use it is recommended that you use the latest "stable" point release. Alternatively you can clone from the stable git tree at <tt>git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git</tt> ([http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary gitweb]).
To download it: [ftp://ftp.kernel.org/pub/linux/kernel/v3.0/linux-3.0.8.tar.bz2]


== Getting the Current Development Version ==
or the latest from [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary Linus Torvalds tree]: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

== Getting the current development version ==
<span id="dev_version"></span>
<span id="dev_version"></span>


There are two main development trees which are interesting to Xen users/developers.
The current day-to-day development is happening in a [http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=summary Konrad's git tree]


=== Mainline Kernel ===
The repository has numerous topic branches to track individual lines of development, and a couple of roll-up branches which contain everything merged together for easy compilation and running.


The first is Linus Torvald's mainline git tree which can be found at <tt>git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git</tt> ([http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary gitweb]).
'''NOTE! All active git branches require at least Xen 4.0.1, using older version (4.0.0 or older) will cause problems, xend not starting, etc.'''


This tree has only one active branch, <tt>master</tt>, but also contains tags for each release and release candidate which can be useful for providing a more concrete baseline for a test or bug report than whatever the current tip happens to be.
Current active branches are:


=== Xen Development Tree ===
* linux-next - patches that are queued up
to go to Linus Torvalad's tree. This includes bug-fixes, new features, etc.
* testing (in Konrad's repository) is off patches being run/developed and obviously going through testing - which means they might not compile or work properly.


The second is xentip tree which is where most day-to-day Xen development work ends up en route to Linus' tree. xentip's tree can be found at <tt>git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git</tt> ([https://git.kernel.org/cgit/linux/kernel/git/xen/tip.git gitweb]).
== Downloading the git tree ==


The repository has numerous topic branches to track individual lines of development, and a couple of roll-up branches which contain everything merged together for easy compilation and running.
<pre><nowiki>
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux
$ cd linux
</nowiki></pre>


'''NOTE! All active git branches require at least Xen 4.0.1, using older version (4.0.0 or older) will cause problems, xend not starting, etc.'''


Current active branches are:
that will automatically check out the 'origin/master' default branch. Note that you need at least 256 MB of free memory, otherwise the "git clone" will fail.


* linux-next - patches that are queued up to go to Linus Torvald's tree. This includes bug-fixes, new features, etc.
Changing the branch: You most probably want to use the "linux-next" (or "upstream/xen") branch, so do this:


== Using git ==


The primary version control system used for Linux kernel development is [http://git-scm.com/ git]. There are numerous git HOWTOs on the web, we only cover the very basics here. For more information on git see:
<pre><nowiki>
* http://git-scm.com/documentation
$ cd /usr/src
* http://learn.github.com/p/intro.html
$ cd linux
* http://linux.yyz.us/git-howto.html
$ git reset --hard
* http://www.landley.net/writing/git-bisect-howto.html
$ git checkout -b upstream/xen origin/upstream/xen
* https://www.google.com/search?q=git
Branch upstream/xen set up to track remote branch refs/remotes/origin/upstream/xen
Switched to a new branch "upstream/xen"
$ git pull
$ git log | less
</nowiki></pre>


To clone Linus' tree:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
$ cd linux


To clone xentip's tree:
(or replace "origin/upstream/xen" with "testing" for example)
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux
$ cd linux


This will automatically check out the 'origin/master' default branch.
Later when you want to update the tree use:


If you are using xentip's tree then you most probably want to use the <tt>linux-next</tt> branch:


$ git reset --hard
<pre><nowiki>
$ git checkout -b xen-next origin/linux-next
$ cd linux
Branch xen-next set up to track remote branch refs/remotes/origin/linux-next
$ make clean
Switched to a new branch "xen-next"
$ git pull
$ git pull
</nowiki></pre>
$ git log | less


Later when you want to update the tree use:


$ git pull
== Configuring the kernel ==
<span id="configure_xen"></span>


== Configuring the Kernel ==
Configure as normal; you can start with your current .config file or use '''make defconfig'''
<span id="configure_xen"></span>
and then depending on what you want your kernel to do (it can do both):


Configure as normal; you can start with your current <tt>.config</tt> file or use '''make defconfig''' ("make multi_v7_defconfig for ARM32) and then:


$ make menuconfig
<pre><nowiki>
make menuconfig
</nowiki></pre>


NOTE0: Make sure you have correct CPU type (Processor Family) set in the kernel configuration, Xen Dom0 options won't show up at all if you have too old CPU selected (too old means a CPU that doesn't support PAE; Pentium Pro was the first CPU to have PAE).
NOTE0: For x86, make sure you have correct CPU type (Processor Family) set in the kernel configuration, Xen Dom0 options won't show up at all if you have too old CPU selected (too old means a CPU that doesn't support PAE; Pentium Pro was the first CPU to have PAE).


NOTE1: If you're building 32 bit version of the kernel, you first need to enable PAE support, since Xen only supports 32 bit PAE kernels nowadays. Xen kernel build options won't show up at all before you've enabled PAE for 32 bit builds (Processor type and features -> High Memory Support (64GB) -> PAE (Physical Address Extension) Support). PAE is not needed for 64 bit kernels.
NOTE1: For x86, if you're building 32 bit version of the kernel, you first need to enable PAE support, since Xen only supports 32 bit PAE kernels nowadays. Xen kernel build options won't show up at all before you've enabled PAE for 32 bit builds (Processor type and features -> High Memory Support (64GB) -> PAE (Physical Address Extension) Support). PAE is not needed for 64 bit kernels.


=== Configure kernel for domU support ===
=== Configuring the Kernel for domU Support ===


# If building 32 bit kernel make sure you have CONFIG_X86_PAE enabled (which is set by selecting CONFIG_HIGHMEM64G)
# If building x86 32 bit kernel make sure you have CONFIG_X86_PAE enabled (which is set by selecting CONFIG_HIGHMEM64G)
#* non-PAE mode doesn't work in 2.6.25, and has been dropped altogether from 2.6.26 and newer kernel versions.
#* non-PAE mode doesn't work in 2.6.25, and has been dropped altogether from 2.6.26 and newer kernel versions.
# Enable these core options (Processor type and features| Paravirtualized guest support]
#For x86 , enable these core options (Processor type and features| Paravirtualized guest support]
#* CONFIG_HYPERVISOR_GUEST=y (3.10+ only)
#* CONFIG_PARAVIRT=y
#* CONFIG_PARAVIRT=y
#* CONFIG_XEN=y
#* CONFIG_XEN=y
#* CONFIG_PARAVIRT_GUEST=y
#* CONFIG_PARAVIRT_GUEST=y
#* CONFIG_PARAVIRT_SPINLOCKS=y
#* CONFIG_PARAVIRT_SPINLOCKS=y
# For ARM, enable these core options (Kernel Features)
#* CONFIG_XEN=y
#* CONFIG_PARAVIRT=y
# And Xen pv console device support (Device Drivers|Character devices
# And Xen pv console device support (Device Drivers|Character devices
#* CONFIG_HVC_DRIVER=y
#* CONFIG_HVC_DRIVER=y
Line 97: Line 97:
#* CONFIG_XEN_SAVE_RESTORE=y
#* CONFIG_XEN_SAVE_RESTORE=y
#* CONFIG_XEN_GRANT_DEV_ALLOC=m
#* CONFIG_XEN_GRANT_DEV_ALLOC=m
# And for tmem support:
# And for tmem support (x86 only):
#* CONFIG_XEN_TMEM=y
#* CONFIG_XEN_TMEM=y
#* CONFIG_CLEANCACHE=y
#* CONFIG_CLEANCACHE=y
Line 103: Line 103:
#* CONFIG_XEN_SELFBALLOONING=y
#* CONFIG_XEN_SELFBALLOONING=y


=== Configure kernel for dom0 support ===
=== Configuring the Kernel for dom0 Support ===


NOTE: Xen dom0 support depends on ACPI support. Make sure you enable ACPI support or you won't see Dom0 options at all.
NOTE: Xen dom0 support depends on ACPI support. Make sure you enable ACPI support or you won't see Dom0 options at all.
Line 109: Line 109:
In addition to the config options above you also need to enable:
In addition to the config options above you also need to enable:


* CONFIG_X86_IO_APIC=y
* CONFIG_ACPI=y
* CONFIG_ACPI_PROCFS=y (optional)
* CONFIG_XEN_DOM0=y
* CONFIG_XEN_DOM0=y
* CONFIG_PCI_XEN=y
* CONFIG_XEN_DEV_EVTCHN=y
* CONFIG_XEN_DEV_EVTCHN=y
* CONFIG_XENFS=y
* CONFIG_XENFS=y
Line 122: Line 118:
* CONFIG_XEN_NETDEV_BACKEND=m
* CONFIG_XEN_NETDEV_BACKEND=m
* CONFIG_XEN_BLKDEV_BACKEND=m
* CONFIG_XEN_BLKDEV_BACKEND=m
* CONFIG_XEN_PCIDEV_BACKEND=m
* CONFIG_XEN_PRIVILEGED_GUEST=y
* CONFIG_XEN_BALLOON=y
* CONFIG_XEN_BALLOON=y
* CONFIG_XEN_SCRUB_PAGES=y
* CONFIG_XEN_SCRUB_PAGES=y


For x86, you will also need to enable:

* CONFIG_X86_IO_APIC=y
* CONFIG_ACPI=y
* CONFIG_ACPI_PROCFS=y (optional)
* CONFIG_PCI_XEN=y
* CONFIG_XEN_PCIDEV_BACKEND=m


If you're using RHEL5 or CentOS5 as a dom0 (ie. you have old udev version), make sure you enable the following options as well:
If you're using RHEL5 or CentOS5 as a dom0 (ie. you have old udev version), make sure you enable the following options as well:
Line 138: Line 139:
<span id="build_kernel"></span>
<span id="build_kernel"></span>


After having downloaded and configured the kernel source as above building the kernel is as simple as:
There are two parts when building Xen: [[#build_xen|Xen]] and the Kernel. After Kernel configuration you have to do two things, build the kernel and build the ramdrive.


$ make all -j <2*number_of_cores>
This is the Ubuntu way:


The <tt>-j</tt> option tells make how many threads to use, a good number is something like twice the number of processor cores in your system since this allows for I/O (e.g. reading the code from disk) to be interleaved with processing (e.g. compiling the code).
<pre><nowiki>
$ cd /usr/src/linux
$ sudo make
$ sudo apt-get install kernel-package fakeroot
$ export CONCURRENCY_LEVEL=<number_of_cores +1>
$ sudo make-kpkg clean
$ sudo fakeroot make-kpkg --initrd --append-to-version=-pv kernel-image kernel-headers
$ sudo dpkg -i ../<linux-image-3.0.XXX.deb>
</nowiki></pre>


== Installing the Kernel ==
The first line will make the kernel with the hidden configuration file (your file hopefully). You might have to do this several times because you will encounter errors that will requiere turning modules off, and start compiling again. It is a good plactice to use make clean when you change many modules at a time. The next line is used for dpkg but is not really that important. the sudo fakeroot line will create your ramdrive needed to boot. This is the debian way of making the image usable this will event copy it to boot but will not update grub.
<span id="install_kernel"></span>


=== The <tt>foo-pkg</tt> Targets ===
The old-skool way:


The kernel contains several makefile targets which can create packages in various formats. These packages include a baseline level of integration with the relevant distros (although not likely to be as good as the distros own packages they are good enough). Even if the distro integration is lacking simply being able to cleanly uninstall the package is a big advantage.
<pre><nowiki>
cd linux
make clean
cp -a .config .config-old
make oldconfig
make menuconfig (if you need to change something)
make bzImage
make modules
make modules_install
# in the following lines replace "version" with the actual kernel version you're compiling.
make install
# And then generate initrd/initramfs image for your dom0 kernel, example for Fedora/RHEL/CentOS:
mkinitrd -f /boot/initrd-version.img version
# For Fedora Core the 'make install' does it automatically
</nowiki></pre>


The full list of package targets can be found in the output of <tt>make help</tt>:
$ make help
[...]
Kernel packaging:
rpm-pkg - Build both source and binary RPM kernel packages
binrpm-pkg - Build only the binary kernel package
deb-pkg - Build the kernel as a deb package
tar-pkg - Build the kernel as an uncompressed tarball
targz-pkg - Build the kernel as a gzip compressed tarball
tarbz2-pkg - Build the kernel as a bzip2 compressed tarball
tarxz-pkg - Build the kernel as a xz compressed tarball
perf-tar-src-pkg - Build perf-3.8.0-rc2.tar source tarball
perf-targz-src-pkg - Build perf-3.8.0-rc2.tar.gz source tarball
perf-tarbz2-src-pkg - Build perf-3.8.0-rc2.tar.bz2 source tarball
perf-tarxz-src-pkg - Build perf-3.8.0-rc2.tar.xz source tarball


The most interesting targets are the <tt>rpm-pkg</tt>, <tt>binrpm-pkg</tt> and <tt>deb-pkg</tt> targets which cover a wide variety of distros. To use simply invoke with make:
=== Update modules ===
$ make deb-pkg
<span id="configure_modules"></span>


Once this command has completed you should find a suitable package in the parent directory which can be installed with <tt>rpm</tt> or <tt>dpkg</tt> in the usual way, e.g.
You need to update some new modules that your newly created kernel requires with XEN.

Please note that often a monholitic kernel is a wise choice as it doesn't necessarilly requires initrd.
$ sudo dpkg -i ../linux-image-<version>_<version>_<arch>.deb

=== Manual Installation ===

If you want to install the kernel manually then you can simply do, as root:

# make modules_install
# make install

This will install the necessary files to <tt>/boot</tt> and <tt>/lib/modules</tt> with no tracking (for this reason it is highly advised to use the <tt>foo-pkg</tt> targets).

Once you have installed you may need to rebuild the initramfs by hand (some distros do this automatically as part of the above steps). The tool to do this is usually Distro dependent, e.g. <tt>dracut</tt> (recent Fedora & Red Hat) <tt>mkinitrd</tt> (Older Fedora & Red Hat) or <tt>mkinitramfs</tt> (Debian & Ubuntu). e.g.:
# mkinitrd -f /boot/initrd-<version>.img <version>
# mkinitramfs <version>

=== Obsolete Debian/Ubuntu <tt>make-kpkg</tt> Method ===

Older versions of Debian/Ubuntu used a tool called `make-kpkg` to both build and package the kernel. However this tool is now obsolete. It is recommended to use the above methods instead.

$ sudo make -j <number_of_cores +1>
$ sudo apt-get install kernel-package fakeroot
$ sudo CONCURRENCY_LEVEL=<number_of_cores +1> make-kpkg clean
$ sudo CONCURRENCY_LEVEL=<number_of_cores +1> fakeroot make-kpkg --initrd --append-to-version=-pv kernel-image kernel-headers
$ sudo dpkg -i ../<linux-image-3.0.XXX.deb>

The first line will make the kernel with the hidden configuration file (your file hopefully). You might have to do this several times because you will encounter errors that will require turning modules off, and start compiling again. It is a good practice to use make clean when you change many modules at a time. The next line is used for dpkg but is not really that important. the sudo fakeroot line will create your ramdisk needed to boot. This is the Debian way of making the image usable this will event copy it to boot but will not update grub.

== Update modules ==
<span id="configure_modules"></span>


You may need to update some new modules that your newly created kernel requires with Xen. Under new enough versions of Xen (e.g. 4.2 and later) the Xen initscripts should take care of this for you.


For older Xen versions you may need to do this yourself by adding the modules to the relevant configuration file. Under Debian and Ubuntu style systems this is <tt>/etc/modules</tt>.
<pre><nowiki>
$ sudo vim /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
lp
rtc
# Added these lines
xen-evtchn
xen-gntdev
xen-netback
xen-blkback
xenfs
blktap
</nowiki></pre>


The following modules may be required:
Again this is the Ubuntu way, find a way for your particular distribution to do the same.
xen-evtchn
xen-gntdev
xen-netback
xen-blkback
xenfs
blktap


[[Category:Developers]]
[[Category:Developers]]
[[Category:Xen]]
[[Category:PVOPS]]

Latest revision as of 19:06, 26 January 2017

Getting the Current Stable Version

The current kernel tarballs are linked from the front page of kernel.org. For stable use it is recommended that you use the latest "stable" point release. Alternatively you can clone from the stable git tree at git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git (gitweb).

Getting the Current Development Version

There are two main development trees which are interesting to Xen users/developers.

Mainline Kernel

The first is Linus Torvald's mainline git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (gitweb).

This tree has only one active branch, master, but also contains tags for each release and release candidate which can be useful for providing a more concrete baseline for a test or bug report than whatever the current tip happens to be.

Xen Development Tree

The second is xentip tree which is where most day-to-day Xen development work ends up en route to Linus' tree. xentip's tree can be found at git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git (gitweb).

The repository has numerous topic branches to track individual lines of development, and a couple of roll-up branches which contain everything merged together for easy compilation and running.

NOTE! All active git branches require at least Xen 4.0.1, using older version (4.0.0 or older) will cause problems, xend not starting, etc.

Current active branches are:

  • linux-next - patches that are queued up to go to Linus Torvald's tree. This includes bug-fixes, new features, etc.

Using git

The primary version control system used for Linux kernel development is git. There are numerous git HOWTOs on the web, we only cover the very basics here. For more information on git see:

To clone Linus' tree:

   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
   $ cd linux

To clone xentip's tree:

   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux
   $ cd linux

This will automatically check out the 'origin/master' default branch.

If you are using xentip's tree then you most probably want to use the linux-next branch:

   $ git reset --hard
   $ git checkout -b xen-next origin/linux-next
   Branch xen-next set up to track remote branch refs/remotes/origin/linux-next
   Switched to a new branch "xen-next"
   $ git pull
   $ git log | less

Later when you want to update the tree use:

   $ git pull

Configuring the Kernel

Configure as normal; you can start with your current .config file or use make defconfig ("make multi_v7_defconfig for ARM32) and then:

   $ make menuconfig

NOTE0: For x86, make sure you have correct CPU type (Processor Family) set in the kernel configuration, Xen Dom0 options won't show up at all if you have too old CPU selected (too old means a CPU that doesn't support PAE; Pentium Pro was the first CPU to have PAE).

NOTE1: For x86, if you're building 32 bit version of the kernel, you first need to enable PAE support, since Xen only supports 32 bit PAE kernels nowadays. Xen kernel build options won't show up at all before you've enabled PAE for 32 bit builds (Processor type and features -> High Memory Support (64GB) -> PAE (Physical Address Extension) Support). PAE is not needed for 64 bit kernels.

Configuring the Kernel for domU Support

  1. If building x86 32 bit kernel make sure you have CONFIG_X86_PAE enabled (which is set by selecting CONFIG_HIGHMEM64G)
    • non-PAE mode doesn't work in 2.6.25, and has been dropped altogether from 2.6.26 and newer kernel versions.
  2. For x86 , enable these core options (Processor type and features| Paravirtualized guest support]
    • CONFIG_HYPERVISOR_GUEST=y (3.10+ only)
    • CONFIG_PARAVIRT=y
    • CONFIG_XEN=y
    • CONFIG_PARAVIRT_GUEST=y
    • CONFIG_PARAVIRT_SPINLOCKS=y
  3. For ARM, enable these core options (Kernel Features)
    • CONFIG_XEN=y
    • CONFIG_PARAVIRT=y
  4. And Xen pv console device support (Device Drivers|Character devices
    • CONFIG_HVC_DRIVER=y
    • CONFIG_HVC_XEN=y
  5. And Xen disk and network support (Device Drivers|Block devices and Device Drivers|Network device support)
    • CONFIG_XEN_FBDEV_FRONTEND=y
    • CONFIG_XEN_BLKDEV_FRONTEND=y
    • CONFIG_XEN_NETDEV_FRONTEND=y
  6. And the rest (Device Drivers|Xen driver support)
    • CONFIG_XEN_PCIDEV_FRONTEND=y
    • CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
    • CONFIG_XEN_FBDEV_FRONTEND=y
    • CONFIG_XEN_XENBUS_FRONTEND=y
    • CONFIG_XEN_SAVE_RESTORE=y
    • CONFIG_XEN_GRANT_DEV_ALLOC=m
  7. And for tmem support (x86 only):
    • CONFIG_XEN_TMEM=y
    • CONFIG_CLEANCACHE=y
    • CONFIG_FRONTSWAP=y
    • CONFIG_XEN_SELFBALLOONING=y

Configuring the Kernel for dom0 Support

NOTE: Xen dom0 support depends on ACPI support. Make sure you enable ACPI support or you won't see Dom0 options at all.

In addition to the config options above you also need to enable:

  • CONFIG_XEN_DOM0=y
  • CONFIG_XEN_DEV_EVTCHN=y
  • CONFIG_XENFS=y
  • CONFIG_XEN_COMPAT_XENFS=y
  • CONFIG_XEN_SYS_HYPERVISOR=y
  • CONFIG_XEN_GNTDEV=y
  • CONFIG_XEN_BACKEND=y
  • CONFIG_XEN_NETDEV_BACKEND=m
  • CONFIG_XEN_BLKDEV_BACKEND=m
  • CONFIG_XEN_BALLOON=y
  • CONFIG_XEN_SCRUB_PAGES=y

For x86, you will also need to enable:

  • CONFIG_X86_IO_APIC=y
  • CONFIG_ACPI=y
  • CONFIG_ACPI_PROCFS=y (optional)
  • CONFIG_PCI_XEN=y
  • CONFIG_XEN_PCIDEV_BACKEND=m

If you're using RHEL5 or CentOS5 as a dom0 (ie. you have old udev version), make sure you enable the following options as well:

  • CONFIG_SYSFS_DEPRECATED=y
  • CONFIG_SYSFS_DEPRECATED_V2=y

For more current Xen related config options check the example .config files from the troubleshooting section, and check the 2.6.18-to-2.6.31-and-higher wiki page.

Building the kernel

After having downloaded and configured the kernel source as above building the kernel is as simple as:

   $ make all -j <2*number_of_cores>

The -j option tells make how many threads to use, a good number is something like twice the number of processor cores in your system since this allows for I/O (e.g. reading the code from disk) to be interleaved with processing (e.g. compiling the code).

Installing the Kernel

The foo-pkg Targets

The kernel contains several makefile targets which can create packages in various formats. These packages include a baseline level of integration with the relevant distros (although not likely to be as good as the distros own packages they are good enough). Even if the distro integration is lacking simply being able to cleanly uninstall the package is a big advantage.

The full list of package targets can be found in the output of make help:

   $ make help
   [...]
   Kernel packaging:
     rpm-pkg             - Build both source and binary RPM kernel packages
     binrpm-pkg          - Build only the binary kernel package
     deb-pkg             - Build the kernel as a deb package
     tar-pkg             - Build the kernel as an uncompressed tarball
     targz-pkg           - Build the kernel as a gzip compressed tarball
     tarbz2-pkg          - Build the kernel as a bzip2 compressed tarball
     tarxz-pkg           - Build the kernel as a xz compressed tarball
     perf-tar-src-pkg    - Build perf-3.8.0-rc2.tar source tarball
     perf-targz-src-pkg  - Build perf-3.8.0-rc2.tar.gz source tarball
     perf-tarbz2-src-pkg - Build perf-3.8.0-rc2.tar.bz2 source tarball
     perf-tarxz-src-pkg  - Build perf-3.8.0-rc2.tar.xz source tarball

The most interesting targets are the rpm-pkg, binrpm-pkg and deb-pkg targets which cover a wide variety of distros. To use simply invoke with make:

   $ make deb-pkg

Once this command has completed you should find a suitable package in the parent directory which can be installed with rpm or dpkg in the usual way, e.g.

   $ sudo dpkg -i ../linux-image-<version>_<version>_<arch>.deb

Manual Installation

If you want to install the kernel manually then you can simply do, as root:

   # make modules_install
   # make install

This will install the necessary files to /boot and /lib/modules with no tracking (for this reason it is highly advised to use the foo-pkg targets).

Once you have installed you may need to rebuild the initramfs by hand (some distros do this automatically as part of the above steps). The tool to do this is usually Distro dependent, e.g. dracut (recent Fedora & Red Hat) mkinitrd (Older Fedora & Red Hat) or mkinitramfs (Debian & Ubuntu). e.g.:

   # mkinitrd -f /boot/initrd-<version>.img <version>
   # mkinitramfs <version>

Obsolete Debian/Ubuntu make-kpkg Method

Older versions of Debian/Ubuntu used a tool called `make-kpkg` to both build and package the kernel. However this tool is now obsolete. It is recommended to use the above methods instead.

   $ sudo make -j <number_of_cores +1>
   $ sudo apt-get install kernel-package fakeroot
   $ sudo CONCURRENCY_LEVEL=<number_of_cores +1> make-kpkg clean
   $ sudo CONCURRENCY_LEVEL=<number_of_cores +1> fakeroot make-kpkg --initrd --append-to-version=-pv kernel-image kernel-headers
   $ sudo dpkg -i ../<linux-image-3.0.XXX.deb>

The first line will make the kernel with the hidden configuration file (your file hopefully). You might have to do this several times because you will encounter errors that will require turning modules off, and start compiling again. It is a good practice to use make clean when you change many modules at a time. The next line is used for dpkg but is not really that important. the sudo fakeroot line will create your ramdisk needed to boot. This is the Debian way of making the image usable this will event copy it to boot but will not update grub.

Update modules

You may need to update some new modules that your newly created kernel requires with Xen. Under new enough versions of Xen (e.g. 4.2 and later) the Xen initscripts should take care of this for you.

For older Xen versions you may need to do this yourself by adding the modules to the relevant configuration file. Under Debian and Ubuntu style systems this is /etc/modules.

The following modules may be required:

   xen-evtchn
   xen-gntdev
   xen-netback
   xen-blkback
   xenfs
   blktap