On Mon, Nov 07, 2022 at 03:39:07PM +0000, Marc Zyngier wrote:
[...]
> > > Please educate me: how useful is it to filter on a vcpu number across
> > > all VMs? What sense does it even make?
> >
> > Now "perf kvm" tool is not sophisticated since it doesn't capture VMID
> > and virtual CPU ID together.
>
> VMID is not a relevant indicator anyway, as it can change at any
> point.
Thanks for correction. IIUC, VMID is not fixed for virtual machine, it
can be re-allocated after overflow.
> But that's only to show that everybody has a different view on
> what they need to collect. At which point, we need to provide an
> infrastructure for data extraction, and not the data itself.
Totally agree.
[...]
> > Option 3: As you suggested, I can bind KVM tracepoints with a eBPF
> > program and the eBPF program records perf events.
> >
> > When I reviewed Arm64's kvm_entry / kvm_exit trace events, they don't
> > have vcpu context in the arguments, this means I need to add new trace
> > events for accessing "vcpu" context.
>
> I'm not opposed to adding new trace{point,hook}s if you demonstrate
> that they are generic enough or will never need to evolve.
>
> >
> > Option 1 and 3 both need to add trace events; option 1 is more
> > straightforward solution and this is why it was choosed in current patch
> > set.
> >
> > I recognized that I made a mistake, actually we can modify the trace
> > event's definition for kvm_entry / kvm_exit, note we only modify the
> > trace event's arguments, this will change the trace function's
> > definition but it will not break ABI (the format is exactly same for
> > the user space). Below changes demonstrate what's my proposing:
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index 94d33e296e10..16f6b61abfec 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -917,7 +917,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
> > /**************************************************************
> > * Enter the guest
> > */
> > - trace_kvm_entry(*vcpu_pc(vcpu));
> > + trace_kvm_entry(vcpu);
> > guest_timing_enter_irqoff();
> >
> > ret = kvm_arm_vcpu_enter_exit(vcpu);
> > diff --git a/arch/arm64/kvm/trace_arm.h b/arch/arm64/kvm/trace_arm.h
> > index 33e4e7dd2719..9df4fd30093c 100644
> > --- a/arch/arm64/kvm/trace_arm.h
> > +++ b/arch/arm64/kvm/trace_arm.h
> > @@ -12,15 +12,15 @@
> > * Tracepoints for entry/exit to guest
> > */
> > TRACE_EVENT(kvm_entry,
> > - TP_PROTO(unsigned long vcpu_pc),
> > - TP_ARGS(vcpu_pc),
> > + TP_PROTO(struct kvm_vcpu *vcpu),
> > + TP_ARGS(vcpu),
> >
> > TP_STRUCT__entry(
> > __field( unsigned long, vcpu_pc )
> > ),
> >
> > TP_fast_assign(
> > - __entry->vcpu_pc = vcpu_pc;
> > + __entry->vcpu_pc = *vcpu_pc(vcpu);
> > ),
> >
> > TP_printk("PC: 0x%016lx", __entry->vcpu_pc)
> >
> > Please let me know your opinion, if you don't object, I can move
> > forward with this approach.
>
> I have no issue with this if this doesn't change anything else.
Thanks for confirmation.
> And if you can make use of this with a BPF program and get to the same
> result as your initial patch, then please submit it for inclusion in
> the kernel as an example. We can then point people to it next time
> this crop up (probably before Xmas).
Will do.
Just head up, if everything is going well, I will place the eBPF
program in the folder tools/perf/examples/bpf/, this can be easy for
integration and release with perf tool.
Thanks,
Leo
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
