On Mon, Sep 26, 2022, Like Xu wrote: > From: Like Xu <likexu@xxxxxxxxxxx> > > The perf_guest_info_callbacks is common to KVM, while intel_pt is not, > not even common to x86. In the VMX context, it makes sense to hook > up the intel_pt specific hook, and given the uniqueness of this usage, > calling the generic callback in the explicit location of the perf context > is not functionally broken. But it's extremely misleading. If I were a developer writing the perf hooks for a different architecture, I would expect perf_handle_guest_intr() to be called on _every_ perf interrupt that occurred in the guest. Genericizing the hook also complicates wiring up the hook and consuming the interrupt type. E.g. patch 3 is buggy; it wires up the VMX handler if and only if PT is in PT_MODE_HOST_GUEST, and then takes a dependency on that buggy behavior by not checking if Intel PT is supported in the now-generic vmx_handle_guest_intr(). This also doesn't really clean up the API from a non-x86 perspective, it just doesn't make it any worse, i.e. other architectures are still exposed to an x86-specific hook. Unless we anticipate ARM or RISC-V (which IIRC is gaining PMU support "soon") needing to hook into "special" perf interrupts, it might be better to figure out a way to make the hooks themselves more extensible for per-arch behavior. E.g similar to kvm_vcpu and kvm_vcpu_arch, add an embedded arch (or vice versa) struct in perf_guest_info_callbacks plus a perf-internal arch hook to update static calls, and use that to wire up handle_intel_pt_int for x86. It'll require more work up front, but in theory it will require less maintenance in the long run. > Rename a bunch of intel_pt_intr() functions to the generic guest_intr(). > No functional change intended. This changelog never says _why_. Looking forward, the reason for the rename is to piggyback the hook for BTS.
