* Avi Kivity <avi@xxxxxxxxxx> wrote: > On 02/26/2010 11:01 AM, Ingo Molnar wrote: > >* Zhang, Yanmin<yanmin_zhang@xxxxxxxxxxxxxxx> wrote: > > > >>2) We couldn't get guest os kernel/user stack data in an easy way, so we > >>might not support callchain feature of tool perf. A work around is KVM > >>copies kernel stack data out, so we could at least support guest os kernel > >>callchain. > >If the guest is Linux, KVM can get all the info we need. > > > >While the PMU event itself might trigger in an NMI (where we cannot access > >most of KVM's data structures safely), for this specific case of KVM > >instrumentation we can delay the processing to a more appropriate time - in > >fact we can do it in the KVM thread itself. > > The nmi will be a synchronous event: it happens in guest context, > and we program the hardware to intercept nmis, so we just get an > exit telling us that an nmi has happened. > > (would also be interesting to allow the guest to process the nmi > directly in some scenarios, though that would require that there be > no nmi sources on the host). > > >We can do that because we just triggered a VM exit, so the VM state is for all > >purposes frozen (as far as this virtual CPU goes). > > Yes. > > >Which egives us plenty of time and opportunity to piggy back to the KVM > >thread, look up the guest stack, process/fill the MMU cache as we walk the > >guest page tables, etc. etc. > > > >It would need some minimal callback facility towards KVM, triggered by a perf > >event PMI. > > Since the event is synchronous and kvm is aware of it we don't need > a callback; kvm can call directly into perf with all the > information. Yes - it's still a "callback" in the abstract sense. Much of it already all existing. > >One additional step needed is to get symbol information from the guest, and to > >integrate it into the symbol cache on the host side in ~/.debug. We already > >support cross-arch symbols and 'perf archive', so the basic facilities are > >there for that. So you can profile on 32-bit PA-RISC and type 'perf report' on > >64-bit x86 and get all the right info. > > > >For this to work across a guest, a gateway is needed towards the guest. > >There's several ways to achieve this. The most practical would be two steps: > > > > - a user-space facility to access guest images/libraries. (say via ssh, or > > just a plain TCP port) This would be useful for general 'remote profiling' > > sessions as well, so it's not KVM specific - it would be useful for remote > > debugging. > > > > - The guest /proc/kallsyms (and vmlinux) could be accessed via that channel > > as well. > > > >(Note that this is purely for guest symbol space access - all the profiling > >data itself comes via the host kernel.) > > > >In theory we could build some sort of 'symbol server' facility into the > >kernel, which could be enabled in guest kernels too - but i suspect existing, > >user-space transports go most of the way already. > > There is also vmchannel aka virtio-serial, a guest-to-host communication > channel. Basically what is needed is plain filesystem access - properly privileged. So doing this via a vmchannel would be nice, but for the symbol extraction it would be a glorified NFS server in essence. Do you have (or plan) any turn-key 'access to all files of the guest' kind of guest-transparent facility that could be used for such purposes? That would have various advantages over a traditional explicit file server approach: - it would not contaminate the guest port space - no guest side configuration needed (the various oprofile remote daemons always sucked as they needed extra setup) - it might even be used with a guest that does no networking - if done fully in the kernel it could be done with a fully 'unaware' guest, etc. Thanks, Ingo -- 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
