Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Avi Kivity on 18 Mar 2010 09:20 On 03/18/2010 03:02 PM, Ingo Molnar wrote: > >> [...] What users eagerly replace their kernels? >> > Those 99% who click on the 'install 193 updates' popup. > > Of which 1 is the kernel, and 192 are userspace updates (of which one may be qemu). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jes Sorensen on 18 Mar 2010 09:30 On 03/18/10 11:58, Ingo Molnar wrote: > > * Jes Sorensen<Jes.Sorensen(a)redhat.com> wrote: >> Thats a very glorified statement but it's not reality, sorry. You can do >> that with something like perf because it's so small and development of perf >> is limited to a very small group of developers. > > I was not talking about just perf: i am also talking about the arch/x86/ > unification which is 200+ KLOC of highly non-trivial kernel code with hundreds > of contributors and with 8000+ commits in the past two years. Sorry but you cannot compare merging two chunks of kernel code that originated from the same base, with the efforts of mixing a large userland project with a kernel component. Apples and oranges. > Also, it applies to perf as well: people said exactly that a year ago: 'perf > has it easy to be clean as it is small, once it gets as large as Oprofile > tooling it will be in the same messy situation'. > > Today perf has more features than Oprofile, has a larger and more complex code > base, has more contributors, and no, it's not in the same messy situation at > all. Both perf and oprofile are still relatively small projects in comparison to QEMU. > So whatever you think of large, unified projects, you are quite clearly > mistaken. I have done and maintained through two different types of > unifications and the experience was very similar: both developers and users > (and maintainers) are much better off. You believe that I am wrong in my assessment of unified projects, and I obviously think you are mistaken and underestimating the cost and effects of trying to merge the two. Well I think we are just going to agree to disagree on this one. I am not against merging projects where it makes sense, but in this particular case I am strongly convinced the loss would be much greater than the gain. Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 18 Mar 2010 09:40 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/18/2010 03:02 PM, Ingo Molnar wrote: > > > >> [...] What users eagerly replace their kernels? > > > > Those 99% who click on the 'install 193 updates' popup. > > > > Of which 1 is the kernel, and 192 are userspace updates (of which one may be > qemu). I think you didnt understand my (tersely explained) point - which is probably my fault. What i said is: - distros update the kernel first. Often in stable releases as well if there's a new kernel released. (They must because it provides new hardware enablement and other critical changes they generally cannot skip.) - Qemu on the other hand is not upgraded with (nearly) that level of urgency. Completely new versions will generally have to wait for the next distro release. With in-kernel tools the kernel and the tooling that accompanies the kernel are upgraded in the same low-latency pathway. That is a big plus if you are offering things like instrumentation (which perf does), which relates closely to the kernel. Furthermore, many distros package up the latest -git kernel as well. They almost never do that with user-space packages. Let me give you a specific example: I'm running Fedora Rawhide with 2.6.34-rc1 right now on my main desktop, and that comes with perf-2.6.34-0.10.rc1.git0.fc14.noarch. My rawhide box has qemu-kvm-0.12.3-3.fc14.x86_64 installed. That's more than a 1000 Qemu commits older than the latest Qemu development branch. So by being part of the kernel repo there's lower latency upgrades and earlier and better testing available on most distros. You made it very clear that you dont want that, but please dont try to claim that those advantages do not exist - they are very much real and we are making good use of it. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 18 Mar 2010 09:40 On 03/18/2010 03:00 PM, Ingo Molnar wrote: > * Avi Kivity<avi(a)redhat.com> wrote: > > >> On 03/18/2010 01:48 PM, Ingo Molnar wrote: >> >> >>>> It's not inevitable, if the projects are badly run, you'll have high >>>> latencies, but projects don't have to be badly run. >>>> >>> So the 64K dollar question is, why does Qemu still suck? >>> >> Where people sent patches, it doesn't suck (or sucks less). Where they >> don't, it still sucks. [...] >> > So is your point that the development process and basic code structure does > not matter at all, it's just a matter of people sending patches? I beg to > differ ... > The development process of course matters, and we have worked hard to fix qemu's. Basic code structure also matters, but you don't fix that with cp. >> [...] And it cost way more than $64K. >> >> If moving things to tools/ helps, let's move Fedora to tools/. >> > Those bits of Fedora which deeply relate to the kernel - yes. > Those bits that are arguably separate - nope. > A qemu GUI is not deeply related to the kernel. Or at all. >>>> How is a patch for the qemu GUI eject button and the kvm shadow mmu >>>> related? Should a single maintainer deal with both? >>>> >>> We have co-maintainers for perf that have a different focus. It works >>> pretty well. >>> >> And it works well when I have patches that change x86 core and kvm. But >> that's no longer a single repository and we have to coordinate. >> > Actually, it works much better if, contrary to your proposal it ends up in a > single repo. Last i checked both of us really worked on such a project, run by > some guy. (Named Linus or so.) > Well, when last I sent x86 patches, they went to you and hpa, applied to tip, from which I had to merge them back. Two repositories. After several weeks they did end up in a third repository, Linus'. The process isn't trivial or fast, but it works. >>> Look at git log tools/perf/ and how user-space and kernel-space components >>> interact in practice. You'll patches that only impact one side, but you'll >>> see very big overlap both in contributor identity and in patches as well. >>> >>> Also, let me put similar questions in a bit different way: >>> >>> - ' how is an in-kernel PIT emulation connected to Qemu's PIT emulation? ' >>> >> Both implement the same spec. One is be a code derivative of the other (via >> Xen). >> >> >>> - ' how is the in-kernel dynticks implementation related to Qemu's >>> implementation of hardware timers? ' >>> >> The quality of host kernel timers directly determines the quality of >> qemu's timer emulation. >> >> >>> - ' how is an in-kernel event for a CD-ROM eject connected to an in-Qemu >>> eject event? ' >>> >> Both implement the same spec. The kernel of course needs to handle >> all implementation variants, while qemu only needs to implement it >> once. >> >> >>> - ' how is a new hardware virtualization feature related to being able to >>> configure and use it via Qemu? ' >>> >> Most features (example: npt) are transparent to userspace, some are >> not. When they are not, we introduce an ioctl() to kvm for >> controlling the feature, and a command-line switch to qemu for >> calling it. >> >> >>> - ' how is the in-kernel x86 decoder/emulator related to the Qemu x86 >>> emulator? ' >>> >> Both implement the same spec. Note qemu is not an emulator but a >> binary translator. >> >> >>> - ' how is the performance of the qemu GUI related to the way VGA buffers are >>> mapped and accelerated by KVM? ' >>> >> kvm needs to support direct mapping when possible and efficient data >> transfer when not. The latter will obviously be much slower. When >> direct mapping is possible, kvm needs to track pages touched by the >> guest to avoid full screen redraws. The rest (interfacing to X or >> vnc, implementing emulated hardware acceleration, full-screen mode, >> etc.) are unrelated. >> >> >>> They are obviously deeply related. >>> >> Not at all. [...] >> > You are obviously arguing for something like UML. Fortunately KVM is not that. > Or i hope it isnt. > I am not arguing for UML and don't understand why you think so. >> [...] kvm in fact knows nothing about vga, to take your last >> example. [...] >> > Look at the VGA dirty bitmap optimization a'ka the KVM_GET_DIRTY_LOG ioctl. > > See qemu/kvm-all.c's kvm_physical_sync_dirty_bitmap(). > > It started out as a VGA optimization (also used by live migration) and even > today it's mostly used by the VGA drivers - albeit a weak one. > > I wish there were stronger VGA optimizations implemented, copying the dirty > bitmap is not a particularly performant solution. The VGA dirty bitmap is 256 bytes in length. Copying it doesn't take any time at all. People are in fact working on a copy-less dirty bitmap solution, for live migration of very large memory guests. Expect set_bit_user() patches for tip.git. > (although it's certainly > better than full emulation) Graphics performance is one of the more painful > aspects of KVM usability today. > If you have suggestions for further optimizations (or even patches) I'd love to hear them. One solution we are working on is QXL, a framebuffer-less graphics card designed for spice. The use case is again server based (hosted desktops) but may be adapted for desktop-on-desktop use. >> [...] To suggest that qemu needs to be close to the kernel to benefit from >> the kernel's timer implementation means we don't care about providing >> quality timing except to ourselves, which luckily isn't the case. >> > That is not what i said. I said they are closely related, and where > technologies are closely related, project proximity turns into project > unification at a certain stage. > I really don't see how. So what if both qemu and kvm implement an i8254? They can't share any code since the internal APIs are so different. Even worse for the x86 emulator as qemu and kvm are fundamentally different. Even more with the qemu timers and kernel dyntick code. >> Some time ago the various desktops needed directory change >> notification, and people implemented inotify (or whatever it's >> called today). No one suggested tools/gnome/ and tools/kde/. >> > You are misconstruing and misrepresenting my argument - i'd expect better. > Gnome and KDE runs on other kernels as well and is generally not considered > close to the kernel. > qemu runs on other kernels (including Windows), just without kvm. > Do you seriously argue that Qemu has nothing to do with KVM these days? > The vast majority of qemu has nothing to do with kvm, all the kvm interface bits are in two files. Things like the GUI, the VNC server, IDE emulation, the management interface (the monitor), live migration, qcow2 and ~15 other file format drivers, chipset emulation, USB controller emulation, snapshot support, slirp, serial port emulation, and a zillion other details have nothing to do with kvm. >>> The quality of a development process is not defined by the easy cases >>> where no project unification is needed. The quality of a development >>> process is defined by the _difficult_ cases. >>> >> That's true, but we don't have issues at the qemu/kvm boundary. Note we do >> have issues at the qemu/aio interfaces and qemu/net interfaces (out of which >> vhost-net was born) but these wouldn't be solved by tools/qemu/. >> > That was not what i suggested. They would be solved by what i proposed: > tools/kvm/, right? > If they were, it would be worth it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 18 Mar 2010 09:50
* Frank Ch. Eigler <fche(a)redhat.com> wrote: > Hi - > > > > > [...] > > > > Distributions are very eager to update kernels even in stable periods of the > > > > distro lifetime - they are much less willing to update user-space packages. > > > > [...] > > > > > > Sorry, er, what? What distributions eagerly upgrade kernels in stable > > > periods, were it not primarily motivated by security fixes? [...] > > > > Please check the popular distro called 'Fedora' for example > > I do believe I've heard of it. According to fedora bodhi, there have > been 18 kernel updates issues for fedora 11 since its release, of > which 12 were for purely security updates, and most of the other six > also contain security fixes. None are described as 'enhancement' > updates. Oh, what about fedora 12? 8 updates total, of which 5 are > security only, one for drm showstoppers, others including security > fixes, again 0 tagged as 'enhancement'. > > So where is that "eagerness" again?? My sense is that most users are > happy to leave a stable kernel running as long as possible, and > distributions know this. You surely must understand that the lkml > demographics are different. > > > and its kernel upgrade policies. > > [citation needed] You are quite wrong, despite the sarcastic tone you are attempting to use, and this is distro kernel policy 101. For distros such as Fedora it's simpler to support the same kernel version across many older versions of the distro than having to support different kernel versions. Check Fedora 12 for example. Four months ago it was released with kernel v2.6.31: http://download.fedora.redhat.com/pub/fedora/linux/releases/12/Fedora/x86_64/os/Packages/kernel-2.6.31.5-127.fc12.x86_64.rpm But if you update a Fedora 12 installation today you'll get kernel v2.6.32: http://download.fedora.redhat.com/pub/fedora/linux/updates/12/SRPMS/kernel-2.6.32.9-70.fc12.src.rpm As a result you'll get a new 2.6.32 kernel on Fedora 12. The end result is what i said in the previous mail: that you'll get a newer kernel even on a stable distro - while user-space packages will only be updated if there's a security issue (and even then there's no version jump like for the kernel). > > > [...] What users eagerly replace their kernels? > > > > Those 99% who click on the 'install 193 updates' popup. > > That's not "eager". That's "I'm exasperated from guessing what's really > important; let's not have so many updates; meh". Erm, fact is, 99% [WAG] of the users click on the update button and accept whatever kernel version the distro update offers them. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |