From: Sean Christopherson <seanjc@google.com>
To: Tianyi Liu <i.pear@outlook.com>
Cc: pbonzini@redhat.com, peterz@infradead.org, mingo@redhat.com,
acme@kernel.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, kvm@vger.kernel.org,
x86@kernel.org, mark.rutland@arm.com, mlevitsk@redhat.com,
maz@kernel.org, alexander.shishkin@linux.intel.com,
jolsa@kernel.org, namhyung@kernel.org, irogers@google.com,
adrian.hunter@intel.com
Subject: Re: [PATCH v3 4/5] perf kvm: Support sampling guest callchains
Date: Tue, 12 Dec 2023 07:39:29 -0800 [thread overview]
Message-ID: <ZXh-sRZQWvJYn0uJ@google.com> (raw)
In-Reply-To: <SYBPR01MB687083237B0E5C03B63EDAB99D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
On Sun, Dec 10, 2023, Tianyi Liu wrote:
> This patch provides support for sampling guests' callchains.
>
> The signature of `get_perf_callchain` has been modified to explicitly
> specify whether it needs to sample the host or guest callchain. Based on
> the context, `get_perf_callchain` will distribute each sampling request
> to one of `perf_callchain_user`, `perf_callchain_kernel`,
> or `perf_callchain_guest`.
>
> The reason for separately implementing `perf_callchain_user` and
> `perf_callchain_kernel` is that the kernel may utilize special unwinders
> like `ORC`. However, for the guest, we only support stackframe-based
> unwinding, so the implementation is generic and only needs to be
> separately implemented for 32-bit and 64-bit.
>
> Signed-off-by: Tianyi Liu <i.pear@outlook.com>
> ---
> arch/x86/events/core.c | 63 ++++++++++++++++++++++++++++++++------
> include/linux/perf_event.h | 3 +-
> kernel/bpf/stackmap.c | 8 ++---
> kernel/events/callchain.c | 27 +++++++++++++++-
> kernel/events/core.c | 7 ++++-
> 5 files changed, 91 insertions(+), 17 deletions(-)
>
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 40ad1425ffa2..4ff412225217 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2758,11 +2758,6 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
> struct unwind_state state;
> unsigned long addr;
>
> - if (perf_guest_state()) {
> - /* TODO: We don't support guest os callchain now */
> - return;
> - }
> -
> if (perf_callchain_store(entry, regs->ip))
> return;
>
> @@ -2778,6 +2773,59 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
> }
> }
>
> +static inline void
> +perf_callchain_guest32(struct perf_callchain_entry_ctx *entry,
> + const struct perf_kvm_guest_unwind_info *unwind_info)
> +{
> + unsigned long ss_base, cs_base;
> + struct stack_frame_ia32 frame;
> + const struct stack_frame_ia32 *fp;
> +
> + cs_base = unwind_info->segment_cs_base;
> + ss_base = unwind_info->segment_ss_base;
> +
> + fp = (void *)(ss_base + unwind_info->frame_pointer);
> + while (fp && entry->nr < entry->max_stack) {
> + if (!perf_guest_read_virt((unsigned long)&fp->next_frame,
This is extremely confusing and potentially dangerous. ss_base and
unwind_info->frame_pointer are *guest* SS:RBP, i.e. this is referencing a guest
virtual address. It works, but it _looks_ like the code is fully dereferencing
a guest virtual address in the hose kernel. And I can only imagine what type of
speculative accesses this generates.
*If* we want to support guest callchains, I think it would make more sense to
have a single hook for KVM/virtualization to fill perf_callchain_entry_ctx. Then
there's no need for "struct perf_kvm_guest_unwind_info", perf doesn't need a hook
to read guest memory, and KVM can decide/control what to do with respect to
mitigating speculatiion issues.
> + &frame.next_frame, sizeof(frame.next_frame)))
> + break;
> + if (!perf_guest_read_virt((unsigned long)&fp->return_address,
> + &frame.return_address, sizeof(frame.return_address)))
> + break;
> + perf_callchain_store(entry, cs_base + frame.return_address);
> + fp = (void *)(ss_base + frame.next_frame);
> + }
> +}
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Tianyi Liu <i.pear@outlook.com>
Cc: pbonzini@redhat.com, peterz@infradead.org, mingo@redhat.com,
acme@kernel.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, kvm@vger.kernel.org,
x86@kernel.org, mark.rutland@arm.com, mlevitsk@redhat.com,
maz@kernel.org, alexander.shishkin@linux.intel.com,
jolsa@kernel.org, namhyung@kernel.org, irogers@google.com,
adrian.hunter@intel.com
Subject: Re: [PATCH v3 4/5] perf kvm: Support sampling guest callchains
Date: Tue, 12 Dec 2023 07:39:29 -0800 [thread overview]
Message-ID: <ZXh-sRZQWvJYn0uJ@google.com> (raw)
In-Reply-To: <SYBPR01MB687083237B0E5C03B63EDAB99D88A@SYBPR01MB6870.ausprd01.prod.outlook.com>
On Sun, Dec 10, 2023, Tianyi Liu wrote:
> This patch provides support for sampling guests' callchains.
>
> The signature of `get_perf_callchain` has been modified to explicitly
> specify whether it needs to sample the host or guest callchain. Based on
> the context, `get_perf_callchain` will distribute each sampling request
> to one of `perf_callchain_user`, `perf_callchain_kernel`,
> or `perf_callchain_guest`.
>
> The reason for separately implementing `perf_callchain_user` and
> `perf_callchain_kernel` is that the kernel may utilize special unwinders
> like `ORC`. However, for the guest, we only support stackframe-based
> unwinding, so the implementation is generic and only needs to be
> separately implemented for 32-bit and 64-bit.
>
> Signed-off-by: Tianyi Liu <i.pear@outlook.com>
> ---
> arch/x86/events/core.c | 63 ++++++++++++++++++++++++++++++++------
> include/linux/perf_event.h | 3 +-
> kernel/bpf/stackmap.c | 8 ++---
> kernel/events/callchain.c | 27 +++++++++++++++-
> kernel/events/core.c | 7 ++++-
> 5 files changed, 91 insertions(+), 17 deletions(-)
>
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 40ad1425ffa2..4ff412225217 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2758,11 +2758,6 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
> struct unwind_state state;
> unsigned long addr;
>
> - if (perf_guest_state()) {
> - /* TODO: We don't support guest os callchain now */
> - return;
> - }
> -
> if (perf_callchain_store(entry, regs->ip))
> return;
>
> @@ -2778,6 +2773,59 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
> }
> }
>
> +static inline void
> +perf_callchain_guest32(struct perf_callchain_entry_ctx *entry,
> + const struct perf_kvm_guest_unwind_info *unwind_info)
> +{
> + unsigned long ss_base, cs_base;
> + struct stack_frame_ia32 frame;
> + const struct stack_frame_ia32 *fp;
> +
> + cs_base = unwind_info->segment_cs_base;
> + ss_base = unwind_info->segment_ss_base;
> +
> + fp = (void *)(ss_base + unwind_info->frame_pointer);
> + while (fp && entry->nr < entry->max_stack) {
> + if (!perf_guest_read_virt((unsigned long)&fp->next_frame,
This is extremely confusing and potentially dangerous. ss_base and
unwind_info->frame_pointer are *guest* SS:RBP, i.e. this is referencing a guest
virtual address. It works, but it _looks_ like the code is fully dereferencing
a guest virtual address in the hose kernel. And I can only imagine what type of
speculative accesses this generates.
*If* we want to support guest callchains, I think it would make more sense to
have a single hook for KVM/virtualization to fill perf_callchain_entry_ctx. Then
there's no need for "struct perf_kvm_guest_unwind_info", perf doesn't need a hook
to read guest memory, and KVM can decide/control what to do with respect to
mitigating speculatiion issues.
> + &frame.next_frame, sizeof(frame.next_frame)))
> + break;
> + if (!perf_guest_read_virt((unsigned long)&fp->return_address,
> + &frame.return_address, sizeof(frame.return_address)))
> + break;
> + perf_callchain_store(entry, cs_base + frame.return_address);
> + fp = (void *)(ss_base + frame.next_frame);
> + }
> +}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-12-12 15:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-10 8:07 [PATCH v3 0/5] perf: KVM: Enable callchains for guests Tianyi Liu
2023-12-10 8:07 ` Tianyi Liu
2023-12-10 8:12 ` [PATCH v3 1/5] KVM: Add arch specific interfaces for sampling guest callchains Tianyi Liu
2023-12-10 8:12 ` Tianyi Liu
2023-12-10 12:16 ` Marc Zyngier
2023-12-10 12:16 ` Marc Zyngier
2023-12-11 22:57 ` Sean Christopherson
2023-12-11 22:57 ` Sean Christopherson
2023-12-10 8:14 ` [PATCH v3 2/5] perf kvm: Introduce guest interfaces for sampling callchains Tianyi Liu
2023-12-10 8:14 ` Tianyi Liu
2023-12-10 8:15 ` [PATCH v3 3/5] KVM: implement new perf callback interfaces Tianyi Liu
2023-12-10 8:15 ` Tianyi Liu
2023-12-10 8:15 ` [PATCH v3 4/5] perf kvm: Support sampling guest callchains Tianyi Liu
2023-12-10 8:15 ` Tianyi Liu
2023-12-12 15:39 ` Sean Christopherson [this message]
2023-12-12 15:39 ` Sean Christopherson
2023-12-10 8:16 ` [PATCH v3 5/5] perf tools: Support PERF_CONTEXT_GUEST_* flags Tianyi Liu
2023-12-10 8:16 ` Tianyi Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZXh-sRZQWvJYn0uJ@google.com \
--to=seanjc@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=i.pear@outlook.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=namhyung@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.