Создание только способных к MSI устройств удара молнии

Apple строго рекомендует создать только способные к MSI устройства Удара молнии. Гарантируйте, чтобы Ваши драйверы OS X включили MSI при поддержке устройств Удара молнии. Для упрощения разработки Mac Pro, компьютеры имеют слоты PCIe та поддержка MSI.

Службы OS X все прерывания на CPU 0 и использовании вторичный контекст прерывания распараллеливают для задержки работы к прерываниям уровня задачи, а не уровням основного прерывания. Этот метод гарантирует, что многократные драйверы могут работать параллельно на доступном CPUs, что OS может запланировать потоки в реальном времени с точностью, и что система остается быстро реагирующей к взаимодействию с пользователем. Методы наиболее успешной практики, описанные в Основных принципах IOKit, мотивируют использование модели абстракции IOWorkLoop для драйверов устройств для задержки работы к потоку IOWorkLoop. Может быть небольшое количество устройств, требующих, чтобы работа была сделана в основном контексте прерывания, однако, драйверы должны провести наименьшее количество количества времени, возможного в контексте основного прерывания.

Обработка аппаратных исключений для поддержки MSI

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

1. Фильтр вызывают, но устройство не сигнализировало прерывание.

   Это может быть вследствие другого устройства, совместно использующего тот же контакт прерывания. Подпрограмма фильтра должна возвратиться false.

2. Фильтр вызывают, и устройство сигнализировало прерывание.

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

3. Фильтр вызывают, и устройство сигнализировало прерывание.

   1. Драйвер может обработать прерывание на этом уровне и возвратить устройство не состоянию прерывания. Если действие прерывания должно быть выполнено, подпрограмма фильтра должна вызвать signalInterrupt().

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

      Подпрограмма фильтра должна препятствовать тому, чтобы устройство сигнализировало другое прерывание и затем вызвать signalInterrupt() заставить действие прерывания быть выполненным. Действие прерывания должно обработать прерывание и возвратить устройство состоянию, где это может снова сигнализировать прерывание. Подпрограмма фильтра должна возвратиться false.

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

int    index  = 0;

int    source = 0;

for ( index = 0; ; index++ )

{

         IOReturn result      = kIOReturnSuccess;

         int interruptType    = 0;

         result = provider->getInterruptType ( index, &interruptType );

         if ( result != kIOReturnSuccess )

               break;

         if ( interruptType & kIOInterruptTypePCIMessaged )

        {

            source = index;

            break;

        }

}

Используя работу замены в горячем режиме с устройствами PCI

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

Пользователь может свободно отключить устройства Удара молнии в любое время, за исключением устройств хранения, и должен быть в состоянии спать и разбудить систему с устройствами, присоединенными, не вызывая проблем. Для всех устройств пользователь не должен быть в состоянии подвесить систему (компьютер) путем отключения устройства или кабеля.

Драйверы устройств PCI, используемые с устройствами Удара молнии, возможно, должны быть обновлены для обработки удивления или незапланированного удаления. В частности циклы MMIO и доступы Конфигурации PCI требуют особого внимания. Когда устройство PCI, подключенное к порту Thunderbolt, отсоединяется от системы, Корневой порт PCIe должен привести к таймауту любых выдающихся транзакций, отправленных в устройство, завершить транзакцию, как будто Неподдерживаемый Запрос произошел на шине, и возвратите значение 0xFFFFFFFF. Корневой порт имеет значение тайм-аута завершения, которое является многими миллисекундами долго и варьируется в зависимости от системного расположения. Планирование в реальном времени, особенно для аудио и видео потоков, может быть затронуто транзакциями, которые должны быть приведены к таймауту.

Как основная инструкция, разработчики должны изменить свои драйверы для обработки возвращаемого значения 0xFFFFFFFF. Если какой-либо поток, обратный вызов, фильтр прерывания или путь выполнения кода в драйвере получают 0xFFFFFFFF указание устройство было отключено, тогда все потоки, обратные вызовы, фильтры прерывания, обработчики прерываний и другие пути выполнения кода в том драйвере, должно прекратить чтения MMIO и сразу пишет, и подготовитесь к завершению.

Если 0xFFFFFFFF юридическое значение для определенного смещения регистра, одного дополнительного чтения различного регистра, который, как известно, никогда не возвращается 0xFFFFFFFF если устройство все еще подключается, предпочтительный механизм для определения. Наконец, если Набор I/O уже выполнил завершение и вызвал водительское willTerminate() метод, никакие дальнейшие доступы не должны быть выполнены.

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

Когда никакой дальнейший доступ не должен быть выполнен, Apple рекомендует контролировать использование записей MMIO. Записи MMIO являются отправленными транзакциями, и для драйверов устройств возможно стоять в очереди многократные записи подряд.

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

Перечисление 3-2  единственная подпрограмма узкого места (чтение-запись MMIO)

class AppleSamplePCI

{

      ...

      bool                     fDeviceRemoved;

      volatile unit8_t *       fBaseAddressRegister;

      ...

      unit32_t        ReadRegister ( uint32_t  offset );

      virtual bool    willTerminate ( IOService * provider, IOOptionBits options );

};

unit32_t

AppleSamplePCI::ReadRegister ( unint32_t offset )

{

         unint32_t   result = 0xFFFFFFFF;

         if  ( !fDeviceRemoved )

         {

                result = OSReadLittleInt32 ( fBaseAddressRegister, offset );

                if ( result == 0xFFFFFFFF )

                    fDeviceRemoved = true;

         }

         return result;

}

bool

AppleSamplePCI::willTerminate ( IOService * provider, IOOptionBits options )

{

         fDeviceRemoved = true;

         return super::willTerminate ( provider, options );

}

Подобные подпрограммы могут быть записаны для транзакций цикла Конфигурации PCI, которые могут получить возвращаемое значение 0xFFFFFFFF и чтения MMIO меньших размеров.

<key>IOPCIPauseCompatible</key>

<true/>

static const IOPMPowerState powerStates[kYourDriverPowerStateCount] = {

    // version, capabilityFlags, outputPowerCharacter,

    // inputPowerRequirement, staticPower, unbudgetedPower

    // powerToAttain timeToAttain settleUpTime

    // timeToLower settleDownTime powerDomainBudget

    // Device off; inputPowerRequirement is 0,

    // which matches the flags for kIOPCIDeviceOffState.

    { kIOPMPowerStateVersion1, 0, 0,

      0, 0, 0,

      0, 0, 0,

      0, 0, 0 },

    // Sleep mode; inputPowerRequirement has kIOPMSoftSleep flag set,

    // which matches the flags for kIOPCIDeviceDozeState.

    { kIOPMPowerStateVersion1, 0, kIOPMSoftSleep,

      kIOPMSoftSleep, 0, 0,

      0, 0, 0,

      0, 0, 0 },

    // Device paused; inputPowerRequirement has kIOPMConfigRetained flag set,

    // which matches the flags for kIOPCIDevicePausedState.

    { kIOPMPowerStateVersion1, kIOPMConfigRetained, kIOPMConfigRetained,

      kIOPMConfigRetained, 0, 0,

      0, 0, 0,

      0, 0, 0 },

    // Device active; inputPowerRequirement has kIOPMPowerOn flag set,

    // which matches the flags for kIOPCIDeviceOnState.

    { kIOPMPowerStateVersion1, kIOPMPowerOn | kIOPMUsable, kIOPMPowerOn,

      kIOPMPowerOn, 0, 0,

      0, 0, 0,

      0, 0, 0 }

};