Update Linux/Mac Context State for AVX512

[anthonycanino]

As part of the changes introduced in #79544 , with respect to adding AVX512 upper SIMD registers: we commented that there will need to be some additional changes for Mac and Linux

"It looks like on Linux (and Mac?) we'll need additional updates in src\coreclr\pal\src\thread\context.cpp, specifically CONTEXTFromNativeContext, CONTEXTToNativeContext, as well as FPREG_HasYmmRegisters() (need a FPREG_HasZmmRegisters()?) and audit other places where CONTEXT_XSTATE is used and is storing 16 registers, 16 bytes each. So it looks like they would need updating to save/restore kmask, the high 16 bytes of zmm0-zmm15 and all of zmm16-zmm31."

Issue is to track work to do this with a follow up PR. Please add the AVX512 tag.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[BruceForstall]

cc @janvorli

[tannergooding]

Was looking at this to get an understanding of how it works and it appears we have some custom logic in context2.S which pulls things from CONTEXT.VectorRegister. I don't, however, see where we're populating this field.

I'm not understanding why we aren't using the "proper" way to do this via XSTATE. For reference: https://learn.microsoft.com/en-us/windows/win32/debug/avx-support-portal and https://learn.microsoft.com/en-us/windows/win32/debug/working-with-xstate-context

Using XSTATE will be required for the ZMM and Mask registers. And presumably will require fixups to the PAL layer that is using a fake Win32 CONTEXT struct as a shim over the platform specific functionality

CC. @janvorli, @jkotas

[jkotas]

it appears we have some custom logic in context2.S which pulls things from CONTEXT.VectorRegister

For example, it is populated here:

runtime/src/coreclr/pal/src/thread/context.cpp

Line 856 in 4ece8f0

memcpy_s(lpContext->VectorRegister, sizeof(M128A) * 16, FPREG_Xstate_Ymmh(native), sizeof(M128A) * 16);

I'm not understanding why we aren't using the "proper" way to do this via XSTATE

CoreCLR PAL is partial Windows API emulator. If you see something that does not fully match how the API works on Windows, it just means that we have not found a need to implement it.

Fully emulating the Windows APIs is not necessarily the best way to make this work. In general, we have been moving away from emulating Windows APIs.

[tannergooding]

For example, it is populated here:

Thanks!

Fully emulating the Windows APIs is not necessarily the best way to make this work. In general, we have been moving away from emulating Windows APIs.

Would you recommend we switch to just consuming xfeatures (Unix) and x86_avx512_state64_t (MacOS) directly instead?

-- Notably I don't see where our XSTATE_AVX handling logic is for Windows either. Could you point me in the right direction for that?

[jkotas]

Would you recommend we switch to just consuming xfeatures (Unix) and x86_avx512_state64_t (MacOS) directly instead?

There needs to be some kind of PAL abstraction that the runtime code is implemented against. I do not have detailed throughs about the best abstraction to use. My only observation is that 100% fidelity with Win32 abstraction is not necessarily the best option.

Notably I don't see where our XSTATE_AVX handling logic is for Windows either. Could you point me in the right direction for that?

Look for InitializeContext2, SetXStateFeaturesMask, XSTATE_MASK_AVX and XSTATE_MASK_AVX512.

[tannergooding]

Thanks! I was looking for a slightly different set of flags/APIs, makes sense why I couldn't find it.