Re: [RFC] Unify KVM kernel-space and user-space code into a singleproject

[Ingo Molnar]

* Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:

> On 03/22/2010 10:55 AM, Ingo Molnar wrote:
> >* Anthony Liguori<anthony@xxxxxxxxxxxxx>  wrote:
> >
> >>[...]
> >>
> >>I've been trying very hard to turn this into a productive thread attempting
> >>to capture your feedback and give clear suggestions about how you can solve
> >>achieve your desired functionality.
> >I'm glad that we are at this more productive stage. I'm still trying to
> >achieve the very same technological capabilities that i expressed in the first
> >few mails when i reviewed the 'perf kvm' patch that was submitted by Yanmin.
> >
> >The crux of the problem is very simple. To quote my earlier mail:
> >
> >  |
> >  | - The inconvenience of having to type:
> >  |      perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms \
> >  |               --guestmodules=/home/ymzhang/guest/modules top
> >  |
> >  |
> >  |   is very obvious even with a single guest. Now multiply that by more guests ...
> >  |
> >
> > For example we want 'perf kvm top' to do something useful by default: it 
> > should find the first guest running and it should report its profile.
> >
> > The tool shouldnt have to guess about where the guests are, what their 
> > namespaces is and how to talk to them. We also want easy symbolic access 
> > to guest, for example:
> >
> >   perf kvm -g OpenSuse-2 record sleep 1
> 
> Two things are needed.  The first thing needed is to be able to enumerate 
> running guests and identify a symbolic name.  I have a patch for this and 
> it'll be posted this week or so.  perf will need to have a QMP client and it 
> will need to look in ${HOME}/.qemu/qmp/ to sockets to connect to.
> 
> This is too much to expect from a client and we've got a GSoC idea posted to 
> make a nice library for tools to use to simplify this.

Ok, that sounds interesting! I'd rather see some raw mechanism that 'perf kvm' 
could use instead of having to require yet another library (which generally 
dampens adoption of a tool). So i think we can work from there.

Btw., have you considered using Qemu's command name (task->comm[]) as the 
symbolic name? That way we could see the guest name in 'top' on the host - a 
nice touch.

> The sockets are named based on UUID and you'll have to connect to a guest 
> and ask it for it's name.  Some guests don't have names so we'll have to 
> come up with a clever way to describe a nameless VM.

I think just exposing the UUID in that lazy case would be adequate? It creates 
pressure for VM launchers to use better symbolic names.

> > I.e.:
> >
> >  - Easy default reference to guest instances, and a way for tools to
> >    reference them symbolically as well in the multi-guest case. Preferably 
> >    something trustable and kernel-provided - not some indirect information 
> >    like a PID file created by libvirt-manager or so.
> 
> A guest is not a KVM concept.  It's a qemu concept so it needs to be 
> something provided by qemu.  The other caveat is that you won't see guests 
> created by libvirt because we're implementing this in terms of a default QMP 
> device and libvirt will disable defaults.  This is desired behaviour.  
> libvirt wants to be in complete control and doesn't want a tool like perf 
> interacting with a guest directly.

Hm, this sucks for multiple reasons. Firstly, perf isnt a tool that 
'interacts', it's an observation tool: just like 'top' is an observation tool.

We want to enable developers to see all activities on the system - regardless 
of who started the VM or who started the process. Imagine if we had a way to 
hide tasks to hide from 'top'. It would be rather awful.

Secondly, it tells us that the concept is fragile if it doesnt automatically 
enumerate all guests, regardless of how they were created.

Full system enumeration is generally best left to the kernel, as it can offer 
coherent access.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/