[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9381647d-de62-4c72-9b1c-930cbd9231d6@intel.com>
Date: Thu, 27 Feb 2025 19:10:48 -0800
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Ingo Molnar <mingo@...nel.org>, Andrew Cooper <andrew.cooper3@...rix.com>
CC: <bp@...en8.de>, <dave.hansen@...el.com>, <dave.hansen@...ux.intel.com>,
<linux-kernel@...r.kernel.org>, <mingo@...hat.com>, <tglx@...utronix.de>,
<x86@...nel.org>
Subject: Re: [PATCH RFC v1 02/11] x86/fpu/xstate: Introduce xstate order table
and accessor macro
On 2/27/2025 1:30 PM, Ingo Molnar wrote:
>
> * Ingo Molnar <mingo@...nel.org> wrote:
>>
>> I propose a new addition, an extension of functionality: if a new CPUID
>> bit indicates it, and a new MSR is written, XFEATURES bit 3 becomes
>> active again - and the MPX area is now used by AVX. Obviously only
>> AVX-aware host and guest kernels would enable AVX.
>
> Erm, s/AVX/APX ...
Just thought of another aspect of this:
I'm curious about how core dumps should handle this. Initially, an
xfeature mask was added to the software-reserved area [1] to indicate
which xfeatures were present in the layout. More recently, a new note
[2] was introduced to expose CPUID-reported size and offset information,
helping tools like GDB. From an offline interpretation standpoint, I
think these bits will become ambiguous without further extensions.
[1] commit 5b3efd500854 ("x86, ptrace: regset extensions to support xstate")
[2] commit ba386777a30b ("x86/elf: Add a new FPU buffer layout info to
x86 core files")
Thanks,
Chang
Powered by blists - more mailing lists