Messages in this thread | | | Date | Mon, 22 Mar 2010 20:27:39 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC] Unify KVM kernel-space and user-space code into a single project |
| |
* Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 03/22/2010 12:34 PM, Ingo Molnar wrote: > >This is really just the much-discredited microkernel approach for keeping > >global enumeration data that should be kept by the kernel ... > > > >Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by Anthony. > >There's numerous ways that this can break: > > > > - Those special files can get corrupted, mis-setup, get out of sync, or can > > be hard to discover. > > > > - The ${HOME}/.qemu/qmp/ solution suggested by Anthony has a very obvious > > design flaw: it is per user. When i'm root i'd like to query _all_ current > > guest images, not just the ones started by root. A system might not even > > have a notion of '${HOME}'. > > > > - Apps might start KVM vcpu instances without adhering to the > > ${HOME}/.qemu/qmp/ access method. > > > > - There is no guarantee for the Qemu process to reply to a request - while > > the kernel can always guarantee an enumeration result. I dont want 'perf > > kvm' to hang or misbehave just because Qemu has hung. > > If your position basically boils down to, we can't trust userspace > and we can always trust the kernel, I want to eliminate any > userspace path, then I can't really help you out.
Why would you want to 'help me out'? I can tell a good solution from a bad one just fine.
You should instead read the long list of disadvantages above, invert them and list then as advantages for the kernel-based vcpu enumeration solution, apply common sense and go admit to yourself that indeed in this situation a kernel provided enumeration of vcpu contexts is the most robust solution.
It's really as simple as that :-)
Thanks,
Ingo
| |