All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>,
	kan.liang@linux.intel.com, mingo@redhat.com, acme@kernel.org,
	namhyung@kernel.org, tglx@linutronix.de,
	dave.hansen@linux.intel.com, irogers@google.com,
	adrian.hunter@intel.com, jolsa@kernel.org,
	alexander.shishkin@linux.intel.com, linux-kernel@vger.kernel.org,
	ak@linux.intel.com, zide.chen@intel.com
Subject: Re: [RFC PATCH 06/12] perf: Support extension of sample_regs
Date: Tue, 17 Jun 2025 15:24:01 +0100	[thread overview]
Message-ID: <aFF6gdxVyp36ADOi@J2N7QTR9R3> (raw)
In-Reply-To: <20250617140617.GC1613633@noisy.programming.kicks-ass.net>

On Tue, Jun 17, 2025 at 04:06:17PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 17, 2025 at 03:33:33PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 17, 2025 at 08:14:36PM +0800, Mi, Dapeng wrote:
> > 
> > > > We're going to do a sane SIMD register set with variable width, and
> > > > reclaim the XMM regs from the normal set.
> > > 
> > > Ok, so we need to add two width variables like
> > > sample_ext_regs_words_intr/user,
> > 
> > s/ext/simd/
> > 
> > Not sure it makes sense to have separate vector widths for kernel and
> > user regs, but sure.
> > 
> > > then reuse the XMM regs bitmap to represent the extend regs bitmap.
> > 
> > But its not extended; its the normal bitmap.
> > 
> > > Considering the OPMASK regs and APX
> > > extended GPRs have same bit-width (64 bits), we may have to combine them
> > > into a single bitmap, e.g. bits[15:0] represents R31~R16 and bits[23:16]
> > > represents OPMASK7 ~ OPMASK0. 
> > 
> > Again confused, bits 0:23 are the normal registers (in a lunatic
> > order). The XMM regs are in 32:63 and will be free if the SIMD thing is
> > present.
> > 
> > SPP+APX should definitely go there.
> > 
> > Not sure about OPMASK; those really do belong with the SIMD state. Let
> > me go figure out what ARM and Risc-V look like in more detail.
> 
> So ARM-SVE has 32 vector registers with 16 predicate registers.
> 
> Risc-V Zv seems to only have 32 vector registers; no special purpose
> predicate registers, instead a regular vector register can be used as a
> predicate register.
> 
> PowerPC VSX has 64 vector registers and no predicate registers afaict.
> 
> While reading this, I came across the useful note that predicate
> registers are 1/8-th the length of the vector registers (because the
> minimal element is a byte). So while the current AVX-512 predicate
> registers are indeed 64bits, this would no longer be true for the
> hypothetical AVX-1024 (or even AVX-512 if we allow 4bit elements).
> 
> As such, I don't think we should stick the predicate registers in the
> normal group -- they really are not normal registers and won't fit for
> future extensions.
> 
> This then leaves us two options:
> 
>  - stick the predicate registers in the high bits of the vector register
>    word, or
> 
>  - add an explicit predicate register word.

TBH, I don't think we can handle extended state in a generic way unless
we treat this like a ptrace regset, and delegate the format of each
specific register set to the architecture code.

On arm64, the behaviour is modal (with two different vector lengths for
streaming/non-streaming SVE when SME is implemented), per-task
configurable (with different vector lengths), can differ between
host/guest for KVM, and some of the registers only exist in some
configurations (e.g. the FFR only exists for SME if FA64 is
implemented).

Mark.

  reply	other threads:[~2025-06-17 14:24 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-13 13:49 [RFC PATCH 00/12] Support vector and more extended registers in perf kan.liang
2025-06-13 13:49 ` [RFC PATCH 01/12] perf/x86: Use x86_perf_regs in the x86 nmi handler kan.liang
2025-06-13 13:49 ` [RFC PATCH 02/12] perf/x86: Setup the regs data kan.liang
2025-06-13 13:49 ` [RFC PATCH 03/12] x86/fpu/xstate: Add xsaves_nmi kan.liang
2025-06-13 14:39   ` Dave Hansen
2025-06-13 14:54     ` Liang, Kan
2025-06-13 15:19       ` Dave Hansen
2025-06-13 13:49 ` [RFC PATCH 04/12] perf: Move has_extended_regs() to header file kan.liang
2025-06-13 13:49 ` [RFC PATCH 05/12] perf/x86: Support XMM register for non-PEBS and REGS_USER kan.liang
2025-06-13 15:15   ` Dave Hansen
2025-06-13 17:51     ` Liang, Kan
2025-06-13 15:34   ` Dave Hansen
2025-06-13 18:14     ` Liang, Kan
2025-06-13 13:49 ` [RFC PATCH 06/12] perf: Support extension of sample_regs kan.liang
2025-06-17  8:00   ` Mi, Dapeng
2025-06-17  8:14   ` Peter Zijlstra
2025-06-17  9:49     ` Mi, Dapeng
2025-06-17 10:28       ` Peter Zijlstra
2025-06-17 12:14         ` Mi, Dapeng
2025-06-17 13:33           ` Peter Zijlstra
2025-06-17 14:06             ` Peter Zijlstra
2025-06-17 14:24               ` Mark Rutland [this message]
2025-06-17 14:44                 ` Peter Zijlstra
2025-06-17 14:55                   ` Mark Rutland
2025-06-17 19:00                     ` Mark Brown
2025-06-17 20:32                     ` Liang, Kan
2025-06-18  9:35                       ` Peter Zijlstra
2025-06-18 10:10                         ` Liang, Kan
2025-06-18 13:30                           ` Peter Zijlstra
2025-06-18 13:52                             ` Liang, Kan
2025-06-18 14:30                               ` Dave Hansen
2025-06-18 14:47                                 ` Dave Hansen
2025-06-18 15:24                                   ` Liang, Kan
2025-06-18 14:45                               ` Peter Zijlstra
2025-06-18 15:22                                 ` Liang, Kan
2025-06-13 13:49 ` [RFC PATCH 07/12] perf/x86: Add YMMH in extended regs kan.liang
2025-06-13 15:48   ` Dave Hansen
2025-06-13 13:49 ` [RFC PATCH 08/12] perf/x86: Add APX " kan.liang
2025-06-13 16:02   ` Dave Hansen
2025-06-13 17:17     ` Liang, Kan
2025-06-17  8:19   ` Peter Zijlstra
2025-06-13 13:49 ` [RFC PATCH 09/12] perf/x86: Add OPMASK " kan.liang
2025-06-13 13:49 ` [RFC PATCH 10/12] perf/x86: Add ZMM " kan.liang
2025-06-13 13:49 ` [RFC PATCH 11/12] perf/x86: Add SSP " kan.liang
2025-06-13 13:49 ` [RFC PATCH 12/12] perf/x86/intel: Support extended registers kan.liang
2025-06-17  7:50 ` [RFC PATCH 00/12] Support vector and more extended registers in perf Mi, Dapeng
2025-06-17  8:24 ` Peter Zijlstra
2025-06-17 13:52   ` Liang, Kan
2025-06-17 14:29     ` Peter Zijlstra
2025-06-17 15:23       ` Liang, Kan
2025-06-17 17:34         ` Peter Zijlstra
2025-06-18  0:57         ` Mi, Dapeng
2025-06-18 10:47           ` Liang, Kan
2025-06-18 12:28             ` Mi, Dapeng
2025-06-18 13:15               ` Liang, Kan
2025-06-19  0:41                 ` Mi, Dapeng
2025-06-19 11:11                   ` Liang, Kan
2025-06-19 12:26                     ` Mi, Dapeng
2025-06-19 13:38                     ` Peter Zijlstra
2025-06-19 14:27                       ` Liang, Kan

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=aFF6gdxVyp36ADOi@J2N7QTR9R3 \
    --to=mark.rutland@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=zide.chen@intel.com \
    /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.