1x PCIe чтобы управлять всем +10


Введение

Высокоскоростные интерфейсы PCIe стали неотъемлемой частью современных процессоров. Производители чипов конкурируют в количестве интегрированных линий PCIe, что влияет на возможности ввода/вывода вычислительных платформ, требования к которым постоянно растут.

Несмотря на развитие технологий, производители серверных решений не спешат использовать интерфейс PCIe для выполнения функций управления платформой. Вероятно это связано с вызовами и издержками, которые неизбежно возникают при переходе на новые архитектурные решения.

Между тем, использование PCIe в качестве интерфейса управления платформой потенциально несет ряд преимуществ, например положительно влияет на общую готовность и надежность системы, снижает издержки дизайна при масштабировании платформы, повышает скорость и снижает задержки при обмене информации внутри системы управления платформой.

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

Преимущества

Мультплексирование

В традиционной модели интерфейс управления платформой предназначен для:

  • Мониторинга состояния платформы: температура, напряжение, скорость вращения вентиляторов, состояние источников питания, наличие ошибок шины, физическая безопасность системы, и др.

  • Адаптивного управления охлаждением и питанием платформы.

  • Журналирования различных событий, в том числе событий сбоев и выхода контролируемых параметров за пределы допустимых значений.

  • Нотификации удаленных получателей об изменениях в состоянии платформы и происшествиях.

  • Предоставления удаленного доступа к управлению платформой, ее состоянию и инвентарной информации о ней.

  • Предоставления удаленного интерфейса для отладки и диагностики серверного ПО.

Типичной реализацией интерфейса управления платформой является отдельная микропроцессорная система — система управления платформой, расположенная на серверной плате. Система управления платформой функционирует безотносительно состояния самой платформы. Центральным звеном системы управления платформой является BMC (Board Management Controller). В зависимости от решения, в систему управления платформой могут включаться различные устройства, а также другие контроллеры. BMC соединяется с серверной платформой различными интерфейсами.

Долгое время для интерфейса управления платформой использовался стандарт IPMI[1], изначально появившийся в 1998м году, и прошедший ряд итераций и расширений. В настоящее время этот стандарт морально устарел и рынок серверных решений постепенно переходит на стандарты PMCI[2] и Redfish[3] от DMTF.

Количество различных соединений между серверной платформой и BMC может исчисляться десятками линий. Так, программное обеспечение для управления системой на сервере имеет доступ к системе управления платформой через системный интерфейс (LPC, eSPI или I2C). Кроме того, практически повсеместно используются следующие интерфейсы:

  • последовательный интерфейс (UART) для перенаправления системной консоли до удаленного клиента.

  • высокоскоростной интерфейс (PCIe) для перенаправления видео и звука до удаленного клиента.

  • высокоскоростной интерфейс (USB или PCIe) для организации виртуальных устройств хранения (virtual media).

  • высокоскоростной сетевой интерфейс (RMII или PCIe) для стороннего обмена через сетевой контроллер серверной платформы.

  • Jtag интерфейс для организации удаленной отладки серверного ПО.

  • низкоскоростные интерфейсы для обмена информацией между устройствами системы управления платформой.

  • набор сигнальных линий для передачи различных состояний и статусов от серверной платформы, и в обратную сторону.

На рисунке ниже представлена типовая схема соединений между серверным процессором (Host CPU) и BMC.

Каждый из интерфейсов требует физических соединений. Большое количество соединений, размещенное на плате и не связанное с полезной нагрузкой серверной платформы, ограничивает число соединений для самой серверной платформы. Поэтому минимизация числа интерфейсов между платформой и системой управления платформой имеет значение. Более того, снижение числа соединений также либо снижает необходимую площадь чипов (как серверного, так и BMC), либо позволяет использовать имеющуюся площадь более оптимально.

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

Таким образом, множество физических соединений разного назначения возможно заменить несколькими функциями оконечного устройства на единственной шине PCIe.

На рисунке ниже представлена схема соединений серверного (Host CPU) процессора с BMC, когда большинство ранее представленных соединений заменено на функции единственного окончания на шине PCIe.

Соединения для GPU/Video и Virtual Media остаются неизменными по причине разницы в направленности соединений.

Скорость

В первом стандарте PCIe, вышедшим в 2002м году, скорость передачи достигает 2,5 GT, что обеспечивает пропускную способность одной линии шины в 250МБ/с в каждом направлении. Второй стандарт позволяет передавать по одной линии уже 500МБ/с, третий до 1ГБ/с, а четвертый до 2ГБ/с. [4]

Для сравнения, широко использующаяся до сих пор шина LPC, формирующая базовые соединения между серверным процессором и BMC, имеет частоту 33МГц с пропускной способностью до 16,5МБ/с, а пришедшая ей на замену шина eSPI — 66МГц и до 33МБ/с соответственно. [5][6]

Подобное преимущество в пропускной способности одной линии PCIe позволяет мультиплексировать несколько функций в одном окончании, не опасаясь превысить пропускную способность канала. Более того, это позволяет выделить большую пропускную способность на те каналы связи, которые традиционно были медленными, но требования к скорости которым выросли. Например, так выросли требования к системному интерфейсу с переходом от стандарта IPMI к DMTF Redfish (в DMTF стандарте он называется Host Interface), т. к. количество данных передаваемых по этому интерфейсу значительно возросло.

Одним из примечательных следствий наличия высокой скорости обмена между BMC и серверным процессором является возможность загрузки встроенного ПО сервера быстрее, чем загрузка по таким интерфейсам как: NAND, SPI, SD или EMMC, которые часто используются в существующих решениях. Этот факт открывает возможность активного использования шины PCIe в качестве альтернативного способа загрузки или обновления встроенного ПО на сервере. В свою очередь возможность обновления встроенного ПО сервера или восстановления работоспособности сервера (в случае повреждения хранимых образов) без необходимости прямого доступа к хранилищу встроенного ПО сервера привносит дополнительный элемент защиты системы от нежелательного проникновения со стороны BMC.

Масштабируемость

Большое количество соединений между BMC и серверной платформой ограничивает возможность масштабировать их в случае многосокетных решений. Количество требуемого пространства на плате для репликации соединений на все узлы превысило бы разумные пределы. По этой причине производители ограничиваются одним узлом, которому отводится роль связи с системой управления платформой.

На рисунке ниже показаны варианты решений на основе процессоров Inte, использующие PCH, а также процессоры других производителей, у которых соединение к BMC происходит напрямую с одним из серверных узлов.

Когда количество физических соединений между BMC и серверным процессом сравнительно невелико, то процесс репликации этих соединений для нескольких сокетов становится достаточно прямолинейным, а площадь платы, требуемая на разводку этих соединений, остается в пределах разумного.

На рисунке ниже показаны варианты соединения BMC, имеющим единственную линию PCIe, и с несколькими линиями.

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

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

Примеры использования

В этой части будут представлены варианты использования того, какие функции могли бы выполняться на каждом узле (окончании PCIe) для выполнения задач системы управления платформой.

Cтатус загрузки

Одним из требований к интерфейсу, по которому рапортуется статус загрузки, является доступность на ранних стадиях, чтобы код, исполняющийся в это время, мог рапортовать прогресс загрузки. Для этого драйвер интерфейса должен быть как можно более прост, чтобы его можно было легко отладить и поместить даже в ROM.

Известные мне дизайны серверных платформ используют два варианта физических интерфейсов для сообщения прогресса загрузки системы: набор GPIO сигналов, или ведомый I2C.

В случае использования GPIO одним из недостатков было выделение 8 сигнальных линий исключительно для передачи статуса загрузки, тогда как в остальное время эти линии не использовались. Вторым недостатком был тот факт, что смена статуса предполагала изменения нескольких сигналов сразу, которые менялись хоть и сразу один за другим, но все-таки последовательно. Такая смена приводила к наличию транзиентных состояний сигналов и возможности считывания неверных значений статусов.

В случае с интерфейсом I2C возникали задержки с чтением статуса в следствие низкой скорости обмена.

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

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

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

Репликация соединения в многосокетных решениях дополнительно позволяет следить за загрузкой каждого узла по отдельности.

Виртуальные GPIO

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

Оконечное устройство PCIe может реализовать функцию набора виртуальных GPIO в том количестве, которое необходимо для передачи любой статусной информации в обе стороны. Это могут быть сигналы для конфигурации загрузки (bootstrap) системы, сигналы различных ошибок или состояния оборудования.

Системный (хост) интерфейс

Оконечное устройство PCIe на серверном процессоре может реализовать как традиционные системные интерфейсы IPMI (KCS, BT, SMIC), так и Redfish хост интерфейс. В последнем случае, окончание будет эмулировать Ethernet интерфейс.

PLDM. Замена IPMB

Современные серверные процессоры содержат в себе сопроцессоры, отслеживающие и управляющие состоянием связанных с процессором параметров — температура, входящее напряжение, ток, потребляемая мощность. Традиционно сопроцессоры были соединены с BMC через выделенные каналы связи (IPMB) и входят в общую систему управления платформой как дополнительные управляющие контроллеры.

Оконечное PCIe устройство на серверном процессоре может реализовать окончание протокола MCTP с поддержкой PLDM сообщений и стать частью системы управления платформой, выставляя набор сенсоров и элементов управления, реализуя необходимый набор команд из соответствующих спецификаций DMTF PLDM.

NC-SI

Наиболее распространенным решением в дизайнах серверных платформ является наличие двух способов сетевого доступа к системе управления платформой — выделенный сетевой порт для сети управления, и сторонний доступ через сетевой порт серверной платформы (sideband interface, NC-SI).

Обычно серверный сетевой порт, через который осуществляется сторонний доступ к BMC разведен как отдельный LAN чип (LOM — LAN on motherboard), но также встречались решения, когда сетевой порт был частью серверного процессора. И в том и другом случае сторонний канал (NC-SI) был отдельным физическим интерфейсом RMII, выведенный либо с LOM, либо с серверного сокета, и соединенный напрямую с BMC.

В случае когда один или несколько сетевых портов встроены в серверный чип, реализация окончанием PCIe на процессоре поддержки NC-SI через MCTP позволяет организовать сторонний сетевой доступ к BMC из любого узла в многосокетном дизайне без усложнения системной платы.

Недостатки и вызовы

Разобрав преимущества и возможные случаи применения PCIe как интерфейса управления платформой, следует также обратить внимание, какие вызовы и недостатки такое решение несет.

Сложность

Простота работы с PCIe устройством на программном уровне является безусловным преимуществом. Однако эту простоту обеспечивает изрядная сложность аппаратного обеспечения. Передатчики, машина состояний, логика реализованных оконечных аппаратных функций и устройств несоразмерно (на несколько порядков) выше, чем при работе с интерфейсами I2C, SPI или GPIO.

С одной стороны реализация набора логики для всех функций PCIe окончания влечет несоразмерно больший транзисторный бюджет по сравнению даже с несколькими I2C, SPI и GPIO интерфейсами вместе взятыми. С другой стороны экономия на контактных площадках должна компенсировать эти потери.

Потребление питания

Интерфейсы I2C и SPI известны экономностью потребления, тогда как затраты на питание PCIe интерфейса значительно выше. С другой стороны, шина PCIe запитывается только во время работы серверной платформы, и даже в активном использовании шины затраты на нее на несколько порядков ниже затрат питания на основную функцию процессора — вычисления и ввод/вывод. Кроме того, опыт использования PCIe в мобильных, энергоемких устройствах привел к вводу новых, энергоэффективных состояний передатчиков PCIe, при которых затраты на потребления уменьшаются в десятки и сотни раз.

Разработка и дизайн

Безусловно, разработка целого ряда аппаратных устройств потребует значительных инвестиций в их разработку, дизайн и отладку. Хорошим подспорьем в данном случае было бы вынесение части данной работы, касающейся разработки интерфейсов или протоколов, на откуп объединенных рабочих групп производителей. В этом случае решение бы априори устраивало и было бы востребовано частью рынка, а значит подключило бы и другие заинтересованные стороны к разработке необходимого аппаратного обеспечения на основе разработанных спецификаций, упростив ввод новой архитектуры в эксплуатацию.

Заключение

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

Ссылки на источники




Комментарии (17):

  1. redneko
    /#24340490

    Хорошая попытка была у Intel с их AMT на базе чипсета, который имеет доступ ко всем интерфейсам. Но завязка на встроенный GPU в процессор и остальные косяки, такие как закрытость решения и собственные костыли, пилящиеся, по ощущениям, по остаточному принципу убили хорошее начинание. Есть материнка - уже не дектоп, но еще не сервер от gigabyte, и на ней с AMT то тут, то там вылезают косяки. То расшаренный сетевой интерфейс тупит с руганью в dmesg, то рвется коннект к консоли в MeshCommander. Монтирование iso в принципе не работает - виртуальный DVD впадает в бесконечный цикл подключения и отключения USB-устройства.

    • vadimr
      /#24340588

      Поэтому в серверных платформах на AMT забивают и лепят вендорский BMC.

  2. vadimr
    /#24340566 / +3

    Вообще-то BMC обязан работать при выключенном питании сервера (или при неисправности / ошибке настроек, исключающей возможность успешного включения материнской платы и инициализации PCI). Он именно для этого и нужен.

    Зачем нужен такой BMC, который работает только при работе PCIe, я затрудняюсь представить. Тогда уж проще удалённо админить средствами ОС.

    • BiosUefi
      /#24340912 / +2

      Типичной случай, АМД сервер умирает ещё до запуска биоса. Внутри AMDшного PSP кода.

      О каком PCIe тут можно говорить?

    • n2dt4qd2wg9b
      /#24342320

      Так он и будет работать отдельно. Когда линк подымется, то будет взаимодействовать.

      • Kitsok
        /#24342484 / +2

        Какой тогда в нем смысл? Любая проблема на этапах BIOS/UEFI до инициализации PCIe становится не диагностируемой.

        • n2dt4qd2wg9b
          /#24343244 / +1

          Смысл в том, и я видел это в железе, что прошивка BMC может участвовать в инициализации и управлении PCIe устройств.

          Любая проблема вылезет до перезагрузки сервера, а значит с большой вероятностью попадет в SEL LOG BMC. А уж если PCIe init не прошел, то всегда можно это увидеть на экране через удаленное видео.

          • Kitsok
            /#24346532

            Каким образом BMC может участвовать в инициализации PCIe root root complex хоста?

            BMC может (и должно) дергать линии типа Reset, Power Enable, идущие в сторону устройств, но вот как средство взаимодействия BMC и хоста (точнее даже, сервисного процессора хоста, как его не назови) PCIe, на мой взгляд, слишком сложно.

            Что касается проблемы и SEL, то хост может и не загрузиться, банально битая планка памяти, и всё, до DXE фазы дело не дойдет. В классической схеме мы это увидим по пост коду (который будет очень очень простым и надежным образом получен по LPC, eSPI или от сервисного процессора по UART, например), а если у нас только PCIe, то как? До инициализации PCIe дело не дойдёт, у хоста памяти-то нету, только кэши.

    • dmirr
      /#24343378

      Вероятно, я плохо артикулировал это в статье - но сокеты сервера - это устройства PCIe для BMC. Он их включает/выключает и общается с ними по PCIe, когда возможно.

      Как устройство PCIe, сокет может инициализировать линк на этапе BOOT ROM, когда фирмварь даже не загружена. И т.к. на сокете реализованы несколько PCIe функций, то уже на этапе работы BOOT ROM BMC может следить за статусом загрузки, устанавливать различные параметры загрузки и, собственно, передавать по линку сам образ ПО, если флэш сервера еще ни разу не прошивали.

      Мой опыт в работе с железом говорит, что инициализация PCIe на таких ранних этапах вполне возможна. Посмотрите к примеру, что творят NXP в их I.MX6/8 SoC.

      • vadimr
        /#24343400

        А кто реализует в таком случае распределение ресурсов на шине PCIe? Как я понял, вы предлагаете фактически либо двойную загрузку, поочерёдно BMC и BIOS, либо первоначальную загрузку целиком силами BMC. Но устройства-то сами согласятся ли быть слейвами у BMC?

        Например, одним из устройств PCIe может быть какой-нибудь аппаратный модуль доверенной загрузки, который сам контролирует дальнейшую работу BOOT ROM в зависимости от различных условий. Это всё само по себе требует определённых танцев с бубнами вокруг настроек BIOS для своей работоспособности, а в случае, если этим будет заниматься BMC, это всё приведёт в лучшем случае к повисанию BMC в определённых ситуациях, а в худшем – к неработоспособности системы в принципе.

        • dmirr
          /#24343646

          Что касается ресурсов PCIe, то речь в статье идет об отдельной иерархии management PCIe, где BMC является хостом, а серверные сокеты в ней - устройства. В этой иерархии рутовый комплекс находится в BMC и тот занимается инициализацией устройств на сокетах. Но речь, опять же, о тех IP внутри серверных SoC, которые находятся в домене platform management и не относятся к серверной функции. Т.е. те, что отвечают за коммуникацию информации между серверным сокетом и BMC.
          За инициализацию устройств в иерархии PCIe сервера отвечает само ПО сервера.
          Что касается загрузкт, то загрузка самого сервера начинается с инициализации SoC. Так например, при включении сокет проверяет бутстрап пины для определения конфигурации загрузки. В статье я предлагаю выбросить эти пины, заменив их IP блоком/PCIe функцией в домене platform management, которая бы захватывала загрузочную конфигурацию по шине (через виртуальные GPIO). А сама загрузка сервера вполне может происходить как обычно - с бут флэша. С т.з. серверного ПО все эти изменения будут видны лишь на самых ранних этапах, возможно до запуска BIOS. У BIOS остаются все те же функции и ответсвенность.

          • lelik363
            /#24344550

            Какой сценарий предусмотрен на случай, если линк PCIе на стороне серверного процессора не поднимется?

            то загрузка самого сервера начинается с инициализации SoC.

            Поясните, пожалуйста, что вы имели ввиду?

            • dmirr
              /#24345102

              Если линк не поднимается, значит либо не работает "железо", или BOOT ROM не способно выполнить функцию по его инициализации. BMC будет считать, что SOC неисправен.
              Инициализация SoC в данном случае - проведение "сброса" железа и этап работы BOOT ROM, до загрузки ПО из BOOT FLASH.

              • lelik363
                /#24345752

                Если линк не поднимается, значит либо не работает «железо», или BOOT ROM не способно выполнить функцию по его инициализации. BMC будет считать, что SOC неисправен

                И что делать дальше?

                • dmirr
                  /#24346242

                  Как-минимум - отпрапортовать проблему.

                  • lelik363
                    /#24346480

                    отпрапортовать проблему

                    Замечательно…
                    А что делать со служебными сигналами: THERMTRIP_N, ERROR_N[2:0] и т.д.? Они про PCIe ничего не знают. Кроме того, состояние этих сигналов обрабатывают не только BMC.

  3. lelik363
    /#24345750

    -