Post

Replies

Boosts

Views

Activity

Perform Hot Reset on PCI Device using PCIDriverKit
We are in the process of migrating a PCI device KEXT to DEXT and have developed a DriverKit extension using PCIDriverKit which matches with IOPCIDevice as its provider. We are able to match the driver to the device and access registers required to perform command operations. However, we are unable to perform hot reset on the device as per PCI specifications. The IORegistry structure for the matched driver is as follows, |-- pci-bridge@1 |-- IOPP |-- pci@0 (parent/provider to the driver) |-- myDriver Hot Reset was earlier implemented in KEXT by setting certain bits of register as per PCI spec from the pci-bridge provider object. We had called IOService-getProvider() - https://developer.apple.com/documentation/kernel/ioservice/1810088-getprovider iteratively to further retrieve the providers of the driver's provider object. By this process, we were able to retrieve the pci-bridge object necessary to perform hot reset. However, this method is not available in IOService of DriverKit Framework and performing the same reset operation from the direct provider object of the driver results in an unsuccessful operation. Is there any alternative to getProvider() in DriverKit? Are there any alternative methods to perform hot reset using PCIDriverKit? Is there a way of retrieving this pci-bridge object from the application side using IOKitLib APIs, passing it to the driver, casting it to IOPCIDevice and then using it? Is this approach feasible? Any help or suggestion would be greatly appreciated. Thanks in advance.
0
0
706
Apr ’21
DEXT crashes when accessing BAR0 offsets using MemoryWrite
We have developed a DEXT using PCIDriverKit with IOPCIDevice as its provider. DEXT crashes when accessing Memory Space using MemoryWriteXX APIs available in PCIDriverKit. We are following the below steps as specified in the Modernize PCI and SCSI drivers with DriverKit presentation. We are calling Open() in Start() as PCI DEXTs must open their provider prior to memory/configuration space access. However, this method returns kIOReturnNotOpen error code. This has already been posted as a separate question here. We are enabling bus master and memory space as this has to be done before issuing any memory reads/writes. Though Open() fails, we are still able to read/write to the device's configuration space using ConfigurationReadxx/ConfigurationWritexx APIs. As per the presentation, device memory mapping is done by PCIDriverKit and MemoryReadxx is working fine for reading offsets in a specific memory index (say BAR0). However, DEXT crashes when we try to use MemoryWritexx for writing to any offset (controller registers) in memory index 0 (BAR0). Our device has only BAR0 available. We verified from the crash log that the point of crash is the MemoryWrite method. Are there any other steps that have to be performed before writing to the memory space using MemoryWrite? Should the Open() call be successful in order to write to the memory space? If yes, how to open a session successfully without Open() returning an error code? The above steps were performed on a M1 machine. We executed the same steps on an Intel machine but even MemoryReadxx API fails there. Is this related to device memory mapping on an Intel machine? How to overcome this issue if PCIDriverKit takes care of device memory mapping? Any help or suggestions would be greatly appreciated.
4
0
1.4k
May ’21