Kvm: qemu with option "-enable-kvm" or kvm-84 from AUR?

Question

whats the difference between the two? Which one should be preferred?
thanks!

Answer 1

Yeah, my bad.  The patches to qemu would come from upstream KVM, like they did before.  Avi Kivity, not Tobias.  My mistake there.
And yeah, I think some of those distinctions are us using different semantics.  I'd call the qemu implementation that Avi maintains a fork -- but that is different to me than, as you worded it, kvm being a fork of qemu.  When saying "kvm" and referring to a chunk of code, not what I'll call for this conversation's sake "the kvm project," has always referred to the kvm module -- the kernel code, again hence the name.  Back when the userspace code was just a set of patches to qemu, this confusion was rarer.  (Even after the kvm project started maintaining their own version of the code, they also maintained the qemu patch set to apply to the qemu project -- their version was just qemu, pre-patched.  Avi discusses that philosophy of modifying the original code as little as possible in his most recent blog a few months ago.)  The kvm userspace code is -- again, by Avi's own description -- qemu and libkvm.  (http://www.linux-kvm.org/page/Code - "The kvm userspace code (libkvm and qemu) is available through a git tree.")  kvm-the-project does maintain a prepatched qemu, but that doesn't make it kvm's code -- particularly when kvm's intent all along was to have their patches accepted by qemu, which they now have.  So while you can say that kvm-the-project has within it a build of qemu -- and if you wanted, you could even call it a fork, though the maintainer declines to use the term -- qemu is not kvm.
I'd also add that though the gray area there exists, from a future-discussion perspective it does make things a lot clearer if we refer to kvm the module, the "pure" build of qemu, and kvm's qemu build (or qemu-kvm) as separate.
And by extension, no, kvm-userspace has not reached 10.0.0.  There's a reason that the kvm userspace code just has build numbers.  Its version number is 85.  It would make a lot of sense to say that the kvm-maintained patches were modified and applied to qemu upstream to make qemu 10.0.0, but the post-10 stability patches for kvm were applied independently to qemu and qemu-kvm -- qemu-kvm basically getting just kvm-related stability patches, which are submitted upstream to qemu (and thus qemu-kvm moving up in build number), and qemu using the qemu-kvm patches as well as patches relating to other parts of the system.
Getting back to the meat of the question, it is important to note that the kvm we're getting from the arch package is NOT the kvm that you would get from building the download file.  You called it clean, and you're absolutely right -- it's *too* clean.  Download the KVM package from sourceforge, build, and do a make -n install; you get:
make -C kernel DESTDIR="" install
make -C libkvm DESTDIR="" install
make -C qemu DESTDIR="" install
Which makes sense if you read their docs -- the KVM build, as per KVM, come as a (independent of the kernel) set of modules and a QEMU build to go with those modules, just like it was before it was accepted by linux-kernel.  (You could probably have noticed that kernel modules were being build when you run make, but there was so much stuff in there that I thought it easier to cut/paste the install phase for clarity.)  The Arch PKGBUILD, however, just compiles qemu-kvm and its necessary libraries:
for dir in libkvm user qemu extboot; do
        cd ${srcdir}/kvm-${pkgver}/${dir}
        make || return 1
    done
and then hand-installs those components without the kernel modules meant to go with it.  Unless the package builder knows something the KVM developer doesn't, I wouldn't go around using that qemu build with whatever KVM module version from whatever different kernel version you may have willy-nilly.
If I had the hankering to run the KVM maintained userspace stuff, I'd do what they said and run their kernel stuff too.  I think a proper KVM build should do that.  But that's not my call, since I'm not the extra maintainer.  As it stands, for me I'd rather use the in-kernel version, which I think will get the kernel-side patches that the KVM project's kernel code gets anyway since there is so much attention on the kernel, but also has the benefit of the qemu userspace code getting bug fixes from the qemu devs themselves.  It sounded to me like that was the direction kvm itself was moving.  But to each their own, of course.  I'd just say better to stick all the way with one or all the way with the other method, and not just start making hybrids without a much deeper knowledge of the code than I think any of us have.
Last edited by slinkygn (2009-05-04 02:11:30)