Em Mon, Mar 22, 2010 at 03:24:47PM +0800, Zhang, Yanmin escreveu: > On Fri, 2010-03-19 at 09:21 +0100, Ingo Molnar wrote: > > So some sort of --guestmount option would be the natural solution, which > > points to the guest system's root: and a Qemu enumeration of guest mounts > > (which would be off by default and configurable) from which perf can pick up > > the target guest all automatically. (obviously only under allowed permissions > > so that such access is secure) > If sshfs could access /proc/ and /sys correctly, here is a design: > --guestmount points to a directory which consists of a list of sub-directories. > Every sub-directory's name is just the qemu process id of guest os. Admin/developer > mounts every guest os instance's root directory to corresponding sub-directory. > > Then, perf could access all files. It's possible because guest os instance > happens to be multi-threading in a process. One of the defects is the accessing to > guest os becomes slow or impossible when guest os is very busy. If the MMAP events on the guest included a cookie that could later be used to query for the symtab of that DSO, we wouldn't need to access the guest FS at all, right? With build-ids and debuginfo-install like tools the symbol resolution could be performed by using the cookies (build-ids) as keys to get to the *-debuginfo packages with matching symtabs (and DWARF for source annotation, etc). We have that for the kernel as: [acme@doppio linux-2.6-tip]$ l /sys/kernel/notes -r--r--r-- 1 root root 36 2010-03-22 13:14 /sys/kernel/notes [acme@doppio linux-2.6-tip]$ l /sys/module/ipv6/sections/.note.gnu.build-id -r--r--r-- 1 root root 4096 2010-03-22 13:38 /sys/module/ipv6/sections/.note.gnu.build-id [acme@doppio linux-2.6-tip]$ That way we would cover DSOs being reinstalled in long running 'perf record' sessions too. This was discussed some time ago but would require help from the bits that load DSOs. build-ids then would be first class citizens. - Arnaldo -- 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
