A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Cancel Create
asid / README.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Cannot retrieve contributors at this time
126 lines (103 sloc) 10.5 KB
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents Copy raw contents
Copy raw contents
ASID: Автоматическое обучение для малых и несбалансированных выборок
Библиотека ASID включает в себя инструменты автоматического обучения на малых и несбалансированных выборках в табличном формате.
Для малых выборок библиотека содержит алгоритм GenerativeModel . Он обучает оптимальную генеративную модель, которая сэмплирует схожие синтетические выборки и не переобучается. Основные преимущества алгоритма:
#транзакция #database ACID — требования к транзакционной системе.
- Он включает в себя 9 наиболее популярных генеративных алгоритмов для табличных данных: ядерная оценка плотности, Гауссовы смеси распределений, копулы и модели глубокого обучения;
- Инструмент достаточно прост в использовании и не требует длительного подбора гиперпараметров;
- Имеет встроенную процедуру подбора гиперпараметров с помощью Hyperopt, время работы которого может контролироваться пользователем;
- Доступны несколько метрик, которые позволяют оценить степень переобучения генеративных моделей.
Для несбалансированных выборок ASID содержит ансамблевый классификационный алгоритм — AutoBalanceBoost (ABB). Он сочетает в себе устойчивый ансамблевый классификатор со встроенной процедурой случайного сэмплирования (random oversampling). Основные преимущества ABB:
- Включает в себя два популярных ансамблевых алгоритма: бэггинг и бустинг;
- Содержит встроенную процедуру последовательного подбора гиперпараметров, которая позволяет получить модель высокого качества без длительного перебора гиперпараметров;
- Инструмент прост в использовании;
- Эмпирический анализ показывает, что ABB демонстрирует устойчивую работу и в среднем выдает качество выше, чем аналогичные алгоритмы.
Для несбалансированных выборок также разработан ImbalancedLearningClassifier , который подбирает оптимальную комбинацию балансирующей процедуры и классификатора для данной задачи. Основные преимущества инструмента:
- Включает в себя AutoBalanceBoost, а также комбинации наиболее популярных ансамблевых алгоритмов и балансирующих процедур из библиотеки imbalanced-learn;
- Инструмент достаточно прост в использовании и не требует длительного подбора гиперпараметров;
- Имеет встроенную процедуру подбора гиперпараметров для балансирующих процедур с помощью Hyperopt, время работы которого может контролироваться пользователем;
- Доступны несколько метрик оценки качества классификации.
Что такое транзакции и ACID — краткое обьяснение
Требования к версии Python: Python 3.8.
-
Установите требования из файла requirements.txt
pip install -r requirements.txt
pip install https://github.com/aimclub/asid/archive/refs/heads/master.zip
Обучение модели по малой выборке с помощью GenerativeModel и генерация синтетического датасета:
from asid.automl_small.gm import GenerativeModel from sklearn.datasets import load_iris X = load_iris().data genmod = GenerativeModel() genmod.
fit(X) genmod.sample(1000)
Обучение модели AutoBalanceBoost на несбалансированном датасете:
from asid.automl_imbalanced.abb import AutoBalanceBoost from sklearn.datasets import make_classification from sklearn.model_selection import train_test_split from sklearn.
metrics import f1_score X, Y = make_classification(n_classes=4, n_features=6, n_redundant=2, n_repeated=0, n_informative=4, n_clusters_per_class=2, flip_y=0.05, n_samples=700, random_state=45, weights=(0.7, 0.2, 0.05, 0.05)) X_train, X_test, y_train, y_test = train_test_split(X, Y, test_size=0.2, random_state=42) clf = AutoBalanceBoost() clf.fit(X_train, y_train) pred = clf.predict(X_test) score = f1_score(y_test, pred, average=»macro»)
Подбор оптимальной схемы классификации для несбалансированного датасета с помощью ImbalancedLearningClassifier (поиск производится среди AutoBalanceBoost, а также комбинаций наиболее популярных ансамблевых алгоритмов и балансирующих процедур из библиотеки imbalanced-learn):
from asid.automl_imbalanced.ilc import ImbalancedLearningClassifier from sklearn.datasets import make_classification from sklearn.model_selection import train_test_split from sklearn.
metrics import f1_score X, Y = make_classification(n_classes=4, n_features=6, n_redundant=2, n_repeated=0, n_informative=4, n_clusters_per_class=2, flip_y=0.05, n_samples=700, random_state=45, weights=(0.7, 0.2, 0.05, 0.05)) X_train, X_test, y_train, y_test = train_test_split(X, Y, test_size=0.2, random_state=42) clf = ImbalancedLearningClassifier() clf.fit(X_train, y_train) pred = clf.predict(X_test) score = f1_score(y_test, pred, average=»macro»)
Результаты эмпирического анализа алгоритмов ASID на различных датасетах доступны здесь.
Документация для ASID доступна по этому адресу.
Примеры использования доступны по этой ссылке.
Plesovskaya, Ekaterina, and Sergey Ivanov. «An Empirical Analysis of KDE-based Generative Models on Small Datasets.» Procedia Computer Science 193 (2021): 442-452.
Исследование проводится при поддержке Исследовательского центра сильного искусственного интеллекта в промышленности Университета ИТМО в рамках мероприятия программы центра: Разработка и испытания экспериментального образца библиотеки алгоритмов сильного ИИ в части базовых алгоритмов оценки качества и автоматической адаптации моделей машинного обучения под сложность задачи и размер выборки на основе генеративного синтеза комплексных цифровых объектов
Источник: github.com
Назначение идентификаторов с адресами (ASID)
В настоящее время я изучаю операционные системы от Сильбершаца, П. Галвина, Г. Ганье. Я изучаю стратегии управления памятью, а также раздел, где они вводят буфер ожидания перехода (TLB).
Некоторые TLB хранят идентификаторы адресного пространства (ASID) в каждой записи TLB. ASID уникально идентифицирует каждый процесс и используется для обеспечения защиты адресного пространства для этого процесса. Когда TLB пытается разрешить номера виртуальных страниц, он гарантирует, что ASID для текущего выполняемого процесса соответствует ASID, связанному с виртуальной страницей. Если ASID не совпадают, попытка рассматривается как промах TLB.
Выше приведена цитата из учебника, объясняющая ASID. Я немного смущен, поскольку промах TLB означает, что логический адрес не может быть сопоставлен в TLB, поэтому его нужно проверить с помощью таблицы страниц, чтобы двигаться к физической памяти.
При этом ASID является дополнительным битом для каждой записи в TLB, чтобы проверить, относится ли процесс, который обращается к этой записи, к процессу. Мне интересно, когда ASID используется для отказа от процесса, разве это не ловушка, а не промах TLB? Пропуск TLB пересылает процесс в таблицу страниц, где логический адрес процесса может быть сопоставлен с определенным адресом в основной памяти. Пожалуйста, помогите мне, где я неправильно понимаю. Спасибо!
Источник: progi.pro
Аппаратная виртуализация на практике: переход к практике
В прошлой статье я
кратко познакомил тебя с архитектурой AMD-V. В этой мы продолжим разбираться
с нелегкой темой. Я намерено упустил множество важных деталей относительно
механизма работы гипервизора, дабы с первого раза не перегружать твой мозг
большими объемами информации. Будем заполнять этот пробел.
Я буду приводить примеры и форматы регистров в Long Mode по ходу, поэтому
сразу следует сказать (или напомнить), что Long Mode — это режим работы
процессора, в котором работают все 64-битные ОС-и.
Инструкция VMRUN
Как ты помнишь из предыдущей статьи (ведь еще помнишь? :)) — инструкция VMRUN
запускает виртуальную машину. Состояние хоста сохраняется в специальной области
памяти, указатель на которую хранится в регистре VM_HSAVE_PA. А состояние
запускаемого гостя — загружается из VMCB (на которую указывает регистр rax).
Сегодня мы будем разбираться с этой чрезвычайно важной инструкцией, чтобы
успешно заполнить управляющий блок виртуальной машины и запустить гостевую
систему.
А верна ли VMCB?
VMRUN производит кучу проверок правильности контрольного блока виртуальной
машины (а то мало ли что мы ей подсунуть хотим). Если обнаруживается что-то
подозрительное и недопустимое, то нас посылают с кодом VMEXIT_INVALID (кстати,
некоторые коды VMEXIT я уже упоминал в предыдущей статье).
Итак, в каких же случаях VMRUN откажется запускать гостя? Буду перечислять
эти ситуации по пунктам, а тебе при прочтении рекомендую иметь перед глазами
структуру VMCB.
Заголовочный файл, содержащий VMCB:
1. Флаг в SVME в регистре EFER равен 0. Аппаратная виртуализация в госте
должна быть включена.
2. Сброшен бит CR0.CD и одновременно установлен CR0.NW. Первый бит
расшифровывается как Cache Disable — когда он установлен, инструкции и данные не
помещаются во внутренние кэши. А вот второй бит (по крайней мере, так написано в
мануале AMD) — вообще игнорируется. Странно, что VMRUN его проверяет при
сброшенном бите CD.
3. Старшие 32 бита CR0 не равны 0. Если ты посмотришь на формат регистра CR0
(в long mode), то увидишь, что эти биты должны быть равны 0.
4. В регистрах CR3, CR4, DR6, DR7, EFER не равны нулю биты, отмеченные как
MBZ (Must Be Zero).
5. ASID равен 0. ASID — это идентификатор адресного пространства, позволяющий
отличать элементы хоста от гостевых в ассоциативном буфере трансляции (TLB). То
есть поле ASID должно быть обязательно проинициализировано. На всякий случай
напомню, что TLB используется для ускорения преобразования виртуальных адресов в
физические. Наличие ASID-идентификатора позволяет избежать сброса TLB при каждом
входе и выходе из гостя. Что, конечно, положительно сказывается на
производительности.
6. Ошибочная инъекция события. Инжектированное событие — это прерывание или
исключение, выполняемое перед первой инструкцией гостя.
// Структура eventinj_t в VMCB описывает параметры инжектированного
события
typedef union
u64 bytes;
struct
u64 vector: 8; // номер прерывания или исключения
u64 type: 3; // тип события
u64 ev: 1; // бит, указывающий на правильность кода ошибки (поле errorcode).
u64 resvd1: 19; // зарезервированные биты
u64 v: 1; // Valid. Если этот бит установлен, событие инжектировано, если
сброшен — не инжектировано
u64 errorcode:32; // код ошибки
> fields;
> __attribute__ ((packed))
eventinj_t;
Вообще, возможных типов инжектированных событий (поле type) всего 4:
- 0 — INTR (внешнее прерывание);
- 2 — NMI (немаскируемое прерывание). Если мы укажем тип NMI, то поле
номера прерывания (vector) будет игнорироваться; - 3 — исключение;
- 4 — программное прерывание.
Если бит ev (Error code valid) установлен, то код ошибки errorcode будет
«затолкнут» в стек. В каких случаях инъекция события неверна? Например, если
гость в 64-битном режиме, а мы пытаемся инжектировать исключение #BR (вызывается
командой bound), невозможное в этом режиме. Мы также получим VMEXIT_INVALID,
если будем использовать зарезервированные значения поля type (1,5,6 или 7). Или
если мы укажем тип исключения, а номер вектора — 2, что соответствует NMI (это
немаскируемое прерывание, а не исключение!).
7. Биты EFER.LMA (Long Mode Active) или LME (Long Mode Enable), отвечающие за
активацию Long Mode, установлены, а процессор не поддерживает Long Mode. Вполне
логично, что такое сочетание будет признано невалидным.
8. Одновременная установка битов EFER. LME и CR0.PG (флаг включения
страничного преобразования адресов) при сброшенном бите CR4.PAE (или CR0.PE) —
недопустимая комбинация.
9. Флаги EFER.LME, CR0.PG, CR4.PAE (бит расширения физического адреса), CS.L
и CS.D одновременно установлены. CS — сегмент кода. Биты L и D содержатся в
дескрипторе сегмента. В 32-битном защищенном режиме бит D использовался для
указания размера операнда и адреса (32 или 16 бит), а бит L — это бит,
указывающий, что размер адреса и операнда у нас 64 бита. Теперь, я думаю, тебе
понятно, почему одновременная установка этих двух битов является ошибкой (то
есть мы указываем, что у нас одновременно по умолчанию установлен размер
операнда 64 и 32 бита).
10. Бит перехвата инструкции VMRUN (в области управления VMCB) сброшен — эта
инструкция должна перехватываться в обязательном порядке. Да, ты все верно
подумал. Действительно, можно вызывать VMRUN, уже находясь в режиме гостя. Вот
пример, связанный с Голубой пилюлей. Некоторым людям удавалось запускать более
20 (!) вложенных пилюль. Главное — правильно сделать перехват этой инструкции.
В VMCB бит перехвата VMRUN располагается в двойном слове по смещению 10h от
начала управляющего блока виртуальной машины и перехватить VMRUN можно так:
.
// Бит VMRUN_INTERCEPT имеет номер 0
pVmcb->general2_intercepts|=1;
.
Вообще, поле general2_intercepts помимо бита перехвата VMRUN содержит флаги
перехвата других инструкций из svm-расширения: VMMCALL, VMLOAD, VMSAVE, STGI,
CLGI и SKINIT, но перехватывать эти инструкции уже необязательно.
11. Физические адреса карты разрешения MSR (MSRPM) или ввода-вывода (IOPM)
равны или больше максимального поддерживаемого физического адреса. А иначе им
(картам) просто не хватит места! Карта разрешения MSR (как и ввода-вывода)
должна быть выровнена по границе 4 килобайта. И VMRUN игнорируются младшие 12
бит адреса MSRPM и IOPM. О картах, кстати, я упоминал в предыдущей статье.
Если VMCB верная, то можно продолжать. Теперь ты знаешь, чего делать нельзя.
Дальше поговорим о том, что можно и нужно :).
VMRUN после проверок и сохранения состояния хоста загружает следующую
информацию из контрольного блока виртуальной машины.
Первое, что обрабатывается VMRUN — это область состояния гостя (она же State
Save Area):
1. CS и rip — определяют, откуда начнет выполняться гость. CS — сегмент кода,
а rip — указатель инструкции в long mode (когда мы имели дело с 32-битами, у нас
был регистр eip).
2. Регистры rflags,rax.
3. SS (сегмент стека) и rsp — стек гостя. В 32-битном режиме был не rsp, a
esp :).
4. CR0, CR2 (в этом регистре содержится виртуальный адрес ошибки страницы —
page fault), CR3, CR4 и EFER — эти регистры отвечают за страничное
преобразование адресов в гостевой системе.
5. IDTR, GDTR(база и размер таблиц дескрипторов GDT и IDT),ES и DS, DR7 и
DR6.
6. V_TPR — виртуальный регистр приоритета задачи (TPR). Значение поля v_tpr
записывается в регистр CR8 гостя. Регистр приоритета задачи используется в
случаях, если, у нас, например, пришло какое-то «не очень важное» прерывание, а
выполняется какая-то задача, которую ну никак нельзя прервать. Тогда мы
записываем приоритет прерывания (например, 7) в регистр CR8 и все прерывания с
приоритетом меньше 7(включительно) будут игнорироваться.
7. V_IRQ. Этот флаг определяет, будет ли виртуальное прерывание отложено.
8. CPL или текущий уровень привилегий. Если гостевая система загружается в
реальный режим — CPL = 0, если в режим виртуального 8086, то 3. CPL определяет
кольцо защиты: 0 — нулевое, 3, соответственно, третье. После этого VMRUN
переходит к обработке области флагов (Control Area).
Здесь можно отметить так называемый TSC_OFFSET. Значение TSC_OFFSET
добавляется к счетчику меток реального времени (в мануалах — TSC) в госте, когда
тот решит получить его значение. То есть, когда мы выполним в госте команду
rdtsc, то к значению счетчика будет автоматически прибавлено значение TSC_OFFSET.
С этим полем связан известный баг (Erratum 140), когда при чтении TSC MSR через
rdmsr, а не rdtsc значение TSC_OFFSET не прибавлялось к счетчику.
Конечно, в Control Area мы можем указать множество различных событий или
инструкций, которые хотим перехватывать. Так же считывается уже
упоминавшийся идентификатор ASID и т.д.
В нашей структуре VMCB каждый сегмент описывается структурой segment_register
(код взят из Xen), содержащей части дескриптора сегмента и селектор на этот
дескриптор:
// структура, описывающая атрибуты сегмента
typedef union segment_attributes
uint16_t bytes;
struct
uint16_t type:4; /* 0; Bit 40-43 */
uint16_t s: 1; /* 4; Bit 44 */
uint16_t dpl: 2; /* 5; Bit 45-46 */
uint16_t p: 1; /* 7; Bit 47 */
uint16_t avl: 1; /* 8; Bit 52 */
uint16_t l: 1; /* 9; Bit 53 */
uint16_t db: 1; /* 10; Bit 54 */
uint16_t g: 1; /* 11; Bit 55 */
uint16_t pad: 4;
> fields;
>
__attribute__ ((packed)) segment_
attributes_t;
// Структура, описывающая сегмент в VMCB
struct segment_register
// селектор на дескриптор сегмента
uint16_t sel;
// атрибуты сегмента
segment_attributes_t attr;
// размер
uint32_t limit;
// адрес начала сегмента
uint64_t base;
> __attribute__ ((packed));
К атрибутам сегментов в VMCB предъявляются определенные требования.
Подробнее:
1. Не разрешен нулевой сегмент кода, поэтому воспринимаются аппаратурой
только некоторые биты в дескрипторе (D, L, R).
2. Регистр TR может иметь только тип TSS (напоминаю, что тип сегмента
определяется в дескрипторе сегмента).
3. У LDTR из атрибутов не игнорируется только бит присутствия сегмента (P).
Когда сработает какое-либо перехватываемое событие, управление получит
инструкция после VMRUN (впрочем, я об этом уже говорил). После VMRUN необходимо
разместить код проверки и обработки различных условий #VMEXIT.
Ядро гипервизора составляет цикл из VMRUN и обработки VMEXIT:
// основной цикл гипервизора (в общем виде)
// paVmcb — physical address vmcb
// vaVmcb — virtual address vmcb
do
// после каждого VMEXIT нужно устанавливать все перехваты заново, т.к. они
очищаются
InstallIntercepts(vaVmcb);
// передаем VMRUN физический адрес VMCB
_VMRUN(paVmcb);
// обработка кодов выхода из гостя
switch(vaVmcb->exitcode)
case VMEXIT_RDTSC:
.
break;
case VMEXIT_VMRUN:
.
break;
.
// другие обрабатываемые события
>
>while(1);
Для полного понимания сказанного тебе придется подтянуть знания защищенного
режима работы процессора (если ты не знаком с этой темой).
Создаем VMCB
Ну что, твоих знаний еще недостаточно для создания полноценного гипервизора?
Однако продолжаю потихоньку вводить тебя в курс дела :).
Что касается выделения блока памяти под VMCB и Host Save Area — это можно
сделать ядерной функцией MmAllocateContiguousMemorySpecifyCache. Ее прототип:
NTKERNELAPI
PVOID
MmAllocateContiguousMemorySpeci
fyCache(
IN SIZE_T NumberOfBytes, // количество выделяемых байт
IN PHYSICAL_ADDRESS LowestAcceptableAddress, // нижняя граница при выделении
памяти
IN PHYSICAL_ADDRESS HighestAcceptableAddress, // верхняя граница при выделении
памяти
IN PHYSICAL_ADDRESS BoundaryAddressMultiple OPTIONAL, // выравнивание региона
IN MEMORY_CACHING_TYPE
CacheType
);
В прошлой статье я упоминал, что для понимания кода понадобится опыт
разработки дров под Винду (ну или хотя бы минимальные знания, чтобы понимать
сорс). Примерный код для выделения памяти под VMCB:
..
l1.QuadPart = 0; // минимальный адрес для выделения
l2.QuadPart = -1; // максимальный адрес
l3.QuadPart = 0x10000; // выравнивание
// VMCB занимает 1 страницу, => uNumberOfPages = 1
// CacheType = MmCached
PageVA = MmAllocateContiguousMe
morySpecifyCache (uNumberOfPages *
PAGE_SIZE,l1, l2, l3, CacheType);
if (!PageVA)
return NULL;
// обнуляем выделенный регион
RtlZeroMemory (PageVA,
uNumberOfPages * PAGE_SIZE);
// получаем физический адрес выделенного региона
PagePA = MmGetPhysicalAddress
(PageVA);
.
Аналогичным образом память выделяется и для HSA, и для карт разрешения MSR и
IOIO.
Заключение
Вот и все на сегодня. Информации много, и, чтобы ее полностью переварить
(если тема для тебя новая), потребуется время. Помни, дорогу осилит идущий. А со
мной по-прежнему можно связаться по e-mail и написать свои предложения или
вопросы по содержанию статей (или просто пообщаться на тему аппаратной
виртуализации).
WWW
Broken Sword на wasm.ru, посвященный защищенному режиму:
Систематизировать знания (или пробелы заполнить) по Long Mode тебе помогут
следующие статьи.
Статья Криса Касперски «Архитектура x86-64 под скальпелем ассемблерщика»:
insidepro.com/kk/072/072r.shtml
Источник: xakep.ru