I'm pleased to announce that the initial beta of macOS 27.3 (26C5035r) includes our support for software I/O in SCSIControllerDriverKit. The class reference has not yet been updated to include this, but it is described in the release notes: "SCSIControllerDriverKit now supports software controllers. A software controller declares itself by setting kIOPropertySoftwareIOKey (an OSBoolean, from <IOKit/storage/IOStorageControllerCharacteristics.h>) through UserSetHBAProperties(). The system honors this setting only before controller initialization completes, so it stays fixed for the life of the controller. Such a controller doesn’t create any DMA mappings, and your dext can access the data buffer associated with a particular I/O through the UserCopyDataBuffer API. (182426393) (FB23797269)" Clearing up a few details on that process: The property kIOPropertySoftwareIOKey ("Software I/O") is created and set to "false" when IOSCSIParallelInterfaceController is initially created. That means a DEXT can check for software I/O support by using CopyProperties() to look for that key, instead of relying on a system version check or similar side channel check. The kIOPropertySoftwareIOKey must be set before the controller initialization sequence begins. Changes to the value after that point will fail. If kIOPropertySoftwareIOKey has been properly set to "true", then fBufferIOVMAddr will be set to NULL. This behavior can be used as additional confirmation that the kernel driver is properly configured. The deprecation and replacement of UserGetDataBuffer by UserCopyDataBuffer was primarily done to faciliate software I/O controllers. Functionally, the two APIs actually behave identically, however, the name change resolves the analyzer warnings that releasing the returned IOMemoryDescriptor previously caused. __Kevin ElliottDTS Engineer, CoreOS/Hardware

Apple's documentation says that once an app joins a Push to Talk channel, pressing "play" on a headset should start recording. On my iPhone it doesn't. Both the M015(our earbud) and AirPods send the press to Apple Music instead. The phone's own log says "No context for this command", then opens Music. So we ask Apple: What exactly has to be true for the earbud press to reach Push to Talk instead of Music? Does it work at all when nothing is playing? Can one press start and the next press stop, or is it press-and-hold only? Is a Bluetooth data signal from the earbud the only other way?

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

Hi Kevin, I need to revise my earlier assessment completely. I seriously underestimated what App Sandbox can do. My teammate Micha had already proven it. I am now officially outnumbered ;) I guess I'm getting too old for this shit. The only thing that doesn't work yet is formatting LUNs from within the app. It would be great to have this supported as well, just like with USB devices. For now we can live with it. We simply haven't found a suitable API for doing this inside the sandbox. If there is one, please let me know. Honestly, "Sandbox" is a serious understatement for what you built there. "SandOS" would fit much better ;) One example: we have now decoupled our processes with the sandbox. GUI and DEXT run separately. The GUI crashes? iSCSI keeps running. The DEXT crashes? It is back so fast that iSCSI doesn't even notice (!) Both crash? The DEXT recovers. iSCSI holds. The GUI stays closed. Once it is reopened, everything looks as if nothing had happened. Whatever happens in our stack, the storage connection stays intact as long as the OS is running. That is really incredible work by your teams. It opens up completely different possibilities for us. Thank you for challenging my assumption. Best regards, Torsten

Hello, I’m developing a macOS iSCSI initiator intended for Mac App Store distribution. The host app handles iSCSI networking, while an embedded DriverKit extension subclasses IOUserSCSIParallelInterfaceController to expose remote iSCSI LUNs as macOS block devices. This is a virtual network-backed controller, without USB or PCI hardware. Development signing and builds succeed, but Mac App Store export fails because the driver’s distribution provisioning profile does not include: com.apple.developer.driverkit.family.scsicontroller Developer Support confirmed that our team’s approved entitlements include DriverKit UserClient Access, but do not include SCSIControllerDriverKit. They referred us to the forums for guidance. Could an Apple engineer clarify: Is this entitlement available for Mac App Store distribution of a virtual iSCSI controller? Does it require separate approval, and what is the correct application channel? I submitted a System Extension entitlement request selecting “SCSI Controller.” Is that the correct process? submitted request: XNX9Q7TFZ3 Developer Support case: 102995412617 Thank you.

Entitlements requested: com.apple.developer.driverkit.userclient-access com.apple.developer.driverkit.transport.usb com.apple.developer.driverkit.transport.hid com.apple.developer.driverkit.family.hid.eventservice com.apple.developer.driverkit.family.serial com.apple.developer.driverkit.family.scsicontroller com.apple.developer.driverkit.family.networking com.apple.developer.driverkit.family.hid.device , and the base com.apple.developer.driverkit entitlement Hi all, We recently received a decline on the DriverKit entitlement set listed above. The response noted: "Technical details within DriverKit mean that it is not a viable solution for security block or broad-scale system modifications." I'd like to get some clarity on how to bring our request in line with what's approvable, and I'm hoping the forum (or a Code-Level Support engineer) can point us in the right direction. Context on what we're building: We develop a Data Loss Prevention (DLP) product for macOS. We already hold the Endpoint Security entitlement (com.apple.developer.endpoint-security.client) and use it in production today for our core monitoring and policy-enforcement functionality. Why we're requesting DriverKit specifically: ESF gives us visibility and the ability to authorize/deny many file and process events, but it does not give us the control we need over removable/peripheral hardware. Two concrete gaps in our DLP policy enforcement that we're trying to close: Blocking data exfiltration via USB-connected Android devices — when an Android phone is plugged in, it mounts as a USB mass-storage/MTP-style device, and our policy needs to be able to prevent it from mounting or being written to, on a per-policy basis (e.g., disable an endpoint's ability to copy files to a connected Android device). Camera blocking — disabling the built-in/USB camera device at the hardware transport level as part of a DLP policy, rather than a userspace toggle that a privileged process could bypass. Our understanding was that "com.apple.developer.driverkit.transport.usb" combined with the HID/USB family entitlements would let us implement a DriverKit-based USB filtering driver to enforce this. Given the decline language about "security block or broad-scale system modifications," it sounds like Apple's position is that DriverKit is not intended to be used to build a general device-blocking layer this way. What I'm hoping to learn: Is per-policy USB mass-storage/MTP mounting control (blocking a specific class of device, e.g., Android phones, from mounting or transferring files) something DriverKit is intended to support at all for third-party DLP vendors, or is this fundamentally out of scope regardless of how the request is written up? If it is in scope, what should we change in the entitlement request write-up (use case description, scoping of which entitlements we actually need vs. what we requested) to make it approvable? We may have over-requested — for example, do we need family.networking and family.serial at all for USB mass-storage/camera blocking, or should we narrow the request to just the USB transport + HID/SCSI entitlements? Is there a preferred way to demonstrate that our use case is a scoped, policy-driven enterprise DLP control (with IT/MDM deployment, not a consumer app) rather than "broad-scale system modification," or does the entitlement review not distinguish on that basis? Any pointers — either on scoping this request correctly, or on whether this is simply not achievable via DriverKit and we should be looking at a different API — would be much appreciated. Happy to provide more detail on our exact enforcement flow if that's useful for a Code-Level Support ticket. Thanks in advance

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

Summary I have a userspace IOUserSCSIParallelInterfaceController dext presenting a virtual disk. It's a software / no-DMA controller — it moves all data with a kernel CPU copy via UserGetDataBuffer; it never does hardware DMA and never reads fBufferIOVMAddr. Buffered I/O works and the disk mounts. The problem is unbuffered / raw-device I/O. For a data-carrying task, ProcessParallelTask calls PrepareForDMA then GenerateIOVMSegments on the task's IODMACommand, and if the segment count != 1 it fails the task with EIO before ever calling UserProcessParallelTask / UserProcessBundledParallelTasks — so UserGetDataBuffer never gets a chance. I already use UserGetDataBuffer and it works for single-segment (aligned) tasks, but a client buffer that straddles a page boundary produces 2 segments and is rejected at that gate. Concrete symptom newfs_apfs writing the container superblock to the raw device from a page-straddling malloc'd buffer: nx_format:308: failed to write superblock to block 0: 5 - Input/output error Minimal repro against my raw device: an aligned 4 KiB pwrite succeeds; a 4 KiB pwrite from a buffer straddling a 16 KiB page returns errno 5. What I think is going on (not sure) My guess is that the framework expects a DART/IOMMU to coalesce a scattered buffer into one IOVM segment, and my virtual controller doesn't have one (ioreg shows no mapper and no iommu-parent on the node — attached), so GenerateIOVMSegments emits raw physical segments and a straddling buffer stays 2 segments. But I don't know if that's actually the reason, or whether a no-DMA controller is even supposed to go through GenerateIOVMSegments at all — hence the questions below. Questions For a no-DMA controller that services data via UserGetDataBuffer, is there a supported way to make the framework deliver a task whose client buffer maps to more than one IOVM segment (relax/skip the GenerateIOVMSegments single-segment gate), so my upcall can run? UserGetDataBuffer returns a fresh contiguous buffer, so the original buffer's segment count shouldn't matter for a CPU-copy controller. Is there a characteristic to declare a PIO / no-DMA / software controller so the framework skips segment generation for it? Can a DriverKit controller get macOS to interpose an IOMapper/DART in front of it (so the buffer is coalesced into one segment) — via a property, a matching personality, or an intermediate provider nub? Or is a hardwareless controller simply not expected to support unbuffered/raw-device I/O? Environment Build: 26A5368g, arm64e Full ioreg -w0 -r -c IOUserSCSIParallelInterfaceController attached. Happy to file a Feedback with a sysdiagnose and the minimal repro.

I'm writing a software IOUserSCSIParallelInterfaceController in DriverKit — there's no DMA hardware behind it (it forwards commands elsewhere), so for each command I read the payload on the CPU by calling UserGetDataBuffer() from within my task-processing method and then CreateMapping() on the returned IOBufferMemoryDescriptor. This works almost all the time, but I've got an intermittent case I can't explain: for some WRITE tasks the buffer I get back is entirely zero-filled, even though it's a genuine write that should carry data. In those cases the SCSIUserParallelTask.fTransferDirection I'm handed is kSCSIDataTransfer_FromInitiatorToTarget, so the task itself looks like a perfectly normal write to me. It seems to happen when the same task object gets reused — a read on that task, then a write. I got stuck, so I disassembled IOSCSIParallelFamily to try to understand where the buffer comes from. In UserGetDataBuffer_Impl it looks like it allocates a fresh IOBufferMemoryDescriptor, zero-fills it, and only copies the client data in when the transfer direction is "from initiator to target". Roughly what I think I'm seeing: ; allocate a fresh IOBufferMemoryDescriptor, then bzero it bl GetDataTransferDirection ; SCSIParallelTask -> SCSITask (+0x100), then ldrb w0, [x0, #0x5b] cmp w0, #1 ; kSCSIDataTransfer_FromInitiatorToTarget ? b.ne Lskip ; if not a write, leave the buffer zeroed ... client->readBytes(0, bounce, len) ; copy client -> bounce Lskip: ... return bounce ; hand back the (possibly still-zeroed) buffer The direction it tests there is read from the SCSITask itself (the byte at SCSITask+0x5b, via GetDataTransferDirection), not from the fTransferDirection field I get in the task struct. And in the failing cases that byte still seems to hold the previous direction for that task (a read, 0x02), so the cmp w0, #1 doesn't match and the copy is skipped — which would explain the zero buffer. I could easily be misreading the disassembly, so I'd really appreciate a sanity check on the intended contract: Is UserGetDataBuffer the right way for a software (no-DMA) controller to get at write payload on the CPU at all? The docs frame it as the exception and otherwise point at fBufferIOVMAddr, but that reads like an IOVM/physical segment I don't think I can map for CPU access — is there a CPU-accessible path I'm missing? Is it my responsibility (or the layer above me) to make sure the task's data-transfer direction is established before UserGetDataBuffer runs? Is there something I should be doing at task setup / UserMapHBAData / completion so this direction isn't stale when a task object is recycled? Or is the SCSITask direction meant to always agree with fTransferDirection by the time my task-processing method runs, and a mismatch means I've done something wrong on my end? Any pointers on the intended behavior here would be a big help — thanks.

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!

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?

I have a DriverKit dext that implements a virtual SCSI HBA (no physical hardware). Because a bare IOUserSCSIParallelInterfaceController has no provider to match, the bundle ships two IOKitPersonalities: Bootstrap — IOClass IOUserService, IOProviderClass IOUserResources, IOResourceMatch IOKit. In Start() it does SetProperties({NvmeOfSCSIHBA: true}) + RegisterService(), publishing itself as a nub. Controller — IOClass IOUserSCSIParallelInterfaceController, IOProviderClass IOUserService, IOPropertyMatch {NvmeOfSCSIHBA: true} — it matches the bootstrap nub. This loads and runs correctly. The problem is upgrades. Activating a higher CFBundleVersion via OSSystemExtensionRequest.activationRequest (in-place replace) always defers the old version's termination to reboot. The new version reaches [activated enabled] but never starts; the old process keeps running until reboot. From sysextd/kernelmanagerd: kernelmanagerd Dext … v15 … is being replaced and cannot be terminated right away sysextd delegate returns Error Domain=OSSystemExtensionErrorDomain Code=101 "…is being replaced", assumes responsibility for old version …, keeping old version 15 sysextd turning the responsibility for termination of …, version 15 over to delegate (with uninstallation at the next reboot) sysextd a category delegate declined to terminate extension with identifier: … sysextd v15 terminating_for_uninstall → terminating_for_upgrade_via_delegate Key observation: this defers even on a fresh boot where the dext was never opened — no app/daemon ever opened the IOUserClient, no I/O, nothing attached beyond the controller↔nub match. So it does not appear to be a "client still holds it open" / busy-state situation; the driver_extension category delegate declines the moment it's a replacement. What I've tried: In-place activationRequest (replace): always defers to reboot (above). deactivationRequest (standalone): the request hangs — no delegate callback at all (waited ~13 min), even with no client open. Disconnecting all clients first (graceful Stop() that cancels its dispatch queues and completes async) does not change the replace deferral. My understanding from the docs/forums is that the normal reboot-free replace relies on the backing device being disconnected/reconnected to quiesce the old dext (thread 677040). My controller matches a persistent IOUserResources-backed nub that never detaches, so there's no equivalent quiesce point. Questions: For a dext whose only provider is a self-published IOUserResources nub (no detachable hardware), is reboot-free replacement structurally impossible — i.e. is the Code=101 "is being replaced" defer inherent to this matching pattern? Is the supported way to live-upgrade such a dext to deactivationRequest → (on .completed) → activationRequest rather than an in-place replace? If so, what makes a deactivationRequest complete in-session vs. defer to reboot for an IOUserResources-matched dext — and what would cause it to hang with no delegate callback? (Daemon's IOUserClient is closed; the controller's Stop() cancels its queues and completes.) Should the dext itself proactively tear down the published nub (e.g. terminate the bootstrap IOService) before/at upgrade so the controller detaches — or does that just re-match the still-staged old personalities and relaunch the old version? Is there a recommended pattern for a virtual (hardwareless) DriverKit HBA that needs in-field, reboot-free version updates, or is reboot genuinely required for this class of dext? Environment: macOS 27 (Tahoe)

I have a DriverKit dext that implements a virtual SCSI HBA (no physical hardware). Because a bare IOUserSCSIParallelInterfaceController has no provider to match, the bundle ships two IOKitPersonalities: Bootstrap — IOClass IOUserService, IOProviderClass IOUserResources, IOResourceMatch IOKit. In Start() it does SetProperties({NvmeOfSCSIHBA: true}) + RegisterService(), publishing itself as a nub. Controller — IOClass IOUserSCSIParallelInterfaceController, IOProviderClass IOUserService, IOPropertyMatch {NvmeOfSCSIHBA: true} — it matches the bootstrap nub. This loads and runs correctly. The problem is upgrades. Activating a higher CFBundleVersion via OSSystemExtensionRequest.activationRequest (in-place replace) always defers the old version's termination to reboot. The new version reaches [activated enabled] but never starts; the old process keeps running until reboot. From sysextd/kernelmanagerd: kernelmanagerd Dext … v15 … is being replaced and cannot be terminated right away sysextd delegate returns Error Domain=OSSystemExtensionErrorDomain Code=101 "…is being replaced", assumes responsibility for old version …, keeping old version 15 sysextd turning the responsibility for termination of …, version 15 over to delegate (with uninstallation at the next reboot) sysextd a category delegate declined to terminate extension with identifier: … sysextd v15 terminating_for_uninstall → terminating_for_upgrade_via_delegate Key observation: this defers even on a fresh boot where the dext was never opened — no app/daemon ever opened the IOUserClient, no I/O, nothing attached beyond the controller↔nub match. So it does not appear to be a "client still holds it open" / busy-state situation; the driver_extension category delegate declines the moment it's a replacement. What I've tried: In-place activationRequest (replace): always defers to reboot (above). deactivationRequest (standalone): the request hangs — no delegate callback at all (waited ~13 min), even with no client open. Disconnecting all clients first (graceful Stop() that cancels its dispatch queues and completes async) does not change the replace deferral. My understanding from the docs/forums is that the normal reboot-free replace relies on the backing device being disconnected/reconnected to quiesce the old dext (thread 677040). My controller matches a persistent IOUserResources-backed nub that never detaches, so there's no equivalent quiesce point. Questions: For a dext whose only provider is a self-published IOUserResources nub (no detachable hardware), is reboot-free replacement structurally impossible — i.e. is the Code=101 "is being replaced" defer inherent to this matching pattern? Is the supported way to live-upgrade such a dext to deactivationRequest → (on .completed) → activationRequest rather than an in-place replace? If so, what makes a deactivationRequest complete in-session vs. defer to reboot for an IOUserResources-matched dext — and what would cause it to hang with no delegate callback? (Daemon's IOUserClient is closed; the controller's Stop() cancels its queues and completes.) Should the dext itself proactively tear down the published nub (e.g. terminate the bootstrap IOService) before/at upgrade so the controller detaches — or does that just re-match the still-staged old personalities and relaunch the old version? Is there a recommended pattern for a virtual (hardwareless) DriverKit HBA that needs in-field, reboot-free version updates, or is reboot genuinely required for this class of dext? Environment: macOS 27 (Tahoe)

Hopefully a very quick question for anyone familiar with IOUserSCSIParallelInterfaceController - what is the right initialization to implement: init () override; Start (IOService * provider) override; UserInitializeController () override; something else Seems #3 is required, but guidance varies on the others, undoubtedly bc IOUserSCSI.. implements a lot of things beyond the usual DriverKit structure. Thanks in advance for any help. (We're trying to implement a driver for a legacy SCSI controller).

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

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