On 3/14/24 09:08, Borislav Petkov wrote: > On Thu, Mar 14, 2024 at 08:37:09AM -0700, Dave Hansen wrote: >> This is pretty close to just a raw dump of the XSAVE CPUID leaves. >> Rather than come up with an XSAVE-specific ABI that depends on CPUID >> *ANYWAY* (because it dumps the "flags" register aka. ECX), maybe we >> should just bite the bullet and dump out (some of) the raw CPUID space. > > Funny you should say that. This was what they had done originally but if > you dump CPUID and you want to add another component in the future which > is *not* described by CPUID, your scheme breaks. Are you envisioning an *XSAVE* state component that's not described by CPUID? Or some _other_ (non-XSAVE) component in a core dump that isn't described by CPUID? > So the idea is to have a self-describing buffers layout, independent > from any x86-ism. You can extend this in a straight-forward way then > later. That argument breaks down a bit on the flags though: xc.xfeat_flags = xstate_flags[i]; Because it comes _directly_ from CPUID with zero filtering: cpuid_count(XSTATE_CPUID, i, &eax, &ebx, &ecx, &edx); ... xstate_flags[i] = ecx; So this layout is quite dependent on what's in x86's CPUID.
