kvm-kmod-2.6.31.5
This package contains the kvm external modules, using the sources from latest stable Linux release 2.6.31.5. It can be used to update the kernel-side support of kvm without upgrading the host kernel.
This release has been tested on x86 down to host kernel 2.6.27 and builds down to 2.6.24. Building against older kernels is expected to be broken, but if anyone provides patches to fix it, I'm open to merge them.
Enjoy,
Jan
Quoted 7 lines · Jan Kiszka
This package contains the kvm external modules, using the sources from latest stable Linux release 2.6.31.5. It can be used to update the kernel-side support of kvm without upgrading the host kernel.
This release has been tested on x86 down to host kernel 2.6.27 and builds down to 2.6.24. Building against older kernels is expected to be broken, but if anyone provides patches to fix it, I'm open to merge them.
Aww - I'm missing the awesome changelogs :-).
Great to see you take this up Jan!
Alex
Quoted 7 lines · Alexander Graf
Quoted 4 lines · Jan Kiszka
This package contains the kvm external modules, using the sources from latest stable Linux release 2.6.31.5. It can be used to update the kernel-side support of kvm without upgrading the host kernel.
Quoted 6 lines
Quoted 3 lines
This release has been tested on x86 down to host kernel 2.6.27 and builds down to 2.6.24. Building against older kernels is expected to be broken, but if anyone provides patches to fix it, I'm open to merge them.
Aww - I'm missing the awesome changelogs :-).
Your wish is my command:
Major KVM changes since kvm-kmod-2.6.30.1:
- MSI-X support
- MCE support
- SVM: Reworked&fixed IRQ injection, added NMI injection
- Host security: Limit lapic periodic timer frequency
- Guest security: CPL check on hypercalls and debug register access
- x86 emulator: lcall and soft INT support, interrupt shadow handling
- Guest migration fixes
(I probably missed some more important stuff)
Major kvm-kmod changes:
- Reanimated support down to 2.6.24 hosts
- Fixed building against out-of-tree kernel builds / split kernels
- udev script with auto-modprobe on boot
- Installation fixes (DESTDIR)
Wanted to attach this information to the tarball as well, but sourceforge's FRS is still in a almost completely broken state. Sigh.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 3 lines · Jan Kiszka
Wanted to attach this information to the tarball as well, but sourceforge's FRS is still in a almost completely broken state. Sigh.
It can be done - upload the changelog file, make it as a changelog, and then go to the tarball and link the newly marked changelog.
Messy.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 7 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
Wanted to attach this information to the tarball as well, but sourceforge's FRS is still in a almost completely broken state. Sigh.
It can be done - upload the changelog file, make it as a changelog, and then go to the tarball and link the newly marked changelog.
Unless the web interface refuses to work with my Firefox (interestingly, it works with IE6 under Windows?!) and the shell access reports the frs folder as detached.
Quoted 3 lines
Messy.
Indeed, beside the bugs, the new concept looks like a step backward: You now have to download the changelog to view it.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 4 lines
This release has been tested on x86 down to host kernel 2.6.27 and builds down to 2.6.24. Building against older kernels is expected to be broken, but if anyone provides patches to fix it, I'm open to merge them.
I am still not able to build with our 2.6.24 kernel.
./sync -v kvm-kmod-2.6.31.5 -l /path/to/kernel/linux-2.6.24-openvz Traceback (most recent call last):
File "./sync", line 247, in <module>
header_sync(arch)
File "./sync", line 219, in header_sync
hack(T, arch, 'include/asm-%(arch)s/kvm.h' % { 'arch': arch })
File "./sync", line 158, in hack
_hack(T + '/' + file, arch) File "./sync", line 149, in _hack
data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'header/include/asm-x86/kvm.h'
The files required are simply not in the correct location. But it seem that make sync (after manually change paths and remove non-existing files) does not change a single file anyways for kernel 2.6.24?
So I can simply skip 'make sync'?
But when I run make I get the following error:
/home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod-2.6.31.5/x86/external-module-compat.h:93: error: redefinition of "native_read_tsc" include/asm/msr.h:230: error: previous definition of "native_read_tsc" was here
if fact, it is defined in msr.h too:
static inline unsigned long long native_read_tsc(void)
{
unsigned long long val;
rdtsc_barrier();
asm volatile("rdtsc" : "=A" (val));
rdtsc_barrier();
return val;
}and in external-module-compat.h:
static inline unsigned long long native_read_tsc(void)
{
unsigned long long val;
asm volatile("rdtsc" : "=A" (val));
return val;
}And I compile on 64bit. So what is the correct version?
- Dietmar
Quoted 15 lines · Dietmar Maurer
Quoted 4 lines
This release has been tested on x86 down to host kernel 2.6.27 and builds down to 2.6.24. Building against older kernels is expected to be broken, but if anyone provides patches to fix it, I'm open to merge them.
I am still not able to build with our 2.6.24 kernel.
./sync -v kvm-kmod-2.6.31.5 -l /path/to/kernel/linux-2.6.24-openvz Traceback (most recent call last):
File "./sync", line 247, in <module>
header_sync(arch)
File "./sync", line 219, inheader_synchack(T, arch, 'include/asm-%(arch)s/kvm.h' % { 'arch': arch }) File "./sync", line 158, in hack _hack(T + '/' + file, arch)
Quoted 8 lines
File "./sync", line 149, in
_hack
data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'header/include/asm-x86/kvm.h'The files required are simply not in the correct location. But it seem that make sync (after manually change paths and remove non-existing files) does not change a single file anyways for kernel 2.6.24?
So I can simply skip 'make sync'?
The release tarball contains all required sources (as described, they were obtained from 2.6.31.5). So you do have to sync, just run configure && make. And you definitely *must not* sync against 2.6.24 or any other older kernel.
Quoted 21 lines
But when I run make I get the following error:
/home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod-2.6.31.5/x86/external-module-compat.h:93: error: redefinition of "native_read_tsc"include/asm/msr.h:230: error: previous definition of "native_read_tsc" was hereif fact, it is defined in
msr.htoo:static inline unsigned long long
native_read_tsc(void){ unsigned long long val; rdtsc_barrier(); asm volatile("rdtsc" : "=A" (val)); rdtsc_barrier(); return val; }and in
external-module-compat.h:
Quoted 8 lines
static inline unsigned long long
native_read_tsc(void){ unsigned long long val; asm volatile("rdtsc" : "=A" (val)); return val; }And I compile on 64bit. So what is the correct version?
I'm running a 64-bit 2.6.24 kernel [1] against the stable branch, but I may have missed some constellation. Please send me your .config (provided you get this error with a clean kvm-kmod-2.6.31.5).
Jan
[1] http://buildbot.kiszka.org/kvm-kmod/waterfall?show=stable-2.6.31
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Well, we use the ubuntu tree:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary
They have a few more patches applied:
Seems the last two patches cause the problem.
I just wonder if we need those bariers or not?
- Dietmar
Quoted 87 lines
-----Original Message-----
From: Jan Kiszka [mailto:[email protected]]
Sent: Mittwoch, 28. Oktober 2009 12:55
To: Dietmar Maurer
Cc: kvm
Subject: Re: [ANNOUNCE] kvm-kmod-2.6.31.5Quoted 2 lines · Dietmar Maurer
Quoted 2 lines
This release has been tested on x86 down to host kernel 2.6.27 and builds down to 2.6.24. Building against older kernels is expected to
be
Quoted 10 lines
Quoted 2 lines
broken, but if anyone provides patches to fix it, I'm open to merge them.
I am still not able to build with our 2.6.24 kernel.
./sync -v kvm-kmod-2.6.31.5 -l /path/to/kernel/linux-2.6.24-openvz Traceback (most recent call last):
File "./sync", line 247, in <module>
header_sync(arch)
File "./sync", line 219, inheader_syncQuoted 6 lines
hack(T, arch, 'include/asm-%(arch)s/kvm.h' % { 'arch': arch }) File "./sync", line 158, in hack _hack(T + '/' + file, arch)File "./sync", line 149, in
_hack
data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'header/include/asm-
x86/kvm.h'Quoted 3 lines
The files required are simply not in the correct location. But it
seem that make sync (after manually change paths and remove non- existing files) does not change a single file anyways for kernel 2.6.24?
Quoted 2 lines
So I can simply skip 'make sync'?
The release tarball contains all required sources (as described, they were obtained from 2.6.31.5). So you do have to sync, just run configure
&& make. And you definitely *must not* sync against 2.6.24 or any other older kernel.Quoted 4 lines
But when I run make I get the following error:
/home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod-
2.6.31.5/x86/external-module-compat.h:93: error: redefinition of "native_read_tsc"Quoted 1 line
include/asm/msr.h:230: error: previous definition of"
native_read_tsc" was hereQuoted 16 lines
if fact, it is defined in
msr.htoo:static inline unsigned long long
native_read_tsc(void){ unsigned long long val; rdtsc_barrier(); asm volatile("rdtsc" : "=A" (val)); rdtsc_barrier(); return val; }and in
external-module-compat.h:Quoted 8 lines
static inline unsigned long long
native_read_tsc(void){ unsigned long long val; asm volatile("rdtsc" : "=A" (val)); return val; }And I compile on 64bit. So what is the correct version?
I'm running a 64-bit 2.6.24 kernel [1] against the stable branch, but I may have missed some constellation. Please send me your .config (provided you get this error with a clean kvm-kmod-2.6.31.5).
Jan
[1] http://buildbot.kiszka.org/kvm-kmod/waterfall?show=stable-2.6.31
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Quoted 6 lines · Dietmar Maurer
Well, we use the ubuntu tree:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary
They have a few more patches applied:
Quoted 7 lines
Seems the last two patches cause the problem.
I just wonder if we need those bariers or not?
The barrier is not our problem regarding the kvm-kmod build, it's the addition of native_read_tsc
(http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=d10247b31c2be39ab3109015bc99bbd2ba6554d4).
Do you know if there is anything to tell this ubuntu-patched kernel apart from a vanilla version? If so, we could adjust the check in x86/external-module-compat.h to avoid this breakage. Locally, you could simply comment out the double definition for now.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 3 lines
Do you know if there is anything to tell this ubuntu-patched kernel apart from a vanilla version? If so, we could adjust the check in
x86/external-module-compat.hto avoid this breakage.
no, not really
Quoted 2 lines
Locally, you could
simply comment out the double definition for now.
Yes, that will work. Many thanks for the fast help!
- Dietmar
Quoted 5 lines · Dietmar Maurer
Quoted 3 lines
Do you know if there is anything to tell this ubuntu-patched kernel apart from a vanilla version? If so, we could adjust the check in
x86/external-module-compat.hto avoid this breakage.no, not really
OK, but I think I have a plan B. The next kvm-kmod release should handle this case gracefully.
Quoted 6 lines
Quoted 3 lines
Locally, you could
simply comment out the double definition for now.Yes, that will work. Many thanks for the fast help!
Is native_read_tsc the only conflict with hardy's kernel?
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Locally, you could
simply comment out the double definition for now.Yes, that will work. Many thanks for the fast help!
Is
native_read_tscthe only conflict with hardy's kernel?
yes.
Quoted 8 lines · Dietmar Maurer
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
Locally, you could
simply comment out the double definition for now.Yes, that will work. Many thanks for the fast help!
Is
native_read_tscthe only conflict with hardy's kernel?yes.
Then you may want to have a look at [1]. If you want to test it, apply that commit to your tree and patch native_read_tsc to kvm_native_read_tsc in svm.c.
Jan
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Dietmar Maurer
Quoted 3 lines
Quoted 1 line
So I can simply skip 'make sync'?
The release tarball contains all required sources (as described, they were obtained from 2.6.31.5). So you do have to sync,
So I need to run 'make sync'?
Ouch. Of course I meant "you do *not* have to sync".
Practically, there is no reason to re-sync when you have the release tarball in hands. 'make sync' is a developer tool when working with the git version of kvm-kmod and/or dragging in brand new kvm kernel sources.
Sorry for the confusion.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux