XSAVE
XSAVE з'яўляецца пашыральным механізмам x86 для захавання стану працэсара, напрыклад вектарных рэгістраў. Апаратная падтрымка, уключэнне на ўзроўні АС і фактычна дазволеныя кампаненты стану з'яўляюцца асобнымі пытаннямі.
Што вам трэба ведаць
XSAVE з'яўляецца пашыральным механізмам x86 для захавання стану працэсара, напрыклад вектарных рэгістраў. Апаратная падтрымка, уключэнне на ўзроўні АС і фактычна дазволеныя кампаненты стану з'яўляюцца асобнымі пытаннямі.
Як гэта працуе
Архітэктура XSAVE выкарыстоўвае пералічаную структуру стану і маскі для апісання таго, якія кампаненты ўключаны і захоўваюцца. Ліст CPUID 0DH апісвае падтрымліваемыя кампаненты і памеры. XCR0 кіруе прыдатнымі кампанентамі стану карыстальніка, тады як OSXSAVE паведамляе праграмнаму забеспячэнню, што аперацыйная сістэма ўключыла асяроддзе XSAVE.
Дзе гэта карысна
Асяроддзю выканання, якое вызначае магчымасць выкарыстання AVX, патрэбны як біт AVX у працэсары, так і стан XMM/YMM, уключаны АС. Рэалізацыя кантэксту або апрацоўкі сігналаў павінна вылучаць месца ў адпаведнасці з уключаным станам, а не меркаваць, што традыцыйнага буфера фіксаванага памеру дастаткова.
Як праверыць падтрымку і актыўнасць
Праверце біт 26 у CPUID.01H:ECX для XSAVE і біт 27 для OSXSAVE. Толькі пасля гэтага выкарыстоўвайце XGETBV, як дазволена, і правярайце неабходныя біты XCR0. Пералічвайце ліст 0DH для структуры стану замест жорсткага кадавання памеру з іншай машыны.
Сродкі кіравання станам - гэта ў першую чаргу адказнасць АС і асяроддзя выканання. Буферы, маскі, памеры кампанентаў, выраўноўванне і правілы аднаўлення павінны адпавядаць архітэктуры і рэжыму выканання. Захаванне толькі падмноства можа пашкодзіць код, які выкарыстоўвае дадатковы ўключаны стан.
Чаго гэта функцыя не гарантуе
Падтрымка XSAVE сама па сабе не азначае, што AVX, AVX-512 ці AMX прыдатныя для выкарыстання. Нельга выкарыстоўваць XGETBV перад вызначэннем неабходнай падтрымкі і ўключэння на ўзроўні АС. Розныя інструкцыі сямейства XSAVE маюць асобныя правілы пералічэння і кампаноўкі.
Сумяшчальнасць і прадукцыйнасць на практыцы
Вызначэнне функцый на ўзроўні праграмы павінна выкарыстоўваць падтрымліваемы інтэрфейс асяроддзя выканання, калі гэта магчыма. Адрознівайце апаратную падтрымку ад уключэння ў АС і, для дынамічных функцый, правоў працэсу. Пазнака працэсара сама па сабе не можа гарантаваць, што адвольная паслядоўнасць захавання/аднаўлення з'яўляецца карэктнай.
Практычны чэк-ліст для праверкі
- Зафіксуйце дакладную мадэль працэсара або платформы, а таксама задзейнічаныя версіі праграмы, АС і асяроддзя выканання. Захавайце дакладную фармулёўку памылкі або патрабавання.
- Звярніцеся да дакументацыі вытворцы для гэтай канкрэтнай мадэлі, затым праверце фактычныя магчымасці і ўключаны стан у асяроддзі, дзе выконваецца праграма.
- Супастаўце кожнае патрабаванне выбранага выканальнага файла або бэкэнда. Аналагічнай назвы функцыі, псеўданіма або агульнай назвы тэхналогіі недастаткова.
- Пацвердзіце, што праграма выбрала патрэбную рэалізацыю. Выкарыстоўвайце яе задакументаваныя сродкі дыягностыкі і падтрымліваемы запасны варыянт, калі патрабаванні не выконваюцца.
- Уносьце па адным падтрымліваемым змяненні за раз і паўтарайце тую ж нагрузку. Захоўвайце зыходную канфігурацыю і магчымасць адкату.
Калі функцыя пазначана, але праграмнае забеспячэнне не можа яе выкарыстоўваць
Пачніце з канкрэтнага кампанента, які выклікае збой. Апаратная база даных апісвае зафіксаваныя магчымасці; аперацыйная сістэма або гіпервізар могуць прадастаўляць іншае фактычнае асяроддзе. Памылка недапушчальнай інструкцыі (illegal instruction) таксама патрабуе даследавання канкрэтнай інструкцыі, якая выклікала збой, і зборкі бінарнага файла, паколькі пашкоджанне даных або іншая непадтрымліваемая інструкцыя могуць выклікаць аналагічны сімптом.
Усталюйце версію праграмы, драйвера або асяроддзя выканання, якая падтрымліваецца для дадзенай платформы, і пры неабходнасці выкарыстоўвайце задакументаваную вытворцам базавую або запасную зборку. Абнаўленне ПЗ не можа стварыць інструкцыю, якой няма ў працэсары. Змяненні ў мікрапраграме (firmware) і палітыках бяспекі павінны адпавядаць працэдурам вытворцы сістэмы і плану аднаўлення, а не агульным рэцэптам аптымізацыі.
Крыніцы і межы прымянення гэтага тлумачэння
Intel 64 and IA-32 Architectures Software Developer's Manual · Ядро Linux: выкарыстанне функцый XSTATE у прасторы карыстальніка
Гэтыя даведнікі вызначаюць архітэктурныя паводзіны і патрабаванні да праграмнага забеспячэння. Яны не пацвярджаюць незалежна кожнае значэнне функцыі на звязанай старонцы мадэлі абсталявання. Для праверкі падтрымкі мадэллю выкарыстоўвайце даныя вытворцы на адпаведнай старонцы і правярайце фактычную канфігурацыю сістэмы. Гэты артыкул не змяшчае вынікаў тэсціравання (benchmark), сертыфікацыі або даты незалежнага агляду.
Крыніцы і праверка
Рэдакцыйная прыналежнасць: Feex. Дата незалежнай праверкі не зафіксавана. Як мы даследуем.
- Intel 64 and IA-32 Architectures Software Developer's Manual · Тамы 1 і 2 апісваюць названыя сямействы інструкцый і CPUID; Том 3 апісвае стан, старонкавую арганізацыю памяці, VMX і элементы кіравання абаронай. Архітэктурная дакументацыя не пацвярджае падтрымку канкрэтнай мадэлі.
- Ядро Linux: выкарыстанне функцый XSTATE у прасторы карыстальніка · Уключаны аперацыйнай сістэмай вектарны стан, дынамічна ўключаны стан плітак, патрабаванні да стэка сігналаў і працэс атрымання дазволаў AMX. Спецыфічныя для Linux паводзіны не гарантуюць таго ж у іншай АС.
Ці быў гэты артыкул карысным?
Дастаткова адказаць "так" або "не". Выберыце прычыну, калі хочаце, або дадайце кароткую нататку.
Дзякуй. Гэта дапамагае нам паляпшаць гэтую старонку.