linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Dapeng Mi <dapeng1.mi@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	Eranian Stephane <eranian@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	broonie@kernel.org, Ravi Bangoria <ravi.bangoria@amd.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [Patch v4 03/17] x86/fpu/xstate: Add xsaves_nmi
Date: Thu, 25 Sep 2025 08:07:08 -0700	[thread overview]
Message-ID: <bc8a902f-549a-482f-bf24-04cf5f38a379@intel.com> (raw)
In-Reply-To: <20250925061213.178796-4-dapeng1.mi@linux.intel.com>

On 9/24/25 23:11, Dapeng Mi wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
> 
> There is a hardware feature (Intel PEBS XMMs group), which can handle
> XSAVE "snapshots" from random code running. This just provides another
> XSAVE data source at a random time.
> 
> Add an interface to retrieve the actual register contents when the NMI
> hit. The interface is different from the other interfaces of FPU. The
> other mechanisms that deal with xstate try to get something coherent.
> But this interface is *in*coherent. There's no telling what was in the
> registers when a NMI hits. It writes whatever was in the registers when
> the NMI hit. It's the invoker's responsibility to make sure the contents
> are properly filtered before exposing them to the end user.
> 
> The support of the supervisor state components is required. The
> compacted storage format is preferred. So the XSAVES is used.

The changelog here is looking a bit munged from the last time I looked
at it. It's getting a bit hard to read. I'd probably run it through your
favorite LLM (and proofread it after of course) to make it more readable.

Ditto for the comments.

Also, what supervisor components are involved here? Aren't we just
talking about [XYZ]MM's?

> +/**
> + * xsaves_nmi - Save selected components to a kernel xstate buffer in NMI
> + * @xstate:	Pointer to the buffer
> + * @mask:	Feature mask to select the components to save
> + *
> + * The @xstate buffer must be 64 byte aligned.
> + *
> + * Caution: The interface is different from the other interfaces of FPU.
> + * The other mechanisms that deal with xstate try to get something coherent.
> + * But this interface is *in*coherent. There's no telling what was in the
> + * registers when a NMI hits. It writes whatever was in the registers when
> + * the NMI hit.
> + * The only user for the interface is perf_event. There is already a
> + * hardware feature (See Intel PEBS XMMs group), which can handle XSAVE
> + * "snapshots" from random code running. This just provides another XSAVE
> + * data source at a random time.
> + * This function can only be invoked in an NMI. It returns the *ACTUAL*
> + * register contents when the NMI hit.
> + */

First, please use actual paragraphs. This isn't a manpage.

But this whole comment kinda rubs me the wrong way.

For instance, I don't think we need to relitigate the XSAVE architecture
with the "The @xstate buffer must be 64 byte aligned." comment. Even if
we did, that's just silly when you could put a one-liner WARN_ON() in
the function which would be a billion times better than a comment.

I'm not sure what "interfaces of FPU" means. I know it came mostly out
of some earlier mails I wrote. But could we trim this down, please?

We basically want to scare anyone else away that might be tempted to use
this.

  reply	other threads:[~2025-09-25 15:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-25  6:11 [Patch v4 00/17] Support vector and more extended registers in perf Dapeng Mi
2025-09-25  6:11 ` [Patch v4 01/17] perf/x86: Use x86_perf_regs in the x86 nmi handler Dapeng Mi
2025-09-25  6:11 ` [Patch v4 02/17] perf/x86: Setup the regs data Dapeng Mi
2025-09-25  6:11 ` [Patch v4 03/17] x86/fpu/xstate: Add xsaves_nmi Dapeng Mi
2025-09-25 15:07   ` Dave Hansen [this message]
2025-09-28  5:31     ` Mi, Dapeng
2025-09-29 19:01       ` Dave Hansen
2025-09-30  2:44         ` Mi, Dapeng
2025-09-25  6:12 ` [Patch v4 04/17] perf: Move has_extended_regs() to header file Dapeng Mi
2025-09-25  6:12 ` [Patch v4 05/17] perf/x86: Support XMM register for non-PEBS and REGS_USER Dapeng Mi
2025-09-25  6:12 ` [Patch v4 06/17] perf: Support SIMD registers Dapeng Mi
2025-09-25  6:12 ` [Patch v4 07/17] perf/x86: Move XMM to sample_simd_vec_regs Dapeng Mi
2025-09-25  6:12 ` [Patch v4 08/17] perf/x86: Add YMM into sample_simd_vec_regs Dapeng Mi
2025-09-25  6:12 ` [Patch v4 09/17] perf/x86: Add ZMM " Dapeng Mi
2025-09-25  6:12 ` [Patch v4 10/17] perf/x86: Add OPMASK into sample_simd_pred_reg Dapeng Mi
2025-09-25  6:12 ` [Patch v4 11/17] perf/x86: Add eGPRs into sample_regs Dapeng Mi
2025-09-25  6:12 ` [Patch v4 12/17] perf/x86: Add SSP " Dapeng Mi
2025-09-25  6:12 ` [Patch v4 13/17] perf/x86/intel: Enable PERF_PMU_CAP_SIMD_REGS Dapeng Mi
2025-09-25  6:12 ` [Patch v4 14/17] perf tools: Only support legacy regs for the PT and PERF_REGS_MASK Dapeng Mi
2025-09-25  6:12 ` [Patch v4 15/17] perf tools: headers: Sync with the kernel sources Dapeng Mi
2025-09-25  6:12 ` [Patch v4 16/17] perf tools: parse-regs: Support the new SIMD format Dapeng Mi
2025-09-25  6:12 ` [Patch v4 17/17] perf tools: regs: Support to dump regs for PERF_SAMPLE_REGS_ABI_SIMD Dapeng Mi

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=bc8a902f-549a-482f-bf24-04cf5f38a379@intel.com \
    --to=dave.hansen@intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=dapeng1.mi@intel.com \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@amd.com \
    --cc=tglx@linutronix.de \
    /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).