American Megatrends предлагает BIOS для NVMe

Согласно пресс-релизу ком­па­нии Ame­ri­can Me­ga­trends, анон­си­ро­ван­ный про­дукт мо­жет быть клас­си­фи­ци­ро­ван как фрейм­ворк, по­зво­ля­ю­щий про­из­во­ди­те­лям mass stor­age под­сис­тем со­зда­вать го­то­вые ре­ше­ния с уче­том це­ле­вой ар­хи­тек­ту­ры NVMe-на­ко­пи­те­лей и плат­форм, с ко­то­ры­ми они бу­­дут ис­поль­зо­вать­ся.

Как из­вест­но, NVMe-на­ко­пи­тель — это PCI Ex­press ус­трой­ст­во, спо­соб­ное нес­ти на бор­ту ROM — но­си­тель ин­фор­ма­ции, со­дер­жащий UEFI-драй­вер, де­тек­ти­ру­е­мый и под­клю­ча­е­мый UEFI плат­фор­мы при стар­те, ана­ло­гич­но то­му, как это име­ет мес­то в ви­део адап­те­ре или SCSI-кон­т­рол­ле­ре. Этот драй­вер под­ме­ня­ет и/или до­пол­ня­ет функ­ции под­держ­ки NVMe-под­сис­те­мы, ре­а­ли­зу­е­мые сис­тем­ной пла­той.

Для чего это нужно?

Подключение Option ROM — программного модуля в составе твердотельного накопителя на шине PCI Express — осу­щест­в­ля­ет­ся регистрацией UEFI-протоколов, образующих набор сервисных API для обслуживания инициализации, чтение и записи устройства. Теоретически, при достаточной степени унификации и от­сут­ст­вии Vendor-Specific ре­сур­сов, поддержка NVMe-накопителя может быть выполнена исключительно средствами UEFI платформы.

На практике такой сценарий затруднен, так как расширение функциональности NVMe-устройств: поддержка ме­та­дан­ных, криптозащита информации, управление соответствием логических и физических устройств (name­space man­age­ment) требует обслуживания Device-Specific ресурсов проприетарным кодом. Вспомнив причины из­вест­ных проблем с установкой ОС семейства Windows XP на платах, оборудованных контроллерами RAID и AHCI, мож­но согласиться с тем, что встроенный Device-Specific драйвер необходим подсистеме хранения данных.

Что осталось за кадром?

Термин namespace, нередко упоминаемый в контексте NVMe подсистем, означает, доступное для использования про­ст­ран­ст­во накопителя. Обратим внимание на комментарий в презентации Flash Summit, к которому компания AMI без­ус­лов­но имела отношение:

«Today, creation/configuration of namespaces is vendor specific»

Одним из решений проблемы недостаточной унификации на уровне команд NVMe-контроллера является ком­плек­то­ва­ние устройства собственным UEFI-драйвером в виде Optional ROM.

Термин namespace management определяет управляющие функции UEFI, необходимые для формирования набора на­ко­пи­те­лей, доступного операционной системе. Как показано на иллюстрации ниже, в общем случае, топология под­клю­че­ния контроллеров и физических устройств может инкапсулироваться низкоуровневым программным обес­пе­че­ни­ем, а множество дисков, декларируемое UEFI-протоколами, не всегда тождественно множеству ус­та­нов­лен­ных фи­зи­че­ских устройств.

В примере на иллюстрации, к порции дискового пространства (NS B), расположенной на физическом устройстве, воз­мо­жен доступ со стороны двух хост-контроллеров, которые в общем случае могут быть подключены к раз­лич­ным пор­там PCIe, возможно расположенным на разных хост-платформах, что подразумевает функции арбитража и син­хро­ни­за­ции, осо­бен­но актуальные для двухпортовых NVMe-устройств.

Интерфейс UEFI станет человечнее?

Своеобразной интригой остается общий подход к реализации конфигурирования. Логично предположить, что в де­ло дол­жна вступить технология HII (Human Interface Infrastructure или Human Interface Interconnect), по­зво­ля­ю­щая ин­те­гри­ро­вать Setup-утилиты, реализованные в процедурах Option ROM в состав CMOS Setup платформы, уни­фи­ци­руя уп­рав­ле­ние опциями для firmware системной платы и периферийных устройств из единого центра, ко­то­рым дол­жен стать UEFI Setup.

В ряде случаев, встроенное программное обеспечение, находящееся в Option ROM и расширяющее возможности UEFI системной платы, может потребовать наличия собственных настраиваемых опций или средств диагностики, а значит выделенной Setup-утилиты с независимым user-интерфейсом, что достаточно неудобно, особенно в сер­вер­ных платформах, содержащих большое количество плат расширения.

Концепция HII предполагает цен­тра­ли­зо­ван­ный подход: редактирование всех настроек должно осуществляться в Setup платформы. Для этого firm­ware плат расширения, которое хранится в Option ROM, передает UEFI системной платы специальный набор де­ск­рип­то­ров, описывающих GUI-объекты. Таким образом динамически создается ин­тер­фейс пользователя, еди­но­об­раз­но об­слу­жи­ва­ющий функциональность встроенных и подключаемых устройств.