Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: [PATCH 1/5] x86-32: Split cache flush handler from simd handler
Next: [RESEND][PATCH 1/3] Add tracing_off_event() to stop tracing when a bug or warning occur
From: Joerg Roedel on 24 Mar 2010 12:50 On Wed, Mar 24, 2010 at 06:09:30PM +0200, Avi Kivity wrote: > On 03/24/2010 05:59 PM, Joerg Roedel wrote: >> >> >>>> I am not tied to /sys/kvm. We could also use /proc/<pid>/kvm/ for >>>> example. This would keep anything in the process space (except for the >>>> global list of VMs which we should have anyway). >>>> >>>> >>> How about ~/.qemu/guests/$pid? >>> >> That makes it hard for perf to find it and even harder to get a list of >> all VMs. > > Looks trivial to find a guest, less so with enumerating (still doable). Not so trival and even more likely to break. Even it perf has the pid of the process and wants to find the directory it has to do: 1. Get the uid of the process 2. Find the username for the uid 3. Use the username to find the home-directory Steps 2. and 3. need nsswitch and/or pam access to get this information from whatever source the admin has configured. And depending on what the source is it may be temporarily unavailable causing nasty timeouts. In short, there are many weak parts in that chain making it more likely to break. A kernel-based approach with /proc/<pid>/kvm does not have those issues (and to repeat myself, it is independent from the userspace being used). Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 24 Mar 2010 12:50 On Wed, Mar 24, 2010 at 06:32:51PM +0200, Avi Kivity wrote: > On 03/24/2010 06:31 PM, Joerg Roedel wrote: > That's just what I want to do. Leave it in userspace and then they can > deal with it without telling us about it. They can't do that with a directory in /proc? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 24 Mar 2010 13:50 Em Wed, Mar 24, 2010 at 06:09:30PM +0200, Avi Kivity escreveu: > Doesn't perf already has a dependency on naming conventions for finding > debug information? It looks at several places, from most symbol rich (/usr/lib/debug/, aka -debuginfo packages, where we have full symtabs) to poorest (the packaged binary, where we may just have a .dynsym). In an ideal world, it would just get the build-id (a SHA1 cookie that is in an ELF session inserted in every binary (aka DSOs), kernel module, kallsyms or vmlinux file) and use that to look first in a local cache (implemented in perf for a long time already) or in some symbol server. For instance, for a random perf.data file I collected here in my machine I have: [acme(a)doppio linux-2.6-tip]$ perf buildid-list | grep libpthread 5c68f7afeb33309c78037e374b0deee84dd441f6 /lib64/libpthread-2.10.2.so [acme(a)doppio linux-2.6-tip]$ So I don't have to access /lib64/libpthread-2.10.2.so directly, nor some convention to get a debuginfo in a local file like: /usr/lib/debug/lib64/libpthread-2.10.2.so.debug Instead the tools look at: [acme(a)doppio linux-2.6-tip]$ l ~/.debug/.build-id/5c/68f7afeb33309c78037e374b0deee84dd441f6 lrwxrwxrwx 1 acme acme 73 2010-01-06 18:53 /home/acme/.debug/.build-id/5c/68f7afeb33309c78037e374b0deee84dd441f6 -> ../../lib64/libpthread-2.10.2.so/5c68f7afeb33309c78037e374b0deee84dd441f6* To find the file for that specific build-id, not the one installed in my machine (or on the different machine, of a different architecture) that may be completely unrelated, a new one, or one for a different arch. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 24 Mar 2010 14:30
Em Wed, Mar 24, 2010 at 08:20:10PM +0200, Avi Kivity escreveu: > On 03/24/2010 07:47 PM, Arnaldo Carvalho de Melo wrote: >> Em Wed, Mar 24, 2010 at 06:09:30PM +0200, Avi Kivity escreveu: >> >>> Doesn't perf already has a dependency on naming conventions for finding >>> debug information? >>> >> It looks at several places, from most symbol rich (/usr/lib/debug/, aka >> -debuginfo packages, where we have full symtabs) to poorest (the >> packaged binary, where we may just have a .dynsym). >> >> In an ideal world, it would just get the build-id (a SHA1 cookie that is >> in an ELF session inserted in every binary (aka DSOs), kernel module, >> kallsyms or vmlinux file) and use that to look first in a local cache >> (implemented in perf for a long time already) or in some symbol server. >> >> For instance, for a random perf.data file I collected here in my machine >> I have: >> >> [acme(a)doppio linux-2.6-tip]$ perf buildid-list | grep libpthread >> 5c68f7afeb33309c78037e374b0deee84dd441f6 /lib64/libpthread-2.10.2.so >> [acme(a)doppio linux-2.6-tip]$ >> >> So I don't have to access /lib64/libpthread-2.10.2.so directly, nor some >> convention to get a debuginfo in a local file like: >> >> /usr/lib/debug/lib64/libpthread-2.10.2.so.debug >> >> Instead the tools look at: >> >> [acme(a)doppio linux-2.6-tip]$ l ~/.debug/.build-id/5c/68f7afeb33309c78037e374b0deee84dd441f6 >> lrwxrwxrwx 1 acme acme 73 2010-01-06 18:53 /home/acme/.debug/.build-id/5c/68f7afeb33309c78037e374b0deee84dd441f6 -> ../../lib64/libpthread-2.10.2.so/5c68f7afeb33309c78037e374b0deee84dd441f6* >> >> To find the file for that specific build-id, not the one installed in my >> machine (or on the different machine, of a different architecture) that >> may be completely unrelated, a new one, or one for a different arch. > Thanks. I believe qemu could easily act as a symbol server for this use > case. Agreed, but it doesn't even have to :-) We just need to get the build-id in the PERF_RECORD_MMAP event somehow and then get this symbol from elsewhere, say the same DVD/RHN channel/Debian Repository/embedded developer toolkit image not stripped/whatever. Or it may already be in the local cache from last week's perf report session :-) - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |