CVS commit: src/sys/arch/x86/x86

"Taylor R Campbell" <[email protected]>
Newsgroups gmane.os.netbsd.devel.cvs
Message-ID <[email protected]>
Module Name:	src
Committed By:	riastradh
Date:		Sat Jul 11 03:26:26 UTC 2026

Modified Files:
	src/sys/arch/x86/x86: identcpu.c

Log Message:
x86: Redo boot-time XSAVE area size ABI check.

Instead of checking each component's offset+size from

    size = CPUID[EAX=0x0d,ECX=i].EAX,
    offset = CPUID[EAX=0x0d,ECX=i].EBX,

to make sure it fits in the XSAVE_MAX_BYTES implied by the
MINSIGSTKSZ ABI parameter, just check the total _enabled_ XSAVE area
size from

    CPUID[EAX=0x0d,ECX=0].EBX,

which is what we use to allocate the XSAVE area in software anyway.

The Intel documentation[1] is not very clear on exactly what
CPUID[EAX=0x0d,ECX=i] reports for i >= 2, saying `valid bit in the
XCR0 register' without distinguishing `supported' from `enabled'
bits, and the AMD documentation I skimmed didn't have these leaves in
any obvious place.  But it seems CPUID[EAX=0xd,ECX=i].EAX/.EBX give
the size and offset of the CPU's _supported_ XSAVE features, rather
than only those for _enabled_ XSAVE features, so the original panic
would have tripped on features we haven't enabled in XCR0_FPU.

In any case, better to verify the parameter we use directly for
allocating space.

[1] Intel 64 and IA-32 Architectures Software Developer's Manual,
    Volume 1: Basic Architecture, Intel, Order Number: 253665-092US,
    June 2026, Sec. 21.3 `CPUID Leaves', Subsection `CPUID.0DH --
    Processor Extended State', Subsubsection `CPUID.0DH.SUB-LEAVES -
    Sub-leaves', pp. 21-43 -- 21-44.
    https://web.archive.org/web/20260709150417/https://cdrdv2-public.intel.com/922477/253665-092-sdm-vol-1.pdf

PR kern/60426: Signal handler corrupts AVX (YMM) registers


To generate a diff of this commit:
cvs rdiff -u -r1.140 -r1.141 src/sys/arch/x86/x86/identcpu.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.