Доступ к PCIe мосту (для сброса PCIe платы)

[WWX]

Доброго времени суток.

Есть некая PCIe плата. Для того, чтобы корректно реализовать на ней сброс требуется доступ к конфигурационному пространству моста, к которому она подключена.
А именно в регистре моста "Bridge Control Register" (0x3E) на некоторое время установить (6-й) бит "Secondary Bus
Reset". (Во всяком случае в драйвере под Linux для этой платы делается именно так.)

Можно ли что-то подобное сделать под Windows 7 и Windows 10?

В запросе IRP_MN_QUERY_INTERFACE можно запросить следующие интерфейсы (но ни один из них полностью не подходит):

- BUS_INTERFACE_STANDARD - как я понимаю, даёт доступ только к своему конфигурационному пространству (но под Windows 7 работает).

- DEVICE_RESET_INTERFACE_STANDARD - (ещё не пробовал), но, судя по описанию, работает только под Windows 10.

- PCI_EXPRESS_ROOT_PORT_INTERFACE - вероятно делает то, что нужно (т. е. даёт доступ к конфигурационному пространству моста), но не очень документирован, и даже если его расковырять, то не уверен, следует ли так делать.

[Ochkarik]

вот тут инфа не поможет?
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/accessing-pci-device-configuration-space
через IRP_MN_WRITE_CONFIG request or the SetBusData method  или Within the ACPI BIOS?

[WWX]

Спасибо за ответ.

Про "ACPI BIOS" что-то не понял. Это третий метод доступа к конфигурационному пространству? Там вроде всего два метода...

"IRP_MN_WRITE_CONFIG" или "SetBusData" насколько я понимаю позволяют драйверу писать в конфигурационное пространство своего же устройства.

Точнее в пространство того устройства, чей адрес PDO (Physical Device Object) указывается.
По идее, если узнать адрес PDO или хотя бы адрес объекта любого устройства из стека DO нужного устройства, то можно было бы считать, что задача почти решена.

Но, похоже что: проблема в том, что PDO другого устройства в общем случае (а также в моём случае) нельзя узнать документированным способом.
Если кто-то опровергнет это утверждение, буду только рад.
("IoGetDeviceObjectPointer" в случае с мостом не работает (возвращает ошибку STATUS_INVALID_DEVICE_REQUEST).)

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

Собственно метод SetBusData и получается в результате запроса интерфейса BUS_INTERFACE_STANDARD, который я упомянул в первом сообщении.

Начинаю немножко понимать линуксоидов, для того, чтобы сделать то, что в Linux'е делается в две строчки, в Windows'е приходится писать дополнительный драйвер...

[Ochkarik]

похоже что действительно так. через фильтр.
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/obtaining-configuration-information-from-other-driver-stacks
хотя DeviceTree, по-моему, показывала весь стек включая PDO?

[WWX]

За ссылку - спасибо. (Почему-то я её пропустил (вот ведь как бывает), хотя и пришёл к правильному выводу.)

хотя DeviceTree, по-моему, показывала весь стек включая PDO?

Предположительно подобного рода программы могут использовать недокументированные возможности.

"pciscope", например, на ПК (на котором должна работать эта чудо плата) не заработал вообще.
Хотя этот ПК сам по себе очень странный, одних ядер там штук сорок...

[Ochkarik]

последняя версия DeviceTree - 2011 года и работает до сих пор) хорошие возможности)

[WWX]

Да, действительно работает, даже PDO показывает.
(Хотя моё устройство в PnP перспективе показала только после второго запуска, а мост показывала всегда. В Driver перспективе и мост и моё устройство также всегда показывала.)

Но при запущенном DeviceTree не получилось выгрузить драйвер из диспетчера устройств без перезагрузки системы.
Можно предположить, что эта программа использует что-то вроде "ObReferenceObjectByName" (недокументированная широко известная в узких кругах ф-ция (не для законопослушных драйверов)).

[Ochkarik]

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

[WWX]

Ух, постараюсь объяснить.

Дело в том, что раньше сброс этой платы осуществлялся путём записи в соответствующий регистр. При этом сбрасывалось (почти) всё на плате, включая сам контроллер PCI (но BAR'ы, насколько я понимаю, не сбрасывались).
Корень зла здесь в том, что наши доблестные жестянщики не сделали отдельный сброс всего кроме контроллера PCI.

И всё бы ничего, но нашёлся один ПК, на котором это приводило к Kernel Panic на Linux'е или BSoD'у на Windows'е.
Похоже что подобный сброс трактовался как внезапная потеря устройства, не поддерживающего внезапного удаления.

Если же мост выдаёт "Secondary Bus Reset" то состояние устройства игнорируется системой (ну или по крайней мере система не падает при "пропадании" устройства). Теперь, грубо говоря (но мягко выражаясь) firmware на плате ждёт этого сигнала и сбрасывает сам себя.

[Ochkarik]

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

[WWX]

Увы, сброс нужен не для установки драйвера, а для "нормальной" работы платы.
(В процессе работы её нужно периодически сбрасывать.)

[Ochkarik]

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

[WWX]

я имел в виду что при перезагрузке сброс же происходит один раз.

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

а если IRP_MN_SURPRISE_REMOVAL обработать? кто BSOD вызывал, драйвер устройства или драйвер шины одного единственного ПК?

Пробовал делать обработку IRP_MN_SURPRISE_REMOVAL - не помогло.

Максимум чего тогда (без фильтра) добился это в IRP_MN_QUERY_CAPABILITIES ставил "Removable" и "SurpriseRemovalOK".
При этом появлялась иконка в трее (наподобие извлечения флешки). Если т. о. через неё выгрузить драйвер, то можно один раз "безопасно" сбросить плату через кнопку сброса (эта кнопка расположена на самой плате). При повторном нажатии (равно как и при первом нажатии без подобной подготовки) ловится BSoD.
Но после такого сброса драйвер уже не загружается. Система ждёт, что плата исчезнет физически (но такой эксперимент чё-то не хочется проводить).
Видимо нужно было "Политику удаления" поменять с "1" на "3" (как у флешки). Но как это сделать я не нашёл.

А вот через фильтр вроде бы нормально сбрасывается.

BSoD вызывал точно не драйвер устройства, а вот кто именно - не особо понятно.
Собственно BSoD: 0x124: WHEA_UNCORRECTABLE_ERROR.

Рабочая гипотеза, что на плате присутствует аппаратный модуль, который бдит за состоянием устройств и в случае чего оповещает об этом ОС...