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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Mar 2010 16:52:21 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Avi Kivity <avi@...hat.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com
Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from
 host side


* Frank Ch. Eigler <fche@...hat.com> wrote:

> 
> Ingo Molnar <mingo@...e.hu> writes:
> 
> > [...]
> >> >I.e. we really want to be able users to:
> >> >
> >> >  1) have it all working with a single guest, without having to specify 'which'
> >> >     guest (qemu PID) to work with. That is the dominant usecase both for
> >> >     developers and for a fair portion of testers.
> >> 
> >> That's reasonable if we can get it working simply.
> >
> > IMO such ease of use is reasonable and required, full stop.
> > If it cannot be gotten simply then that's a bug: either in the code, or in the 
> > design, or in the development process that led to the design. Bugs need 
> > fixing. [...]
> 
> Perhaps the fact that kvm happens to deal with an interesting application 
> area (virtualization) is misleading here.  As far as the host kernel or 
> other host userspace is concerned, qemu is just some random unprivileged 
> userspace program (with some *optional* /dev/kvm services that might happen 
> to require temporary root).
> 
> As such, perf trying to instrument qemu is no different than perf trying to 
> instrument any other userspace widget.  Therefore, expecting 'trusted 
> enumeration' of instances is just as sensible as using 'trusted ps' and 
> 'trusted /var/run/FOO.pid files'.

You are quite mistaken: KVM isnt really a 'random unprivileged application' in 
this context, it is clearly an extension of system/kernel services.

( Which can be seen from the simple fact that what started the discussion was 
  'how do we get /proc/kallsyms from the guest'. I.e. an extension of the 
  existing host-space /proc/kallsyms was desired. )

In that sense the most natural 'extension' would be the solution i mentioned a 
week or two ago: to have a (read only) mount of all guest filesystems, plus a 
channel for profiling/tracing data. That would make symbol parsing easier and 
it's what extends the existing 'host space' abstraction in the most natural 
way.

( It doesnt even have to be done via the kernel - Qemu could implement that
  via FUSE for example. )

As a second best option a 'symbol server' might be used too.

Thanks,

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