On Sun, Mar 21, 2010 at 07:43:00PM +0100, Ingo Molnar wrote: > 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). If you want to access the guests file-system you need a piece of software running in the guest which gives you this access. But when you get an event this piece of software may not be runnable (if the guest is in an interrupt handler or any other non-preemptible code path). When the host finally gets access to the guests filesystem again the source of that event may already be gone (process has exited, module unloaded...). The only way to solve that is to pass the event information to the guest immediatly and let it collect the information we want. > It can decide whether it exposes the files. Nor are there any "security > issues" to begin with. I am not talking about security. Security was sufficiently flamed about already. > You need to be aware of the fact that symbol resolution is a separate step > from call chain generation. Same concern as above applies to call-chain generation 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. > > Meaning exactly what? 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. Thanks, Joerg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
