Code

2012-05-16T21:02:47Z

Marcelot:

=Code=

[[Category:Architechture]]

== kernel git tree ==

The kvm kernel code is available through a git tree (like the kernel itself). To create a repository using git, type

git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=virt/kvm/kvm.git;a=summary]

For subsequent upgrades use the command

git pull

in the git working directory.

== kernel git workflow ==

See [[Kvm-Git-Workflow]]

== userspace git tree ==

The kvm userspace code (libkvm and qemu) is available through a git tree. To create a repository using git, type

git clone git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

Alternatively, it is also accessible through the kernel.org gitweb interface:
[http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=summary]

'''If you want to contribute code''', please [http://wiki.qemu.org/Contribute/StartHere develop against qemu.git] and submit patches to qemu-devel@nongnu.org. The qemu-kvm.git tree regularly gets changes from qemu.git and patches against qemu-kvm.git should be minimized.

== building an external module with older kernels ==

'''This only works for the x86 architecture.'''

1. If you wish to use a distribution kernel (or just some random kernel you like) with kvm,
you can use the external module kit. You will need the kvm-kmod repository:

git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
cd kvm-kmod
git submodule update --init
./configure [--kerneldir=/path/to/kernel/dir]
make sync
make

=== Tip about building against Red Hat Enterprise Linux kernels ===

<code>kvm-userspace/kernel</code> has some compat code to allow it to compile against older kernels, and also some code specific to features that are normally not present on older kernels but are present on RHEL kernels.

So, when building against a RHEL kernel tree, check if the <code>RHEL_*</code> macros at <code>${kerneldir}/include/linux/version.h</code> are defined correctly, corresponding to the RHEL version where the kernel source comes from. If those macros aren't defined correctly, the compat code that allows compilation against RHEL kernels will break and you will get build errors.

== release tags ==

kvm stable releases (based off of Qemu's stable branch) are tagged with <code>kvm-qemu-0.NN.N</code> where ''N'' equates to the upstream Qemu branch versions. Note that kvm has them tagged not branched.

kvm development releases are tagged with <code>kvm-nn</code> where ''nn'' is the release number.

== Binary Packages ==

=== CentOS / RHEL ===

Unofficial packages of latest releases can be found at:
<code>http://www.lfarkas.org/linux/packages/centos/5/</code>

=== Debian ===

For Debian Lenny, please use packages from backports.debian.org - for <em>both</em> qemu-kvm and kernel (at least 2.6.32). It is important to use more recent kernel - 2.6.26 does not work well with kvm.

Note that package "kvm" has been renamed to "qemu-kvm" in Squeeze and in Lenny backports (and kvm is now transitional package that installs qemu-kvm automatically).

Debian Squeeze will have qemu-kvm based on 0.12, available in standard repositories.

Experimental 0.13 packages are available at
<code>http://www.corpit.ru/debian/tls/kvm/0.13/</code> , pending upload to debian -experimental.

== nightly snapshots ==

Nightly snapshots, for those who are uncomfortable with git, are [http://people.qumranet.com/avi/snapshots available]. When reporting a problem with a snapshot, please quote the snapshot name (which includes the date) and the contents of the SOURCES file in the snapshot tarball.

Kvm-Git-Workflow

2012-05-16T20:58:37Z

Marcelot: KVM Git Workflow

== New git workflow for kvm.git ==

The old 'master' branch has been abandoned (still available for
reviewing history). The new branch structure will be as follows:

'master': contains patches destined for fixes after the current merge windows; for example, after v3.4 has been released, master contains fixes which will be merged during the 3.4 cycle.

'next': contains patches destined for the next merge window; for
example, if v3.4 has just been released, then 'next' will be based on
the v3.5-rc1 tag (or thereabouts), and will be accepting patches
targeted at the 3.6 merge window (when 3.5 is released).

'queue': holding area for patches which have not been tested yet; may
be rebased; usually merged into 'next'

'kvm-updates/3.x': unchanged, patches destined for a stable branch

Since 'next' is based on an -rc1 release, it may lack upstream non-kvm
fixes (or features) needed for development. To work around that, an
'auto-next' branch will be provided that is a merge of current upstream
and 'next' (this is more or less the equivalent of the old 'master'
branch). That branch of course will be rebased often.

== How to work with the new layout ==

If you're a developer, usually developing against 'next' is okay. If
'next' is unstable for you or you need a new upstream API, work against
'auto-next', but let the maintainers know that when posting your patch.

If you're working on a fix for the current cycle, work against upstream
or 'master' (they should be equivalent most of the time).

If you're a submaintainer, post git pull requests against 'next' or
'master', according to your merge target.

Please ask Avi or Marcelo with any question or suggestion. It's
better to ask a "silly" question than develop against a stale tree
accidentally and waste your efforts.

KVM - User contributions [en]

Code

Kvm-Git-Workflow