From: Leo Yan <leo.yan@linaro.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
John Garry <john.garry@huawei.com>,
linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Suleiman Souhlal <suleiman@google.com>,
Namhyung Kim <namhyung@kernel.org>, Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv3] perf kvm: add kvm-stat for arm64
Date: Thu, 17 Sep 2020 19:42:31 +0800 [thread overview]
Message-ID: <20200917114231.GE12548@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <652f10660f09bd608b825233713f775a@kernel.org>
On Thu, Sep 17, 2020 at 11:21:15AM +0100, Marc Zyngier wrote:
[...]
> > > > +const char *vcpu_id_str = "id";
> > >
> > > On Arm64, ftrace tracepoint "kvm_entry" doesn't contain the field "id"
> > > or field "vcpu_id", thus it always reads out the "id" is 0 and it is
> > > recorded into Perf's structure vcpu_event_record::vcpu_id and assigned
> > > to perf thread's private data "thread::private".
> > >
> > > With current code, it will not mess up different vcpus' samples
> > > because
> > > now the samples are analyzed based on thread context, but since all
> > > threads' "vcpu_id" is zero, thus all samples are accounted for
> > > "vcpu_id=0" and cannot print out correct result with option "--vcpu":
> > >
> > >
> > > $ perf kvm stat report --vcpu 4
> > >
> > > Analyze events for all VMs, VCPU 4:
> > >
> > > VM-EXIT Samples Samples% Time% Min Time
> > > Max Time Avg time
> > >
> > > Total Samples:0, Total events handled time:0.00us.
> > >
> > >
> > > This is an issue I observed, if we want to support option "--vcpu",
> > > seems we need to change ftrace event for "kvm_entry", but this will
> > > break ABI.
> > >
> > > Essentially, this issue is caused by different archs using different
> > > format for ftrace event "kvm_entry", on x86 it contains feild
> > > "vcpu_id" but arm64 only just records "vcpu_pc".
> > >
> > > @Marc, @Will, do you have any suggestion for this? Do you think it's
> > > feasible to add a new field "vcpu_id" into the tracepoint "kvm_entry"
> > > for Arm64's version?
>
> The question really is: how will you handle the ABI breackage?
> I don't see a good solution for it, apart from having a *separate*
> tracepoint that collects all the information you need. And even that is
> really ugly.
I searched a bit and found in practice it's not impossible to add new
parameters for existed tracepoint, e.g. [1][2] are two examples to add
new parameters for existed tracepoints and have been merged into
mainline kernel. IIUC, we keep the old parameters for a tracepoint
so this can avoid to break ABI if any apps have used this tracepoint,
and adding a new parameter for the tracepoint should be safe.
If you agree with this, I'd like to suggest to apply below change.
How about you think for this?
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 46dc3d75cf13..d9f9b8e1df77 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -736,7 +736,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
/**************************************************************
* Enter the guest
*/
- trace_kvm_entry(*vcpu_pc(vcpu));
+ trace_kvm_entry(vcpu->vcpu_id, *vcpu_pc(vcpu));
guest_enter_irqoff();
ret = kvm_call_hyp_ret(__kvm_vcpu_run, vcpu);
diff --git a/arch/arm64/kvm/trace_arm.h b/arch/arm64/kvm/trace_arm.h
index 4691053c5ee4..e1d3e7a67e8b 100644
--- a/arch/arm64/kvm/trace_arm.h
+++ b/arch/arm64/kvm/trace_arm.h
@@ -12,18 +12,20 @@
* Tracepoints for entry/exit to guest
*/
TRACE_EVENT(kvm_entry,
- TP_PROTO(unsigned long vcpu_pc),
- TP_ARGS(vcpu_pc),
+ TP_PROTO(unsigned int vcpu_id, unsigned long vcpu_pc),
+ TP_ARGS(vcpu_id, vcpu_pc),
TP_STRUCT__entry(
+ __field( unsigned int, vcpu_id )
__field( unsigned long, vcpu_pc )
),
TP_fast_assign(
+ __entry->vcpu_id = vcpu_id;
__entry->vcpu_pc = vcpu_pc;
),
- TP_printk("PC: 0x%08lx", __entry->vcpu_pc)
+ TP_printk("vcpu: %u, PC: 0x%08lx", __entry->vcpu_id, __entry->vcpu_pc)
);
TRACE_EVENT(kvm_exit,
Thanks,
Leo
[1] https://lkml.org/lkml/2019/2/26/282
[2] https://lore.kernel.org/linux-mm/20191106080037.GA59367@google.com/t/
_______________________________________________
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:[~2020-09-17 11:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-17 0:36 [PATCHv3] perf kvm: add kvm-stat for arm64 Sergey Senozhatsky
2020-09-17 8:47 ` Leo Yan
2020-09-17 9:54 ` Sergey Senozhatsky
2020-09-17 10:09 ` Leo Yan
2020-09-17 10:12 ` Leo Yan
2020-09-17 10:21 ` Marc Zyngier
2020-09-17 11:00 ` Sergey Senozhatsky
2020-09-17 13:08 ` Leo Yan
2020-09-17 11:42 ` Leo Yan [this message]
2020-09-17 11:53 ` Marc Zyngier
2020-09-17 12:52 ` Leo Yan
2020-09-18 0:32 ` Sergey Senozhatsky
2020-09-18 8:20 ` Marc Zyngier
2020-09-18 10:35 ` Sergey Senozhatsky
2020-09-18 10:55 ` Marc Zyngier
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=20200917114231.GE12548@leoy-ThinkPad-X240s \
--to=leo.yan@linaro.org \
--cc=acme@kernel.org \
--cc=john.garry@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=maz@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=suleiman@google.com \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).