From: Andrew Jones <ajones@ventanamicro.com>
To: Quan Zhou <zhouquan@iscas.ac.cn>
Cc: anup@brainfault.org, atishp@atishpatra.org,
paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
kvm@vger.kernel.org, kvm-riscv@lists.infradead.org,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 1/2] riscv: perf: add guest vs host distinction
Date: Thu, 22 Aug 2024 15:41:38 +0200 [thread overview]
Message-ID: <20240822-a03a7c96ebceb658325e7fce@orel> (raw)
In-Reply-To: <430f3d38-b12e-4ac8-8040-33bab40380ab@iscas.ac.cn>
On Thu, Aug 22, 2024 at 02:38:44PM GMT, Quan Zhou wrote:
...
> > > +unsigned short perf_misc_flags(struct pt_regs *regs)
> >
> > I see that the consumer of perf_misc_flags is only a u16, but all other
> > architectures define this function as returning an unsigned long, and
> > your last version did as well. My comment in the last version was that
> > we should use an unsigned long for the 'misc' variable to match the
> > return type of the function. I still think we should do that instead
> > since the function should be consistent with the other architectures.
> >
>
> I agree with your point that the type of `misc` should be consistent with
> other architectures.
>
> However, one thing confuses me. The return value of perf_misc_flags
> is assigned to the `misc` field of the perf_event_header structure,
> and the field is defined as `u16`. I checked the return type of
Yes, that's what I mentioned above.
> `perf_misc_flags` in other architectures, and I found that for x86/arm/s390,
> the type is `unsigned long`, while for powerpc, it is `u32`.
> These do not match `u16`, which seems to pose a risk of type truncation and
> feels a bit unconventional. Or is there some other reasonable consideration
> behind this?
No, it's just historic. I see three paths, one is use 'unsigned long' like
the other architectures and assume we'll never have flags touching bits
over 15, so it's fine. Or, same as the first path, but also add
'#define PERF_RECORD_MISC_MAX 15' with a comment explaining misc flags
must be 15 or less as a separate patch. Or, for the third, add patches to
this series that first change all architectures to return u16s.
Thanks,
drew
next prev parent reply other threads:[~2024-08-22 13:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 13:23 [PATCH v2 0/2] riscv: Add perf support to collect KVM guest statistics from host side zhouquan
2024-08-13 13:23 ` [PATCH v2 1/2] riscv: perf: add guest vs host distinction zhouquan
2024-08-21 12:48 ` Andrew Jones
2024-08-22 6:38 ` Quan Zhou
2024-08-22 13:41 ` Andrew Jones [this message]
2024-08-13 13:24 ` [PATCH v2 2/2] riscv: KVM: add basic support for host vs guest profiling zhouquan
2024-08-21 12:51 ` Andrew Jones
2024-08-22 6:42 ` Quan Zhou
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=20240822-a03a7c96ebceb658325e7fce@orel \
--to=ajones@ventanamicro.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@atishpatra.org \
--cc=jolsa@kernel.org \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=zhouquan@iscas.ac.cn \
/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).