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: Ingo Molnar on 21 Mar 2010 18:10 * Avi Kivity <avi(a)redhat.com> wrote: > > Consider the _other_ examples that are a lot more clear: > > > > ' If you expose paravirt spilocks via KVM please also make sure the KVM > > tooling can make use of it, has an option for it to configure it, and > > that it has sufficient efficiency statistics displayed in the tool for > > admins to monitor.' > > > > ' If you create this new paravirt driver then please also make sure it can > > be configured in the tooling. ' > > > > ' Please also add a testcase for this bug to tools/kvm/testcases/ so we dont > > repeat this same mistake in the future. ' > > All three happen quite commonly in qemu/kvm development. Of course someone > who develops a feature also develops a patch that exposes it in qemu. There > are several test cases in qemu-kvm.git/kvm/user/test. If that is the theory then it has failed to trickle through in practice. As you know i have reported a long list of usability problems with hardly a look. That list could be created by pretty much anyone spending a few minutes of getting a first impression with qemu-kvm. So something is seriously wrong in KVM land, to pretty much anyone trying it for the first time. I have explained how i see the root cause of that, while you seem to suggest that there's nothing wrong to begin with. I guess we'll have to agree to disagree on that. 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: Anthony Liguori on 21 Mar 2010 19:40 On 03/21/2010 02:17 PM, Ingo Molnar wrote: > >> If you want to improve this, you need to do the following: >> >> 1) Add a userspace daemon that uses vmchannel that runs in the guest and can >> fetch kallsyms and arbitrary modules. If that daemon lives in >> tools/perf, that's fine. >> > Adding any new daemon to an existing guest is a deployment and usability > nightmare. > > The basic rule of good instrumentation is to be transparent. The moment we > have to modify the user-space of a guest just to monitor it, the purpose of > transparent instrumentation is defeated. > > That was one of the fundamental usability mistakes of Oprofile. > > There is no 'perf' daemon - all the perf functionality is _built in_, and for > very good reasons. It is one of the main reasons for perf's success as well. > The solution should be a long lived piece of code that runs without kernel privileges. How the code is delivered to the user is a separate problem. If you want to argue that the kernel should build an initramfs that contains some things that always should be shipped with the kernel but don't need to be within the kernel, I think that's something that's long over due. We could make it a kernel thread, but what's the point? It's much safer for it to be a userspace thread and it doesn't need to interact with the kernel in an intimate way. Regards, Anthony Liguori -- 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: Anthony Liguori on 21 Mar 2010 19:50 On 03/21/2010 04:00 PM, Ingo Molnar wrote: > * Avi Kivity<avi(a)redhat.com> wrote: > > >> On 03/21/2010 09:59 PM, Ingo Molnar wrote: >> >>> Frankly, i was surprised (and taken slightly off base) by both Avi and Anthony >>> suggesting such a clearly inferior "add a demon to the guest space" solution. >>> It's a usability and deployment non-starter. >>> >> It's only clearly inferior if you ignore every consideration against it. >> It's definitely not a deployment non-starter, see the tons of daemons that >> come with any Linux system. [...] >> > Avi, please dont put arguments into my mouth that i never made. > > My (clearly expressed) argument was that: > > _a new guest-side demon is a transparent instrumentation non-starter_ > FWIW, there's no reason you couldn't consume a vmchannel port from within the kernel. I don't think the code needs to be in the kernel and from a security PoV, that suggests that it should be in userspace IMHO. But if you want to make a kernel thread, knock yourself out. I have no objection to that from a qemu perspective. I can't see why Avi would mind either. I think it's papering around another problem (the kernel should control initrds IMHO) but that's a different topic. Regards, Anthony Liguori -- 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: Anthony Liguori on 21 Mar 2010 20:00 On 03/21/2010 05:00 PM, Ingo Molnar wrote: > If that is the theory then it has failed to trickle through in practice. As > you know i have reported a long list of usability problems with hardly a look. > That list could be created by pretty much anyone spending a few minutes of > getting a first impression with qemu-kvm. > I think the point you're missing is that your list was from the perspective of someone looking at a desktop virtualization solution that had was graphically oriented. As Avi has repeatedly mentioned, so far, that has not been the target audience of QEMU. The target audience tends to be: 1) people looking to do server virtualization and 2) people looking to do command line based development. Usually, both (1) and (2) are working on machines that are remotely located. What's important to these users is that VMs be easily launchable from the command line, that there is a lot of flexibility in defining machine types, and that there is a programmatic way to interact with a given instance of QEMU. Those are the things that we've been focusing on recently. The reason we don't have better desktop virtualization support is simple. No one is volunteering to do it and no company is funding development for it. When you look at something like VirtualBox, what you're looking at is a long ago forked version of QEMU with a GUI added focusing on desktop virtualization. There is no magic behind adding a better, more usable GUI to QEMU. It just takes resources. I understand that you're trying to make the point that without catering to the desktop virtualization use case, we won't get as many developers as we could. Personally, I don't think that argument is accurate. If you look at VirtualBox, it's performance is terrible. Having a nice GUI hasn't gotten them the type of developers that can improve their performance. No one is arguing that we wouldn't like to have a nicer UI. I'd love to merge any patch like that. Regards, Anthony Liguori -- 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: Anthony Liguori on 21 Mar 2010 20:20
On 03/21/2010 04:54 PM, Ingo Molnar wrote: > * Avi Kivity<avi(a)redhat.com> wrote: > > >> On 03/21/2010 10:55 PM, Ingo Molnar wrote: >> >>> Of course you could say the following: >>> >>> ' Thanks, I'll mark this for v2.6.36 integration. Note that we are not >>> able to add this to the v2.6.35 kernel queue anymore as the ongoing >>> usability work already takes up all of the project's maintainer and >>> testing bandwidth. If you want the feature to be merged sooner than that >>> then please help us cut down on the TODO and BUGS list that can be found >>> at XYZ. There's quite a few low hanging fruits there. ' >>> >> That would be shooting at my own foot as well as the contributor's since I >> badly want that RCU stuff, and while a GUI would be nice, that itch isn't on >> my back. >> > I think this sums up the root cause of all the problems i see with KVM pretty > well. > A good maintainer has to strike a balance between asking more of people than what they initially volunteer and getting people to implement the less fun things that are nonetheless required. The kernel can take this to an extreme because at the end of the day, it's the only game in town and there is an unending number of potential volunteers. Most other projects are not quite as fortunate. When someone submits a patch set to QEMU implementing a new network backend for raw sockets, we can push back about how it fits into the entire stack wrt security, usability, etc. Ultimately, we can arrive at a different, more user friendly solution (networking helpers) and along with some time investment on my part, we can create a much nicer, more user friendly solution. Still command line based though. Responding to such a patch set with, replace the SDL front end with a GTK one that lets you graphically configure networking, is not reasonable and the result would be one less QEMU contributor in the long run. Overtime, we can, and are, pushing people to focus more on usability. But that doesn't get you a first class GTK GUI overnight. The only way you're going to get that is by having a contributor be specifically interesting in building such a thing. We simply haven't had that in the past 5 years that I've been involved in the project. If someone stepped up to build this, I'd certainly support it in every way possible and there are probably some steps we could take to even further encourage this. Regards, Anthony Liguori -- 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/ |