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:	Mon, 22 Mar 2010 12:47:44 +0100
From:	Joerg 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 Mon, Mar 22, 2010 at 11:59:27AM +0100, Ingo Molnar wrote:
> Best would be if you demonstrated any problems of the perf symbol lookup code 
> you are aware of on the host side, as it has that exact design you are 
> criticising here. We are eager to fix any bugs in it.
> 
> If you claim that it's buggy then that should very much be demonstratable - no 
> need to go into theoretical arguments about it.

I am not claiming anything. I just try to imagine how your proposal
will look like in practice and forgot that symbol resolution is done at
a later point.
But even with defered symbol resolution we need more information from
the guest than just the rip falling out of KVM. The guest needs to tell
us about the process where the event happened (information that the host
has about itself without any hassle) and which executable-files it was
loaded from.

> > 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.
> 
> That is kind of half of my suggestion - the built-in enumeration guests and a 
> guaranteed channel to them accessible to tools. (KVM already has its own 
> special channel so it's not like channels of communication are useless.)
> 
> The other half of my suggestion is that if we bring this thought to its 
> logical conclusion then we might as well walk the whole mile and not use 
> quirky, binary API single-channel pipes. I.e. we could use this convenient, 
> human-readable, structured, hierarchical abstraction to expose information in 
> a finegrained, scalable way, which has a world-class implementation in Linux: 
> the 'VFS namespace'.

Probably. At least it is the solution that fits best into the current
design of perf. But we should think about how this will be done. Raw
disk access is no solution because we need to access virtual
file-systems of the guest too. Network filesystems may be a solution but
then we come back to the 'deployment-nightmare'.

	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/