Поддержка AVX-512 виндой

Салют!

Есть ли у кого-нибудь инфа о том, начиная с какой версии Windows присутствует поддержка AVX-512?

Второй вопрос: возможно ли принудительно включить такую поддержку (в 10-ке, в частности), даже если процессор не поддерживает AVX-512?
Зачем? К примеру, чтобы можно было юзать SDE и т.п. штуки.

Ну и вопрос про SSE.
Ранние версии Windows не знали о SSE, ибо его тогда не было. Не знаю про Windows 2000, но NT 4.0 или 98 не должны были (ну, 95 и NT 3.51 уж точно). Соответственно, при переключении контекста максимум, что у них было – это fsave/frstor для сохранения состояние FPU/MMX. Никаких fxsave/fxrstor, а тем более xgetbv, xsave*/xrstor* не было и в помине. Понимаю, что сейчас это не очень актуально, тем не менее, получается, что возможности проверить поддержку SSE ОСью тогда не было. Проверялась поддержка только процессором, поэтому нигде про необходимость проверки поддержки SSE ОСью не пишут, пишут только про AVX[512]. И соответственно, использование софта с SSE на таких ОСях чревато глюками (аналогично использованию AVX, скажем, на XP, но тут проверку всё же сделать можно, благо появился xgetbv).
Мой ход мысли верный?

 

Наверное структуру CONTEXT из сдк нужной винды проще посмотреть, того, чего там нету, точно не сохраняется. А поддержка наборов инструкций вроде как всегда cpuid проверялась.

 

Хм, спасибо за идею, но что-то я не вижу поддержки AVX-512 вообще...

Спойлер: Windows SDK 10.0.17763.0

Код (Text):

1. typedef struct DECLSPEC_ALIGN(16) _XSAVE_FORMAT {
2.     WORD   ControlWord;
3.     WORD   StatusWord;
4.     BYTE  TagWord;
5.     BYTE  Reserved1;
6.     WORD   ErrorOpcode;
7.     DWORD ErrorOffset;
8.     WORD   ErrorSelector;
9.     WORD   Reserved2;
10.     DWORD DataOffset;
11.     WORD   DataSelector;
12.     WORD   Reserved3;
13.     DWORD MxCsr;
14.     DWORD MxCsr_Mask;
15.     M128A FloatRegisters[8];
16.  
17. #if defined(_WIN64)
18.  
19.     M128A XmmRegisters[16];
20.     BYTE  Reserved4[96];
21.  
22. #else
23.  
24.     M128A XmmRegisters[8];
25.     BYTE  Reserved4[224];
26.  
27. #endif
28.  
29. } XSAVE_FORMAT, *PXSAVE_FORMAT;
30.  
31. typedef XSAVE_FORMAT XMM_SAVE_AREA32, *PXMM_SAVE_AREA32;
32.  
33. typedef struct DECLSPEC_ALIGN(16) _CONTEXT {
34.  
35.     //
36.     // Register parameter home addresses.
37.     //
38.     // N.B. These fields are for convience - they could be used to extend the
39.     //      context record in the future.
40.     //
41.  
42.     DWORD64 P1Home;
43.     DWORD64 P2Home;
44.     DWORD64 P3Home;
45.     DWORD64 P4Home;
46.     DWORD64 P5Home;
47.     DWORD64 P6Home;
48.  
49.     //
50.     // Control flags.
51.     //
52.  
53.     DWORD ContextFlags;
54.     DWORD MxCsr;
55.  
56.     //
57.     // Segment Registers and processor flags.
58.     //
59.  
60.     WORD   SegCs;
61.     WORD   SegDs;
62.     WORD   SegEs;
63.     WORD   SegFs;
64.     WORD   SegGs;
65.     WORD   SegSs;
66.     DWORD EFlags;
67.  
68.     //
69.     // Debug registers
70.     //
71.  
72.     DWORD64 Dr0;
73.     DWORD64 Dr1;
74.     DWORD64 Dr2;
75.     DWORD64 Dr3;
76.     DWORD64 Dr6;
77.     DWORD64 Dr7;
78.  
79.     //
80.     // Integer registers.
81.     //
82.  
83.     DWORD64 Rax;
84.     DWORD64 Rcx;
85.     DWORD64 Rdx;
86.     DWORD64 Rbx;
87.     DWORD64 Rsp;
88.     DWORD64 Rbp;
89.     DWORD64 Rsi;
90.     DWORD64 Rdi;
91.     DWORD64 R8;
92.     DWORD64 R9;
93.     DWORD64 R10;
94.     DWORD64 R11;
95.     DWORD64 R12;
96.     DWORD64 R13;
97.     DWORD64 R14;
98.     DWORD64 R15;
99.  
100.     //
101.     // Program counter.
102.     //
103.  
104.     DWORD64 Rip;
105.  
106.     //
107.     // Floating point state.
108.     //
109.  
110.     union {
111.         XMM_SAVE_AREA32 FltSave;
112.         struct {
113.             M128A Header[2];
114.             M128A Legacy[8];
115.             M128A Xmm0;
116.             M128A Xmm1;
117.             M128A Xmm2;
118.             M128A Xmm3;
119.             M128A Xmm4;
120.             M128A Xmm5;
121.             M128A Xmm6;
122.             M128A Xmm7;
123.             M128A Xmm8;
124.             M128A Xmm9;
125.             M128A Xmm10;
126.             M128A Xmm11;
127.             M128A Xmm12;
128.             M128A Xmm13;
129.             M128A Xmm14;
130.             M128A Xmm15;
131.         } DUMMYSTRUCTNAME;
132.     } DUMMYUNIONNAME;
133.  
134.     //
135.     // Vector registers.
136.     //
137.  
138.     M128A VectorRegister[26];
139.     DWORD64 VectorControl;
140.  
141.     //
142.     // Special debug control registers.
143.     //
144.  
145.     DWORD64 DebugControl;
146.     DWORD64 LastBranchToRip;
147.     DWORD64 LastBranchFromRip;
148.     DWORD64 LastExceptionToRip;
149.     DWORD64 LastExceptionFromRip;
150. } CONTEXT, *PCONTEXT;

Тут M128A VectorRegister[26], как я понимаю – это старшая половина YMM, а вот про ZMM ничего. И даже странно, что выравнивание 16 байт, а не 64 (xsave требует выравнивания на 64 байта).
Как-то странно. Должна же винда поддерживать AVX-512...

А про cpuid понятно, вопроса и нет

 

В мануале то, что в сдк _XSAVE_FORMAT, приведено только для fxsave. xsave сохраняет только выбранные компоненты и для avx512 это вроде бы маска

Код (Text):

1. #define XSTATE_MASK_AVX512                  ((1ui64 << (XSTATE_AVX512_KMASK)) | \
2.                                              (1ui64 << (XSTATE_AVX512_ZMM_H)) | \
3.                                              (1ui64 << (XSTATE_AVX512_ZMM)))
4.  

Ну вобщем не входят они похоже в контекст, но сохраняются

 

А почему не посмотреть ?

KiEnableXSave(): if KeFeatureBits.800000h then XSETBV;

context_get/set/swap: if KeFeatureBits.800000h then RtlGetExtendedContextLength()

-> KiInitializeXSave():

KiGetXSaveSupportedFeatures()
KiUpdateXSaveSize()
etc.

А есчо там есть KiParseLoadOptions(), которая какие то параметры строковые в настройках обрабатывает XSAVEPROCESSORSMASK etc.

^ W8

 

Короче, в 7-ке (в заголовочных файлах SDK) сочетания "AVX512" нет вообще (что неудивительно, учитывая, что AVX только в SP1 появился). В 8.1 тоже нет. В 10-ке есть. Получается, что только с 10-й винды началась поддержка AVX-512.
В целом, это неудивительно, ибо AVX-512 появился в 2015, а Windows 8.1 вышла в 2013.

По поводу SSE: "All versions of Windows since Windows98 support SSE, as do Linux kernels since 2.2."

--- Сообщение объединено, 9 май 2019 ---

Остался вопрос вот в чём:

По идее, есть попасть в r0 (через драйвер, к примеру), то можно через xsetbv включить 5-7 биты, так ведь?
Причём, это нужно делать тоже из-под SDE, иначе будет #UD (т.е. если cpuid не указывает, что биты 5-7 валидные для установки в xcr0, то xsetbv выдаст #UD).

 

Jin X,

Я немного посмотрел свежую матчасть. Короче там сам чёрт ноги сломит". Вопрос зачем тс нужна эта поддержка и тем более разбирать как ядро это реализует, там всё сложно что касается математики(обработка этих наборов).

Интереса ради посмотрел и на SDE. Инструмент очень годный, вот только зачем вам нужны не использующиеся расширения архитектуры я так и не понял.

По SDE - сурки на последний билд я не нашёл, те там совсем всё иначе, тот же пин не соответствует суркам.

Интересно как обрабатываются сервисные шлюзы - Int2e что бы получить управление за инструкцией, а не sysenter; из дебаг инфы - разрабы этот шлюз называют альтернативным(AltEntry"). Все Ki*entry захвачены монитором.

У меня визор похож, поэтому я взял для теста пакет апп накрытых протекторами из этой темы https://wasm.in/threads/oep-protektory.33242/

Короче на сильных протекторах он не работает, видимо по этой причини и не используется в RE. Большинство под ним работает стабильно и шустро.

Можно допилить как следует системную обработку, как я это сделал в dye(там любой прот работает), но проблема в сборке, как я понял свежих сурков нет. А вторая проблема из первой вытекающая - как в этот инструмент не имея возможностей сборки интегрировать фильтры/надстройки что бы обрабатывать нужные события.

 

Почему неиспользующиеся?
У меня, к примеру, они не поддерживаются, а где-то могут поддерживаться. А чтобы их потестить, мне надо использовать SDE или что-то подобное. Но для SDE нужно в xcr0 их как-то пропихнуть, иначе ничего работать не будет.

 

Jin X,

Это же чёрный ящик, вы вообще смотрели как оно работает отладчиком ?

> Но для SDE нужно в xcr0 их как-то пропихнуть

Да по описанию понятно что инструмент(SDE) это поддерживает и соответственно ОС. Только вот это НИГДЕ не используется, тестовый семпл найти невозможно. Проблема надуманная. Эти новые железячные фичи в ближайшее время не будут использованы. Это фичи вендора(intel), но есть есчо и другие на этой архитектуре, у которых таких механизмов нет.

> А чтобы их потестить, мне надо использовать SDE или что-то подобное.

Что это значит ?
Тоесть что бы вам какие то железячные фичи новые(не юзаемые) потестить нужен инструмент вендора.. какой то бред. Отладчик не годится и самостоятельно посмотреть как оно работает нельзя, не удивительно, иначе бы уже давно собрал сотни тестовых семплов для проверки.

Начнём с начала. Опишите вашу работу с SDE. Хоть будет с чего начать.

 

Что именно "оно"?

ОС включает поддержку, когда этот набор присутствует в процессоре. А раз его не было изначально, то и включить он его не может (даже при всём желании). Соответственно, когда мы запускаем SDE, то соответствующие биты в xcr0 сброшены, и выполнение инструкций вызывает #UD. Это несколько странно для SDE, но я, пытаясь выполнить даже одну инструкцию AVX-512 из-под SDE (в отладчике x64dbg) увидел именно такую картину. Не знаю, получится ли установить эти биты из-под SDE, и начнёт ли винда их сохранять в контексте (хотя для немногопоточных программ можно и без этого обойтись, если там других сюрпризов не будет каких-нибудь).

Ну это же нормальная история, когда новые технологии начинают применять через несколько лет после выхода. Прошло не так много времени с их появления. В 2015 начали говорить о них, в 2016 они были лишь в Xeon, и только в 2017 они появились в Skylake-X, который стоил как крыло от Боинга (сейчас разве что Core i7-7800X более или менее приемлемо стоит). Более массово, как я понимаю, они начинают появляться в процессорах 2018-2019 годов (хотя лично я Cannon Lake пока не вижу в продаже). В самом наборе в сравнении с AVX там нововведений достаточно, это ж не только увеличение размера (и кол-ва) регистров.

Всё просто: запускается SDE, и из-под него тестируемая прога. Или отладчик (x64dbg).
Я так AVX2 тестил, BMI2, которых у меня, к сожалению, тоже нет...

--- Сообщение объединено, 12 май 2019 ---

В плане использования много примеров привести не могу, но кое-что есть:
https://www.agner.org/optimize/#vectorclass
https://www.agner.org/optimize/#asmlib
https://habr.com/ru/company/intel/blog/266055/

 

Я тут потестил ещё...
Оказывается, AVX-512 всё же работает из-под SDE, но без отладчика.

А вот из-под связки SDE+x64dbg – нет. При загрузке проги в x64dbg отладик он встаёт на int3 внутри PinVM и тут происходит любопытная вещь:
– если проверить в этой точке cpuid и xgetbv, то они показывают, что AVX-512 (и другие неподдерживаемые реальным CPU инструкции) отсутствуют и ОС их не поддерживает;
– если код просто запустить (F9), то всё будет ок, всё будет работать, вот только отладчик не останавливает выполнение на entry point (даже если поставить туда int3 прямо в коде).

Оля просто тупо запускает прогу сразу, WinDbg вообще не работает. Как пользоваться отладчиком – х/з. Причём, что любопытно, насколько я помню, раньше мне как-то удавалось запускать x64dbg из-под SDE и что-то там отлаживать.

--- Сообщение объединено, 13 май 2019 ---

Вот тут нашёл инфу про отладку, но там только для VS: https://software.intel.com/en-us/articles/debugging-applications-with-intel-sde#Windows

 

Jin X,

Как то всё слишком запутано. Как я понял вам это нужно что бы использовать не поддерживаемые наборы, на то он и эмулятор. Но зачем тогда поддержка ос ?

Так как это эмулятор, то ему должна быть не нужна инфа про процессор. Он же не выполняет на нём эти блоки ну или не должен.

Какое вообще отношение имеет cpuid/xget(должна эмулиться) к эмулятору(PIN) ?

 

Indy_, под эмулятором всё нормально работает, как я выяснил.
Проблема оказалась только с отладчиком. Отлаживать под дебагерами не получается. На начальной точке инструкции не эмулируются, а на entry point отладчик не останавливается.
upd: Попробовал поставить аппаратный бряк на entry point. Дебагер остановился, но cpuid опять показывает нули. А если просто запустить (без остановки на entry point, хоть и из-под отладчика), то всё ок. Бред какой-то...

Контекст же должен сохраняться ОСью (это что касается AVX-512). Хотя, эмулятор, наверное, и это должен учитывать как-то.

Если эмулятор нормально работает, значит cpuid/xgetbv должны выдавать правильные значения (тогда и инструкции из нужных наборов эмулируются).

 

Jin X,

> Контекст же должен сохраняться ОСью

Нет не должен. Вы используете эмулятор.

У меня такое впечатление что вы не понимаете предмет. Тоесть не видите разницу между эмуляцией и эмулятором. Точно какой то бред.

 

Под "ОСью" я имею в виду то, что видит программа, а не реальную ОСь (хотя я уже сам немного потерял нить этих цитат).
В общем, речь была о том, что эмулятор должен эмулировать и флаги поддержки ОСью, и контекст сохранять, правильно? И мне сначала показалось, что он этого не делает (по крайней мере, частично), а полагается почему-то на ОСь. Что и ввело меня в ступор – почему так странно? Вот я писал:

А потом дошло, что это запуске отладчика идёт отладка эмулятора, а не программы, поэтому в отладчике ничего не работает (AVX-512). Дошло, когда решил потестить на своей проге, а не просто загрузил случайный EXE-шник и прямо в отладчике набирал инструкции AVX-512 (сначала так делал и не обращал внимание на то, что за код в отладчике загружен).
В общем, проблема сейчас с отладкой, если коротко о насущном.
Я не знаю, как Pin внутри устроен, и это всё кажется мне странным (что отладчик, запущенный в эмуляторе начинает отлаживать этот эмулятор). Всё равно, что при запуске дебагера в QEMU (или каком-нибудь DOSBox'е) дебагер будет видеть не код программы, а код эмулятора.

 

Jin X,

> отладчик, запущенный в эмуляторе начинает отлаживать этот эмулятор

Я про это выше и говорил, вы почему то запутались в этих эмуляциях".

Всё предельно просто. PIN это эмулятор, он раскодирует каждую инструкцию и выполняет её работу, те эмулирует поток инструкций, за исключением сервисных шлюзов - они выполняются напрямую. SDE это надстройка, среда для выполнения эмуляции, работы PIN'a.

Отладчик не запущён в эмуляторе, а вы отлаживаете эмулятор. Это значит что реальный CPU никак не связан с апп, так как оно работает в виртуальной машине. Поэтому и было не ясно сразу что вы спрашиваете, какое отношение имеет ОС к эмулятору. Короче говоря cpuid для эмулятора и эмулируемой среды совершенно разные и не связаны никак.

Ядро ОС не использует даже базовый набор математики, точнее использует крайне редко и вы про это не узнаете. Использование этих блоков по факту разрабам запрещено, по той простой причине, что как только поток начнёт использовать математику это сильно посадит общий профайл(начнётся сохранение блоков математики при обработке исключений или при планировании).

 

А почему это происходит? Почему я не могу запустить отладчик в эмуляторе?
Я же запускаю сначала SDE, который показывает консоль CMD, а оттуда уже отладчик. Я же не открываю эмулятор в отладчике.
Причём, отладчик запускается и выполняет все функции (загрузку файла, к примеру) очень медленно, как в эмуляторе.

А что эта среда в себе содержит? Я так понимаю, она и занимается в т.ч. сохранением и восстановлением контекста (регистров AVX-512)?

Это я понимаю, поэтому меня и удивило, что я вижу из-под отладчика (запущенного из-под SDE) реальный cpuid, а нужные инструкции при этом не эмулируются.

Не понял, что вы имеете в виду. Как cpuid может существовать в среде без эмулятора (или вы имеете в виду реальный CPU)?

 

Jin X,

> Как cpuid может существовать в среде без эмулятора (или вы имеете в виду реальный CPU)?

А вы не думали почему это глючное говно(SDE) никто не юзает ?

Если это эмулятор полноценный, то не должен использовать текущие параметры процессора. В данном случае судя по вашему описанию оно читает реальные параметры, а затем выполняет эмуляцию виртуальных наборов. Походу разрабы совсем сумашедшие.

 

Почему никто? Я пару раз видел, что о нём писали. Задумка-то хорошая.
А какие есть альтернативы? Такие же простые в использовании.

Да нет же. Я ж уже написал, что при запуске без отладчика всё работает как надо. Инструкции работают и выдаются те параметры (cpuid, xgetbv), которые должны быть на процессорах, поддерживающих эти наборы.
Проблема только при запуске отладчика из-под SDE. Они как будто меняются местами. Вернее, как будто появляется ещё один слой: SDE → x64dbg → PinVM (откуда???) → отлаживаемая программа. Т.е. отладчик начинает отлаживать виртуальную машину Pin, при этом он тормозит (а значит какая-то эмуляция работает поверх него), но cpuid выдают значения реального процессора (а не виртуального), а новые инструкции тоже не эмулируются (#UD). Вот это загадка.

 

Jin X,

> отладчик начинает отлаживать виртуальную машину Pin
> при запуске отладчика из-под SDE

Запуск sde под отладчиком". А какой именно отладчик вы используете - x64dbg ?

Может стоит другой использовать.