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:50 On 03/18/2010 03:31 PM, Ingo Molnar wrote: > * 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.) > No, they don't. RHEL 5 is still on 2.6.18, for example. Users don't like their kernels updated unless absolutely necessary, with good reason. Kernel updates = reboots. > - 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. > F12 recently updated to 2.6.32. This is probably due to 2.6.31.stable dropping away, and no capacity at Fedora to maintain it on their own. So they are caught in a bind - stay on 2.6.31 and expose users to security vulnerabilities or move to 2.6.32 and cause regressions. Not a happy choice. > 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. > I'm sure if we ask the Fedora qemu maintainer to package qemu-kvm.git they'll consider it favourably. Isn't that what rawhide is for? > 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. > I don't mind at all if rawhide users run on the latest and greatest, but release users deserve a little more stability. -- 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 10:00 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/18/2010 03:31 PM, Ingo Molnar wrote: > >* 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.) > > No, they don't. [...] I just replied to Frank Ch. Eigler with a specific example that shows how this happens - and believe me, it happens. > [...] RHEL 5 is still on 2.6.18, for example. Users > don't like their kernels updated unless absolutely necessary, with > good reason. Nope - RHEL 5 is on a 2.6.18 base for entirely different reasons. > Kernel updates = reboots. If you check the update frequency of RHEL 5 kernels you'll see that it's comparable to that of Fedora. > > - 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. > > F12 recently updated to 2.6.32. This is probably due to 2.6.31.stable > dropping away, and no capacity at Fedora to maintain it on their own. So > they are caught in a bind - stay on 2.6.31 and expose users to security > vulnerabilities or move to 2.6.32 and cause regressions. Not a happy > choice. Happy choice or not, this is what i said is the distro practice these days. (i dont know all the distros that well so i'm sure there's differences) > > 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. > > I'm sure if we ask the Fedora qemu maintainer to package qemu-kvm.git > they'll consider it favourably. Isn't that what rawhide is for? Rawhide is generally for latest released versions, to ready them for the next distro release - with special exception for the kernel, which has a special position due being a hardware-enabler and because it has an extremely predictable release schedule of every 90 days (+- 10 days). Very rarely do distro people jump versions for things like GCC or Xorg or Gnome/KDE, but they've been burned enough times by unexpected delays in those projects to be really loathe to do it. Qemu might get an exception - dunno, you could ask. My point still holds: by hosting KVM user-space bits in the kernel together with the rest of KVM you get version parity - which has clear advantages. You also might have more luck with a bleeding-edge distro such as Gentoo. > >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. > > I don't mind at all if rawhide users run on the latest and greatest, but > release users deserve a little more stability. What are you suggesting, that released versions of KVM are not reliable? Of course any tools/ bits are release engineered just as much as the rest of KVM .... 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: Ingo Molnar on 18 Mar 2010 10:10 * Daniel P. Berrange <berrange(a)redhat.com> wrote: > On Thu, Mar 18, 2010 at 02:31:24PM +0100, Ingo Molnar wrote: > > > > * 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. > > This has nothing todo with them being in separate source repos. We could > update QEMU to new major feature releaes with the same frequency in a Fedora > release, but we delibrately choose not to rebase the QEMU userspace because > experiance has shown the downside from new bugs / regressions outweighs the > benefit of any new features. > > The QEMU updates in stable Fedora trees, now just follow the minor bugfix > release stream provided by QEMU & those arrive in Fedora with little > noticable delay. That is exactly what i said: Qemu and most user-space packages are on a 'slower' update track than the kernel: generally updated for minor releases. My further point was that the kernel on the other hand gets updated more frequently and as such, any user-space tool bits hosted in the kernel repo get updated more frequently as well. 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: Ingo Molnar on 18 Mar 2010 10:20 * Avi Kivity <avi(a)redhat.com> wrote: > > 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. [...] I wouldnt jump to assumptions there. perf shares some facilities with the kernel on the source code level - they can be built both in the kernel and in user-space. But my main thought wasnt even to actually share the implementation - but to actually synchronize when a piece of device emulation moves into the kernel. It is arguably bad for performance in most cases when Qemu handles a given device - so all the common devices should be kernel accelerated. The version and testing matrix would be simplified significantly as well: as kernel and qemu goes hand in hand, they are always on the same version. > [...] Even worse for the x86 emulator as qemu and kvm are fundamentally > different. So is it your argument that the difference and the duplication in x86 instruction emulation is a good thing? You said it some time ago that the kvm x86 emulator was very messy and you wish it was cleaner. While qemu's is indeed rather different (it's partly a translator/JIT), i'm sure the decoder logic could be shared - and qemu has a slow-path full-emulation fallback in any case, which is similar to what in-kernel emulator does (IIRC ...). That might have changed meanwhile. 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: Ingo Molnar on 18 Mar 2010 10:30
* John Kacur <jkacur(a)redhat.com> wrote: > On Thu, Mar 18, 2010 at 1:33 PM, Frank Ch. Eigler <fche(a)redhat.com> wrote: > > Ingo Molnar <mingo(a)elte.hu> writes: > > > >> [...] > >> 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? ?What users > > eagerly replace their kernels? > > > > Us guys reading and participating on the list. ;) I'd like to second that - i'm actually quite happy to update the distro kernel. Also, i have rarely any problems even with bleeding edge kernels in rawhide - they are working pretty smoothly. A large xorg update showing up in yum update gives me the cringe though ;-) 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/ |