On Sat, 05 Nov 2022 07:23:11 +0000, Leo Yan <leo.yan@xxxxxxxxxx> wrote: > > Since the two trace events kvm_entry_v2/kvm_exit_v2 are added, we can > use the field "vcpu_id" in the events to get to know the virtual CPU ID. > To keep backward compatibility, we still need to rely on the trace > events kvm_entry/kvm_exit for old kernels. > > This patch adds Arm64's functions setup_kvm_events_tp() and > arm64__setup_kvm_tp(), by detecting the nodes under sysfs folder, it can > dynamically register trace events kvm_entry_v2/kvm_exit_v2 when the > kernel has provided them, otherwise, it rolls back to use events > kvm_entry/kvm_exit for backward compatibility. > > Let cpu_isa_init() to invoke arm64__setup_kvm_tp(), this can allow the > command "perf kvm stat report" also to dynamically setup trace events. > > Before: > > # perf kvm stat report --vcpu 27 > > Analyze events for all VMs, VCPU 27: > > VM-EXIT Samples Samples% Time% Min Time Max Time Avg time > > Total Samples:0, Total events handled time:0.00us. > > After: > > # perf kvm stat report --vcpu 27 > > Analyze events for all VMs, VCPU 27: > > VM-EXIT Samples Samples% Time% Min Time Max Time Avg time > > SYS64 808 98.54% 91.24% 0.00us 303.76us 3.46us ( +- 13.54% ) > WFx 10 1.22% 7.79% 0.00us 69.48us 23.91us ( +- 25.91% ) > IRQ 2 0.24% 0.97% 0.00us 22.64us 14.82us ( +- 52.77% ) > > Total Samples:820, Total events handled time:3068.28us. Please educate me: how useful is it to filter on a vcpu number across all VMs? What sense does it even make? Conversely, what would be the purpose of filtering on a 5th thread of any process irrespective of what the process does? To me, this is the same level of non-sense. AFAICT, this is just piling more arbitrary data extraction for no particular reason other than "just because we can", and there is absolutely no guarantee that this is fit for anyone else's purpose. I'd rather you have a generic tracepoint taking the vcpu as a context and a BPF program that spits out the information people actually need, keeping things out of the kernel. Or even a tracehook (like the scheduler does), and let people load a module to dump whatever information they please. But randomly adding new tracepoints to output a semi-useless field without any consideration for future-proofing? No, thank you. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
