I've just shipped a signed NetworkingDriverKit driver for the Realtek RTL8127 10GbE PCIe NICs on Apple Silicon, source at https://github.com/stefb69/RTL812xLucy (directory RTL8127Dext). It runs at line rate (9.4 Gbit/s each way at MTU 1500, 9.9 with jumbo frames) with TSO, checksum offload and four TX queues by service class. Since there are very few public NetworkingDriverKit drivers to learn from, here is what cost me the most time, in case it saves someone else a week. Three of these are filed as feedback. TX packets from native Skywalk flows have a 2-byte data offset (FBxxxxxxxx). getDataVirtualAddress() / getDataIOVirtualAddress() return the buffer base; the frame starts at getDataOff(). BSD-path packets (ping, curl, ssh, DHCP) have offset 0, Network.framework flows (Safari, URLSession, App Store, codesign --timestamp) have offset 2. If you DMA from the base, everything "works" except every modern client, which sits in SYN_SENT. The headers don't mention it. getMaxTransferUnit() is the maximum MTU, not the current one (FBxxxxxxxx). It is read once at registerEthernetInterface() and becomes the hard ceiling for ifconfig mtu; return your current 1500 and jumbo frames fail with EINVAL before your dext is called. Don't call bpfAttach() on macOS 26.6 (FBxxxxxxxx). It worked once, then panicked the kernel inside IOSkywalkFamily when the dext was replaced while tcpdump was attached. Without it, tcpdump on your interface only sees host-path frames, not native flows, so debugging point 1 is done from the peer side. Smaller ones: the personality needs IOClass = IOUserNetworkEthernet and CFBundleIdentifierKernel = com.apple.iokit.IOSkywalkFamily, not IOUserService, or super::Start fails with 0xe00002bc. All queues are created disabled: setEnable(true) in setInterfaceEnable(), plus requestDequeue() on the TX queues when the link comes up. setMulticastAddresses() must be implemented or no multicast group is ever joined (mDNS and IPv6 solicited-node are silently dead). Release dispatch sources from the Cancel() completion block, not right after Cancel(), or the dext crashes at every upgrade. The dext bundle must be named .dext or the host app reports "Extension not found in App bundle". Dext os_log lines show up as kernel: messages with the .dext bundle as sender; use %{public}s. Performance question for Apple engineers: with eight or more parallel TCP senders at MTU 1500 the stack emits ~3 KB TSO packets at ~160k packets/s and the dext saturates one core around 4.5 Gbit/s (fine at MTU 9000, fine with one to four streams). Is IOUserNetworkPacketPoller the intended answer for per-packet cost in a NIC dext, and is there any guidance on batch sizes for IOUserNetworkTxSubmissionQueue dequeues?

I have a DriverKit system extension (dext) that uses PCIDriverKit. I would like to get the build environment straightened out to successfully distribute the dext and associated software to end users. There are three types of software involved: The Dext-hosting application - this is the application that must be installed to /Applications/, and will perform the registration of the dext. The dext is deployed "within" this application, and can be found in the /Contents/Library/SystemExtensions folder of the app bundle. The dext itself - this is the actual binary system extension, which will be registered by its owning application, and will operate in its own application space independent of the hosting application. Additional applications that communicate with the dext - these are applications which will connect to the dext through user clients, but these applications do not contain the dext themselves. There are multiple locations where settings need to be exactly correct for each type of software to be signed, provisioned, and notarized properly in order to be distributed to users: developer.apple.com - where "identifiers" and "provisioning profiles" are managed. Note that there are differences in access between "Team Agent", "Admin", and "Developer" at this site. Xcode project's Target "Signing & Capabilities" tab - this is where "automatically manage signing" can be selected, as well as team selection, provisioning profile selection, and capabilities can be modified. Xcode project's Target "Build Settings" tab - this is where code signing identity, code signing development team, code signing entitlements file selection, Info.plist options and file selection, and provisioning profile selection. Xcode's Organizer window, which is where you manage archives and select for distribution. In this case, I am interested in "Developer ID" Direct Distribution - I want the software signed with our company's credentials (Team Developer ID) so that users know they can trust the software. Choosing "automatically manage signing" does not work for deployment. The debug versions of software include DriverKit (development) capability (under App ID configuration at developer.apple.com), and this apparently must not be present in distributable provisioning. I believe this means that different provisioning needs to occur between debug and release builds? I have tried many iterations of selections at all the locations, for all three types of binaries, and rather than post everything that does not work, I am asking, "what is supposed to work?"

I have requested an entitlement for my DriverKit based driver, but the status is still in "Submitted" phase. I have also tried contacting Apple Support by phone/mail but to no avail [Case ID: 20000143721904]. Below are the details of my request. Is there any way to know the turnaround time or to expedite the process as this entitlement is necessary for the distribution of our app? Also, what is the preferrable way to follow up in such cases? Entitlement: com.apple.developer.driverkit.transport.pci - DriverKit PCI (PrimaryMatch) Team: 8S33FS7Q5Q Request Id - NZYWRD96U3 Requested At - August 13, 2026 Type - Team Status - Submitted Thank you, Abishek.

I am working on a DriverKit driver and we are subclassing IOUserSCSIParallelInterfaceController. I have implemented UserLogicalUnitResetRequest end-to-end and it sends a real Task management IU to the controller and returns the correct kSCSIServiceResponse_*. When I call the hook from within the dext manually it works but I am not able to invoke this UserLogicalUnitResetRequest from macOS. My question is, under what conditions does macOS itself invoke this hook (or the other five TMF hooks - abort/set, TargetReset, ClearACA/TaskSet)? I tried to insert a gate at the top of UserProcessParallelTask, which for one chosen target, swallows the incoming task without submitting it to the controller and without completing the OSAction. I then ran normal APFS filesystem IO against the target and observed following: Every stalled command arrives with SCSIUserParallelTask.fTimeoutInMilliSec = 0. The command hang indefinitely. None of the TMF hooks are ever invoked by the framework. I am not sure if I am doing something wrong here. Is fTimeoutInMilliSec = 0 on filesystem IO expected? Is there a way for the dext to surface a shorter deadline that the framework will watchdog? What actually invokes the TMF hooks- filesystem-IO timeout escalation, storage recovery, or is there an expectation that the dext runs its own per-command watchdog and invokes its reset code internally? Any help would be really appreciated! Thank you for your time!

Hello everyone, I am migrating a KEXT for a SCSI PCI RAID controller (LSI 3108 RoC) to DriverKit (DEXT). While the DEXT loads successfully, I'm facing a DMA issue: an INQUIRY command results in a 0-byte disk because the data buffer received by the DEXT is all zeros, despite our firmware logs confirming that the correct data was prepared and sent. We have gathered detailed forensic evidence and would appreciate any insights from the community. Detailed Trace of a Failing INQUIRY Command: 1, DEXT Dispatches the Command: Our UserProcessParallelTask implementation correctly receives the INQUIRY task. Logs show the requested transfer size is 6 bytes, and the DEXT obtains the IOVA (0x801c0000) to pass to the hardware. DEXT Log: [UserProcessParallelTask_Impl] --- FORENSIC ANALYSIS --- [UserProcessParallelTask_Impl] fBufferIOVMAddr = 0x801c0000 [UserProcessParallelTask_Impl] fRequestedTransferCount = 6 2, Firmware Receives IOVA and Prepares Correct Data: A probe in our firmware confirms that the hardware successfully received the correct IOVA and the 6-byte length requirement. The firmware then prepares the correct 6-byte INQUIRY response in its internal staging buffer. Firmware Logs: -- [FIRMWARE PROBE: INCOMING DMA DUMP] -- Host IOVA (High:Low) = 0x00000000801c0000 DataLength in Header = 6 (0x6) --- [Firmware Outgoing Data Dump from go_inquiry] --- Source Address: 0x228BB800, Length: 6 bytes 0x0000: 00 00 05 12 1F 00 3, Hardware Reports a Successful Transfer, but Data is Lost: After the firmware initiates the DMA write to the Host IOVA, the hardware reports a successful transfer of 6 bytes back to our DEXT. DEXT Completion Log: [AME_Host_Normal_Handler_SCSI_Request] [TaskID: 200] COMPLETING... [AME_Host_Normal_Handler_SCSI_Request] Hardware Transferred = 6 bytes [AME_Host_Normal_Handler_SCSI_Request] - ReplyStatus = SUCCESS (0x0) [AME_Host_Normal_Handler_SCSI_Request] - SCSIStatus = SUCCESS (0x0) The Core Contradiction: Despite the firmware preparing the correct data and the hardware reporting a successful DMA transfer, the fDataBuffer in our DEXT remains filled with zeros. The 6 bytes of data are lost somewhere between the PCIe bus and host memory. This "data-in-firmware, zeros-in-DEXT" phenomenon leads us to believe the issue lies in memory address translation or a system security policy, as our legacy KEXT works perfectly on the same hardware. Compared to a KEXT, are there any known, stricter IOMMU/security policies for a DEXT that could cause this kind of "silent write failure" (even with a correct IOVA)? Alternatively, what is the correct and complete expected workflow in DriverKit for preparing an IOMemoryDescriptor* fDataBuffer (received in UserProcessParallelTask) for a PCI hardware device to use as a DMA write target? Any official documentation, examples, or advice on the IOMemoryDescriptor to PCI Bus Address workflow would be immensely helpful. Thank you. Charles

I am developing a dext that is running into issues pertaining to IOConnectMapMemory (at least I think so). There are 3 parts of code that are involved, the dext (which allocates the memory in the first place), a user client library which is involved in connecting to the dext and releasing when the hardware is removed, and finally some processing code (at the user level) which executes on this shared block of memory from the dext. The shared memory is allocated using an IOBufferMemoryDescriptor: IOBufferMemoryDescriptor::Create(kIOMemoryDirectionNone, sizeof(sharedMemoryBlock), IOVMPageSize, &(ivars->mSharedMemoryBlockMemDesc)); The User Client Library acquires a mapped pointer to this memory by calling IOConnectMapMemory: IOConnectMapMemory(mConnect, kMemoryType_SharedMemoryBlock, mach_task_self(), (mach_vm_address_t*)&mUserClientSharedBlockPtr, (mach_vm_size_t*)&mSizeOfUserClientSharedBlock, kIOMapAnywhere); …which triggers the dext’s IOUserClient subclass' “CopyClientMemoryForType_Impl”. That code adds a retain and returns a pointer to the IOBufferMemoryDescriptor: case kMemoryType_SharedMemoryBlock: // error checks first (make sure it’s allocated and initialized, etc) ivars->mSharedMemoryBlockMemDesc->retain(); *memory = ivars->mSharedMemoryBlockMemDesc; break; IOConnectMapMemory returns the “mapped pointer” (in mUserClientSharedBlockPtr) to the User Client Library, which in turn provides it to the processing code. The processing code checks the pointer validity, and if valid, runs its processing. This worked fine with a kext implementation. This fails with dext implementation, because during the processing call (after validity check but during usage) the mapped pointer can become NULL, which seems to be against the design pattern, and causes the application to crash due to an access violation (dereferencing NULL). I assume I am doing something incorrect here, but I’m not seeing what it is. The memory was retained, so it should not be deleted until the User Client Library has released it, but the only release available would be IOConnectUnmapMemory, and that fails with “invalid argument” (0xE00002C2) after the device is hot-unplugged. I am not finding IOConnectMapMemory examples on developer.apple.com. I have verified via the forums that IOConnectMapMemory is still a recommended practice with DriverKit development: https://developer.apple.com/forums/thread/803947?answerId=862249022#862249022 . What’s the trick here for stability? The device is a peripheral which can be unplugged or turned off at any time, which would result in the dext and user client library code tearing down the structures and memory, but it should be able to do so safely without causing access violations. (Note, this has been simplified for the purpose of focusing the question, in reality there are 4 separate memory blocks which are shared in this fashion: two ring buffers, main engine status, and client status. They each use their own memory_type definition, but a general solution is needed and can be applied to all 4, and there can be multiple clients at any point in time).

Hello everyone, We are migrating our KEXT for a Thunderbolt storage device to a DEXT based on IOUserSCSIParallelInterfaceController. We've run into a fundamental issue where the driver's behavior splits based on the I/O source: high-level I/O from the file system (e.g., Finder, cp) is mostly functional (with a minor ls -al sorting issue for Traditional Chinese filenames), while low-level I/O directly to the block device (e.g., diskutil) fails or acts unreliably. Basic read/write with dd appears to be mostly functional. We suspect that our DEXT is failing to correctly register its full device "personality" with the I/O Kit framework, unlike its KEXT counterpart. As a result, low-level I/O requests with special attributes (like cache synchronization) sent by diskutil are not being handled correctly by the IOUserSCSIParallelInterfaceController framework of our DEXT. Actions Performed & Relevant Logs 1. Discrepancy: diskutil info Shows Different Device Identities for DEXT vs. KEXT For the exact same hardware, the KEXT and DEXT are identified by the system as two different protocols. KEXT Environment: Device Identifier: disk5 Protocol: Fibre Channel Interface ... Disk Size: 66.0 TB Device Block Size: 512 Bytes DEXT Environment: Device Identifier: disk5 Protocol: SCSI SCSI Domain ID: 2 SCSI Target ID: 0 ... Disk Size: 66.0 TB Device Block Size: 512 Bytes 2. Divergent I/O Behavior: Partial Success with Finder/cp vs. Failure with diskutil High-Level I/O (Partially Successful): In the DEXT environment, if we operate on an existing volume (e.g., /Volumes/MyVolume), file copy operations using Finder or cp succeed. Furthermore, the logs we've placed in our single I/O entry point, UserProcessParallelTask_Impl, are triggered. Side Effect: However, running ls -al on such a volume shows an incorrect sorting order for files with Traditional Chinese names (they appear before . and ..). Low-Level I/O (Contradictory Behavior): In the DEXT environment, when we operate directly on the raw block device (/dev/disk5): diskutil partitionDisk ... -> Fails 100% of the time with the error: Error: -69825: Wiping volume data to prevent future accidental probing failed. dd command -> Basic read/write operations appear to work correctly (a write can be immediately followed by a read within the same DEXT session, and the data is correct). 3. Evidence of Cache Synchronization Failure (Non-deterministic Behavior) The success of the dd command is not deterministic. Cross-environment tests prove that its write operations are unreliable: First Test: In the DEXT environment, write a file with random data to /dev/disk5 using dd. Reboot into the KEXT environment. Read the data back from /dev/disk5 using dd. The result is a file filled with all zeros. Conclusion: The write operation only went to the hardware cache, and the data was lost upon reboot. Second Test: In the DEXT environment, write the same random file to /dev/disk5 using dd. Key Variable: Immediately after, still within the DEXT environment, read the data back once for verification. The content is correct! Reboot into the KEXT environment. Read the data back from /dev/disk5. This time, the content is correct! Conclusion: The additional read operation in the second test unintentionally triggered a hardware cache flush. This proves that the dd (in our DEXT) write operation by itself does not guarantee synchronization, making its behavior unreliable. Our Problem Based on the observations above, we have the conclusion: High-Level Path (triggered by Finder/cp): When an I/O request originates from the high-level file system, the framework seems to enter a fully-featured mode. In this mode, all SCSI commands, including READ/WRITE, INQUIRY, and SYNCHRONIZE CACHE, are correctly packaged and dispatched to our UserProcessParallelTask_Impl entry point. Therefore, Finder operations are mostly functional. Low-Level Path (triggered by dd/diskutil): When an I/O request originates from the low-level raw block device layer: The most basic READ/WRITE commands can be dispatched (which is why dd appears to work). However, critical management commands, such as INQUIRY and SYNCHRONIZE CACHE, are not being correctly dispatched or handled. This leads to the incorrect device identification in diskutil info and the failure of diskutil partitionDisk due to its inability to confirm cache synchronization. We would greatly appreciate any guidance, suggestions, or insights on how to resolve this discrepancy. Specifically, what is the recommended approach within DriverKit to ensure that a DEXT based on IOUserSCSIParallelInterfaceController can properly declare its capabilities and handle both high-level and low-level I/O requests uniformly? Thank you. Charles

Hello, We are running some tests with our driver with SIP on. We have all the entitlements and everything works smoothly. Thing is, when we run our xxxx.app from Applications, it pops up a GUI with install and uninstall button that we created. When we do install, it prompts us to enable system extension in System settings. I am wondering if there is a way to automate this. I understand I can automate running the xxxx.app from command line but can we automate having to go to System settings->login items & Extensions and enabling our system extension from command line too. Does Apple force an user to go to settings and do it once for security? From my research, I did not find any reliable answer to this. Thank you for your help!

Hi, I recently requested for some entitlements from Apple. In the form that I filled, there was only placeholder for Vendor ID so I put my vendor ID (in decimals). There was no placeholder to specify Device ID. However, in the Description placeholder at the end of the form, I did put the device ID (in decimals). After I got the entitlements, I tried loading my driver to match the device. It does match with only vendor ID but does not match with Vendor and Device ID together. So, now matching has widened little bit more than what we wanted. I was wondering if this is normal or if I did something wrong due to which entitlements was only granted for vendor ID but not for vendor + device Id. Thank you for your time!

I'm encountering a bug developing a (Thunderbolt) PCIDriverKit dext. The system runs well for a while, and then the hardware instance is shut down by the OS (Sonoma 14.7.6) for some unknown reason, but the dext is not, so hardware reads return 0xFFFFFFFF (device disconnected). There is no crash report, or diagnostic report. I don't see anything related in a sysdiagnose capture. The only hint I can find is the kernel logs indicate: 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompletionTimeoutInterrupt Completion timeout detected at address 0xe00510020 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompleterAbortInterrupt Completer Abort received (pri_status = 0x00100407, sec_status = 0x200000f0): 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompleterAbortInterrupt * Received Master Abort on a link side of the Root Complex That address (0xe00510020) looks like it's our PCI device (at a BAR0, offset 0x0020) read. What does this error explicitly mean? Did the device take too long to respond to the read request? After the event, every device on that Thunderbolt bus is disconnected, and a reboot seems to be required. Hardware is a 14" 2023 MacBook Pro M3.

DriverKit kernel crash, possible PCI bridge issue? In working on a DriverKit driver for a legacy SCSI controller, we have finally arrived at the expected (and usually joyful) point in driver development - a repeatable kernel crash and reboot. It happens when the controller first attempts to do "real work" by accessing requests or replies provided to it by the driver. I will provide additional information below (and can share more), but it’s a bit tricky because there is a lot of steps required to get to the point where the PCIe card is sufficiently initialized to respond, presumably attempt a memory access, and bring down the whole system. The system freezes and reboots write after the first MemoryWrite32 with an address of a request. The address is properly (we believe) mapped, using IODMACommand et al, approximately like so: uint64_t reqArrSize = MPT_REQUEST_AREA * kMaxTasks; IOAddressSegment arrseg = {}; IOMemoryMap * arrmap = nullptr; ret = IOBufferMemoryDescriptor::Create(kIOMemoryDirectionInOut, reqArrSize, 0, &ivars->fReqArrayDesc); if (ret != kIOReturnSuccess) { … } IODMACommandSpecification dmaspec = {}; dmaspec.options = kIODMACommandSpecificationNoOptions; dmaspec.maxAddressBits = 32; // tried 31 here but that fails to allocate, the addresses start at 80000000, then leads to a crash // but that seems to be a bridge / SID issue, not the address itself ret = IODMACommand::Create(ivars->pciDevice, kIODMACommandCreateNoOptions, &dmaspec, &ivars->fReqArrayDMA); if (ret != kIOReturnSuccess) { … } ivars->fReqArrayDMA->retain(); uint64_t dmaFlags = 0; uint32_t segCount = 1; // capacity in; actual out IOAddressSegment segs[1] = {}; ret = ivars->fReqArrayDMA->PrepareForDMA(kIODMACommandPrepareForDMANoOptions, ivars->fReqArrayDesc, 0, reqArrSize, &dmaFlags, &segCount, segs); if ((ret != kIOReturnSuccess ) || (segCount != 1)) {…} ivars->fReqArrayPhys = segs[0].address; ivars->fReqArrayDesc->CreateMapping(0,0,0,0,0, &arrmap); // virtual mapping ivars->fReqArray = (uint8_t *)(arrmap ? arrmap->GetAddress() : 0); // virtual ivars->fReqFreemap.set(); // mark all request entries as free memset(ivars->fReqArray, 0, reqArrSize); The crash is very violent and consistent: panic(...): "dart-apciec0 (...): DART DART exception SID 0 ERROR_STATUS 0x80000001 ERROR_ADDRESS 0x0000000080000000 (no exceptionInfo)" @AppleT8110DART.cpp:1720 The fault address is the address we write to one of the controller's control register. We suspect that the issue is that this card uses an 8114 bridge, which uses its SID for the request, instead of the (scsi controller chip) endpoint. The mapping, meanwhile, is under the endpoint’s SID. So when the controller attempts its first request using the physical address, the mapping does not exist at the right level - which brings down the whole system. pcic0-bridge 0x106b/0x1015 Apple TB PCIe port └ pci-bridge 0x1b21/0x2461 ASMedia (TB tunnel) └ pci-bridge 0x1b21/0x2461 ASMedia IOPCITunnelled=Yes └ pci-bridge 0x10b5/0x8114 - (on the controller card) PLX PEX 8114, PCIe-to-PCI-X bridge └ scsi@8 0x1000/0x0030 - (on the controller card), LSI, on bus 4 (PCI-X secondary side) Worse yet, there appears to be no way form within a DEXT to ask for a mapping at a different level, and the 8114 doesn’t have a mapper of its own anyway (attempting to do so with a separate DEXT fails). That last part we know because we tried a workaround with two DEXTs, one that successfully matches the 8114 bridge and the other that matches the SCSI controller chip itself. However, the bridge doesn’t have a mapper attached and so the OS does not seem to give us a useful address (using the same IOBufferMemoryDescriptor::Create, ODMACommand::Create, PrepareForDMA sequence), and 32 bit request simply fails with kIOReturnMessageTooLarge. Attached is a quick diagram of our suspicions and a longer write-up (far warning, unlike the above, that is mostly AI output but it’s been reviewed by the team). Questions: Have others dealt with this problem of legacy PCI devices that have bridges that don’t fit neatly into the restrictions, and what did you do? Is there a way to get the right virtual<->physical mappings recognized at the right level? Is there a way to temporarily turn off SID checking or is that (as I assume) intrinsic to how this works? Are we on the wrong track entirely?

Dear All, I am currently developing a high throughput audio system which operates via PCIe tunneled into a USB4 interface. This include a custom FPGA based hardware and custom Audio DriverKit driver. While performing read operation via the hw DMA (that is a Host to Device transfer), I am noticing sparse latency spikes into the read transfers. Specifically, 4KB operations (which I assume including MRd + CpID) take normally from 5us to 40us to be completed, perfectly fine for my case. However, in some rare occasions, they can end up to 400us, which causes me overruns. The measurements have been carried out from the FPGA and they include the overall request and transfer time. While trying to tackle the problem, I'm investigating the possible power saving options and performance constraint methods at my disposal. I currently use these methods to mitigate the problem. ChangePowerState(kIOServicePowerCapabilityOn); SetPowerOverride(true); RequireMaxBusStall(kIOMaxBusStall25usec); CreatePMAssertion(kIOServicePMAssertionCPUBit | kIOServicePMAssertionForceFullWakeupBit, &ivars->PMAssertionID, false); The buffers are currently about 16MB, single segment, 16KB aligned and, of course, "prepared" for DMA. The system run for 3 hours without any overrun, but I'm not still fully convinced about its reliability. May someone provide me some comments on this? Are there profiling tools that I can use? Feel free to request me any required detail. The testing system is a MacBook Pro M2 Pro. Many Thanks and Best Regards Francesco

We're developing a custom Thunderbolt device and want to expose it to macOS as an ethernet interface, while owning the full network stack implementation up to and including IP, TCP and UDP — bypassing the macOS network stack for those layers. Is IOEthernetController the right DriverKit approach for this, and does it allow intercepting traffic before it reaches the macOS IP stack?

We are developing an IOUserSCSIParallelInterfaceController driver for a legacy controller. After completing init() successfully, no other methods are called before a DriverKit assert failure - .driver.dext) Assertion failed: (notsync || !remote || (msgid == IOService_Start_ID) || queue->OnQueue()), function Invoke, file uioserver.cpp, line 1654. - that leads immediately to "IOPCIDevice::ClientCrashed_Impl() for client " . This appears to be because the framework is attempting a SetPowerState()' during DEXT load, which is delivered off-queue and panics in OSMetaClassBase::Invoke (uioserver.cpp`) before any other dext method runs. Apple Silicon Mac, macOS 26 (DriverKit 25.1 SDK), Xcode 26.x. Expected: The SetPowerState() power-up is delivered on the driver object's dispatch queue (or otherwise handled by the framework), allowing the dext's SetPowerState override to run, ACK via super::SetPowerState(powerFlags, SUPERDISPATCH), and proceed to UserInitializeController. Actual behavior: init() completes (our trace logs init then completed init) Neither Start_Impl nor SetPowerState_Impl ever executes Instead the process fails with the assertion above , IOPCIDevice::ClientCrashed_Impl() reports "client … does not have open session … skipping recovery". The dext crash-loops ("Driver … has crashed N time(s)"). Any suggestions?

Hello everyone, We are in the process of migrating a high-performance storage KEXT to DriverKit. During our initial validation phase, we noticed a performance gap between the DEXT and the KEXT, which prompted us to try and optimize our I/O handling process. Background and Motivation: Our test hardware is a RAID 0 array of two HDDs. According to AJA System Test, our legacy KEXT achieves a write speed of about 645 MB/s on this hardware, whereas the new DEXT reaches about 565 MB/s. We suspect the primary reason for this performance gap might be that the DEXT, by default, uses a serial work-loop to submit I/O commands, which fails to fully leverage the parallelism of the hardware array. Therefore, to eliminate this bottleneck and improve performance, we configured a dedicated parallel dispatch queue (MyParallelIOQueue) for the UserProcessParallelTask method. However, during our implementation attempt, we encountered a critical issue that caused a system-wide crash. The Operation Causing the Panic: We configured MyParallelIOQueue using the following combination of methods: In the .iig file: We appended the QUEUENAME(MyParallelIOQueue) macro after the override keyword of the UserProcessParallelTask method declaration. In the .cpp file: We manually created a queue with the same name by calling the IODispatchQueue::Create() function within our UserInitializeController method. The Result: This results in a macOS kernel panic during the DEXT loading process, forcing the user to perform a hard reboot. After the reboot, checking with the systemextensionsctl list command reveals the DEXT's status as [activated waiting for user], which indicates that it encountered an unrecoverable, fatal error during its initialization. Key Code Snippets to Reproduce the Panic: In .iig file - this was our exact implementation: class DRV_MAIN_CLASS_NAME: public IOUserSCSIParallelInterfaceController { public: virtual kern_return_t UserProcessParallelTask(...) override QUEUENAME(MyParallelIOQueue); }; In .h file: struct DRV_MAIN_CLASS_NAME_IVars { // ... IODispatchQueue* MyParallelIOQueue; }; In UserInitializeController implementation: kern_return_t IMPL(DRV_MAIN_CLASS_NAME, UserInitializeController) { // ... // We also included code to manually create the queue. kern_return_t ret = IODispatchQueue::Create("MyParallelIOQueue", kIODispatchQueueReentrant, 0, &ivars->MyParallelIOQueue); if (ret != kIOReturnSuccess) { // ... error handling ... } // ... return kIOReturnSuccess; } Our Question: What is the officially recommended and most stable method for configuring UserProcessParallelTask_Impl() to use a parallel I/O queue? Clarifying this is crucial for all developers pursuing high-performance storage solutions with DriverKit. Any explanation or guidance would be greatly appreciated. Best Regards, Charles

Does Virtualization.framework support delegating a Thunderbolt/PCIe device to a Linux guest VM running on Apple Silicon? We're developing a custom PCIe device and would like to iterate on the driver in a Linux VM environment on the same host.

Can a Thunderbolt device dynamically expose logical child devices to macOS and control their connection and disconnection lifecycle, independently of the physical device connection?

I need a bit more support. Per Apple’s guidance, our dext’s hosting app checks to see if the dext is installed, and if it is not installed, it will register the dext. I am going to refer to this as “auto registration.” I have also added a menu option to register the dext, which I am going to call “manual registration.” The manual registration works. The user is prompted to “Allow” the dext to be loaded, and things proceed normally. The auto-registration does not work. It produces an error response that is not helpful: Request did fail with Error 1 (The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 1.)) Registration failed, unknown error. They execute the exact same code path – the auto registration calls the menu option’s function that executes from user selection. When comparing the sysextd logs, they differ starting at “Advancing from validating to validating_by_category.” The manual registration has a trace that reads: got reply from com.apple.system_extension.driver_extension... The auto registration does not get this reply. Attached are the two logs. This is Sonoma 14.7.6, the earliest OS we must support. Any suggestions on what is happening or how to fix it so that auto registration can work? Validate_by_category failure trace Validate_by_category success trace

Hi Kevin, I'm starting this new thread to focus on alignment optimization and recalibrating our HBA constraints. Following up on your suggestion about UserReportHBAConstraints and alignment optimization, here are our current DEXT settings: Via UserReportHBAConstraints(): kIOMaximumSegmentCountRead/WriteKey: 129 kIOMaximumSegmentByteCountRead/WriteKey: 65,536 (64 KB) kIOMinimumSegmentAlignmentByteCountKey: 4 bytes kIOMaximumSegmentAddressableBitCountKey: 32 kIOMinimumHBADataAlignmentMaskKey: 0 Via SetProperties() (additional injection): kIOMaximumByteCountRead/WriteKey: 524,288 (512 KB) kIOMaximumBlockCountRead/WriteKey: 1,024 We inherited the segment count (129) and max I/O length (512 KB) from our legacy KEXT, which were originally calculated based on a 4 KB segment size (Max I/O 512 KB / 4 KB + 1 = 129). The current alignment value of 4 was essentially a placeholder, as the legacy hardware didn't enforce strict page-level alignment. Given that our testing is on Apple Silicon, we are considering increasing kIOMinimumSegmentAlignmentByteCountKey to 16,384 (16 KB) to match the native page size. However, I have two specific questions regarding this: Stripe Size vs. Page Size: Our RAID stripe size is typically larger than 16 KB (e.g., 64 KB or 128 KB). Should we be aligning the system to the RAID stripe size for hardware efficiency, or is it more critical to stick to the 16 KB page size to optimize the IOMMU/DART mapping overhead in DriverKit? Recalibration: If we increase the alignment to 16 KB, should we also adjust the kIOMaximumSegmentByteCount to match (i.e., 16 KB), or is it better to keep it at 64 KB to allow fewer, larger segments per I/O? We suspect that the 38% gain we saw in 4 KB Random Reads might improve even further if we fix this alignment bottleneck. Looking forward to your thoughts. Best regards, Charles

Hi Everyone, We are currently migrating a mature legacy KEXT to DriverKit for our PCIe SCSI storage controller (connected via Thunderbolt 3). During the DEXT load sequence, we have observed that the system automatically triggers a power state transition from State 0 (Off) to State 2 (On). However, this process results in a Kernel Panic due to a timeout after approximately 21 seconds. We have verified that our implementation of Start_Impl, UserInitializeController_Impl, and SetPowerState_Impl executes extremely fast, with a total execution time of less than one second. Specifically, SetPowerState_Impl returns kIOReturnSuccess immediately upon being called. Furthermore, our current Info.plist does not contain any IOPowerManagement dictionary or related keys. Despite the fast execution and the absence of explicit power management declarations in the plist, the kernel power management state machine (IOServicePM) still generates a 21-second timeout, leading to the following panic: Panic Log: panic(cpu 7 caller 0xfffffe0020be8fec): MySCSIDriver::setPowerState(0xfffffe2fb1a65c00 : 0xfffffe0020bfed88, 0 -> 2) timed out after 21257 ms @IOServicePM.cpp:5609 com.example.driver.dext: ( id: com.example.driver.dext; path: /Library/SystemExtensions/[UUID]/com.example.driver.dext; state: loaded ) Note on Previous Discussion: I would like to express my gratitude to Kevin from Apple DTS for the helpful discussion regarding the implementation of BundleParallelTask on the forums. Since then, we have shifted our development focus toward completing the overall management ecosystem, delivering a comprehensive operational interface for users, and handling specific user environments and behaviors. Our current priority is ensuring system stability—specifically resolving these Thunderbolt-related power management issues (sleep/wake)—to prepare the product for upcoming testing. I remain very grateful for the guidance provided on batch task optimization and intend to resume those optimizations once this critical stability baseline is secured. Technical Guidance Needed for PM Migration In our legacy KEXT, we utilized PMinit(), registerPowerDriver(), and joinPMtree() to precisely control the timing of power management registration. In transitioning to the DriverKit SDK, we have not found clear guidance on several key points: Standardized Migration Path: What is the recommended way to implement equivalent power management initialization (formerly PMinit) within a DriverKit subclass? In DriverKit, how should we replicate the behavior of manually calling registerPowerDriver and joinPMtree to ensure the driver is only monitored once the hardware is ready? Implicit Power Registration: Why does the system enforce a setPowerState(0 -> 2) transition on a subclass of IOUserSCSIParallelInterfaceController even when no IOPowerManagement dictionary is defined in the Info.plist? Is this a default behavior of the SCSI or PCI transport framework? Thunderbolt Specifics: Are there specific power proxying requirements or configurations for PCIe devices over Thunderbolt to avoid conflicts with the default IOPCIFamily power policies? Best Regards, Charles