linux-kernel - Re: [RFC PATCH 06/12] perf: Support extension of sample

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250618093500.GH1613376@noisy.programming.kicks-ass.net>
Date: Wed, 18 Jun 2025 11:35:00 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Liang, Kan" <kan.liang@...ux.intel.com>
Cc: Mark Rutland <mark.rutland@....com>,
	"Mi, Dapeng" <dapeng1.mi@...ux.intel.com>, mingo@...hat.com,
	acme@...nel.org, namhyung@...nel.org, tglx@...utronix.de,
	dave.hansen@...ux.intel.com, irogers@...gle.com,
	adrian.hunter@...el.com, jolsa@...nel.org,
	alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org,
	ak@...ux.intel.com, zide.chen@...el.com, broonie@...nel.org
Subject: Re: [RFC PATCH 06/12] perf: Support extension of sample_regs

On Tue, Jun 17, 2025 at 04:32:24PM -0400, Liang, Kan wrote:

> > Yep, those options may work for us, but we'd need to think harder about
> > it. Our approach for ptrace and signals has been to have a header and
> > pack at the active vector length, so padding to a max width would be
> > different, but maybe it's fine.
> > 
> > Having another representation feels like a recipe waiting to happen.
> > 
> 
> I'd like to make sure I understand correctly.
> If we'd like an explicit predicate register word, the below change in
> struct perf_event_attr is OK for ARM as well, right?
> 
> 	__u16 sample_simd_pred_reg_words;
> 	__u16 sample_simd_pred_reg_intr;
> 	__u16 sample_simd_pred_reg_user;
> 	__u16 sample_simd_reg_words;
> 	__u64 sample_simd_reg_intr;
> 	__u64 sample_simd_reg_user;
> 
> BTW: would that be easier for ARM if changing the _words to _type?
> You may define some types like, stream_sve, n_stream_sve, etc.
> The output will depend on the types, rather than the max length of
> registers.

I'm thinking what they're after is something like:

PERF_SAMPLE_SIMD_REGS := {
	u16 nr_vectors;
	u16 vector_length;
	u16 nr_pred;
	u16 pred_length;
	u64 data[];
}

Where the output data also has a length. Such that even if we ask for
512 bit vectors, the thing is allowed to respond with say 128 bit
vectors if that is all the machine has at that time.