RE: [RFC 00/13] Proposal for a new NT_X86_CPUID core dump note

["George, Jini Susan" <JiniSusan.George@amd.com>]

[AMD Official Use Only - General]

I think that even if the xsave layout remains uniform across the cores of a system, since we are trying to design an extensible .note section which can possibly hold all kinds of CPUID information, we might want to consider various scenarios wherein the CPUID information might differ across cores (esp for big.LITTLE/(P/E)), like the cache information, perhaps ? It might be more prudent to include the coretype information also in such cases ?

Rgds
Jini.

>>-----Original Message-----
>>From: John Baldwin <jhb@FreeBSD.org>
>>Sent: Thursday, October 12, 2023 10:48 PM
>>To: Simon Marchi <simon.marchi@polymtl.ca>; gdb-patches@sourceware.org
>>Cc: Felix <felix.willgerodt@intel.com>; George, Jini Susan
>><JiniSusan.George@amd.com>
>>Subject: Re: [RFC 00/13] Proposal for a new NT_X86_CPUID core dump note
>>
>>Caution: This message originated from an External Source. Use proper caution
>>when opening attachments, clicking links, or responding.
>>
>>
>>On 10/12/23 7:33 AM, Simon Marchi wrote:
>>>
>>>
>>> On 2023-10-09 14:36, John Baldwin wrote:
>>>> One of the shortcomings of the previous XSAVE patch series is that it
>>>> depends on heuristics based on the total XSAVE register set size and
>>>> XCR0 mask to infer layouts of the various register blocks for core
>>>> dumps.  This series introduces a new x86-specific core dump note
>>>> intended to supplant these heuristics by storing the raw CPUID leaves
>>>> describing the XSAVE layout in core dumps.
>>>>
>>>> This series proposes a new core dump note, NT_X86_CPUID (0x205),
>>>> which contains an array of structures.  Each structure describes an
>>>> invidual CPUID sub-leaf containing both the inputs to CPUID (%eax and
>>>> %ecx) and the outputs (%eax, %ebx, %ecx, and %edx) in a format
>>>> roughly matching the follow C structure:
>>>>
>>>> struct cpuid_leaf
>>>> {
>>>>      uint32_t leaf;
>>>>      uint32_t subleaf;
>>>>      uint32_t eax;
>>>>      uint32_t ebx;
>>>>      uint32_t ecx;
>>>>      uint32_t edx;
>>>> };
>>>>
>>>> This format is not XSAVE-specific and implementations could choose to
>>>> add additional CPUID leaves to this structure if needed in the future.
>>>> Consumers of this note should lookup the value of required leaves and
>>>> ignore any unneeded leaves.
>>>>
>>>> An alternate approach might be to write out a more XSAVE-specific
>>>> note that is an array containing the offset and size of each XSAVE region.
>>>
>>> Something I thought about: I think there are asymmetrical x86
>>> processors now, with "big" and "little" cores, not sure how they call
>>> them.  For them, is it possible for the XSAVE layout to be different
>>> per core, for instance some cores supporting AVX512 and some cores
>>> not?  And therefore, will we eventually need to include CPUID / XSAVE
>>> information for more than one CPU core type in the core file notes?
>>
>>(The Intel names are "P" (performance) and "E" (energy-efficient) cores
>>btw)
>>
>>I have no idea if they use the same or different XSAVE layouts.  It would seem to
>>be a royal pain if they did as everytime a user thread migrated between cores
>>the OS would have to convert the XSAVE block from one layout to the other.
>>FreeBSD does not have any notion of multiple layouts today and just assumes
>>that the XSAVE layout is uniform across all cores in a system.  I believe Linux's
>>kernel does the same from my reading.
>>
>>--
>>John Baldwin