kvm-kmod.git

This is a small git repository for the kvm external module kit. It includes a submodule link to the kernel tree, so when you check out the repository, it also checks out a kernel tree for a specific revision. This way the various scripts and the kernel source are always synchronized.

$ git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
$ git submodule init
$ git submodule update
$ ./configure
$ make sync
$ make

Todo:

- add maint branches
- automatic 'make sync'? perhaps replace by symlimks?
- add release script

hi,
i see this big reorganization of the sources (which is good), but does it means that there will be separate tarball releases for kvm-kmod and kvm userspace (which can be compiled without other tarball and git commands)?
if yes, it means there'll be one kvm-kmod tarball or for each kernel there will be a different tarball?
thanks

This is a small git repository for the kvm external module kit. It includes a submodule link to the kernel tree, so when you check out the repository, it also checks out a kernel tree for a specific revision. This way the various scripts and the kernel source are always synchronized.

$ git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
$ git submodule init
$ git submodule update
$ ./configure
$ make sync
$ make

Todo:

- add maint branches
- automatic 'make sync'? perhaps replace by symlimks?
- add release script

Configure spits out an error about include/asm not existing. I think that make sync has to be run before configure to create the include directory and copy asm-x86 inside so that "ln -sf asm-"$karch" include/asm" will work.

This is a small git repository for the kvm external module kit.

Quoted 2 lines · Avi Kivity

This is a small git repository for the kvm external module kit.

So, I am building on a host with CONFIG_KVM_TRACE set in its kernel, but I run configure without enabling kvm trace. As a result the module fails to link:

WARNING: "kvm_trace_ioctl" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!
WARNING: "kvm_trace_cleanup" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!

I think you need to undef CONFIG_KVM_TRACE somewhere to override the value set in autoconf.h?

Quoted 12 lines · Michael S. Tsirkin

Quoted 2 lines · Avi Kivity

This is a small git repository for the kvm external module kit.

So, I am building on a host with CONFIG_KVM_TRACE set in its kernel, but I run configure without enabling kvm trace. As a result the module fails to link:

WARNING: "kvm_trace_ioctl" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!
WARNING: "kvm_trace_cleanup" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!

Quoted 3 lines

I think you need to undef CONFIG_KVM_TRACE somewhere to override the value set in autoconf.h?

Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the two options independent.

Quoted 2 lines

Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the two options independent.

You decide.

I also wonder what happens if one tries to build on a machine with kvm built into kernel. Ideally one would get a clear error message.

Quoted 5 lines · Michael S. Tsirkin

Quoted 3 lines

Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the
two options independent.

You decide.

Well, I think it's less confusing.

Quoted 6 lines · Avi Kivity

Quoted 4 lines · Michael S. Tsirkin

Quoted 4 lines

Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the
two options independent.

Quoted 4 lines

Quoted 2 lines

You decide.

Well, I think it's less confusing.

Fine. Patch?

Quoted 5 lines · Michael S. Tsirkin

Quoted 3 lines

Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the two options independent.

You decide.

Well, I think it's less confusing.

Quoted 4 lines

I also wonder what happens if one tries to build on a machine with kvm built into kernel. Ideally one would get a clear error message.

kvm-kmod is really designed for those running on pre-kvm distro kernels, and for those testing newer kvm versions on distro kernels. If you can compile your own kernel, download kvm.git and run that.

Quoted 7 lines

Quoted 5 lines

I also wonder what happens if one tries to build on a machine with kvm built into kernel. Ideally one would get a clear error message.

kvm-kmod is really designed for those running on pre-kvm distro kernels, and for those testing newer kvm versions on distro kernels. If you can compile your own kernel, download kvm.git and run that.

So no way of having kvm-kmod sync in kvm.git bits and still build against the current running kernel?

I wanted to test out 2.6.29-maint kernel modules and in kvm-userspace/kernel, I could checkout maint/2.6.29 in kvm.git and then make LINUX= sync. I couldn't quite figure out how to do that with kvm-kmod since when I do a ./configure --kerneldir -- it's building modules *for* whatever kernel is at kerneldir rather than just syncing in the kvm bits from that kerneldir and then building modules against the running kernel.

The reason I'm digging is that I'm seeing 64-bit migration failing on maint/2.6.29 kvm modules, but not on upstream kvm kernel bits and I wanted to bisect to find where 64-bit migration is fixed so I can suggest what to pull into maint/2.6.29.

Quoted 5 lines · Ryan Harper

Quoted 5 lines

Quoted 5 lines

I also wonder what happens if one tries to build on a machine with kvm built into kernel. Ideally one would get a clear error message.

Quoted 8 lines

Quoted 4 lines

kvm-kmod is really designed for those running on pre-kvm distro kernels, and for those testing newer kvm versions on distro kernels. If you can compile your own kernel, download kvm.git and run that.

So no way of having kvm-kmod sync in kvm.git bits and still build against the current running kernel?

We must be miscommunicating, what you describe is kvm-kmod.git's sole purpose in life.

Quoted 8 lines

I wanted to test out 2.6.29-maint kernel modules and in kvm-userspace/kernel, I could checkout maint/2.6.29 in kvm.git and then make LINUX= sync. I couldn't quite figure out how to do that with kvm-kmod since when I do a ./configure --kerneldir -- it's building modules *for* whatever kernel is at kerneldir rather than just syncing in the kvm bits from that kerneldir and then building modules against the running kernel.

'make sync' will copy the kvm bits from the linux-2.6 directory, or $(LINUX) if you specify that to make.

So:
LINUX= is for the kvm sources (further controlled by whatever branch
is checked out)
--kerneldir= is for the host kernel

Quoted 6 lines

The reason I'm digging is that I'm seeing 64-bit migration failing on maint/2.6.29 kvm modules, but not on upstream kvm kernel bits and I wanted to bisect to find where 64-bit migration is fixed so I can suggest what to pull into maint/2.6.29.

Thanks, that's helpful. How does it fail? maybe I can supply an educated guess.

Quoted 5 lines

So:
LINUX= is for the kvm sources (further controlled by whatever branch
is checked out)
--kerneldir= is for the host kernel

Ah, excellent, I didn't see it documented on the Code page of the wiki and I blindly assumed that it went away. Thanks for correction.

Quoted 8 lines

Quoted 6 lines

The reason I'm digging is that I'm seeing 64-bit migration failing on maint/2.6.29 kvm modules, but not on upstream kvm kernel bits and I wanted to bisect to find where 64-bit migration is fixed so I can suggest what to pull into maint/2.6.29.

Thanks, that's helpful. How does it fail? maybe I can supply an educated guess.

Migration succeeds, but source and target are frozen (though monitor of guest is still interactive.

Nothing interesting in host dmesg, and of course no output from either guest (they seemed locked). Reproduced this sort of hang for any number of guests (RHEL4u7/8, SLES10 SP2, SLES11, Win2k3-r2, win2k8, etc.) as long as they are 64-bit

Quoted 5 lines · Ryan Harper

Quoted 5 lines

Quoted 5 lines

I also wonder what happens if one tries to build on a machine with kvm built into kernel. Ideally one would get a clear error message.

Quoted 8 lines

Quoted 4 lines

kvm-kmod is really designed for those running on pre-kvm distro kernels, and for those testing newer kvm versions on distro kernels. If you can compile your own kernel, download kvm.git and run that.

So no way of having kvm-kmod sync in kvm.git bits and still build against the current running kernel?

We must be miscommunicating, what you describe is kvm-kmod.git's sole purpose in life.

Quoted 8 lines

I wanted to test out 2.6.29-maint kernel modules and in kvm-userspace/kernel, I could checkout maint/2.6.29 in kvm.git and then make LINUX= sync. I couldn't quite figure out how to do that with kvm-kmod since when I do a ./configure --kerneldir -- it's building modules *for* whatever kernel is at kerneldir rather than just syncing in the kvm bits from that kerneldir and then building modules against the running kernel.

'make sync' will copy the kvm bits from the linux-2.6 directory, or $(LINUX) if you specify that to make.

So:
LINUX= is for the kvm sources (further controlled by whatever branch
is checked out)
--kerneldir= is for the host kernel

% cd kvm
% git checkout -f 2.6.29-stable origins/maint/2.6.29 % cd ../kvm-kmod.git
% ./configure
% make LINUX=../kvm sync
./sync -v kvm-devel -l ../kvm
Traceback (most recent call last):
File "./sync", line 207, in <module>
source_sync(arch)
File "./sync", line 200, in source_sync
hack(T, arch, i)
File "./sync", line 123, in hack

    _hack(T + '/' + file, arch)

File "./sync", line 114, in _hack
data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'source/timer.c'
make: *** [sync] Error 1

kvm.git on branch kvm-85:
% make LINUX=/home/rharper/work/git/kvm sync
./sync -v kvm-devel -l /home/rharper/work/git/kvm
Traceback (most recent call last):
File "./sync", line 207, in <module>
source_sync(arch)
File "./sync", line 200, in source_sync
hack(T, arch, i)
File "./sync", line 123, in hack

    _hack(T + '/' + file, arch)

File "./sync", line 114, in _hack
data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'source/eventfd.c'
make: *** [sync] Error 1

kvm.git on branch kvm-86:
% make LINUX=/home/rharper/work/git/kvm sync
./sync -v kvm-devel -l /home/rharper/work/git/kvm
Traceback (most recent call last):
File "./sync", line 207, in <module>
source_sync(arch)
File "./sync", line 200, in source_sync
hack(T, arch, i)
File "./sync", line 123, in hack

    _hack(T + '/' + file, arch)

File "./sync", line 114, in _hack
data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'source/eventfd.c'
make: *** [sync] Error 1

only branch master seems to work with kvm-kmod

Quoted 20 lines · Ryan Harper

% cd kvm
% git checkout -f 2.6.29-stable origins/maint/2.6.29 % cd ../kvm-kmod.git
% ./configure
% make LINUX=../kvm sync
./sync -v kvm-devel -l ../kvm
Traceback (most recent call last):
File "./sync", line 207, in <module>
source_sync(arch)
File "./sync", line 200, in source_sync
hack(T, arch, i)
File "./sync", line 123, in hack
_hack(T + '/' + file, arch)
File "./sync", line 114, in _hack
data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'source/timer.c'
make: *** [sync] Error 1

Quoted 3 lines

only branch master seems to work with kvm-kmod

Well there are differences in the source trees, so they need different hacking. There is a branch for 2.6.30 in kvm-kmod.git, but 2.6.29 is slightly different and doesn't have a branch. You can just remove the offending files from ./sync, there's a good chance it will work.

though it would be nice to have something to indicate the version we synced, right now all modules that are built this way, dmesg reports:

loaded kvm module (kvm-devel