Asdo wrote:
Thanks for your reply,
sorry to get you angry, but there are still things which are not clear to me.

Well, today wasn't my best day.
You're right the documentation on the matter is nearly non-existing.

[]
3) Everyone here mentions to upgrade the userspace part only. That sounds strange to me because in all kernelmode+usermode applications I have seen up to now, the usermode part was just there to drive the kernelmode part (basically parse commandline parameters and communicate them to the kernel) Ok I understand that in KVM also the emulated

In kvm it's the opposite.  Kernel part is very small and the interface
does not change as frequently.  It's basically just a wrapper around
the CPU VT extensions.

[]
But what about stable kernel modules?

Are these the kvm-kmod's?

Yes.

And besides, the versioning of kvm-kmod's are not obvious to me: I see these ones at sourceforge:

2.6.31.5
2.6.30
2.6.30.1
2.6.30-rc8
2.6.30-rc6

I don't undestand why they are numbered like the kernel, that's strange... More specifically, this is the question: If I have a kernel version N, what kvm-kmod can I compile in it? If I can just compile version N, then it's useless because that's identical to the kvm.ko I already had. Or can I compile kvm-kmod 2.6.31.5 in my kernel 2.6.24? That's a strange version numbering... why haven't you used the same numbering as for qemu-kvm?

Because such numbering proved to be confusing, and you are confused by
it too.  The above numbers means just like, kvm-kmod from kernel 2.6.30.1
(say), but "ported" to a wider range of kernels.  kvm-kmod is being
developed as part of kernel.


Btw, 2.6.24 and in fact anything before ~2.6.28 might be problematic for
real kvm usage, due to other parts of the kernel.  Applies to both
host and guest kernels.

/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to