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

Ingo Molnar
2010-03-21T18:43:00Z

* oerg Roedel <joro@8bytes.org> 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