Re: [PATCH] Enhance perf to collect KVM guest os statistics fromhost side

[oerg Roedel]

On Sun, Mar 21, 2010 at 07:43:00PM +0100, Ingo Molnar wrote:
> Having access to the actual executable files that include the symbols achieves 
> precisely that - with the additional robustness that all this functionality is 
> concentrated into the host, while the guest side is kept minimal (and 
> transparent).

If you want to access the guests file-system you need a piece of
software running in the guest which gives you this access. But when you
get an event this piece of software may not be runnable (if the guest is
in an interrupt handler or any other non-preemptible code path). When the
host finally gets access to the guests filesystem again the source of
that event may already be gone (process has exited, module unloaded...).
The only way to solve that is to pass the event information to the guest
immediatly and let it collect the information we want.


> It can decide whether it exposes the files. Nor are there any "security 
> issues" to begin with.

I am not talking about security. Security was sufficiently flamed about
already.

> You need to be aware of the fact that symbol resolution is a separate step 
> from call chain generation.

Same concern as above applies to call-chain generation too.

> > How we speak to the guest was already discussed in this thread. My personal 
> > opinion is that going through qemu is an unnecessary step and we can solve 
> > that more clever and transparent for perf.
> 
> Meaning exactly what?

Avi was against that but I think it would make sense to give names to
virtual machines (with a default, similar to network interface names).
Then we can create a directory in /dev/ with that name (e.g.
/dev/vm/fedora/). Inside the guest a (priviledged) process can create
some kind of named virt-pipe which results in a device file created in
the guests directory (perf could create /dev/vm/fedora/perf for
example). This file is used for guest-host communication.

Thanks,

	Joerg

--
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/