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

[Ingo Molnar]

* oerg Roedel <joro@xxxxxxxxxx> wrote:

> On Fri, Mar 19, 2010 at 09:21:22AM +0100, Ingo Molnar wrote:
> > Unfortunately, in a previous thread the Qemu maintainer has indicated that he 
> > will essentially NAK any attempt to enhance Qemu to provide an easily 
> > discoverable, self-contained, transparent guest mount on the host side.
> > 
> > No technical justification was given for that NAK, despite my repeated 
> > requests to particulate the exact security problems that such an approach 
> > would cause.
> > 
> > If that NAK does not stand in that form then i'd like to know about it - it 
> > makes no sense for us to try to code up a solution against a standing 
> > maintainer NAK ...
> 
> I still think it is the best and most generic way to let the guest do the 
> symbol resolution. [...]

Not really.

> [...] This has several advantages:
> 
> 	1. The guest knows best about its symbol space. So this would be
> 	   extensible to other guest operating systems.  A brave
> 	   developer may even implement symbol passing for Windows or
> 	   the BSDs ;-)

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).

> 	2. The guest can decide for its own if it want to pass this
> 	   inforamtion to the host-perf. No security issues at all.

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

> 	3. The guest can also pass us the call-chain and we don't need
> 	   to care about complicated of fetching from the guest
> 	   ourself.

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

I.e. call-chains are a (entirely) separate issue, and could reasonably be done 
in the guest or in the host.

It has no bearing on this symbol resolution question.

> 	4. This way extensible to nested virtualization too.

Nested virtualization is actually already taken care of by the filesystem 
solution via an existing method called 'subdirectories'. If the guest offers 
sub-guests then those symbols will be exposed in a similar way via its own 
'guest files' directory hierarchy.

I.e. if we have 'Guest-2' nested inside 'the 'Guest-Fedora-1' instance, we get:

 /guests/
 /guests/Guest-Fedora-1/etc/
 /guests/Guest-Fedora-1/usr/

we'd also have:

 /guests/Guest-Fedora-1/guests/Guest-2/

So this is taken care of automatically.

I.e. none of the four 'advantages' listed here are actually advantages over my 
proposed solution, so your conclusion is subsequently flawed as well.

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

Thanks,

	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/