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

["Taylor R Campbell" <riastradh%netbsd.org@localhost>]

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.