Blue Swirl wrote: > On 6/6/09, Jan Kiszka wrote: >> Blue Swirl wrote: >> > On 6/6/09, Avi Kivity wrote: >> >> Andreas Färber wrote: >> >> >> >>> Or as another example, I've been unable to try KVM with svn/git QEMU >> >> because new capability defines keep being added that block compiling QEMU >> >> with KVM from any mainstream distribution. With nobody here being able to >> >> recommend a working distribution, that makes KVM a moot alternative, >> >> especially on systems you can't install your own kernel modules on. I just >> >> hope that Fedora 11 will let me try it. >> >> Try qemu-kvm.git, that should compile and run on almost anything (and is a >> >> lot faster and more featureful than kvm support in qemu.git). >> > >> > Maybe the backwards compatibility features should be ported to QEMU? >> > For example, is there a workaround for >> > #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS >> > ? >> >> >> Given that we have always-up-to-date kvm-kmod packages with support down >> to reasonable kernel versions, I would prefer to keep upstream clean >> from old workarounds. They should only be needed for issues found very >> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in >> the future. > > But then I (and from Andreas' message I gather that many others) can't > test KVM support on QEMU without building, installing and maintaining > (updating, rebuilding, reinstalling etc) my own kernel instead of the > distro build. You don't have to, it builds against the distro kernel's devel package (I'm doing most KVM development on boring distro kernels). No black magic involved. Really. > > Does this also mean that KVM stuff in QEMU releases will not be usable > for anyone (except those building their own kernels) until distros > upgrade to a compatible kernel version a few years later? In a year from now, you won't need any of todays workarounds on a then up-to-date distro kernel. And given that not only bug fixes come with kvm-kmod but also feature enhancements, updating the in-kernel kvm modules that way will likely remain a valid use case even after that point. Jan