Re: [RFC PATCH 05/12] perf/x86: Support XMM register for non-PEBS and REGS_USER

[Dave Hansen <dave.hansen@intel.com>]

On 6/13/25 06:49, kan.liang@linux.intel.com wrote:
> +static void x86_pmu_get_ext_regs(struct x86_perf_regs *perf_regs, u64 mask)
> +{
> +	void *xsave = (void *)ALIGN((unsigned long)per_cpu(ext_regs_buf, smp_processor_id()), 64);
> +	struct xregs_state *xregs_xsave = xsave;
> +	u64 xcomp_bv;
> +
> +	if (WARN_ON_ONCE(!xsave))
> +		return;
> +
> +	xsaves_nmi(xsave, mask);
> +
> +	xcomp_bv = xregs_xsave->header.xcomp_bv;
> +	if (mask & XFEATURE_MASK_SSE && xcomp_bv & XFEATURE_SSE)
> +		perf_regs->xmm_regs = (u64 *)xregs_xsave->i387.xmm_space;
> +}

Now that I'm thinking about the init optimization... This is buggy.

Isn't XSAVE fun?

Here's a little primer:

	xcomp_bv - tells you what the format of the buffer is.
		   Which states are where.
	xstate_bv - (aka. xfeatures) tells you which things XSAVES
		    wrote to the buffer.

It's totally valid to have a feature set in xcomp_bv but not xstate_bv.

xcomp_bv is actually pretty boring:

	The XSAVES instructions sets bit 63 of the XCOMP_BV field of the
	XSAVE header while writing RFBM[62:0] to XCOMP_BV[62:0]

Since you know the RFBM, you also know xstate_bv. You don't need to read
it out of the buffer even.

Oh, and what's with the:

	xcomp_bv & XFEATURE_SSE

? xcomp_bv is a bitmap, just like 'mask'

So, what do you do when

	if (!(xregs_xsave->header.xfeatures & XFEATURE_MASK_SSE))
		... here?

The "XSAVE-Enabled Registers Group" docs say:

	The first eight bytes include the XSAVES instruction’s XSTATE_BV
	bit vector (reflecting INIT optimization). This field
	is in XCR0 format.

So the PEBS parsing code has to know how to deal with this situation too
and not copy the xmm_regs out to users.