[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100319172903.GI13108@8bytes.org>
Date: Fri, 19 Mar 2010 18:29:03 +0100
From: oerg Roedel <joro@...tes.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Avi Kivity <avi@...hat.com>,
Sheng Yang <sheng@...ux.intel.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Marcelo Tosatti <mtosatti@...hat.com>,
Jes Sorensen <Jes.Sorensen@...hat.com>,
Gleb Natapov <gleb@...hat.com>,
Zachary Amsden <zamsden@...hat.com>, zhiteng.huang@...el.com,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from
host side
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. 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 ;-)
2. The guest can decide for its own if it want to pass this
inforamtion to the host-perf. No security issues at all.
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.
4. This way extensible to nested virtualization 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.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists